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

Статья
06/25/2013

Информация в этом разделе применима в следующих ситуациях:

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

Некоторые приложения зависят от информации, сущностей или объектов, которые находятся вне области однопользовательской базы данных. Как правило, приложение зависит от баз данных 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).

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

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

[В начало]

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

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

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

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

[В начало]

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

Если в базе данных, к которой осуществляется доступ с другого экземпляра сервера, содержатся зашифрованные данные, а на исходном сервере главный ключ базы данных защищен главным ключом службы, может потребоваться повторное шифрование главного ключа службы. Главный ключ базы данных — это симметричный ключ, который применяется для защиты закрытых ключей сертификатов и асимметричных ключей, имеющихся в базе данных. При создании этот ключ зашифровывается с помощью алгоритма 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. Дополнительные сведения см. в разделе Уведомления о событиях.

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

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

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

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

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

Создание предупреждения о событии WMI

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

Межбазовая доставка уведомлений о событиях, в которой участвует зеркально отображенная база данных, по определению является удаленной, потому что зеркально отображенная база данных может выполнить переход на другой ресурс. Компонент 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 2012 файлы каталога присоединяются из предыдущего расположения вместе с другими файлами базы данных точно так же, как и в SQL Server 2005. Дополнительные сведения см. в разделе Обновление полнотекстового поиска из SQL Server 2005.

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

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

[В начало]

Задания

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

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

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

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

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

Имена входа

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

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

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

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

[В начало]

Разрешения

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

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

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

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

Важно!
При внесении в скрипт имен входа соответствующие им пароли в скрипт не заносятся. При наличии имен входа, использующих проверку подлинности 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) и Репликация и доставка журналов (SQL Server).

[В начало]

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

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

[В начало]

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

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

[В начало]

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

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

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

[В начало]