(Возврат на основную страницу)

Содержание номера за Март 2009 год

SQL Server
для администраторов

Март 2009
№ 3 (33)

Рон Толмейдж

Перенос базы данных: зависимости

Облачный подход — SQL Data Services

Команда SQL Broker

Интеграция данных в масштабе реального времени с помощью Service Broker и другие методики SQL 

Рон Толмейдж

«Подвижность» баз данных как цель проектирования (проектирование баз данных с учетом будущих переносов)

Разрешение взаимоблокировок в SQL Server 2000. Часть 1

Перенос базы данных: зависимости

Чтобы рассмотреть все разновидности зависимостей отдельной базы данных, по-видимому имеет смысл взять в качестве исходной точки саму базу, а затем двигаться наружу, вовне. В этой статье я покажу, как построить контрольный список, на основе которого вы сможете создавать собственные контрольные списки для переносов баз данных.

Почему следует учитывать зависимости?

Невозможно избежать переноса баз данных, и ситуации, в которых приходится выполнять эту операцию, общеизвестны. Ниже перечислены самые распространенные причины перемещений баз данных.

•    Обновление оборудования — подключение нового сервера.

•    Обновление операционной системы Windows до новой версии (что потребует переинсталляции сервера).

•    Обновление до новой версии SQL Server на новом экземпляре.

•    Построение полнофункциональной тестовой версии, системы контроля качества (Quality Assu­rance — QA) или же версии рабочего места разработчика.

Все вышеперечисленные сценарии приводят к необходимости перемещения большинства баз данных на новый сервер. Но перенос базы данных не исчерпывается копированием и последующим восстановлением/присоединением базы. Этих действий недостаточно для сохранения функциональности базы данных на новом месте.

Чтобы перенесенная база данных осталась в рабочем состоянии, необходимо перенести многие из ее зависимостей. На самом деле, чтобы полностью сохранить работоспособность базы, следует восстановить все зависимости. В этой статье под зависимостями базы данных я подразумеваю те объекты, от которых зависит эта база данных, равно как и объекты, которые зависят от нее.

Несложно перенести с одного сервера на другой полностью автономную, «самодостаточную» базу данных, не требующую каких­либо ссылок на внешние объекты. Но даже в этом случае, как показано далее, скорее всего, придется учесть неявные зависимости.

Абсолютно автономные и изолированные базы данных представляют собой исключение. Большинство промышленных баз данных, особенно большие и сложные базы, зависят от компонентов приложений или от других составляющих SQL Server, являющихся внешними по отношению к базе.

Облачный подход — SQL Data Services

Представьте, что вы владеете собственной компанией. Дела идут хорошо, ваше производство растет. Но как будет выглядеть ваша сетевая инфраструктура? Возникнет множество требований, таких как обеспечение роста, гибкости, сохранности и инноваций. Сегодня уже существует способ решения этих проблем, который называется облачной обработкой данных (cloud computing). Подобная концепция нуждается не только в соответствующей аппаратной платформе, но и в соответствующем программном обеспечении — SQL Data Services (SDS).

Исходные данные

Облачные вычисления — это новый способ поддержки приложений. В основе облачных вычислений лежит облачная платформа (cloud platform), которая позволяет разработчикам создавать приложения, выполняемые в облаке, или использовать услуги, предоставляемые облаком, или то и другое одновременно.

В отличие от обычных приложений, приложения в облаке имеют иную архитектуру. Если обычные платформы поддерживают приложения масштабов предприятия, то облачные платформы оперируют в масштабах интернета, оперируя с гораздо большим количеством пользователей одновременно. Эта мощь высокой масштабируемости облачной платформы позволяет предоставлять свою функциональность различными способами.

SDS является такой облачной платформой. Она базируется на HTTP и использует SOAP и протокол REST для формирования запросов и передачи данных между облаком и клиентом. SDS очень гибка, из­за интерфейса служб и простой модели данных. Для простой обработки и оперирования данными в ней есть язык запросов, который работает с этим интерфейсом и моделью данных. А нужен ли нам язык запросов? Не будет ли он простой излишней нагрузкой?

В облачной модели существуют некоторые ограничения. Например, невозможно получить доступ к функциям нижележащей операционной системы, но почему?

«Одной из характеристик, делающих облачные вычисления такими привлекательными, является ее потенциал масштабирования, но для того чтобы приложение, базирующееся на облачной платформе, могло работать с нагрузками интернет­зоны, оно нуждается в определенных ограничениях».

Эти ограничения ведут к тому, что платформа вынуждена предоставлять данные функции самостоятельно и достаточно гибким и эффективным способом, чтобы обработать множество запросов пользователей и быть масштабируемой. Поэтому доступ к хранилищу данных выполняется посредством языка запросов.

Существует также и альтернативный способ хранения данных. SDS использует трехуровневую систему вложенности — концепцию ACE (рис. 2). Это гибкая модель данных, в которой для хранения данных не нужна схема. В ней существует три уровня — владелец (authority), контейнер (container) и объект (entity). Владелец — это единица местоположения, она содержит контейнеры. Каждый контейнер содержит коллекцию объектов и является единицей непротиворечивости (consistency) и контекстом поиска. Объекты — это наборы свойств в виде пар имя­значение и поэтому являются единицами изменения и обновления данных. Такая модель позволяет облаку произвольно масштабироваться.

Интеграция данных в масштабе реального времени с помощью Service Broker и другие методики SQL

В этой статье рассматриваются различные приемы достижения интеграции данных между экземплярами SQL Server в масштабе реального времени. В ней приводится множество примеров кода, которые могут помочь пользователям в разработке. Данный документ сосредотачивается на использовании каждой технологии, которая является частью службы интеграции данных. Используйте упоминаемые ссылки для получения более детальной информации о данных технологиях.

Определение интеграции данных в реальном времени

Интеграция данных в реальном времени обеспечивает управляемый событиями перенос и преобразование информации между разными схемами. Интеграция данных должна быть прозрачной для системы­источника, и не вызывать каких­либо серьезных нагрузок на системы при захвате и доставке событий. Эта методика также поддерживает промежуточный формат, который позволяет разделять схемы систем­источников и систем­приемников. Она позволяет также изменять схемы без прерывания работы приложения в другой системе. Интеграция данных предоставляет быстрый и эффективный способ доставки данных по назначению с использованием управ­ляемой событиями модели без необходимости запроса новых данных у системы­источника.

Интеграция данных о продажах

Демонстрационный проект по интеграции данных в реальном времени иллюстрирует интеграцию данных о продажах между базами данных Adven­tu­reWorks (AW) и Adven­tureWorksDW (AWDW). Служба интеграции данных отслеживает изменения данных о продажах в AW и преобразует данные из схемы AW в обычный XML­формат. Служба пересылает XML­данные в AWDW и преобразует их в соответствующую схему AWDW.

Демо использует демонстрационные базы данных из SQL Server. Перейдите по ссылке для подробной информации об этих базах данных http://msdn.microsoft.com/en­us/library/ms124659.aspx. Пользователи могут скачать и установить эти базы данных для SQL Server2008 по этой ссылке: http://technet.micro­soft.com/en­us/library/ms124501(SQL.100).aspx.

Исчерпывающий код примера вы можете найти по адресу: http://www.codeplex.com/SQLSrvSrvcBrkr/Release/ProjectReleases.aspx?ReleaseId=15139.

«Подвижность» баз данных как цель проектирования (проектирование баз данных с учетом будущих переносов)

При эксплуатации SQL Server в промышленной среде время от времени возникает необходимость переноса баз данных с одного сервера на другой. Это следует учитывать заранее, только приступая к разработке решений на основе SQL Server. Проектировщики и разработчики часто упускают из виду тот факт, что базу данных рано или поздно придется переносить на другой сервер. Колонка текущего месяца — первая из трех, посвященных проблемам, с которыми сталкиваются при перемещениях баз данных. В предлагаемой здесь вступительной статье мы рассмотрим причины, по которым необходимо планировать перенос базы данных еще на этапе проектирования архитектуры приложения.

Проблемы, возникающие при переносе баз данных

Перенести базу данных SQL Server с сервера на сервер несложно. Достаточно сделать резервную копию базы на одном сервере и восстановить ее на другом, отсоединить ее от одного сервера и присоединить к другому или же воспользоваться одной из утилит копирования баз данных.

Проблемы начинаются при попытках добиться корректного функционирования базы данных на новом сервере. В большинстве случаев после переноса базы приходится выполнять дополнительные шаги по воссозданию ее исходной среды, а также переу­станавливать отдельные настройки приложения. На самом деле, задачу по переносу нельзя считать решенной, пока не будут выполнены все заключительные операции. Суть не в том, чтобы приступить к переносу, а в том, чтобы его успешно завершить!

Ситуация, когда перемещение базы данных нарушает функционирование приложения, совсем не редкость. Однажды я стал свидетелем того, как после недели тестирования заказчик отказался от запланированного переноса, настолько промышленная база данных усложнилась в процессе эксплуатации. Обычно вспомогательные объекты и сложные настройки существенно увеличивают время простоя при переносе базы и повышают риск сбоя. Тут кроется ирония: чем дольше находится база данных в эксплуатации, тем сложнее, скорее всего, станут ее зависимости и вспомогательные объекты, и тем тяжелее окажется перенос. Но в тоже время, чем дольше находится база данных в эксплуатации, тем выше вероятность того, что такой перенос потребуется!

«Подвижность» и качество базы данных

Свойства, определяющие качество базы данных, принято объединять в группы, названия которых чаще всего заканчиваются на «­ity» в английском языке (и на «­ость» в русском) — перечислим их:

•    Доступность (Availability).

•    Масштабируемость (Scalability).

•    Безопасность (Security).

•    Поддерживаемость (Maintainability).

•    Развертываемость (Deployability).

•    Расширяемость (Extensibility).

•    Производительность (Performance).

Если база данных проектируется с расчетом на легкий и надежный перенос, это, несомненно, повышает ее качество. Под каким же именем мы внесем это свойство в список? Как подобрать подходящий термин, отражающий способность базы к перемещению с сервера на сервер?

«Переносимость баз данных» («database portability») — звучит отлично, но означает совместимость приложения с продуктами различных поставщиков. (К тому же «переносимость баз данных» имеет специальный смысл в Exchange 2007 — термин относится к переносу баз данных почтовых ящиков между серверами Exchange.) Также отпадает «мобильность баз данных» («database mobility»), поскольку во вселенной Microsoft «мобильность» относится к мобильным устройствам, а никак не к серверам. Более точное по смыслу выражение «транспортабельность баз данных» («database trans­por­ta­bility@), кажется, еще не задействовано в области SQL Server, но «транспортабельность» в исходном виде («transportability») очень похожа на «переносимость» («portability»), да и слово очень длинное (в обоих языках)! Поэтому позвольте мне остановиться на выражении «подвижность баз данных» («data­base mova­bility»), призванном отразить степень сложности операции по переносу базы.

Сценарии переносов баз данных

Проектируя взаимодействие приложения с базой данных, имеет смысл предусмотреть гибкое конфигурирование, облегчающее перемещение базы на другой сервер. Другими словами, следует не жестко кодировать, не «зашивать в код» имена серверов или баз данных, а обеспечить считывание подобной информации из неких внешних (по отношению к приложению) источников, без труда настраиваемых в оперативном режиме.

К тому же, поскольку промышленная база данных постоянно растет и усложняется, важно убедиться, что перенос вместе с базой на другой сервер вспомогательных функционалов и объектов не будет сопряжен со значительными трудностями. Речь идет об именах входа сервера, разрешениях баз данных, заданиях, связанных серверах, пакетах SSIS (SQL Server Integration Services), зеркальных отображениях (mirroring) и конечных точках (endpoint) компонента Service Broker — список можно и продолжить. Весьма вероятно, что подобные объекты усложнят и замедлят перенос сверх начальных ожиданий.

Итак, «подвижность баз данных» должна учитываться уже на этапе проектирования. Чтобы убедиться в этом, рассмотрим несколько потенциальных сценариев, ведущих к переносу базы данных с сервера на сервер.

Разрешение взаимоблокировок в SQL Server 2000. Часть 1

Можно разработать приложение, определяющее взаимоблокировку и повторяющее отмененную вследствие взаимоблокировки транзакцию, но гораздо эффективнее заранее устранить условия, ведущие ко взаимоблокировкам.
В этой статье описывается возникновение взаимоблокировок SQL Server, их разновидности и способы разрешения. Для приложения, поддерживающего сложные транзакции и многопользовательский режим, взаимоблокировки SQL Server нередко становятся досадной и трудноразрешимой проблемой. Взаимоблокировки представляют собой серьезную проблему многопользовательских приложений SQL Server. Они происходят тогда, когда транзакции взаимно блокируют друг друга и каждая из транзакций ожидает завершения другой. SQL Server диагностирует взаимоблокировки, блокирующие ресурсы базы данных, отменяет один из запросов к данным и откатывает транзакцию. Из этой статьи вы узнаете, как использовать SQL Server Profiler и флаг трассировки 1204 для определения и анализа взаимоблокировок. Вы также освоите некоторые приемы, позволяющие устранить причины их возникновения.

Взаимоблокировки (deadlock) встречаются не только при работе с SQL Server. В любой системе баз данных, применяющей блокировочный механизм координирования пользовательских транзакций, с той или иной степенью вероятности могут сложиться усло­вия для возникновения взаимоблокировок. Чтобы разобраться со взаимоблокировками и научиться их разрешать, необходимо освоить основные понятия, относящиеся к этой проблеме.

Табл. 1. Общая схема возникновения взаимоблокировки в SQL Server при блокировках ресурсов

Табл. 2. Наиболее распространенные режимы блокировок ресурсов

Табл. 3. Большинство блокировок ресурсов несовместимы между собой

Да — совместимы. Нет — несовместимы

Табл. 4. Так транзакции удерживают совмещаемые блокировки при различных уровнях изоляции

Табл. 5. История транзакций, участвующих в «моноресурсной» взаимоблокировке

Табл. 6. Взаимоблокировка с участием только монопольных блокировок

Табл. 7. Простая взаимоблокировка типа «X­S»

Табл. 8. Более изощренная блокировка типа «X­S»

(Возврат на основную страницу)