# Amazon RDS for Microsoft SQL Server の一般的な DBA タスク
このセクションでは、Microsoft SQL Server Amazon RDS データベースエンジンを実行する DB インスタンスに関連したいくつかの一般的な DBA タスクの Amazon RDS 固有の実装について説明します。マネージド型サービスの操作性を実現するために、Amazon RDS では DB インスタンスへのシェルアクセスはできません。また、上位の権限を必要とする特定のシステムプロシージャやシステムテーブルへのアクセスが制限されます。
**注記**
SQL Server DB インスタンスを使用する場合、新しく作成したデータベースを変更するためのスクリプトを実行できますが、新しいデータベースのモデルとして使用される「モデル」データベースを変更することはできません。
**Topics**
+ [
# Amazon RDS で実行している Microsoft SQL Server DB インスタンスの tempdb データベースへのアクセス
](SQLServer.TempDB.md)
+ [
# Database Engine Tuning Advisor を使用して Amazon RDS for SQL Server DB インスタンスのデータベースワークロードを分析する
](Appendix.SQLServer.CommonDBATasks.Workload.md)
+ [
# `db_owner` の Amazon RDS for SQL Server データベースの `rdsa` アカウントへの変更
](Appendix.SQLServer.CommonDBATasks.ChangeDBowner.md)
+ [
# Amazon RDS for Microsoft SQL Server の照合と文字セットの管理
](Appendix.SQLServer.CommonDBATasks.Collation.md)
+ [
# Amazon RDS for SQL Server のデータベースユーザーの作成
](Appendix.SQLServer.CommonDBATasks.CreateUser.md)
+ [
# Amazon RDS for SQL Server データベースの復旧モデルの決定
](Appendix.SQLServer.CommonDBATasks.DatabaseRecovery.md)
+ [
# Amazon RDS for SQL Server の最終フェイルオーバー時間の決定
](Appendix.SQLServer.CommonDBATasks.LastFailover.md)
+ [
# ログシーケンス番号のギャップによるポイントインタイムリカバリ障害のトラブルシューティング
](Appendix.SQLServer.CommonDBATasks.PITR-LSN-Gaps.md)
+ [
# Amazon RDS for SQL Server のデータベース名の表示を拒否または許可する
](Appendix.SQLServer.CommonDBATasks.ManageView.md)
+ [
# Amazon RDS for SQL Server の一括ロード中の高速挿入の無効化
](Appendix.SQLServer.CommonDBATasks.DisableFastInserts.md)
+ [
# Amazon RDS for Microsoft SQL Server DB インスタンスのデータベースの削除
](Appendix.SQLServer.CommonDBATasks.DropMirrorDB.md)
+ [
# マルチ AZ 配置の Amazon RDS for Microsoft SQL Server データベースの名前の変更
](Appendix.SQLServer.CommonDBATasks.RenamingDB.md)
+ [
# Amazon RDS for SQL Server のマスターユーザーの db\$1owner ロールメンバーシップのリセット
](Appendix.SQLServer.CommonDBATasks.ResetPassword.md)
+ [
# Amazon RDS for SQL Server のライセンス終了した DB インスタンスの復元
](Appendix.SQLServer.CommonDBATasks.RestoreLTI.md)
+ [
# Amazon RDS for SQL Server データベースのオフラインからオンラインへの切り替え
](Appendix.SQLServer.CommonDBATasks.TransitionOnline.md)
+ [
# Amazon RDS for SQL Server の変更データキャプチャの使用
](Appendix.SQLServer.CommonDBATasks.CDC.md)
+ [
# Amazon RDS 用 SQL Server エージェントの使用
](Appendix.SQLServer.CommonDBATasks.Agent.md)
+ [
# Amazon RDS for Microsoft SQL Server ログの使用方法
](Appendix.SQLServer.CommonDBATasks.Logs.md)
+ [
# Amazon RDS for SQL Server のトレースファイルとダンプファイルの使用
](Appendix.SQLServer.CommonDBATasks.TraceFiles.md)
# Amazon RDS で実行している Microsoft SQL Server DB インスタンスの tempdb データベースへのアクセス
Amazon RDS で実行している Microsoft SQL Server DB インスタンスの `tempdb` データベースにアクセスできます。`tempdb` に対してコードを実行するには、Microsoft SQL Server Management Studio (SSMS) 経由で Transact-SQL を使用するか、他の標準の SQL クライアントアプリケーションを使用します。DB インスタンスへの接続の詳細については、「[SQL Server DB インスタンスへの接続](USER_ConnectToMicrosoftSQLServerInstance.md)」を参照してください。
DB インスタンスのマスターユーザーは、`CONTROL` への `tempdb` アクセスが付与されるため、`tempdb` データベースオプションを変更できます。マスターユーザーは、`tempdb` データベースの所有者ではありません。必要に応じて、マスターユーザーは他のユーザーに `CONTROL` アクセスを付与し、他のユーザーにも `tempdb` データベースオプションを変更することを許可できます。
**注記**
`tempdb` データベースに対して Database Console Command (DBCC) を実行することはできません。
# tempdb データベースオプションの変更
Amazon RDS DB インスタンスで `tempdb` データベースのデータベースオプションを変更できます。変更可能なオプションの詳細については、Microsoft ドキュメントの「[tempdb データベース](https://msdn.microsoft.com/en-us/library/ms190768%28v=sql.120%29.aspx)」を参照してください。
ファイルの最大サイズオプションなどのデータベースオプションは、DB インスタンスの再起動後も保持されます。データベースオプションを変更して、データをインポートする際のパフォーマンスを最適化したり、ストレージ不足を防止したりすることができます。
## データをインポートする際のパフォーマンスの最適化
大量のデータを DB インスタンス内にインポートする際のパフォーマンスを最適化するには、tempdb データベースの `SIZE` プロパティと `FILEGROWTH` プロパティに大きな数値を設定します。`tempdb` を最適化する方法の詳細については、Microsoft ドキュメントの「[tempdb のパフォーマンスの最適化](https://technet.microsoft.com/en-us/library/ms175527%28v=sql.120%29.aspx)」を参照してください。
以下の例では、ファイルサイズを 100 GB に、ファイルの拡張単位を 10 パーセントに設定しています。
```
1. alter database[tempdb] modify file (NAME = N'templog', SIZE=100GB, FILEGROWTH = 10%)
```
## ストレージの問題の防止
`tempdb` データベースによる使用可能なディスク容量の占有を防止するには、`MAXSIZE` プロパティを設定します。次の例では、プロパティを 2048 MB に設定しています。
```
1. alter database [tempdb] modify file (NAME = N'templog', MAXSIZE = 2048MB)
```
# tempdb データベースの圧縮
Amazon RDS DB インスタンスの `tempdb` データベースを圧縮するには、2 つの方法があります。`rds_shrink_tempdbfile` プロシージャを使用するか、`SIZE` プロパティを設定できます。
## rds\$1shrink\$1tempdbfile プロシージャの使用
Amazon RDS プロシージャ `msdb.dbo.rds_shrink_tempdbfile` を使用すると、`tempdb` データベースを圧縮できます。`rds_shrink_tempdbfile` が `CONTROL` にアクセスできる場合にのみ、`tempdb` を呼び出すことができます。`rds_shrink_tempdbfile` を呼び出すとき、DB インスタンスのダウンタイムはありません。
`rds_shrink_tempdbfile` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `@temp_filename` | SYSNAME | — | 必須 | 圧縮するファイルの論理名。 |
| `@target_size` | int | null | optional | ファイルの新しいサイズ (メガバイト単位)。 |
次の例では、`tempdb` データベース用にファイル名を取得します。
```
1. use tempdb;
2. GO
3.
4. select name, * from sys.sysfiles;
5. GO
```
以下の例では、`tempdb` という名前の `test_file` データベースファイルを圧縮し、新しいサイズとして `10` メガバイトをリクエストしています。
```
1. exec msdb.dbo.rds_shrink_tempdbfile @temp_filename = N'test_file', @target_size = 10;
```
## SIZE プロパティの設定
`tempdb` を設定して DB インスタンスを再起動することでも、`SIZE` データベースを圧縮できます。DB インスタンスの再起動の詳細については、「[ DB インスタンスの再起動](USER_RebootInstance.md)」を参照してください。
次の例では、`SIZE` プロパティを 1024 MB に設定しています。
```
1. alter database [tempdb] modify file (NAME = N'templog', SIZE = 1024MB)
```
# マルチ AZ 配置の TempDB 設定
データベースミラーリング (DBM) または Always On Availability Groups (AG) を使用して、RDS for SQL Server DB インスタンスがマルチ AZ 配置にある場合、`tempdb` データベースの使用については、以下の考慮事項に留意してください。
プライマリ DB インスタンスからセカンダリ DB インスタンスに `tempdb` データをレプリケートすることはできません。セカンダリ DB インスタンスにフェイルオーバーすると、そのセカンダリ DB インスタンスの `tempdb` は空になります。
プライマリ DB インスタンスからセカンダリ DB インスタンスに、ファイルのサイズ設定や自動拡張設定などの `tempdb` データベースオプションの設定を同期できます。`tempDB` 設定の同期は、すべての RDS for SQL Server バージョンでサポートされています。次のストアドプロシージャを使用して、`tempdb` 設定の自動同期を有効にできます。
```
EXECUTE msdb.dbo.rds_set_system_database_sync_objects @object_types = 'TempDbFile';
```
**重要**
`rds_set_system_database_sync_objects` ストアドプロシージャを使用する前に、セカンダリ DB インスタンスではなく、プライマリ DB インスタンスで希望の `tempdb` 設定を行ってください。セカンダリ DB インスタンスで設定を変更した場合、自動同期を有効にすると、希望の `tempdb` 設定が削除される可能性があります。
次の関数を使用して、`tempdb` 設定の自動同期が有効になっているかどうかを確認できます。
```
SELECT * from msdb.dbo.rds_fn_get_system_database_sync_objects();
```
`tempdb` 設定の自動同期が有効な場合、`object_class` フィールドに戻り値があります。無効なときには、値は返されません。
次の関数を使用して、オブジェクトが UTC 時間で最後に同期された時刻を調べることができます。
```
SELECT * from msdb.dbo.rds_fn_server_object_last_sync_time();
```
例えば、`tempdb` 設定を 01:00 に変更してから `rds_fn_server_object_last_sync_time` 関数を実行した場合、`last_sync_time` として返される値は 01:00 より後であり、自動同期が発生したことを示します。
SQL Server Agent ジョブレプリケーションも使用している場合は、 `@object_type` パラメータで指定することで、SQL Agent ジョブと `tempdb` 設定の両方のレプリケーションを有効にできます。
```
EXECUTE msdb.dbo.rds_set_system_database_sync_objects @object_types = 'SQLAgentJob,TempDbFile';
```
SQL Server Agent ジョブのレプリケーションの詳細については、「[SQL Server エージェントジョブレプリケーションをオンにする](Appendix.SQLServer.CommonDBATasks.Agent.md#SQLServerAgent.Replicate)」を参照してください。
`rds_set_system_database_sync_objects` ストアドプロシージャを使用して `tempdb` 設定変更が自動的に同期されるようにする代わりに、次のいずれかの手動方法を使用できます。
**注記**
`rds_set_system_database_sync_objects` ストアドプロシージャを使用して `tempdb` 設定の自動同期を有効にすることをお勧めます。自動同期を使用すると、`tempdb` 設定を変更するたびにこれらの手動タスクを実行する必要がなくなります。
+ まず DB インスタンスを変更してマルチ AZ を無効にします。次に tempdb を変更し、最後にマルチ AZ を再度有効にします。この方法に伴うダウンタイムはありません。
詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
+ まず元のプライマリインスタンスで `tempdb` を変更します。次に手動でフェイルオーバーし、最後に新しいプライマリインスタンスで `tempdb` を変更します。このメソッドではダウンタイムが生じます。
詳しくは、「[ DB インスタンスの再起動](USER_RebootInstance.md)」を参照してください。
# Database Engine Tuning Advisor を使用して Amazon RDS for SQL Server DB インスタンスのデータベースワークロードを分析する
Database Engine Tuning Advisor は、Microsoft によって提供されるクライアントアプリケーションで、データベースワークロードを分析し、実行するクエリのタイプに基づいて Microsoft SQL Server データベースの最適なインデックスセットを推奨します。SQL Server Management Studio と同様に、チューニングアドバイザーは SQL Server を実行している Amazon RDS DB インスタンスに接続するクライアントコンピュータから実行します。クライアントコンピュータは、独自のネットワーク内で、オンプレミスで実行するローカルコンピュータ、または Amazon RDS DB インスタンスと同じリージョンで実行している Amazon EC2 Windows インスタンスです。
このセクションでは、チューニングアドバイザーで分析するためにワークロードをキャプチャする方法を紹介します。Amazon RDS では SQL Server インスタンスへのホストアクセスが制限されるため、これがワークロードをキャプチャするための最適なプロセスです。詳細については、Microsoft のドキュメントの [Database Engine Tuning Advisor](https://docs.microsoft.com/en-us/sql/relational-databases/performance/database-engine-tuning-advisor) を参照してください。
チューニングアドバイザーを使用するには、いわゆるワークロードをアドバイザーに提供する必要があります。ワークロードは、調整するデータベースに対して実行する一連の Transact-SQL ステートメントです。データベースエンジンチューニングアドバイザーは、データベースを調整する際のワークロード入力として、トレースファイル、トレーステーブル、Transact-SQL スクリプト、または XML ファイルを使用します。Amazon RDS を使用するときは、クライアントコンピュータ上のファイル、またはクライアントコンピュータにアクセス可能な Amazon RDS for SQL Server DB のデータベーステーブルがワークロードになります。ファイルまたはテーブルには、調整するデータベースに対するクエリが再生に適した形式で格納されている必要があります。
チューニングアドバイザーをもっとも効果的に機能させるには、ワークロードをできる限り実際的なものにする必要があります。DB インスタンスに対してトレースを実行することで、ワークロードのファイルまたはテーブルを生成できます。トレースの実行中に、DB インスタンスの負荷をシミュレートするか、正常な負荷でアプリケーションを実行できます。
トレースには、クライアント側とサーバー側の 2 種類があります。クライアント側トレースはセットアップが比較的容易で、SQL Server Profiler でキャプチャされたトレースイベントをリアルタイムで監視することができます。サーバー側トレースは、セットアップが複雑で、複数の Transact-SQL スクリプトを作成する必要があります。さらに、トレースは Amazon RDS DB インスタンスのファイルに書き込まれるため、トレースによってストレージ領域が消費されます。この結果ストレージ領域が不足した場合、DB インスタンスは空き領域がない状態になり、使用不能になる可能性があるため、実行中のサーバー側トレースがどのくらいのストレージ領域を使用するかを追跡することが重要になります。
クライアント側トレースの場合、十分な量のトレースデータが SQL Server Profiler にキャプチャされると、ワークロードファイルを生成できます。そのためには、ローカルコンピュータのファイルにトレースを保存します。または、クライアントコンピュータから利用できる DB インスタンスのデータベーステーブルにトレースを保存します。クライアント側トレースを使用する主なデメリットは、大量の負荷がかかると、トレースですべてのクエリをキャプチャできない可能性があることです。この結果、データベースエンジンチューニングアドバイザーによって実行される分析の効果が低下します。大量の負荷の下でトレースを実行する必要があり、そのトレースセッション中にすべてのクエリを確実にキャプチャしたい場合は、サーバー側トレースを使用してください。
サーバー側トレースの場合、DB インスタンスのトレース ファイルを適切なワークロードファイルに入れるか、追跡完了後に DB インスタンスのテーブルにトレースを保存することができます。SQL Server Profiler を使用してトレースをローカルコンピュータのファイルに保存するか、チューニングアドバイザーで DB インスタンスのトレーステーブルから読み取ることができます。
# SQL Server DB インスタンスでクライアント側トレースを実行する
**SQL Server DB インスタンスでクライアント側トレースを実行するには**
1. SQL Server Profiler を起動します。これは SQL Server インスタンスのフォルダの Performance Tools フォルダにインストールされます。クライアント側トレースを開始するには、トレース定義テンプレートをロードするか定義する必要があります。
1. SQL Server Profiler の [ファイル] メニューで、[**新しいトレース**] を選択します。[**Connect to Server**] ダイアログボックスで、トレースを実行するデータベースの DB インスタンスエンドポイント、ポート、マスターユーザー名、およびパスワードを入力します。
1. [**Trace Properties**] ダイアログボックスで、トレース名を入力し、トレース定義テンプレートを選択します。デフォルトテンプレート TSQL\$1Replay は、アプリケーションに標準で装備されています。このテンプレートを編集して、トレースを定義できます。[**トレースのプロパティ**] ダイアログボックスの [**イベントの選択**] タブで、イベントとイベント情報を編集します。
トレース定義テンプレートの詳細と SQL Server Profiler を使用してクライアント側トレースを指定する方法については、Microsoft ドキュメントの [Database Engine Tuning Advisor](https://docs.microsoft.com/en-us/sql/relational-databases/performance/database-engine-tuning-advisor) を参照してください。
1. クライアント側トレースを開始し、DB インスタンスに対して実行される間、SQL クエリをリアルタイムで監視してください。
1. トレースが完了したら、[**ファイル**] メニューから [**トレースの停止**] を選択します。結果をファイルまたはトレーステーブルとして DB インスタンスに保存します。
# SQL Server DB インスタンスでサーバー側トレースを実行する
サーバー側トレースを作成するスクリプトの作成は複雑になる可能性があるため、このドキュメントでは割愛します。このセクションでは、例として使用できるサンプルスクリプトを紹介します。クライアント側トレースと同様に、データベースエンジンチューニングアドバイザーを使用して開くことのできるワークロードファイルまたはトレーステーブルを作成することが目的です。
次に紹介する簡略化したサンプルスクリプトでは、サーバー側トレースを開始し、詳細をキャプチャしてワークロードファイルを作成します。トレースは、最初に D:\$1RDSDBDATA\$1Log ディレクトリの RDSTrace.trc ファイルに保存され、100 MB ごとにロールオーバーされて、それ以降のトレースファイルには RDSTrace\$11.trc、RDSTrace\$12.trc のように名前が付けられます。
```
DECLARE @file_name NVARCHAR(245) = 'D:\RDSDBDATA\Log\RDSTrace';
DECLARE @max_file_size BIGINT = 100;
DECLARE @on BIT = 1
DECLARE @rc INT
DECLARE @traceid INT
EXEC @rc = sp_trace_create @traceid OUTPUT, 2, @file_name, @max_file_size
IF (@rc = 0) BEGIN
EXEC sp_trace_setevent @traceid, 10, 1, @on
EXEC sp_trace_setevent @traceid, 10, 2, @on
EXEC sp_trace_setevent @traceid, 10, 3, @on
. . .
EXEC sp_trace_setfilter @traceid, 10, 0, 7, N'SQL Profiler'
EXEC sp_trace_setstatus @traceid, 1
END
```
以下の例はトレースを停止するスクリプトです。前述のスクリプトで作成されるトレースは、明示的にトレースを停止するか、プロセスがディスク容量を使い果たすまで継続されます。
```
DECLARE @traceid INT
SELECT @traceid = traceid FROM ::fn_trace_getinfo(default)
WHERE property = 5 AND value = 1 AND traceid <> 1
IF @traceid IS NOT NULL BEGIN
EXEC sp_trace_setstatus @traceid, 0
EXEC sp_trace_setstatus @traceid, 2
END
```
サーバー側トレースの結果をデータベーステーブルに保存し、fn\$1trace\$1gettable 関数を使用することで、そのデータベーステーブルをチューニングアドバイザーのワークロードとして使用することができます。次のコマンドは、D:\$1rdsdbdata\$1Log ディレクトリにある RDSTrace.trc という名前の全ファイル (RDSTrace\$11.trc などのすべてのロールオーバーファイルを含む) の結果を、現在のデータベースの RDSTrace という名前のテーブルにロードします。
```
SELECT * INTO RDSTrace
FROM fn_trace_gettable('D:\rdsdbdata\Log\RDSTrace.trc', default);
```
特定のロールオーバーファイルをテーブル (例えば、RDSTrace\$11.trc ファイル) に保存するには、fn\$1trace\$1gettable の最後のパラメータとしてロールオーバーファイルの名前を指定し、デフォルトの代わりに 1 を代入します。
```
SELECT * INTO RDSTrace_1
FROM fn_trace_gettable('D:\rdsdbdata\Log\RDSTrace_1.trc', 1);
```
# トレースを使用してチューニングアドバイザーを実行する
ローカルファイルまたはデータベーステーブルとしてトレースを作成したら、DB インスタンスに対してチューニングアドバイザーを実行できます。Amazon RDS でチューニングアドバイザーを使用するときのプロセスは、スタンドアロンのリモート SQL Server インスタンスを使用するときと同じです。クライアントマシンのチューニングアドバイザー UI を使用するか、コマンドラインから dta.exe ユーティリティを使用することができます。いずれの場合も、DB インスタンスのエンドポイントを使用して Amazon RDS DB インスタンスに接続し、チューニングアドバイザーを使用するときに、マスターユーザー名とマスターユーザーパスワードを指定する必要があります。
次のコード例では、エンドポイント **dta.cnazcmklsdei.us-east-1.rds.amazonaws.com** を持つ Amazon RDS DB インスタンスに対して dta.exe コマンドラインユーティリティを使用する方法をデモンストレーションします。この例には、マスターユーザー名 **admin** とマスターユーザーのパスワード **test** が含まれています。チューニングするサンプルデータベースは、**C:\$1RDSTrace.trc** という名前が付いたマシンです。サンプルコマンドラインコードでは、**RDSTrace1** というトレースセッション名も指定し、ローカルマシンへの出力ファイルとして、SQL 出力スクリプトには **RDSTrace.sql**、結果ファイルには **RDSTrace.txt**、分析の XML ファイルには **RDSTrace.xml** という名前を指定します。また、RDSDTA データベースに **RDSTraceErrors** という名前のエラーテーブルが指定されます。
```
dta -S dta.cnazcmklsdei.us-east-1.rds.amazonaws.com -U admin -P test -D RDSDTA -if C:\RDSTrace.trc -s RDSTrace1 -of C:\ RDSTrace.sql -or C:\ RDSTrace.txt -ox C:\ RDSTrace.xml -e RDSDTA.dbo.RDSTraceErrors
```
次は同じコマンドラインコードの例ですが、入力ワークロードがリモート Amazon RDS インスタンスにある **RDSTrace** データベースの **RDSDTA** というテーブルである点が異なります。
```
dta -S dta.cnazcmklsdei.us-east-1.rds.amazonaws.com -U admin -P test -D RDSDTA -it RDSDTA.dbo.RDSTrace -s RDSTrace1 -of C:\ RDSTrace.sql -or C:\ RDSTrace.txt -ox C:\ RDSTrace.xml -e RDSDTA.dbo.RDSTraceErrors
```
dta ユーティリティのコマンドラインパラメータの一覧については、Microsoft のドキュメントの [dta Utility](https://docs.microsoft.com/en-us/sql/tools/dta/dta-utility) を参照してください。
# `db_owner` の Amazon RDS for SQL Server データベースの `rdsa` アカウントへの変更
RDS for SQL Server DB インスタンスでデータベースを作成または復元すると、Amazon RDS はデータベースの所有者を `rdsa` に設定します。マルチ AZ 配置で SQL Server データベースミラーリング (DBM) または Always On 可用性グループ (AG) を使用している場合、Amazon RDS はセカンダリ DB インスタンスのデータベースの所有者を `NT AUTHORITY\SYSTEM` に設定します。セカンダリ DB インスタンスがプライマリロールに昇格されるまで、セカンダリデータベースの所有者を変更することはできません。ほとんどの場合、クエリの実行時にデータベースの所有者を `NT AUTHORITY\SYSTEM` に設定しても問題はありませんが、実行に昇格アクセス許可を必要とする `sys.sp_updatestats` などのシステムストアドプロシージャの実行時にエラーが発生する可能性があります。
次のクエリを使用して、`NT AUTHORITY\SYSTEM` が所有するデータベースの所有者を特定できます。
```
SELECT name FROM sys.databases WHERE SUSER_SNAME(owner_sid) = 'NT AUTHORITY\SYSTEM';
```
Amazon RDS ストアドプロシージャ `rds_changedbowner_to_rdsa` を使用して、データベースの所有者を `rdsa` に変更できます。`rds_changedbowner_to_rdsa` では、`master, model, msdb, rdsadmin, rdsadmin_ReportServer, rdsadmin_ReportServerTempDB, SSISDB` の各データベースは使用できません。
データベースの所有者を `rdsa` に変更するには、`rds_changedbowner_to_rdsa` ストアドプロシージャを呼び出してデータベース名を指定します。
**Example 使用例:**
```
exec msdb.dbo.rds_changedbowner_to_rdsa 'TestDB1';
```
以下のパラメータは必須です。
+ `@db_name` — データベースの所有者を `rdsa` に変更する対象のデータベースの名前。
**重要**
`rds_changedbowner_to_rdsa` を使用して、データベースの所有権を `rdsa` 以外のログインに変更することはできません。例えば、データベースを作成したログインに所有権を変更することはできません。他のデータベースユーザーを使用してメンバーシップを付与できない場合に、マスターユーザーの `db_owner` ロールの失われたメンバーシップを復元するには、マスターユーザーのパスワードをリセットして、`db_owner` ロールのメンバーシップを取得します。詳細については、「[Amazon RDS for SQL Server のマスターユーザーの db\$1owner ロールメンバーシップのリセット](Appendix.SQLServer.CommonDBATasks.ResetPassword.md)」を参照してください。
# Amazon RDS for Microsoft SQL Server の照合と文字セットの管理
このトピックでは、Amazon RDS で Microsoft SQL Server の照合順序と文字セットを管理する方法について説明します。データベースの作成中に照合順序を設定し、後で変更する方法を説明し、言語とロケールの要件に基づいてテキストデータを適切に処理できるようにします。さらに、Amazon RDS の SQL Server 環境で互換性とパフォーマンスを維持するためのベストプラクティスについても説明します。
SQL Server は、複数のレベルで照合をサポートします。DB インスタンスを作成するときに、デフォルトのサーバー照合を設定します。照合は、データベース、テーブル、または列レベルでオーバーライドできます。
**Topics**
+ [
## Microsoft SQL Server のサーバーレベルの照合
](#Appendix.SQLServer.CommonDBATasks.Collation.Server)
+ [
## Microsoft SQL Server のデータベースレベルの照合
](#Appendix.SQLServer.CommonDBATasks.Collation.Database-Table-Column)
## Microsoft SQL Server のサーバーレベルの照合
Microsoft SQL Server DB インスタンスを作成するときに、使用するサーバーの照合順序を設定できます。別の照合を選択しない場合、サーバーレベルの照合はデフォルトでSQL\$1Latin1\$1General\$1CP1\$1CI\$1AS になります。サーバー照合は、デフォルトですべてのデータベースとデータベースオブジェクトに適用されます。
**注記**
DB スナップショットから復元する場合は、照合順序を変更できません。
Amazon RDS は現在、以下のサーバー照合をサポートしています。
| 照合 | 説明 |
| --- | --- |
| Arabic\$1CI\$1AS | アラビア語、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし |
| Chinese\$1PRC\$1BIN2 | Chinese-PRC、バイナリコードポイントのソート順序 |
| Chinese\$1PRC\$1CI\$1AS | 中国語 - 中華人民共和国、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし |
| Chinese\$1Taiwan\$1Stroke\$1CI\$1AS | 繁体字中国語 (台湾)、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし |
| Danish\$1Norwegian\$1CI\$1AS | デンマーク-ノルウェー語、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし |
| Danish\$1Norwegian\$1CI\$1AS\$1KS | デンマーク-ノルウェー語、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別あり、全角半角の区別なし |
| Danish\$1Norwegian\$1CI\$1AS\$1KS\$1WS | デンマーク-ノルウェー語、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別あり、全角半角の区別あり |
| Danish\$1Norwegian\$1CI\$1AS\$1WS | デンマーク-ノルウェー語、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別あり |
| Danish\$1Norwegian\$1CS\$1AI | デンマーク-ノルウェー語、大文字と小文字の区別あり、アクセント (濁音、破裂音) の区別なし、ひらがな片仮名の区別なし、全角半角の区別なし |
| Danish\$1Norwegian\$1CS\$1AI\$1KS | デンマーク-ノルウェー語、大文字と小文字の区別あり、アクセント (濁音、破裂音) の区別なし、ひらがな片仮名の区別あり、全角半角の区別なし |
| Finnish\$1Swedish\$1100\$1BIN | Finnish-Swedish-100、バイナリソート |
| Finnish\$1Swedish\$1100\$1BIN2 | Finnish-Swedish-100、バイナリコードポイント比較ソート |
| Finnish\$1Swedish\$1100\$1CI\$1AI | フィンランド-スウェーデン語-100、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別なし、ひらがな片仮名の区別なし、全角半角の区別なし |
| Finnish\$1Swedish\$1100\$1CI\$1AS | フィンランド-スウェーデン語-100、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし |
| Finnish\$1Swedish\$1CI\$1AS | フィンランド語、スウェーデン語、およびスウェーデン語 (フィンランド)、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし |
| French\$1CI\$1AS | フランス語、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし |
| Greek\$1CI\$1AS | ギリシャ語、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし |
| Greek\$1CS\$1AS | ギリシャ語、大文字と小文字の区別あり、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし |
| Hebrew\$1BIN | ヘブライ語、バイナリソート |
| Hebrew\$1CI\$1AS | ヘブライ語、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし |
| Japanese\$1BIN | 日本語、バイナリソート |
| Japanese\$1CI\$1AS | 日本語、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし |
| Japanese\$1CS\$1AS | 日本語、大文字と小文字の区別あり、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし |
| Japanese\$1XJIS\$1140\$1CI\$1AS | 日本語、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし、補足文字、バリエーションセレクタの区別なし |
| Japanese\$1XJIS\$1140\$1CI\$1AS\$1KS\$1VSS | 日本語、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし、補足文字、バリエーションセレクタの区別あり |
| Japanese\$1XJIS\$1140\$1CI\$1AS\$1VSS | 日本語、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし、補足文字、バリエーションセレクタの区別あり |
| Japanese\$1XJIS\$1140\$1CS\$1AS\$1KS\$1WS | 日本語、大文字と小文字の区別あり、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別あり、全角半角の区別あり、補足文字、バリエーションセレクタの区別なし |
| Korean\$1Wansung\$1CI\$1AS | 韓国語 (Wansung)、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし |
| Latin1\$1General\$1100\$1BIN | Latin1-General-100、バイナリソート |
| Latin1\$1General\$1100\$1BIN2 | Latin1-General-100、バイナリコードポイントソート |
| Latin1\$1General\$1100\$1BIN2\$1UTF8 | Latin1-General-100、バイナリコードポイントソート順序、UTF-8 エンコード |
| Latin1\$1General\$1100\$1CI\$1AS | Latin1-General-100、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし |
| Latin1\$1General\$1100\$1CI\$1AS\$1SC\$1UTF8 | Latin1-General-100、大文字と小文字を区別しない、アクセントを区別する、補助文字、UTF-8 エンコード |
| Latin1\$1General\$1BIN | Latin1-General、バイナリソート |
| Latin1\$1General\$1BIN2 | Latin1-General、バイナリ、コードポイントソート |
| Latin1\$1General\$1CI\$1AI | Latin1-General、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別なし、ひらがな片仮名の区別なし、全角半角の区別なし |
| Latin1\$1General\$1CI\$1AS | Latin1-General、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし |
| Latin1\$1General\$1CI\$1AS\$1KS | Latin1-General、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別あり、全角半角の区別なし |
| Latin1\$1General\$1CS\$1AS | Latin1-General、大文字と小文字の区別あり、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし |
| Modern\$1Spanish\$1CI\$1AS | 現代スペイン語、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし |
| Polish\$1CI\$1AS | ポーランド語、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし |
| SQL\$11xCompat\$1CP850\$1CI\$1AS | Latin1-General、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし (Unicode データの場合)、コードページ 850 の SQL Server ソート順 49 (非 Unicode データの場合) |
| SQL\$1Latin1\$1General\$1CP1\$1CI\$1AI | Latin1-General、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別なし、ひらがな片仮名の区別なし、全角半角の区別なし (Unicode データの場合)、コードページ 1252 の SQL Server ソート順 54 (非 Unicode データの場合) |
| **SQL\$1Latin1\$1General\$1CP1\$1CI\$1AS (デフォルト)** | Latin1-General、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし (Unicode データの場合)、コードページ 1252 の SQL Server ソート順 52 (非 Unicode データの場合) |
| SQL\$1Latin1\$1General\$1CP1\$1CS\$1AS | Latin1-General、大文字と小文字の区別あり、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし (Unicode データの場合)、コードページ 1252 の SQL Server ソート順 51 (非 Unicode データの場合) |
| SQL\$1Latin1\$1General\$1CP437\$1CI\$1AI | Latin1-General、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別なし、ひらがな片仮名の区別なし、全角半角の区別なし (Unicode データの場合)、コードページ 437 の SQL Server ソート順 34 (非 Unicode データの場合) |
| SQL\$1Latin1\$1General\$1CP850\$1BIN | Latin1-General、バイナリソート順 (Unicode データの場合)、コードページ 850 の SQL Server ソート順 40 (非 Unicode データの場合) |
| SQL\$1Latin1\$1General\$1CP850\$1BIN2 | Latin1-General、バイナリコードポイントソート (Unicode データの場合)、コードページ 850 の SQL Server ソート順 40 (非 Unicode データの場合) |
| SQL\$1Latin1\$1General\$1CP850\$1CI\$1AI | Latin1-General、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別なし、ひらがな片仮名の区別なし、全角半角の区別なし (Unicode データの場合)、コードページ 850 の SQL Server ソート順 44 (非 Unicode データの場合) |
| SQL\$1Latin1\$1General\$1CP850\$1CI\$1AS | Latin1-General、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし (Unicode データの場合)、コードページ 850 の SQL Server ソート順 42 (非 Unicode データの場合) |
| SQL\$1Latin1\$1General\$1Pref\$1CP850\$1CI\$1AS | Latin1-General-Pref、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし (Unicode データの場合)、コードページ 850 の SQL Server ソート順 183 (非 Unicode データの場合) |
| SQL\$1Latin1\$1General\$1CP1256\$1CI\$1AS | Latin1-General、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし (Unicode データの場合)、コードページ 1256 の SQL Server ソート順 146 (非 Unicode データの場合) |
| SQL\$1Latin1\$1General\$1CP1255\$1CS\$1AS | Latin1-General、大文字と小文字の区別あり、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし (Unicode データの場合)、コードページ 1255 の SQL Server ソート順 137 (非 Unicode データの場合) |
| Thai\$1CI\$1AS | タイ語、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし |
| Turkish\$1CI\$1AS | トルコ語、大文字と小文字の区別なし、アクセント (濁音、破裂音) の区別あり、ひらがな片仮名の区別なし、全角半角の区別なし |
AWS CLI を使用して、サポートされている照合順序のリストをプログラムで取得することもできます。
```
aws rds describe-db-engine-versions --engine sqlserver-ee --list-supported-character-sets --query 'DBEngineVersions[].SupportedCharacterSets[].CharacterSetName' | sort -u
```
照合を選択
+ Amazon RDS のコンソールを使用している場合、新しい DB インスタンスを作成するときには、**[Additional configuration]** (追加設定) を選択し、**[Collation]** (照合) フィールドに照合を入力します。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ AWS CLI を使用している場合は、`--character-set-name` コマンドで `create-db-instance` オプションを使います。詳細については、[create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) を参照してください。
+ Amazon RDS API を使用している場合は、`CharacterSetName` 操作で `CreateDBInstance` パラメータを使用します。詳細については、[CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) を参照してください。
## Microsoft SQL Server のデータベースレベルの照合
デフォルト照合順序は、新しいデータベースまたはデータベースオブジェクトを作成する際に、照合順序を上書きすることにより、データベース、テーブル、または列レベルで変更できます。例えば、デフォルトのサーバー照合が SQL\$1Latin1\$1General\$1CP1\$1CI\$1AS の場合は、Mohawk 照合に対応できるように、これを Mohawk\$1100\$1CI\$1AS に変更することができます。クエリの引数も、必要に応じて他の照合順序を使用するために型変換できます。
例えば、次のクエリは、AccountName 列のデフォルト照合順序を Japanese\$1CI\$1AS に変更します。
```
CREATE TABLE [dbo].[Account]
(
[AccountID] [nvarchar](10) NOT NULL,
[AccountName] [nvarchar](100) COLLATE Mohawk_100_CI_AS NOT NULL
) ON [PRIMARY];
```
Microsoft SQL Server DB エンジンは、組み込みの NCHAR、NVARCHAR、および NTEXT データ型で Unicode をサポートします。例えば、CJK サポートが必要な場合は、データベースとテーブルを作成するときに、文字列ストレージに対してこれらの Unicode データ型を使用して、デフォルトサーバー照合順序を上書きします。以下のリンクから、SQL Server に対する照合順序と Unicode のサポートに関連する Microsoft の情報を参照できます。
+ [照合順序の使用](http://msdn.microsoft.com/en-us/library/ms187582%28v=sql.105%29.aspx)
+ [照合順序とインターナショナル対応に関する用語](http://msdn.microsoft.com/en-us/library/ms143726%28v=sql.105%29)
+ [SQL Server 照合順序の使用](http://msdn.microsoft.com/en-us/library/ms144260%28v=sql.105%29.aspx)
+ [データベースとデータベースエンジンアプリケーションの国際化に関する注意点](http://msdn.microsoft.com/en-us/library/ms190245%28v=sql.105%29.aspx)
# Amazon RDS for SQL Server のデータベースユーザーの作成
Amazon RDS for Microsoft SQL Server DB インスタンスのデータベースユーザーを作成するには、次の例のように T-SQL スクリプトを実行します。SQL Server Management Suite (SSMS) などのアプリケーションを使用します。DB インスタンスの作成時に作成されたマスターユーザーとして DB インスタンスにログインします。
```
--Initially set context to master database
USE [master];
GO
--Create a server-level login named theirname with password theirpassword
CREATE LOGIN [theirname] WITH PASSWORD = 'theirpassword';
GO
--Set context to msdb database
USE [msdb];
GO
--Create a database user named theirname and link it to server-level login theirname
CREATE USER [theirname] FOR LOGIN [theirname];
GO
```
ロールにデータベースユーザーを追加する例については、[SQLAgentUser ロールへのユーザーの追加](SQLServerAgent.AddUser.md) を参照してください。
**注記**
ユーザーを追加する際に許可エラーが発生した場合は、DB インスタンスのマスターユーザーパスワードを変更することで許可を復元できます。詳細については、「[Amazon RDS for SQL Server のマスターユーザーの db\$1owner ロールメンバーシップのリセット](Appendix.SQLServer.CommonDBATasks.ResetPassword.md)」を参照してください。
アプリケーションでマスターユーザーのアクセス許可をクローンすることはベストプラクティスではありません。詳細については、「[Amazon RDS for SQL Server でマスターユーザーの権限をクローンする方法](https://aws.amazon.com/blogs/database/how-to-clone-master-user-permissions-in-amazon-rds-for-sql-server/)」を参照してください。
# Amazon RDS for SQL Server データベースの復旧モデルの決定
Amazon RDS では、復旧モデル、保持期間、およびデータベースステータスがリンクされています。
これらの設定のいずれかを変更する前に、変更の影響を理解しておくことが重要です。各設定が他の設定に影響を与える場合があります。次に例を示します。
+ バックアップ保持を有効にしている状態でデータベースの復旧モデルを SIMPLE または BULK\$1LOGGED に変更すると、Amazon RDS で復旧モデルは 5 分以内に FULL にリセットされます。これに伴って、RDS で DB インスタンスのスナップショットも作成されます。
+ バックアップ保持期間を `0` 日に設定すると、RDS で復旧モードは SIMPLE に設定されます。
+ バックアップ保持期間を `0` 日に設定した状態で、データベースの復旧モデルを SIMPLE から他のオプションに変更すると、RDS で復旧モデルは SIMPLE にリセットされます。
**重要**
マルチ AZ インスタンスの復旧モデルは、絶対に変更しないでください。ALTER DATABASE などを使用して変更できそうに思える場合でも、変更してはなりません。バックアップ保持期間 (FULL 復旧モデル) は、マルチ AZ に必須です。この復旧モデルを変更すると、RDS によって即座に FULL に戻されます。
この自動リセットにより、RDS でミラーが完全に再構築されます。この再構築中は、ミラーでフェイルオーバーの準備が整うまで、データベースの可用性が約 30～90 分間低下します。DB インスタンスも、シングル AZ からマルチ AZ に切り替える場合と同じように、パフォーマンスが低下します。パフォーマンスが低下する期間は、データベースのストレージサイズに応じて異なります。データベースのストレージサイズが大きいほど、低下する期間が長くなります。
SQL Server の復旧モデルの詳細については、Microsoft ドキュメントの[復旧モデル (SQL Server)](https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/recovery-models-sql-server) を参照してください。
# Amazon RDS for SQL Server の最終フェイルオーバー時間の決定
最後のフェイルオーバー時間を確認するには、次のストアドプロシージャを使用します。
```
execute msdb.dbo.rds_failover_time;
```
このプロシージャは、次の情報を返します。
****
| 出力パラメータ | 説明 |
| --- | --- |
| errorlog\$1available\$1from | ログディレクトリでエラーログが使用可能になる時間が表示されます。 |
| recent\$1failover\$1time | エラーログに最新のフェイルオーバー時間が含まれている場合は、その時間が表示されます。それ以外の場合は、`null` が表示されます。 |
**注記**
ストアドプロシージャは、最新のフェイルオーバー時間を取得するために、ログディレクトリ内のすべての使用可能な SQL Server エラーログを検索します。フェイルオーバーメッセージが SQL Server によって上書きされている場合、フェイルオーバー時間は取得されません。
**Example 最近のフェイルオーバーがない例**
この例は、エラーログに最近のフェイルオーバーが存在しない場合の出力を示しています。2020-04-29 23:59:00.01 以降、フェイルオーバーは発生していません。
| errorlog\$1available\$1from | recent\$1failover\$1time |
| --- | --- |
| 2020-04-29 23:59:00.0100000 | null |
**Example 最近のフェイルオーバーの**
この例は、エラーログにフェイルオーバーが存在する場合の出力を示しています。最新のフェイルオーバーは、2020-05-05 18:57:51.89 に発生しています。
| errorlog\$1available\$1from | recent\$1failover\$1time |
| --- | --- |
| 2020-04-29 23:59:00.0100000 | 2020-05-05 18:57:51.8900000 |
# ログシーケンス番号のギャップによるポイントインタイムリカバリ障害のトラブルシューティング
RDS for SQL Server でポイントインタイムリカバリ (PITR) を試みると、ログシーケンス番号 (LSN) のギャップが原因で障害が発生する可能性があります。これらのギャップにより、RDS はデータベースを要求された時間に復元できなくなり、RDS は復元インスタンスを `incompatible-restore` 状態にします。
この問題の一般的な原因は次のとおりです。
+ データベース復旧モデルへの手動変更。
+ トランザクションログのバックアップを完了するためのリソースが不足しているため、RDS によって自動復旧モデルが変更される。
データベース内の LSN ギャップを特定するには、次のクエリを実行します。
```
SELECT * FROM msdb.dbo.rds_fn_list_tlog_backup_metadata(database_name)
ORDER BY backup_file_time_utc desc;
```
LSN ギャップを検出したら、次を実行できます。
+ LSN ギャップの前に復元ポイントを選択します。
+ 次のインスタンスバックアップが完了した後、ある時点まで待機して復元します。
この問題を回避するには、RDS for SQL Server データベースの復旧モデルを手動で変更しないことをお勧めします。これは、インスタンスの耐久性を妨げてしまうためです。また、定期的なトランザクションログのバックアップを確保するために、ワークロードに十分なリソースを持つインスタンスタイプを選択することをお勧めします。
トランザクションログ管理の詳細については、「Microsoft SQL Server ドキュメント」の「[SQL Server トランザクションログのアーキテクチャと管理ガイド](https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-log-architecture-and-management-guide?view=sql-server-ver16)」を参照してください。
# Amazon RDS for SQL Server のデータベース名の表示を拒否または許可する
マスターユーザーは `DENY VIEW ANY DATABASE TO LOGIN` を設定して、ユーザーにデータベースを非表示にすることはできません。このアクセス許可を変更するには、代わりに次のストアドプロシージャを使用します。
+ *LOGIN* へのデータベースの表示アクセスを拒否する:
```
EXEC msdb.dbo.rds_manage_view_db_permission @permission=‘DENY’, @server_principal=‘LOGIN’
go
```
+ *LOGIN* へのデータベースの表示アクセスを許可する:
```
EXEC msdb.dbo.rds_manage_view_db_permission @permission='GRANT', @server_principal='LOGIN'
go
```
このストアドプロシージャを使用する場合は、次の点を考慮してください。
+ データベース名は、SSMS および内部 DMV (動的管理ビュー) には非表示になります。ただし、データベース名は監査、ログ、メタデータテーブルでは引き続き表示可能です。これらは保護されている `VIEW ANY DATABASE` サーバーアクセス許可です。詳細については、「[サーバーの権限の拒否](https://learn.microsoft.com/en-us/sql/t-sql/statements/deny-server-permissions-transact-sql?view=sql-server-ver16#permissions)」を参照してください。
+ 権限が `GRANT` (許可) に戻されると、*LOGIN* はすべてのデータベースを表示できます。
+ *LOGIN* を削除して再作成すると、LOGIN に関連する表示アクセス許可が `ALLOW` にリセットされます。
+ マルチ AZ インスタンスの場合は、プライマリホストの *LOGIN* にのみ `DENY` または `GRANT` アクセス許可を設定します。変更はセカンダリホストに自動的に伝播されます。
+ このアクセス許可は、ログインがデータベース名を表示できるかどうかのみを変更します。ただし、データベースとその内部のオブジェクトへのアクセスは個別に管理されます。
# Amazon RDS for SQL Server の一括ロード中の高速挿入の無効化
SQL Server 2016 以降では、高速挿入はデフォルトで有効になっています。高速挿入では、データベースが単純または一括ログ復旧モデルにあるときに発生する最小限のログを活用して、挿入パフォーマンスを最適化します。高速挿入では、それぞれの一括ロードバッチが新しいエクステントを取得し、使用可能な空き領域がある既存のエクステントの配分ルックアップをバイパスして、挿入パフォーマンスを最適化します。
ただし、高速挿入では、バッチサイズが小さい一括ロードにより、オブジェクトにより消費される未使用の領域が増加する可能性があります。バッチサイズを増やすことができない場合は、トレースフラグ 692 を有効にすると、未使用の予約領域を減らすことができますが、パフォーマンスは低下します。このトレースフラグを有効にすると、ヒープまたはクラスター化インデックスにデータを一括でロードする際の高速挿入が無効になります。
DB パラメータグループを使用して、起動パラメータとしてトレースフラグ 692 を有効にします。詳細については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
トレースフラグ 692 は、SQL Server 2016 以降での Amazon RDS でサポートされています。トレースフラグの詳細については、Microsoft ドキュメントの [DBCC TRACEON - Trace Flags](https://docs.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-traceon-trace-flags-transact-sql) を参照してください。
# Amazon RDS for Microsoft SQL Server DB インスタンスのデータベースの削除
単一 AZ または マルチ AZ 配置で Microsoft SQL Server を実行している Amazon RDS DB インスタンスのデータベースを削除できます。データベースを削除するには、次のコマンドを使用します。
```
--replace your-database-name with the name of the database you want to drop
EXECUTE msdb.dbo.rds_drop_database N'your-database-name'
```
**注記**
コマンドでストレートの単一の引用を使用します。スマート引用はエラーを発生させます。
この手順を使用してデータベースを削除すると、Amazon RDS は、このデータベースへのすべての既存の接続とデータベースのバックアップ履歴を削除します。
他のユーザーにバックアップと復元を許可するには、次の手順に従います。
```
USE master
GO
CREATE LOGIN user1 WITH PASSWORD=N'changeThis', DEFAULT_DATABASE=master, CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO
USE msdb
GO
CREATE USER user1 FOR LOGIN user1
GO
use msdb
GO
GRANT EXECUTE ON msdb.dbo.rds_backup_database TO user1
GO
GRANT EXECUTE ON msdb.dbo.rds_restore_database TO user1
GO
```
# マルチ AZ 配置の Amazon RDS for Microsoft SQL Server データベースの名前の変更
マルチ AZ を使用する Microsoft SQL Server データベースインスタンスの名前を変更するには、次の手順を使用します。
1. 最初に、DB インスタンスのマルチ AZ を無効にします。
1. `rdsadmin.dbo.rds_modify_db_name` を実行して、データベースの名前を変更します。
1. 次に、DB インスタンスのマルチ AZ ミラーリングまたは AlwaysOn 可用性グループをオンにして、元の状態に戻します。
詳細については、「[Microsoft SQL Server DB インスタンスへのマルチ AZ の追加](USER_SQLServerMultiAZ.md#USER_SQLServerMultiAZ.Adding)」を参照してください。
**注記**
インスタンスでマルチ AZ を使用していない場合は、`rdsadmin.dbo.rds_modify_db_name` の実行前または実行後に設定を変更する必要はありません。
リードレプリカソースインスタンスのデータベースの名前を変更することはできません。
**例: **次の例では、`rdsadmin.dbo.rds_modify_db_name` に保存された手順でデータベースの名前を **MOO** から **ZAR** に変更します。これはステートメント `DDL ALTER DATABASE [MOO] MODIFY NAME = [ZAR]` の実行に似ています。
```
EXEC rdsadmin.dbo.rds_modify_db_name N'MOO', N'ZAR'
GO
```
# Amazon RDS for SQL Server のマスターユーザーの db\$1owner ロールメンバーシップのリセット
RDS for SQL Server データベースの `db_owner` ロールメンバーシップからマスターユーザーをロックし、他のデータベースユーザーがメンバーシップを付与できない場合、DB インスタンスのマスターユーザーパスワードを変更することで、失われたメンバーシップを復元できます。
DB インスタンスのマスターユーザーパスワードを変更することで、RDS は誤って取り消された可能性のある DB インスタンス内のデータベースに `db_owner` メンバーシップを付与します。DB インスタンスのパスワードは、Amazon RDS コンソール、AWS CLI コマンドの [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)、または [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) API オペレーションを使用して変更できます。DB インスタンスの変更の詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
# Amazon RDS for SQL Server のライセンス終了した DB インスタンスの復元
Microsoft は、Microsoft ライセンスモビリティ情報を報告しない Amazon RDS の一部のお客様について、DB インスタンスを削除するよう要求しています。Amazon RDS では、これらの DB インスタンスのスナップショットを作成するので、そのスナップショットから、ライセンスを含んだモデルを使用する新しい DB インスタンスを復元できます。
Standard Edition のスナップショットから、Standard Edition または Enterprise Edition のいずれかに復元できます。
Enterprise Edition のスナップショットから、Standard Edition または Enterprise Edition のいずれかに復元できます。
**Amazon RDS がインスタンスの最終スナップショットを作成した後で、SQL Server のスナップショットから復元するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**Snapshots**] を選択します。
1. SQL Server DB インスタンスのスナップショットを選択します。Amazon RDS が、DB インスタンスの最終スナップショットを作成します。終了したインスタンスのスナップショットの名前は `instance_name-final-snapshot` の形式です。例えば、DB インスタンス名が **mytest.cdxgahslksma.us-east-1.rds.com** である場合、最終スナップショットは ** mytest-final-snapshot** という名前で、元の DB インスタンスと同じ AWS リージョン内に配置されます。
1. [**アクション**]、[**スナップショットの復元**] の順に選択します。
[**Restore DB Instance**] ウィンドウが表示されます。
1. [**ライセンスモデル**] で、[**ライセンス込み**] を選択します。
1. 使用する SQL Server DB エンジンを選択します。
1. [**DB インスタンス識別子**] に、復元された DB インスタンスの名前を入力します。
1. [**DB インスタンスの復元**] を選択します。
スナップショットから復元する方法の詳細については、「[DB インスタンスへの復元](USER_RestoreFromSnapshot.md)」を参照してください。
# Amazon RDS for SQL Server データベースのオフラインからオンラインへの切り替え
Amazon RDS DB インスタンスの Microsoft SQL Server データベースを `OFFLINE` から `ONLINE` に切り替えることができます。
****
| SQL Server メソッド | Amazon RDS方法 |
| --- | --- |
| ALTER DATABASE *db\$1name* SET ONLINE; | EXEC rdsadmin.dbo.rds\$1set\$1database\$1online *db\$1name* |
# Amazon RDS for SQL Server の変更データキャプチャの使用
Amazon RDS は、Microsoft SQL Server で実行されている DB インスタンスの変更データキャプチャをサポートします。CDC は、テーブル内のデータに行われる変更をキャプチャします。また、各変更に関するメタデータを保存します。これにより、後にアクセスできるようになります。CDC の動作の詳細については、Microsoft ドキュメントの「[変更データキャプチャ](https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/track-data-changes-sql-server#Capture)」を参照してください。Amazon RDS DB インスタンスで CDC を使用するには、`msdb.dbo.rds_cdc_enable_db` を実行して、データベース上で有効にします。CDC が有効になると、該当データベースの `db_owner` であるユーザーは誰でも、そのデータベースのテーブルの CDC を有効または無効にすることができます。
**重要**
復元中、CDC は無効になります。関連するメタデータはすべて、データベースより自動的に削除されます。これは、スナップショット復元とポイントインタイムリストアに適用されます。これらの復元のいずれかを実行すると、CDC を再度有効にして、追跡するテーブルを再度指定できます。
DB インスタンスの CDC を有効にするには、`msdb.dbo.rds_cdc_enable_db` ストアドプロシージャを実行します。
```
1. exec msdb.dbo.rds_cdc_enable_db 'database_name'
```
DB インスタンスの CDC を無効にするには、`msdb.dbo.rds_cdc_disable_db` ストアドプロシージャを実行します。
```
1. exec msdb.dbo.rds_cdc_disable_db 'database_name'
```
以下の手順を使用して、ユーザーに CDC アクセス許可を付与します。
```
1. go
2. GRANT EXECUTE ON msdb.dbo.rds_cdc_enable_db TO User1
3. GRANT EXECUTE ON msdb.dbo.rds_cdc_disable_db TO User1
```
**Topics**
+ [
## 変更データキャプチャを使用したテーブルの追跡
](#Appendix.SQLServer.CommonDBATasks.CDC.tables)
+ [
## 変更データキャプチャのジョブ
](#Appendix.SQLServer.CommonDBATasks.CDC.jobs)
+ [
## マルチ AZ インスタンスの変更データキャプチャ
](#Appendix.SQLServer.CommonDBATasks.CDC.Multi-AZ)
## 変更データキャプチャを使用したテーブルの追跡
CDC がデータベースで有効になったら、特定のテーブルの追跡を開始できます。追跡するテーブルを選択するには、[sys.sp\$1cdc\$1enable\$1table](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-enable-table-transact-sql) を実行します。
```
1. --Begin tracking a table
2. exec sys.sp_cdc_enable_table
3. @source_schema = N'source_schema'
4. , @source_name = N'source_name'
5. , @role_name = N'role_name'
6.
7. --The following parameters are optional:
8.
9. --, @capture_instance = 'capture_instance'
10. --, @supports_net_changes = supports_net_changes
11. --, @index_name = 'index_name'
12. --, @captured_column_list = 'captured_column_list'
13. --, @filegroup_name = 'filegroup_name'
14. --, @allow_partition_switch = 'allow_partition_switch'
15. ;
```
テーブルの CDC 設定を表示するには、[sys.sp\$1cdc\$1help\$1change\$1data\$1capture](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-help-change-data-capture-transact-sql) を実行します。
```
1. --View CDC configuration
2. exec sys.sp_cdc_help_change_data_capture
3.
4. --The following parameters are optional and must be used together.
5. -- 'schema_name', 'table_name'
6. ;
```
CDC テーブル、関数、ストアドプロシージャの詳細については、SQL Server のドキュメントの以下を参照してください。
+ [変更データキャプチャのストアドプロシージャ (Transact-SQL)](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/change-data-capture-stored-procedures-transact-sql)
+ [変更データキャプチャの関数 (Transact-SQL)](https://docs.microsoft.com/en-us/sql/relational-databases/system-functions/change-data-capture-functions-transact-sql)
+ [変更データキャプチャのテーブル (Transact-SQL)](https://docs.microsoft.com/en-us/sql/relational-databases/system-tables/change-data-capture-tables-transact-sql)
## 変更データキャプチャのジョブ
CDC が有効になったら、SQL Server により CDC ジョブが作成されます。データベースの所有者 (`db_owner`) は CDC ジョブを表示、作成、変更、および削除することができます。ただし、所有者は RDS システムアカウントです。そのため、これらのジョブをネイティブのビュー、プロシージャ、または SQL Server Management Studio で表示することはできません。
データベースの CDC の動作をコントロールするには、SQL Server のネイティブプロシージャ ([sp\$1cdc\$1enable\$1table](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-enable-table-transact-sql)、[sp\$1cdc\$1start\$1job](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-start-job-transact-sql) など) を使用します。CDC ジョブパラメータ (`maxtrans`、`maxscans` など) を変更するには、[sp\$1cdc\$1change\$1jobs](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-change-job-transact-sql) を使用できます。
CDC ジョブに関する詳細情報を取得するには、次の動的管理ビューに対してクエリを実行します。
+ sys.dm\$1cdc\$1errors
+ sys.dm\$1cdc\$1log\$1scan\$1sessions
+ sysjobs
+ sysjobhistory
## マルチ AZ インスタンスの変更データキャプチャ
マルチ AZ インスタンスで CDC を使用する場合は、ミラーの CDC ジョブ設定がプリンシパルのいずれかと一致していることを確認します。CDC ジョブは、`database_id` にマッピングされています。セカンダリのデータベース ID がプリンシパルと異なる場合、そのジョブは正しいデータベースと関連付けられません。フェイルオーバー後のエラーを防ぐために、RDS によってジョブは削除され、新しいプリンシパルに再作成されます。再作成されたジョブでは、フェイルオーバー前に記録されたパラメータがプリンシパルによって使用されます。
このプロセスはすぐに実行されますが、RDS によって変更される前に CDC ジョブを実行できる場合があります。プリンシパルとセカンダリレプリカの間で一貫したパラメータを維持するには、次の 3 つの方法があります。
+ CDC を有効にしたすべてのデータベースに対して、同じジョブパラメータを使用する。
+ CDC ジョブ設定を変更する前に、マルチ AZ インスタンスを単一 AZ に変換する。
+ プリンシパルでパラメータを変更する場合は、必ず手動で転送する。
フェイルオーバー後に CDC ジョブを再作成するために使用される CDC パラメータを表示し、定義するには、`rds_show_configuration` および `rds_set_configuration` を使用します。
次の例では、`cdc_capture_maxtrans` のために設定された値を返します。`RDS_DEFAULT` に設定されているパラメータの場合は、RDS によって自動的に値が設定されます。
```
-- Show configuration for each parameter on either primary and secondary replicas.
exec rdsadmin.dbo.rds_show_configuration 'cdc_capture_maxtrans';
```
セカンダリの構成を設定するには、`rdsadmin.dbo.rds_set_configuration` を実行します。この手順では、セカンダリサーバーのすべてのデータベース向けにパラメータ値を設定します。これらの設定は、フェイルオーバー後にのみ使用されます。次の例では、CDC キャプチャのジョブの `maxtrans` を *1000* に設定します。
```
--To set values on secondary. These are used after failover.
exec rdsadmin.dbo.rds_set_configuration 'cdc_capture_maxtrans', 1000;
```
プリンシパルの CDC ジョブパラメータを設定するには、代わりに [sys.sp\$1cdc\$1change\$1jobs](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sys-sp-cdc-change-job-transact-sql) を使用します。
# Amazon RDS 用 SQL Server エージェントの使用
Amazon RDS では、Microsoft SQL Server の Enterprise、Standard、または Web エディションを実行している DB インスタンスの SQL Server エージェントを使用できます。SQL Server エージェントは、ジョブと呼ばれるスケジュールされた管理タスクを実行する Microsoft Windows サービスです。SQL Server エージェントを使用して T-SQL ジョブを実行し、SQL Server DB インスタンスでインデックスの再構築、データ破損の確認、およびデータの集計を行うことができます。
SQL Server DB インスタンスを作成すると、マスターユーザーが `SQLAgentUserRole` ロールに登録されます。
SQL Server エージェントは、指定したイベントに対応し、またはオンデマンドで、スケジュールに従ってジョブを実行できます。詳細については、Microsoft ドキュメントの [SQL Server エージェント](http://msdn.microsoft.com/en-us/library/ms189237)を参照してください。
**注記**
DB インスタンスのメンテナンスおよびバックアップウィンドウ中に実行されるジョブをスケジュールすることは避けてください。AWS によって起動されたメンテナンスおよびバックアッププロセスによって、ジョブが中断されたり、ジョブがキャンセルされたりする可能性があります。
マルチ AZ 配置では、ジョブのレプリケーション機能がオンになっているとき、SQL Server エージェントジョブは、プライマリホストからセカンダリホストにレプリケートされます。詳細については、「[SQL Server エージェントジョブレプリケーションをオンにする](#SQLServerAgent.Replicate)」を参照してください。
マルチ AZ 配置は、SQL Server エージェントジョブの数が 10,000 に制限されています。制限の引き上げが必要な場合は、サポート に連絡して緩和をリクエストしてください。[AWS サポート センター](https://console.aws.amazon.com/support/home#/)のページを開き、必要に応じてサインインし、[**ケースの作成**] を選択します。**[Service Limit increase]** (サービス制限の緩和) を選択します。フォームに入力して送信します。
SQL Server Management Studio (SSMS) で個々の SQL Server エージェントジョブの履歴を表示するには、オブジェクトエクスプローラーを開き、ジョブを右クリックして、[**View History**] (履歴を表示) を選択します。
SQL Server エージェントは DB インスタンスのマネージドホストで実行されているため、一部のアクションはサポートされていません。
+ ActiveX、Windows コマンドシェル、または Windows PowerShell を使用した、レプリケーションジョブの実行やコマンドラインスクリプトの実行はサポートされません。
+ SQL Server エージェントを手動で起動、停止、または再起動することはできません。
+ SQL Server エージェントを使用した E メール通知は、DB インスタンスからは使用できません。
+ SQL Server エージェントのアラートとオペレータはサポートされていません。
+ SQL Server エージェントを使用したバックアップの作成はサポートされていません。Amazon RDS を使用して DB インスタンスをバックアップします。
+ RDS for SQL Server は、現在、SQL Server エージェントトークンの使用をサポートしていません。
## SQL Server エージェントジョブレプリケーションをオンにする
SQL Server エージェントジョブレプリケーションは、次のストアドプロシージャを使用して有効にできます。
```
EXECUTE msdb.dbo.rds_set_system_database_sync_objects @object_types = 'SQLAgentJob';
```
ストアドプロシージャは、Amazon RDS for SQL Server でサポートされているすべての SQL Server バージョンで実行できます。以下のカテゴリのジョブがレプリケートされます。
+ [未分類 (ローカル)]
+ [未分類 (マルチサーバー)]
+ [未分類]
+ データコレクター
+ データベースエンジンチューニングアドバイザー
+ データベースメンテナンス
+ フルテキスト
T-SQL ジョブステップを使用するジョブのみがレプリケートされます。SQL Server Integration Services (SSIS)、SQL Server Reporting Services (SSRS)、レプリケーション、PowerShell などのステップタイプのジョブはレプリケートされません。データベースメールとサーバーレベルのオブジェクトを使用するジョブはレプリケートされません。
**重要**
プライマリホストは、レプリケーションの信頼できるソースです。ジョブのレプリケーションをオンにする前に、SQL Server エージェントのジョブがプライマリであることを確認してください。これを行わない場合、新しいジョブがセカンダリホスト上にあるときにこの機能をオンにすると、SQL Server エージェントのジョブが削除される可能性があります。
次の関数を使用して、レプリケーションがオンになっているかどうかを確認できます。
```
SELECT * from msdb.dbo.rds_fn_get_system_database_sync_objects();
```
SQL Server エージェントジョブがレプリケートされている場合、T-SQL クエリは以下を返します。レプリケートしていない場合は、`object_class` に対して何も返しません。
![\[SQL Server エージェントジョブがレプリケート中\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/SQLAgentJob.png)
次の関数を使用して、オブジェクトが UTC 時間で最後に同期された時刻を調べることができます。
```
SELECT * from msdb.dbo.rds_fn_server_object_last_sync_time();
```
例えば、01:00 に SQL Server エージェントジョブを変更するとします。直近の同期時刻は 01:00 以降になると予想されます。これは、同期が行われたことを示します。
同期後、セカンダリノードで `date_created` と `date_modified` に返される値は一致することが期待されます。
![\[サーバーオブジェクトが前回同期された時刻は 01:21:23 でした\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/SQLAgentJob_last_sync_time.png)
`tempdb` レプリケーションも使用している場合は、`@object_type` パラメータで指定することで、SQL Agent ジョブと `tempdb` 設定の両方のレプリケーションを有効にできます。
```
EXECUTE msdb.dbo.rds_set_system_database_sync_objects @object_types = 'SQLAgentJob,TempDbFile';
```
`tempdb` レプリケーションの詳細については、「[マルチ AZ 配置の TempDB 設定](SQLServer.TempDB.MAZ.md)」を参照してください。
# SQL Server エージェントのロール
RDS for SQL Server は、ジョブを管理するためのさまざまなレベルのアクセス許可を持つ、以下の SQL Server エージェントのロールをサポートしています。
+ **SQLAgentUserRole**
アクセス許可
+ 独自のジョブ、スケジュール、オペレーターを作成および管理する
+ 独自のジョブとスケジュールのプロパティを表示する
+ 他のユーザーが作成したジョブは表示または管理できない
このロールは、独自のジョブを作成および管理する必要があるが、他のユーザーが作成したジョブへのアクセスを必要としないユーザーに適しています。
+ **SQLAgentReaderRole**
アクセス許可
+ SQLAgentUserRole のすべてのアクセス許可
+ すべてのジョブとスケジュール (他のユーザーが作成したものを含む) を一覧表示する
+ すべてのジョブのプロパティを表示する
+ ジョブ履歴を確認する
このロールは、すべてのジョブのステータスをモニタリングする必要があるが、ジョブを管理する必要がないユーザーに適しています。
+ **SQLAgentOperatorRole**
アクセス許可
+ SQLAgentUserRole と SQLAgentReaderRole のすべてのアクセス許可
+ ジョブを実行、停止、または開始する
+ ジョブ履歴を管理する
+ ジョブとスケジュールを有効/無効にする
+ オペレーターとプロキシを表示する
このロールは、最も包括的なアクセス許可を提供するものであり、すべてのジョブを完全に制御する必要があるユーザーに適しています。
SQL Server ログインにロールを割り当てるには、次のコマンドを使用します。
```
USE msdb;
EXEC sp_addrolemember 'SQLAgentOperatorRole', 'username';
```
## RDS for SQL Server での SQLAgentOperatorRole の管理
現在のジョブを表示するには、SQLAgentOperatorRole を SQL Server ログインに追加し、データベースから切断する前にそれを削除する必要があります。
SQL Server Management Studio で SQL Server エージェントツリーを視覚化するには、次の手順に従います。
**SQL Server Management Studio (SSMS) で SQL Server エージェントを表示する**
1. RDS マスター認証情報を使用して RDS SQL Server インスタンスにログインし、目的のユーザーに SQLAgentUserRole を付与します。
```
USE msdb
GO
IF NOT EXISTS(SELECT name FROM sys.database_principals WHERE name = 'UserName')
BEGIN
CREATE USER UserName FROM LOGIN UserName
END
GO
ALTER ROLE SQLAgentUserRole ADD MEMBER UserName
GO
GRANT ALTER ON ROLE::[SQLAgentOperatorRole] to UserName
GO
```
これらのコマンドは、`msdb` データベースにユーザーが存在しない場合に作成します。また、SQLAgentUserRole にユーザーを追加し、SQL Server エージェントツリーを SSMS で表示できるようにします。最後に、SQLAgentOperatorRole に対する変更アクセス許可をユーザーに付与します。これにより、ユーザーはロールに対して自身を追加または削除できます。
1. 上記のロールに自分自身を追加するには、ジョブを表示する必要があるユーザーを使用して RDS SQL Server インスタンスに接続し、次のスクリプトを実行します。
```
use msdb
go
ALTER ROLE SQLAgentOperatorRole ADD MEMBER UserName
GO
```
次に、**[ジョブ]** フォルダを右クリックし、**[更新]** を選択します。
1. このアクションを実行すると、**[ジョブ]** タブに **[\$1]** (プラス) ボタンが表示されます。クリックして SQL Server エージェントジョブのリストを展開します。
1.
**重要**
RDS SQL Server インスタンスから切断する前に、SQLAgentOperatorRole から自分自身を削除する必要があります。
SQLAgentOperatorRole からログインを削除するには、Management Studio を切断または終了する前に次のクエリを実行します。
```
USE msdb
GO
ALTER ROLE SQLAgentOperatorRole DROP MEMBER UserName
GO
```
詳細については、「[RDS SQL Server での SQLAgentOperatorRole の活用](https://aws.amazon.com/blogs/database/leveraging-sqlagentoperatorrole-in-rds-sql-server/)」を参照してください。
# SQLAgentUser ロールへのユーザーの追加
SQL Server エージェントにログインまたはユーザーを追加できるようにするには、マスターユーザーとしてログインし、次の操作を行ってください。
1. `CREATE LOGIN` コマンドを使用して、別のサーバーレベルログインを作成します。
1. `msdb` コマンドを使用して `CREATE USER` にユーザーを作成し、このユーザーを前の手順で作成したログインにリンクします。
1. `SQLAgentUserRole` システムストアドプロシージャを使用して、`sp_addrolemember` にユーザーを追加します。
例えば、マスターユーザー名が **admin** で、ユーザー名が **theirname**、パスワードが **theirpassword** のユーザーに SQL Server エージェントへのアクセスを許可するとします。その場合は、以下の手順を使用できます。
**SQLAgentUser ロールにユーザーを追加するには**
1. マスターユーザーとしてログインします。
1. 以下のコマンドを実行します。
```
--Initially set context to master database
USE [master];
GO
--Create a server-level login named theirname with password theirpassword
CREATE LOGIN [theirname] WITH PASSWORD = 'theirpassword';
GO
--Set context to msdb database
USE [msdb];
GO
--Create a database user named theirname and link it to server-level login theirname
CREATE USER [theirname] FOR LOGIN [theirname];
GO
--Added database user theirname in msdb to SQLAgentUserRole in msdb
EXEC sp_addrolemember [SQLAgentUserRole], [theirname];
```
# SQL Server エージェントジョブの削除
`sp_delete_job` ストアドプロシージャを使用して、Amazon RDS for Microsoft SQL Server の SQL Server エージェントジョブを削除します。
SSMS を使用して SQL Server エージェントジョブを削除することはできません。これを試みると、次のようなエラーメッセージが表示されます。
```
The EXECUTE permission was denied on the object 'xp_regread', database 'mssqlsystemresource', schema 'sys'.
```
マネージド型サービスとしての RDS では、Windows レジストリにアクセスする手順の実行が制限されています。SSMS を使用すると、RDS が承認されていないプロセス (`xp_regread`) の実行を試みます。
**注記**
RDS for SQL Server では、sysadmin ロールのメンバーのみが、別のログインが所有するジョブを更新または削除できます。詳細については、「[RDS SQL Server での SQLAgentOperatorRole の活用](https://aws.amazon.com/blogs/database/leveraging-sqlagentoperatorrole-in-rds-sql-server/)」を参照してください。
**SQL Server エージェントジョブを削除するには**
+ 次の T-SQL ステートメントを実行します。
```
EXEC msdb..sp_delete_job @job_name = 'job_name';
```
# Amazon RDS for Microsoft SQL Server ログの使用方法
Amazon RDS コンソールを使用して、SQL Server エージェントのログ、Microsoft SQL Server のエラーログ、SQL Server Reporting Services (SSRS) のログを表示、監視、ダウンロードすることができます。
## ログファイルの監視
Amazon RDS コンソールでログを表示すると、その時点で存在しているログの内容を表示できます。コンソールでログを監視すると、動的な状態でログが表示され、ほぼリアルタイムでログの更新を確認できます。
監視の対象としてアクティブになるのは最新のログのみです。例えば、以下に示すようなログがあるとします。
![\[エラーログが選択された Amazon RDS コンソールのログセクションの画像。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/logs_sqlserver.png)
最新のログである log/ERROR のみがアクティブに更新されています。他のログを表示することもできますが、静的であり、更新されません。
## ログファイルのアーカイブ
Amazon RDS コンソールには、過去 1 週間と当日のログが表示されます。ログをダウンロードしてアーカイブし、過去のリファレンスとして保持できます。ログをアーカイブする方法の 1 つとして、Amazon S3 バケットにログをロードする方法があります。Amazon S3 バケットをセットアップしてファイルをアップロードする方法については、*Amazon Simple Storage Service 入門ガイド*の「[Amazon S3 の基礎](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AmazonS3Basics.html)」を参照し、[**開始方法**] をクリックしてください。
## エラーログとエージェントログの表示
Microsoft SQL Server のエラーログおよびエージェントログを表示するには、以下のパラメータで Amazon RDS ストアドプロシージャ `rds_read_error_log` を使用します。
+ **`@index`** – 取得するログのバージョン。デフォルト値は 0 で、現在のエラーログを取得します。以前のログを取得するには 1、さらにもう一つ前のログを取得するには 2、という方法で指定します。
+ **`@type`** – 取得するログのタイプ。エラーログを取得するには、1 を指定します。エージェントログを取得するには、2 を指定します。
**Example**
以下の例では現在のエラーログをリクエストします。
```
EXEC rdsadmin.dbo.rds_read_error_log @index = 0, @type = 1;
```
SQL Server エラーの詳細については、Microsoft ドキュメントの [Database engine errors](https://docs.microsoft.com/en-us/sql/relational-databases/errors-events/database-engine-events-and-errors) を参照してください。
# Amazon RDS for SQL Server のトレースファイルとダンプファイルの使用
このセクションでは、Microsoft SQL Server を実行する Amazon RDS DB インスタンスのトレースファイルとダンプファイルの操作について説明します。
## トレース SQL クエリを生成する
```
1. declare @rc int
2. declare @TraceID int
3. declare @maxfilesize bigint
4.
5. set @maxfilesize = 5
6.
7. exec @rc = sp_trace_create @TraceID output, 0, N'D:\rdsdbdata\log\rdstest', @maxfilesize, NULL
```
## オープントレースを表示する
```
1. select * from ::fn_trace_getinfo(default)
```
## トレースの内容を表示する
```
1. select * from ::fn_trace_gettable('D:\rdsdbdata\log\rdstest.trc', default)
```
## トレースファイルおよびダンプファイルの保持期間を設定する
トレースファイルとダンプファイルが蓄積されて、ディスク領域を消費することがあります。デフォルトでは、Amazon RDS では、7 日を経過したトレースファイルとダンプファイルは消去されます。
現在のトレースファイルとダンプファイルの保持期間を表示するには、以下の例に示すように、`rds_show_configuration` の手順を使用します。
```
1. exec rdsadmin..rds_show_configuration;
```
トレースファイルの保持期間を変更するには、`rds_set_configuration` プロシージャを使用し、`tracefile retention` を分単位で設定します。以下の例では、トレースファイルの保持期間を 24 時間に設定しています。
```
1. exec rdsadmin..rds_set_configuration 'tracefile retention', 1440;
```
ダンプファイルの保持期間を変更するには、`rds_set_configuration` プロシージャを使用し、`dumpfile retention` を分単位で設定します。以下の例では、ダンプファイルの保持期間を 3 日に設定しています。
```
1. exec rdsadmin..rds_set_configuration 'dumpfile retention', 4320;
```
セキュリティ上の理由から、SQL Server DB インスタンスの特定のトレースファイルまたはダンプファイルを削除することはできません。未使用のトレースファイルまたはダンプファイルをすべて削除するには、ファイルの保持期間を 0 に設定します。