データベースを別のサーバー インスタンスで使用できるようにするときのメタデータの管理
このトピックは、次の状況における Microsoft SQL Server 2005 以降のバージョンの使用に関連しています。
データベースのデータベース ミラーリングを設定する場合。
ログ配布構成内のプライマリ サーバーとセカンダリ サーバー間でロールの変更を準備する場合。
別のサーバー インスタンスにデータベースを復元する場合。
別のサーバー インスタンスにデータベースのコピーをアタッチする場合。
アプリケーションによっては、シングル ユーザー データベースのスコープの外部にある情報、エンティティ、オブジェクトに依存することがあります。通常、アプリケーションには、master データベースと msdb データベースに対する依存関係があります。また、ユーザー データベースにも依存関係があります。ユーザー データベースの外部に格納される (ユーザー データベースを正しく機能させるために必要な) すべてのデータは、対象のサーバー インスタンスで使用できるようにする必要があります。たとえば、アプリケーションのログインは master データベースにメタデータとして格納されているため、対象サーバーで再作成する必要があります。アプリケーションまたはデータベースのメンテナンス プランが、メタデータが msdb データベースに格納される SQL Server エージェント ジョブに依存する場合、対象のサーバー インスタンスでこれらのジョブを再作成する必要があります。同様に、サーバーレベルのトリガーのメタデータは master に格納されます。
アプリケーションのデータベースを別のサーバー インスタンスに移動するときは、移動先のサーバー インスタンスの master および msdb で、依存しているエンティティとオブジェクトのすべてのメタデータを再作成する必要があります。たとえば、データベース アプリケーションでサーバーレベルのトリガーを使用している場合、そのデータベースを新しいシステムでアタッチまたは復元するだけでは不十分です。このデータベースは、master データベース内のこれらのトリガーのメタデータを手動で再作成しない限り、正常に動作しません。
ユーザー データベースの外部に格納される情報、エンティティ、およびオブジェクト
ここからは、別のサーバー インスタンスで使用できるようにしたデータベースに影響を及ぼすことが考えられる問題の概要を説明します。次の一覧に示す情報、エンティティ、またはオブジェクトのうち、1 種類以上の項目を再作成する必要が生じる場合があります。概要を参照するには、該当する項目のリンクをクリックしてください。
サーバー構成の設定
資格情報
複数データベースにまたがるクエリ
データベースの所有権
分散クエリおよびリンク サーバー
暗号化データ
ユーザー定義エラー メッセージ
イベント通知と Windows Management Instrumentation (WMI) イベント (サーバー レベル)
拡張ストアド プロシージャ
Full-Text Engine for SQL Server プロパティ
ジョブ
ログイン
権限
レプリケーションの設定
Service Broker アプリケーション
スタートアップ プロシージャ
トリガー (サーバー レベル)
サーバー構成の設定
SQL Server 2005 以降のバージョンでは、主要なサービスや機能のインストールと開始を選択的に行います。これにより、外部からのアクセスを制限し、攻撃を防ぐことができます。新規インストール時の既定の構成では、多くの機能が有効化されていません。データベースが、既定で無効になっているサービスまたは機能に依存している場合、対象のサーバー インスタンスでそのサービスまたは機能を有効にする必要があります。
これらの設定、およびその有効化と無効化に関する詳細については、「セキュリティ構成について」および「サーバー構成オプションの設定」を参照してください。
[先頭に戻る]
資格情報
資格情報は、SQL Server 外部のリソースへの接続に必要な認証情報を含むレコードです。多くの資格情報は、Windows ログインとパスワードで構成されています。
この機能の詳細については、「資格情報 (データベース エンジン)」を参照してください。
.gif "注意") 注 |
|---|
SQL Server エージェント プロキシ アカウントでは資格情報を使用します。プロキシ アカウントの資格情報 ID については、sysproxies システム テーブルを使用してください。 |
[先頭に戻る]
複数データベースにまたがるクエリ
DB_CHAINING データベース オプションと TRUSTWORTHY データベース オプションは、既定では OFF になっています。これらのオプションのいずれかが元のデータベースで ON に設定されていると、対象のサーバー インスタンスのデータベースで、これらの設定を有効にする必要がある場合があります。詳細については、「ALTER DATABASE (Transact-SQL)」を参照してください。
SQL Server 2000 Service Pack 3 (SP3) 以降のバージョンの SQL Server では、アタッチおよびデタッチ操作により、複数データベースにまたがる組み合わせ所有権が無効になります。組み合わせ所有権を有効にする方法の詳細については、「cross db ownership chaining オプション」を参照してください。
詳細については、次のトピックも参照してください。
[先頭に戻る]
データベースの所有権
データベースを別のコンピューターに復元すると、復元操作を開始した 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 カタログ ビューを使用します。詳細については、「イベント通知 (データベース エンジン)」を参照してください。
また、イベント通知は Service Broker を使用して配信されます。着信メッセージのルートは、サービスを格納したデータベースには含まれていません。代わりに、明示的なルートが msdb に格納されます。サービスが、サービス宛ての着信メッセージをルーティングするため msdb データベース内の明示的なルートを使用する場合、別のインスタンスにデータベースをアタッチする際はこのルートを再作成する必要があります。詳細については、「Service Broker のルーティング」を参照してください。
リモートのメッセージ配信用にデータベースをセットアップするには
Windows Management Instrumentation (WMI) イベント
WMI Provider for Server Events を使用すれば、Windows Management Instrumentation (WMI) を使用して SQL Server のイベントを監視できます。データベースが依存する WMI プロバイダーによって公開されているサーバーレベルのイベントに依存するすべてのアプリケーションは、対象のサーバー インスタンスのコンピューターで定義されている必要があります。WMI イベント プロバイダーは、msdb で定義されている対象サービスでイベント通知を作成します。
| 注 |
|---|
詳細については、「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 が返されるようになります。送信側のサービスは常に同じ形式で名前指定されるので、ルートではブローカー インスタンスを指定する必要があります。
ミラー化されたルートには、ミラー化されたデータベースのサービスが発信側サービスか発信先サービスかにかかわらず、次の要件が適用されます。
発信先サービスがミラー化されたデータベースにある場合、発信側サービスに、発信先に戻るためのミラー化されたルートがあること。ただし、発信先は通常のルートで発信側に戻れること。
発信側サービスがミラー化されたデータベースにある場合、発信先に、受信確認や応答の配信のために発信側サービスに戻るミラー化されたルートがあること。ただし、発信側は通常のルートで発信先に戻れること。
詳細については、次のトピックも参照してください。
[先頭に戻る]
拡張ストアド プロシージャ
.gif "重要な注意事項") 重要 |
|---|
この機能は、将来のバージョンの Microsoft SQL Server では削除される予定です。新しい開発作業では、この機能の使用を避け、現在この機能を使用しているアプリケーションは修正するようにしてください。代わりに CLR Integration を使用してください。 |
拡張ストアド プロシージャは SQL Server 拡張ストアド プロシージャ API を使用してプログラミングされます。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 データベースを SQL Server 2008 サーバー インスタンスにアタッチする場合、カタログ ファイルは SQL Server 2005 と同様に他のデータベース ファイルと一緒に以前の場所からアタッチされます。詳細については、「フルテキスト検索のアップグレード」を参照してください。 |
詳細については、次のトピックも参照してください。
[先頭に戻る]
ジョブ
データベースが SQL Server エージェント ジョブに依存する場合、対象のサーバー インスタンス上でそれらの SQL Server エージェント ジョブを再作成する必要があります。ジョブは環境に依存します。対象のサーバー インスタンス上で既存のジョブを再作成する場合、元のサーバー インスタンス上のジョブの環境に一致するように対象のサーバー インスタンスを変更することが必要になる場合があります。次の環境的要因は重要です。
ジョブによって使用されるログイン
SQL Server エージェント ジョブを作成または実行するには、まず、ジョブに必要なすべての SQL Server ログインを対象のサーバー インスタンスに追加する必要があります。詳細については、「SQL Server エージェント ジョブを作成および管理できるようにユーザーを構成する方法 (SQL Server Management Studio)」を参照してください。
SQL Server エージェントのサービス開始アカウント
サービス開始アカウントにより、SQL Server エージェントを実行する Microsoft Windows アカウントとそのネットワーク権限が定義されます。SQL Server エージェントは、指定されたユーザー アカウントで実行されます。SQL Server エージェント サービスのコンテキストは、ジョブとその実行環境の設定に影響します。アカウントは、ジョブで必要とされるネットワーク共有などのリソースにアクセスできる必要があります。サービス開始アカウントの選択方法と変更方法の詳細については、「SQL Server エージェント サービスのアカウントの選択」を参照してください。
正しく稼働するには、適切なドメイン、ファイル システム、およびレジストリの権限を持つようにサービス開始アカウントを構成する必要があります。また、サービス アカウント用に構成する必要がある共有ネットワーク リソースがジョブで必要になる場合があります。詳細については、「Windows サービス アカウントの設定」を参照してください。
SQL Server の特定のインスタンスに関連付けられている SQL Server エージェント サービスには独自のレジストリ ハイブが設定されているので、SQL Server エージェント サービスのジョブは、通常、このレジストリ ハイブの 1 つ以上の設定に依存します。ジョブが適切に動作するには、それらのレジストリ設定が必要です。スクリプトを使用して別の 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 の別のインスタンスに復元、アタッチ、またはコピーした後、データベース ユーザーが孤立する可能性があります。
元のデータベースのコピーに含まれている一部またはすべてのオブジェクトに対するスクリプトは、SQL Server スクリプト生成ウィザードを使用して、[スクリプト オプションの選択] ページで [スクリプト ログイン] オプションを [True] に設定することで作成できます。詳細については、「スクリプトを生成する方法 (SQL Server Management Studio)」を参照してください。
SQL Server ログインを表示する方法とサーバー インスタンスの孤立ユーザーを検出および解決する方法の詳細については、「対応するログインの存在しないユーザーに関するトラブルシューティング」を参照してください。
| 注 |
|---|
ミラー化されたデータベースのログインを設定する方法の詳細については、「データベース ミラーリングのログイン アカウントの設定」および「役割の交代後のログインとジョブの管理 (SQL Server)」を参照してください。 |
[先頭に戻る]
権限
次の種類の権限は、データベースが別のサーバー インスタンスで使用できるようになったときに影響を受ける場合があります。
システム オブジェクトに対する GRANT 権限、REVOKE 権限、または DENY 権限
サーバー インスタンスに対する GRANT 権限、REVOKE 権限、または DENY 権限 (サーバーレベルの権限)
システム オブジェクトに対する GRANT 権限、REVOKE 権限、または DENY 権限
ストアド プロシージャ、拡張ストアド プロシージャ、関数、ビューなどのシステム オブジェクトに対する権限は、master データベースに格納されるので、対象のサーバー インスタンスで構成する必要があります。
元のデータベースのコピーに含まれている一部またはすべてのオブジェクトに対するスクリプトは、SQL Server スクリプト生成ウィザードを使用して、[スクリプト オプションの選択] ページで [オブジェクトレベル権限のスクリプトを作成] オプションを [True] に設定することで作成できます。詳細については、「スクリプトを生成する方法 (SQL Server Management Studio)」を参照してください。
| 重要 |
|---|
ログインのスクリプトを作成する場合、パスワードはスクリプトに含まれません。SQL Server 認証を使用するログインがある場合、対象のサーバー インスタンスでスクリプトを変更する必要があります。 |
システム オブジェクトは、sys.system_objects カタログ ビューで確認できます。システム オブジェクトの権限は、master データベースの sys.database_permissions カタログ ビューで確認できます。これらのカタログ ビューに対するクエリの実行およびシステム オブジェクト権限の付与に関する詳細については、「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 データベースに存在する証明書または非対称キーを再作成してログインにマップし、必要なサーバー レベルの権限をそのログインに与える必要があります。
証明書または非対称キーを作成するには
ログインに証明書または非対称キーをマップするには
マップされたログインに権限を割り当てるには
証明書および非対称キーの詳細については、「暗号化階層」を参照してください。
[先頭に戻る]
レプリケーションの設定
レプリケートされたデータベースのバックアップを別のサーバーまたはデータベースに復元する場合、レプリケーションの設定は保存できません。この場合、バックアップの復元後にすべてのパブリケーションおよびサブスクリプションを再作成する必要があります。この処理を簡単にするには、現在のレプリケーションの設定を行うスクリプトと、レプリケーションの有効化および無効化を行うスクリプトを作成します。詳細については、「レプリケーション オブジェクトのスクリプトを作成する方法 (SQL Server Management Studio)」を参照してください。レプリケーションの設定の再作成を容易にするには、これらのスクリプトをコピーし、対象のサーバー インスタンスで動作するようにサーバー名の参照を変更します。
詳細については、「レプリケートされたデータベースのバックアップと復元」、「レプリケーションおよびデータベース ミラーリング」、および「レプリケーションとログ配布」を参照してください。
[先頭に戻る]
Service Broker アプリケーション
Service Broker アプリケーションに関連する多くの要素は、データベースに伴って使用できます。ただし、アプリケーションの一部の要素は、新しい場所で再作成または再構成する必要があります。詳細については、「移行 (Service Broker)」を参照してください。
[先頭に戻る]
スタートアップ プロシージャ
スタートアップ プロシージャは、自動的に実行するように設定され、SQL Server を起動するたびに実行されるストアド プロシージャです。データベースがスタートアップ プロシージャに依存している場合、それらのスタートアップ プロシージャを対象のサーバー インスタンスで定義し、スタートアップ時に自動的に実行されるように構成する必要があります。
詳細については、「ストアド プロシージャの自動実行」を参照してください。
[先頭に戻る]
トリガー (サーバー レベル)
DDL トリガーにより、さまざまなデータ定義言語 (DDL) イベントに応答してストアド プロシージャが起動されます。これらのイベントは、主にキーワード CREATE、ALTER、および DROP で始まる Transact-SQL ステートメントに対応します。DDL と同様の操作を実行する特定のシステム ストアド プロシージャも DDL トリガーを起動できます。
この機能の詳細については、「DDL トリガ」を参照してください。
[先頭に戻る]