データベースを別のサーバー インスタンスで使用できるようにするときのメタデータの管理 (SQL Server)

  • [アーティクル]

このトピックは、次の状況に関連しています。

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

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

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

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

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

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

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

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

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

サーバー構成の設定

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

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

[上へ]

資格情報

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

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

Note

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 データベースを SQL Server 2014 サーバー インスタンスにアタッチすると、カタログ ファイルは、SQL Server 2005 と同じ他のデータベース ファイルと共に以前の場所からアタッチされます。 詳細については、「 フルテキスト検索のアップグレード」を参照してください。

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

[上へ]

ジョブ

データベースが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]に設定することで作成できます。

注意

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

[上へ]

アクセス許可

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

  • システム オブジェクトに対する GRANT 権限、REVOKE 権限、または DENY 権限

  • サーバー インスタンスに対する GRANT 権限、REVOKE 権限、または DENY 権限 (サーバーレベルの権限)

システム オブジェクトに対する GRANT 権限、REVOKE 権限、または DENY 権限

ストアド プロシージャ、拡張ストアド プロシージャ、関数、ビューなどのシステム オブジェクトに対する権限は、 master データベースに格納されるので、対象のサーバー インスタンスで構成する必要があります。

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

重要

ログインのスクリプトを作成する場合、パスワードはスクリプトに含まれません。 SQL Server認証を使用するログインがある場合は、変換先のスクリプトを変更する必要があります。

システム オブジェクトは、 sys.system_objects カタログ ビューで確認できます。 システム オブジェクトの権限は、 master データベースの sys.database_permissions カタログ ビューで確認できます。 これらのカタログ ビューのクエリとシステム オブジェクトのアクセス許可の付与の詳細については、「 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」を参照してください。

[上へ]

レプリケーションの設定

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

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

[上へ]

Service Broker アプリケーション

Service Broker アプリケーションの多くの側面は、データベースと共に移動します。 ただし、アプリケーションの一部の要素は、新しい場所で再作成または再構成する必要があります。

[上へ]

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

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

[上へ]

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

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

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

[上へ]

参照

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