Поделиться через

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

Этот раздел относится к следующим ситуациям:

  • Настройка реплик доступности в группе доступности Always On Availability Groups.

  • Настройка зеркального отображения базы данных.

  • Подготовка смены ролей между сервером-источником и сервером-получателем в конфигурации доставки журналов.

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

  • Присоединение копии базы данных к другому экземпляру сервера.

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

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

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

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

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

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

Дополнительные сведения об этих параметрах и включении или отключении см. в разделе "Параметры конфигурации сервера" (SQL Server).

[Top]

Подтверждение компетенции

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

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

Замечание

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

[Top]

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

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

Операции присоединения и отсоединения приводят к отмене межбазовых цепочек владения для базы данных. Сведения о том, как включить цепочки владения, см. в разделе Параметр конфигурации сервера "cross db ownership chaining".

Дополнительные сведения см. в разделе "Настройка зеркальной базы данных для использования надежного свойства " (Transact-SQL)

[Top]

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

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

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

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

[Top]

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

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

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

При копировании, восстановлении или присоединении зашифрованной базы данных к новому экземпляру SQL Server копия главного ключа базы данных, зашифрованная главным ключом службы, не хранится в главном экземпляре сервера назначения. На целевом экземпляре сервера необходимо открыть главный ключ базы данных. Чтобы открыть главный ключ, выполните следующую инструкцию: 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).

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

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

[Top]

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

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

[Top]

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

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

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

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

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

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

Замечание

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

Создание оповещения 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 для возврата после отработки отказа. Поскольку службу отправителя всегда называют тем же способом, маршрут должен указывать экземпляр брокера.

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

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

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

[Top]

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

Это важно

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

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

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

Это важно

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

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

[Top]

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

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

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

Замечание

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

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

[Top]

Вакансии

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

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

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

  • учетная запись запуска службы агент 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 и запуска задания, чтобы узнать, работает ли оно должным образом. Это позволит определить несовместимость и попытаться устранить их. Если скриптное задание не работает должным образом в новой среде, рекомендуется создать эквивалентное задание, которое работает правильно в этой среде.

[Top]

Имена входа

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

Для создания скрипта для нескольких или всех объектов исходной копии базы данных можно воспользоваться мастером создания скриптов и в диалоговом окне Выбор параметров скрипта установить значение TRUE для параметра Внести в скрипт имена входа.

Замечание

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

[Top]

Разрешения

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

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

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

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

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

Для создания скрипта для нескольких или всех объектов исходной копии базы данных можно воспользоваться мастером создания скриптов и в диалоговом окне Выбор параметров скрипта установить значение TRUE для параметра Внести в скрипт разрешения уровня объектов.

Это важно

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

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

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

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

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

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

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

Замечание

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

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

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

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

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

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

[Top]

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

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

Дополнительные сведения см. в статьях "Резервное копирование и восстановление реплицированных баз данных", "Зеркальное отображение баз данных" и "Репликация баз данных" (SQL Server) и "Доставка журналов" (SQL Server).

[Top]

Приложения Service Broker

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

[Top]

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

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

[Top]

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

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

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

[Top]

См. также

Изолированные базы данных
Копирование баз данных на другие серверы
Подключение и отсоединение базы данных (SQL Server)
Отработка отказа на дополнительный поставщик журналов (SQL Server)
Переключение ролей во время сеанса зеркального отображения базы данных (SQL Server)
Настройка зашифрованной зеркальной базы данных
Диспетчер конфигурации SQL Server
Диагностика потерянных пользователей (SQL Server)

  • Last updated on