Статья
04/01/2012

Управление метаданными при обеспечении доступности базы данных на другом экземпляре сервера

Этот раздел касается использования Microsoft SQL Server 2005 и более поздних версий в следующих ситуациях.

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

Некоторые приложения зависят от информации, сущностей или объектов, которые находятся вне области однопользовательской базы данных. Как правило, приложение зависит от баз данных master, msdb и пользовательской базы данных. Что-либо сохраненное вне пользовательской базы данных, которая требуется для правильного функционирования другой базы данных, должно быть доступно на экземпляре целевого сервера. Например, имена входа для приложений сохраняются как метаданные в базе данных master и должны быть созданы заново на целевом сервере. Если приложение или план обслуживания базы данных зависит от заданий агента SQL Server, чьи метаданные сохранены в базе данных msdb, необходимо создать заново эти задания на экземпляре целевого сервера. Точно так же метаданные сохраняются в базе данных master и для триггера уровня сервера.

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

Информация, сущности и объекты, сохраненные вне пользовательской базы данных

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

Параметры конфигурации сервера
Учетные данные
Межбазовые запросы
Владелец базы данных
Распределенные запросы и связанные серверы
Зашифрованные данные
Определяемые пользователем сообщения об ошибках
Уведомления о событиях и события инструментария управления Windows (WMI) на уровне сервера
Расширенные хранимые процедуры
Свойства средства полнотекстового поиска для SQL Server
Задания
Имена входа
Разрешения
Параметры репликации
Приложения компонента Service Broker
Стартовые процедуры
Триггеры уровня сервера

Параметры конфигурации сервера

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

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

[В начало]

Учетные данные

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

Дополнительные сведения об этой функции см. в разделе Учетные данные (компонент Database Engine).

Примечание
Учетные данные используются учетными записями-посредниками агента SQL Server. Получить идентификационный номер участника-посредника можно в системной таблице sysproxies.

[В начало]

Межбазовые запросы

Параметры базы данных DB_CHAINING и TRUSTWORTHY по умолчанию принимают значение OFF. Если в исходной базе данных какой-либо из этих параметров имеет значение ON, то может потребоваться его включение на целевом экземпляре сервера. Дополнительные сведения см. в разделе ALTER DATABASE (Transact-SQL).

В SQL Server 2000 с пакетом обновления 3 (SP3) и более поздних версиях SQL Server присоединение и отсоединение отключают межбазовые цепочки владения для базы данных. Сведения о том, как включить цепочки владения, см. в разделе Параметр cross db ownership chaining.

Дополнительные сведения см. также в следующих разделах:

[В начало]

Владелец базы данных

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

Распределенные запросы и связанные серверы

Распределенные запросы и связанные серверы поддерживаются приложениями OLE DB. Распределенные запросы получают доступ к данным из нескольких разнородных источников, расположенных на одних и тех же или разных компьютерах. Конфигурация связанных серверов позволяет SQL Server выполнять команды на источниках данных OLE DB с удаленных серверов. Дополнительные сведения об этих функциях см. в разделах Распределенные запросы, Связь серверов и Получение метаданных от связанных серверов.

[В начало]

Зашифрованные данные

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

Чтобы разрешить автоматическое шифрование главного ключа базы данных на экземпляре сервера, копия этого ключа зашифровывается с использованием главного ключа службы. Эта зашифрованная копия хранится как в рабочей базе данных, так и в базе данных master. Обычно копия, хранимая в базе данных master, обновляется при каждом изменении главного ключа без участия пользователя. SQL Server сначала пытается расшифровать главный ключ базы данных с помощью главного ключа службы экземпляра. Если дешифрование завершилось неудачей, SQL Server ищет в хранилище учетные данные главного ключа с таким же семейством идентификатора GUID, что и у базы данных, для которой требуется главный ключ. После этого SQL Server пытается расшифровать главный ключ базы данных при помощи совпадающих учетных данных, перебирая их по порядку до тех пор, пока дешифрование не завершится успешно или не будут просмотрены все подходящие учетные данные. Главный ключ, который не зашифрован с помощью главного ключа службы, следует открывать с помощью инструкции OPEN MASTER KEY и пароля.

При копировании, восстановлении или присоединении зашифрованного ключа базы данных на новом экземпляре SQL Server в базе данных master целевого сервера не содержится копия главного ключа базы данных, зашифрованного с использованием главного ключа службы. На целевом экземпляре сервера необходимо открыть главный ключ базы данных. Сделать это можно, выполнив следующую инструкцию: OPEN MASTER KEY DECRYPTION BY PASSWORD ='password'. После этого рекомендуется выполнить следующую инструкцию, чтобы включить автоматическое дешифрование главного ключа: ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY. Эта инструкция передает экземпляру сервера копию главного ключа базы данных, зашифрованного с использованием главного ключа службы. Дополнительные сведения см. в разделах OPEN MASTER KEY (Transact-SQL) и ALTER MASTER KEY (Transact-SQL).

Сведения о включении автоматического дешифрования главного ключа базы данных в зеркальной копии базы данных см. в разделе Настройка зашифрованной зеркальной базы данных.

Дополнительные сведения см. также в следующих разделах:

[В начало]

Определяемые пользователем сообщения об ошибках

Определяемые пользователем сообщения об ошибках настраиваются в представлении каталога sys.messages, которое хранится в базе данных master. Если приложение базы данных зависит от определяемых пользователем сообщений об ошибках и если эта база данных доступна на другом экземпляре сервера, то для добавления на целевой экземпляр сервера уже имеющихся определяемых пользователем сообщений об ошибках следует пользоваться хранимой процедурой sp_addmessage.

[В начало]

Уведомления о событиях и события инструментария управления Windows (WMI) на уровне сервера

Уведомления о событии на уровне сервера

Уведомления о событиях уровня сервера хранятся в базе данных msdb. Поэтому, если приложение базы данных находится в зависимости от уведомления о событии уровня сервера, уведомления о событии необходимо создать и на целевом экземпляре сервера. Для просмотра уведомлений о событиях на экземпляре сервера используется представление каталога sys.server_event_notifications. Дополнительные сведения см. в разделе Уведомления о событиях (компонент Database Engine).

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

Настройка базы данных для удаленной доставки сообщений

Миграция (компонент Service Broker)

События инструментария управления Windows (WMI)

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

Примечание
Дополнительные сведения см. в разделе Основные понятия о поставщике WMI для событий сервера.

Создание оповещения WMI в среде SQL Server Management Studio

Как создать предупреждение о событии WMI (среда SQL Server Management Studio)

Принцип работы уведомлений о событиях зеркальной базы данных

Межбазовая доставка уведомлений о событиях, которая вовлекает зеркально отображенную базу данных, является удаленной, потому что зеркально отображенная база данных может выполнить переход на другой ресурс. Компонент Service Broker поддерживает зеркально отображенные базы данных в форме маршрутов зеркального отображения. Маршрут зеркального отображения имеет два адреса: один для экземпляра основного сервера и другой для экземпляра зеркального сервера.

С помощью настройки маршрутов зеркального отображения создается маршрутизация компонента Service Broker, учитывающая зеркальное отображение базы данных. Маршруты зеркального отображения позволяют компоненту Service Broker явно переадресовывать сеансы связи на текущий экземпляр основного сервера. Например, рассмотрим службу Service_A, которая расположена на зеркальной базе данных Database_A. Предположим, что необходима другая служба Service_B, расположенная в базе данных Database_B, чтобы вести диалог со службой Service_A. Для этого диалога база данных Database_B должна содержать зеркально отображенный маршрут для службы Service_A. Кроме того, база данных Database_A должна содержать незеркальный маршрут протокола TCP к службе Service_B, который в отличие от локального остается допустимым после переключения на другой ресурс. Эти маршруты включают ACK для возврата после отработки отказа. Поскольку службу отправителя всегда называют тем же способом, маршрут должен указывать экземпляр брокера.

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

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

Дополнительные сведения см. также в следующих разделах:

[В начало]

Расширенные хранимые процедуры

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

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

Программирование расширенных хранимых процедур осуществляется с помощью API-интерфейса расширенных хранимых процедур SQL Server. Участник предопределенной роли сервера sysadmin может зарегистрировать расширенную хранимую процедуру на экземпляре SQL Server и выдать пользователям разрешение на ее выполнение. Расширенные хранимые процедуры будут добавляться только в базу данных master.

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

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

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

Дополнительные сведения см. в разделах GRANT, предоставление разрешений на объект (Transact-SQL), DENY, запрет разрешений на объект (Transact-SQL) и REVOKE, отмена разрешения (Transact-SQL).

[В начало]

Свойства средства полнотекстового поиска для SQL Server

Свойства средства полнотекстового поиска устанавливаются процедурой sp_fulltext_service. Убедитесь, что на целевом экземпляре сервера настроены необходимые для этих свойств параметры. Дополнительные сведения об этих свойствах см. в разделе FULLTEXTSERVICEPROPERTY (Transact-SQL).

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

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

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

Дополнительные сведения см. также в следующих разделах:

[В начало]

Задания

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

Имя входа, используемое заданием

Для создания или выполнения заданий агента SQL Server на целевой экземпляр сервера сначала нужно добавить необходимые ему имена входа SQL Server. Дополнительные сведения см. в разделе Как разрешить пользователю создание и управление заданиями агента SQL Server (среда SQL Server Management Studio).
Стартовая учетная запись службы агента SQL Server

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

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

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

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

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

Учетные записи-посредники агента SQL Server

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

Дополнительные сведения см. также в следующих разделах:

Реализация заданий
Управление именами входа и заданиями после переключения ролей (для зеркального отображения базы данных)
Настройка учетных записей служб Windows (при установке экземпляра SQL Server)
Настройка агента SQL Server (при установке экземпляра SQL Server)
Обеспечение безопасности агента SQL Server

Просмотр существующих заданий и их свойств

Создание задания

Создание сценария существующего задания

Как создавать сценарии для заданий с помощью Transact-SQL (среда SQL Server Management Studio)

Имена входа

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

Для создания сценария для нескольких или всех объектов исходной копии базы данных можно воспользоваться мастером создания сценариев и в диалоговом окне Выбор параметров сценария установить значение TRUE для параметра Внести в сценарий имена входа. Дополнительные сведения см. в разделе Как сформировать сценарий (среда SQL Server Management Studio).

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

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

[В начало]

Разрешения

При открытии доступа к базе данных на другом экземпляре сервера могут быть применены следующие типы разрешений:

Разрешения GRANT, REVOKE или DENY на системные объекты.
Разрешения GRANT, REVOKE или DENY на экземпляр сервера (разрешения уровня сервера).

Разрешения GRANT, REVOKE или DENY на системные объекты

Разрешения на такие системные объекты, как хранимые процедуры, расширенные хранимые процедуры, функции и представления, хранятся в базе данных master и должны быть сконфигурированы на целевом экземпляре сервера.

Для создания сценария для нескольких или всех объектов исходной копии базы данных можно воспользоваться мастером создания сценариев и в диалоговом окне Выбор параметров сценария установить значение TRUE для параметра Внести в сценарий разрешения уровня объектов. Дополнительные сведения см. в разделе Как сформировать сценарий (среда SQL Server Management Studio).

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

Системные объекты отображаются в представлении каталога sys.system_objects. Разрешения на доступ к системным объектам отображаются в представлении каталога sys.database_permissions в базе данных master. Сведения о запросе этих представлений каталога и выдаче разрешений на уровне объектов см. в разделе GRANT, предоставление разрешения на системный объект (Transact-SQL). Дополнительные сведения см. в разделах REVOKE, отмена разрешения на системные объекты (Transact-SQL) и DENY, запрет разрешений на системные объекты (Transact-SQL).

Разрешения GRANT, REVOKE или DENY на экземпляр сервера

Разрешения в области сервера хранятся в базе данных master и должны быть сконфигурированы на целевом экземпляре сервера. Чтобы получить сведения о разрешениях сервера на экземпляре сервера, запросите представление каталога sys.server_permissions, сведения об участниках сервера можно получить из представления каталога sys.server_principals, а сведения о членстве ролей сервера содержатся в представлении каталога sys.server_role_members.

Дополнительные сведения см. в разделах GRANT, предоставление разрешений на сервер (Transact-SQL), REVOKE, отмена разрешений сервера (Transact-SQL) и DENY, запрет разрешений на сервере (Transact-SQL).

Разрешения уровня сервера на сертификат или асимметричный ключ

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

Примечание
Сопоставленное имя входа используется только для проверки правильности кода, подписанного соответствующим сертификатом или асимметричным ключом. Сопоставленные учетные записи не могут быть использованы для проверки правильности.

Сопоставленное имя входа используется только для проверки правильности кода, подписанного соответствующим сертификатом или асимметричным ключом. Сопоставленные учетные записи не могут быть использованы для проверки правильности.

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

Создание сертификата или асимметричного ключа

Сопоставление сертификата или асимметричного ключа

CREATE LOGIN (Transact-SQL)

Выдача разрешений сопоставленному имени входа

GRANT, предоставление разрешений на сервер (Transact-SQL)

Дополнительные сведения о сертификатах и асимметричных ключах см. в разделе Иерархия средств шифрования.

[В начало]

Параметры репликации

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

Дополнительные сведения см. в разделах Резервное копирование и восстановление из копий реплицируемых баз данных, Репликация и зеркальное отображение базы данных и Репликация и доставка журналов.

[В начало]

Приложения компонента Service Broker

Многие аспекты приложения компонента Service Broker перемещаются вместе с базой данных. Однако некоторые из них в новом местоположении необходимо создать или настроить повторно. Дополнительные сведения см. в разделе Миграция (компонент Service Broker).

[В начало]

Стартовые процедуры

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

Дополнительные сведения см. в разделе Автоматическое выполнение хранимых процедур.

[В начало]

Триггеры уровня сервера

Триггеры DDL вызывают хранимые процедуры в ответ на ряд событий языка DDL. Эти события в основном соответствуют инструкциям языка Transact-SQL, начинающимся ключевыми словами CREATE, ALTER или DROP. Триггеры DDL могут быть вызваны определенными системными хранимыми процедурами, функциональность которых схожа с операциями DDL.

Дополнительные сведения об этой возможности см. в разделе Триггеры DDL.

[В начало]