データベースを別のサーバーで使用できるようにするときのメタデータの管理

  • [アーティクル]

適用対象:SQL Server

この記事は、次の状況に関連しています。

  • Always On可用性グループ可用性グループの可用性レプリカの構成。

  • データベースのデータベース ミラーリングを設定する場合。

  • ログ配布構成内のプライマリ サーバーとセカンダリ サーバー間でロールの変更を準備する場合。

  • 別のサーバー インスタンスにデータベースを復元する場合。

  • 別のサーバー インスタンスにデータベースのコピーをアタッチする場合。

  • メソッドを使用してデータベース エンジンのアップグレードを実行する - 新しいインストールに移行します。

  • データベースをAzure SQLに移行する (仮想マシンまたはManaged Instance)。

アプリケーションによっては、シングル ユーザー データベースのスコープの外部にある情報、エンティティ、オブジェクトに依存することがあります。 通常、アプリケーションには、master データベースと msdb データベースへの依存関係があり、ユーザー データベースにも依存関係があります。 ユーザー データベースの外部に格納される (ユーザー データベースを正しく機能させるために必要な) すべてのデータは、対象のサーバー インスタンスで使用できるようにする必要があります。 たとえば、アプリケーションのログインが、master データベースにメタデータとして格納されているため、それらを宛先サーバーで再作成する必要があります。 アプリケーションまたはデータベースのメンテナンス プランが、メタデータが msdb データベースに格納される SQL Server エージェント ジョブに依存している場合、宛先サーバー インスタンスでこれらのジョブを再作成する必要があります。 同様に、サーバーレベルのトリガーのメタデータは master に格納されます。

アプリケーションのデータベースを別のサーバー インスタンスに移動するときは、移行先サーバー インスタンス上のmasterおよび msdb に、依存しているエンティティとオブジェクトのすべてのメタデータを再作成する必要があります。 たとえば、データベース アプリケーションでサーバー レベルのトリガーを使っている場合、そのデータベースを新しいシステムでアタッチまたは復元するだけでは不十分です。 このデータベースは、master データベース内にそれらのトリガー用のメタデータを手作業で作り直さない限り、正常に動作しません。

ユーザー データベースの外部に格納される情報、エンティティ、およびオブジェクト

ここからは、別のサーバー インスタンスで使用できるようにしたデータベースに影響を及ぼすことが考えられる問題の概要を説明します。 次の一覧に示す情報、エンティティ、またはオブジェクトのうち、1 種類以上の項目を再作成する必要が生じる場合があります。 概要を表示するには、アイテムのリンクを選択します。

サーバー構成の設定

SQL Server 2005 (9.x) 以降のバージョンでは、主要なサービスと機能を選択的にインストールして開始します。 これにより、外部からのアクセスを制限し、攻撃を防ぐことができます。 新規インストールの既定の構成では、多くの機能が有効になっていません。 データベースが、既定で無効になっているサービスまたは機能に依存している場合、対象のサーバー インスタンスでそのサービスまたは機能を有効にする必要があります。

これらの設定の詳細と有効化または無効化については、「サーバー構成オプション (SQL Server)」を参照してください。

資格情報

資格情報は、SQL Server 外部のリソースへの接続に必要な認証情報を含むレコードです。 多くの資格情報は、Windows ログインとパスワードで構成されています。

この機能の詳細については、「 資格情報 (データベース エンジン)」を参照してください。

注意

SQL Server エージェント プロキシ アカウントでは資格情報が使用されます。 プロキシ アカウントの資格情報 ID については、 sysproxies システム テーブルを使用してください。

複数データベースにまたがるクエリ

DB_CHAINING データベース オプションと TRUSTWORTHY データベース オプションは、既定では OFF になっています。 これらのオプションのいずれかが元のデータベースで ON に設定されていると、対象のサーバー インスタンスのデータベースで、これらの設定を有効にする必要がある場合があります。 詳しくは、「 ALTER DATABASE (Transact-SQL)」をご覧ください。

アタッチおよびデタッチ操作により、複数データベースにまたがる組み合わせ所有権が無効になります。 チェーンを有効にする方法については、「 cross db ownership chaining サーバー構成オプション」を参照してください。

詳細については、「信頼できるプロパティを使用するようにミラー データベースを設定する (Transact-SQL)」も参照してください。

データベースの所有権

データベースが別のコンピューターに復元されると、復元操作を開始したSQL Server ログインまたは Windows ユーザーが自動的に新しいデータベースの所有者になります。 復元されたデータベースのシステム管理者または新しいデータベース所有者は、そのデータベースの所有権を変更できます。

分散クエリおよびリンク サーバー

分散クエリおよびリンク サーバーは OLE DB アプリケーションでサポートされます。 分散クエリは、同一コンピューター上または異なるコンピューター上の複数の異種データ ソースのデータにアクセスします。 リンク サーバー構成を使用すると、SQL Serverはリモート サーバー上の OLE DB データ ソースに対してコマンドを実行できます。 これらの機能の詳細については、「 リンク サーバー (データベース エンジン)」を参照してください。

暗号化データ

別のサーバー インスタンスで使用できるようにするデータベースに暗号化データが含まれていて、データベース マスター キーが、元のサーバーのサービス マスター キーによって保護されている場合、そのサービス マスター キーを再度暗号化することが必要になる場合があります。 データベース マスター キー は対称キーで、証明書の秘密キーや暗号化されたデータベース内の非対称キーを保護するときに使用します。 データベース マスター キーを作成するときには、トリプル 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 ステートメントを実行して、データベース マスター キーの自動暗号化解除を有効にすることをお勧めします。 この ALTER MASTER KEY ステートメントにより、サービス マスター キーを使用して暗号化されたデータベース マスター キーのコピーが対象のサーバー インスタンスに提供されます。 詳細については、「 OPEN MASTER KEY (Transact-SQL)」 および 「ALTER MASTER KEY (Transact-SQL)」を参照してください。

ミラー データベースのデータベース マスター キーの自動暗号化解除を有効にする方法については、「 暗号化されたミラー データベースの設定」を参照してください。

詳細については、次のトピックも参照してください。

ユーザー定義エラー メッセージ

ユーザー定義エラー メッセージは、 sys.messages カタログ ビューに存在します。 このカタログ ビューは に master格納されます。 データベース アプリケーションがユーザー定義エラー メッセージに依存していて、データベースを別のサーバー インスタンスで使用できる場合は、 sp_addmessage を使用してユーザー定義エラー メッセージを対象のサーバー インスタンスに追加できます。

イベント通知と Windows Management Instrumentation (WMI) イベント (サーバー レベル)

サーバーレベルのイベント通知

サーバー レベルのイベント通知は に msdb格納されます。 したがって、データベース アプリケーションがサーバーレベルのイベント通知に依存している場合、そのイベント通知を対象のサーバー インスタンスで再作成する必要があります。 サーバー インスタンスでイベント通知を表示するには、 sys.server_event_notifications カタログ ビューを使用します。 詳しくは、「 Event Notifications」をご覧ください。

さらに、イベント通知は Service Broker を使用して配信されます。 受信メッセージのルートは、サービスを含むデータベースには含まれません。 代わりに、明示的なルートは に msdb格納されます。 サービスでデータベース内の明示的なルートを msdb 使用して受信メッセージをサービスにルーティングする場合は、別のインスタンスにデータベースをアタッチするときに、このルートを再作成する必要があります。

Windows Management Instrumentation (WMI) イベント

WMI Provider for Server Events を使用すると、Windows Management Instrumentation (WMI) を使用して、SQL Server内のイベントを監視できます。 データベースが依存する WMI プロバイダーによって公開されているサーバーレベルのイベントに依存するすべてのアプリケーションは、対象のサーバー インスタンスのコンピューターで定義されている必要があります。 WMI イベント プロバイダーは、 で msdb定義されているターゲット サービスを使用してイベント通知を作成します。

Note

詳細については、「 WMI Provider for Server Events の概念」を参照してください。

SQL Server Management Studio を使用して WMI 警告を作成するには

ミラー化されたデータベースに対するイベント通知の動作のしくみ

ミラー化されたデータベースはフェールオーバーできるため、ミラー化されたデータベースに関するイベント通知の複数データベースにまたがる配信は、定義上はリモートで行われます。 Service Broker は、ミラー化されたルートの形式で、ミラー化 されたデータベースに対して特別なサポートを提供します。 ミラー化されたルートには、プリンシパル サーバー インスタンス用とミラー サーバー インスタンス用の 2 つのアドレスがあります。

ミラー化されたルートを設定すると、Service Broker ルーティングでデータベース ミラーリングを認識できるようになります。 ミラー化されたルートを使用すると、Service Broker は会話を現在のプリンシパル サーバー インスタンスに透過的にリダイレクトできます。 たとえば、ミラー化されたデータベース Database_A によってホストされているサービス Service_A について考えてみます。 Database_B によってホストされているもう 1 つのサービス Service_B には Service_A との対話が必要であるとします。 この対話を可能にするには、Database_B に Service_A 用のミラー化されたルートを含める必要があります。 さらに、Database_A には Service_B へのミラー化されていない TCP 転送ルートを含める必要があります。このルートはローカル ルートとは異なり、フェールオーバー後も有効なままです。 これらのルートによって、フェールオーバー後に ACK が返されるようになります。 送信側のサービスは常に同じ形式で名前指定されるので、ルートではブローカー インスタンスを指定する必要があります。

ミラー化されたルートには、ミラー化されたデータベースのサービスが発信側サービスか発信先サービスかにかかわらず、次の要件が適用されます。

  • 発信先サービスがミラー化されたデータベースにある場合、発信側サービスに、発信先に戻るためのミラー化されたルートがあること。 ただし、発信先は通常のルートで発信側に戻れること。

  • イニシエーター サービスがミラー化されたデータベースにある場合、ターゲット サービスには、受信確認と応答を配信するために、イニシエーターへのミラー化されたルートが必要です。 ただし、発信側は通常のルートで発信先に戻れること。

拡張ストアド プロシージャ

重要

この機能は、Microsoft SQL Server の将来のバージョンで削除されます。 新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。 代わりに CLR 統合 を使用してください。

拡張ストアド プロシージャは、拡張ストアド プロシージャ API SQL Server使用してプログラミングされます。 sysadmin 固定サーバー ロールのメンバーは、拡張ストアド プロシージャを SQL Server のインスタンスに登録し、プロシージャを実行する権限をユーザーに付与できます。 拡張ストアド プロシージャは、データベースにのみ master 追加できます。

拡張ストアド プロシージャは、SQL Serverのインスタンスのアドレス空間で直接実行され、メモリ リークやその他の問題が発生して、サーバーのパフォーマンスと信頼性が低下する可能性があります。 参照先データを含むインスタンスとは別のSQL Serverのインスタンスに拡張ストアド プロシージャを格納することを検討する必要があります。 また、データベースへのアクセスには分散クエリを使用することも検討してください。

重要

システム管理者は、拡張ストアド プロシージャをサーバーに追加して他のユーザーに Execute 権限を許可する前に、各拡張ストアド プロシージャに有害なコードや悪意のあるコードが含まれていないことを十分に確認する必要があります。

詳細については、「 GRANT オブジェクトのアクセス許可 (Transact-SQL)」、 DENY オブジェクトのアクセス許可 (Transact-SQL)、 REVOKE オブジェクトのアクセス許可 (Transact-SQL)に関するページを参照してください。

Full-Text Engine for SQL Server プロパティ

Full-Text Engine のプロパティは、 sp_fulltext_serviceによって設定されます。 対象のサーバー インスタンスで、これらのプロパティに必要な設定が行われていることを確認してください。 これらのプロパティの詳細については、「 FULLTEXTSERVICEPROPERTY (Transact-SQL)」を参照してください。

さらに、 ワード ブレーカーとステマー のコンポーネント、または フルテキスト検索フィルター コンポーネントのバージョンが、元のサーバー インスタンスと対象のサーバー インスタンスで異なると、フルテキスト インデックスおよびクエリの動作が異なる場合があります。 また、 類義語辞典 はインスタンス固有のファイルに格納されています。 それらのファイルのコピーを対象のサーバー インスタンスの該当する場所にコピーするか、新しいインスタンス上でこれらのファイルを再作成する必要があります。

注意

フルテキスト カタログ ファイルを含むSQL Server 2005 (9.x) データベースをSQL Server サーバー インスタンスにアタッチすると、カタログ ファイルは、SQL Server 2005 (9.x) と同じ他のデータベース ファイルと共に以前の場所からアタッチされます。 詳細については、「 フルテキスト検索のアップグレード」を参照してください。

詳細については、次のトピックも参照してください。

ジョブ

データベースがSQL Server エージェントジョブに依存している場合は、移行先サーバー インスタンスで再作成する必要があります。 ジョブは環境に依存します。 対象のサーバー インスタンス上で既存のジョブを再作成する場合、元のサーバー インスタンス上のジョブの環境に一致するように対象のサーバー インスタンスを変更することが必要になる場合があります。 次の環境的要因は重要です。

  • ジョブによって使用されるログイン

    SQL Server エージェントジョブを作成または実行するには、まず、ジョブに必要なSQL Serverログインを移行先サーバー インスタンスに追加する必要があります。 詳細については、「 SQL Server エージェント ジョブ ステップを作成および管理するユーザーの構成」を参照してください。

  • SQL Server エージェント サービスのスタートアップ アカウント

    サービス開始アカウントにより、SQL Server エージェントを実行する Microsoft Windows アカウントとそのネットワーク アクセス許可が定義されます。 SQL Server エージェントは、指定されたユーザー アカウントで実行されます。 SQL Server エージェント サービスのコンテキストは、ジョブとその実行環境の設定に影響します。 アカウントは、ジョブで必要とされるネットワーク共有などのリソースにアクセスできる必要があります。 サービス開始アカウントの選択方法と変更方法の詳細については、「 SQL Server エージェント サービスのアカウントの選択」を参照してください。

    正しく稼働するには、適切なドメイン、ファイル システム、およびレジストリの権限を持つようにサービス開始アカウントを構成する必要があります。 また、サービス アカウント用に構成する必要がある共有ネットワーク リソースがジョブで必要になる場合があります。 詳細については、「 Windows サービス アカウントと権限の構成」を参照してください。

  • SQL Serverの特定のインスタンスに関連付けられているSQL Server エージェント サービスには独自のレジストリ ハイブがあり、そのジョブは通常、このレジストリ ハイブの 1 つ以上の設定に依存します。 ジョブが適切に動作するには、それらのレジストリ設定が必要です。 スクリプトを使用して別のSQL Server エージェント サービスでジョブを再作成する場合、そのレジストリにそのジョブの正しい設定がない可能性があります。 再作成されたジョブが移行先サーバー インスタンスで正しく動作するためには、元のサービスと移行先SQL Server エージェントサービスのレジストリ設定が同じである必要があります。

    注意事項

    現在の設定が他のジョブで必要な場合は、再作成されたジョブを処理するために宛先SQL Server エージェントサービスのレジストリ設定を変更すると、問題が発生する可能性があります。 さらに、レジストリを誤って編集すると、システムに重大な障害が発生する場合があります。 レジストリを変更する前に、コンピューター上の重要なすべてのデータをバックアップすることをお勧めします。

  • SQL Server エージェント プロキシ

    SQL Server エージェント プロキシは、指定したジョブ ステップのセキュリティ コンテキストを定義します。 ジョブを対象のサーバー インスタンス上で実行する場合、そのジョブに必要なすべてのプロキシをそのインスタンス上で手動で再作成する必要があります。 詳細については、「 SQL Server エージェント プロキシの作成 」および「 プロキシを使用するマルチサーバー ジョブのトラブルシューティング」を参照してください。

詳細については、次のトピックも参照してください。

既存のジョブと各ジョブのプロパティを表示するには

ジョブを作成するには

ジョブを再作成するスクリプトを使用する場合の推奨事項

まず、単純なジョブをスクリプト化し、他のSQL Server エージェント サービスでジョブを再作成し、ジョブを実行して意図したとおりに動作するかどうかを確認することをお勧めします。 これにより、互換性のない部分を確認し、それらの解決に取り組むことができます。 スクリプト化されたジョブが新しい環境で意図したとおりに動作しない場合は、その環境で正常に動作する同等のジョブを作成することをお勧めします。

Login

SQL Serverのインスタンスにログインするには、有効なSQL Serverログインが必要です。 このログインは、プリンシパルが SQL Server のインスタンスに接続できるかどうかを確認する認証プロセスで使用されます。 対応するSQL Server ログインが未定義であるか、サーバー インスタンスで正しく定義されていないデータベース ユーザーは、インスタンスにログインできません。 このようなユーザーは、そのサーバー インスタンスのデータベースの 孤立ユーザー と呼ばれます。 データベースを復元、アタッチ、または別のインスタンスのSQL Serverにコピーすると、データベース ユーザーが孤立する可能性があります。

元のデータベースのコピーに含まれている一部またはすべてのオブジェクトに対するスクリプトは、SQL Server スクリプト生成ウィザードを使用して、 [スクリプト オプションの選択] ページで [スクリプト ログイン] オプションを [True]に設定することで作成できます。

注意

ミラー化されたデータベースのログインを設定する方法については、「データベース ミラーリングまたはAlways On可用性グループのログイン アカウントの設定 (SQL Server)」および「ロールの切り替え後のログインとジョブの管理 (SQL Server)」を参照してください。

アクセス許可

次の種類の権限は、データベースが別のサーバー インスタンスで使用できるようになったときに影響を受ける場合があります。

  • システム オブジェクトに対する 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)」を参照してください。

サーバー インスタンスに対する 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 再作成し、ログインにマップする必要があります。 データベースを別のサーバー インスタンスに移動、コピー、または復元する場合は、コピー先サーバー インスタンスのデータベースにその master 証明書または非対称キーを再作成し、ログインにマップし、ログインに必要なサーバー レベルのアクセス許可を付与する必要があります。

証明書または非対称キーを作成するには

ログインに証明書または非対称キーをマップするには

マップされたログインに権限を割り当てるには

証明書および非対称キーの詳細については、「 Encryption Hierarchy」を参照してください。

TRUSTWORTHY プロパティ

TRUSTWORTHY データベース プロパティを使用して、SQL Server インスタンスがデータベースとその内容を信頼するかどうかを示します。 データベースがアタッチされているとき、既定で、かつ、安全上の理由から、このオプションは OFF に設定されます。このことは、元のサーバーでこのオプションが ON に設定されている場合も当てはまります。 このプロパティの詳細については、「 TRUSTWORTHY データベース プロパティ 」を参照してください。このオプションをオンにする方法については、「 ALTER DATABASE (Transact-SQL)」を参照してください。

レプリケーションの設定

レプリケートされたデータベースのバックアップを別のサーバーまたはデータベースに復元する場合、レプリケーション設定を保持することはできません。 この場合、バックアップの復元後にすべてのパブリケーションおよびサブスクリプションを再作成する必要があります。 この処理を簡単にするには、現在のレプリケーションの設定を行うスクリプトと、レプリケーションの有効化および無効化を行うスクリプトを作成します。 レプリケーション設定を再作成するには、これらのスクリプトをコピーし、移行先サーバー インスタンスで動作するようにサーバー名の参照を変更します。

詳細については、「レプリケートされたデータベースのバックアップと復元」、「データベース ミラーリングとレプリケーション (SQL Server)」、および「ログ配布とレプリケーション (SQL Server)」を参照してください。

Service Broker アプリケーション

Service Broker アプリケーションの多くの側面は、データベースと共に移動します。 ただし、アプリケーションの一部の要素は、新しい場所で再作成または再構成する必要があります。 既定で、かつ、安全上の理由から、データベースが別のサーバーからアタッチされているとき、is_broker_enabled と is_honoor_broker_priority_on のオプションが OFF に設定されます。 これらのオプションを ON に設定する方法については、「 ALTER DATABASE (Transact-SQL)」を参照してください。

スタートアップ プロシージャ

スタートアップ プロシージャは、自動実行としてマークされ、SQL Serverが開始されるたびに実行されるストアド プロシージャです。 データベースがスタートアップ プロシージャに依存している場合は、対象サーバー インスタンスでデータベースを定義し、起動時に自動的に実行するように構成する必要があります。

トリガー (サーバー レベル)

DDL トリガーは、複数のデータ定義言語 (DDL) イベントに応答してストアド プロシージャを起動します。 これらのイベントは、主に、キーワード CREATE、ALTER、DROP で始まる Transact-SQL ステートメントに対応します。 DDL と同様の操作を実行する特定のシステム ストアド プロシージャも DDL トリガーを起動できます。

この機能の詳細については、「 DDL Triggers」を参照してください。

参照

包含データベース
他のサーバーへのデータベースのコピー
データベースのデタッチとアタッチ (SQL Server)
ログ配布のセカンダリへのフェールオーバー (SQL Server)
データベース ミラーリング セッション中の役割の交代 (SQL Server)
暗号化されたミラー データベースの設定
SQL Server 構成マネージャー
孤立したユーザーのトラブルシューティング (SQL Server)
新しいインストールへの移行 移行の概要: Azure VM 上のSQL ServerへのSQL Server