Блог

В SQL Server 2012 они представили автономную базу данных. Какова реальная цель этой функции? Какие недостатки предыдущих версий он исправил?

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

Например, в Denali эти проблемы решаются:

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

• Если у вас есть база данных с параметрами сортировки, которые отличаются от параметров сортировки сервера, вы можете обнаружить, что у вас возникают конфликты параметров сортировки при объединении или выполнении других операций с таблицами #temp, потому что создаваемые таблицы #temp наследуют параметры сортировки сервера, а не вызывающую базу данных. Хотя вы можете обойти это, указав предложение COLLATE для каждой отдельной ссылки на столбец, в случае с автономными базами данных #tempdb наследует параметры сортировки вызывающей базы данных, переопределяя параметры сортировки сервера.

• Функция THROW() также может практически попасть в эту категорию, поскольку вам больше не нужно использовать sys.messages для хранения пользовательских сообщений. Это не так распространено, как две вышеуказанные проблемы, но, безусловно, облегчает переход на новый сервер, если нет необходимости синхронизировать sys.messages. Это не ограничивается автономными базами данных, но играет ту же роль.

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

В будущих версиях будут устранены другие проблемы. Например:

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

• Связанные серверы также являются внешней зависимостью. Это можно легко решить с помощью связанных серверов на уровне базы данных — тем более, что они представляют собой нечто большее, чем контейнеры-синонимы / указатели.

Есть и другие, но они сильно пострадали.