データベースを別のサーバーで使用できるようにするときのメタデータの管理Manage Metadata When Making a Database Available on Another Server

このトピックに適用されますはいSQL ServerありませんAzure SQL DatabaseありませんAzure SQL Data Warehouseありません。並列データ ウェアハウスTHIS TOPIC APPLIES TO: yesSQL ServernoAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

この記事は、次の状況に関連しています。This article is relevant in the following situations:

  • Always On 可用性グループAlways On availability groups 可用性グループの可用性レプリカを構成する場合。Configuring the availability replicas of an Always On 可用性グループAlways On availability groups availability group.

  • データベースのデータベース ミラーリングを設定する場合。Setting up database mirroring for a database.

  • ログ配布構成内のプライマリ サーバーとセカンダリ サーバー間でロールの変更を準備する場合。When preparing to change roles between primary and secondary servers in a log shipping configuration.

  • 別のサーバー インスタンスにデータベースを復元する場合。Restoring a database to another server instance.

  • 別のサーバー インスタンスにデータベースのコピーをアタッチする場合。Attaching a copy of a database on another server instance.

    アプリケーションによっては、シングル ユーザー データベースのスコープの外部にある情報、エンティティ、オブジェクトに依存することがあります。Some applications depend on information, entities, and/or objects that are outside of the scope of a single user database. 通常、アプリケーションには、 master データベースと msdb データベースに対する依存関係があります。また、ユーザー データベースにも依存関係があります。Typically, an application has dependencies on the master and msdb databases, and also on the user database. ユーザー データベースの外部に格納される (ユーザー データベースを正しく機能させるために必要な) すべてのデータは、対象のサーバー インスタンスで使用できるようにする必要があります。Anything stored outside of a user database that is required for the correct functioning of that database must be made available on the destination server instance. たとえば、アプリケーションのログインが、 master データベースにメタデータとして格納されているため、それらを移行先サーバーで再作成する必要があります。For example, the logins for an application are stored as metadata in the master database, and they must be re-created on the destination server. アプリケーションまたはデータベースのメンテナンス プランが、メタデータが SQL ServerSQL Server msdb データベースに格納される エージェント ジョブに依存する場合、対象のサーバー インスタンスでこれらのジョブを再作成する必要があります。If an application or database maintenance plan depends on SQL ServerSQL Server Agent jobs, whose metadata is stored in the msdb database, you must re-create those jobs on the destination server instance. 同様に、サーバーレベルのトリガーのメタデータは masterに格納されます。Similarly, the metadata for a server-level trigger is stored in master.

    アプリケーションのデータベースを別のサーバー インスタンスに移動するときは、移行先サーバー インスタンス上の master および msdb に、依存しているエンティティとオブジェクトのすべてのメタデータを再作成する必要があります。When you move the database for an application to another server instance, you must re-create all the metadata of the dependant entities and objects in master and msdb on the destination server instance. たとえば、データベース アプリケーションでサーバーレベルのトリガーを使用している場合、そのデータベースを新しいシステムでアタッチまたは復元するだけでは不十分です。For example, if a database application uses server-level triggers, just attaching or restoring the database on the new system is not enough. このデータベースは、 master データベース内にこれらのトリガーのメタデータを手動で再作成しない限り、正常に動作しません。The database will not work as expected unless you manually re-create the metadata for those triggers in the master database.

ユーザー データベースの外部に格納される情報、エンティティ、およびオブジェクトInformation, Entities, and Objects That Are Stored Outside of User Databases

ここからは、別のサーバー インスタンスで使用できるようにしたデータベースに影響を及ぼすことが考えられる問題の概要を説明します。The remainder of this article summarizes the potential issues that might affect a database that is being made available on another server instance. 次の一覧に示す情報、エンティティ、またはオブジェクトのうち、1 種類以上の項目を再作成する必要が生じる場合があります。You might have to re-create one or more of the types of information, entities, or objects listed in the following list. 概要を参照するには、該当する項目のリンクをクリックしてください。To see a summary, click the link for the item.

Server Configuration SettingsServer Configuration Settings

SQL Server 2005SQL Server 2005 以降のバージョンでは、主要なサービスや機能のインストールと開始を選択的に行います。 and later versions selectively install and starts key services and features. これにより、外部からのアクセスを制限し、攻撃を防ぐことができます。This helps reduce the attackable surface area of a system. 新規インストール時の既定の構成では、多くの機能が有効化されていません。In the default configuration of new installations, many features are not enabled. データベースが、既定で無効になっているサービスまたは機能に依存している場合、対象のサーバー インスタンスでそのサービスまたは機能を有効にする必要があります。If the database relies on any service or feature that is off by default, this service or feature must be enabled on the destination server instance.

これらの設定、およびその有効化と無効化に関する詳細については、「サーバー構成オプション (SQL Server)」を参照してください。For more information about these settings and enabling or disabling them, see Server Configuration Options (SQL Server).

[資格情報]Credentials

資格情報は、 SQL ServerSQL Server外部のリソースへの接続に必要な認証情報を含むレコードです。A credential is a record that contains the authentication information that is required to connect to a resource outside SQL ServerSQL Server. 多くの資格情報は、Windows ログインとパスワードで構成されています。Most credentials consist of a Windows login and password.

この機能の詳細については、「資格情報 (データベース エンジン)」を参照してください。For more information about this feature, see Credentials (Database Engine).

注: SQL ServerSQL Server エージェント プロキシ アカウントでは資格情報を使用します。NOTE: SQL ServerSQL Server Agent Proxy accounts use credentials. プロキシ アカウントの資格情報 ID については、 sysproxies システム テーブルを使用してください。To learn the credential ID of a proxy account, use the sysproxies system table.

Cross-Database QueriesCross-Database Queries

DB_CHAINING データベース オプションと TRUSTWORTHY データベース オプションは、既定では OFF になっています。The DB_CHAINING and TRUSTWORTHY database options are OFF by default. これらのオプションのいずれかが元のデータベースで ON に設定されていると、対象のサーバー インスタンスのデータベースで、これらの設定を有効にする必要がある場合があります。If either of these are set to ON for the original database, you may have to enable them on the database on the destination server instance. 詳細については、「ALTER DATABASE (Transact-SQL)」を参照してください。For more information, see ALTER DATABASE (Transact-SQL).

アタッチおよびデタッチ操作により、複数データベースにまたがる組み合わせ所有権が無効になります。Attach-and-detach operations disable cross-database ownership chaining for the database. チェーンを有効にする方法については、「cross db ownership chaining サーバー構成オプション」を参照してください。For information about how to enable chaining, see cross db ownership chaining Server Configuration Option.

詳細については、「TRUSTWORTHY プロパティを使用するようにミラー データベースを設定する方法 (Transact-SQL)」も参照してくださいFor more information, see also Set Up a Mirror Database to Use the Trustworthy Property (Transact-SQL)

データベースの所有権Database Ownership

データベースを別のコンピューターに復元すると、復元操作を開始した SQL ServerSQL Server ログイン ユーザーまたは Windows ユーザーが自動的に新しいデータベースの所有者になります。When a database is restored on another computer, the SQL ServerSQL Server login or Windows user who initiated the restore operation becomes the owner of the new database automatically. 復元されたデータベースのシステム管理者または新しいデータベース所有者は、そのデータベースの所有権を変更できます。When the database is restored, the system administrator or the new database owner can change database ownership.

分散クエリおよびリンク サーバーDistributed Queries and Linked Servers

分散クエリおよびリンク サーバーは OLE DB アプリケーションでサポートされます。Distributed queries and linked servers are supported for OLE DB applications. 分散クエリは、同一コンピューター上または異なるコンピューター上の複数の異種データ ソースのデータにアクセスします。Distributed queries access data from multiple heterogeneous data sources on either the same or different computers. リンク サーバーを構成すると、 SQL ServerSQL Server はリモート サーバー上の OLE DB データ ソースに対してコマンドを実行できます。A linked server configuration enables SQL ServerSQL Server to execute commands against OLE DB data sources on remote servers. 詳しくは、「リンク サーバー (データベース エンジン)」を参照してください。For more information about these features, see Linked Servers (Database Engine).

暗号化データEncrypted Data

別のサーバー インスタンスで使用できるようにするデータベースに暗号化データが含まれていて、データベース マスター キーが、元のサーバーのサービス マスター キーによって保護されている場合、そのサービス マスター キーを再度暗号化することが必要になる場合があります。If the database you are making available on another server instance contains encrypted data and if the database master key is protected by the service master key on the original server, it might be necessary to re-create the service master key encryption. データベース マスター キー は対称キーで、証明書の秘密キーや暗号化されたデータベース内の非対称キーを保護するときに使用します。The database master key is a symmetric key that is used to protect the private keys of certificates and asymmetric keys in an encrypted database. データベース マスター キーを作成するときには、トリプル DES アルゴリズムとユーザー指定のパスワードを使用してデータベース マスター キーを暗号化します。When created, the database master key is encrypted by using the Triple DES algorithm and a user-supplied password.

サーバー インスタンスでデータベース マスター キーの暗号化を自動的に解除できるようにするには、サービス マスター キーを使用してデータベース マスター キーのコピーを暗号化します。To enable the automatic decryption of the database master key on a server instance, a copy of this key is encrypted by using the service master key. この暗号化されたコピーをデータベースと masterデータベースの両方に格納します。This encrypted copy is stored in both the database and in master. 通常、 master に格納されたコピーは、マスター キーが変更されるたびに暗黙的に更新されます。Typically, the copy stored in master is silently updated whenever the master key is changed. SQL ServerSQL Server により、インスタンスのサービス マスター キーを使用して、データベース マスター キーの暗号化解除が最初に試行されます。 first tries to decrypt the database master key with the service master key of the instance. 暗号化解除が失敗した場合、 SQL ServerSQL Server では資格情報ストア内で、マスター キーが必要なデータベースと同じファミリ GUID のマスター キー資格情報が検索されます。If that decryption fails, SQL ServerSQL Server searches the credential store for master key credentials that have the same family GUID as the database for which it requires the master key. SQL ServerSQL Server では、次に、一致した資格情報を順に使用してデータベースのマスター キーの暗号化解除が試行されます。これは暗号化解除が成功するか、資格情報がなくなった時点で終了します。 then tries to decrypt the database master key with each matching credential until the decryption succeeds or there are no more credentials. サービス マスター キーによって暗号化されていないマスター キーは、OPEN MASTER KEY ステートメントとパスワードを使用して開かれている必要があります。A master key that is not encrypted by the service master key must be opened by using the OPEN MASTER KEY statement and a password.

暗号化されたデータベースがコピー、復元、または SQL ServerSQL Serverの新しいインスタンスにアタッチされた場合、サービス マスター キーによって暗号化されたデータベース マスター キーのコピーは、対象のサーバー インスタンスの master データベースに格納されません。When an encrypted database is copied, restored, or attached to a new instance of SQL ServerSQL Server, a copy of the database master key encrypted by the service master key is not stored in master on the destination server instance. 対象のサーバー インスタンスで、データベースのマスター キーを開く必要があります。On the destination server instance, you must open the master key of the database. マスター キーを開くには、OPEN MASTER KEY DECRYPTION BY PASSWORD ='password' ステートメントを実行します。To open the master key, execute the following statement: OPEN MASTER KEY DECRYPTION BY PASSWORD ='password'. 次に、ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY ステートメントを実行して、データベース マスター キーの自動暗号化解除を有効にすることをお勧めします。We recommend that you then enable automatic decryption of the database master key by executing the following statement: ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY. この ALTER MASTER KEY ステートメントにより、サービス マスター キーを使用して暗号化されたデータベース マスター キーのコピーが対象のサーバー インスタンスに提供されます。This ALTER MASTER KEY statement provisions the server instance with a copy of the database master key that is encrypted with the service master key. 詳細については、「OPEN MASTER KEY (Transact-SQL)」と「ALTER MASTER KEY (Transact-SQL)」を参照してください。For more information, see OPEN MASTER KEY (Transact-SQL) and ALTER MASTER KEY (Transact-SQL).

ミラー データベースのデータベース マスター キーの自動暗号化解除を有効にする方法については、「暗号化されたミラー データベースの設定」を参照してください。For information about how to enable automatic decryption of the database master key of a mirror database, see Set Up an Encrypted Mirror Database.

詳細については、次のトピックも参照してください。For more information, see also:

User-defined Error MessagesUser-defined Error Messages

ユーザー定義エラー メッセージは、 sys.messages カタログ ビューに存在します。User-defined error messages reside in the sys.messages catalog view. このカタログ ビューは、 masterデータベースに格納されています。This catalog view is stored in master. データベース アプリケーションがユーザー定義エラー メッセージに依存していて、データベースを別のサーバー インスタンスで使用できる場合は、 sp_addmessage を使用してユーザー定義エラー メッセージを対象のサーバー インスタンスに追加できます。If a database application depends on user-defined error messages and the database is made available on another server instance, use sp_addmessage to add those user-defined messages on the destination server instance.

Event Notifications and Windows Management Instrumentation (WMI) Events (at Server Level)Event Notifications and Windows Management Instrumentation (WMI) Events (at Server Level)

サーバーレベルのイベント通知Server-Level Event Notifications

サーバーレベルのイベント通知は msdbに格納されます。Server-level event notifications are stored in msdb. したがって、データベース アプリケーションがサーバーレベルのイベント通知に依存している場合、そのイベント通知を対象のサーバー インスタンスで再作成する必要があります。Therefore, if a database application relies on a server-level event notification, that event notification must be re-created on the destination server instance. サーバー インスタンスでイベント通知を表示するには、 sys.server_event_notifications カタログ ビューを使用します。To view the event notifications on a server instance, use the sys.server_event_notifications catalog view. 詳しくは、「 Event Notifications」をご覧ください。For more information, see Event Notifications.

また、イベント通知は Service BrokerService Brokerを使用して配信されます。Additionally, event notifications are delivered by using Service BrokerService Broker. 着信メッセージのルートは、サービスを格納したデータベースには含まれていません。Routes for incoming messages are not included in the database that contains a service. 代わりに、明示的なルートが msdbに格納されます。Instead, explicit routes are stored in msdb. サービスが、サービス宛ての着信メッセージをルーティングするために msdb データベース内の明示的なルートを使用する場合、別のインスタンスにデータベースをアタッチするには、このルートを再作成する必要があります。If your service uses an explicit route in the msdb database to route incoming messages to the service, when you attach a database in a different instance, you must re-create this route.

Windows Management Instrumentation (WMI) イベントWindows Management Instrumentation (WMI) Events

WMI Provider for Server Events を使用すれば、Windows Management Instrumentation (WMI) を使用して SQL ServerSQL Serverのイベントを監視できます。The WMI Provider for Server Events lets you use the Windows Management Instrumentation (WMI) to monitor events in SQL ServerSQL Server. データベースが依存する WMI プロバイダーによって公開されているサーバーレベルのイベントに依存するすべてのアプリケーションは、対象のサーバー インスタンスのコンピューターで定義されている必要があります。Any application that relies on server-level events exposed through the WMI provider on which a database relies must be defined the computer of the destination server instance. WMI イベント プロバイダーは、 msdbで定義されている対象サービスでイベント通知を作成します。WMI Event provider creates event notifications with a target service that is defined in msdb.

注: 詳細については、「 WMI Provider for Server Events の概念」をご覧ください。NOTE: For more information, see WMI Provider for Server Events Concepts.

SQL Server Management Studio を使用して WMI 警告を作成するにはTo create a WMI alert using SQL Server Management Studio

ミラー化されたデータベースに対するイベント通知の動作のしくみHow Event Notifications Work for a Mirrored Database

ミラー化されたデータベースはフェールオーバーできるため、ミラー化されたデータベースに関するイベント通知の複数データベースにまたがる配信は、定義上はリモートで行われます。Cross-database delivery of event notifications that involves a mirrored database is remote, by definition, because the mirrored database can fail over. Service BrokerService Broker には、 ミラー化されたルートの形式で、ミラー化されたデータベース用の特別なサポートが用意されています。 provides special support for mirrored databases, in the form of mirrored routes. ミラー化されたルートには、プリンシパル サーバー インスタンス用とミラー サーバー インスタンス用の 2 つのアドレスがあります。A mirrored route has two addresses: one for the principal server instance and one for the mirror server instance.

ミラー化されたルートをセットアップすることにより、 Service BrokerService Broker のルーティングでデータベース ミラーリングが認識されるようにします。By setting up mirrored routes, you make Service BrokerService Broker routing aware of database mirroring. ミラー化されたルートを使用すると、 Service BrokerService Broker で現在のプリンシパル サーバー インスタンスに透過的にメッセージ交換をリダイレクトできます。The mirrored routes enable Service BrokerService Broker to transparently redirect conversations to the current principal server instance. たとえば、ミラー化されたデータベース Database_A によってホストされているサービス Service_A について考えてみます。For example, consider a service, Service_A, which is hosted by a mirrored database, Database_A. Database_B によってホストされているもう 1 つのサービス Service_B には Service_A との対話が必要であるとします。Assume that you need another service, Service_B, which is hosted by Database_B, to have a dialog with Service_A. この対話を可能にするには、Database_B に Service_A 用のミラー化されたルートを含める必要があります。For this dialog to be possible, Database_B must contain a mirrored route for Service_A. さらに、Database_A には Service_B へのミラー化されていない TCP 転送ルートを含める必要があります。このルートはローカル ルートとは異なり、フェールオーバー後も有効なままです。In addition, Database_A must contain a nonmirrored TCP transport route to Service_B, which, unlike a local route, remains valid after failover. これらのルートによって、フェールオーバー後に ACK が返されるようになります。These routes enable ACKs to come back after a failover. 送信側のサービスは常に同じ形式で名前指定されるので、ルートではブローカー インスタンスを指定する必要があります。Because the service of the sender is always named in the same manner, the route must specify the broker instance.

ミラー化されたルートには、ミラー化されたデータベースのサービスが発信側サービスか発信先サービスかにかかわらず、次の要件が適用されます。The requirement for mirrored routes applies for regardless of whether the service in the mirrored database is the initiator service or the target service:

  • 発信先サービスがミラー化されたデータベースにある場合、発信側サービスに、発信先に戻るためのミラー化されたルートがあること。If target service is in the mirrored database, the initiator service must have a mirrored route back to the target. ただし、発信先は通常のルートで発信側に戻れること。However, the target can have a regular route back to initiator.

  • 発信側サービスがミラー化されたデータベースにある場合、発信先に、受信確認や応答の配信のために発信側サービスに戻るミラー化されたルートがあること。If initiator service is in the mirrored database, the target service must have a mirrored route back to initiator to deliver acknowledgements and replies. ただし、発信側は通常のルートで発信先に戻れること。However, the initiator can have a regular route to the target.

Extended Stored ProceduresExtended Stored Procedures

重要:IMPORTANT! この機能はメンテナンス モードであり、Microsoft SQL Server の将来のバージョンで削除される可能性があります。This feature is in maintenance mode and may be removed in a future version of Microsoft SQL Server. 新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。Avoid using this feature in new development work, and plan to modify applications that currently use this feature. 代わりに CLR 統合 を使用してください。 Use CLR Integration instead.

拡張ストアド プロシージャは SQL ServerSQL Server 拡張ストアド プロシージャ API を使用してプログラミングされます。Extended stored procedures are programmed by using the SQL ServerSQL Server Extended Stored Procedure API. sysadmin 固定サーバー ロールのメンバーは、 SQL ServerSQL Server のインスタンスを使用して拡張ストアド プロシージャを登録し、ユーザーにその拡張ストアド プロシージャを実行する権限を与えることができます。A member of the sysadmin fixed server role can register an extended stored procedure with an instance of SQL ServerSQL Server and grant permission to users to execute the procedure. 拡張ストアド プロシージャは、 master データベースにのみ追加できます。Extended stored procedures can be added only to the master database.

拡張ストアド プロシージャは SQL ServerSQL Serverのインスタンスのアドレス空間で直接実行されるので、メモリ リークや、サーバーのパフォーマンスと信頼性を低下させるその他の問題が発生する原因になる場合があります。Extended stored procedures run directly in the address space of an instance of SQL ServerSQL Server, and they may produce memory leaks or other problems that reduce the performance and reliability of the server. 参照データを含んでいる SQL ServerSQL Server のインスタンスとは別のインスタンスに拡張ストアド プロシージャを格納することを検討してください。You should consider storing extended stored procedures in an instance of SQL ServerSQL Server that is separate from the instance that contains the referenced data. また、データベースへのアクセスには分散クエリを使用することも検討してください。You should also consider using distributed queries to access the database.

重要

システム管理者は、拡張ストアド プロシージャをサーバーに追加して他のユーザーに Execute 権限を許可する前に、各拡張ストアド プロシージャに有害なコードや悪意のあるコードが含まれていないことを十分に確認する必要があります。Before adding extended stored procedures to the server and granting EXECUTE permissions to other users, the system administrator should thoroughly review each extended stored procedure to make sure that it does not contain harmful or malicious code.

詳細については、「GRANT (オブジェクトの権限の許可) (Transact-SQL)」、「DENY (オブジェクトの権限の拒否) (Transact-SQL)」、および「REVOKE (オブジェクトの権限の取り消し) (Transact-SQL)」を参照してください。For more information, see GRANT Object Permissions (Transact-SQL), DENY Object Permissions (Transact-SQL), and REVOKE Object Permissions (Transact-SQL).

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

Full-Text Engine のプロパティは、 sp_fulltext_serviceによって設定されます。Properties are set on the Full-Text Engine by sp_fulltext_service. 対象のサーバー インスタンスで、これらのプロパティに必要な設定が行われていることを確認してください。Make sure that the destination server instance has the required settings for these properties. これらのプロパティの詳細については、「FULLTEXTSERVICEPROPERTY (Transact-SQL)」を参照してください。For more information about these properties, see FULLTEXTSERVICEPROPERTY (Transact-SQL).

さらに、ワード ブレーカーとステマーのコンポーネント、またはフルテキスト検索フィルター コンポーネントのバージョンが、元のサーバー インスタンスと対象のサーバー インスタンスで異なると、フルテキスト インデックスおよびクエリの動作が異なる場合があります。Additionally, if the word breakers and stemmers component or full-text search filters component have different versions on the original and destination server instances, full-text index and queries may behave differently. また、 類義語辞典 はインスタンス固有のファイルに格納されています。Also, the thesaurus is stored in instance-specific files. それらのファイルのコピーを対象のサーバー インスタンスの該当する場所にコピーするか、新しいインスタンス上でこれらのファイルを再作成する必要があります。You must either transfer a copy of those files to an equivalent location on the destination server instance or re-create them on new instance.

注: フルテキスト カタログ ファイルを含む SQL Server 2005SQL Server 2005 データベースを SQL Server 2017SQL Server 2017 サーバー インスタンスにアタッチする場合、カタログ ファイルは SQL Server 2005SQL Server 2005と同様に他のデータベース ファイルと一緒に以前の場所からアタッチされます。NOTE: When you attach a SQL Server 2005SQL Server 2005 database that contains full-text catalog files onto a SQL Server 2017SQL Server 2017 server instance, the catalog files are attached from their previous location along with the other database files, the same as in SQL Server 2005SQL Server 2005. 詳細については、「 SQL Server 2005 からのフルテキスト検索のアップグレード」を参照してください。For more information, see Upgrade Full-Text Search.

詳細については、次のトピックも参照してください。For more information, see also:

ジョブJobs

データベースが SQL ServerSQL Server エージェント ジョブに依存する場合、対象のサーバー インスタンス上でそれらの SQL Server エージェント ジョブを再作成する必要があります。If the database relies on SQL ServerSQL Server Agent jobs, you will have to re-create them on the destination server instance. ジョブは環境に依存します。Jobs depend on their environments. 対象のサーバー インスタンス上で既存のジョブを再作成する場合、元のサーバー インスタンス上のジョブの環境に一致するように対象のサーバー インスタンスを変更することが必要になる場合があります。If you plan to re-create an existing job on the destination server instance, the destination server instance might have to be modified to match the environment of that job on the original server instance. 次の環境的要因は重要です。The following environmental factors are significant:

  • ジョブによって使用されるログインThe login used by the job

    SQL ServerSQL Server エージェント ジョブを作成または実行するには、まず、ジョブに必要なすべての SQL ServerSQL Server ログインを対象のサーバー インスタンスに追加する必要があります。To create or execute SQL ServerSQL Server Agent jobs, you must first add any SQL ServerSQL Server logins required by the job to the destination server instance. 詳細については、「 SQL Server エージェント ジョブ ステップを作成および管理するユーザーの構成」を参照してください。For more information, see Configure a User to Create and Manage SQL Server Agent Jobs.

  • SQL ServerSQL Server エージェントのサービス開始アカウント Agent service startup account

    サービス開始アカウントにより、 MicrosoftMicrosoft エージェントを実行する SQL ServerSQL Server Windows アカウントとそのネットワーク権限が定義されます。The service startup account defines the MicrosoftMicrosoft Windows account in which SQL ServerSQL Server Agent runs and its network permissions. SQL ServerSQL Server エージェントは、指定されたユーザー アカウントで実行されます。 Agent runs as a specified user account. SQL Server エージェント サービスのコンテキストは、ジョブとその実行環境の設定に影響します。The context of the Agent service affects the settings for the job and its run environment. アカウントは、ジョブで必要とされるネットワーク共有などのリソースにアクセスできる必要があります。The account must have access to the resources, such as network shares, required by the job. サービス開始アカウントの選択方法と変更方法の詳細については、「 SQL Server エージェント サービスのアカウントの選択」を参照してください。For information about how to select and modify the service startup account, see Select an Account for the SQL Server Agent Service.

    正しく稼働するには、適切なドメイン、ファイル システム、およびレジストリの権限を持つようにサービス開始アカウントを構成する必要があります。To operate correctly, the service startup account must be configured to have the correct domain, file system, and registry permissions. また、サービス アカウント用に構成する必要がある共有ネットワーク リソースがジョブで必要になる場合があります。Also, a job might require a shared network resource that must be configured for the service account. 詳細については、「 Windows サービス アカウントと権限の構成」を参照してください。For information, see Configure Windows Service Accounts and Permissions.

  • SQL ServerSQL Server の特定のインスタンスに関連付けられている SQL ServerSQL Serverエージェント サービスには独自のレジストリ ハイブが設定されているので、SQL Server エージェント サービスのジョブは、通常、このレジストリ ハイブの 1 つ以上の設定に依存します。 Agent service, which is associated with a specific instance of SQL ServerSQL Server, has its own registry hive, and its jobs typically have dependencies on one or more of the settings in this registry hive. ジョブが適切に動作するには、それらのレジストリ設定が必要です。To behave as intended, a job requires those registry settings. スクリプトを使用して別の SQL ServerSQL Server エージェント サービスにジョブを再作成した場合、その SQL Server エージェント サービスのレジストリには、再作成されたジョブに適したレジストリ設定が行われない場合があります。If you use a script to re-create a job in another SQL ServerSQL Server Agent service, its registry might not have the correct settings for that job. 再作成したジョブを対象のサーバー インスタンスで適切に動作させるには、元の SQL ServerSQL Server エージェント サービスと対象の SQL Server エージェント サービスのレジストリ設定が同じである必要があります。For re-created jobs to behave correctly on a destination server instance, the original and destination SQL ServerSQL Server Agent services should have the same registry settings.

    注意事項

    現在のレジストリ設定が他のジョブで必要な場合、ジョブの再作成を処理するために対象の SQL ServerSQL Server エージェント サービスのレジストリ設定を変更すると、問題が発生する可能性があります。Changing registry settings on the destination SQL ServerSQL Server Agent service to handle a re-created job could be problematic if the current settings are required by other jobs. さらに、レジストリを誤って編集すると、システムに重大な障害が発生する場合があります。Furthermore, incorrectly editing the registry can severely damage your system. レジストリを変更する前に、コンピューター上の重要なすべてのデータをバックアップすることをお勧めします。Before you make changes to the registry, we recommend that you back up any valued data on the computer.

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

    SQL ServerSQL Server エージェント プロキシでは、指定されたジョブ ステップのセキュリティ コンテキストを定義します。A SQL ServerSQL Server Agent proxy defines the security context for a specified job step. ジョブを対象のサーバー インスタンス上で実行する場合、そのジョブに必要なすべてのプロキシをそのインスタンス上で手動で再作成する必要があります。For a job to run on the destination server instance, all the proxies it requires must be manually re-created on that instance. 詳細については、「 SQL Server エージェント プロキシの作成 」および「 プロキシを使用するマルチサーバー ジョブのトラブルシューティング」を参照してください。For more information, see Create a SQL Server Agent Proxy and Troubleshoot Multiserver Jobs That Use Proxies.

    詳細については、次のトピックも参照してください。For more information, see also:

  • ジョブの実装Implement Jobs

  • 役割の交代後のログインとジョブの管理 (SQL Server) (データベース ミラーリングの場合)Management of Logins and Jobs After Role Switching (SQL Server) (for database mirroring)

  • Windows サービス アカウントと権限の構成 ( SQL ServerSQL Server のインスタンスをインストールする場合)Configure Windows Service Accounts and Permissions (when you install an instance of SQL ServerSQL Server)

  • SQL Server エージェントの構成 ( SQL ServerSQL Serverのインスタンスをインストールする場合)Configure SQL Server Agent (when you install an instance of SQL ServerSQL Server)

  • SQL Server エージェントのセキュリティの実装Implement SQL Server Agent Security

    既存のジョブと各ジョブのプロパティを表示するにはTo view existing jobs and their properties

  • ジョブの利用状況の監視Monitor Job Activity

  • sp_help_job (Transact-SQL)sp_help_job (Transact-SQL)

  • ジョブ ステップ情報の表示View Job Step Information

  • dbo.sysjobs (Transact-SQL)dbo.sysjobs (Transact-SQL)

    ジョブを作成するにはTo create a job

  • ジョブの作成Create a Job

  • ジョブの作成Create a Job

ジョブを再作成するスクリプトを使用する場合の推奨事項Best Practices for Using a Script to Re-create a Job

まず、簡単なジョブのスクリプトを作成し、別の SQL ServerSQL Server エージェント サービスでジョブを再作成し、そのジョブを実行して適切に動作するかどうかを確認することをお勧めします。We recommend that you start by scripting a simple job, re-creating the job on the other SQL ServerSQL Server Agent service, and running the job to see whether it works as intended. これにより、互換性のない部分を確認し、それらの解決に取り組むことができます。This will let you identify incompatibilities and try to resolve them. スクリプト化したジョブが新しい環境で正常に動作しない場合、新しい環境で正常に動作する同等のジョブを作成することをお勧めします。If a scripted job does not work as intended in its new environment, we recommend that you create an equivalent job that works correctly in that environment.

ログインLogins

SQL ServerSQL Server のインスタンスにログインするには、有効な SQL ServerSQL Server ログインが必要です。Logging into an instance of SQL ServerSQL Server requires a valid SQL ServerSQL Server login. このログインは、プリンシパルが SQL ServerSQL Serverのインスタンスに接続できるかどうかを確認する認証プロセスで使用されます。This login is used in the authentication process that verifies whether the principal can connect to the instance of SQL ServerSQL Server. 対応する SQL ServerSQL Server ログインが未定義のデータベース ユーザー、またはサーバー インスタンスで適切に定義されていないデータベース ユーザーは、インスタンスにログインできません。A database user for which the corresponding SQL ServerSQL Server login is undefined or is incorrectly defined on a server instance cannot log in to the instance. このようなユーザーは、そのサーバー インスタンスのデータベースの 孤立ユーザー と呼ばれます。Such a user is said to be an orphaned user of the database on that server instance. データベースを SQL ServerSQL Serverの別のインスタンスに復元、アタッチ、またはコピーした後、データベース ユーザーが孤立する可能性があります。A database user can become orphaned if after a database is restored, attached, or copied to a different instance of SQL ServerSQL Server.

元のデータベースのコピーに含まれている一部またはすべてのオブジェクトに対するスクリプトは、SQL Server スクリプト生成ウィザードを使用して、 [スクリプト オプションの選択] ページで [スクリプト ログイン] オプションを [True] に設定することで作成できます。To generate a script for some or all the objects in the original copy of the database, you can use the Generate Scripts Wizard, and in the Choose Script Options dialog box, set the Script Logins option to True.

注: ミラー化されたデータベースのログインを設定する方法については、「データベース ミラーリングまたは AlwaysOn 可用性グループのログイン アカウントの設定 (SQL Server)」および「役割の交代後のログインとジョブの管理 (SQL Server)」をご覧ください。NOTE: For information about how to set up logins for a mirrored database, see Set Up Login Accounts for Database Mirroring or Always On Availability Groups (SQL Server) and Management of Logins and Jobs After Role Switching (SQL Server).

PermissionsPermissions

次の種類の権限は、データベースが別のサーバー インスタンスで使用できるようになったときに影響を受ける場合があります。The following types of permissions might be affected when a database is made available on another server instance.

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

  • サーバー インスタンスに対する GRANT 権限、REVOKE 権限、または DENY 権限 (サーバーレベルの権限)GRANT, REVOKE, or DENY permissions on server instance (server-level permissions)

システム オブジェクトに対する GRANT 権限、REVOKE 権限、または DENY 権限GRANT, REVOKE, and DENY Permissions on System Objects

ストアド プロシージャ、拡張ストアド プロシージャ、関数、ビューなどのシステム オブジェクトに対する権限は、 master データベースに格納されるので、対象のサーバー インスタンスで構成する必要があります。Permissions on system objects such as stored procedures, extended stored procedures, functions, and views, are stored in the master database and must be configured on the destination server instance.

元のデータベースのコピーに含まれている一部またはすべてのオブジェクトに対するスクリプトは、SQL Server スクリプト生成ウィザードを使用して、 [スクリプト オプションの選択] ページで [オブジェクトレベル権限のスクリプトを作成] オプションを [True] に設定することで作成できます。To generate a script for some or all the objects in the original copy of the database, you can use the Generate Scripts Wizard, and in the Choose Script Options dialog box, set the Script Object-Level Permissions option to True.

重要

ログインのスクリプトを作成する場合、パスワードはスクリプトに含まれません。If you script logins, the passwords are not scripted. SQL ServerSQL Server 認証を使用するログインがある場合、対象のサーバー インスタンスでスクリプトを変更する必要があります。If you have logins that use SQL ServerSQL Server Authentication, you have to modify the script on the destination.

システム オブジェクトは、 sys.system_objects カタログ ビューで確認できます。System objects are visible in the sys.system_objects catalog view. システム オブジェクトの権限は、master データベースの sys.database_permissions カタログ ビューで確認できます。The permissions on system objects are visible in the sys.database_permissions catalog view in the master database. これらのカタログ ビューに対するクエリの実行およびシステム オブジェクト権限の付与に関する詳細については、「GRANT (システム オブジェクトの権限の許可) (Transact-SQL)」を参照してください。For information about querying these catalog views and granting system-object permissions, see GRANT System Object Permissions (Transact-SQL). 詳細については、「REVOKE (サーバーの権限の取り消し) (Transact-SQL)」および「DENY (サーバーの権限の拒否) (Transact-SQL)」を参照してください。For more information, see REVOKE System Object Permissions (Transact-SQL) and DENY System Object Permissions (Transact-SQL).

サーバー インスタンスに対する GRANT 権限、REVOKE 権限、および DENY 権限GRANT, REVOKE, and DENY Permissions on a Server Instance

サーバー スコープの権限は master データベースに格納されるので、対象のサーバー インスタンスで構成する必要があります。Permissions at the server scope are stored in the master database and must be configured on the destination server instance. サーバー インスタンスのサーバー権限の詳細については sys.server_permissions カタログ ビュー、サーバー プリンシパルの詳細については sys.server_principals カタログ ビュー、サーバー ロールのメンバーシップの詳細については sys.server_role_members カタログ ビューに対してクエリを実行してください。For information about the server permissions of a server instance, query the sys.server_permissions catalog view, for information about server principals query the sys.server_principalss catalog view, and for information about membership of server roles query the sys.server_role_members catalog view.

詳細については、「GRANT (サーバーの権限の許可) (Transact-SQL)」、「REVOKE (サーバーの権限の取り消し) (Transact-SQL)」、および「DENY (サーバーの権限の拒否) (Transact-SQL)」を参照してください。For more information, see GRANT Server Permissions (Transact-SQL), REVOKE Server Permissions (Transact-SQL), and DENY Server Permissions (Transact-SQL).

証明書または非対称キーのサーバー レベルの権限Server-Level Permissions for a Certificate or Asymmetric Key

サーバー レベルの権限を証明書または非対称キーに直接与えることはできません。Server-level permissions cannot be granted directly to a certificate or asymmetric key. 代わりに、特定の証明書または非対称キー用に排他的に作成された、マップされたログインにサーバー レベルの権限を与えます。Instead, server-level permissions are granted to a mapped login that is created exclusively for a specific certificate or asymmetric key. したがって、サーバー レベルの権限が必要な証明書または非対称キーには、独自の 証明書にマップされたログイン または 非対称キーにマップされたログインが個別に必要です。Therefore, each certificate or asymmetric key that requires server-level permissions, requires its own certificate-mapped login or asymmetric key-mapped login. 証明書または非対称キーにサーバー レベルの権限を与えるには、それぞれのマップされるログインに権限を与えます。To grant server-level permissions for a certificate or asymmetric key, grant the permissions to its mapped login.

注: マップされたログインは、対応する証明書または非対称キーを使用して署名されたコードの承認にのみ使用されます。NOTE: A mapped login is used only for authorization of code signed with the corresponding certificate or asymmetric key. マップされたログインを認証に使用することはできません。Mapped logins cannot be used for authentication.

マップされたログインとその権限は、どちらも masterデータベースに存在します。The mapped login and its permissions both reside in master. 証明書または非対称キーが master以外のデータベースに存在する場合は、 master データベースで証明書または非対称キーを再作成して任意のログインにマップする必要があります。If a certificate or asymmetric key resides in a database other than master, you must re-create it in master and map it to a login. そのデータベースを別のサーバー インスタンスに移動、コピー、または復元する場合は、対象のサーバー インスタンスの master データベースに存在する証明書または非対称キーを再作成してログインにマップし、必要なサーバー レベルの権限をそのログインに与える必要があります。If you move, copy, or restore the database to another server instance, you must re-create its certificate or asymmetric key in the master database of the destination server instance, map to a login, and grant the required server-level permissions to the login.

証明書または非対称キーを作成するにはTo create a certificate or asymmetric key

TRUSTWORTHY プロパティTrustworthy Property

TRUSTWORTHY データベース プロパティを使用して、SQL Server インスタンスがデータベースとその内容を信頼するかどうかを示します。The TRUSTWORHTY database property is used to indicate whether this instance of SQL Server trusts the database and the contents within it. データベースがアタッチされているとき、既定で、かつ、安全上の理由から、このオプションは OFF に設定されます。このことは、元のサーバーでこのオプションが ON に設定されている場合も当てはまります。When a database is attached, by default and for security, this option is set to OFF, even if this option was set to ON on the original server. このプロパティの詳細については、「TRUSTWORTHY データベース プロパティ」を参照してください。このオプションをオンにする方法については、「ALTER DATABASE (Transact-SQL)」を参照してください。For more information about this property, see TRUSTWORTHY database property and for information on turning this option ON, see ALTER DATABASE (Transact-SQL).

Replication SettingsReplication Settings

レプリケートされたデータベースのバックアップを別のサーバーまたはデータベースに復元する場合は、レプリケーションの設定は保存できません。If you restore a backup of a replicated database to another server or database, replication settings cannot be preserved. この場合、バックアップの復元後にすべてのパブリケーションおよびサブスクリプションを再作成する必要があります。In this case, you must re-create all publications and subscriptions after backups are restored. この処理を簡単にするには、現在のレプリケーションの設定を行うスクリプトと、レプリケーションの有効化および無効化を行うスクリプトを作成します。To make this process easier, create scripts for your current replication settings and, also, for the enabling and disabling of replication. レプリケーションの設定の再作成を容易にするには、これらのスクリプトをコピーし、対象のサーバー インスタンスで動作するようにサーバー名の参照を変更します。To help re-create your replication settings, copy these scripts and change the server name references to work for the destination server instance.

詳細については、「レプリケートされたデータベースのバックアップと復元」、「データベース ミラーリングとレプリケーション (SQL Server)」、および「ログ配布とレプリケーション (SQL Server)」を参照してください。For more information, see Back Up and Restore Replicated Databases, Database Mirroring and Replication (SQL Server), and Log Shipping and Replication (SQL Server).

Service Broker アプリケーションService Broker Applications

Service BrokerService Broker アプリケーションに関連する多くの要素は、データベースに伴って使用できます。Many aspects of a Service BrokerService Broker application move with the database. ただし、アプリケーションの一部の要素は、新しい場所で再作成または再構成する必要があります。However, some aspects of the application must be re-created or reconfigured in the new location. 既定で、かつ、安全上の理由から、データベースが別のサーバーからアタッチされているとき、is_broker_enabledis_honoor_broker_priority_on のオプションが OFF に設定されます。By default and for security, when a database is attached from another server, the options for is_broker_enabled and is_honoor_broker_priority_on are set to OFF. これらのオプションを ON に設定する方法については「ALTER DATABASE (Transact-SQL)」を参照してください。For information about how to set these options ON, see ALTER DATABASE (Transact-SQL).

Startup ProceduresStartup Procedures

スタートアップ プロシージャは、自動的に実行するように設定され、 SQL ServerSQL Server を起動するたびに実行されるストアド プロシージャです。A startup procedure is a stored procedure that is marked for automatic execution and is executed every time SQL ServerSQL Server starts. データベースがスタートアップ プロシージャに依存している場合、それらのスタートアップ プロシージャを対象のサーバー インスタンスで定義し、スタートアップ時に自動的に実行されるように構成する必要があります。If the database depends on any startup procedures, they must be defined on the destination server instance and be configured to be automatically executed at startup.

Triggers (at Server Level)Triggers (at Server Level)

DDL トリガーにより、さまざまなデータ定義言語 (DDL) イベントに応答してストアド プロシージャが起動されます。DDL triggers fire stored procedures in response to a variety of Data Definition Language (DDL) events. これらのイベントは、主にキーワード CREATE、ALTER、および DROP で始まる Transact-SQLTransact-SQL ステートメントに対応します。These events primarily correspond to Transact-SQLTransact-SQL statements that start with the keywords CREATE, ALTER, and DROP. DDL と同様の操作を実行する特定のシステム ストアド プロシージャも DDL トリガーを起動できます。Certain system stored procedures that perform DDL-like operations can also fire DDL triggers.

この機能の詳細については、「 DDL Triggers」を参照してください。For more information about this feature, see DDL Triggers.

参照See Also

包含データベース Contained Databases
他のサーバーへのデータベースのコピー Copy Databases to Other Servers
データベースのデタッチとアタッチ (SQL Server) Database Detach and Attach (SQL Server)
ログ配布のセカンダリへのフェールオーバー (SQL Server) Fail Over to a Log Shipping Secondary (SQL Server)
データベース ミラーリング セッション中の役割の交代 (SQL Server) Role Switching During a Database Mirroring Session (SQL Server)
暗号化されたミラー データベースの設定 Set Up an Encrypted Mirror Database
SQL Server 構成マネージャー SQL Server Configuration Manager
孤立ユーザーのトラブルシューティング (SQL Server)Troubleshoot Orphaned Users (SQL Server)