` です。RDS は、絶対パスと相対パスをサポートしています。サブフォルダを作成したい場合、ファイルパス内に含めます。 |
| `@overwrite_file` | INT | 0 | オプション | 既存のファイルを上書きしてください。 0 = 上書きしないでください 1 = 上書きしてください |
ファイル拡張子のないファイルと、ファイル拡張子が .bcp、.csv、.dat、.fmt、.info、.lst、.tbl、.txt、.xml のファイルをダウンロードできます。
**注記**
SQL Server Integration Services が有効になっている場合、ファイル拡張子が .ispac のファイルのダウンロードがサポートされます。SSIS の有効化の詳細については、「[SQL Server Integration Services](Appendix.SQLServer.Options.SSIS.md)」を参照してください。
SQL Server Analysis Services が有効になっている場合、ファイル拡張子が .abf、.asdatabase、.configsettings、.deploymentoptions、.deploymenttargets、.xmla のファイルのダウンロードがサポートされます。SSAS の有効化の詳細については、「[SQL Server Analysis Services](Appendix.SQLServer.Options.SSAS.md)」を参照してください。
以下の例は S3 からファイルをダウンロードするためのストアドプロシージャを表します。
```
exec msdb.dbo.rds_download_from_s3
@s3_arn_of_file='arn:aws:s3:::amzn-s3-demo-bucket/bulk_data.csv',
@rds_file_path='D:\S3\seed_data\data.csv',
@overwrite_file=1;
```
例 `rds_download_from_s3` の操作は、フォルダがまだない場合、`seed_data` に `D:\S3\` という名前のフォルダを作成します。次に例ではソースファイル `bulk_data.csv` を S3 から DB インスタンスの `data.csv` という名前の新しいファイルにダウンロードします。`@overwrite_file` パラメータが `1` に設定されているため、すでにファイルが存在する場合は上書きされます。
## SQL Server DB インスタンスから Amazon S3 バケットにファイルをアップロードする
RDS for SQL Server DB インスタンスから S3 バケットにファイルをアップロードするには、Amazon RDS ストアドプロシージャ `msdb.dbo.rds_upload_to_s3` を以下のパラメータで使用してください。
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `@s3_arn_of_file` | NVARCHAR | – | 必須 | ファイルの S3 ARN が S3 内で作成されます (例: `arn:aws:s3:::amzn-s3-demo-bucket/mydata.csv`)。 |
| `@rds_file_path` | NVARCHAR | – | 必須 | S3 にアップロードするファイルのファイルパス。絶対パスと相対パスの両方をサポートしています。 |
| `@overwrite_file` | INT | – | オプション | 既存のファイルを上書きしてください。 0 = 上書きしないでください 1 = 上書きしてください |
以下の例では、`data.csv` という名前のファイルを `D:\S3\seed_data\` 内の指定の場所から、ARN が指定する S3 バケットに、ファイル `new_data.csv` をアップロードします。
```
exec msdb.dbo.rds_upload_to_s3
@rds_file_path='D:\S3\seed_data\data.csv',
@s3_arn_of_file='arn:aws:s3:::amzn-s3-demo-bucket/new_data.csv',
@overwrite_file=1;
```
@overwrite\$1file パラメータが `1` に設定されているため、ファイルが S3 にすでに存在している場合は上書きされます。
# RDS DB インスタンスでのファイル一覧表示
DB インスタンスで使用可能なファイルをリスト表示するには、ストアドプロシージャと機能の両方を使用します。最初に、以下のストアドプロシージャを実行して `D:\S3\` 内のファイルから詳細を集めます。
```
exec msdb.dbo.rds_gather_file_details;
```
ストアドプロシージャは、タスクの ID を返します。保管のタスクと同様、ストアドプロシージャも同期せずに実行されます。タスクのステータスが `SUCCESS` になるとすぐに、`rds_fn_list_file_details` 機能のタスク ID を使用して、 D:\$1S3\$1 内の既存のファイルやディレクトリのリスト表示ができます。以下を参照してください。
```
SELECT * FROM msdb.dbo.rds_fn_list_file_details(TASK_ID);
```
`rds_fn_list_file_details` 機能は、次の列があるテーブルを返します。
| 出力パラメータ | 説明 |
| --- | --- |
| filepath | ファイルの絶対パス (例: D:\$1S3\$1mydata.csv) |
| size\$1in\$1bytes | ファイルサイズ (バイト単位) |
| last\$1modified\$1utc | UTC 形式での最終変更を行った日時 |
| is\$1directory | アイテムがディレクトリ (true/false) かどうかを表示するオプション |
# RDS DB インスタンスでのファイル削除
DB インスタンスで使用可能なファイルを削除するには、Amazon RDS ストアドプロシージャ `msdb.dbo.rds_delete_from_filesystem` を以下のパラメータで使用します。
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `@rds_file_path` | NVARCHAR | – | 必須 | 削除するファイルのファイルパス。絶対パスと相対パスの両方をサポートしています。 |
| `@force_delete` | INT | 0 | オプション | ディレクトリを削除するには、このフラグが `1` に含まれ設定されている必要があります。 `1` = ディレクトリを削除する ファイルを削除する場合、このパラメータは無視されます。 |
ディレクトリを削除するには、`@rds_file_path` がバックスラッシュ (`\`) で終了し、`@force_delete` が `1` に設定される必要があります。
次の例では、ファイル `D:\S3\delete_me.txt` が削除されます。
```
exec msdb.dbo.rds_delete_from_filesystem
@rds_file_path='D:\S3\delete_me.txt';
```
次の例では、ディレクトリ `D:\S3\example_folder\` が削除されます。
```
exec msdb.dbo.rds_delete_from_filesystem
@rds_file_path='D:\S3\example_folder\',
@force_delete=1;
```
# ファイル転送タスクのステータスをモニタリングする
S3 統合タスクのステータスを追跡するには、`rds_fn_task_status` 機能を呼び出してください。2 つのパラメータを使用します。1 つめのパラメータは常に `NULL` を選択してください。これは、S3 統合に適用されないためです。2 つめのパラメータは、タスク ID を受け入れます。
全タスクのリストを見るには、以下の例にあるように、初期のパラメータを `NULL` に設定し、2 つめのパラメータを `0` に設定します。
```
SELECT * FROM msdb.dbo.rds_fn_task_status(NULL,0);
```
特定のタスクを受け取るには、以下の例にあるように、初期のパラメータを `NULL` に設定し、2 つめのパラメータをタスク ID に設定します。
```
SELECT * FROM msdb.dbo.rds_fn_task_status(NULL,42);
```
`rds_fn_task_status` 機能は次の情報を返します。
| 出力パラメータ | 説明 |
| --- | --- |
| `task_id` | タスクの ID。 |
| `task_type` | S3 統合では、タスクには以下のタスクタイプがあります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.SQLServer.Options.S3-integration.using.monitortasks.html) |
| `database_name` | S3 統合タスクには適用できません。 |
| `% complete` | タスクの進行状況の割合。 |
| `duration(mins)` | タスクにかかった時間 (分単位)。 |
| `lifecycle` | タスクのステータス。有効な状態には以下のものがあります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.SQLServer.Options.S3-integration.using.monitortasks.html) |
| `task_info` | タスクに関する追加情報。処理中にエラーが発生した場合、この列にエラーに関する情報が含まれます。 |
| `last_updated` | タスクのステータスが最後に更新された日時。 |
| `created_at` | タスクが作成された日時。 |
| `S3_object_arn` | S3 オブジェクトの ARN はダウンロードまたはアップロードされます。 |
| `overwrite_S3_backup_file` | S3 統合タスクには適用できません。 |
| `KMS_master_key_arn` | S3 統合タスクには適用できません。 |
| `filepath` | RDS DB インスタンスのファイルパス。 |
| `overwrite_file` | 既存のファイルが上書きされるかどうかを表示するオプション |
| `task_metadata` | S3 統合タスクには適用できません。 |
# タスクのキャンセル
S3 統合タスクをキャンセルするには、`msdb.dbo.rds_cancel_task` パラメータで `task_id` ストアドプロシージャを使用します。進行中の削除およびリスト作成タスクは、キャンセルできません。以下の例は、タスクをキャンセルするリクエストを示します。
```
exec msdb.dbo.rds_cancel_task @task_id = 1234;
```
すべてのタスクとそのタスク ID の概要を表示するには、 `rds_fn_task_status` に記載のように [ファイル転送タスクのステータスをモニタリングする](Appendix.SQLServer.Options.S3-integration.using.monitortasks.md) 機能を使用してください。
## S3 統合のマルチ AZ の制限
マルチ AZ インスタンスでは、`D:\S3` フォルダ内のファイルはフェイルオーバー後にスタンバイレプリカから削除されます。フェイルオーバーは、例えば、インスタンスクラスの変更やエンジンバージョンのアップグレードなど、DB インスタンスの変更中に計画できます。または、プライマリの停止中にフェイルオーバーが予定外になることがあります。
**注記**
`D:\S3` フォルダをファイルストレージに使用することはお勧めしません。ベストプラクティスは、作成したファイルを Amazon S3 にアップロードして耐久性を保持し、データをインポートする必要があるときにファイルをダウンロードすることです。
最後のフェイルオーバー時間を決定するには、`msdb.dbo.rds_failover_time` ストアドプロシージャを使用できます。詳細については、「[Amazon RDS for SQL Server の最終フェイルオーバー時間の決定](Appendix.SQLServer.CommonDBATasks.LastFailover.md)」を参照してください。
**Example 最近のフェイルオーバーがない例**
この例は、エラーログに最近のフェイルオーバーが存在しない場合の出力を示しています。2020-04-29 23:59:00.01 以降、フェイルオーバーは発生していません。
したがって、`rds_delete_from_filesystem` ストアドプロシージャを使用して削除されていない、その時間の後にダウンロードされたすべてのファイルは、現在のホストで引き続きアクセスできます。それ以前にダウンロードされたファイルも利用可能になる場合があります。
| errorlog\$1available\$1from | recent\$1failover\$1time |
| --- | --- |
| 2020-04-29 23:59:00.0100000 | null |
**Example 最近のフェイルオーバーの**
この例は、エラーログにフェイルオーバーが存在する場合の出力を示しています。最新のフェイルオーバーは、2020-05-05 18:57:51.89 に発生しています。
`rds_delete_from_filesystem` ストアドプロシージャを使用して削除されていない、その時間以降にダウンロードされたすべてのファイルは、現在のホストで引き続きアクセスできます。
| errorlog\$1available\$1from | recent\$1failover\$1time |
| --- | --- |
| 2020-04-29 23:59:00.0100000 | 2020-05-05 18:57:51.8900000 |
# RDS for SQL Server と S3 の統合を無効にする
ここでは、Amazon RDS for SQL Server と Amazon S3 の統合を無効にする方法について説明します。S3 統合を無効化するときは、`D:\S3\` のファイルは削除されません。
**注記**
IAM ロールを DB インスタンスから削除するには、DB インスタンスのステータスが `available` である必要があります。
## コンソール
**IAM ロールと DB インスタンスの関連を外す**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. RDS for SQL Server DB インスタンスの名前を選択して詳細を表示します。
1. [**接続とセキュリティ**] タブの [**IAM ロールの管理**] セクションで、削除する IAM ロールを選択します。
1. [**削除**] を選択します。
## AWS CLI
**IAM ロールを RDS for SQL Server DB インスタンスから削除するには**
+ 以下の AWS CLI コマンドが、IAM ロールを `mydbinstance` と名前の付いたRDS for SQL Server DB インスタンスから削除します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds remove-role-from-db-instance \
--db-instance-identifier mydbinstance \
--feature-name S3_INTEGRATION \
--role-arn your-role-arn
```
Windows の場合:
```
aws rds remove-role-from-db-instance ^
--db-instance-identifier mydbinstance ^
--feature-name S3_INTEGRATION ^
--role-arn your-role-arn
```
`your-role-arn` を、`--feature-name` オプションにとって適した IAM ロール ARN に交換します。
# Amazon RDS for SQL Server でのデータベースメールの使用
データベースメールを使用して、SQL Server データベースインスタンスの Amazon RDS からユーザーに E メールメッセージを送信できます。メッセージには、ファイルとクエリ結果を含めることができます。データベースメールは、次のコンポーネントを含みます。
+ **設定オブジェクトおよびセキュリティオブジェクト** – これらのオブジェクトは 、プロファイルとアカウントを作成し、`msdb` データベースに保存されます。
+ **メッセージングオブジェクト** – これらのオブジェクトは、メッセージの送信に使用する [sp\$1send\$1dbmail](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-send-dbmail-transact-sql) ストアドプロシージャと、メッセージに関する情報を保持するデータ構造を含みます。それらは `msdb` データベースに保存されます。
+ **ログオブジェクトと監査オブジェクト** – データベースメールは、`msdb` データベースと Microsoft Windows アプリケーションイベントログにログ情報を書き込みます。
+ **データベースメール 実行可能ファイル** – `DatabaseMail.exe` は、`msdb` データベースのキューから読み取り、E メールメッセージを送信します。
RDS は、Web Edition、Standard Edition、および Enterprise Edition の SQL Server のすべてのバージョンで、データベースメールをサポートします。
## 制約事項
SQL Server DB インスタンスでのデータベースメールの使用には、次の制約事項が適用されます。
+ データベースメールは、SQL Server Express Edition ではサポートされていません。
+ データベースメールの設定パラメータの変更はサポートされていません。プリセット (デフォルト) の値を表示するには、[sysmail\$1help\$1configure\$1sp](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-help-configure-sp-transact-sql) ストアドプロシージャを使用します。
+ 添付ファイルは、完全にはサポートされていません。詳細については、「[添付ファイルの使用](#SQLServer.DBMail.Files)」を参照してください。
+ 添付ファイルの最大サイズは 1 MB です。
+ データベースメールは、マルチ AZ DB インスタンスで追加の設定が必要です。詳細については、「[マルチ AZ 配置に関する考慮事項](#SQLServer.DBMail.MAZ)」を参照してください。
+ 定義済み演算子に E メールメッセージを送信する SQL Server エージェントの設定はサポートされていません。
# データベースメールの有効化
DB インスタンスでデータベースメールを有効にするには、次の手順に従います。
1. 新しいパラメータグループを作成します。
1. パラメータグループを変更して、`database mail xps` パラメータを 1 に設定します。
1. パラメータグループを DB インスタンスに関連付けます。
## データベースメールパラメータグループの作成
DB インスタンスの SQL Server のエディションとバージョンに対応する `database mail xps` パラメータのパラメータグループを作成します。
**注記**
既存のパラメータグループを変更することもできます。「[データベースメールを有効にするパラメータの変更](#DBMail.ModifyParamGroup)」 の手順に従います。
### コンソール
次の例では、SQL Server Standard Edition 2016 のパラメータグループを作成します。
**パラメータグループを作成するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、**[パラメータグループ]** を選択します。
1. [**Create parameter group**] を選択します。
1. [**パラメータグループの作成**] ペインで、次の操作を行います。
1. [**パラメータグループファミリー**] で、[**sqlserver-se-13.0**] を選択します。
1. [**グループ名**] に、パラメータグループの識別子 (**dbmail-sqlserver-se-13** など) を入力します。
1. [**説明**] に「**Database Mail XPs**」と入力します。
1. **[作成]** を選択します。
### CLI
次の例では、SQL Server Standard Edition 2016 のパラメータグループを作成します。
**パラメータグループを作成するには**
+ 以下のいずれかのコマンドを使用します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds create-db-parameter-group \
--db-parameter-group-name dbmail-sqlserver-se-13 \
--db-parameter-group-family "sqlserver-se-13.0" \
--description "Database Mail XPs"
```
Windows の場合:
```
aws rds create-db-parameter-group ^
--db-parameter-group-name dbmail-sqlserver-se-13 ^
--db-parameter-group-family "sqlserver-se-13.0" ^
--description "Database Mail XPs"
```
## データベースメールを有効にするパラメータの変更
DB インスタンスの SQL Server のエディションとバージョンに対応するパラメータグループの `database mail xps` パラメータを変更します。
データベースメールを有効にするには、`database mail xps` パラメータを 1 に設定します。
### コンソール
次の例では、SQL Server Standard Edition 2016 用に作成したパラメータグループを変更します。
**パラメータグループを変更するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**パラメータグループ**] を選択します。
1. [**dbmail-sqlserver-se-13**] などのパラメータグループを選択します。
1. [**パラメータ**] で、パラメータのリストを **mail** でフィルタ処理します。
1. [**データベースメール xps**] を選択します。
1. [**Edit parameters**] を選択します。
1. **1** と入力します。
1. **[Save changes]** (変更の保存) をクリックします。
### CLI
次の例では、SQL Server Standard Edition 2016 用に作成したパラメータグループを変更します。
**パラメータグループを変更するには**
+ 以下のいずれかのコマンドを使用します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name dbmail-sqlserver-se-13 \
--parameters "ParameterName='database mail xps',ParameterValue=1,ApplyMethod=immediate"
```
Windows の場合:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name dbmail-sqlserver-se-13 ^
--parameters "ParameterName='database mail xps',ParameterValue=1,ApplyMethod=immediate"
```
## パラメータグループと DB インスタンスの関連付け
AWS マネジメントコンソール または AWS CLI を使用して、データベースメールパラメータグループを DB インスタンスに関連付けることができます。
### コンソール
データベースメールパラメータグループを新規または既存の DB インスタンスに関連付けることができます。
+ 新しい DB インスタンスの場合は、インスタンスを起動するときにそれを関連付けます。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の DB インスタンスの場合は、インスタンスを変更することでそれを関連付けます。詳しくは、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
### CLI
データベースメールパラメータグループを新規または既存の DB インスタンスに関連付けることができます。
**データベースメールパラメータグループを使用して DB インスタンスを作成するには**
+ パラメータグループの作成時に使用したものと同じ DB エンジンのタイプとメジャーバージョンを指定します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds create-db-instance \
--db-instance-identifier mydbinstance \
--db-instance-class db.m5.2xlarge \
--engine sqlserver-se \
--engine-version 13.00.5426.0.v1 \
--allocated-storage 100 \
--manage-master-user-password \
--master-username admin \
--storage-type gp2 \
--license-model li
--db-parameter-group-name dbmail-sqlserver-se-13
```
Windows の場合:
```
aws rds create-db-instance ^
--db-instance-identifier mydbinstance ^
--db-instance-class db.m5.2xlarge ^
--engine sqlserver-se ^
--engine-version 13.00.5426.0.v1 ^
--allocated-storage 100 ^
--manage-master-user-password ^
--master-username admin ^
--storage-type gp2 ^
--license-model li ^
--db-parameter-group-name dbmail-sqlserver-se-13
```
**DB インスタンスを変更し、データベースメールパラメータグループを関連付けるには**
+ 以下のいずれかのコマンドを使用します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--db-parameter-group-name dbmail-sqlserver-se-13 \
--apply-immediately
```
Windows の場合:
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--db-parameter-group-name dbmail-sqlserver-se-13 ^
--apply-immediately
```
# データベースメールの設定
データベースメールを設定するには、次のタスクを実行します。
1. データベースメールプロファイルを作成します。
1. データベースメールアカウントを作成します。
1. データベースメールアカウントをデータベースメールプロファイルに追加します。
1. データベースメールプロファイルにユーザーを追加します。
**注記**
データベースメールを設定するには、`execute` データベースのストアドプロシージャに `msdb` アクセス権限があることを確認します。
## データベースメールプロファイルの作成
データベースメールプロファイルを作成するには、[sysmail\$1add\$1profile\$1sp](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-add-profile-sp-transact-sql) ストアドプロシージャを使用します。次の例では、`Notifications` という名前のプロファイルを作成します。
**プロファイルを作成するには**
+ 次の SQL 文を使用します。
```
USE msdb
GO
EXECUTE msdb.dbo.sysmail_add_profile_sp
@profile_name = 'Notifications',
@description = 'Profile used for sending outgoing notifications using Amazon SES.';
GO
```
## データベースメールアカウントの作成
データベースメールアカウントを作成するには、[sysmail\$1add\$1account\$1sp](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-add-account-sp-transact-sql) ストアドプロシージャを使用します。次の例では、Amazon Simple Email Service を使用して、プライベート VPC の RDS for SQL Server DB インスタンスに `SES` という名前のアカウントを作成します。
Amazon SES を使用するには、以下のパラメータが必要です。
+ `@email_address` – Amazon SES 検証済みの アイデンティティ。詳細については、[Verified identities in Amazon SES](https://docs.aws.amazon.com/ses/latest/dg/verify-addresses-and-domains.html) を参照してください。
+ `@mailserver_name` – Amazon SES SMTP エンドポイント。詳細については、[Amazon SES SMTP エンドポイントへの接続](https://docs.aws.amazon.com/ses/latest/dg/smtp-connect.html)を参照してください。
+ `@username` – Amazon SES SMTP ユーザー名。詳細については、[Amazon SES SMTP 認証情報の取得](https://docs.aws.amazon.com/ses/latest/dg/smtp-credentials.html)を参照してください。
AWS Identity and Access Management ユーザー名を使用しないでください。
+ `@password` – Amazon SES SMTP パスワード。詳細については、[Amazon SES SMTP 認証情報の取得](https://docs.aws.amazon.com/ses/latest/dg/smtp-credentials.html)を参照してください。
**アカウントを作成するには**
+ 次の SQL 文を使用します。
```
USE msdb
GO
EXECUTE msdb.dbo.sysmail_add_account_sp
@account_name = 'SES',
@description = 'Mail account for sending outgoing notifications.',
@email_address = 'nobody@example.com',
@display_name = 'Automated Mailer',
@mailserver_name = 'vpce-0a1b2c3d4e5f-01234567.email-smtp.us-west-2.vpce.amazonaws.com',
@port = 587,
@enable_ssl = 1,
@username = 'Smtp_Username',
@password = 'Smtp_Password';
GO
```
**注記**
セキュリティのベストプラクティスとして、ここに表示されているプロンプト以外の認証情報を指定してください。
## データベースメールアカウントのデータベースメールプロファイルへの追加
データベースメールアカウントをデータベースメールプロファイルに追加するには、[sysmail\$1add\$1profileaccount\$1sp](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-add-profileaccount-sp-transact-sql) ストアドプロシージャを使用します。次の例では、`SES` アカウントを `Notifications` プロファイルに追加します。
**プロファイルにアカウントを追加するには**
+ 次の SQL 文を使用します。
```
USE msdb
GO
EXECUTE msdb.dbo.sysmail_add_profileaccount_sp
@profile_name = 'Notifications',
@account_name = 'SES',
@sequence_number = 1;
GO
```
## データベースメールプロファイルへのユーザーの追加
`msdb` データベースプリンシパルにデータベースメールプロファイルを使用するアクセス権限を付与するには、[sysmail\$1add\$1principalprofile\$1sp](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sysmail-add-principalprofile-sp-transact-sql) ストアドプロシージャを使用します。*プリンシパル* は、SQL Server リソースをリクエストできるエンティティです。データベースプリンシパルは、SQL Server 認証ユーザー、Windows 認証ユーザー、または Windows 認証グループにマッピングする必要があります。
次の例では、`Notifications` プロファイルへのパブリックアクセスを許可します。
**プロファイルにユーザーを追加するには**
+ 次の SQL 文を使用します。
```
USE msdb
GO
EXECUTE msdb.dbo.sysmail_add_principalprofile_sp
@profile_name = 'Notifications',
@principal_name = 'public',
@is_default = 1;
GO
```
## データベースメールの Amazon RDS ストアドプロシージャと関数
Microsoft が提供する[ストアドプロシージャ](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/database-mail-stored-procedures-transact-sql)により、データベースメールの使用 (アカウントやプロファイルの作成、一覧表示、更新、削除) が可能です。加えて、RDS は、次の表に示すストアドプロシージャおよびデータベースメールの機能を提供します。
| プロシージャ/関数 | 説明 |
| --- | --- |
| rds\$1fn\$1sysmail\$1allitems | 送信メッセージ (他のユーザーの送信メッセージを含む) を表示します。 |
| rds\$1fn\$1sysmail\$1event\$1log | イベント (他のユーザーの送信メッセージのイベントを含む) を表示します。 |
| rds\$1fn\$1sysmail\$1mailattachments | 添付ファイル (他のユーザーの送信メッセージの添付ファイルも含む) を表示します。 |
| rds\$1sysmail\$1control | メールキュー (DatabaseMail.exe プロセス) を開始および停止します。 |
| rds\$1sysmail\$1delete\$1mailitems\$1sp | すべてのユーザーが送信した E メールメッセージをデータベースメール内部テーブルから削除します。 |
# データベースメールを使用した E メールメッセージの送信
データベースメールを使用して E メールメッセージを送信するには、[sp\$1send\$1dbmail](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-send-dbmail-transact-sql) ストアドプロシージャを使用します。
## Usage
```
EXEC msdb.dbo.sp_send_dbmail
@profile_name = 'profile_name',
@recipients = 'recipient1@example.com[; recipient2; ... recipientn]',
@subject = 'subject',
@body = 'message_body',
[@body_format = 'HTML'],
[@file_attachments = 'file_path1; file_path2; ... file_pathn'],
[@query = 'SQL_query'],
[@attach_query_result_as_file = 0|1]';
```
以下のパラメータは必須です。
+ `@profile_name` – メッセージの送信元となるデータベースメールプロファイル名
+ `@recipients` – メッセージの送信先となるセミコロン区切りの E メールアドレスリスト
+ `@subject` – メッセージの件名
+ `@body` – メッセージの本文 宣言された変数を本文として使用することもできます。
以下のパラメータはオプションです。
+ `@body_format` – このパラメータは、HTML 形式で E メールを送信するため、宣言された変数と共に使用します。
+ `@file_attachments` – セミコロン区切りのメッセージ添付ファイルリスト。ファイルパスは絶対パスである必要があります。
+ `@query` – 実行する SQL クエリ クエリ結果は、ファイルで添付することも、メッセージの本文に含めることもできます。
+ `@attach_query_result_as_file` – クエリ結果をファイルでアタッチするかどうか。[いいえ] の場合は 0、[はい] の場合は 1 に設定します。デフォルトは 0 です。
## 例
次の例は、E メールメッセージを送信する方法をデモンストレーションします。
**Example 単一の受信者へのメッセージの送信の**
```
USE msdb
GO
EXEC msdb.dbo.sp_send_dbmail
@profile_name = 'Notifications',
@recipients = 'nobody@example.com',
@subject = 'Automated DBMail message - 1',
@body = 'Database Mail configuration was successful.';
GO
```
**Example 複数の受信者へのメッセージの送信の**
```
USE msdb
GO
EXEC msdb.dbo.sp_send_dbmail
@profile_name = 'Notifications',
@recipients = 'recipient1@example.com;recipient2@example.com',
@subject = 'Automated DBMail message - 2',
@body = 'This is a message.';
GO
```
**Example 添付ファイルでの SQL クエリ結果の送信の**
```
USE msdb
GO
EXEC msdb.dbo.sp_send_dbmail
@profile_name = 'Notifications',
@recipients = 'nobody@example.com',
@subject = 'Test SQL query',
@body = 'This is a SQL query test.',
@query = 'SELECT * FROM abc.dbo.test',
@attach_query_result_as_file = 1;
GO
```
**Example HTML 形式でのメッセージの送信の**
```
USE msdb
GO
DECLARE @HTML_Body as NVARCHAR(500) = 'Hi, Heading
See the report. Regards ';
EXEC msdb.dbo.sp_send_dbmail
@profile_name = 'Notifications',
@recipients = 'nobody@example.com',
@subject = 'Test HTML message',
@body = @HTML_Body,
@body_format = 'HTML';
GO
```
**Example データベースで特定のイベントが発生した時の、トリガーを使用したメッセージの送信の**
```
USE AdventureWorks2017
GO
IF OBJECT_ID ('Production.iProductNotification', 'TR') IS NOT NULL
DROP TRIGGER Purchasing.iProductNotification
GO
CREATE TRIGGER iProductNotification ON Production.Product
FOR INSERT
AS
DECLARE @ProductInformation nvarchar(255);
SELECT
@ProductInformation = 'A new product, ' + Name + ', is now available for $' + CAST(StandardCost AS nvarchar(20)) + '!'
FROM INSERTED i;
EXEC msdb.dbo.sp_send_dbmail
@profile_name = 'Notifications',
@recipients = 'nobody@example.com',
@subject = 'New product information',
@body = @ProductInformation;
GO
```
# メッセージ、ログ、添付ファイルの表示
RDS ストアドプロシージャを使用して、メッセージ、イベントログ、および添付ファイルを表示します。
**すべての E メールメッセージを表示するには**
+ 次の SQL クエリを使用します。
```
SELECT * FROM msdb.dbo.rds_fn_sysmail_allitems(); --WHERE sent_status='sent' or 'failed' or 'unsent'
```
**すべての E メールイベントログを表示するには**
+ 次の SQL クエリを使用します。
```
SELECT * FROM msdb.dbo.rds_fn_sysmail_event_log();
```
**すべての E メールの添付ファイルを表示するには**
+ 次の SQL クエリを使用します。
```
SELECT * FROM msdb.dbo.rds_fn_sysmail_mailattachments();
```
# メッセージの削除
`rds_sysmail_delete_mailitems_sp` ストアドプロシージャを使用して、メッセージを削除します。
**注記**
RDS は、データベースメール履歴データのサイズが 1 GB に達すると、メールテーブル項目を自動的に削除します。保持期間は最短 24 時間です。
メールアイテムを長期間保持する場合、アーカイブできます。詳細については、Microsoft ドキュメントの「[データベースメールメッセージとイベントログをアーカイブする SQL Server Agent ジョブの作成](https://docs.microsoft.com/en-us/sql/relational-databases/database-mail/create-a-sql-server-agent-job-to-archive-database-mail-messages-and-event-logs)」を参照してください。
**E メールメッセージをすべて削除するには**
+ 次の SQL 文を使用します。
```
DECLARE @GETDATE datetime
SET @GETDATE = GETDATE();
EXECUTE msdb.dbo.rds_sysmail_delete_mailitems_sp @sent_before = @GETDATE;
GO
```
**特定のステータスの E メールメッセージをすべて削除するには**
+ 失敗したメッセージをすべて削除するには、次の SQL ステートメントを使用します。
```
DECLARE @GETDATE datetime
SET @GETDATE = GETDATE();
EXECUTE msdb.dbo.rds_sysmail_delete_mailitems_sp @sent_status = 'failed';
GO
```
# メールキューの開始と停止
DB メールキューを開始および停止するには、次の手順に従います。
**Topics**
+ [メールキューの開始](#SQLServer.DBMail.Start)
+ [メールキューの停止](#SQLServer.DBMail.Stop)
## メールキューの開始
`rds_sysmail_control` ストアドプロシージャを使用して、データベースメールプロセスを開始します。
**注記**
データベースメールを有効にすると、メールキューが自動的に開始します。
**メールキューを開始するには**
+ 次の SQL 文を使用します。
```
EXECUTE msdb.dbo.rds_sysmail_control start;
GO
```
## メールキューの停止
`rds_sysmail_control` ストアドプロシージャを使用して、データベースメールプロセスを停止します。
**メールキューを停止するには**
+ 次の SQL 文を使用します。
```
EXECUTE msdb.dbo.rds_sysmail_control stop;
GO
```
## 添付ファイルの使用
SQL Server の RDS からのデータベースメールメッセージでは、次の添付ファイル拡張子をサポートしていません。.ade、.adp、.apk、.appx、.appxbundle、.bat、.bak、.cab、.chm、.cmd、.com、.cpl、.dll、.dmg、.exe、.hta、.inf1、.ins、.isp、.iso、.jar、.job、.js、.jse、.ldf、.lib、.lnk、.mde、.mdf、.msc、.msi、.msix、.msixbundle、.msp、.mst、.nsh、.pif、.ps、.ps1、.psc1、.reg、.rgs、.scr、.sct、.shb、.shs、.svg、.sys、.u3p、.vb、.vbe、.vbs、.vbscript、.vxd、.ws、wsc、.wsf、および.wsh
データベースメールは、現在のユーザーの Microsoft Windows セキュリティコンテキストを使用して、ファイルへのアクセスを制御します。SQL Server 認証でログインするユーザーは、`@file_attachments` ストアドプロシージャで`sp_send_dbmail` パラメータを使用してファイルをアタッチすることはできません。Windows では、リモートコンピュータから別のリモートコンピュータに、SQL Server が認証情報を提供することはできません。したがって、データベースメールは、SQL Server を実行しているコンピュータ以外のコンピュータからコマンドを実行すると、ネットワーク共有からファイルをアタッチすることはできません。
ただし、SQL Server Agent ジョブを使用して、ファイルをアタッチすることができます。SQL Server Agent の詳細については、Microsoft ドキュメントの「[Amazon RDS 用 SQL Server エージェントの使用](Appendix.SQLServer.CommonDBATasks.Agent.md)」および「[SQL Server Agent](https://docs.microsoft.com/en-us/sql/ssms/agent/sql-server-agent)」を参照してください。
## マルチ AZ 配置に関する考慮事項
マルチ AZ DB インスタンスでデータベースメールを設定しても、設定はセカンダリに自動的には反映されません。マルチ AZ インスタンスをシングル AZ インスタンスに変換し、データベースメールを設定した後に、DB インスタンスをマルチ AZ に戻すことをお勧めします。次に、プライマリノードとセカンダリノードの両方に、データベースメールの設定があります。
データベースメールを設定したマルチ AZ インスタンスからリードレプリカを作成すると、レプリカはその設定を継承しますが、SMTP サーバーのパスワードは継承しません。パスワードを使用して、データベースメールアカウントを更新します。
## SMTP (ポート 25) 制限の削除
デフォルトでは、AWS は RDS for SQL Server DB インスタンスの SMTP (ポート 25) でのアウトバウンドトラフィックをブロックします。これは、Elastic Network Interface 所有者のポリシーに基づいてスパムを防ぐために行われます。必要に応じて、この制限を削除できます。詳細については、「[Amazon EC2 インスタンスまたは Lambda 関数のポート 25 の制限を解除するにはどうすればよいですか?](https://repost.aws/knowledge-center/ec2-port-25-throttle)」を参照してください。
# Amazon RDS for SQL Server の tempdb データベースに対するインスタンスストアのサポート
*インスタンスストア*は、DB インスタンスに一時ブロックレベルのストレージを提供します。このストレージは、ホストコンピュータに物理的にアタッチされたディスク上にあります。これらのディスクには、ソリッドステートドライブ (SSD) に基づく不揮発性メモリエクスプレス (NVMe) インスタンスストレージがあります。このストレージは、低レイテンシー、非常に高いランダム I/O パフォーマンス、高いシーケンシャル読み取りスループットを実現するために最適化されています。
`tempdb` データファイルと `tempdb` ログファイルをインスタンスストアに配置することで、Amazon EBS に基づく標準ストレージと比べて、読み取りおよび書き込みのレイテンシーを低く抑えることができます。
**注記**
SQL Server データベースファイルとデータベースログファイルは、インスタンスストアに配置されません。
## インスタンスストアの有効化
RDS が次のいずれかのインスタンスクラスを使用して DB インスタンスをプロビジョニングすると、`tempdb` データベースは自動的にインスタンスストアに配置されます。
+ db.m5d
+ db.r5d
+ db.x2iedn
インスタンスストアを有効にするには、次のいずれかの操作を行います。
+ これらのインスタンスタイプの 1 つを使用して SQL Server DB インスタンスを作成します。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の SQL Server DB インスタンスを変更して、そのうちの 1 つを使用します。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
インスタンスストアは、これらのインスタンスタイプの 1 つ以上がサポートされているすべての AWS リージョンで使用できます。`db.m5d` と `db.r5d` インスタンスクラスの詳細については、「[ DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。Amazon RDS for SQL Server でサポートされるインスタンスクラスの詳細については、[Microsoft SQL Server の DB インスタンスクラスのサポート](SQLServer.Concepts.General.InstanceClasses.md) を参照してください。
## ファイルの場所とサイズに関する考慮事項
インスタンスストアがないインスタンスでは、RDS は `tempdb` データとログファイルを `D:\rdsdbdata\DATA` ディレクトリに保存します。デフォルトでは、どちらのファイルも 8 MB から始まります。
インスタンスストアがあるインスタンスでは、RDS は `tempdb` データとログファイルを `T:\rdsdbdata\DATA` ディレクトリに保存します。
`tempdb` にデータファイル (`tempdb.mdf`) とログファイル (`templog.ldf`) が 1 つしかない場合、`templog.ldf` はデフォルトでは 8 MB から始まり、`tempdb.mdf` はインスタンスのストレージ容量の 80％以上から始まります。ストレージ容量の 20% または 200 GB のどちらか小さい方を、無料で起動できます。複数の `tempdb` データファイルは 80% のディスク領域を均等に分割しますが、ログファイルの初期サイズは常に 8 MB です。
例えば、DB インスタンスクラスを `db.m5.2xlarge` から `db.m5d.2xlarge` に変更すると、`tempdb` データファイルのサイズはそれぞれ 8 MB から合計 234 GB に増加します。
**注記**
インスタンスストア (`tempdb`) の `T:\rdsdbdata\DATA` データとログファイルに加えて、データボリューム (`tempdb`) に追加の `D:\rdsdbdata\DATA` データとログファイルを作成することもできます。これらのファイルの初期サイズは常に 8 MB です。
## バックアップに関する考慮事項
バックアップを長期間保持する必要がありますが、時間の経過とともにコストがかかる場合があります。`tempdb` データブロックとログブロックは、ワークロードに応じて非常に頻繁に変更されることがあります。これにより、DB スナップショットのサイズが大幅に増加する可能性があります。
`tempdb` がインスタンスストアにある場合、スナップショットに一時ファイルは含まれません。つまり、EBS のみのストレージと比べて、スナップショットのサイズが小さくなり、空いたバックアップ割り当ての使用量が少なくなります。
## ディスクがいっぱいになるエラー
インスタンスストア内の使用可能な領域をすべて使用すると、次のようなエラーが表示されることがあります。
+ データベース「tempdb」のトランザクションログは「ACTIVE\$1TRANSACTION」のため、いっぱいになりました。
+ PRIMARY」ファイルグループがいっぱいであるため、データベース「tempdb」のオブジェクト「dbo.SORT の一時実行ストレージ: 140738941419520」に領域を割り当てられませんでした。不要なファイルの削除、ファイルグループ内のオブジェクトの削除、ファイルグループへのファイルの追加、またはファイルグループ内の既存のファイルの自動拡張を有効に設定して、ディスク領域を作ります。
インスタンスストアがいっぱいになると、次の項目のうちから 1 つまたは複数を実行できます。
+ ワークロードや `tempdb` の使用方法を調整します。
+ より多くの NVMe ストレージを持つ DB インスタンスクラスを使用するように拡張します。
+ インスタンスストアの使用を停止し、EBS ストレージのみを持つインスタンスクラスを使用します。
+ EBS ボリューム上の `tempdb` のセカンダリデータまたはログファイルを追加して、混合モードを使用します。
## インスタンスストアの削除
インスタンスストアを削除するには、インスタンスストアをサポートしないインスタンスタイプ (db.m5、db.r5、db.x1e など) を使用するように SQL Server DB インスタンスを変更します。
**注記**
インスタンスストアを削除すると、一時ファイルは `D:\rdsdbdata\DATA` ディレクトリに移動され、8 MB に縮小されます。
# Amazon RDS for Microsoft SQL Server で拡張イベントを使用する
Microsoft SQL Server の拡張イベントを使用して、Amazon RDS for SQL Server のデバッグおよびトラブルシューティング情報をキャプチャできます。拡張イベントは、Microsoft によって非推奨にされている SQL Trace と Server Profiler を置き換えます。拡張イベントは、プロファイラートレースに似ていますが、トレースされるイベントをより細かく制御できます。拡張イベントは、Amazon RDS で SQL Server バージョン 2016 以降でサポートされています。詳細については、Microsoft のドキュメントの「[Extended events overview](https://docs.microsoft.com/en-us/sql/relational-databases/extended-events/extended-events)」を参照してください。
Amazon RDS for SQL Server のマスターユーザー特権を持つユーザーの場合、拡張イベントは自動的にオンになります。
**Topics**
+ [制限と推奨事項](#SQLServer.ExtendedEvents.Limits)
+ [RDS for SQL Server での拡張イベントの設定](#SQLServer.ExtendedEvents.Config)
+ [マルチ AZ 配置に関する考慮事項](#SQLServer.ExtendedEvents.MAZ)
+ [拡張イベントファイルのクエリ](#SQLServer.ExtendedEvents.Querying)
## 制限と推奨事項
RDS for SQL Server で拡張イベントを使用する場合、次の制限が適用されます。
+ 拡張イベントは、Enterprise エディションと Standard エディションでのみサポートされます。
+ デフォルトの拡張イベントセッションは変更できません。
+ セッションメモリのパーティションモードを `NONE` に設定してください。
+ セッションイベント保持モードは、`ALLOW_SINGLE_EVENT_LOSS` または `ALLOW_MULTIPLE_EVENT_LOSS` のいずれかになります。
+ Event Tracing for Windows (ETW) ターゲットはサポートされていません。
+ ファイルターゲットが `D:\rdsdbdata\log` ディレクトリにあることを確認します。
+ ペアが一致するターゲットの場合は、`respond_to_memory_pressure` プロパティを `1` に設定します。
+ リングバッファーターゲットメモリは 4 MB を超えることはできません。
+ 次のアクションはサポートされていません。
+ `debug_break`
+ `create_dump_all_threads`
+ `create_dump_single_threads`
+ `rpc_completed` イベントは、15.0.4083.2、14.0.3370.1、13.0.5865.1、12.0.6433.1、11.0.7507.2 以降のバージョンでサポートされています。
## RDS for SQL Server での拡張イベントの設定
RDS for SQL Server では、拡張イベントセッションの特定のパラメータ値を設定できます。次の表では、設定可能なパラメータについて説明しています。
| パラメータ名 | 説明 | RDS デフォルト値 | 最小値 | 最大値 |
| --- | --- | --- | --- | --- |
| xe\$1session\$1max\$1memory | イベントバッファリングのためにセッションに割り当てるメモリの最大量を指定します。この値は、イベントセッションの max\$1memory 設定に対応しています。 | 4 MB | 4 MB | 8 MB |
| xe\$1session\$1max\$1event\$1size | 大きなイベントで許可される最大メモリサイズを指定します。この値は、イベントセッションの max\$1event\$1size 設定に対応しています。 | 4 MB | 4 MB | 8 MB |
| xe\$1session\$1max\$1dispatch\$1latency | 拡張イベントセッションターゲットにディスパッチされるまでにイベントがメモリにバッファされる時間を指定します。この値は、イベントセッションの max\$1dispatch\$1latency 設定に対応しています。 | 30 秒 | 1 秒 | 30 秒 |
| xe\$1file\$1target\$1size | ファイルターゲットの最大サイズを指定します。この値は、ファイルターゲットの max\$1file\$1size 設定に対応します。 | 100 MB | 10 MB | 1 GB |
| xe\$1file\$1retention | イベントセッションのファイルターゲットによって生成されたファイルの保存期間を日単位で指定します。 | 7 日間 | 0 日 | 7 日間 |
**注記**
`xe_file_retention` をゼロに設定すると、これらのファイルのロックが SQL Server によって解放された後、.xel ファイルが自動的に削除されます。ロックは、.xel ファイルが `xe_file_target_size` で設定されたサイズ制限に達すると解放されます。
`rdsadmin.dbo.rds_show_configuration` ストアドプロシージャを使用して、これらのパラメータの現在の値を表示できます。例えば、`xe_session_max_memory` の現在の設定を表示するには、次の SQL 文を使用します。
```
exec rdsadmin.dbo.rds_show_configuration 'xe_session_max_memory'
```
`rdsadmin.dbo.rds_set_configuration` ストアドプロシージャを使用して変更することができます。例えば、`xe_session_max_memory` を 4 MB に設定するには、次の SQL ステートメントを使用します。
```
exec rdsadmin.dbo.rds_set_configuration 'xe_session_max_memory', 4
```
## マルチ AZ 配置に関する考慮事項
プライマリ DB インスタンスで拡張イベントセッションを作成すると、そのセッションはスタンバイレプリカに伝達されません。新しいプライマリ DB インスタンスで、拡張イベントセッションをフェイルオーバーして作成できます。または、マルチ AZ 設定を削除してから再び追加して、拡張イベントセッションをスタンバイレプリカに伝達することもできます。RDS は、スタンバイレプリカ上のデフォルト以外の拡張イベントセッションをすべて停止し、これらのセッションがスタンバイ上のリソースを消費しません。このため、スタンバイレプリカがプライマリ DB インスタンスになった後、新しいプライマリで拡張イベントセッションを手動で開始するようにしてください。
**注記**
このアプローチは、Always On 可用性グループとデータベースミラーリングの両方に適用されます。
SQL Server エージェントジョブを使用して、スタンバイレプリカを追跡し、スタンバイがプライマリになる場合はセッションを開始することもできます。例えば、SQL Server エージェントのジョブステップで次のクエリを使用して、プライマリ DB インスタンスでイベントセッションを再開します。
```
BEGIN
IF (DATABASEPROPERTYEX('rdsadmin','Updateability')='READ_WRITE'
AND DATABASEPROPERTYEX('rdsadmin','status')='ONLINE'
AND (DATABASEPROPERTYEX('rdsadmin','Collation') IS NOT NULL OR DATABASEPROPERTYEX('rdsadmin','IsAutoClose')=1)
)
BEGIN
IF NOT EXISTS (SELECT 1 FROM sys.dm_xe_sessions WHERE name='xe1')
ALTER EVENT SESSION xe1 ON SERVER STATE=START
IF NOT EXISTS (SELECT 1 FROM sys.dm_xe_sessions WHERE name='xe2')
ALTER EVENT SESSION xe2 ON SERVER STATE=START
END
END
```
このクエリにより、イベントセッション `xe1` と `xe2` が停止状態の場合は、これらのイベントセッションがプライマリ DB インスタンスで再開されます。また、このクエリに便利な間隔のスケジュールを追加することもできます。
## 拡張イベントファイルのクエリ
SQL Server Management Studio または `sys.fn_xe_file_target_read_file` 関数を使用して、ファイルターゲットを使用する拡張イベントのデータを表示できます。この関数の詳細については、Microsoft ドキュメントの [sys.fn\$1xe\$1file\$1target\$1read\$1file (Transact-SQL)](https://docs.microsoft.com/en-us/sql/relational-databases/system-functions/sys-fn-xe-file-target-read-file-transact-sql) を参照してください。
拡張イベントファイルターゲットは、RDS for SQL Server の `D:\rdsdbdata\log` ディレクトリにのみファイルを書き込むことができます。
例えば、次の SQL クエリを使用して、名前が `xe` で始まる拡張イベントセッションのすべてのファイルの内容を一覧表示します。
```
SELECT * FROM sys.fn_xe_file_target_read_file('d:\rdsdbdata\log\xe*', null,null,null);
```
# RDS for SQL Server によるトランザクションログのバックアップへのアクセス
RDS for SQL Server のトランザクションログのバックアップにアクセスすることで、データベースのトランザクションログのバックアップファイルを一覧表示し、ターゲット Amazon S3 バケットにコピーできます。Amazon S3 バケットにトランザクションログのバックアップをコピーすることで、それらをデータベースの完全バックアップや差分バックアップと組み合わせて使用し、特定の時点でのデータベース復元を実行できます。RDS ストアドプロシージャを使用して、トランザクションログのバックアップへのアクセスを設定し、利用可能なトランザクションログバックアップを一覧表示して、Amazon S3 バケットにコピーします。
トランザクションログのバックアップにアクセスすると、次のような機能と利点を利用できます。
+ RDS for SQL Server DB インスタンスにあるデータベースの利用可能なトランザクションログのバックアップのメタデータを一覧表示して表示します。
+ 使用可能なトランザクションログのバックアップを RDS for SQL Server からターゲット Amazon S3 バケットにコピーします。
+ DB インスタンス全体を復元しなくても、データベースのポイントインタイム復元を実行できます。DB クラスターのポイントインタイム復元の方法については、「[Amazon RDS の DB インスタンスを特定の時点に復元する](USER_PIT.md)」を参照してください。
## 可用性およびサポート
トランザクションログのバックアップへのアクセスは、すべての AWS リージョンでサポートされています。トランザクションログバックアップへのアクセスは、Amazon RDS でサポートされている Microsoft SQL Server のすべてのエディションとバージョンで使用できます。
## 要件
トランザクションログのバックアップへのアクセスを有効にする前に、以下の要件を満たす必要があります。
+ DB インスタンスで自動バックアップを有効に設定し、バックアップの保存期間を 1 日以上の値に設定する必要があります。自動バックアップの有効化と保存ポリシーの設定の詳細については、「[自動バックアップの有効化](USER_WorkingWithAutomatedBackups.Enabling.md)」を参照してください。
+ Amazon S3 バケットは、ソース DB インスタンスと同じアカウントとリージョンに存在している必要があります。トランザクションログのバックアップへのアクセスを有効にする前に、トランザクションログのバックアップファイルに使用するため、既存の Amazon S3 バケットを選択するか、[新しいバケットを作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingaBucket.html)します。
+ Amazon RDS によってトランザクションログファイルをコピーできるように、Amazon S3 バケットのアクセス権限ポリシーを次のように設定する必要があります。
1. バケットのオブジェクトアカウントの所有権プロパティを **[Bucket Owner Preferred]** (バケット所有者優先) に設定します。
1. 以下のポリシーを追加します。デフォルトではポリシーがないため、バケットアクセスコントロールリスト (ACL) を使用してバケットポリシーを編集し、追加します。
次の例では、ARN を使用してリソースを指定しています。リソースベースの信頼関係では `SourceArn` および `SourceAccount` のグローバル条件コンテキストキーを使用して、サービスに付与する特定のリソースへのアクセス許可を制限することをお勧めします。ARN での使用の詳細については、「[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)」および「[Amazon RDS の Amazon リソースネーム (ARN)](USER_Tagging.ARN.md)」を参照してください。
**Example トランザクションログのバックアップへのアクセスするための Amazon S3 権限ポリシーの例**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Only allow writes to my bucket with bucket owner full control",
"Effect": "Allow",
"Principal": {
"Service": "backups.rds.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/{customer_path}/*",
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:sourceAccount": "{customer_account}",
"aws:sourceArn": "{db_instance_arn}"
}
}
}
]
}
```
------
+ Amazon S3 バケットにアクセスするための AWS Identity and Access Management (IAM) ロール。IAM ロールが既にある場合はそれを使用できます。AWS マネジメントコンソール を使用して `SQLSERVER_BACKUP_RESTORE` オプションを追加する際に、新しい IAM ロールの作成を選択することもできます。または、手動で新しいロールを作成することもできます。`SQLSERVER_BACKUP_RESTORE` による IAM ロールの作成と設定の詳細については、「[ネイティブバックアップおよび復元用の IAM ロールの手動作成](SQLServer.Procedural.Importing.Native.Enabling.md#SQLServer.Procedural.Importing.Native.Enabling.IAM)」を参照してください。
+ `SQLSERVER_BACKUP_RESTORE` オプションは、DB インスタンスのオプショングループに追加されている必要があります。`SQLSERVER_BACKUP_RESTORE` オプションの追加についての詳細は、「[SQL Server のネイティブバックアップおよび復元のサポート](Appendix.SQLServer.Options.BackupRestore.md)」を参照してください。
**注記**
DB インスタンスでストレージ暗号化が有効になっている場合は、ネイティブバックアップと復元オプショングループで提供される IAM ロールに AWS KMS (KMS) アクションとキーを指定する必要があります。
オプションで、`rds_restore_log` ストアドプロシージャを使用してデータベースのポイントインタイム復元を実行する場合は、ネイティブバックアップ、復元オプショングループ、トランザクションログのバックアップへのアクセスに、同じ Amazon S3 パスを使用することをお勧めします。この方法により、Amazon RDS がオプショングループから復元ログ機能を実行する役割を引き受けると、同じ Amazon S3 パスからトランザクションログのバックアップを取得できるようになります。
+ DB インスタンスが暗号化されている場合、暗号化タイプ (AWSマネージドキーまたはカスタマーマネージドキー) に関係なく、IAM ロールと `rds_tlog_backup_copy_to_S3` ストアドプロシージャでカスタマーマネージド KMS キーを指定する必要があります。
## 制限と推奨事項
トランザクションログのバックアップへのアクセスには、次の制限と推奨事項があります。
+ バックアップの保存期間が 1 日から 35 日の間に設定されている任意の DB インスタンスについて、過去 7 日間のトランザクションログのバックアップを一覧表示してコピーできます。
+ トランザクションログのバックアップのアクセスに使用する Amazon S3 バケットは、ソース DB インスタンスと同じアカウントとリージョンに存在している必要があります。クロスアカウントおよびクロスリージョンコピーはサポートされていません。
+ トランザクションログのバックアップのコピー先として設定できる Amazon S3 バケットは 1 つだけです。`rds_tlog_copy_setup` ストアドプロシージャを使用して、新しいターゲット Amazon S3 バケットを選択できます。新しいターゲット Amazon S3 バケットの選択の詳細については、「[トランザクションログのバックアップへのアクセス設定](USER.SQLServer.AddlFeat.TransactionLogAccess.Enabling.md)」を参照してください。
+ RDS インスタンスでストレージ暗号化が有効になっていない場合、`rds_tlog_backup_copy_to_S3` ストアドプロシージャを使用するときに KMS キーを指定することはできません。
+ マルチアカウントコピーはサポートされていません。コピーに使用される IAM ロールは、DB インスタンスの所有者アカウント内の Amazon S3 バケットへの書き込みアクセスのみを許可します。
+ RDS for SQL Server DB インスタンスでは、どのような種類のタスクでも 2 つまでしか実行できません。
+ 1 つのデータベースに対して、同時に実行できるコピータスクは 1 つだけです。DB インスタンス上の複数のデータベースのトランザクションログのバックアップをコピーする場合は、データベースごとに個別のコピータスクを使用します。
+ 既に Amazon S3 バケットに同じ名前で存在するトランザクションログのバックアップをコピーすると、既存のトランザクションログのバックアップは上書きされます。
+ プライマリ DB インスタンスのトランザクションログのバックアップへのアクセス権が提供されているストアドプロシージャのみを実行できます。これらのストアドプロシージャは、RDS for SQL Server のリードレプリカや、マルチ AZ DB クラスターのセカンダリインスタンスでは実行できません。
+ `rds_tlog_backup_copy_to_S3` ストアドプロシージャの実行中に RDS for SQL Server DB インスタンスを再起動すると、DB インスタンスがオンラインに戻ったときに、タスクは自動的に最初から再開されます。再起動前に、タスクの実行中に Amazon S3 バケットにコピーされたトランザクションログのバックアップはすべて上書きされます。
+ Microsoft SQL Server システムデータベースと `RDSAdmin` データベースは、トランザクションログのバックアップにアクセスするように設定できません。
+ SSE-KMS で暗号化されたバケットへのコピーはサポートされていません。
# トランザクションログのバックアップへのアクセス設定
トランザクションログのバックアップへのアクセスを設定するには、[要件](USER.SQLServer.AddlFeat.TransactionLogAccess.md#USER.SQLServer.AddlFeat.TransactionLogAccess.Requirements) セクションの要件リストを入力して、次に `rds_tlog_copy_setup` ストアドプロシージャを実行します。この手順により、DB インスタンスレベルでトランザクションログのバックアップ機能にアクセスできるようになります。DB インスタンス上の個々のデータベースごとに実行する必要はありません。
**重要**
トランザクションログのバックアップ機能へのアクセスを設定し、使用するには、データベースユーザーに SQL Server 内の各データベースの `db_owner` ロールを付与する必要があります。
**Example 使用例:**
```
exec msdb.dbo.rds_tlog_copy_setup
@target_s3_arn='arn:aws:s3:::amzn-s3-demo-bucket/myfolder';
```
以下のパラメータは必須です。
+ `@target_s3_arn` – トランザクションログのバックアップファイルをコピーするターゲット Amazon S3 バケットの ARN。
**Example Amazon S3 バケットのターゲットバケットの設定例:**
```
exec msdb.dbo.rds_tlog_copy_setup @target_s3_arn='arn:aws:s3:::amzn-s3-demo-logging-bucket/mytestdb1';
```
設定を検証するには、`rds_show_configuration` ストアドプロシージャを呼び出します。
**Example 設定の検証例:**
```
exec rdsadmin.dbo.rds_show_configuration @name='target_s3_arn_for_tlog_copy';
```
トランザクションログのバックアップへのアクセス先を別の Amazon S3 バケットに変更するには、現在の Amazon S3 バケット値を表示し、`@target_s3_arn` の新しい値を使用して、`rds_tlog_copy_setup` ストアドプロシージャを再実行します。
**Example トランザクションログのバックアップにアクセスするため設定された既存の Amazon S3 バケットの表示例**
```
exec rdsadmin.dbo.rds_show_configuration @name='target_s3_arn_for_tlog_copy';
```
**Example 新しいターゲット Amazon S3 バケットへの更新例**
```
exec msdb.dbo.rds_tlog_copy_setup @target_s3_arn='arn:aws:s3:::amzn-s3-demo-logging-bucket1/mynewfolder';
```
# 利用可能なトランザクションログのバックアップの一覧表示
RDS for SQL Server では、完全な復旧モデルを使用するように設定されたデータベースで、DB インスタンスのバックアップ保存期間を 1 日以上に設定すると、トランザクションログのバックアップが自動で有効になります。トランザクションログのバックアップへのアクセスを有効にすると、最大 7 日間分のトランザクションログのバックアップを Amazon S3 バケットにコピーできるようになります。
トランザクションログのバックアップへのアクセスを有効にすると、それを使用して、利用可能なトランザクションログバックアップファイルの一覧表示と、コピーを開始できます。
**トランザクションログのバックアップの一覧表示**
個々のデータベースで利用可能なすべてのトランザクションログのバックアップを一覧表示するには、`rds_fn_list_tlog_backup_metadata` 関数を呼び出します。関数を呼び出すときは、`ORDER BY` または `WHERE` 句を使用できます。
**Example 利用可能なトランザクションログのバックアップファイルの一覧表示とフィルタリング例**
```
SELECT * from msdb.dbo.rds_fn_list_tlog_backup_metadata('mydatabasename');
SELECT * from msdb.dbo.rds_fn_list_tlog_backup_metadata('mydatabasename') WHERE rds_backup_seq_id = 3507;
SELECT * from msdb.dbo.rds_fn_list_tlog_backup_metadata('mydatabasename') WHERE backup_file_time_utc > '2022-09-15 20:44:01' ORDER BY backup_file_time_utc DESC;
```
![\[rds_fn_list_tlog_backup_metadata からの出力\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/sql_accesstransactionlogs_func.png)
`rds_fn_list_tlog_backup_metadata` 関数は、次の出力を返します。
****
| 列名 | データ型 | 説明 |
| --- | --- | --- |
| `db_name` | sysname | トランザクションログのバックアップを一覧表示するために指定されたデータベース名。 |
| `db_id` | int | 入力パラメータ `db_name` の内部データベース識別子。 |
| `family_guid` | uniqueidentifier | 作成時の元のデータベースの一意の ID。この値は、データベースが復元されても、データベース名が異なっても変わりません。 |
| `rds_backup_seq_id` | int | RDS が各トランザクションログのバックアップファイルのシーケンス番号を保持するために内部で使用する ID。 |
| `backup_file_epoch` | bigint | トランザクションのバックアップファイルが生成されたエポック時間。 |
| `backup_file_time_utc` | datetime | `backup_file_epoch` 値の UTC 時刻変換後の値。 |
| `starting_lsn` | numeric(25,0) | トランザクションログのバックアップファイルの最初または最も古いログレコードのログシーケンス番号。 |
| `ending_lsn` | numeric(25,0) | トランザクションログのバックアップファイルの最後またはその次のログレコードのログシーケンス番号。 |
| `is_log_chain_broken` | bit | 現在のトランザクションログのバックアップファイルと、以前のトランザクションログのバックアップファイル間でログチェーンが壊れているかどうかを示す boolean 値。 |
| `file_size_bytes` | bigint | トランザクションのバックアップセットのサイズ (バイト単位)。 |
| `Error` | varCHAR(4000) | `rds_fn_list_tlog_backup_metadata` 関数が例外をスローした場合のエラーメッセージ。例外がない場合は NULL です。 |
# トランザクションログのバックアップのコピー
個々のデータベースの利用可能なトランザクションログのバックアップセットを Amazon S3 バケットにコピーするには、`rds_tlog_backup_copy_to_S3` ストアドプロシージャを呼び出します。`rds_tlog_backup_copy_to_S3` ストアドプロシージャでは、トランザクションログのバックアップをコピーする新しいタスクを開始します。
**注記**
`rds_tlog_backup_copy_to_S3` ストアドプロシージャでは、`is_log_chain_broken` 属性を検証せずにトランザクションログのバックアップをコピーします。このため、`rds_tlog_backup_copy_to_S3` ストアドプロシージャを実行する前に、ログチェーンが壊れていないことを手動で確認する必要があります。追加の説明については、「[トランザクションログのバックアップログチェーンの検証](#USER.SQLServer.AddlFeat.TransactionLogAccess.Copying.LogChain)」を参照してください。
**Example `rds_tlog_backup_copy_to_S3` ストアドプロシージャの使用例**
```
exec msdb.dbo.rds_tlog_backup_copy_to_S3
@db_name='mydatabasename',
[@kms_key_arn='arn:aws:kms:region:account-id:key/key-id'],
[@backup_file_start_time='2022-09-01 01:00:15'],
[@backup_file_end_time='2022-09-01 21:30:45'],
[@starting_lsn=149000000112100001],
[@ending_lsn=149000000120400001],
[@rds_backup_starting_seq_id=5],
[@rds_backup_ending_seq_id=10];
```
次の入力パラメータが利用可能です。
****
| パラメータ | 説明 |
| --- | --- |
| `@db_name` | トランザクションログのバックアップをコピーするためのデータベース名。 |
| `@kms_key_arn` | カスタマーマネージド KMS キー。AWS マネージド KMS キーで DB インスタンスを暗号化する場合は、カスタマーマネージドキーを作成する必要があります。カスタマーマネージドキーで DB インスタンスを暗号化する場合、同じ KMS キー ARN を使用できます。 |
| `@backup_file_start_time` | `rds_fn_list_tlog_backup_metadata` 関数の `[backup_file_time_utc]` 列から提供された UTC タイムスタンプ。 |
| `@backup_file_end_time` | `rds_fn_list_tlog_backup_metadata` 関数の `[backup_file_time_utc]` 列から提供された UTC タイムスタンプ。 |
| `@starting_lsn` | `rds_fn_list_tlog_backup_metadata` 関数の `[starting_lsn]` 列から提供されたログシーケンス番号 (LSN) |
| `@ending_lsn` | `rds_fn_list_tlog_backup_metadata` 関数の `[ending_lsn]` 列から提供されたログシーケンス番号 (LSN)。 |
| `@rds_backup_starting_seq_id` | `rds_fn_list_tlog_backup_metadata` 関数の `[rds_backup_seq_id]` 列から提供されたシーケンス ID。 |
| `@rds_backup_ending_seq_id` | `rds_fn_list_tlog_backup_metadata` 関数の `[rds_backup_seq_id]` 列から提供されたシーケンス ID。 |
時間、LSN、シーケンス ID のいずれかのパラメータセットを指定できます。必要なパラメータは 1 セットだけです。
また、どのセットでもパラメータを 1 つだけ指定できます。例えば、`backup_file_end_time` パラメータの値のみを指定すると、7 日間の制限内であれば、それ以前に利用可能なすべてのトランザクションログのバックアップファイルが Amazon S3 バケットにコピーされます。
`rds_tlog_backup_copy_to_S3` ストアドプロシージャの有効な入力パラメータの組み合わせは次のとおりです。
****
| 指定されたパラメータ | 予想される結果 |
| --- | --- |
| exec msdb.dbo.rds_tlog_backup_copy_to_S3
@db_name = 'testdb1',
@backup_file_start_time='2022-08-23 00:00:00',
@backup_file_end_time='2022-08-30 00:00:00';
| 過去 7 日間のトランザクションログのバックアップをコピーします。このバックアップは、指定された `backup_file_start_time` から `backup_file_end_time` の範囲に存在します。この例では、ストアドプロシージャは「2022-08-23 00:00:00」から「2022-08-30 00:00:00」の間に生成されたトランザクションログのバックアップをコピーします。 |
| exec msdb.dbo.rds_tlog_backup_copy_to_S3
@db_name = 'testdb1',
@backup_file_start_time='2022-08-23 00:00:00';
| 指定された `backup_file_start_time` を起点として、過去 7 日間のトランザクションログのバックアップをコピーします。この例では、ストアドプロシージャは「2022-08-23 00:00:00」のトランザクションログのバックアップを最新のトランザクションログのバックアップにコピーします。 |
| exec msdb.dbo.rds_tlog_backup_copy_to_S3
@db_name = 'testdb1',
@backup_file_end_time='2022-08-30 00:00:00';
| 指定された `backup_file_end_time` まで、過去 7 日間のトランザクションログのバックアップをコピーします。この例では、ストアドプロシージャは「2022-08-23 00:00:00」から「2022-08-30 00:00:00」までのトランザクションログのバックアップをコピーします。 |
| exec msdb.dbo.rds_tlog_backup_copy_to_S3
@db_name='testdb1',
@starting_lsn =1490000000040007,
@ending_lsn = 1490000000050009;
| 過去 7 日間の利用可能なトランザクションログのバックアップをコピーします。このバックアップは、指定された `starting_lsn` から `ending_lsn` の範囲にあります。この例では、ストアドプロシージャは、LSN 範囲が 1490000000040007 から 1490000000050009 までの過去 7 日間のトランザクションログのバックアップをコピーします。 |
| exec msdb.dbo.rds_tlog_backup_copy_to_S3
@db_name='testdb1',
@starting_lsn =1490000000040007;
| 指定された `starting_lsn` から、過去 7 日間の利用可能なトランザクションログのバックアップをコピーします。この例では、ストアドプロシージャは LSN 1490000000040007 からのトランザクションログのバックアップを最新のトランザクションログのバックアップにコピーします。 |
| exec msdb.dbo.rds_tlog_backup_copy_to_S3
@db_name='testdb1',
@ending_lsn =1490000000050009;
| 指定された `ending_lsn` まで、過去 7 日間の利用可能なトランザクションログのバックアップをコピーします。この例では、ストアドプロシージャは、LSN が 1490000000050009 までの過去 7 日間のトランザクションログのバックアップをコピーします。 |
| exec msdb.dbo.rds_tlog_backup_copy_to_S3
@db_name='testdb1',
@rds_backup_starting_seq_id= 2000,
@rds_backup_ending_seq_id= 5000;
| 過去 7 日間の利用可能なトランザクションログのバックアップをコピーします。このバックアップは、指定された `rds_backup_starting_seq_id` から `rds_backup_ending_seq_id` の範囲に存在します。この例では、ストアドプロシージャは、seq\$1id 2000 から seq\$1id 5000 までの rds バックアップシーケンス ID の範囲内で、過去 7 日間のトランザクションログのバックアップをコピーします。 |
| exec msdb.dbo.rds_tlog_backup_copy_to_S3
@db_name='testdb1',
@rds_backup_starting_seq_id= 2000;
| 指定された `rds_backup_starting_seq_id` から、過去 7 日間の利用可能なトランザクションログのバックアップをコピーします。この例では、ストアドプロシージャは seq\$1id 2000 から始まる最新のトランザクションログのバックアップを最新のトランザクションログのバックアップにコピーします。 |
| exec msdb.dbo.rds_tlog_backup_copy_to_S3
@db_name='testdb1',
@rds_backup_ending_seq_id= 5000;
| 指定された `rds_backup_ending_seq_id` まで、過去 7 日間の利用可能なトランザクションログのバックアップをコピーします。この例では、ストアドプロシージャは、seq\$1id 5000 までの過去 7 日間のトランザクションログのバックアップをコピーします。 |
| exec msdb.dbo.rds_tlog_backup_copy_to_S3
@db_name='testdb1',
@rds_backup_starting_seq_id= 2000;
@rds_backup_ending_seq_id= 2000;
| 過去 7 日以内に利用可能な場合、指定された `rds_backup_starting_seq_id` で 1 つのトランザクションログのバックアップをコピーします。この例では、ストアドプロシージャは、seq\$1id が 2000 の 1 つのトランザクションログのバックアップをコピーします (過去 7 日以内に存在する場合)。 |
## トランザクションログのバックアップログチェーンの検証
トランザクションログのバックアップにアクセスするように設定されたデータベースでは、自動バックアップ保持が有効になっている必要があります。自動バックアップ保持により、DB インスタンスのデータベースが `FULL` 復旧モデルに設定されます。データベースのポイントインタイム復元をサポートするには、データベース復旧モデルを変更しないでください。データベース復旧モデルを変更すると、ログチェーンが壊れる可能性があります。データベースは `FULL` 復旧モデルに設定しておくことをお勧めします。
トランザクションログのバックアップをコピーする前にログチェーンを手動で検証するには、`rds_fn_list_tlog_backup_metadata` 関数を呼び出して `is_log_chain_broken` 列の値を確認します。値が「1」の場合、現在のログのバックアップと前回のログのバックアップの間でログチェーンが壊れていたことを示します。
次の例は、`rds_fn_list_tlog_backup_metadata` ストアドプロシージャからの出力のログチェーンが壊れていることを示しています。
![\[rds_fn_list_tlog_backup_metadata からの出力で、壊れたログチェーンを表示します。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/sql_accesstransactionlogs_logchain_error.png)
通常のログチェーンでは、特定の rds\$1sequence\$1id の first\$1lsn のログシーケンス番号 (LSN) 値は、前の rds\$1sequence\$1id の last\$1lsn の値と一致する必要があります。この図では、rds\$1sequence\$1id が 45 の first\$1lsn の値は 90987 ですが、その前の rds\$1sequence\$1id が 44 の last\$1lsn 値 90985 と一致しません。
SQL Server のトランザクションログアーキテクチャとログシーケンス番号の詳細については、Microsoft SQL Server ドキュメントの「[トランザクションログの論理アーキテクチャ](https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-log-architecture-and-management-guide?view=sql-server-ver15#Logical_Arch)」を参照してください。
# Amazon S3 バケットフォルダおよびファイル構造
Amazon S3 バケット内のトランザクションログのバックアップには、以下の標準構造と命名規則があります。
+ 各データベースの `target_s3_arn` パスの下に、`{db_id}.{family_guid}` という命名構造を持つ新しいフォルダが作成されます。
+ フォルダ内のトランザクションログのバックアップは、`{db_id}.{family_guid}.{rds_backup_seq_id}.{backup_file_epoch}` のようなファイル名構造を持ちます。
+ `rds_fn_list_tlog_backup_metadata` 関数を使用すると、`family_guid,db_id,rds_backup_seq_id and backup_file_epoch` の詳細を表示できます。
以下の例では、Amazon S3 バケット内の一連のトランザクションログのバックアップのフォルダおよびファイル構造を示しています。
![\[Amazon S3 バケット構造とトランザクションログへのアクセス\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/sql_accesstransactionlogs_s3.png)
# タスクのステータスの追跡
コピータスクのステータスを追跡するには、`rds_task_status` ストアドプロシージャを呼び出します。パラメータを何も指定しない場合、ストアドプロシージャによりすべてのタスクのステータスが返されます。
**Example 使用例:**
```
exec msdb.dbo.rds_task_status
@db_name='database_name',
@task_id=ID_number;
```
以下のパラメータはオプションです。
+ `@db_name` – タスクのステータスを表示するデータベースの名前。
+ `@task_id` – タスクのステータスを表示するタスクの ID。
**Example 特定タスク ID のステータスの一覧表示例:**
```
exec msdb.dbo.rds_task_status @task_id=5;
```
**Example 特定データベースおよびタスクのステータスの一覧表示例:**
```
exec msdb.dbo.rds_task_status@db_name='my_database',@task_id=5;
```
**Example 特定データベースのすべてのタスクおよびステータスの一覧表示例:**
```
exec msdb.dbo.rds_task_status @db_name='my_database';
```
**Example 現在の DB インスタンスのすべてのタスクおよびステータスの一覧表示例:**
```
exec msdb.dbo.rds_task_status;
```
# タスクのキャンセル
実行中のタスクをキャンセルするには、`rds_cancel_task` ストアドプロシージャを呼び出します。
**Example 使用例:**
```
exec msdb.dbo.rds_cancel_task @task_id=ID_number;
```
以下のパラメータは必須です。
+ `@task_id` – キャンセルするタスクの ID。`rds_task_status` ストアドプロシージャを呼び出すことにより、タスク ID を表示できます。
実行中のタスクの表示とキャンセルの詳細については、「[ネイティブバックアップと復元を使用した SQL Server データベースのインポートとエクスポート](SQLServer.Procedural.Importing.md)」を参照してください。
# トランザクションログのバックアップへのアクセスについてのトラブルシューティング
トランザクションログのバックアップへのアクセスにストアドプロシージャを使用する場合、次のような問題が発生する場合があります。
****
| ストアドプロシージャ | エラーメッセージ | 問題 | トラブルシューティングの推奨事項 |
| --- | --- | --- | --- |
| rds\$1tlog\$1copy\$1setup | この DB インスタンスでは、バックアップは無効になっています。DB インスタンスのバックアップを「1」以上の保持期間で有効にして、もう一度試してください。 | DB インスタンスの自動バックアップを有効化する。 | DB インスタンスのバックアップの保持期間は、最低でも 1 日以上有効にする必要があります。自動バックアップの有効化バックアップの保持期間の設定の詳細については、「[バックアップの保存期間](USER_WorkingWithAutomatedBackups.BackupRetention.md)」を参照してください。 |
| rds\$1tlog\$1copy\$1setup | rds\$1tlog\$1copy\$1setup ストアドプロシージャの実行中にエラーが発生しました。RDS エンドポイントに再接続して、もう一度試してください。 | 内部エラーが発生しました。 | RDS エンドポイントに再接続し、`rds_tlog_copy_setup` ストアドプロシージャを再実行します。 |
| rds\$1tlog\$1copy\$1setup | rds\$1tlog\$1backup\$1copy\$1setup ストアドプロシージャをトランザクション内で実行することはサポートされていません。セッションに未処理のトランザクションがないことを確認して、もう一度試してください。 | ストアドプロシージャでは、`BEGIN` および `END` を使用してトランザクション内で試行されました。 | `rds_tlog_copy_setup` ストアドプロシージャを実行するときは、`BEGIN` および `END` を使用しないでください。 |
| rds\$1tlog\$1copy\$1setup | 入力パラメータ `@target_s3_arn` の S3 バケット名には、スペース以外の文字が少なくとも 1 文字含まれている必要があります。 | 入力パラメータ `@target_s3_arn` に間違った値が指定されました。 | 入力パラメータ `@target_s3_arn` に完全な Amazon S3 バケット ARN が指定されていることを確認します。 |
| rds\$1tlog\$1copy\$1setup | `SQLSERVER_BACKUP_RESTORE` オプションが有効になっていないか、有効化処理中です。オプションを有効にするか、後でもう一度試してください。 | `SQLSERVER_BACKUP_RESTORE` オプションが DB インスタンスで有効になっていないか、有効化されたばかりで内部アクティベーションが保留されています。 | 要件セクションで指定されている `SQLSERVER_BACKUP_RESTORE` オプションを有効にします。数分間待って、再度 `rds_tlog_copy_setup` ストアドプロシージャを実行してください。 |
| rds\$1tlog\$1copy\$1setup | 入力パラメータ `@target_s3_arn` のターゲット S3 arn を空または null にすることはできません。 | 入力パラメータ `@target_s3_arn` に `NULL` 値が指定されたか、値が指定されませんでした。 | 入力パラメータ `@target_s3_arn` に完全な Amazon S3 バケット ARN が指定されていることを確認します。 |
| rds\$1tlog\$1copy\$1setup | 入力パラメータ `@target_s3_arn` のターゲット S3 arn は、arn:aws で始まる必要があります。 | 入力パラメータ `@target_s3_arn` は、前に `arn:aws` を付けずに指定されました。 | 入力パラメータ `@target_s3_arn` に完全な Amazon S3 バケット ARN が指定されていることを確認します。 |
| rds\$1tlog\$1copy\$1setup | ターゲット S3 ARN は、既に指定された値が設定されています。 | `rds_tlog_copy_setup` ストアドプロシージャは前に実行され、Amazon S3 バケット ARN で設定されていました。 | トランザクションログのバックアップにアクセスするために Amazon S3 バケット値を変更するには、別の `target S3 ARN` を指定します。 |
| rds\$1tlog\$1copy\$1setup | トランザクションログのバックアップへのアクセスを有効にする認証情報を生成できません。`rds_tlog_copy_setup` で指定されている S3 パス ARN を確認し、後でもう一度試してください。 | トランザクションログのバックアップにアクセスするための認証情報の生成中に、不明なエラーが発生しました。 | 設定設定を確認して、もう一度試してください。 |
| rds\$1tlog\$1copy\$1setup | 保留中のタスクがある間は、rds\$1tlog\$1copy\$1setup ストアドプロシージャを実行できません。保留中のタスクが完了するのを待ち、もう一度試してください。 | 一度に実行できるタスクは 2 つだけです。完了を待っている保留中のタスクがあります。 | 保留中のタスクを表示して、完了するのを待ちます。モニタリングタスクのステータスの詳細については、「[タスクのステータスの追跡](USER.SQLServer.AddlFeat.TransactionLogAccess.TrackTaskStatus.md)」をご参照ください。 |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | T-log バックアップファイルコピータスクがデータベース: %s、タスク ID: %d で既に発行されています。後でもう一度試してください。 | 特定のデータベースに対して、同時に実行できるコピータスクは 1 つだけです。完了を待っている保留中のコピータスクがあります。 | 保留中のタスクを表示して、完了するのを待ちます。モニタリングタスクのステータスの詳細については、「[タスクのステータスの追跡](USER.SQLServer.AddlFeat.TransactionLogAccess.TrackTaskStatus.md)」をご参照ください。 |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | これらの 3 セットのパラメータセットのうち、少なくとも 1 セットを指定する必要があります。SET-1:(@backup\$1file\$1start\$1time、@backup\$1file\$1end\$1time) \$1 SET-2:(@starting\$1lsn、@ending\$1lsn) \$1 SET-3:(@rds\$1backup\$1starting\$1seq\$1id、@rds\$1backup\$1ending\$1seq\$1id) | 3 セットのパラメータセットのいずれも指定されていないか、指定されたパラメータセットに必要なパラメータが不足しています。 | 時間、lsn、シーケンス ID のいずれかのパラメータを指定できます。これら 3 セットのパラメータのうち 1 セットが必要です。必要なパラメータの詳細については、「[トランザクションログのバックアップのコピー](USER.SQLServer.AddlFeat.TransactionLogAccess.Copying.md)」を参照してください。 |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | インスタンスでは、バックアップは無効になっています。バックアップを有効にして、しばらくしてからもう一度試してください。 | DB インスタンスの自動バックアップを有効化する。 | 自動バックアップの有効化バックアップの保持期間の設定の詳細については、「[バックアップの保存期間](USER_WorkingWithAutomatedBackups.BackupRetention.md)」を参照してください。 |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | 指定されたデータベース %s が見つかりません。 | 入力パラメータ `@db_name` に指定された値が DB インスタンスのデータベース名と一致しません。 | 正しいデータベース名を使用してください。すべてのデータベースを名前で一覧表示するには、`SELECT * from sys.databases` を実行します。 |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | SQL Server システムデータベースまたは rdsadmin データベースの RDS\$1TLOG\$1Backup\$1copy\$1to\$1S3 ストアドプロシージャを実行できません。 | 入力パラメータ `@db_name` として指定された値は、SQL Server システムデータベース名または RDSAdmin データベースと一致します。 | データベース `master, model, msdb, tempdb, RDSAdmin.` は、トランザクションログバックアップへのアクセスには使用できません。 |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | 入力パラメータ @db\$1name のデータベース名を空または null にすることはできません。 | 入力パラメータ `@db_name` に空または `NULL` の値が指定されました。 | 正しいデータベース名を使用してください。すべてのデータベースを名前で一覧表示するには、`SELECT * from sys.databases` を実行します。 |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | rds\$1tlog\$1backup\$1copy\$1setup ストアドプロシージャを実行するには、DB インスタンスのバックアップ保持期間を少なくとも 1 に設定する必要があります。 | DB インスタンスの自動バックアップを有効化する。 | 自動バックアップの有効化バックアップの保持期間の設定の詳細については、「[バックアップの保存期間](USER_WorkingWithAutomatedBackups.BackupRetention.md)」を参照してください。 |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | ストアドプロシージャ rds\$1tlog\$1backup\$1copy\$1to\$1S3 の実行中にエラーが発生しました。RDS エンドポイントに再接続して、もう一度試してください。 | 内部エラーが発生しました。 | RDS エンドポイントに再接続し、`rds_tlog_backup_copy_to_S3` ストアドプロシージャを再実行します。 |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | これらの 3 セットのパラメータセットのうち、1 セットのみ指定できます。SET-1:(@backup\$1file\$1start\$1time、@backup\$1file\$1end\$1time) \$1 SET-2:(@starting\$1lsn、@ending\$1lsn) \$1 SET-3:(@rds\$1backup\$1starting\$1seq\$1id、@rds\$1backup\$1ending\$1seq\$1id) | 複数のパラメータセットが指定されました。 | 時間、lsn、シーケンス ID のいずれかのパラメータを指定できます。これら 3 セットのパラメータのうち 1 セットが必要です。必要なパラメータの詳細については、「[トランザクションログのバックアップのコピー](USER.SQLServer.AddlFeat.TransactionLogAccess.Copying.md)」を参照してください。 |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | rds\$1tlog\$1backup\$1copy\$1to\$1S3 ストアドプロシージャをトランザクション内で実行することはサポートされていません。セッションに未処理のトランザクションがないことを確認して、もう一度試してください。 | ストアドプロシージャでは、`BEGIN` および `END` を使用してトランザクション内で試行されました。 | `rds_tlog_backup_copy_to_S3` ストアドプロシージャを実行するときは、`BEGIN` および `END` を使用しないでください。 |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | 指定されたパラメータは、トランザクションバックアップログの保持期間外です。使用可能なトランザクションログのバックアップファイルを一覧表示するには、rds\$1fn\$1list\$1tlog\$1backup\$1metadata 関数を実行します。 | 指定された入力パラメータで、コピー保持期間内で該当するトランザクションのログバックアップはありませんでした。 | 有効なパラメータセットを使用してもう一度試してください。必要なパラメータの詳細については、「[トランザクションログのバックアップのコピー](USER.SQLServer.AddlFeat.TransactionLogAccess.Copying.md)」を参照してください。 |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | リクエストの処理中にアクセス許可エラーがありました。バケットが DB インスタンスと同じアカウントとリージョンにあることを確認し、公開ドキュメントのテンプレートに対する S3 バケットポリシーのアクセス許可を確認してください。 | 指定された S3 バケットまたはそのポリシーのアクセス許可で問題が検出されました。 | トランザクションログのバックアップにアクセスするための設定が正しいことを確認します。S3 バケットの設定要件の詳細については、「[要件](USER.SQLServer.AddlFeat.TransactionLogAccess.md#USER.SQLServer.AddlFeat.TransactionLogAccess.Requirements)」を参照してください。 |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | RDS リードレプリカインスタンスで `rds_tlog_backup_copy_to_S3` ストアドプロシージャを実行することは許可されていません。 | RDS リードレプリカインスタンスでストアドプロシージャが試行されました。 | RDS プライマリ DB インスタンスに接続して、`rds_tlog_backup_copy_to_S3` ストアドプロシージャを実行します。 |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | 入力パラメータ `@starting_lsn` の LSN は `@ending_lsn` 未満である必要があります。 | 入力パラメータ `@starting_lsn` に指定された値が、入力パラメータ `@ending_lsn` に指定された値より大きい。 | 入力パラメータ `@starting_lsn` に指定された値が、入力パラメータ `@ending_lsn` に指定された値より小さいことを確認してください。 |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | `rds_tlog_backup_copy_to_S3` ストアドプロシージャは、ソースデータベース内の `db_owner` ロールのメンバーのみが実行できます。 | 指定された `db_name` で `rds_tlog_backup_copy_to_S3` ストアドプロシージャを実行しようとしているアカウントには、`db_owner` ロールが付与されていません。 | ストアドプロシージャを実行しているアカウントに、指定された `db_name` の `db_owner` ロールが付与されていることを確認してください。 |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | 入力パラメータ `@rds_backup_starting_seq_id` のシーケンス ID は、`@rds_backup_ending_seq_id` 以下である必要があります。 | 入力パラメータ `@rds_backup_starting_seq_id` に指定された値が、入力パラメータ `@rds_backup_ending_seq_id` に指定された値より大きい。 | 入力パラメータ `@rds_backup_starting_seq_id` に指定された値が、入力パラメータ `@rds_backup_ending_seq_id` に指定された値より小さいことを確認してください。 |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | SQLSERVER\$1BACKUP\$1RESTORE オプションが有効になっていないか、有効化処理中です。オプションを有効にするか、後でもう一度試してください。 | `SQLSERVER_BACKUP_RESTORE` オプションが DB インスタンスで有効になっていないか、有効化されたばかりで内部アクティベーションが保留されています。 | 要件セクションで指定されている `SQLSERVER_BACKUP_RESTORE` オプションを有効にします。数分間待って、再度 `rds_tlog_backup_copy_to_S3` ストアドプロシージャを実行してください。 |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | 入力パラメータ `@backup_file_start_time` の開始時刻は `@backup_file_end_time` より早い必要があります。 | 入力パラメータ `@backup_file_start_time` に指定された値が、入力パラメータ `@backup_file_end_time` に指定された値より遅い。 | 入力パラメータ `@backup_file_start_time` に指定された値が、入力パラメータ `@backup_file_end_time` に指定された値より小さいことを確認してください。 |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | アクセスできないため、リクエストを処理できませんでした。機能の設定とアクセス許可を確認してください。 | Amazon S3 バケットのアクセス許可に問題があるか、指定された Amazon S3 バケットが別のアカウントまたはリージョンにある可能性があります。 | Amazon S3 バケットポリシーのアクセス許可が、RDS のアクセスを許可するように設定されていることを確認してください。Amazon S3 バケットが DB インスタンスと同じアカウントとリージョンにあることを確認してください。 |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | ストレージが暗号化されていないインスタンスのストアドプロシージャへの入力パラメータとして、KMS Key ARN は指定できません。 | DB インスタンスでストレージ暗号化が有効化されていない場合は、入力パラメータ `@kms_key_arn` を指定しないでください。 | `@kms_key_arn` の入力パラメータは指定しないでください。 |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | ストレージ暗号化インスタンスのストアドプロシージャへの入力パラメータとして、KMS キー ARN を指定する必要があります。 | DB インスタンスでストレージ暗号化が有効化されている場合は、入力パラメータ `@kms_key_arn` を指定する必要があります。 | `@kms_key_arn` の入力パラメータに、トランザクションログのバックアップに使用する Amazon S3 バケットの ARN と一致する値を指定します。 |
| rds\$1tlog\$1backup\$1copy\$1to\$1S3 | `rds_tlog_backup_copy_to_S3` ストアドプロシージャを実行する前に、`rds_tlog_copy_setup` ストアドプロシージャを実行して、`@target_s3_arn` を設定する必要があります。 | `rds_tlog_backup_copy_to_S3` ストアドプロシージャの実行を試行する前に、トランザクションログのバックアップへのアクセスのセットアップ手順が完了しませんでした。 | `rds_tlog_backup_copy_to_S3` ストアドプロシージャを実行する前に、`rds_tlog_copy_setup` ストアドプロシージャを実行してください。トランザクションログのバックアップにアクセスするためのセットアップ手順の実行の詳細については、「[トランザクションログのバックアップへのアクセス設定](USER.SQLServer.AddlFeat.TransactionLogAccess.Enabling.md)」を参照してください。 |
# Microsoft SQL Server データベースエンジンのオプション
このセクションでは、Microsoft SQL Server DB エンジンを実行する Amazon RDS インスタンスに使用できるオプションについて説明します。これらのオプションを有効にするには、オプショングループに追加してから、そのオプショングループを DB インスタンスに関連付けます。詳細については、「[オプショングループを使用する](USER_WorkingWithOptionGroups.md)」を参照してください。
RDS オプショングループを介して追加されないオプション機能 (SSL、Microsoft Windows 認証、Amazon S3 統合など) を必要とする場合は、「[Amazon RDS での Microsoft SQL Server の追加機能](User.SQLServer.AdditionalFeatures.md)」を参照してください。
Amazon RDS では、Microsoft SQL Server DB インスタンスの以下のオプションがサポートされています。
****
| オプション | オプション ID | エンジンのエディション |
| --- | --- | --- |
| [Oracle OLEDB とリンクされたサーバー](Appendix.SQLServer.Options.LinkedServers_Oracle_OLEDB.md) | `OLEDB_ORACLE` | SQL Server Enterprise Edition SQL Server Standard Edition |
| [ネイティブバックアップおよび復元](Appendix.SQLServer.Options.BackupRestore.md) | `SQLSERVER_BACKUP_RESTORE` | SQL Server Enterprise Edition SQL Server Standard Edition SQL Server Web Edition SQL Server Express Edition |
| [透過的なデータ暗号化](Appendix.SQLServer.Options.TDE.md) | `TRANSPARENT_DATA_ENCRYPTION` (RDS コンソール) `TDE` (AWS CLI と RDS API) | SQL Server 2016–2022 Enterprise Edition SQL Server 2022 Standard Edition |
| [SQL Server Audit](Appendix.SQLServer.Options.Audit.md) | `SQLSERVER_AUDIT` | RDS では、SQL Server 2016 以降、SQL Server のすべてのエディションでサーバーレベルの監査がサポートされており、Enterprise Edition でもデータベースレベルの監査がサポートされています。 SQL Server SQL Server 2016 (13.x) SP1 以降では、すべてのエディションでサーバーレベルとデータベースレベルの両方の監査がサポートされています。 詳細については、SQL Server ドキュメントの「[SQL Server Audit (database engine)](https://docs.microsoft.com/sql/relational-databases/security/auditing/sql-server-audit-database-engine?view=sql-server-2017)」を参照してください。 |
| [SQL Server Analysis Services](Appendix.SQLServer.Options.SSAS.md) | `SSAS` | SQL Server Enterprise Edition SQL Server Standard Edition |
| [SQL Server Integration Services](Appendix.SQLServer.Options.SSIS.md) | `SSIS` | SQL Server Enterprise Edition SQL Server Standard Edition |
| [SQL Server Reporting Services](Appendix.SQLServer.Options.SSRS.md) | `SSRS` | SQL Server Enterprise Edition SQL Server Standard Edition |
| [Microsoft 分散トランザクションコーディネーター](Appendix.SQLServer.Options.MSDTC.md) | `MSDTC` | RDS では、SQL Server 2016 以降、SQL Server のすべてのエディションで分散トランザクションがサポートされています。 |
| [SQL Server リソースガバナー](Appendix.SQLServer.Options.ResourceGovernor.md) | `RESOURCE_GOVERNOR` | SQL Server Enterprise Edition SQL Server 2022 Developer Edition |
## SQL Server のバージョンとエディションで使用できるオプションの一覧表示
`describe-option-group-options` AWS CLI コマンドを使用して、SQL Server のバージョンとエディションで使用可能なオプション、およびそれらのオプションの設定を一覧表示できます。
次の例は、SQL Server 2019 Enterprise Edition のオプションとオプションの設定を示しています。`--engine-name` オプションは必須です。
```
aws rds describe-option-group-options --engine-name sqlserver-ee --major-engine-version 15.00
```
出力は次のようになります。
```
{
"OptionGroupOptions": [
{
"Name": "MSDTC",
"Description": "Microsoft Distributed Transaction Coordinator",
"EngineName": "sqlserver-ee",
"MajorEngineVersion": "15.00",
"MinimumRequiredMinorEngineVersion": "4043.16.v1",
"PortRequired": true,
"DefaultPort": 5000,
"OptionsDependedOn": [],
"OptionsConflictsWith": [],
"Persistent": false,
"Permanent": false,
"RequiresAutoMinorEngineVersionUpgrade": false,
"VpcOnly": false,
"OptionGroupOptionSettings": [
{
"SettingName": "ENABLE_SNA_LU",
"SettingDescription": "Enable support for SNA LU protocol",
"DefaultValue": "true",
"ApplyType": "DYNAMIC",
"AllowedValues": "true,false",
"IsModifiable": true,
"IsRequired": false,
"MinimumEngineVersionPerAllowedValue": []
},
...
{
"Name": "TDE",
"Description": "SQL Server - Transparent Data Encryption",
"EngineName": "sqlserver-ee",
"MajorEngineVersion": "15.00",
"MinimumRequiredMinorEngineVersion": "4043.16.v1",
"PortRequired": false,
"OptionsDependedOn": [],
"OptionsConflictsWith": [],
"Persistent": true,
"Permanent": false,
"RequiresAutoMinorEngineVersionUpgrade": false,
"VpcOnly": false,
"OptionGroupOptionSettings": []
}
]
}
```
# Amazon RDS for SQL Server での Oracle OLEDB によるリンクされたサーバーのサポート
RDS for SQL Server 上の Oracle Provider for OLEDB とリンクされたサーバーを使用すると、Oracle データベース上の外部データソースにアクセスできます。リモート Oracle データソースからデータを読み取り、RDS for SQL Server DB インスタンスの外部にあるリモート Oracle データベースサーバーに対してコマンドを実行できます。Oracle OLEDB とリンクされたサーバーを使用すると、次のことが可能になります。
+ SQL Server 以外のデータソースに直接アクセスする
+ データを移動することなく、同じクエリでさまざまな Oracle データソースに対してクエリを実行する
+ エンタープライズエコシステム全体のデータソースに対して分散クエリ、更新、コマンド、トランザクションを発行する
+ Microsoft ビジネスインテリジェンススイート (SSIS、SSRS、SSAS) 内から Oracle データベースへの接続を統合する
+ Oracle データベースから RDS for SQL サーバーに移行
既存または新しい RDS for SQL Server DB インスタンスで、Oracle 用の 1 つ以上のリンクされたサーバーをアクティブ化できます。その後、外部の Oracle データソースを DB インスタンスと統合できます。
**Contents**
+ [サポート対象のバージョンとリージョン](#LinkedServers_Oracle_OLEDB.VersionRegionSupport)
+ [制限と推奨事項](#LinkedServers_Oracle_OLEDB.Limitations)
+ [Oracle とリンクされたサーバーのアクティベーション](#LinkedServers_Oracle_OLEDB.Enabling)
+ [OLEDB\$1ORACLE のオプショングループの作成](#LinkedServers_Oracle_OLEDB.OptionGroup)
+ [`OLEDB_ORACLE` オプションのオプショングループへの追加](#LinkedServers_Oracle_OLEDB.Add)
+ [`OLEDB_ORACLE` バージョンオプションを別のバージョンに変更する](#LinkedServers_Oracle_OLEDB.Modify)
+ [オプショングループを DB インスタンスに関連付ける](#LinkedServers_Oracle_OLEDB.Apply)
+ [OLEDB プロバイダーのプロパティの変更](#LinkedServers_Oracle_OLEDB.ModifyProviderProperties)
+ [OLEDB ドライバープロパティの変更](#LinkedServers_Oracle_OLEDB.ModifyDriverProperties)
+ [Oracle とリンクされたサーバーの非アクティブ化](#LinkedServers_Oracle_OLEDB.Disable)
## サポート対象のバージョンとリージョン
RDS for SQL Server は、すべてのリージョンで、SQL Server Standard と Enterprise エディションの次のバージョンについて Oracle OLEDB とリンクしたサーバーをサポートします。
+ SQL Server 2022、すべてのバージョン
+ SQL Server 2019、すべてのバージョン
+ SQL Server 2017、すべてのバージョン
Oracle OLEDB とリンクされたサーバーは、以下の Oracle Database バージョンでサポートされています。
+ Oracle Database 21c、すべてのバージョン
+ Oracle Database 19c、すべてのバージョン
+ Oracle Database 18c、すべてのバージョン
Oracle OLEDB とリンクされたサーバーは、以下の OLEDB Oracle ドライバーバージョンでサポートされています。
+ 21.7
+ 21.16
## 制限と推奨事項
Oracle OLEDB とリンクされたサーバーに適用される次の制約事項および推奨事項に注意してください。
+ 各 RDS for SQL Server DB インスタンスのセキュリティグループに適切な TCP ポートを追加して、ネットワークトラフィックを許可します。例えば、EC2 Oracle DB インスタンスと RDS for SQL Server DB インスタンスの間にリンクされたサーバーを設定する場合、EC2 Oracle DB インスタンスの IP アドレスからのトラフィックを許可する必要があります。また、SQL Server がデータベース通信をリッスンするために使用しているポートでのトラフィックを許可する必要があります。セキュリティグループの詳細については、「[セキュリティグループによるアクセス制御](Overview.RDSSecurityGroups.md)」を参照してください。
+ オプショングループの `OLEDB_ORACLE` オプションをオン、オフ、または変更した後、RDS for SQL Server DB インスタンスを再起動します。オプショングループのステータスにはこれらのイベントに `pending_reboot` が表示され、必須です。常時オプションやミラーリングオプションが有効になっている RDS for SQL Server のマルチ AZ インスタンスの場合、インスタンスの新規作成後または復元後にインスタンスを再起動すると、フェイルオーバーが予想されます。
+ Oracle データソースのユーザー名とパスワードによる簡易認証のみをサポートします。
+ Open Database Connectivity (ODBC) ドライバーはサポートされていません。上記の OLEDB ドライバーバージョンのみがサポートされています。
+ 分散トランザクション (XA) はサポートされています。分散トランザクションを有効にするには、DB インスタンスのオプショングループで `MSDTC` オプションを有効にし、XA トランザクションが有効になっていることを確認します。詳細については、「[RDS for SQL Server での Microsoft 分散トランザクションコーディネーターのサポート](Appendix.SQLServer.Options.MSDTC.md)」を参照してください。
+ 接続文字列のショートカットとして使用するデータソース名 (DSN) の作成はサポートされていません。
+ OLEDB ドライバーのトレースはサポートされていません。SQL Server 拡張イベントを使用して OLEDB イベントをトレースできます。詳細については、「[RDS for SQL Server で拡張イベントを設定する](https://aws.amazon.com/blogs/database/set-up-extended-events-in-amazon-rds-for-sql-server/)」を参照してください。
+ SQL Server Management Studio (SSMS) を使用して Oracle リンクサーバーのカタログフォルダにアクセスすることはサポートされていません。
## Oracle とリンクされたサーバーのアクティベーション
RDS for SQL Server DB インスタンスに `OLEDB_ORACLE` オプションを追加して、Oracle とリンクされたサーバーを有効にします。以下のプロセスを使用します。
1. 新しいオプショングループを作成するか、既存のオプショングループを選択します。
1. オプショングループに [`OLEDB_ORACLE`] オプションを追加します。
1. 使用する OLEDB ドライバーのバージョンを選択します。
1. オプショングループを DB インスタンスに関連付けます。
1. DB インスタンスを再起動します。
### OLEDB\$1ORACLE のオプショングループの作成
Oracle とリンクされたサーバーを使用するには、使用する DB インスタンスの SQL Server のエディションとバージョンに対応するオプショングループを作成または変更します。この手順を完了するには、AWS マネジメントコンソール または AWS CLI を使用してください。
#### コンソール
次の手順では、SQL Server Standard Edition 2019 のオプショングループを作成します。
**オプショングループを作成するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. **[Create group]** (グループの作成) を選択します。
1. [**Create subnet group**(オプショングループの作成)] ウィンドウで以下を行います。
1. [**名前**] に、AWS アカウント内で一意のオプショングループ名 (**oracle-oledb-se-2019** など) を入力します。名前には、英字、数字、ハイフンのみを使用できます。
1. [**説明**] に、オプショングループの簡単な説明 (**OLEDB\$1ORACLE option group for SQL Server SE 2019** など) を入力します。この説明は表示用に使用されます。
1. [**エンジン**] で [**sqlserver-se**] を選択します。
1. **[Major engine version]** (メジャーエンジンのバージョン) で、**[15.00]** を選択します。
1. **[作成]** を選択します。
#### CLI
次の手順では、SQL Server Standard Edition 2019 のオプショングループを作成します。
**オプショングループを作成するには**
+ 以下のいずれかのコマンドを実行します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds create-option-group \
--option-group-name oracle-oledb-se-2019 \
--engine-name sqlserver-se \
--major-engine-version 15.00 \
--option-group-description "OLEDB_ORACLE option group for SQL Server SE 2019"
```
Windows の場合:
```
aws rds create-option-group ^
--option-group-name oracle-oledb-se-2019 ^
--engine-name sqlserver-se ^
--major-engine-version 15.00 ^
--option-group-description "OLEDB_ORACLE option group for SQL Server SE 2019"
```
### `OLEDB_ORACLE` オプションのオプショングループへの追加
次に、AWS マネジメントコンソール または AWS CLI を使用して `OLEDB_ORACLE` オプションをオプショングループに追加します。
#### コンソール
**OLEDB\$1ORACLE オプションを追加するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. 作成したオプショングループ (この例では **oracle-oledb-se-2019**) を選択します。
1. **[オプションの追加]** を選択します。
1. **[Option details]** (オプションの詳細) で、**[Option name]** (オプション名) として **[OLEDB\$1ORACLE]** を選択します。
1. **Version** で、インストールする OLEDB Oracle ドライバーのバージョンを選択します。
1. **[スケジュール]** で、オプションをすぐに追加するか、次のメンテナンスウィンドウで追加するかを選択します。
1. **[オプションを追加]** を選択します。
#### CLI
**OLEDB\$1ORACLE オプションを追加するには**
+ オプショングループに [`OLEDB_ORACLE`] オプションを追加します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds add-option-to-option-group \
--option-group-name oracle-oledb-se-2019 \
--options OptionName=OLEDB_ORACLE, OptionVersion=21.16 \
--apply-immediately
```
Windows の場合:
```
aws rds add-option-to-option-group ^
--option-group-name oracle-oledb-se-2019 ^
--options OptionName=OLEDB_ORACLE, OptionVersion=21.16 ^
--apply-immediately
```
### `OLEDB_ORACLE` バージョンオプションを別のバージョンに変更する
`OLEDB_ORACLE` オプションバージョンを別のバージョンに変更するには、AWS マネジメントコンソール または AWS CLI を使用します。
#### コンソール
**OLEDB\$1ORACLE オプションを変更するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. `OLEDB_ORACLE` オプションが含まれているオプショングループ (前の例では **oracle-oledb-se-2019**) を選択します。
1. **[Modify option]** (オプションの変更) を選択します。
1. **[Option details]** (オプションの詳細) で、**[Option name]** (オプション名) として **[OLEDB\$1ORACLE]** を選択します。
1. **[バージョン]** で、使用する OLEDB Oracle ドライバーのバージョンを選択します。
1. **[スケジュール]** で、オプションをすぐに変更するか、次のメンテナンスウィンドウで追加するかを選択します。
1. **[Modify option]** (オプションの変更) を選択します。
#### CLI
`OLEDB_ORACLE` オプションバージョンを変更するには、使用するオプショングループおよびオプションバージョンを指定して、[https://docs.aws.amazon.com/cli/latest/reference/rds/add-option-to-option-group.html](https://docs.aws.amazon.com/cli/latest/reference/rds/add-option-to-option-group.html) AWS CLI コマンドを使用します。
**OLEDB\$1ORACLE オプションを変更するには**
+
**Example**
Linux、macOS、Unix の場合:
```
aws rds add-option-to-option-group \
--option-group-name oracle-oledb-se-2019 \
--options OptionName=OLEDB_ORACLE, OptionVersion=21.7 \
--apply-immediately
```
Windows の場合:
```
aws rds add-option-to-option-group ^
--option-group-name oracle-oledb-se-2019 ^
--options OptionName=OLEDB_ORACLE, OptionVersion=21.7 ^
--apply-immediately
```
### オプショングループを DB インスタンスに関連付ける
`OLEDB_ORACLE` オプショングループおよびパラメータグループを DB インスタンスに関連付けるには、AWS マネジメントコンソールまたは AWS CLI を使用します。
#### コンソール
Oracle のリンクされたサーバーの有効化を完了するには、`OLEDB_ORACLE` オプショングループを新規または既存の DB インスタンスに関連付けます。
+ 新しい DB インスタンスの場合は、インスタンスを起動するときにそれらを関連付けます。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の DB インスタンスの場合は、インスタンスを変更することでそれらを関連付けます。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
#### CLI
`OLEDB_ORACLE` オプショングループおよびパラメータグループを新規または既存の DB インスタンスに関連付けることができます。
**`OLEDB_ORACLE` オプショングループおよびパラメータグループを使用してインスタンスを作成するには**
+ オプショングループの作成時に使用したのと同じ DB エンジンのタイプとメジャーバージョンを指定します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds create-db-instance \
--db-instance-identifier mytestsqlserveroracleoledbinstance \
--db-instance-class db.m5.2xlarge \
--engine sqlserver-se \
--engine-version 15.0.4236.7.v1 \
--allocated-storage 100 \
--manage-master-user-password \
--master-username admin \
--storage-type gp2 \
--license-model li \
--domain-iam-role-name my-directory-iam-role \
--domain my-domain-id \
--option-group-name oracle-oledb-se-2019 \
--db-parameter-group-name my-parameter-group-name
```
Windows の場合:
```
aws rds create-db-instance ^
--db-instance-identifier mytestsqlserveroracleoledbinstance ^
--db-instance-class db.m5.2xlarge ^
--engine sqlserver-se ^
--engine-version 15.0.4236.7.v1 ^
--allocated-storage 100 ^
--manage-master-user-password ^
--master-username admin ^
--storage-type gp2 ^
--license-model li ^
--domain-iam-role-name my-directory-iam-role ^
--domain my-domain-id ^
--option-group-name oracle-oledb-se-2019 ^
--db-parameter-group-name my-parameter-group-name
```
**インスタンスを変更して `OLEDB_ORACLE` オプショングループを関連付けるには**
+ 以下のいずれかのコマンドを実行します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance \
--db-instance-identifier mytestsqlserveroracleoledbinstance \
--option-group-name oracle-oledb-se-2019 \
--db-parameter-group-name my-parameter-group-name \
--apply-immediately
```
Windows の場合:
```
aws rds modify-db-instance ^
--db-instance-identifier mytestsqlserveroracleoledbinstance ^
--option-group-name oracle-oledb-se-2019 ^
--db-parameter-group-name my-parameter-group-name ^
--apply-immediately
```
## OLEDB プロバイダーのプロパティの変更
OLEDB プロバイダーのプロパティを表示および変更することができます。`master` ユーザーのみが、このタスクを実行できます。DB インスタンス上に作成された Oracle のリンクされたサーバーはすべて、その OLEDB プロバイダーの同じプロパティを使用します。`sp_MSset_oledb_prop` ストアドプロシージャを呼び出して、OLEDB プロバイダーのプロパティを変更します。
OLEDB プロバイダーのプロパティを変更するには
```
USE [master]
GO
EXEC sp_MSset_oledb_prop N'OraOLEDB.Oracle', N'AllowInProcess', 1
EXEC sp_MSset_oledb_prop N'OraOLEDB.Oracle', N'DynamicParameters', 0
GO
```
次のプロパティを変更できます。
****
| プロパティ名 | 推奨値 (1 = オン、0 = オフ) | Description |
| --- | --- | --- |
| `Dynamic parameter` | 1 | パラメータ化されたクエリで SQL プレースホルダー ('?' で表されます) を許可します。 |
| `Nested queries` | 1 | サブクエリなど、`FROM` 句内のネストされた `SELECT` ステートメントを許可します。 |
| `Level zero only` | 0 | プロバイダーに対して呼び出されるのは、ベースレベルの OLEDB インターフェイスだけです。 |
| `Allow inprocess` | 1 | Microsoft SQL Server を有効にすると、プロバイダーをインプロセスサーバーとしてインスタンス化できます。Oracle リンクサーバーを使用するには、このプロパティを 1 に設定します。 |
| `Non transacted updates` | 0 | 0 以外の場合、SQL Server は更新を許可します。 |
| `Index as access path` | 誤 | 0 以外の場合、SQL Server はプロバイダーのインデックスを使用してデータを取得しようとします。 |
| `Disallow adhoc access` | 誤 | 設定すると、SQL Server は OLEDB プロバイダーに対するパススルークエリの実行を許可しません。このオプションはチェックできますが、パススルークエリを実行するのが適切な場合もあります。 |
| `Supports LIKE operator` | 1 | プロバイダーが LIKE キーワードを使用したクエリをサポートしていることを示します。 |
## OLEDB ドライバープロパティの変更
Oracle にリンクされたサーバーを作成するとき、OLEDB ドライバーのプロパティを表示および変更できます。`master` ユーザーのみが、このタスクを実行できます。[Driver] (ドライバー) プロパティは、リモート Oracle データソースを使用するときに OLEDB ドライバーがデータを処理する方法を定義します。[Driver] (ドライバー) プロパティは、DB インスタンスで作成された各 Oracle リンクサーバーに固有です。`master.dbo.sp_addlinkedserver` ストアドプロシージャを呼び出して、OLEDB プロバイダーのプロパティを変更します。
例: リンクされたサーバーを作成して OLEDB ドライバー `FetchSize` プロパティを変更するには
```
EXEC master.dbo.sp_addlinkedserver
@server = N'Oracle_link2',
@srvproduct=N'Oracle',
@provider=N'OraOLEDB.Oracle',
@datasrc=N'my-oracle-test.cnetsipka.us-west-2.rds.amazonaws.com:1521/ORCL',
@provstr='FetchSize=200'
GO
```
```
EXEC master.dbo.sp_addlinkedsrvlogin
@rmtsrvname=N'Oracle_link2',
@useself=N'False',
@locallogin=NULL,
@rmtuser=N'master',
@rmtpassword='Test#1234'
GO
```
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
## Oracle とリンクされたサーバーの非アクティブ化
Oracle でリンクされた Server を無効にするには、オプショングループから `OLEDB_ORACLE` オプションを削除します。
**重要**
このオプションを削除しても、DB インスタンス上の既存のリンクされたサーバー設定は削除されません。DB インスタンスから削除するには、手動で削除する必要があります。
削除後に `OLEDB_ORACLE` オプションを再度有効にすると、DB インスタンスで以前に設定したリンクされたサーバー設定を再利用できます。
### コンソール
以下の手順では、`OLEDB_ORACLE` オプションを削除します。
**OLEDB\$1ORACLE オプションをオプショングループから削除するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. `OLEDB_ORACLE` オプションが含まれているオプショングループ (前の例では `oracle-oledb-se-2019`) を選択します。
1. **[オプションを削除]** を選択します。
1. **[Deletion options]** (オプションの削除) で、**[Options to delete]** (削除するオプション) として **[OLEDB\$1ORACLE]** を選択します。
1. **[Apply immediately]** (すぐに適用) で、オプションをすぐに削除する場合は **[Yes]** (はい) を選択し、次のメンテナンスウィンドウで削除する場合は **[No]** (いいえ) を選択します。
1. **[削除]** を選択します。
### CLI
以下の手順では、`OLEDB_ORACLE` オプションを削除します。
**OLEDB\$1ORACLE オプションをオプショングループから削除するには**
+ 以下のいずれかのコマンドを実行します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds remove-option-from-option-group \
--option-group-name oracle-oledb-se-2019 \
--options OLEDB_ORACLE \
--apply-immediately
```
Windows の場合:
```
aws rds remove-option-from-option-group ^
--option-group-name oracle-oledb-se-2019 ^
--options OLEDB_ORACLE ^
--apply-immediately
```
# RDS for SQL Server での Teradata ODBC を使用したリンクサーバー
RDS for SQL Server での Teradata ODBC ドライバーを使用したリンクサーバーのサポートにより、Teradata データベース上の外部データソースにアクセスできます。RDS for SQL Server インスタンスの外部にあるリモート Teradata データベースサーバーからデータを読み取ってコマンドを実行できます。Teradata ODBC を使用したリンクサーバーを使用すると、次の機能が有効になります。
+ SQL Server 以外のデータソースに直接アクセスする。
+ データを移動することなく、同じクエリでさまざまな Teradata データソースに対してクエリを実行する。
+ エンタープライズエコシステム全体のデータソースに対して分散クエリ、更新、コマンド、トランザクションを発行する。
+ Microsoft ビジネスインテリジェンススイート (SSIS、SSRS、SSAS) 内から Teradata データベースへの接続を統合する。
+ Teradata データベースから RDS for SQL Server に移行する。
既存の RDS for SQL Server DB インスタンスまたは新しい RDS for SQL Server DB インスタンスで、Teradata 用のリンクサーバーを 1 つ以上アクティブ化できます。その後、外部の Teradata データソースを DB インスタンスと統合できます。
**Topics**
+ [サポート対象のバージョンとリージョン](#USER_SQLServerTeradata.VersionRegionSupport)
+ [制限と推奨事項](#USER_SQLServerTeradata.LimitsandRecommendations)
+ [マルチ AZ 配置に関する考慮事項](#USER_SQLServerTeradata.MultiAZ)
+ [Teradata とのリンクサーバーのアクティブ化](USER_SQLServerTeradata.Activate.md)
+ [Teradata とのリンクサーバーの作成](USER_SQLServerTeradata.CreateLinkedServers.md)
+ [Teradata にリンクされたサーバーの非アクティブ化](USER_SQLServerTeradata.Deactivate.md)
## サポート対象のバージョンとリージョン
RDS for SQL Server は、すべての AWS リージョンで、SQL Server Standard Edition と SQL Server Enterprise Edition の次のバージョンについて Teradata ODBC を使用したリンクサーバーをサポートしています。
+ SQL Server 2022、すべてのバージョン
+ SQL Server 2019、すべてのバージョン
+ SQL Server 2017、すべてのバージョン
次の Teradata データベースバージョンは、RDS for SQL Server とのリンクをサポートしています。
+ Teradata 17.20、すべてのバージョン
## 制限と推奨事項
Teradata ODBC を使用したリンクサーバーには、次の制限が適用されます。
+ RDS for SQL Server は、Teradata ソースのユーザー名とパスワードによる簡易認証のみをサポートします。
+ RDS for SQL Server は、Teradata ODBC ドライバーのバージョン 17.20.0.33 のみをサポートします。
+ RDS for SQL Server は、接続文字列のショートカットとして使用するデータソース名 (DSN) の作成をサポートしません。
+ RDS for SQL Server は、ODBC ドライバーのトレースをサポートしません。ODBC イベントをトレースするには、SQL Server 拡張イベントを使用します。詳細については、「[RDS for SQL Server で拡張イベントを設定する](https://aws.amazon.com/blogs/database/set-up-extended-events-in-amazon-rds-for-sql-server/)」を参照してください。
+ RDS for SQL Server は、SQL Server Management Studio (SSMS) の使用時に Teradata リンクサーバーのカタログフォルダにアクセスすることをサポートしていません。
Teradata ODBC を使用したリンクサーバーを使用する際には、次の推奨事項を考慮してください。
+ 各 RDS for SQL Server DB インスタンスのセキュリティグループに適切な TCP ポートを追加して、ネットワークトラフィックを許可します。EC2 Teradata DB インスタンスと RDS for SQL Server DB インスタンスの間にリンクサーバーを設定する場合、EC2 Teradata DB インスタンスの IP アドレスからのトラフィックを許可する必要があります。また、RDS for SQL Server DB インスタンスがデータベース通信をリッスンするために使用しているポートでのトラフィックを許可する必要があります。セキュリティグループの詳細については、「[セキュリティグループによるアクセス制御](Overview.RDSSecurityGroups.md)」を参照してください。
+ 分散トランザクション (XA) はサポートされています。分散トランザクションをアクティブにするには、DB インスタンスのオプショングループで `MSDTC` オプションを有効にし、XA トランザクションが有効になっていることを確認します。詳細については、「[RDS for SQL Server での Microsoft 分散トランザクションコーディネーターのサポート](Appendix.SQLServer.Options.MSDTC.md)」を参照してください。
+ リンクされた Teradata ODBC は、Teradata Server で設定されている限り、SSL/TLS をサポートします。詳細については、「[Enable TLS Connectivity on Teradata Vantage](https://docs.teradata.com/r/Enterprise_IntelliFlex_Lake_VMware/Teradata-Call-Level-Interface-Version-2-Reference-for-Workstation-Attached-Systems-20.00/Mainframe-TLS-Connectivity-Supplement/Enable-TLS-Connectivity-on-Teradata-Vantage)」を参照してください。
## マルチ AZ 配置に関する考慮事項
RDS for SQL Server は現在、マルチ AZ 配置内のミラーリングされたデータベースサーバー (または Always-On 可用性グループのセカンダリサーバー) にリンクサーバーをレプリケートしません。設定を変更してミラーリングまたは Always-On を追加する前にリンクサーバーを追加した場合、リンクサーバーは既存のリンクサーバーに対してコピーされます。
または、プライマリインスタンスにリンクサーバーを作成し、高可用性サーバーインスタンスにフェイルオーバーしてから、リンクサーバーを再度作成する方法でも、リンクサーバーを両方の RDS for SQL Server インスタンス上に存在させることができます。
# Teradata とのリンクサーバーのアクティブ化
RDS for SQL Server DB インスタンスに `ODBC_TERADATA` オプションを追加して、Teradata とのリンクサーバーをアクティブ化します。以下のプロセスを使用します。
**Topics**
+ [`ODBC_TERADATA` のオプショングループの作成](#USER_SQLServerTeradata.Activate.CreateOG)
+ [`ODBC_TERADATA` オプションのオプショングループへの追加](#USER_SQLServerTeradata.Activate.AddOG)
+ [`ODBC_TERADATA` オプションを DB インスタンスに関連付ける](#USER_SQLServerTeradata.Activate.AssociateOG)
## `ODBC_TERADATA` のオプショングループの作成
Teradata とのリンクサーバーを使用するには、オプショングループを作成するか、使用する DB インスタンスの SQL Server エディションおよびバージョンに対応するオプショングループを変更します。この手順を完了するには、AWS マネジメントコンソール または AWS CLI を使用してください。
### コンソール
次の手順を使用して、SQL Server Standard Edition 2019 のオプショングループを作成します。
**オプショングループを作成するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. **[Create group]** (グループの作成) を選択します。
1. **[Create option group]** (オプショングループを作成) ウィンドウで次の操作を行います。
1. **[Name]** (名前) に、AWS アカウント 内で一意のオプショングループ名 (`teradata-odbc-se-2019` など) を入力します。名前には、英字、数字、ハイフンのみ使用できます。
1. **[説明]** に、オプショングループの簡単な説明を入力します。
1. [**エンジン**] で [**sqlserver-se**] を選択します。
1. **[Major engine version]** (メジャーエンジンのバージョン) で、**[15.00]** を選択します。
1. **[作成]** を選択します。
### AWS CLI
次の手順では、SQL Server Standard Edition 2019 のオプショングループを作成します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds create-option-group \
--option-group-name teradata-odbc-se-2019 \
--engine-name sqlserver-se \
--major-engine-version 15.00 \
--option-group-description "ODBC_TERADATA option group for SQL Server SE 2019"
```
**Example**
Windows の場合:
```
aws rds create-option-group ^
--option-group-name teradata-odbc-se-2019 ^
--engine-name sqlserver-se ^
--major-engine-version 15.00 ^
--option-group-description "ODBC_TERADATA option group for SQL Server SE 2019"
```
## `ODBC_TERADATA` オプションのオプショングループへの追加
次に、AWS マネジメントコンソール または AWS CLI を使用して `ODBC_Teradata` オプションをオプショングループに追加します。
### コンソール
次の手順を使用して、SQL Server Standard Edition 2019 のオプショングループを作成します。
**`ODBC_TERADATA` オプションを追加するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. 新しいオプショングループを選択します。
1. **[オプションを追加]** を選択します。
1. **[オプションの詳細]** で以下を実行します。
1. **[オプション名]** で **ODBC\$1TERADATA** を選択します。
1. **オプションのバージョン**として `17.20.33.00` を選択します。
1. [スケジューリング] で、オプションをすぐに追加するか、次のメンテナンスウィンドウで追加するかを選択します。
1. **[オプションを追加]** を選択します。
### AWS CLI
次の手順では、オプショングループに `ODBC_TERADATA` オプションを追加します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds add-option-to-option-group \
--option-group-name teradata-odbc-se-2019 \
--options "OptionName=ODBC_TERADATA,OptionVersion=17.20.33.00" \
--apply-immediately
```
**Example**
Windows の場合:
```
aws rds add-option-to-option-group ^
--option-group-name teradata-odbc-se-2019 ^
--options "OptionName=ODBC_TERADATA,OptionVersion=17.20.33.00" ^
--apply-immediately
```
## `ODBC_TERADATA` オプションを DB インスタンスに関連付ける
`ODBC_TERADATA` オプショングループを DB インスタンスに関連付けるには、AWS マネジメントコンソールまたは AWS CLI を使用します。
### コンソール
Teradata 用のリンクサーバーのアクティブ化を完了するには、オプショングループを新規または既存の DB インスタンスに関連付けます。
+ 新しい DB インスタンスの場合は、インスタンスを起動するときにそれを関連付けます。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の DB インスタンスの場合は、インスタンスを変更することでそれを関連付けます。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
### AWS CLI
オプショングループの作成時に使用したのと同じ DB エンジンのタイプとメジャーバージョンを指定します。
Linux、macOS、Unix の場合:
```
aws rds create-db-instance \
--db-instance-identifier mytestsqlserverteradataodbcinstance \
--db-instance-class db.m5.2xlarge \
--engine sqlserver-se \
--engine-version 15.00 \
--license-model license-included \
--allocated-storage 100 \
--master-username admin \
--master-user-password password \
--storage-type gp2 \
--option-group-name teradata-odbc-se-2019
```
Windows の場合:
```
aws rds create-db-instance ^
--db-instance-identifier mytestsqlserverteradataodbcinstance ^
--db-instance-class db.m5.2xlarge ^
--engine sqlserver-se ^
--engine-version 15.00 ^
--license-model license-included ^
--allocated-storage 100 ^
--master-username admin ^
--master-user-password password ^
--storage-type gp2 ^
--option-group-name teradata-odbc-se-2019
```
インスタンスを変更して新しいオプショングループを関連付けるには:
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance \
--db-instance-identifier mytestsqlserverteradataodbcinstance \
--option-group-name teradata-odbc-se-2019 \
--apply-immediately
```
Windows の場合:
```
aws rds modify-db-instance ^
--db-instance-identifier mytestsqlserverteradataodbcinstance ^
--option-group-name teradata-odbc-se-2019 ^
--apply-immediately
```
# Teradata とのリンクサーバーの作成
Teradata とのリンクサーバーを作成するには、次のコマンドを実行します。
```
EXECUTE master.dbo.sp_addlinkedserver
@server = N'LinkedServer_NAME',
@srvproduct=N'',
@provider=N'MSDASQL',
@provstr=N'"PROVIDER=MSDASQL;DRIVER={Teradata Database ODBC Driver 17.20};
DBCName=Server;UID=user_name;PWD=user_password;
UseDataEncryption=YES/NO;SSLMODE=PREFER/ALLOW/DISABLE>;"',
@catalog='database'
```
```
EXECUTE master.dbo.sp_addlinkedsrvlogin
@rmtsrvname = N'LinkedServer_NAME',
@locallogin = NULL ,
@useself = N'False',
@rmtuser = N'user_name',
@rmtpassword = N'user_password'
```
上のコマンドの例を次に示します。
```
EXECUTE master.dbo.sp_addlinkedserver
@server = N'LinkedServerToTeradata',
@srvproduct=N'',
@provider=N'MSDASQL',
@provstr=N'"PROVIDER=MSDASQL;DRIVER={Teradata Database ODBC Driver 17.20};
DBCName=my-teradata-test.cnetsipka.us-west-2.rds.amazonaws.com;
UID=master;
PWD=Test#1234;
UseDataEncryption=YES;
SSLMODE=PREFER;"',
@catalog='MyTestTeradataDB'
EXECUTE master.dbo.sp_addlinkedsrvlogin
@rmtsrvname = N'LinkedServerToTeradata',
@locallogin = NULL ,
@useself = N'False',
@rmtuser = N'master',
@rmtpassword = N'Test#1234'
```
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
# Teradata にリンクされたサーバーの非アクティブ化
Teradata へのリンクサーバーを非アクティブにするには、オプショングループから `ODBC_TERADATA` オプションを削除します。
**重要**
このオプションを削除しても、DB インスタンス上のリンクサーバー設定は削除されません。DB インスタンスから削除するには、手動で削除する必要があります。
削除後に `ODBC_TERADATA` を再度アクティブにすると、DB インスタンスで以前に設定したリンクサーバー設定を再利用できます。
## コンソール
オプショングループから `ODBC_TERADATA` オプションを削除するには
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. `ODBC_TERADATA` オプションを含むオプショングループを選択します。
1. **[削除]** を選択します。
1. **[削除オプション]** で、**[削除するオプション]** の下の `ODBC_TERADATA` を選択します。
1. **[Apply immediately]** (すぐに適用) で、オプションをすぐに削除する場合は **[Yes]** (はい) を選択し、次のメンテナンスウィンドウで削除する場合は **[No]** (いいえ) を選択します。
1. **[削除]** を選択します。
## AWS CLI
以下のコマンドは、`ODBC_TERADATA` オプションを削除します。
Linux、macOS、Unix の場合:
```
aws rds remove-option-from-option-group \
--option-group-name teradata-odbc-se-2019 \
--options ODBC_TERADATA \
--apply-immediately
```
Windows の場合:
```
aws rds remove-option-from-option-group ^
--option-group-name teradata-odbc-se-2019 ^
--options ODBC_TERADATA ^
--apply-immediately
```
# SQL Server のネイティブバックアップおよび復元のサポート
SQL Server データベースのネイティブバックアップおよび復元を使用すると、オンプレミスデータベースの差分バックアップまたは完全バックアップを作成し、バックアップファイルを Amazon S3 に保存できます。これで、SQL Server を実行する既存の Amazon RDS DB インスタンスに復元できます。また、RDS for SQL Server データベースをバックアップして Amazon S3 に保存し、他の場所に復元することもできます。さらに、オンプレミスサーバーや SQL サーバーが実行されている別の Amazon RDS DB インスタンスにバックアップを復元できます。詳細については、「[ネイティブバックアップと復元を使用した SQL Server データベースのインポートとエクスポート](SQLServer.Procedural.Importing.md)」を参照してください。
Amazon RDS では、差分および完全バックアップファイル (.bak ファイル) を使用した、Microsoft SQL Server データベースのネイティブバックアップと復元をサポートしています。
## ネイティブバックアップおよび復元オプションの追加
DB インスタンスにネイティブバックアップおよび復元オプションを追加する一般的な手順は以下のとおりです。
1. 新しいオプショングループを作成するか、既存のオプショングループをコピーまたは変更します。
1. オプショングループに [`SQLSERVER_BACKUP_RESTORE`] オプションを追加します。
1. AWS Identity and Access Management (IAM) ロールとオプションを関連付けます。IAM ロールには、データベースバックアップを復元できるように S3 バケットのアクセス権限を付与します。
つまり、オプションには、有効な Amazon リソースネーム (ARN) を`arn:aws:iam::account-id:role/role-name` 形式で設定するオプションが必要となります。詳細については、*AWS 全般のリファレンス* の「[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html#arn-syntax-iam)」を参照してください。
IAM ロールには、信頼関係と許可ポリシーがアタッチされている必要もあります。信頼関係は RDS がロールを引き受けることを許可し、許可ポリシーはロールが実行できるアクションを定義します。詳細については、「[ネイティブバックアップおよび復元用の IAM ロールの手動作成](SQLServer.Procedural.Importing.Native.Enabling.md#SQLServer.Procedural.Importing.Native.Enabling.IAM)」を参照してください。
1. オプショングループを DB インスタンスに関連付けます。
ネイティブバックアップおよび復元オプションを追加したら、DB インスタンスを再起動する必要はありません。オプショングループがアクティブになるとすぐ、バックアップと復元をスタートできます。
### コンソール
**ネイティブバックアップおよび復元オプションを追加**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. 新しいオプショングループを作成するか、既存のオプショングループを使用します。カスタム DB オプションの作成方法については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
既存のオプショングループを使用する場合は、次のステップに進んでください。
1. オプショングループに [**SQLSERVER\$1BACKUP\$1RESTORE**] オプションを追加します。オプションの追加方法の詳細については、「[オプショングループにオプションを追加する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption)」を参照してください。
1. 次のいずれかを行ってください。
+ 既存の IAM ロールおよびAmazon S3 設定を使用するには、**IAM ロール**に対して既存の IAM ロールを選択します。既存の IAM ロールを使用すると、RDS は、このロールに対して設定した Amazon S3 設定を使用します。
+ 新規ロールを作成し、Amazon S3 設定を構成するには、次の手順を実行します。
1. **[IAM role]** (IAM ロール) は、**[Create a new role]** (新しいロールの作成) を選択します。
1. 「**S3 バケット**」 で、リストからS3 バケットを選択します。
1. 「**S3 プレフィックス (オプション)**」 で、Amazon S3 バケットに保存されているファイルに使用するプレフィックスを指定します。
このプレフィックスにはファイルパスを含めることはできますが、必須ではありません。プレフィックスを提供すると、RDS はそのプレフィックスをすべてのバックアップファイルにアタッチします。その後、復元中に、RDS はプレフィックスを使用して関連ファイルを特定し、非関連ファイルを無視します。例えば、バックアップファイルを保持する以外の目的で、S3 バケットを使用することが可能です。この場合、RDS が、特定のフォルダやサブフォルダでネイティブバックアップおよび復元を実行するため、プレフィックスを使うことが可能です。
プレフィックスを空白にした場合、RDS はプレフィックスを使用しないでバックアップファイルの特定およびファイルの復元を実行します。その結果、複数ファイルの復元中に、RDS は S3 バケットの各フォルダのすべてのファイルの復元を試みます。
1. バックアップファイルを暗号化する場合は、「**暗号化を有効化する**」の チェックボックスを選択します。バックアップファイルを暗号化しない場合は、チェックボックスをオフにします (デフォルト)。
「**暗号化を有効化する**」 を選択した場合、「**AWS KMS key**」で暗号化キーを選択します。暗号化キーの詳細については、*AWS Key Management Service デベロッパーガイド*の「[スタート方法](https://docs.aws.amazon.com/kms/latest/developerguide/getting-started.html)」を参照してください。
1. [**オプションの追加**] を選択します。
1. 新規または既存の DB インスタンスに、DB オプショングループを適用します。
+ 新しい DB インスタンスの場合は、インスタンスを起動するときにオプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の DB インスタンスの場合は、インスタンスを修正し、新しいオプショングループを添付することで、オプショングループを適用します。(詳しくは、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。)
### CLI
この手順では、以下を前提とします。
+ 既存のオプショングループに SQLSERVER\$1BACKUP\$1RESTORE オプションを追加します。オプションの追加方法の詳細については、「[オプショングループにオプションを追加する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption)」を参照してください。
+ このオプションを既存の IAM ロールに関連付けます。また、バックアップを保存するための S3 バケットへのアクセス権があります。
+ オプショングループを既存の DB インスタンスに適用します。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
**ネイティブバックアップおよび復元オプションを追加**
1. オプショングループに [`SQLSERVER_BACKUP_RESTORE`] オプションを追加します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds add-option-to-option-group \
--apply-immediately \
--option-group-name mybackupgroup \
--options "OptionName=SQLSERVER_BACKUP_RESTORE, \
OptionSettings=[{Name=IAM_ROLE_ARN,Value=arn:aws:iam::account-id:role/role-name}]"
```
Windows の場合:
```
aws rds add-option-to-option-group ^
--option-group-name mybackupgroup ^
--options "[{\"OptionName\": \"SQLSERVER_BACKUP_RESTORE\", ^
\"OptionSettings\": [{\"Name\": \"IAM_ROLE_ARN\", ^
\"Value\": \"arn:aws:iam::account-id:role/role-name"}]}]" ^
--apply-immediately
```
**注記**
Windows コマンドプロンプトを使用する場合、JSON コードでは、二重引用符 (") の前にバックスラッシュ (\$1) を付けてエスケープする必要があります。
1. DB インスタンスにオプショングループを適用します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--option-group-name mybackupgroup \
--apply-immediately
```
Windows の場合:
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--option-group-name mybackupgroup ^
--apply-immediately
```
## ネイティブバックアップおよび復元オプションの設定の変更
ネイティブバックアップおよび復元オプションを有効にすると、オプションの設定を変更できます。オプション設定の変更方法の詳細については、「[オプションの設定を変更する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.ModifyOption)」を参照してください。
## ネイティブバックアップおよび復元オプションの削除
DB インスタンスからオプションを削除することによって、ネイティブバックアップおよび復元をオフにすることができます。ネイティブバックアップおよび復元オプションを削除したら、DB インスタンスを再起動する必要はありません。
DB インスタンスからネイティブバックアップおよび復元オプションを削除するには、次のいずれかを実行します。
+ オプションを所属するオプショングループから削除します。この変更はそのオプショングループを使用するすべての DB インスタンスに影響します。詳細については、「[オプショングループからオプションを削除する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.RemoveOption)」を参照してください。
+ DB インスタンスを修正して、ネイティブバックアップおよび復元オプションが含まれない別オプショングループを指定します。この変更は、単一の DB インスタンスに影響します。デフォルト (空) のオプショングループや別のカスタムオプショングループを指定できます。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
# SQL サーバーの透過的なデータの暗号化サポート
Amazon RDS は、透過的なデータ暗号化 (TDE) を使用して、Microsoft SQL Server を実行する DB インスタンスのデータの暗号化をサポートします。TDE は、ストレージへの書き込み前に自動的にデータを暗号化し、ストレージからのデータの読み取り時に自動的にデータを復号します。
Amazon RDS は、次の SQL Server のバージョンおよびエディションの TDE をサポートしています。
+ SQL Server 2022: Standard および Enterprise Edition
+ SQL Server 2019: Standard および Enterprise Edition
+ SQL Server 2017 Enterprise Edition
+ SQL Server 2016 Enterprise Edition
**注記**
RDS for SQL Server は、読み取り専用データベースの TDE をサポートしていません。
SQL Server の 透過的データ暗号化では、2 階層キーアーキテクチャを使用して暗号化キーの管理を行っています。証明書は、データベースマスターキーから生成され、データ暗号化キーの保護に使用されます。データベース暗号化キーにより、ユーザーデータベースのデータの実際の暗号化と復号が実行されます。データベースマスターキーと TDE 証明書は、Amazon RDS によりバックアップおよび管理されます。
透過的データ暗号化 (TDE) は、機密データの暗号化が必要なシナリオで使用されます。例えば、データファイルとバックアップをサードパーティーに提供したり、セキュリティ関連の規制遵守の問題に対処したりすることができます。`model` データベースや `master` データベースなど、SQL Server のシステムデータベースを暗号化することはできません。
透過的データ暗号化の詳細はこのガイドの範囲外ですが、暗号化アルゴリズムとキーのそれぞれのセキュリティ上の長所と短所を理解しておく必要があります。SQL Server の透過的データ暗号化の詳細については、Microsoft のドキュメントで「[透過的データ暗号化 (TDE)](http://msdn.microsoft.com/en-us/library/bb934049.aspx)」を参照してください。
**Topics**
+ [RDS for SQL Server の TDE をオンにする](#TDE.Enabling)
+ [RDS for SQL Server でのデータの暗号化](TDE.Encrypting.md)
+ [RDS for SQL Server での TDE 証明書のバックアップと復元](TDE.BackupRestoreRDS.md)
+ [オンプレミスデータベースの TDE 証明書のバックアップと復元](TDE.BackupRestoreOnPrem.md)
+ [RDS for SQL Server の TDE をオフにする](TDE.Disabling.md)
## RDS for SQL Server の TDE をオンにする
RDS for SQL Server DB インスタンスに対して透過的なデータ暗号化 (TDE) をオンにするには、DB インスタンスに関連付けられている RDS オプショングループで TDE オプションを指定します。
1. DB インスタンスが、TDE オプションが含まれているオプショングループにすでに関連付けられているかどうかを確認します。DB インスタンスが関連付けられているオプショングループを表示するには、RDS コンソール、AWS CLI コマンド ([describe-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html))、または API オペレーション [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) を使用します。
1. TDE がオンになっているオプショングループに DB インスタンスが関連付けられていない場合は、2 つのオプションから選択できます。オプショングループを作成して TDE オプションを追加するか、オプションを追加するように関連するオプショングループを変更することもできます。
**注記**
RDS コンソールの場合、このオプション名は `TRANSPARENT_DATA_ENCRYPTION` です。AWS CLI と RDS API の場合、名前は `TDE` です。
オプショングループの作成または変更の詳細については、「[オプショングループを使用する](USER_WorkingWithOptionGroups.md)」を参照してください。オプショングループへのオプションの追加の詳細については、「[オプショングループにオプションを追加する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption)」を参照してください。
1. [TDE] オプションを持つオプショングループに DB インスタンスを関連付けます。オプショングループへの DB インスタンスの関連付けの詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
### オプショングループに関する考慮事項
TDE オプションは、永続オプションです。すべての DB インスタンスおよびバックアップがオプショングループに関連付けられていない限り、オプショングループから削除することはできません。オプショングループに TDE オプションを追加したら、そのオプショングループは、TDE を使用する DB インスタンスにのみ関連付けることができます。オプショングループの永続オプションの詳細については、「[オプショングループの概要](USER_WorkingWithOptionGroups.md#Overview.OptionGroups)」を参照してください。
TDE オプションは永続オプションであるため、オプショングループおよび関連付けられている DB インスタンスとの間に競合が生じることがあります。次の状況で競合が生じることがあります。
+ TDE オプションを含む現在のオプショングループを、TDE オプションを含まないオプショングループに置き換えた。
+ DB スナップショットから復元した先の新しい DB インスタンスに TDE オプションを含むオプショングループがない。このシナリオの詳細については、「[オプショングループの考慮事項](USER_CopySnapshot.md#USER_CopySnapshot.Options)」を参照してください。
### SQL Server のパフォーマンスに関する考慮事項
透過的データ暗号化の使用は、SQL Server DB インスタンスのパフォーマンスに影響を与えることがあります。
暗号化されていないデータベースが DB インスタンスにあり、そのインスタンスに暗号化されたデータベースが 1 つでもあれば、暗号化されていないデータベースのパフォーマンスも低下することがあります。したがって、暗号化されたデータベースと暗号化されていないデータベースは別々の DB インスタンスに維持することをお勧めします。
# RDS for SQL Server でのデータの暗号化
TDE オプションがオプショングループに追加されると、暗号化プロセスに使用される証明書が Amazon RDS によって生成されます。その後、証明書を使用して、DB インスタンス上のデータベースのデータを暗号化する SQL ステートメントを実行できます。
以下の例では、RDS によって生成された `RDSTDECertificateName` という証明書を使用して、`myDatabase` というデータベースを暗号化しています。
```
1. ---------- Turning on TDE -------------
2.
3. -- Find an RDS TDE certificate to use
4. USE [master]
5. GO
6. SELECT name FROM sys.certificates WHERE name LIKE 'RDSTDECertificate%'
7. GO
8.
9. USE [myDatabase]
10. GO
11. -- Create a database encryption key (DEK) using one of the certificates from the previous step
12. CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256
13. ENCRYPTION BY SERVER CERTIFICATE [RDSTDECertificateName]
14. GO
15.
16. -- Turn on encryption for the database
17. ALTER DATABASE [myDatabase] SET ENCRYPTION ON
18. GO
19.
20. -- Verify that the database is encrypted
21. USE [master]
22. GO
23. SELECT name FROM sys.databases WHERE is_encrypted = 1
24. GO
25. SELECT db_name(database_id) as DatabaseName, * FROM sys.dm_database_encryption_keys
26. GO
```
TDE を使用した SQL Server データベースの暗号化にかかる時間は、いくつかの要因によって異なります。例えば、DB インスタンスのサイズ、プロビジョンド IOPS ストレージがインスタンスに対して有効になっているかどうか、データ量などです。
# RDS for SQL Server での TDE 証明書のバックアップと復元
RDS for SQL Server には、TDE 証明書のバックアップ、復元、および削除のためのストアドプロシージャが用意されています。RDS for SQL Server には、復元されたユーザー TDE 証明書を表示するための機能も用意されています。
ユーザー TDE 証明書は、オンプレミスで TDE がオンになっている RDS for SQL Server にデータベースを復元するために使用されます。これらの証明書には、プレフィックス `UserTDECertificate_` が付いています。データベースを復元した後、それらを使用できるようにする前に、RDS は、TDE を オンにしたデータベースを変更し、RDS で生成された TDE 証明書を使用するようにします。これらの証明書には、プレフィックス `RDSTDECertificate` が付いています。
ユーザー TDE 証明書は、`rds_drop_tde_certificate` ストアドプロシージャを使って削除しない限り、RDS for SQL Server DB インスタンスに残ります。(詳しくは、「[復元された TDE 証明書の削除](#TDE.BackupRestoreRDS.Drop)」を参照してください。)
ユーザー TDE 証明書を使用して、移行元 DB インスタンスから他のデータベースを復元できます。復元するデータベースは同じ TDE 証明書を使用し、TDE がオンになっている必要があります。同じ証明書を再度インポート (復元) する必要はありません。
**Topics**
+ [前提条件](#TDE.BackupRestoreRDS.Prereqs)
+ [制限事項](#TDE.Limitations)
+ [TDE 証明書のバックアップ](#TDE.BackupRestoreRDS.Backup)
+ [TDE 証明書の復元](#TDE.BackupRestoreRDS.Restore)
+ [復元された TDE 証明書の表示](#TDE.BackupRestoreRDS.Show)
+ [復元された TDE 証明書の削除](#TDE.BackupRestoreRDS.Drop)
## 前提条件
RDS for SQL Server で TDE 証明書をバックアップまたは復元する前に、次のタスクを実行してください。最初の 3 つについては、「[ネイティブバックアップおよび復元のセットアップ](SQLServer.Procedural.Importing.Native.Enabling.md)」を参照してください。
1. バックアップおよび復元するファイルを保存するための Amazon S3 汎用バケットまたはディレクトリバケットを作成します。
データベースバックアップと TDE 証明書のバックアップには、別々のバケットを使用することをお勧めします。
1. ファイルのバックアップと復元用の IAM ロールを作成します。
IAM ロールは、AWS KMS key のユーザーおよび管理者の両方である必要があります。
ディレクトリバケットを使用する場合、ディレクトリバケットで [ネイティブバックアップおよび復元用の IAM ロールの手動作成](SQLServer.Procedural.Importing.Native.Enabling.md#SQLServer.Procedural.Importing.Native.Enabling.IAM) に必要なアクセス許可以外、追加のアクセス許可は必要ありません。
S3 リソースを使用する場合、[ネイティブバックアップおよび復元用の IAM ロールの手動作成](SQLServer.Procedural.Importing.Native.Enabling.md#SQLServer.Procedural.Importing.Native.Enabling.IAM) に必要なアクセス許可に加えて、IAM ロールには次のアクセス許可も必要です。
+ S3 バケットリソースの `s3:GetBucketAcl`、`s3:GetBucketLocation`、および`s3:ListBucket`
1. DB インスタンスのオプショングループに追加された `SQLSERVER_BACKUP_RESTORE` オプション。
これは、`TRANSPARENT_DATA_ENCRYPTION` (`TDE`) オプションへの追加です。
1. 対称暗号化 KMS キーであることを確認します。次のオプションがあります。
+ アカウントに既存の KMS キーがある場合は、それを使用できます。これ以上の操作は不要です。
+ アカウントに既存の対称暗号化 KMS キーがない場合は、*AWS Key Management Serviceデベロッパーガイド*の「[キーの作成](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk)」の手順に従って KMS キーを作成します。
1. Amazon S3 統合を有効にして、DB インスタンスと Amazon S3 の間でファイルを転送します。
Amazon S3 統合を有効にするための詳細については、「[Amazon RDS for SQL Server DB インスタンスと Amazon S3 の統合](User.SQLServer.Options.S3-integration.md)」を参照してください。
ディレクトリバケットは S3 統合ではサポートされていないことにご注意ください。このステップは、[オンプレミスデータベースの TDE 証明書のバックアップと復元](TDE.BackupRestoreOnPrem.md) にのみ必要です。
## 制限事項
ストアドプロシージャを使用して TDE 証明書をバックアップおよび復元する場合、次の制限があります。
+ `SQLSERVER_BACKUP_RESTORE` および `TRANSPARENT_DATA_ENCRYPTION` (`TDE`) オプションはどちらも DB インスタンスに関連付けられたオプショングループに追加されている必要があります。
+ TDE 証明書のバックアップと復元は、マルチ AZ DB インスタンスではサポートされていません。
+ TDE 証明書のバックアップおよび復元タスクのキャンセルはサポートされていません。
+ RDS for SQL Server DB インスタンス上の他のデータベースの TDE 暗号化にユーザー TDE 証明書を使用することはできません。これを使用して復元できるのは、TDE がオンになっていて、同じ TDE 証明書を使用する移行元 DB インスタンスから他のデータベースのみです。
+ 削除できるのはユーザー TDE 証明書のみです。
+ RDS でサポートされているユーザー TDE 証明書の最大数は 10 です。数が 10 を超える場合は、未使用の TDE 証明書を削除して、もう一度試してください。
+ 証明書名を空または null にすることはできません。
+ 証明書を復元する場合、証明書名にキーワード `RDSTDECERTIFICATE` を含めることはできません。また、プレフィックス `UserTDECertificate_` で始まる必要があります。
+ `@certificate_name` パラメータには、a ～ z、0 ～ 9、@、\$1、\$1、下線 (\$1) の文字のみを含めることができます。
+ `@certificate_file_s3_arn` のファイル拡張子は .cer (大文字小文字を区別しない) にする必要があります。
+ `@private_key_file_s3_arn` のファイル拡張子は .pvk (大文字小文字を区別しない) にする必要があります。
+ プライベートキーファイルの S3 メタデータには、`x-amz-meta-rds-tde-pwd` タグが含まれる必要があります。詳細については、「[オンプレミスデータベースの TDE 証明書のバックアップと復元](TDE.BackupRestoreOnPrem.md)」を参照してください。
+ RDS for SQL Server は、TDE のクロスアカウントキーの使用をサポートしていません。
## TDE 証明書のバックアップ
TDE 証明書をバックアップするには、`rds_backup_tde_certificate` ストアドプロシージャを使用します。これには、以下の構文があります。
```
EXECUTE msdb.dbo.rds_backup_tde_certificate
@certificate_name='UserTDECertificate_certificate_name | RDSTDECertificatetimestamp',
@certificate_file_s3_arn='arn:aws:s3:::bucket_name/certificate_file_name.cer',
@private_key_file_s3_arn='arn:aws:s3:::bucket_name/key_file_name.pvk',
@kms_password_key_arn='arn:aws:kms:region:account-id:key/key-id',
[@overwrite_s3_files=0|1];
```
以下のパラメータは必須です。
+ `@certificate_name` — バックアップする TDE 証明書の名前。
+ `@certificate_file_s3_arn` — Amazon S3 の証明書バックアップファイルの送信先 Amazon リソースネーム (ARN)。
+ `@private_key_file_s3_arn` — TDE 証明書を保護するぷらいべーとキーファイルの送信先 S3 ARN。
+ `@kms_password_key_arn` — プライベートキーのパスワードの暗号化に使用される対称 KMS キーの ARN。
次のパラメータはオプションです。
+ `@overwrite_s3_files` — S3 内の既存の証明書および秘密キーファイルを上書きするかどうかを示します。
+ `0` – 既存のファイルを上書きしません。この値はデフォルト値です。
設定 `@overwrite_s3_files` を 0 にすると、ファイルが既に存在している場合はエラーが返されます。
+ `1` – バックアップファイルではない場合でも、指定された名前を持つ既存のファイルを上書きします。
**Example TDE 証明書のバックアップ**
```
EXECUTE msdb.dbo.rds_backup_tde_certificate
@certificate_name='RDSTDECertificate20211115T185333',
@certificate_file_s3_arn='arn:aws:s3:::TDE_certs/mycertfile.cer',
@private_key_file_s3_arn='arn:aws:s3:::TDE_certs/mykeyfile.pvk',
@kms_password_key_arn='arn:aws:kms:us-west-2:123456789012:key/AKIAIOSFODNN7EXAMPLE',
@overwrite_s3_files=1;
```
## TDE 証明書の復元
ユーザー TDE 証明書を復元 (インポート) するには `rds_restore_tde_certificate` ストアドプロシージャを使用します。これには、以下の構文があります。
```
EXECUTE msdb.dbo.rds_restore_tde_certificate
@certificate_name='UserTDECertificate_certificate_name',
@certificate_file_s3_arn='arn:aws:s3:::bucket_name/certificate_file_name.cer',
@private_key_file_s3_arn='arn:aws:s3:::bucket_name/key_file_name.pvk',
@kms_password_key_arn='arn:aws:kms:region:account-id:key/key-id';
```
以下のパラメータは必須です。
+ `@certificate_name` — 復元する TDE 証明書の名前。名前はプレフィックス `UserTDECertificate_` で開始する必要があります。
+ `@certificate_file_s3_arn` — TDE 証明書を復元するために使用されるバックアップファイルの S3 ARN。
+ `@private_key_file_s3_arn` — 復元する TDE 証明書のプライベートキーバックアップファイルの S3 ARN。
+ `@kms_password_key_arn` — プライベートキーのパスワードの暗号化に使用される対称 KMS キーの ARN。
**Example TDE 証明書の復元**
```
EXECUTE msdb.dbo.rds_restore_tde_certificate
@certificate_name='UserTDECertificate_myTDEcertificate',
@certificate_file_s3_arn='arn:aws:s3:::TDE_certs/mycertfile.cer',
@private_key_file_s3_arn='arn:aws:s3:::TDE_certs/mykeyfile.pvk',
@kms_password_key_arn='arn:aws:kms:us-west-2:123456789012:key/AKIAIOSFODNN7EXAMPLE';
```
## 復元された TDE 証明書の表示
復元 (インポート) したユーザー TDE 証明書を表示するには `rds_fn_list_user_tde_certificates` 関数を使用します。これには、以下の構文があります。
```
SELECT * FROM msdb.dbo.rds_fn_list_user_tde_certificates();
```
出力は以下のようになります。すべての列がここに表示されるわけではありません。
| | | | | | | | | | | |
| --- |--- |--- |--- |--- |--- |--- |--- |--- |--- |--- |
| name | certificate\$1id | principal\$1id | pvt\$1key\$1encryption\$1type\$1desc | issuer\$1name | cert\$1serial\$1number | thumbprint | subject | start\$1date | expiry\$1date | pvt\$1key\$1last\$1backup\$1date |
| UserTDECertificate\$1tde\$1cert | 343 | 1 | ENCRYPTED\$1BY\$1MASTER\$1KEY | AnyCompany Shipping | 79 3e 57 a3 69 fd 1d 9e 47 2c 32 67 1d 9c ca af | 0x6BB218B34110388680B FE1BA2D86C695096485B5 | AnyCompany Shipping | 2022-04-05 19:49:45.0000000 | 2023-04-05 19:49:45.0000000 | NULL |
## 復元された TDE 証明書の削除
使用していない復元された (インポートされた) ユーザー TDE 証明書を削除するには、`rds_drop_tde_certificate` ストアドプロシージャを使用します。これには、以下の構文があります。
```
EXECUTE msdb.dbo.rds_drop_tde_certificate @certificate_name='UserTDECertificate_certificate_name';
```
以下のパラメータは必須です。
+ `@certificate_name`— 削除する TDE 証明書の名前。
復元された (インポートされた) TDE 証明書のみを削除できます。RDS で作成された証明書は削除できません。
**Example TDE 証明書の削除**
```
EXECUTE msdb.dbo.rds_drop_tde_certificate @certificate_name='UserTDECertificate_myTDEcertificate';
```
# オンプレミスデータベースの TDE 証明書のバックアップと復元
オンプレミスデータベースの TDE 証明書をバックアップし、後でそれらを RDS for SQL Server に復元できます。RDS for SQL Server TDE 証明書をオンプレミス DB インスタンスに復元することもできます。
**注記**
RDS for SQL Server は、TDE のクロスアカウントキーの使用をサポートしていません。
次の手順では、TDE 証明書とプライベートキーをバックアップします。プライベートキーは、対称暗号化 KMS キーから生成されたデータキーを使用して暗号化されます。
**オンプレミスの TDE 証明書をバックアップするには**
1. AWS CLI [generate-data-key](https://docs.aws.amazon.com/cli/latest/reference/kms/generate-data-key.html) コマンドを使用して、データキーを生成します。
```
aws kms generate-data-key \
--key-id my_KMS_key_ID \
--key-spec AES_256
```
出力は以下のようになります。
```
{
"CiphertextBlob": "AQIDAHimL2NEoAlOY6Bn7LJfnxi/OZe9kTQo/XQXduug1rmerwGiL7g5ux4av9GfZLxYTDATAAAAfjB8BgkqhkiG9w0B
BwagbzBtAgEAMGgGCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQMyCxLMi7GRZgKqD65AgEQgDtjvZLJo2cQ31Vetngzm2ybHDc3d2vI74SRUzZ
2RezQy3sAS6ZHrCjfnfn0c65bFdhsXxjSMnudIY7AKw==",
"Plaintext": "U/fpGtmzGCYBi8A2+0/9qcRQRK2zmG/aOn939ZnKi/0=",
"KeyId": "arn:aws:kms:us-west-2:123456789012:key/1234abcd-00ee-99ff-88dd-aa11bb22cc33"
}
```
次のステップで、プレーンテキスト出力をプライベートキーのパスワードとして使用します。
1. 次の例に示すように、TDE 証明書をバックアップします。
```
BACKUP CERTIFICATE myOnPremTDEcertificate TO FILE = 'D:\tde-cert-backup.cer'
WITH PRIVATE KEY (
FILE = 'C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\cert-backup-key.pvk',
ENCRYPTION BY PASSWORD = 'U/fpGtmzGCYBi8A2+0/9qcRQRK2zmG/aOn939ZnKi/0=');
```
1. 証明書のバックアップファイルを Amazon S3 証明書バケットに保存します。
1. プライベートキーのバックアップファイルを S3 証明書バケットに保存し、ファイルのメタデータに次のタグを付けます。
+ キー – `x-amz-meta-rds-tde-pwd`
+ 値 — データキーの生成による `CiphertextBlob` 値、以下の例を参照。
```
AQIDAHimL2NEoAlOY6Bn7LJfnxi/OZe9kTQo/XQXduug1rmerwGiL7g5ux4av9GfZLxYTDATAAAAfjB8BgkqhkiG9w0B
BwagbzBtAgEAMGgGCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQMyCxLMi7GRZgKqD65AgEQgDtjvZLJo2cQ31Vetngzm2ybHDc3d2vI74SRUzZ
2RezQy3sAS6ZHrCjfnfn0c65bFdhsXxjSMnudIY7AKw==
```
次の手順では、RDS for SQL Server TDE 証明書をオンプレミス DB インスタンスに復元します。証明書のバックアップ、対応するプライベートキーファイル、およびデータキーを使用して、移行先 DB インスタンスに TDE 証明書をコピーして復元します。復元された証明書は、新しいサーバーのデータベースマスターキーによって暗号化されます。
**TDE 証明書を復元するには**
1. TDE 証明書のバックアップファイルとプライベートキーファイルを Amazon S3 から移行先インスタンスにコピーします。Amazon S3 からのファイルコピーの詳細については、「[RDS for SQL Server と Amazon S3 間のファイル転送](Appendix.SQLServer.Options.S3-integration.using.md)」を参照してください。
1. KMS キーを使用して出力暗号テキストを復号化し、データキーのプレーンテキストを取得します。暗号テキストは、プライベートキーバックアップファイルの S3 メタデータにあります。
```
aws kms decrypt \
--key-id my_KMS_key_ID \
--ciphertext-blob fileb://exampleCiphertextFile | base64 -d \
--output text \
--query Plaintext
```
次のステップで、プレーンテキスト出力をプライベートキーのパスワードとして使用します。
1. 次の SQL コマンドを使用して、TDE 証明書を復元します。
```
CREATE CERTIFICATE myOnPremTDEcertificate FROM FILE='D:\tde-cert-backup.cer'
WITH PRIVATE KEY (FILE = N'D:\tde-cert-key.pvk',
DECRYPTION BY PASSWORD = 'plain_text_output');
```
KMS の復号化の詳細については、「*AWS CLI コマンドリファレンス*」の KMS セクションの「[復号](https://docs.aws.amazon.com/cli/latest/reference/kms/decrypt.html)」を参照してください。
TDE 証明書が移行先 DB インスタンスで復元された後、その証明書を使用して暗号化されたデータベースを復元できます。
**注記**
同じ TDE 証明書を使用して、移行元 DB インスタンス上の複数の SQL Server データベースを暗号化できます。複数のデータベースを移行先インスタンスに移行するには、それらに関連付けられた TDE 証明書を移行先インスタンスに一度だけコピーします。
# RDS for SQL Server の TDE をオフにする
RDS for SQL Server DB インスタンスの TDE をオフにするには、まず、DB インスタンスに暗号化されたオブジェクトが残っていないようにします。これを行うには、オブジェクトを復号化するか、削除します。暗号化されたオブジェクトが DB インスタンスに残っている場合は、DB インスタンスに対して TDE をオフにすることはできません。暗号化用のユーザー TDE 証明書が復元 (インポート) された場合は、削除する必要があります。コンソールを使用してオプショングループから TDE オプションを削除すると、処理中であることがコンソールに示されます。さらに、オプショングループが暗号化された DB インスタンスまたは DB スナップショットに関連付けられている場合は、エラーイベントが作成されます。
以下の例では、`customerDatabase` というデータベースから TDE 暗号化を削除しています。
```
1. ------------- Removing TDE ----------------
2.
3. USE [customerDatabase]
4. GO
5.
6. -- Turn off encryption of the database
7. ALTER DATABASE [customerDatabase]
8. SET ENCRYPTION OFF
9. GO
10.
11. -- Wait until the encryption state of the database becomes 1. The state is 5 (Decryption in progress) for a while
12. SELECT db_name(database_id) as DatabaseName, * FROM sys.dm_database_encryption_keys
13. GO
14.
15. -- Drop the DEK used for encryption
16. DROP DATABASE ENCRYPTION KEY
17. GO
18.
19. -- Drop a user TDE certificate if it was restored (imported)
20. EXECUTE msdb.dbo.rds_drop_tde_certificate @certificate_name='UserTDECertificate_certificate_name';
21.
22. -- Alter to SIMPLE Recovery mode so that your encrypted log gets truncated
23. USE [master]
24. GO
25. ALTER DATABASE [customerDatabase] SET RECOVERY SIMPLE
26. GO
```
すべてのオブジェクトを復号すると、2 つのオプションを使用できます。
1. DB インスタンスを変更して TDE オプションが含まれていないオプショングループに関連付けることができます。
1. オプショングループから TDE オプションを削除できます。
# SQL Server Audit
Amazon RDS では、組み込みの SQL Server 監査メカニズムを使用して、Microsoft SQL Server データベースを監査することができます。監査と監査の仕様は、オンプレミスのデータベースサーバー用にそれらを作成するのと同じ方法で作成することができます。
RDS は、完了した監査ログを S3 バケットにアップロードします。この際、作成されたロールを IAM 使用します。保存を有効にしている場合、RDS は設定された期間、監査ログを DB インスタンスに保存します。
詳細については、Microsoft SQL Server ドキュメントの「[SQL Server Audit (database engine)](https://docs.microsoft.com/sql/relational-databases/security/auditing/sql-server-audit-database-engine)」を参照してください。
## データベースアクティビティストリームを使用した SQL Server Audit
RDS のデータベースアクティビティストリームを使用すると、SQL Server Audit イベントを Imperva、McAfee、IBM のデータベースアクティビティ監視ツールと統合できます。RDS SQL Server のデータベースアクティビティストリームによる監査の詳細については、「[Microsoft SQL Server での監査](DBActivityStreams.md#DBActivityStreams.Overview.SQLServer-auditing)」を参照してください。
**Topics**
+ [データベースアクティビティストリームを使用した SQL Server Audit](#Appendix.SQLServer.DAS.Audit)
+ [SQL Server Audit のサポート](#Appendix.SQLServer.Options.Audit.Support)
+ [SQL Server Audit を DB インスタンスオプションに追加する](Appendix.SQLServer.Options.Audit.Adding.md)
+ [SQL Server Audit を使用する](Appendix.SQLServer.Options.Audit.CreateAuditsAndSpecifications.md)
+ [監査ログの表示](Appendix.SQLServer.Options.Audit.AuditRecords.md)
+ [マルチ AZ インスタンスで SQL Server Audit を使用する](#Appendix.SQLServer.Options.Audit.Multi-AZ)
+ [S3 バケットを設定する](Appendix.SQLServer.Options.Audit.S3bucket.md)
+ [SQL Server Audit の IAM ロールを手動で作成する](Appendix.SQLServer.Options.Audit.IAM.md)
## SQL Server Audit のサポート
Amazon RDS では、SQL Server 2016 以降、SQL Server のすべてのエディションでサーバーレベルの監査がサポートされており、Enterprise エディションでもデータベースレベルの監査がサポートされています。SQL サーバー 2016 (13.x) SP1 以降では、すべてのエディションでサーバーレベルとデータベースレベルの両方の監査がサポートされています。詳細については、SQL Server ドキュメントの「[SQL Server Audit (database engine)](https://docs.microsoft.com/sql/relational-databases/security/auditing/sql-server-audit-database-engine)」を参照してください。
RDS では、SQL Server Audit に関する次のオプション設定の構成をサポートしています。
| オプション設定 | 有効な値 | 説明 |
| --- | --- | --- |
| IAM\$1ROLE\$1ARN | 形式 arn:aws:iam::account-id:role/role-name の有効な Amazon リソースネーム (ARN)。 | 監査ログを保存する S3 バケットへのアクセスを許可する IAM ロールの ARN。詳細については、AWS 全般のリファレンス の「[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html#arn-syntax-iam)」を参照してください。 |
| S3\$1BUCKET\$1ARN | arn:aws:s3:::amzn-s3-demo-bucket 形式または arn:aws:s3:::amzn-s3-demo-bucket/key-prefix 形式の有効な ARN。 | 監査ログを保存する S3 バケットの ARN。 |
| ENABLE\$1COMPRESSION | true または false | 監査ログの圧縮を行います。デフォルトでは、圧縮は有効です (true に設定されている)。 |
| RETENTION\$1TIME | 0 ～840 | SQL Server 監査レコードが RDS インスタンスに保持される保持期間 (時間単位)。保持設定は、デフォルトでは無効になります。 |
# SQL Server Audit を DB インスタンスオプションに追加する
SQL Server 監査を有効にするには、DB インスタンスでオプションを有効にすることと、SQL Server 内の機能を有効にすることの 2 つのステップを行う必要があります。SQL Server Audit オプションを DB インスタンスに追加するプロセスは次のとおりです。
1. 新しいオプショングループを作成するか、既存のオプショングループをコピーまたは変更します。
1. すべての必須オプションを追加して構成します。
1. オプショングループを DB インスタンスに関連付けます。
SQL Server Audit オプションを追加後、DB インスタンスを再起動する必要はありません。オプショングループがアクティブになった時点で、監査を作成して監査ログを S3 バケットに保存できるようになります。
**DB インスタンスのオプショングループに SQL Server Audit を追加して設定するには**
1. 次のいずれかを選択します。
+ 既存のオプショングループを使用します。
+ カスタムの DB オプショングループを作成し、そのオプショングループを使用します。詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
1. オプショングループに [**SQLSERVER\$1AUDIT**] オプションを追加し、オプション設定を構成します。オプションの追加方法の詳細については、「[オプショングループにオプションを追加する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption)」を参照してください。
+ 必要なポリシーがアタッチされた IAM ロールがある場合は、[**IAM ロール**] で、そのロールを選択できます。新しい IAM ロールを作成するには、[**新しいロールの作成**] を選択します。必要なポリシーの詳細については、[SQL Server Audit の IAM ロールを手動で作成する](Appendix.SQLServer.Options.Audit.IAM.md) を参照してください。
+ 使用する S3 バケットが既にある場合は、[**S3 送信先の選択**] で、そのバケットを選択します。S3 バケットを作成するには、[**新しい S3 バケットの作成**] を選択します。
+ 監査ファイルを圧縮する場合は、[**圧縮の有効化**] オプションをオンにします。デフォルトでは、圧縮は有効になっています。圧縮を無効にするには、[**Enable Compression (圧縮の有効化)**] をオフにします。
+ DB インスタンスの監査レコードを保持するには、[**Audit log retention (監査ログの保持**)] オプションをオンにします。保持期間 (時間) を指定します。最大保持期間は 35 日間です。
1. 新規または既存の DB インスタンスに、DB オプショングループを適用します。次のいずれかを選択します。
+ 新しい DB インスタンスを作成する場合は、インスタンスを起動するときにオプショングループを適用します。
+ 既存の DB インスタンスで、インスタンスを変更し、新しいオプショングループをアタッチして、オプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
## SQL Server Audit オプションを変更する
SQL Server Audit オプションを有効にしたら、設定を変更できます。オプション設定の変更方法の詳細については、「[オプションの設定を変更する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.ModifyOption)」を参照してください。
## DB インスタンスオプションから SQL Server Audit を削除する
SQL Server Audit 機能をオフにするには、監査を無効にし、オプションを削除します。
**監査を削除するには**
1. SQL Server 内の監査設定をすべて無効にします。監査が実行されている場所を確認するには、SQL Server セキュリティカタログビューをクエリします。詳細については、Microsoft SQL Server ドキュメントの「[Security catalog views](https://docs.microsoft.com/sql/relational-databases/system-catalog-views/security-catalog-views-transact-sql)」を参照してください。
1. DB インスタンスから SQL Server Audit オプションを削除します。次のいずれかを選択します。
+ DB インスタンスで使用しているオプショングループから SQL Server Audit オプションを削除します。この変更は同じオプショングループを使用するすべての DB インスタンスに影響します。詳細については、「[オプショングループからオプションを削除する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.RemoveOption)」を参照してください。
+ DB インスタンスを変更し、オプショングループを選択します (SQL Server Audit オプションはオフ)。この変更は、変更した DB インスタンスにのみ影響します。デフォルト (空) のオプショングループや別のカスタムオプショングループを指定できます。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
1. DB インスタンスから SQL Server Audit オプションを削除後、インスタンスを再起動する必要はありません。S3 バケットから不要な監査ファイルを削除します。
# SQL Server Audit を使用する
サーバー監査、サーバー監査の仕様、およびデータベース監査の仕様は、オンプレミスデータベースサーバーの場合と同じ方法で制御することができます。
## 監査の作成
サーバーの監査は、オンプレミスデータベースサーバーで作成した方法と同じ方法で作成することができます。サーバー監査の作成方法については、Microsoft SQL Server ドキュメントの「[CREATE SERVER AUDIT](https://docs.microsoft.com/sql/t-sql/statements/create-server-audit-transact-sql)」を参照してください。
エラーを回避するには、次の制限に準拠します。
+ インスタンスごとにサポートされるサーバー監査の最大数 50 を超えない。
+ データをバイナリファイルに書き込むように SQL Server に指示する。
+ サーバーの監査名のプリフィックスとして `RDS_` を使用しない。
+ `FILEPATH` で、`D:\rdsdbdata\SQLAudit` を指定する。
+ `MAXSIZE` で、2 MB～50 MB の間のサイズを指定する。
+ `MAX_ROLLOVER_FILES` または `MAX_FILES` を設定しない。
+ 監査レコードの書き込みに失敗した場合に DB インスタンスをシャットダウンするように SQL Server を構成しない。
## 監査仕様の作成
サーバー監査仕様とデータベース監査仕様は、オンプレミスデータベースサーバーで作成するのと同じ方法で作成します。監査仕様の作成方法については、Microsoft SQL Server のドキュメントの「[CREATE SERVER AUDIT SPECIFICATION](https://docs.microsoft.com/sql/t-sql/statements/create-server-audit-specification-transact-sql)」および「[CREATE DATABASE AUDIT SPECIFICATION](https://docs.microsoft.com/sql/t-sql/statements/create-database-audit-specification-transact-sql)」を参照してください。
エラーを回避するために、データベース監査仕様またはサーバー監査仕様の名前のプリフィックスとして `RDS_` を使用しないでください。
# 監査ログの表示
監査ログは `D:\rdsdbdata\SQLAudit` に格納されます。
ファイルがサイズ制限に達している場合に SQL Server が監査ログファイルへの書き込みを完了すると、Amazon RDS はファイルを S3 バケットにアップロードします。保持設定が有効になっている場合、Amazon RDS は、このファイルを保持フォルダ (`D:\rdsdbdata\SQLAudit\transmitted`) に移動します。
保持設定については、[SQL Server Audit を DB インスタンスオプションに追加する](Appendix.SQLServer.Options.Audit.Adding.md) を参照してください。
監査ログファイルがアップロードされるまで、監査レコードは DB インスタンスに維持されます。監査レコードを表示するには、次のコマンドを実行します。
```
SELECT *
FROM msdb.dbo.rds_fn_get_audit_file
('D:\rdsdbdata\SQLAudit\*.sqlaudit'
, default
, default )
```
同じコマンドを使用して、保持フォルダの監査レコードを表示するには、フィルタを `D:\rdsdbdata\SQLAudit\transmitted\*.sqlaudit` に変更します。
```
SELECT *
FROM msdb.dbo.rds_fn_get_audit_file
('D:\rdsdbdata\SQLAudit\transmitted\*.sqlaudit'
, default
, default )
```
## マルチ AZ インスタンスで SQL Server Audit を使用する
マルチ AZ インスタンスで、監査ログファイルを Amazon S3 に送信するためのプロセスは、単一 AZ インスタンスのプロセスと似ています。ただし、重要な相違点がいくつかあります。
+ データベース監査仕様オブジェクトはすべてのノードにレプリケートされます。
+ サーバー監査およびサーバー監査仕様は、セカンダリノードにはレプリケートされません。その代わりに、手動で作成または変更する必要があります。
サーバー監査またはサーバー監査仕様を両方のノードからキャプチャするには
1. サーバー監査またはサーバー監査仕様をプライマリノードに作成します。
1. セカンダリノードにフェイルオーバーし、セカンダリノードに同じ名前と GUID を持つサーバー監査仕様またはサーバー監査仕様を作成します。GUID を指定するには、`AUDIT_GUID` パラメータを使用します。
# S3 バケットを設定する
監査ログファイルは、DB インスタンスから S3 バケットに自動的にアップロードされます。監査ファイルのターゲットとして使用する S3 バケットには、以下の制限が適用されます。
+ DB インスタンスと同じ AWS リージョンおよび AWS アカウントにある必要があります。
+ 公開することは禁止されています。
+ バケット所有者は IAM ロール所有者でもある必要があります。
+ IAM ロールには、S3 バケットのサーバー側の暗号化に関連付けられたカスタマー管理の KMS キーに対するアクセス許可が必要です。
データを格納するために使用されるターゲットキーは、次の命名スキーマに従います: `amzn-s3-demo-bucket/key-prefix/instance-name/audit-name/node_file-name.ext`
**注記**
バケット名とキープレフィックス値の両方を (`S3_BUCKET_ARN`) オプションで設定します。
このスキーマは、以下の要素で構成されています。
+ ***amzn-s3-demo-bucket*** – S3 バケットの名前。
+ **`key-prefix`** - 監査ログに使用するカスタムキープレフィックス。
+ **`instance-name`** - Amazon RDS インスタンスの名前。
+ **`audit-name`** - 監査の名前。
+ **`node`** - 監査ログの出典であるノードの識別子 (`node1` または `node2`)。シングル AZ インスタンスには 1 つのノード、マルチ AZ インスタンスには 2 つのレプリケーションノードがあります。プライマリノードとセカンダリノードのロールは時間とともに変化するため、これらはプライマリノードとセカンダリノードではありません。その代わりに、ノード識別子はシンプルなラベルです。
+ **`node1`** - 初期のレプリケーションノード (シングル AZ には 1 つのノードのみがあります)。
+ ** 2 `node2`** -番目のレプリケーションノード (マルチ AZ には 2 つのノードがあります)。
+ **`file-name`** - ターゲットファイルの名前。ファイル名は SQL Server からそのまま取得されます。
+ **`ext`** - ファイルの拡張子 (`zip` または `sqlaudit`)。
+ **`zip`** - 圧縮が有効になっているかどうか (デフォルト)。
+ **`sqlaudit`** - 圧縮が無効になっているかどうか。
# SQL Server Audit の IAM ロールを手動で作成する
通常、新しいオプションを作成すると、AWS マネジメントコンソール は IAM ロールと IAM 信頼ポリシーを作成します。ただし、SQL Server Audits で使用する新しい IAM ロールを手動で作成して、必要に応じてその他の要件に合わせてカスタマイズできます。そのためには、Amazon RDS サービスで Amazon S3 バケットを使用できるように、IAM ロールを作成して、アクセス許可を委任します。この IAM ロールを作成したら、信頼ポリシーとアクセス許可ポリシーをアタッチします。信頼ポリシーを使用することで、Amazon RDS はこのロールを引き受けることができます。アクセス許可ポリシーでは、このロールが実行できるアクションを定義します。詳細については、*AWS Identity and Access Management ユーザーガイド*の[AWS のサービスに許可を委任するロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)を参照してください。
必要な信頼関係とアクセス許可ポリシーは、このセクションの例を使用して作成できます。
以下の例は、SQL Server Audit の信頼関係を示しています。この例では、*サービスプリンシパル* `rds.amazonaws.com` を使用して、RDS で S3 バケットに書き込めるようにしています。*サービスプリンシパル*は、サービスにアクセス許可を付与するために使用される識別子です。このように、いつでも `rds.amazonaws.com` にアクセス許可を付与できます。これにより、RDS はお客様に代わってアクションを実行できるようになります。サービスプリンシパルの詳細については、[AWS JSON ポリシーの要素: プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)を参照してください。
**Example SQL Server Audit の信頼関係**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
リソースベースの信頼関係では [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) および [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) のグローバル条件コンテキストキーを使用して、サービスに付与する特定のリソースへのアクセス許可を制限することをお勧めします。これは、[混乱した使節の問題](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)に対する最も効果的な保護方法です。
両方のグローバル条件コンテキストキーを使用し、`aws:SourceArn` 値にアカウント ID を含めます。この場合は、`aws:SourceAccount` 値と `aws:SourceArn` 値のアカウントは、同じステートメントで使用する場合、同じアカウント ID を使用する必要があります。
+ 単一リソースに対するクロスサービスアクセスが必要な場合は `aws:SourceArn` を使用します。
+ そのアカウント内の任意のリソースをクロスサービス使用に関連付けることを許可する場合、`aws:SourceAccount`を使用します。
信頼関係では、`aws:SourceArn` グローバル条件コンテキストキーに、必ず、ロールにアクセスするリソースの完全な Amazon リソースネーム (ARN) を使用します。SQL Server Audit の場合は、次の例に示すように、DB オプショングループと DB インスタンスの両方を必ず含めるようにしてください。
**Example SQL Server Audit のグローバル条件コンテキストキーとの信頼関係**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceArn": [
"arn:aws:rds:Region:my_account_ID:db:db_instance_identifier",
"arn:aws:rds:Region:my_account_ID:og:option_group_name"
]
}
}
}
]
}
```
SQL Server Audit のアクセス許可ポリシーの次の例では、Amazon S3 バケットの ARN を指定します。ARN を使用して、アクセス許可を付与する特定のアカウント、ユーザー、またはロールを識別します。ARN の使用の詳細については、[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) を参照してください。
**Example SQL Server Audit のアクセス許可ポリシー**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketACL",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:ListMultipartUploadParts",
"s3:AbortMultipartUpload"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/key_prefix/*"
}
]
}
```
**注記**
`s3:ListAllMyBuckets` アクションは、同じ AWS アカウントが S3 バケットと SQL Server DB インスタンスの両方を所有していることを確認するために必要です。このアクションは、アカウント内のバケットの名前を一覧表示します。
S3 バケットの名前空間はグローバルです。誤ってバケットを削除した場合は、別のユーザーが同じ名前のバケットを別のアカウントで作成できます。次に、SQL Server 監査データが新しいバケットに書き込まれます。
# Amazon RDS for SQL Server での SQL Server Analysis Services のサポート
Microsoft SQL Server Analysis Services (SSAS) は、Microsoft ビジネスインテリジェンス (MSBI) スイートの一部です。SSAS は、SQL Server 内にインストールされているオンライン分析処理 (OLAP) およびデータマイニングツールです。SSAS を使用してデータを分析し、ビジネス上の意思決定に役立てます。SSAS は、ビジネスインテリジェンス環境の一般的なクエリや計算用に最適化されているという点で、SQL Server リレーショナルデータベースとは異なります。
SSAS は、既存または新規の DB インスタンスに対してオンにすることができます。データベースエンジンと同じ DB インスタンスにインストールされます。SSAS の詳細については、Microsoft の [Analysis Services のドキュメント](https://docs.microsoft.com/en-us/analysis-services)を参照してください。
Amazon RDS は、次のバージョンで SQL Server スタンダードエディションおよびエンタープライズエディションの SSAS をサポートします。
+ 表形式モード:
+ SQL Server 2019、バージョン 15.00.4043.16.v1 以降
+ SQL Server 2017、バージョン 14.00.3223.3.v1 以降
+ SQL Server 2016、バージョン 13.00.5426.0.v1 以降
+ 多次元モード:
+ SQL Server 2019、バージョン 15.00.4153.1.v1 以降
+ SQL Server 2017、バージョン 14.00.3381.3.v1 以降
+ SQL Server 2016、バージョン 13.00.5882.1.v1 以降
**Contents**
+ [制約事項](#SSAS.Limitations)
+ [SSAS をオンにする](SSAS.Enabling.md)
+ [SSAS のオプショングループの作成](SSAS.Enabling.md#SSAS.OptionGroup)
+ [SSAS オプションをオプショングループに追加する](SSAS.Enabling.md#SSAS.Add)
+ [オプショングループを DB インスタンスに関連付ける](SSAS.Enabling.md#SSAS.Apply)
+ [VPC セキュリティグループへのインバウンドアクセスの許可](SSAS.Enabling.md#SSAS.InboundRule)
+ [Amazon S3 統合の有効化](SSAS.Enabling.md#SSAS.EnableS3)
+ [Amazon RDS への SSAS プロジェクトのデプロイ](SSAS.Deploy.md)
+ [デプロイタスクのステータスのモニタリング](SSAS.Monitor.md)
+ [Amazon RDS での SSAS の使用](SSAS.Use.md)
+ [SSAS 用の Windows 認証ユーザーの設定](SSAS.Use.md#SSAS.Use.Auth)
+ [データベース管理者としてのドメインユーザーの追加](SSAS.Use.md#SSAS.Admin)
+ [SSAS プロキシの作成](SSAS.Use.md#SSAS.Use.Proxy)
+ [SQL Server エージェントを使用した SSAS データベース処理のスケジュール](SSAS.Use.md#SSAS.Use.Schedule)
+ [プロキシからの SSAS アクセスの取り消し](SSAS.Use.md#SSAS.Use.Revoke)
+ [SSAS データベースのバックアップ](SSAS.Backup.md)
+ [SSAS データベースの復元](SSAS.Restore.md)
+ [特定の時点への DB インスタンスの復元](SSAS.Restore.md#SSAS.PITR)
+ [SSAS モードの変更](SSAS.ChangeMode.md)
+ [SSAS をオフにする](SSAS.Disable.md)
+ [SSAS の問題のトラブルシューティング](SSAS.Trouble.md)
## 制約事項
RDS for SQL Server で SSAS を使用する場合は、次の制限が適用されます。
+ RDS for SQL Server は、表形式モードまたは多次元モードでの SSAS の実行をサポートしています。詳細については、Microsoft のドキュメントの「[テーブルソリューションと多次元ソリューションの比較](https://docs.microsoft.com/en-us/analysis-services/comparing-tabular-and-multidimensional-solutions-ssas)」を参照してください。
+ 一度に使用できる SSAS モードは 1 つだけです。モードを変更する前に、すべての SSAS データベースを必ず削除してください。
詳細については、「[SSAS モードの変更](SSAS.ChangeMode.md)」を参照してください。
+ マルチ AZ インスタンスはサポートされていません。
+ インスタンスは自己管理型の Active Directory または AWS Directory Service for Microsoft Active Directory for SSAS 認証を使用する必要があります。詳細については、「[RDS for SQL Server による Active Directory の操作](User.SQLServer.ActiveDirectoryWindowsAuth.md)」を参照してください。
+ ユーザーには、SSAS サーバーの管理者アクセス権は付与されませんが、データベースレベルの管理者アクセス権が付与されます。
+ SSAS へのアクセスにサポートされているポートは 2383 のみです。
+ プロジェクトを直接デプロイすることはできません。これを行うには、用意されている RDS ストアドプロシージャを使用できます。詳細については、「[Amazon RDS への SSAS プロジェクトのデプロイ](SSAS.Deploy.md)」を参照してください。
+ デプロイ中の処理はサポートされていません。
+ デプロイでの .xmla ファイルの使用はサポートされていません。
+ SSAS のプロジェクト入力ファイルとデータベースバックアップ出力ファイルは、DB インスタンスの `D:\S3` フォルダにのみ配置できます。
# SSAS をオンにする
DB インスタンスの SSAS をオンにするには、次のプロセスを使用します。
1. 新しいオプショングループを作成するか、既存のオプショングループを選択します。
1. オプショングループに [`SSAS`] オプションを追加します。
1. オプショングループを DB インスタンスに関連付けます。
1. SSAS リスナーポートの仮想プライベートクラウド (VPC) セキュリティグループへのインバウンドアクセスを許可します。
1. Amazon S3 統合をオンにします。
## SSAS のオプショングループの作成
AWS マネジメントコンソール または AWS CLI を使用して、使用する DB インスタンスの SQL Server エンジンおよびバージョンに対応するオプショングループを作成します。
**注記**
既存のオプショングループが正しい SQL Server エンジンおよびバージョンに対応している場合は、それを使用することもできます。
### コンソール
次の手順では、コンソールを使用して SQL Server Standard Edition 2017 のオプショングループを作成します。
**オプショングループを作成するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. **[Create group]** (グループの作成) を選択します。
1. [**オプショングループの作成**] ウィンドウで、次の操作を行います。
1. [**名前**] に、AWS アカウント内で一意のオプショングループ名 (**ssas-se-2017** など) を入力します。名前には、英字、数字、ハイフンのみを使用できます。
1. [**説明**] に、オプショングループの簡単な説明 (**SSAS option group for SQL Server SE 2017** など) を入力します。この説明は表示用に使用されます。
1. [**エンジン**] で [**sqlserver-se**] を選択します。
1. [**メジャーエンジンのバージョン**] で、[**14.00**] を選択します。
1. [**Create**] (作成) を選択します。
### CLI
次の例では、CLI を使用して SQL Server Standard Edition 2017 のオプショングループを作成します。
**オプショングループを作成するには**
+ 以下のいずれかのコマンドを使用します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds create-option-group \
--option-group-name ssas-se-2017 \
--engine-name sqlserver-se \
--major-engine-version 14.00 \
--option-group-description "SSAS option group for SQL Server SE 2017"
```
Windows の場合:
```
aws rds create-option-group ^
--option-group-name ssas-se-2017 ^
--engine-name sqlserver-se ^
--major-engine-version 14.00 ^
--option-group-description "SSAS option group for SQL Server SE 2017"
```
## SSAS オプションをオプショングループに追加する
次に、AWS マネジメントコンソール または AWS CLI を使用して `SSAS` オプションをオプショングループに追加します。
### コンソール
**SSAS オプションを追加するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. 先ほど作成したオプショングループを選択します。
1. [**オプションの追加**] を選択します。
1. [**オプションの詳細**] で、[**オプション名**] として **SSAS** を選択します。
1. [**オプション設定**] で、次の操作を行います。
1. **[Max memory]** (最大メモリ) に、10～80 の範囲の値を入力します。
[**最大メモリ**] は、メモリの上限しきい値を指定します。この値を超えると、実行中のリクエスト用と新しい優先順位の高いリクエスト用のスペースを確保するために、SSAS がメモリの解放を積極的にスタートします。この値は、DB インスタンスの合計メモリに対する割合 (%) です。指定できる値は 10〜80 で、デフォルトは 45 です。
1. **[Mode]** (モード) で、SSAS サーバーモードとして **[Tabular]** (表形式) または **[Multidimensional]** (多次元) を選択します。
**[Mode]** (モード) オプション設定が表示されない場合は、自身の AWS リージョンで多次元モードがサポートされていないことを意味します。詳細については、「[制約事項](Appendix.SQLServer.Options.SSAS.md#SSAS.Limitations)」を参照してください。
**[Tabular]** (表形式) はデフォルトです。
1. **[セキュリティグループ]** で、オプションに関連付ける VPC セキュリティグループを選択します。
**注記**
SSAS にアクセスするためのポート 2383 は事前に設定されています。
1. **[スケジュール]** で、オプションをすぐに追加するか、次のメンテナンスウィンドウで追加するかを選択します。
1. **[オプションを追加]** を選択します。
### CLI
**SSAS オプションを追加するには**
1. 次のパラメータを使用して JSON ファイル (`ssas-option.json` など) を作成します。
+ `OptionGroupName` - 以前に作成または選択したオプショングループの名前 (次の例では `ssas-se-2017`)。
+ `Port` - SSAS にアクセスするために使用するポート。サポートされているポートは 2383 のみです。
+ `VpcSecurityGroupMemberships` – RDS DB インスタンスの VPC セキュリティグループのメンバーシップ。
+ `MAX_MEMORY` - メモリの上限しきい値。この値を超えると、実行中のリクエスト用および新しい優先順位の高いリクエスト用のスペースを確保するために、SSAS がメモリの解放を積極的にスタートします。この値は、DB インスタンスの合計メモリに対する割合 (%) です。指定できる値は 10〜80 で、デフォルトは 45 です。
+ `MODE` – SSAS サーバモード。`Tabular` または `Multidimensional`。`Tabular` がデフォルトです。
`MODE` オプション設定が有効ではないというエラーは、多次元モードが自身の AWS リージョンでサポートされていないという意味です。詳細については、「[制約事項](Appendix.SQLServer.Options.SSAS.md#SSAS.Limitations)」を参照してください。
SSAS オプション設定を含む JSON ファイルの例を次に示します。
```
{
"OptionGroupName": "ssas-se-2017",
"OptionsToInclude": [
{
"OptionName": "SSAS",
"Port": 2383,
"VpcSecurityGroupMemberships": ["sg-0abcdef123"],
"OptionSettings": [{"Name":"MAX_MEMORY","Value":"60"},{"Name":"MODE","Value":"Multidimensional"}]
}],
"ApplyImmediately": true
}
```
1. オプショングループに [`SSAS`] オプションを追加します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds add-option-to-option-group \
--cli-input-json file://ssas-option.json \
--apply-immediately
```
Windows の場合:
```
aws rds add-option-to-option-group ^
--cli-input-json file://ssas-option.json ^
--apply-immediately
```
## オプショングループを DB インスタンスに関連付ける
コンソールまたは CLI を使用して、オプショングループを DB インスタンスに関連付けることができます。
### コンソール
オプショングループを新規または既存の DB インスタンスに関連付けます。
+ 新規の DB インスタンスの場合は、DB インスタンスの起動時にオプショングループを DB インスタンスと関連付けます。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の DB インスタンスの場合は、DB インスタンスを変更してから、新しいオプショングループと関連付けます。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
**注記**
既存のインスタンスを使用する場合は、このインスタンスに Active Directory ドメインと AWS Identity and Access Management (IAM) ロールが既に関連付けられている必要があります。新しいインスタンスを作成する場合は、既存の Active Directory ドメインと IAM ロールを指定します。詳細については、「[RDS for SQL Server による Active Directory の操作](User.SQLServer.ActiveDirectoryWindowsAuth.md)」を参照してください。
### CLI
オプショングループを新規または既存の DB インスタンスに関連付けることができます。
**注記**
既存のインスタンスを使用する場合は、このインスタンスに Active Directory ドメインと IAM ロールが既に関連付けられている必要があります。新しいインスタンスを作成する場合は、既存の Active Directory ドメインと IAM ロールを指定します。詳細については、「[RDS for SQL Server による Active Directory の操作](User.SQLServer.ActiveDirectoryWindowsAuth.md)」を参照してください。
**オプショングループを使用する DB インスタンスを作成するには**
+ オプショングループの作成時に使用したのと同じ DB エンジンのタイプとメジャーバージョンを指定します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds create-db-instance \
--db-instance-identifier myssasinstance \
--db-instance-class db.m5.2xlarge \
--engine sqlserver-se \
--engine-version 14.00.3223.3.v1 \
--allocated-storage 100 \
--manage-master-user-password \
--master-username admin \
--storage-type gp2 \
--license-model li \
--domain-iam-role-name my-directory-iam-role \
--domain my-domain-id \
--option-group-name ssas-se-2017
```
Windows の場合:
```
aws rds create-db-instance ^
--db-instance-identifier myssasinstance ^
--db-instance-class db.m5.2xlarge ^
--engine sqlserver-se ^
--engine-version 14.00.3223.3.v1 ^
--allocated-storage 100 ^
--manage-master-user-password ^
--master-username admin ^
--storage-type gp2 ^
--license-model li ^
--domain-iam-role-name my-directory-iam-role ^
--domain my-domain-id ^
--option-group-name ssas-se-2017
```
**DB インスタンスを変更してオプショングループを関連付けるには**
+ 以下のいずれかのコマンドを使用します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance \
--db-instance-identifier myssasinstance \
--option-group-name ssas-se-2017 \
--apply-immediately
```
Windows の場合:
```
aws rds modify-db-instance ^
--db-instance-identifier myssasinstance ^
--option-group-name ssas-se-2017 ^
--apply-immediately
```
## VPC セキュリティグループへのインバウンドアクセスの許可
DB インスタンスに関連付けられた VPC セキュリティグループで、指定した SSAS リスナーポートのインバウンドルールを作成します。セキュリティグループの設定の詳細については、「[セキュリティグループを作成して VPC 内の DB インスタンスへのアクセスを提供する](CHAP_SettingUp.md#CHAP_SettingUp.SecurityGroup)」を参照してください。
## Amazon S3 統合の有効化
モデル設定ファイルをホストにダウンロードしてデプロイするには、Amazon S3 統合を使用します。詳細については、「[Amazon RDS for SQL Server DB インスタンスと Amazon S3 の統合](User.SQLServer.Options.S3-integration.md)」を参照してください。
# Amazon RDS への SSAS プロジェクトのデプロイ
RDS では、SQL Server Management Studio (SSMS) を使用して SSAS プロジェクトを直接デプロイすることはできません。プロジェクトをデプロイするには、RDS ストアドプロシージャを使用します。
**注記**
デプロイでの .xmla ファイルの使用はサポートされていません。
プロジェクトをデプロイする前に、以下を確認してください。
+ Amazon S3 統合がオンになっている。詳細については、「[Amazon RDS for SQL Server DB インスタンスと Amazon S3 の統合](User.SQLServer.Options.S3-integration.md)」を参照してください。
+ `Processing Option` 構成設定が `Do Not Process` に設定されている。この設定は、デプロイ後に処理が実行されないことを意味します。
+ `myssasproject.asdatabase` ファイルと `myssasproject.deploymentoptions` ファイルの両方がある。これらは、SSAS プロジェクトの構築時に自動的に生成されます。
**SSAS プロジェクトを RDS にデプロイするには**
1. 次の例に示すように、`.asdatabase` (SSAS モデル) を S3 バケットから DB インスタンスにダウンロードします。ダウンロードパラメータの詳細については、「[Amazon S3 バケットから SQL Server DB インスタンスにファイルをダウンロードする](Appendix.SQLServer.Options.S3-integration.using.md#Appendix.SQLServer.Options.S3-integration.using.download)」を参照してください。
```
exec msdb.dbo.rds_download_from_s3
@s3_arn_of_file='arn:aws:s3:::bucket_name/myssasproject.asdatabase',
[@rds_file_path='D:\S3\myssasproject.asdatabase'],
[@overwrite_file=1];
```
1. `.deploymentoptions` ファイルを S3 バケットから DB インスタンスにダウンロードします。
```
exec msdb.dbo.rds_download_from_s3
@s3_arn_of_file='arn:aws:s3:::bucket_name/myssasproject.deploymentoptions',
[@rds_file_path='D:\S3\myssasproject.deploymentoptions'],
[@overwrite_file=1];
```
1. プロジェクトをデプロイします。
```
exec msdb.dbo.rds_msbi_task
@task_type='SSAS_DEPLOY_PROJECT',
@file_path='D:\S3\myssasproject.asdatabase';
```
# デプロイタスクのステータスのモニタリング
デプロイ (またはダウンロード) タスクのステータスを追跡するには、`rds_fn_task_status` 関数を呼び出します。2 つのパラメータを使用します。1 つめのパラメータは、SSAS に適用されないため、常に `NULL` を設定してください。2 つめのパラメータは、タスク ID を受け入れます。
全タスクのリストを見るには、以下の例にあるように、初期のパラメータを `NULL` に設定し、2 つめのパラメータを `0` に設定します。
```
SELECT * FROM msdb.dbo.rds_fn_task_status(NULL,0);
```
特定のタスクを受け取るには、以下の例にあるように、初期のパラメータを `NULL` に設定し、2 つめのパラメータをタスク ID に設定します。
```
SELECT * FROM msdb.dbo.rds_fn_task_status(NULL,42);
```
`rds_fn_task_status` 機能は次の情報を返します。
| 出力パラメータ | 説明 |
| --- | --- |
| `task_id` | タスクの ID。 |
| `task_type` | SSAS では、次のタスクタイプを使用できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/SSAS.Monitor.html) |
| `database_name` | SSAS タスクは該当しません。 |
| `% complete` | タスクの進行状況の割合。 |
| `duration (mins)` | タスクにかかった時間 (分単位)。 |
| `lifecycle` | タスクのステータス。有効な状態には以下のものがあります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/SSAS.Monitor.html) |
| `task_info` | タスクに関する追加情報。処理中にエラーが発生した場合、この列にエラーに関する情報が含まれます。 詳細については、「[SSAS の問題のトラブルシューティング](SSAS.Trouble.md)」を参照してください。 |
| `last_updated` | タスクのステータスが最後に更新された日時。 |
| `created_at` | タスクが作成された日時。 |
| `S3_object_arn` | SSAS タスクは該当しません。 |
| `overwrite_S3_backup_file` | SSAS タスクは該当しません。 |
| `KMS_master_key_arn` | SSAS タスクは該当しません。 |
| `filepath` | SSAS タスクは該当しません。 |
| `overwrite_file` | SSAS タスクは該当しません。 |
| `task_metadata` | SSAS タスクに関連付けられたメタデータ。 |
# Amazon RDS での SSAS の使用
SSAS プロジェクトをデプロイすると、SSMS で OLAP データベースを直接処理できます。
**RDS で SSAS を使用するには**
1. SSMS で、Active Directory ドメインのユーザー名とパスワードを使用して SSAS に接続します。
1. [**データベース**] を展開します。新しくデプロイした SSAS データベースが表示されます。
1. 接続文字列を見つけて、ユーザー名とパスワードを、ソース SQL データベースにアクセスできるように更新します。この操作は、SSAS オブジェクトを処理するために必要です。
1. 表形式モードの場合、次の操作を行います。
1. **[Connections]** (接続) タブを展開します。
1. 右クリックで接続オブジェクトのメニューを開き、**[Properties]** (プロパティ) を選択します。
1. 接続文字列のユーザー名とパスワードを更新します。
1. 多次元モードの場合、次の操作を行います。
1. **[Data Sources]** (データソース) タブを展開します。
1. 右クリックでデータソースオブジェクトのメニューを開き、**[Properties]** (プロパティ) を選択します。
1. 接続文字列のユーザー名とパスワードを更新します。
1. 作成した SSAS データベースのコンテキスト (右クリック) メニューを開き、[**データベースの処理**] を選択します。
入力データのサイズによっては、処理オペレーションが完了するまでに数分かかる場合があります。
**Topics**
+ [SSAS 用の Windows 認証ユーザーの設定](#SSAS.Use.Auth)
+ [データベース管理者としてのドメインユーザーの追加](#SSAS.Admin)
+ [SSAS プロキシの作成](#SSAS.Use.Proxy)
+ [SQL Server エージェントを使用した SSAS データベース処理のスケジュール](#SSAS.Use.Schedule)
+ [プロキシからの SSAS アクセスの取り消し](#SSAS.Use.Revoke)
## SSAS 用の Windows 認証ユーザーの設定
メイン管理者ユーザー (マスターユーザーと呼ばれることもあります) は、以下のコード例を使用して、Windows 認証ログインを設定し、必要な手順に対するアクセス許可を付与できます。これにより、ドメインユーザーに SSAS カスタマータスクの実行、S3 ファイル転送手順の使用、認証情報の作成、および SQL Server エージェントプロキシの操作を行うアクセス許可が付与されます。詳細については、Microsoft ドキュメントの「[Credentials (Database Engine)](https://docs.microsoft.com/en-us/sql/relational-databases/security/authentication-access/credentials-database-engine?view=sql-server-ver15)」および「[Create a SQL Server Agent Proxy](https://docs.microsoft.com/en-us/sql/ssms/agent/create-a-sql-server-agent-proxy?view=sql-server-ver15)」を参照してください。
必要に応じて、Windows 認証ユーザーに以下のアクセス許可の一部またはすべてを付与できます。
**Example**
```
-- Create a server-level domain user login, if it doesn't already exist
USE [master]
GO
CREATE LOGIN [mydomain\user_name] FROM WINDOWS
GO
-- Create domain user, if it doesn't already exist
USE [msdb]
GO
CREATE USER [mydomain\user_name] FOR LOGIN [mydomain\user_name]
GO
-- Grant necessary privileges to the domain user
USE [master]
GO
GRANT ALTER ANY CREDENTIAL TO [mydomain\user_name]
GO
USE [msdb]
GO
GRANT EXEC ON msdb.dbo.rds_msbi_task TO [mydomain\user_name] with grant option
GRANT SELECT ON msdb.dbo.rds_fn_task_status TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_task_status TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_cancel_task TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_download_from_s3 TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_upload_to_s3 TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_delete_from_filesystem TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_gather_file_details TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_add_proxy TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_update_proxy TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_grant_login_to_proxy TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_revoke_login_from_proxy TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_delete_proxy TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_enum_login_for_proxy to [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_enum_proxy_for_subsystem TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_sqlagent_proxy TO [mydomain\user_name] with grant option
ALTER ROLE [SQLAgentUserRole] ADD MEMBER [mydomain\user_name]
GO
```
## データベース管理者としてのドメインユーザーの追加
次の方法で、ドメインユーザーを SSAS データベース管理者として追加できます。
+ データベース管理者は、SSMS を使用して `admin` 権限を持つロールを作成し、そのロールにユーザーを追加できます。
+ 次のストアドプロシージャを使用できます。
```
exec msdb.dbo.rds_msbi_task
@task_type='SSAS_ADD_DB_ADMIN_MEMBER',
@database_name='myssasdb',
@ssas_role_name='exampleRole',
@ssas_role_member='domain_name\domain_user_name';
```
以下のパラメータは必須です。
+ `@task_type` - MSBI タスクのタイプ (この例では `SSAS_ADD_DB_ADMIN_MEMBER`)。
+ `@database_name` - 管理者権限を付与する先の SSAS データベースの名前。
+ `@ssas_role_name` - SSAS データベース管理者ロールの名前。ロールがまだ存在しない場合は、作成されます。
+ `@ssas_role_member` - 管理者ロールに追加する SSAS データベースユーザー。
## SSAS プロキシの作成
SQL Server エージェントを使用して SSAS データベース処理をスケジュールできるようにするには、SSAS 認証情報と SSAS プロキシを作成します。これらの手順を Windows 認証ユーザーとして実行します。
**SSAS 認証情報を作成するには**
+ プロキシの認証情報を作成します。そのためには、SSMS または以下の SQL ステートメントを使用できます。
```
USE [master]
GO
CREATE CREDENTIAL [SSAS_Credential] WITH IDENTITY = N'mydomain\user_name', SECRET = N'mysecret'
GO
```
**注記**
`IDENTITY` はドメイン認証ログインであることが必要です。`mysecret` をドメイン認証ログインのパスワードに置き換えます。
**SSAS プロキシを作成するには**
1. 以下の SQL ステートメントを使用して、プロキシを作成します。
```
USE [msdb]
GO
EXEC msdb.dbo.sp_add_proxy @proxy_name=N'SSAS_Proxy',@credential_name=N'SSAS_Credential',@description=N''
GO
```
1. 以下の SQL ステートメントを使用して、他のユーザーにプロキシへのアクセスを許可します。
```
USE [msdb]
GO
EXEC msdb.dbo.sp_grant_login_to_proxy @proxy_name=N'SSAS_Proxy',@login_name=N'mydomain\user_name'
GO
```
1. 以下の SQL ステートメントを使用して、SSAS サブシステムにプロキシへのアクセスを許可します。
```
USE [msdb]
GO
EXEC msdb.dbo.rds_sqlagent_proxy @task_type='GRANT_SUBSYSTEM_ACCESS',@proxy_name='SSAS_Proxy',@proxy_subsystem='SSAS'
GO
```
**プロキシとそのプロキシに対する許可を表示するには**
1. 以下の SQL ステートメントを使用して、プロキシの被付与者を表示します。
```
USE [msdb]
GO
EXEC sp_help_proxy
GO
```
1. 以下の SQL ステートメントを使用して、サブシステムの許可を表示します。
```
USE [msdb]
GO
EXEC msdb.dbo.sp_enum_proxy_for_subsystem
GO
```
## SQL Server エージェントを使用した SSAS データベース処理のスケジュール
認証情報とプロキシを作成し、SSAS にプロキシへのアクセスを許可したら、SQL Server エージェントジョブを作成して SSAS データベース処理をスケジュールできます。
**SSAS データベース処理をスケジュールするには**
+ SSMS または T-SQL を使用して、SQL Server エージェントジョブを作成します。以下の例では T-SQL を使用しています。SSMS または T-SQL を使用して、ジョブスケジュールをさらに設定できます。
+ `@command` パラメータは、SQL Server エージェントジョブによって実行される XML for Analysis (XMLA) コマンドの概要を示します。この例では、SSAS 多次元データベース処理を設定します。
+ `@server` パラメータは、SQL Server エージェントジョブのターゲット SSAS サーバー名の概要を示しています。
SQL Server エージェントジョブが存在する同じ RDS DB インスタンス内で SSAS サービスを呼び出すには、`localhost:2383` を使用します。
RDS DB インスタンスの外部から SSAS サービスを呼び出すには、RDS エンドポイントを使用します。RDS DB インスタンスが同じドメインで参加している場合、Kerberos Active Directory (AD) エンドポイント (`your-DB-instance-name.your-AD-domain-name`) も使用できます。外部 DB インスタンスの場合は、RDS DB インスタンスに関連付けられた VPC セキュリティグループをセキュアな接続用に適切に設定してください。
クエリをさらに編集して、さまざまな XMLA オペレーションをサポートできます。T-SQL クエリを直接変更するか、SQL Server エージェントジョブの作成後に SSMS UI を使用して編集を行います。
```
USE [msdb]
GO
DECLARE @jobId BINARY(16)
EXEC msdb.dbo.sp_add_job @job_name=N'SSAS_Job',
@enabled=1,
@notify_level_eventlog=0,
@notify_level_email=0,
@notify_level_netsend=0,
@notify_level_page=0,
@delete_level=0,
@category_name=N'[Uncategorized (Local)]',
@job_id = @jobId OUTPUT
GO
EXEC msdb.dbo.sp_add_jobserver
@job_name=N'SSAS_Job',
@server_name = N'(local)'
GO
EXEC msdb.dbo.sp_add_jobstep @job_name=N'SSAS_Job', @step_name=N'Process_SSAS_Object',
@step_id=1,
@cmdexec_success_code=0,
@on_success_action=1,
@on_success_step_id=0,
@on_fail_action=2,
@on_fail_step_id=0,
@retry_attempts=0,
@retry_interval=0,
@os_run_priority=0, @subsystem=N'ANALYSISCOMMAND',
@command=N'
ProcessFull
UseExisting
',
@server=N'localhost:2383',
@database_name=N'master',
@flags=0,
@proxy_name=N'SSAS_Proxy'
GO
```
## プロキシからの SSAS アクセスの取り消し
以下のストアドプロシージャを使用して、SSAS サブシステムへのアクセスを取り消し、SSAS プロキシを削除できます。
**アクセスを取り消してプロキシを削除するには**
1. サブシステムのアクセスを取り消します。
```
USE [msdb]
GO
EXEC msdb.dbo.rds_sqlagent_proxy @task_type='REVOKE_SUBSYSTEM_ACCESS',@proxy_name='SSAS_Proxy',@proxy_subsystem='SSAS'
GO
```
1. プロキシに対する許可を取り消します。
```
USE [msdb]
GO
EXEC msdb.dbo.sp_revoke_login_from_proxy @proxy_name=N'SSAS_Proxy',@name=N'mydomain\user_name'
GO
```
1. プロキシを削除します。
```
USE [msdb]
GO
EXEC dbo.sp_delete_proxy @proxy_name = N'SSAS_Proxy'
GO
```
# SSAS データベースのバックアップ
SSAS データベースのバックアップファイルは、DB インスタンスの `D:\S3` フォルダにのみ作成できます。バックアップファイルを S3 バケットに移動するには、Amazon S3 を使用します。
SSAS データベースをバックアップするには、次のようにします。
+ 特定のデータベースに対する `admin` ロールを持つドメインユーザーは、SSMS を使用してデータベースを `D:\S3` フォルダにバックアップできます。
詳細については、「[データベース管理者としてのドメインユーザーの追加](SSAS.Use.md#SSAS.Admin)」を参照してください。
+ 次のストアドプロシージャを使用できます。このストアドプロシージャは、暗号化をサポートしていません。
```
exec msdb.dbo.rds_msbi_task
@task_type='SSAS_BACKUP_DB',
@database_name='myssasdb',
@file_path='D:\S3\ssas_db_backup.abf',
[@ssas_apply_compression=1],
[@ssas_overwrite_file=1];
```
以下のパラメータは必須です。
+ `@task_type` - MSBI タスクのタイプ (この例では `SSAS_BACKUP_DB`)。
+ `@database_name` - バックアップする SSAS データベースの名前。
+ `@file_path` - SSAS バックアップファイルのパス。`.abf` 拡張子は必須です。
以下のパラメータはオプションです。
+ `@ssas_apply_compression` - SSAS バックアップを圧縮するかどうか。有効な値は 1 (はい) と 0 (いいえ) です。
+ `@ssas_overwrite_file` - SSAS バックアップファイルを上書きするかどうか。有効な値は 1 (はい) と 0 (いいえ) です。
# SSAS データベースの復元
SSAS データベースをバックアップから復元するには、次のストアドプロシージャを使用します。
同じ名前の既存の SSAS データベースがある場合は、データベースを復元できません。復元用のストアドプロシージャは、暗号化されたバックアップファイルをサポートしていません。
```
exec msdb.dbo.rds_msbi_task
@task_type='SSAS_RESTORE_DB',
@database_name='mynewssasdb',
@file_path='D:\S3\ssas_db_backup.abf';
```
以下のパラメータは必須です。
+ `@task_type` - MSBI タスクのタイプ (この例では `SSAS_RESTORE_DB`)。
+ `@database_name` - 復元先の新しい SSAS データベースの名前。
+ `@file_path` - SSAS バックアップファイルへのパス。
## 特定の時点への DB インスタンスの復元
ポイントインタイムリカバリ (PITR) は SSAS データベースには適用されません。PITR を実行すると、復元されたインスタンスでは、リクエストした時刻より前の最後のスナップショットの SSAS データのみを使用できます。
**復元された DB インスタンスで最新の SSAS データベースを使用するには**
1. SSAS データベースを出典インスタンスの `D:\S3` フォルダにバックアップします。
1. バックアップファイルを S3 バケットに転送します。
1. S3 バケットから復元されたインスタンスの `D:\S3` フォルダにバックアップファイルを転送します。
1. 復元されたインスタンスに SSAS データベースを復元するためのストアドプロシージャを実行します。
SSAS プロジェクトを再処理してデータベースを復元することもできます。
# SSAS モードの変更
SSAS の実行モードは、表形式または多次元に変更できます。モードを変更するには、AWS マネジメントコンソール または AWS CLI を使用して、SSAS オプションのオプション設定を変更します。
**重要**
一度に使用できる SSAS モードは 1 つだけです。モードを変更する前に、必ずすべての SSAS データベースを削除してください。そうしないと、エラーが発生します。
## コンソール
次の Amazon RDS コンソールの手順では、SSAS モードを表形式に変更し、`MAX_MEMORY` パラメータを 70% にします。
**SSAS オプションを変更するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. `SSAS` オプションで、変更するオプショングループ (前の例では`ssas-se-2017`) を選択します。
1. **[Modify option]** (オプションの変更) を選択します。
1. オプション設定を次のように変更します。
1. **[Max memory]** (最大メモリ) に、**70** を入力します。
1. **[Mode]** (モード) で、**[Tabular]** (表形式) を選択します。
1. **[Modify option]** (オプションの変更) を選択します。
## AWS CLI
次の AWS CLI の例では、SSAS モードを表形式に変更し、`MAX_MEMORY` パラメータを 70% に設定します。
CLI コマンドが機能するためには、変更していない場合でも、必要なパラメータをすべて含めてください。
**SSAS オプションを変更するには**
+ 以下のいずれかのコマンドを使用します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds add-option-to-option-group \
--option-group-name ssas-se-2017 \
--options "OptionName=SSAS,VpcSecurityGroupMemberships=sg-12345e67,OptionSettings=[{Name=MAX_MEMORY,Value=70},{Name=MODE,Value=Tabular}]" \
--apply-immediately
```
Windows の場合:
```
aws rds add-option-to-option-group ^
--option-group-name ssas-se-2017 ^
--options OptionName=SSAS,VpcSecurityGroupMemberships=sg-12345e67,OptionSettings=[{Name=MAX_MEMORY,Value=70},{Name=MODE,Value=Tabular}] ^
--apply-immediately
```
# SSAS をオフにする
SSAS をオフにするには、オプショングループから `SSAS` オプションを削除します。
**重要**
`SSAS` オプションを削除する前に、SSAS データベースを削除します。
SSAS データベースを削除して `SSAS` オプションを削除する前に、SSAS データベースをバックアップすることを強くお勧めします。
## コンソール
**SSAS オプションをオプショングループから削除するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. `SSAS` オプションで、削除するオプショングループ (前の例では `ssas-se-2017`) を選択します。
1. [**オプションの削除**] を選択します。
1. [**オプションの削除**] で、[**削除するオプション**] として [**SSAS**] を選択します。
1. [**すぐに適用**] で、オプションをすぐに削除する場合は [**はい**] を選択し、次のメンテナンスウィンドウで削除する場合は [**いいえ**] を選択します。
1. [**削除**] を選択します。
## AWS CLI
**SSAS オプションをオプショングループから削除するには**
+ 以下のいずれかのコマンドを使用します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds remove-option-from-option-group \
--option-group-name ssas-se-2017 \
--options SSAS \
--apply-immediately
```
Windows の場合:
```
aws rds remove-option-from-option-group ^
--option-group-name ssas-se-2017 ^
--options SSAS ^
--apply-immediately
```
# SSAS の問題のトラブルシューティング
SSAS の使用時に、次の問題が発生することがあります。
| 問題 | タイプ | トラブルシューティングの推奨事項 |
| --- | --- | --- |
| SSAS オプションを設定できません。要求された SSAS モードは new\$1mode ですが、現在の DB インスタンスには number 個の current\$1mode データベースがあります。new\$1mode モードに切り替える前に既存のデータベースを削除します。データベースを削除するために current\$1mode モードへのアクセスを取り戻すには、現在の DB オプショングループを更新するか、SSAS オプションの MODE オプション設定値として %s を使用して新しいオプショングループをアタッチします。 | RDS イベント | 現在のモードを使用する SSAS データベースがまだある場合は、SSAS モードを変更できません。SSAS データベースを削除してから、もう一度試してください。 |
| number 個の既存 mode のデータベースがあるため、SSAS オプションを削除できません。SSAS オプションは、すべての SSAS データベースが削除されるまで削除できません。SSAS オプションを再度追加し、すべての SSAS データベースを削除して、もう一度試してください。 | RDS イベント | SSAS データベースがまだある場合は、SSAS をオフにすることはできません。SSAS データベースを削除してから、もう一度試してください。 |
| SSAS オプションが有効になっていないか、有効化中です。後ほどもう一度試してください。」 | RDS ストアドプロシージャ | SSAS ストアドプロシージャは、このオプションがオフになっているときやオンになる途中のときには実行できません。 |
| SSAS オプションが正しく設定されていません。オプショングループのメンバーシップステータスが「in-sync」であることを確認し、RDS イベントログで関連する SSAS 設定エラーメッセージを確認します。これらを調べてから、もう一度試してください。エラーが引き続き発生する場合は、AWS サポートにお問い合わせください。 | RDS ストアドプロシージャ | オプショングループのメンバーシップが `in-sync` ステータスでないときは、SSAS ストアドプロシージャを実行できません。これにより、SSAS オプションは誤った設定状態になります。 SSAS オプションの変更により、オプショングループのメンバーシップステータスが `failed` に変更された場合、次の 2 つの理由が考えられます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/SSAS.Trouble.html) RDS では、一度に 1 つの SSAS モードのみが可能で、SSAS データベースが存在する場合の SSAS オプションの削除がサポートされていないので、SSAS オプションを再構成します。 RDS イベントログで SSAS インスタンスの設定エラーを確認し、それに応じて問題を解決します。 |
| デプロイに失敗しました。変更は、deployment\$1file\$1mode モードで実行されているサーバーにのみデプロイできます。現在のサーバーモードは current\$1mode です。 | RDS ストアドプロシージャ | 表形式データベースを多次元サーバーにデプロイしたり、多次元データベースを表形式サーバーにデプロイしたりすることはできません。 正しいモードのファイルを使用していることを確認し、`MODE` オプション設定が適切な値に設定されていることを確認します。 |
| 復元に失敗しました。バックアップファイルは、restore\$1file\$1mode モードで実行されているサーバー上でのみ復元できます。現在のサーバーモードは current\$1mode です。 | RDS ストアドプロシージャ | 表形式データベースを多次元サーバーに復元したり、多次元データベースを表形式サーバーに復元することはできません。 正しいモードのファイルを使用していることを確認し、`MODE` オプション設定が適切な値に設定されていることを確認します。 |
| 復元に失敗しました。バックアップファイルと RDS DB インスタンスのバージョンに互換性がありません。 | RDS ストアドプロシージャ | SQL Server インスタンスのバージョンと互換性のないバージョンで SSAS データベースを復元することはできません。 詳細については、Microsoft のドキュメントの「[テーブルモデルの互換性レベル](https://docs.microsoft.com/en-us/analysis-services/tabular-models/compatibility-level-for-tabular-models-in-analysis-services)」と「[多次元データベースの互換性レベル](https://docs.microsoft.com/en-us/analysis-services/multidimensional-models/compatibility-level-of-a-multidimensional-database-analysis-services)」を参照してください。 |
| 復元に失敗しました。復元オペレーションで指定されたバックアップファイルが破損しているか、SSAS バックアップファイルではありません。@rds\$1file\$1path が正しいフォーマットであることを確認してください。 | RDS ストアドプロシージャ | 破損したファイルで SSAS データベースを復元することはできません。 ファイルが破損したり、破壊されていたりしていないことを確認してください。 このエラーは、`@rds_file_path` が正しくフォーマットされていない場合 (例えば、`D:\S3\\incorrect_format.abf` のように二重のバックスラッシュがある場合) にも発生します。 |
| 復元に失敗しました。復元されたデータベース名には、予約語や無効な文字 (. , ; ' ` : / \$1\$1 \$1 \$1 ? \$1" & % \$1 \$1 \$1 = ( ) [ ] \$1 \$1 <>)、または 100 文字を超える文字を含めることはできません。 | RDS ストアドプロシージャ | 復元されたデータベース名には、予約語や有効でない文字、または 100 文字を超える文字を含めることはできません。 SSAS オブジェクトの命名規則については、Microsoft のドキュメントの「[オブジェクトの名前付け規則](https://docs.microsoft.com/en-us/analysis-services/multidimensional-models/olap-physical/object-naming-rules-analysis-services)」を参照してください。 |
| 無効なロール名が指定されました。ロール名に予約文字列を含めることはできません。 | RDS ストアドプロシージャ | ロール名に予約文字列を含めることはできません。 SSAS オブジェクトの命名規則については、Microsoft のドキュメントの「[オブジェクトの名前付け規則](https://docs.microsoft.com/en-us/analysis-services/multidimensional-models/olap-physical/object-naming-rules-analysis-services)」を参照してください。 |
| 無効なロール名が指定されました。ロール名には、予約文字 (. , ; ' ` : / \$1\$1 \$1 \$1 ? \$1" & % \$1 \$1 \$1 = ( ) [ ] \$1 \$1 <>) を含めることはできません。 | RDS ストアドプロシージャ | ロール名に予約文字を含めることはできません。 SSAS オブジェクトの命名規則については、Microsoft のドキュメントの「[オブジェクトの名前付け規則](https://docs.microsoft.com/en-us/analysis-services/multidimensional-models/olap-physical/object-naming-rules-analysis-services)」を参照してください。 |
# Amazon RDS for SQL Server での SQL Server Integration Services のサポート
Microsoft SQL Server Integration Services (SSIS) は、幅広いデータ移行タスクの実行に使用できるコンポーネントです。SSIS は、データ統合およびワークフローアプリケーションに対応したプラットフォームです。データの抽出、変換、ロード (ETL) に使用されるデータウェアハウジングツールを備えています。このツールを使用して、SQL Server データベースのメンテナンスと多次元キューブデータの更新を自動化することもできます。
SSIS プロジェクトはパッケージに編成されて、XML ベースの .dtsx ファイルとして保存されます。パッケージには、制御フローとデータフローを含めることができます。データフローを使用して、ETL オペレーションを表します。デプロイ後、パッケージは SQL Server の SSISDB データベースに保存されます。SSISDB は、完全復旧モードで動作するオンライントランザクション処理 (OLTP) データベースです。
Amazon RDS for SQL Server は RDS DB インスタンスでの SSIS の直接実行をサポートしています。既存または新規の DB インスタンスで SSIS を有効にできます。SSIS はデータベースエンジンと同じ DB インスタンスにインストールされます。
RDS は、次のバージョンで SQL Server スタンダードエディションおよびエンタープライズエディションの SSIS をサポートします。
+ SQL Server 2022、すべてのバージョン
+ SQL Server 2019、バージョン 15.00.4043.16.v1 以降
+ SQL Server 2017、バージョン 14.00.3223.3.v1 以降
+ SQL Server 2016、バージョン 13.00.5426.0.v1 以降
**Contents**
+ [制限と推奨事項](#SSIS.Limitations)
+ [SSIS の有効化](#SSIS.Enabling)
+ [SSIS のオプショングループの作成](#SSIS.OptionGroup)
+ [オプショングループへの SSIS オプションの追加](#SSIS.Add)
+ [SSIS のパラメータグループの作成](#SSIS.CreateParamGroup)
+ [SSIS のパラメータの変更](#SSIS.ModifyParam)
+ [オプショングループとパラメータグループを DB インスタンスに関連付ける](#SSIS.Apply)
+ [S3 統合を有効にする](#SSIS.EnableS3)
+ [SSISDB の管理権限](SSIS.Permissions.md)
+ [SSIS 用の Windows 認証ユーザーの設定](SSIS.Permissions.md#SSIS.Use.Auth)
+ [SSIS プロジェクトのデプロイ](SSIS.Deploy.md)
+ [デプロイタスクのステータスのモニタリング](SSIS.Monitor.md)
+ [SSIS の使用](SSIS.Use.md)
+ [SSIS プロジェクトのデータベース接続マネージャーの設定](SSIS.Use.md#SSIS.Use.ConnMgrs)
+ [SSIS プロキシの作成](SSIS.Use.md#SSIS.Use.Proxy)
+ [SQL Server エージェントを使用した SSIS パッケージのスケジュール](SSIS.Use.md#SSIS.Use.Schedule)
+ [プロキシからの SSIS アクセスの取り消し](SSIS.Use.md#SSIS.Use.Revoke)
+ [SSIS データベースの無効化と削除](SSIS.DisableDrop.md)
+ [SSIS の無効化](SSIS.DisableDrop.md#SSIS.Disable)
+ [SSISDB データベースの削除](SSIS.DisableDrop.md#SSIS.Drop)
## 制限と推奨事項
RDS for SQL Server で SSIS を実行する場合は、以下の制限と推奨事項が適用されます。
+ また、DB インスタンスには、`clr enabled` パラメータが 1 に設定されたパラメータグループが関連付けられている必要があります。詳細については、「[SSIS のパラメータの変更](#SSIS.ModifyParam)」を参照してください。
**注記**
SQL Server 2017 または 2019 で `clr enabled` パラメータを有効にしている場合、DB インスタンスで共通言語ランタイム (CLR) を使用できません。詳細については、「[サポート対象外の機能とサポートが制限されている機能](SQLServer.Concepts.General.FeatureNonSupport.md)」を参照してください。
+ 以下の制御フロータスクがサポートされています。
+ Analysis Services DDL 実行タスク
+ Analysis Services 処理タスク
+ 一括挿入タスク
+ データベース整合性チェックタスク
+ データフロータスク
+ データマイニングクエリタスク
+ データプロファイリングタスク
+ パッケージ実行タスク
+ SQL Server エージェントジョブ実行タスク
+ SQL 実行タスク
+ T-SQL ステートメント実行タスク
+ オペレーター通知タスク
+ インデックス再構築タスク
+ インデックス再編成タスク
+ データベース縮小タスク
+ データベース転送タスク
+ ジョブ転送タスク
+ ログイン転送タスク
+ SQL Server オブジェクト転送タスク
+ 統計更新タスク
+ プロジェクトのデプロイのみがサポートされています。
+ SQL Server エージェントを使用した SSIS パッケージの実行がサポートされています。
+ SSIS ログレコードは、ユーザーが作成したデータベースにのみ挿入できます。
+ ファイルの操作には `D:\S3` フォルダのみを使用します。他のディレクトリにあるファイルは削除されます。ファイルの場所について、そのほか以下の詳細にも注意してください。
+ SSIS プロジェクトの入力ファイルと出力ファイルは `D:\S3` フォルダに配置します。
+ データフロータスクの場合、`BLOBTempStoragePath` と `BufferTempStoragePath` の場所を `D:\S3` フォルダ内のファイルに変更します。ファイルパスは `D:\S3\` で始まる必要があります。
+ ファイル接続に使用されるすべてのパラメータ、可変、表現が `D:\S3` フォルダを指していることを確認します。
+ マルチ AZ インスタンスでは、SSIS によって `D:\S3` フォルダに作成されたファイルは、フェイルオーバー後に削除されます。詳細については、「[S3 統合のマルチ AZ の制限](User.SQLServer.Options.S3-integration.md#S3-MAZ)」を参照してください。
+ SSIS によって `D:\S3` フォルダに作成されたファイルは、耐久性を高めるために、Amazon S3 バケットにアップロードします。
+ 列のインポートと列のエクスポートの変換、およびデータフロータスクのスクリプトコンポーネントはサポートされていません。
+ SSIS パッケージの実行時にダンプを有効にしたり、SSIS パッケージにデータタップを追加したりすることはできません。
+ SSIS スケールアウト機能はサポートされていません。
+ プロジェクトを直接デプロイすることはできません。この機能を実行するための RDS ストアドプロシージャが提供されています。詳細については、「[SSIS プロジェクトのデプロイ](SSIS.Deploy.md)」を参照してください。
+ RDS にデプロイする SSIS プロジェクト (.ispac) ファイルは `DoNotSavePasswords` 保護モードで構築します。
+ SSIS は、リードレプリカを使用する Always On インスタンスではサポートされていません。
+ `SSIS` オプションに関連付けられている SSISDB データベースをバックアップすることはできません。
+ SSIS の他のインスタンスからの SSISDB データベースのインポートと復元はサポートされていません。
+ 他の SQL Server DB インスタンスまたは Oracle データソースに接続できます。RDS for SQL Server 上の SSIS では、MySQL または PostgreSQL などの他のデータベースエンジンへの接続はサポートされていません。Oracle データソースへの接続に関する詳細については、[Oracle OLEDB とリンクされたサーバー](Appendix.SQLServer.Options.LinkedServers_Oracle_OLEDB.md) を参照してください。
+ SSIS は、オンプレミスドメインへの送信の信頼を持つドメイン参加インスタンスをサポートしていません。送信の信頼を使用する場合は、ローカル AWS ドメインのアカウントから SSIS ジョブを実行します。
+ ファイルシステムベースのパッケージの実行はサポートされていません。
## SSIS の有効化
SSIS を有効にするには、DB インスタンスに SSIS オプションを追加します。以下のプロセスを使用します。
1. 新しいオプショングループを作成するか、既存のオプショングループを選択します。
1. オプショングループに [`SSIS`] オプションを追加します。
1. 新しいパラメータグループを作成するか、既存のパラメータグループを選択します。
1. パラメータグループを変更して、`clr enabled` パラメータを 1 に設定します。
1. オプショングループとパラメータグループを DB インスタンスに関連付けます。
1. Amazon S3 統合を有効にする
**注記**
DB インスタンスに既に SSISDB という名前のデータベースがある場合や、SSIS ログインが予約されている場合、そのインスタンスで SSIS を有効にすることはできません。
### SSIS のオプショングループの作成
SSIS を使用するには、使用する DB インスタンスの SQL Server のエディションとバージョンに対応するオプショングループを作成または変更します。そのためには、AWS マネジメントコンソール または AWS CLI を使用します。
#### コンソール
次の手順では、SQL Server Standard Edition 2016 のオプショングループを作成します。
**オプショングループを作成するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. **[Create group]** (グループの作成) を選択します。
1. [**Create subnet group**(オプショングループの作成)] ウィンドウで以下を行います。
1. [**名前**] に、AWS アカウント内で一意のオプショングループ名 (**ssis-se-2016** など) を入力します。名前には、英字、数字、ハイフンのみを使用できます。
1. [**説明**] に、オプショングループの簡単な説明 (**SSIS option group for SQL Server SE 2016** など) を入力します。この説明は表示用に使用されます。
1. [**エンジン**] で [**sqlserver-se**] を選択します。
1. [**メジャーエンジンのバージョン**] で、[**13.00**] を選択します。
1. **[作成]** を選択します。
#### CLI
次の手順では、SQL Server Standard Edition 2016 のオプショングループを作成します。
**オプショングループを作成するには**
+ 以下のいずれかのコマンドを実行します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds create-option-group \
--option-group-name ssis-se-2016 \
--engine-name sqlserver-se \
--major-engine-version 13.00 \
--option-group-description "SSIS option group for SQL Server SE 2016"
```
Windows の場合:
```
aws rds create-option-group ^
--option-group-name ssis-se-2016 ^
--engine-name sqlserver-se ^
--major-engine-version 13.00 ^
--option-group-description "SSIS option group for SQL Server SE 2016"
```
### オプショングループへの SSIS オプションの追加
次に、AWS マネジメントコンソール または AWS CLI を使用して `SSIS` オプションをオプショングループに追加します。
#### コンソール
**SSIS オプションを追加するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. 作成したオプショングループ (この例では **ssis-se-2016**) を選択します。
1. [**オプションの追加**] を選択します。
1. [**オプションの詳細**] で、[**オプション名**] として [**SSRS**] を選択します。
1. [**スケジュール**] で、オプションをすぐに追加するか、次のメンテナンスウィンドウで追加するかを選択します。
1. **[オプションを追加]** を選択します。
#### CLI
**SSIS オプションを追加するには**
+ オプショングループに [`SSIS`] オプションを追加します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds add-option-to-option-group \
--option-group-name ssis-se-2016 \
--options OptionName=SSIS \
--apply-immediately
```
Windows の場合:
```
aws rds add-option-to-option-group ^
--option-group-name ssis-se-2016 ^
--options OptionName=SSIS ^
--apply-immediately
```
### SSIS のパラメータグループの作成
SSIS で使用する DB インスタンスの SQL Server のエディションとバージョンに対応する `clr enabled` パラメータのパラメータグループを作成または変更します。
#### コンソール
以下の例では、SQL Server Standard Edition 2016 のパラメータグループを作成します。
**パラメータグループを作成するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、**[パラメータグループ]** を選択します。
1. [**Create parameter group**] を選択します。
1. [**パラメータグループの作成**] ペインで、次の操作を行います。
1. [**パラメータグループファミリー**] で、[**sqlserver-se-13.0**] を選択します。
1. [**グループ名**] に、パラメータグループの識別子 (**ssis-sqlserver-se-13** など) を入力します。
1. [**説明**] に「**clr enabled parameter group**」と入力します。
1. **[作成]** を選択します。
#### CLI
以下の例では、SQL Server Standard Edition 2016 のパラメータグループを作成します。
**パラメータグループを作成するには**
+ 以下のいずれかのコマンドを実行します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds create-db-parameter-group \
--db-parameter-group-name ssis-sqlserver-se-13 \
--db-parameter-group-family "sqlserver-se-13.0" \
--description "clr enabled parameter group"
```
Windows の場合:
```
aws rds create-db-parameter-group ^
--db-parameter-group-name ssis-sqlserver-se-13 ^
--db-parameter-group-family "sqlserver-se-13.0" ^
--description "clr enabled parameter group"
```
### SSIS のパラメータの変更
DB インスタンスの SQL Server のエディションとバージョンに対応するパラメータグループの `clr enabled` パラメータを変更します。SSIS の場合、`clr enabled` パラメータを 1 に設定します。
#### コンソール
以下の手順では、SQL Server Standard Edition 2016 用に作成したパラメータグループを変更します。
**パラメータグループを変更するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**パラメータグループ**] を選択します。
1. [**ssis-sqlserver-se-13**] などのパラメータグループを選択します。
1. [**パラメータ**] で、パラメータのリストを **clr** でフィルタ処理します。
1. [**clr enabled (clr 有効化)**] を選択します。
1. [**Edit parameters**] を選択します。
1. [**Values (値)**] から [**1**] を選択します。
1. **[Save changes]** (変更の保存) をクリックします。
#### CLI
以下の手順では、SQL Server Standard Edition 2016 用に作成したパラメータグループを変更します。
**パラメータグループを変更するには**
+ 以下のいずれかのコマンドを実行します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name ssis-sqlserver-se-13 \
--parameters "ParameterName='clr enabled',ParameterValue=1,ApplyMethod=immediate"
```
Windows の場合:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name ssis-sqlserver-se-13 ^
--parameters "ParameterName='clr enabled',ParameterValue=1,ApplyMethod=immediate"
```
### オプショングループとパラメータグループを DB インスタンスに関連付ける
SSIS オプショングループおよびパラメータグループを DB インスタンスに関連付けるには、AWS マネジメントコンソール または AWS CLI を使用します。
**注記**
既存のインスタンスを使用する場合は、このインスタンスに Active Directory ドメインと AWS Identity and Access Management (IAM) ロールが既に関連付けられている必要があります。新しいインスタンスを作成する場合は、既存の Active Directory ドメインと IAM ロールを指定します。詳細については、「[RDS for SQL Server による Active Directory の操作](User.SQLServer.ActiveDirectoryWindowsAuth.md)」を参照してください。
#### コンソール
SSIS の有効化を完了するには、SSIS オプショングループおよびパラメータグループを新規または既存の DB インスタンスに関連付けます。
+ 新しい DB インスタンスの場合は、インスタンスを起動するときにそれらを関連付けます。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の DB インスタンスの場合は、インスタンスを変更することでそれらを関連付けます。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
#### CLI
SSIS オプショングループおよびパラメータグループを新規または既存の DB インスタンスに関連付けることができます。
**SSIS オプショングループおよびパラメータグループを使用してインスタンスを作成するには**
+ オプショングループの作成時に使用したものと同じ DB エンジンのタイプとメジャーバージョンを指定します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds create-db-instance \
--db-instance-identifier myssisinstance \
--db-instance-class db.m5.2xlarge \
--engine sqlserver-se \
--engine-version 13.00.5426.0.v1 \
--allocated-storage 100 \
--manage-master-user-password \
--master-username admin \
--storage-type gp2 \
--license-model li \
--domain-iam-role-name my-directory-iam-role \
--domain my-domain-id \
--option-group-name ssis-se-2016 \
--db-parameter-group-name ssis-sqlserver-se-13
```
Windows の場合:
```
aws rds create-db-instance ^
--db-instance-identifier myssisinstance ^
--db-instance-class db.m5.2xlarge ^
--engine sqlserver-se ^
--engine-version 13.00.5426.0.v1 ^
--allocated-storage 100 ^
--manage-master-user-password ^
--master-username admin ^
--storage-type gp2 ^
--license-model li ^
--domain-iam-role-name my-directory-iam-role ^
--domain my-domain-id ^
--option-group-name ssis-se-2016 ^
--db-parameter-group-name ssis-sqlserver-se-13
```
**インスタンスを変更し、SSIS オプショングループおよびパラメータグループを関連付けるには**
+ 以下のいずれかのコマンドを実行します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance \
--db-instance-identifier myssisinstance \
--option-group-name ssis-se-2016 \
--db-parameter-group-name ssis-sqlserver-se-13 \
--apply-immediately
```
Windows の場合:
```
aws rds modify-db-instance ^
--db-instance-identifier myssisinstance ^
--option-group-name ssis-se-2016 ^
--db-parameter-group-name ssis-sqlserver-se-13 ^
--apply-immediately
```
### S3 統合を有効にする
SSIS プロジェクト (.ispac) ファイルをデプロイのためにホストにダウンロードするには、S3 ファイル統合を使用します。詳細については、「[Amazon RDS for SQL Server DB インスタンスと Amazon S3 の統合](User.SQLServer.Options.S3-integration.md)」を参照してください。
# SSISDB の管理権限
SSIS オプションを使用してインスタンスを作成または変更すると、その結果、SSISDB データベースのマスターユーザーには、ssis\$1admin および ssis\$1logリーダー ロールが付与されます。マスターユーザーには SSISDB に対する以下の権限があります。
+ ssis\$1admin ロールの変更
+ ssis\$1logリーダー ロールの変更
+ 任意のユーザーの変更
マスターユーザーは SQL 認証ユーザーであるため、マスターユーザーを使用して SSIS パッケージを実行することはできません。マスターユーザーはこれらの権限を使用して新しい SSISDB ユーザーを作成し、それらのユーザーを ssis\$1admin および ssis\$1logリーダー ロールに追加できます。これは、ドメインユーザーに SSIS を使用するアクセス許可を付与するのに役立ちます。
## SSIS 用の Windows 認証ユーザーの設定
マスターユーザーは、以下のコード例を使用して、SSISDB に Windows 認証ログインを設定し、必要な手順に対するアクセス許可を付与できます。これにより、ドメインユーザーに SSIS パッケージのデプロイと実行、S3 ファイル転送手順の使用、認証情報の作成、および SQL Server エージェントプロキシの操作を行うアクセス許可が付与されます。詳細については、Microsoft ドキュメントの「[Credentials (Database Engine)](https://docs.microsoft.com/en-us/sql/relational-databases/security/authentication-access/credentials-database-engine?view=sql-server-ver15)」および「[Create a SQL Server Agent Proxy](https://docs.microsoft.com/en-us/sql/ssms/agent/create-a-sql-server-agent-proxy?view=sql-server-ver15)」を参照してください。
**注記**
必要に応じて、Windows 認証ユーザーに以下のアクセス許可の一部またはすべてを付与できます。
**Example**
```
-- Create a server-level SQL login for the domain user, if it doesn't already exist
USE [master]
GO
CREATE LOGIN [mydomain\user_name] FROM WINDOWS
GO
-- Create a database-level account for the domain user, if it doesn't already exist
USE [SSISDB]
GO
CREATE USER [mydomain\user_name] FOR LOGIN [mydomain\user_name]
-- Add SSIS role membership to the domain user
ALTER ROLE [ssis_admin] ADD MEMBER [mydomain\user_name]
ALTER ROLE [ssis_logreader] ADD MEMBER [mydomain\user_name]
GO
-- Add MSDB role membership to the domain user
USE [msdb]
GO
CREATE USER [mydomain\user_name] FOR LOGIN [mydomain\user_name]
-- Grant MSDB stored procedure privileges to the domain user
GRANT EXEC ON msdb.dbo.rds_msbi_task TO [mydomain\user_name] with grant option
GRANT SELECT ON msdb.dbo.rds_fn_task_status TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_task_status TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_cancel_task TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_download_from_s3 TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_upload_to_s3 TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_delete_from_filesystem TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_gather_file_details TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_add_proxy TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_update_proxy TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_grant_login_to_proxy TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_revoke_login_from_proxy TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_delete_proxy TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_enum_login_for_proxy to [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.sp_enum_proxy_for_subsystem TO [mydomain\user_name] with grant option
GRANT EXEC ON msdb.dbo.rds_sqlagent_proxy TO [mydomain\user_name] WITH GRANT OPTION
-- Add the SQLAgentUserRole privilege to the domain user
USE [msdb]
GO
ALTER ROLE [SQLAgentUserRole] ADD MEMBER [mydomain\user_name]
GO
-- Grant the ALTER ANY CREDENTIAL privilege to the domain user
USE [master]
GO
GRANT ALTER ANY CREDENTIAL TO [mydomain\user_name]
GO
```
# SSIS プロジェクトのデプロイ
RDS では、SQL Server Management Studio (SSMS) または SSIS の手順を使用して SSIS プロジェクトを直接デプロイすることはできません。Amazon S3 からプロジェクトファイルをダウンロードしてデプロイするには、RDS ストアドプロシージャを使用します。
ストアドプロシージャを実行するには、ストアドプロシージャの実行アクセス許可を付与した任意のユーザーとしてログインします。詳細については、「[SSIS 用の Windows 認証ユーザーの設定](SSIS.Permissions.md#SSIS.Use.Auth)」を参照してください。
**SSIS プロジェクトをデプロイするには**
1. プロジェクト (.ispac) ファイルをダウンロードします。
```
exec msdb.dbo.rds_download_from_s3
@s3_arn_of_file='arn:aws:s3:::bucket_name/ssisproject.ispac',
@rds_file_path='D:\S3\ssisproject.ispac',
@overwrite_file=1;
```
1. 以下のことを確認してから、デプロイタスクを送信します。
+ フォルダが SSIS カタログに存在する。
+ プロジェクト名が、SSIS プロジェクトの開発中に使用したプロジェクト名と一致する。
```
exec msdb.dbo.rds_msbi_task
@task_type='SSIS_DEPLOY_PROJECT',
@folder_name='DEMO',
@project_name='ssisproject',
@file_path='D:\S3\ssisproject.ispac';
```
# デプロイタスクのステータスのモニタリング
デプロイタスクのステータスを追跡するには、`rds_fn_task_status` 関数を呼び出します。2 つのパラメータを使用します。1 つめのパラメータは、SSIS に適用されないため、常に `NULL` を設定してください。2 つめのパラメータは、タスク ID を受け入れます。
全タスクのリストを見るには、以下の例にあるように、初期のパラメータを `NULL` に設定し、2 つめのパラメータを `0` に設定します。
```
SELECT * FROM msdb.dbo.rds_fn_task_status(NULL,0);
```
特定のタスクを受け取るには、以下の例にあるように、初期のパラメータを `NULL` に設定し、2 つめのパラメータをタスク ID に設定します。
```
SELECT * FROM msdb.dbo.rds_fn_task_status(NULL,42);
```
`rds_fn_task_status` 機能は次の情報を返します。
| 出力パラメータ | 説明 |
| --- | --- |
| `task_id` | タスクの ID。 |
| `task_type` | `SSIS_DEPLOY_PROJECT` |
| `database_name` | SSIS タスクには該当しません。 |
| `% complete` | タスクの進行状況の割合。 |
| `duration (mins)` | タスクにかかった時間 (分単位)。 |
| `lifecycle` | タスクのステータス。有効な状態には以下のものがあります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/SSIS.Monitor.html) |
| `task_info` | タスクに関する追加情報。処理中にエラーが発生した場合、この列にエラーに関する情報が含まれます。 |
| `last_updated` | タスクのステータスが最後に更新された日時。 |
| `created_at` | タスクが作成された日時。 |
| `S3_object_arn` | SSIS タスクには該当しません。 |
| `overwrite_S3_backup_file` | SSIS タスクには該当しません。 |
| `KMS_master_key_arn` | SSIS タスクには該当しません。 |
| `filepath` | SSIS タスクには該当しません。 |
| `overwrite_file` | SSIS タスクには該当しません。 |
| `task_metadata` | SSIS タスクに関連付けられたメタデータ。 |
# SSIS の使用
SSIS プロジェクトを SSIS カタログにデプロイした後、SSMS から直接パッケージを実行するか、SQL Server エージェントを使用してパッケージをスケジュールできます。SSIS パッケージを実行するには、Windows 認証のログインを使用する必要があります。詳細については、「[SSIS 用の Windows 認証ユーザーの設定](SSIS.Permissions.md#SSIS.Use.Auth)」を参照してください。
**Topics**
+ [SSIS プロジェクトのデータベース接続マネージャーの設定](#SSIS.Use.ConnMgrs)
+ [SSIS プロキシの作成](#SSIS.Use.Proxy)
+ [SQL Server エージェントを使用した SSIS パッケージのスケジュール](#SSIS.Use.Schedule)
+ [プロキシからの SSIS アクセスの取り消し](#SSIS.Use.Revoke)
## SSIS プロジェクトのデータベース接続マネージャーの設定
接続マネージャーを使用する場合、以下のタイプの認証を使用できます。
+ AWS Managed Active Directory を使用したローカルデータベース接続の場合、SQL 認証または Windows 認証を使用できます。Windows 認証の場合、接続文字列のサーバー名として `DB_instance_name.fully_qualified_domain_name` を使用します。
例えば、`myssisinstance.corp-ad.example.com` を使用します。ここで、`myssisinstance` は DB インスタンス名、`corp-ad.example.com` は完全修飾ドメイン名です。
+ リモート接続の場合は、常に SQL 認証を使用します。
+ セルフマネージド Active Directory を使用したローカルデータベース接続の場合、SQL 認証または Windows 認証を使用できます。Windows 認証の場合、接続文字列のサーバー名として `.` または `LocalHost` を使用します。
## SSIS プロキシの作成
SQL Server エージェントを使用して SSIS パッケージをスケジュールできるようにするには、SSIS 認証情報と SSIS プロキシを作成します。これらの手順を Windows 認証ユーザーとして実行します。
**SSIS 認証情報を作成するには**
+ プロキシの認証情報を作成します。そのためには、SSMS または以下の SQL ステートメントを使用できます。
```
USE [master]
GO
CREATE CREDENTIAL [SSIS_Credential] WITH IDENTITY = N'mydomain\user_name', SECRET = N'mysecret'
GO
```
**注記**
`IDENTITY` はドメイン認証ログインであることが必要です。`mysecret` をドメイン認証ログインのパスワードに置き換えます。
SSISDB プライマリホストが変更されるたびに、SSIS プロキシ認証情報を変更して、新しいホストがそれらのホストにアクセスできるようにします。
**SSIS プロキシを作成するには**
1. 以下の SQL ステートメントを使用して、プロキシを作成します。
```
USE [msdb]
GO
EXEC msdb.dbo.sp_add_proxy @proxy_name=N'SSIS_Proxy',@credential_name=N'SSIS_Credential',@description=N''
GO
```
1. 以下の SQL ステートメントを使用して、他のユーザーにプロキシへのアクセスを許可します。
```
USE [msdb]
GO
EXEC msdb.dbo.sp_grant_login_to_proxy @proxy_name=N'SSIS_Proxy',@login_name=N'mydomain\user_name'
GO
```
1. 以下の SQL ステートメントを使用して、SSIS サブシステムにプロキシへのアクセスを許可します。
```
USE [msdb]
GO
EXEC msdb.dbo.rds_sqlagent_proxy @task_type='GRANT_SUBSYSTEM_ACCESS',@proxy_name='SSIS_Proxy',@proxy_subsystem='SSIS'
GO
```
**プロキシとそのプロキシに対する許可を表示するには**
1. 以下の SQL ステートメントを使用して、プロキシの被付与者を表示します。
```
USE [msdb]
GO
EXEC sp_help_proxy
GO
```
1. 以下の SQL ステートメントを使用して、サブシステムの許可を表示します。
```
USE [msdb]
GO
EXEC msdb.dbo.sp_enum_proxy_for_subsystem
GO
```
## SQL Server エージェントを使用した SSIS パッケージのスケジュール
認証情報とプロキシを作成し、SSIS にプロキシへのアクセスを許可したら、SQL Server エージェントジョブを作成して SSIS パッケージをスケジュールできます。
**SSIS パッケージをスケジュールするには**
+ SSMS または T-SQL を使用して、SQL Server エージェントジョブを作成できます。以下の例では T-SQL を使用しています。
```
USE [msdb]
GO
DECLARE @jobId BINARY(16)
EXEC msdb.dbo.sp_add_job @job_name=N'MYSSISJob',
@enabled=1,
@notify_level_eventlog=0,
@notify_level_email=2,
@notify_level_page=2,
@delete_level=0,
@category_name=N'[Uncategorized (Local)]',
@job_id = @jobId OUTPUT
GO
EXEC msdb.dbo.sp_add_jobserver @job_name=N'MYSSISJob',@server_name=N'(local)'
GO
EXEC msdb.dbo.sp_add_jobstep @job_name=N'MYSSISJob',@step_name=N'ExecuteSSISPackage',
@step_id=1,
@cmdexec_success_code=0,
@on_success_action=1,
@on_fail_action=2,
@retry_attempts=0,
@retry_interval=0,
@os_run_priority=0,
@subsystem=N'SSIS',
@command=N'/ISSERVER "\"\SSISDB\MySSISFolder\MySSISProject\MySSISPackage.dtsx\"" /SERVER "\"my-rds-ssis-instance.corp-ad.company.com/\""
/Par "\"$ServerOption::LOGGING_LEVEL(Int16)\"";1 /Par "\"$ServerOption::SYNCHRONIZED(Boolean)\"";True /CALLERINFO SQLAGENT /REPORTING E',
@database_name=N'master',
@flags=0,
@proxy_name=N'SSIS_Proxy'
GO
```
## プロキシからの SSIS アクセスの取り消し
以下のストアドプロシージャを使用して、SSIS サブシステムへのアクセスを取り消し、SSIS プロキシを削除できます。
**アクセスを取り消してプロキシを削除するには**
1. サブシステムのアクセスを取り消します。
```
USE [msdb]
GO
EXEC msdb.dbo.rds_sqlagent_proxy @task_type='REVOKE_SUBSYSTEM_ACCESS',@proxy_name='SSIS_Proxy',@proxy_subsystem='SSIS'
GO
```
1. プロキシに対する許可を取り消します。
```
USE [msdb]
GO
EXEC msdb.dbo.sp_revoke_login_from_proxy @proxy_name=N'SSIS_Proxy',@name=N'mydomain\user_name'
GO
```
1. プロキシを削除します。
```
USE [msdb]
GO
EXEC dbo.sp_delete_proxy @proxy_name = N'SSIS_Proxy'
GO
```
# SSIS データベースの無効化と削除
SSIS データベースを無効化または削除するには、次の手順を実行します。
**Topics**
+ [SSIS の無効化](#SSIS.Disable)
+ [SSISDB データベースの削除](#SSIS.Drop)
## SSIS の無効化
SSIS を無効にするには、オプショングループから `SSIS` オプションを削除します。
**重要**
SSIS オプションを削除しても SSISDB データベースは削除されないため、SSIS プロジェクトを失うことなくこのオプションを安全に削除できます。
削除後に `SSIS` オプションを再度有効にして、前に SSIS カタログにデプロイされていた SSIS プロジェクトを再利用できます。
### コンソール
以下の手順では、`SSIS` オプションを削除します。
**SSIS オプションをオプショングループから削除するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. `SSIS` オプションが含まれているオプショングループ (前の例では `ssis-se-2016`) を選択します。
1. [**オプションの削除**] を選択します。
1. [**オプションの削除**] で、[**削除するオプション**] として [**SSIS**] を選択します。
1. [**すぐに適用**] で、オプションをすぐに削除する場合は [**はい**] を選択し、次のメンテナンスウィンドウで削除する場合は [**いいえ**] を選択します。
1. [**削除**] を選択します。
### CLI
以下の手順では、`SSIS` オプションを削除します。
**SSIS オプションをオプショングループから削除するには**
+ 以下のいずれかのコマンドを実行します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds remove-option-from-option-group \
--option-group-name ssis-se-2016 \
--options SSIS \
--apply-immediately
```
Windows の場合:
```
aws rds remove-option-from-option-group ^
--option-group-name ssis-se-2016 ^
--options SSIS ^
--apply-immediately
```
## SSISDB データベースの削除
SSIS オプションを削除しても、SSISDB データベースは削除されません。SSISDB データベースを削除するには、SSIS オプションを削除した後、`rds_drop_ssis_database` ストアドプロシージャを使用します。
**SSIS データベースを削除するには**
+ 次のストアドプロシージャを使用します。
```
USE [msdb]
GO
EXEC dbo.rds_drop_ssis_database
GO
```
SSISDB データベースを削除した後、SSIS オプションを再度有効にすると、新しい SSISDB カタログが取得されます。
# Amazon RDS for SQL Server での SQL Server Reporting Services のサポート
Microsoft SQL Server Reporting Services (SSRS) は、レポートの生成とディストリビューションに使用されるサーバーベースのアプリケーションです。これは、SQL Server Analysis Services (SSAS) および SQL Server Integration Services (SSIS) を含む SQL Server サービスのスイートの一部です。SSRS は、SQL Server 上に構築されたサービスです。これを使用すると、さまざまなデータソースからデータを収集して、それを簡単に理解でき、分析の準備が整っている方法で提示できます。
Amazon RDS for SQL Server は、RDS DB インスタンスで SSRS を直接実行する操作をサポートしています。SSRS は、既存または新規の DB インスタンスで使用できます。
RDS は、次のバージョンで SQL Server スタンダードエディションおよびエンタープライズエディションの SSRS をサポートします。
+ SQL Server 2022、すべてのバージョン
+ SQL Server 2019、バージョン 15.00.4043.16.v1 以降
+ SQL Server 2017、バージョン 14.00.3223.3.v1 以降
+ SQL Server 2016、バージョン 13.00.5820.21.v1 以降
**Contents**
+ [制限と推奨事項](#SSRS.Limitations)
+ [SSRS をオンにする](SSRS.Enabling.md)
+ [SSRS のオプショングループの作成](SSRS.Enabling.md#SSRS.OptionGroup)
+ [オプショングループへの SSRS オプションの追加](SSRS.Enabling.md#SSRS.Add)
+ [オプショングループと DB インスタンスの関連付け](SSRS.Enabling.md#SSRS.Apply)
+ [VPC セキュリティグループへのインバウンドアクセスの許可](SSRS.Enabling.md#SSRS.Inbound)
+ [レポートサーバーデータベース](#SSRS.DBs)
+ [SSRS ログファイル](#SSRS.Logs)
+ [SSRS ウェブポータルへのアクセス](SSRS.Access.md)
+ [RDS での SSL の使用](SSRS.Access.md#SSRS.Access.SSL)
+ [ドメインユーザーへのアクセスの許可](SSRS.Access.md#SSRS.Access.Grant)
+ [ウェブポータルへのアクセス](SSRS.Access.md#SSRS.Access)
+ [レポートのデプロイとレポートデータソースの設定](SSRS.DeployConfig.md)
+ [SSRS へのレポートのデプロイ](SSRS.DeployConfig.md#SSRS.Deploy)
+ [レポートのデータソースの設定](SSRS.DeployConfig.md#SSRS.ConfigureDataSource)
+ [SSRS E メールを使用してレポートを送信する](SSRS.Email.md)
+ [システムレベルのアクセス許可の取り消し](SSRS.Access.Revoke.md)
+ [タスクのステータスのモニタリング](SSRS.Monitor.md)
+ [SSRS データベースの無効化と削除](SSRS.DisableDelete.md)
+ [SSRS をオフにする](SSRS.DisableDelete.md#SSRS.Disable)
+ [SSRS データベースの削除](SSRS.DisableDelete.md#SSRS.Drop)
## 制限と推奨事項
SQL Server 用 RDS で SSRS を実行する場合は、次の制限と推奨事項が適用されます。
+ リードレプリカを持つ DB インスタンスでは SSRS を使用することはできません。
+ インスタンスは、自己管理型の Active Directory または AWS Directory Service for Microsoft Active Directory for SSRS ウェブポータルおよびウェブサーバー認証を使用する必要があります。詳細については、「[RDS for SQL Server による Active Directory の操作](User.SQLServer.ActiveDirectoryWindowsAuth.md)」を参照してください。
+ SSRS オプションを使用して作成されたレポートサーバーデータベースをバックアップすることはできません。
+ SSRS の他のインスタンスからのレポートサーバーデータベースのインポートと復元はサポートされていません。詳細については、「[レポートサーバーデータベース](#SSRS.DBs)」を参照してください。
+ デフォルトの SSL ポート (443) でリッスンするように SSRS を構成することはできません。指定できる値は、1234、1434、3260、3343、3389、47001 を除く、1150～49511 です。
+ Microsoft Windows ファイル共有によるサブスクリプションはサポートされていません。
+ Reporting Services Configuration Manager の使用はサポートされていません。
+ ロールの作成と変更はサポートされていません。
+ レポートサーバーのプロパティの変更はサポートされていません。
+ システム管理者とシステムユーザーのロールは付与されません。
+ ウェブポータルを使用してシステムレベルのロールの割り当てを編集することはできません。
# SSRS をオンにする
DB インスタンスの SSRS をオンにするには、次のプロセスを使用します。
1. 新しいオプショングループを作成するか、既存のオプショングループを選択します。
1. オプショングループに [`SSRS`] オプションを追加します。
1. オプショングループを DB インスタンスに関連付けます。
1. SSRS リスナーポートの Virtual Private Cloud (VPC) セキュリティグループへのインバウンドアクセスを許可します。
## SSRS のオプショングループの作成
SSRS を使用するには、使用する DB インスタンスの SQL Server エンジンおよびバージョンに対応するオプショングループを作成します。そのためには、AWS マネジメントコンソール または AWS CLI を使用します。
**注記**
既存のオプショングループが正しい SQL Server エンジンおよびバージョンに対応している場合は、それを使用することもできます。
### コンソール
次の手順では、SQL Server Standard Edition 2017 のオプショングループを作成します。
**オプショングループを作成するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. [**Create group (グループの作成)**] を選択します。
1. [**オプショングループの作成**] ウィンドウで、次の操作を行います。
1. **[Name]** (名前) に、AWS アカウント 内で一意のオプショングループ名 (**ssrs-se-2017** など) を入力します。名前には、英字、数字、ハイフンのみを使用できます。
1. [**説明**] に、オプショングループの簡単な説明 (**SSRS option group for SQL Server SE 2017** など) を入力します。この説明は表示用に使用されます。
1. [**エンジン**] で [**sqlserver-se**] を選択します。
1. [**メジャーエンジンのバージョン**] で、[**14.00**] を選択します。
1. **[作成]** を選択します。
### CLI
次の手順では、SQL Server Standard Edition 2017 のオプショングループを作成します。
**オプショングループを作成するには**
+ 以下のいずれかのコマンドを実行します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds create-option-group \
--option-group-name ssrs-se-2017 \
--engine-name sqlserver-se \
--major-engine-version 14.00 \
--option-group-description "SSRS option group for SQL Server SE 2017"
```
Windows の場合:
```
aws rds create-option-group ^
--option-group-name ssrs-se-2017 ^
--engine-name sqlserver-se ^
--major-engine-version 14.00 ^
--option-group-description "SSRS option group for SQL Server SE 2017"
```
## オプショングループへの SSRS オプションの追加
次に、AWS マネジメントコンソール または AWS CLI を使用して `SSRS` オプションをオプショングループに追加します。
### コンソール
**SSRS オプションを追加するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. 先ほど作成したオプショングループを選択し、**[Add option]** (オプションの追加) を選択します。
1. [**オプションの詳細**] で、[**オプション名**] として **SSRS** を選択します。
1. [**オプション設定**] で、次の操作を行います。
1. SSRS サービスがリッスンするポートを入力します。デフォルトは 8443 です。許可される値のリストについては、「[制限と推奨事項](Appendix.SQLServer.Options.SSRS.md#SSRS.Limitations)」を参照してください。
1. [**最大メモリ**] に値を入力します。
[**最大メモリ**] は、レポートサーバーアプリケーションに対して新しいメモリ割り当て要求を許可しない上限しきい値を指定します。この値は、DB インスタンスの合計メモリに対する割合 (%) です。指定できる値は 10～80 です。
1. [**セキュリティグループ**] で、オプションに関連付ける VPC セキュリティグループを選択します。DB インスタンスに関連付けられているものと同じセキュリティグループを使用します。
1. SSRS Email を使用してレポートを送信するには、**[Email delivery in reporting services]** (レポートサービスでのメール配信) の **[Configure email delivery options]** (E メール配信オプションの設定) チェックボックスを選択し、以下の操作を実行します。
1. **[Sender email address]** (送信者メールアドレス) で、SSRS Email で送信されるメッセージの **[From]** フィールドに使用するメールアドレスを入力します。
SMTP サーバーからメールを送信するアクセス許可を持つユーザーアカウントを指定します。
1. **SMTP server]** (SMTP サーバー) で、使用する SMTP サーバーまたはゲートウェイを指定します。
IP アドレス、社内イントラネット上のコンピュータの NetBIOS 名、または完全修飾ドメイン名を使用できます。
1. **[SMTP port]** (SMTP ポート) で、メールサーバーに接続するために使用するポートを入力します。デフォルトは 25 です。
1. 認証を使用するには:
1. **[Use authentication]** (認証の使用) チェックボックスを選択します。
1. **[Secret Amazon Resource Name (ARN)]** (シークレットの Amazon リソースネーム (ARN)) で、ユーザー認証情報の AWS Secrets Manager ARN を入力します。
次の形式を使用します。
**arn:aws:secretsmanager:*Region*:*AccountId*:secret:*SecretName*-*6RandomCharacters***
例:
**arn:aws:secretsmanager:*us-west-2*:*123456789012*:secret:*MySecret-a1b2c3***
シークレットを作成するための詳細については、「[SSRS E メールを使用してレポートを送信する](SSRS.Email.md)」を参照してください。
1. **[Use Secure Sockets Layer (SSL)]** (Secure Sockets Layer (SSL) を使用する)) チェックボックスを選択して、SSL を使用して電子メールメッセージを暗号化します。
1. **[スケジュール]** で、オプションをすぐに追加するか、次のメンテナンスウィンドウで追加するかを選択します。
1. **[オプションを追加]** を選択します。
### CLI
**SSRS オプションを追加するには**
1. `ssrs-option.json` などの JSON ファイル を作成します。
1. 以下の必須パラメータを設定します。
+ `OptionGroupName` - 以前に作成または選択したオプショングループの名前 (次の例では `ssrs-se-2017`)。
+ `Port` - SSRS サービスがリッスンするポート。デフォルトは 8443 です。許可される値のリストについては、「[制限と推奨事項](Appendix.SQLServer.Options.SSRS.md#SSRS.Limitations)」を参照してください。
+ `VpcSecurityGroupMemberships` - RDS DB インスタンスの VPC セキュリティグループのメンバーシップ。
+ `MAX_MEMORY` - レポートサーバーアプリケーションに対して新しいメモリ割り当て要求を許可しない上限しきい値。この値は、DB インスタンスの合計メモリに対する割合 (%) です。指定できる値は 10～80 です。
1. (オプション) SSRS Email を使用するには、次のパラメータを設定します。
+ `SMTP_ENABLE_EMAIL` — SSRS E メールを使用するには `true` に設定します。デフォルトは `false` です。
+ `SMTP_SENDER_EMAIL_ADDRESS` — SSRS E メールで送信されるメッセージの**[From]** フィールドに使用するメールアドレスです。SMTP サーバーからメールを送信するアクセス許可を持つユーザーアカウントを指定します。
+ `SMTP_SERVER` — 使用する SMTP サーバーまたはゲートウェイ。IP アドレス、社内イントラネット上のコンピュータの NetBIOS 名、または完全修飾ドメイン名を使用できます。
+ `SMTP_PORT` — メールサーバーに接続するために使用するポート。デフォルトは 25 です。
+ `SMTP_USE_SSL` — SSL を使用して E メールメッセージを暗号化するには、`true` に設定します。デフォルトは `true` です。
+ `SMTP_EMAIL_CREDENTIALS_SECRET_ARN` — ユーザー認証情報を保持する Secrets Manager ARN。次の形式を使用します。
**arn:aws:secretsmanager:*Region*:*AccountId*:secret:*SecretName*-*6RandomCharacters***
シークレットを作成するための詳細については、「[SSRS E メールを使用してレポートを送信する](SSRS.Email.md)」を参照してください。
+ `SMTP_USE_ANONYMOUS_AUTHENTICATION` — 認証を使用しない場合は、`true` に設定し、`SMTP_EMAIL_CREDENTIALS_SECRET_ARN` を含めないでください。
`SMTP_ENABLE_EMAIL` が `true` の場合、デフォルトは `false` です。
次の例には、シークレット ARN を使用した SSRS E メールパラメータが含まれています。
```
{
"OptionGroupName": "ssrs-se-2017",
"OptionsToInclude": [
{
"OptionName": "SSRS",
"Port": 8443,
"VpcSecurityGroupMemberships": ["sg-0abcdef123"],
"OptionSettings": [
{"Name": "MAX_MEMORY","Value": "60"},
{"Name": "SMTP_ENABLE_EMAIL","Value": "true"}
{"Name": "SMTP_SENDER_EMAIL_ADDRESS","Value": "nobody@example.com"},
{"Name": "SMTP_SERVER","Value": "email-smtp.us-west-2.amazonaws.com"},
{"Name": "SMTP_PORT","Value": "25"},
{"Name": "SMTP_USE_SSL","Value": "true"},
{"Name": "SMTP_EMAIL_CREDENTIALS_SECRET_ARN","Value": "arn:aws:secretsmanager:us-west-2:123456789012:secret:MySecret-a1b2c3"}
]
}],
"ApplyImmediately": true
}
```
1. オプショングループに [`SSRS`] オプションを追加します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds add-option-to-option-group \
--cli-input-json file://ssrs-option.json \
--apply-immediately
```
Windows の場合:
```
aws rds add-option-to-option-group ^
--cli-input-json file://ssrs-option.json ^
--apply-immediately
```
## オプショングループと DB インスタンスの関連付け
AWS マネジメントコンソール または AWS CLI を使用して、オプショングループを DB インスタンスに関連付けます。
既存の DB インスタンスを使用する場合は、このインスタンスに Active Directory ドメインと AWS Identity and Access Management (IAM) ロールが既に関連付けられている必要があります。新しいインスタンスを作成する場合は、既存の Active Directory ドメインと IAM ロールを指定します。詳細については、「[RDS for SQL Server による Active Directory の操作](User.SQLServer.ActiveDirectoryWindowsAuth.md)」を参照してください。
### コンソール
オプショングループを新規または既存の DB インスタンスに関連付けることができます。
+ 新しい DB インスタンスの場合は、インスタンスを起動するときにオプショングループを関連付けます。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の DB インスタンスの場合は、インスタンスを変更してから、新しいオプショングループを関連付けます。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
### CLI
オプショングループを新規または既存の DB インスタンスに関連付けることができます。
**オプショングループを使用する DB インスタンスを作成するには**
+ オプショングループの作成時に使用したものと同じ DB エンジンのタイプとメジャーバージョンを指定します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds create-db-instance \
--db-instance-identifier myssrsinstance \
--db-instance-class db.m5.2xlarge \
--engine sqlserver-se \
--engine-version 14.00.3223.3.v1 \
--allocated-storage 100 \
--manage-master-user-password \
--master-username admin \
--storage-type gp2 \
--license-model li \
--domain-iam-role-name my-directory-iam-role \
--domain my-domain-id \
--option-group-name ssrs-se-2017
```
Windows の場合:
```
aws rds create-db-instance ^
--db-instance-identifier myssrsinstance ^
--db-instance-class db.m5.2xlarge ^
--engine sqlserver-se ^
--engine-version 14.00.3223.3.v1 ^
--allocated-storage 100 ^
--manage-master-user-password ^
--master-username admin ^
--storage-type gp2 ^
--license-model li ^
--domain-iam-role-name my-directory-iam-role ^
--domain my-domain-id ^
--option-group-name ssrs-se-2017
```
**オプショングループを使用するように DB インスタンスを変更するには**
+ 以下のいずれかのコマンドを実行します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance \
--db-instance-identifier myssrsinstance \
--option-group-name ssrs-se-2017 \
--apply-immediately
```
Windows の場合:
```
aws rds modify-db-instance ^
--db-instance-identifier myssrsinstance ^
--option-group-name ssrs-se-2017 ^
--apply-immediately
```
## VPC セキュリティグループへのインバウンドアクセスの許可
DB インスタンスに関連付けられた VPC セキュリティグループへのインバウンドアクセスを許可するには、指定された SSRS リスナーポートのインバウンドルールを作成します。セキュリティグループの設定の詳細については、「[セキュリティグループを作成して VPC 内の DB インスタンスへのアクセスを提供する](CHAP_SettingUp.md#CHAP_SettingUp.SecurityGroup)」を参照してください。
## レポートサーバーデータベース
DB インスタンスが SSRS オプションに関連付けられている場合、DB インスタンスに 2 つの新しいデータベースが作成されます。
+ `rdsadmin_ReportServer`
+ `rdsadmin_ReportServerTempDB`
これらのデータベースは、ReportServer および ReportServerTempDB データベースとして機能します。SSRS は、ReportServer データベースにデータを保存し、ReportServerTempDB にそのデータをキャッシュします。詳細については、Microsoft ドキュメントの「[レポートサーバーデータベース](https://learn.microsoft.com/en-us/sql/reporting-services/report-server/report-server-database-ssrs-native-mode?view=sql-server-ver15)」を参照してください。
RDS はこれらのデータベースを所有および管理するため、ALTER や DROP などのデータベース操作は許可されません。`rdsadmin_ReportServerTempDB` データベースへのアクセスは許可されていません。ただし、`rdsadmin_ReportServer` データベースに対して読み取りオペレーションを実行することはできます。
## SSRS ログファイル
SSRS ログファイルをリスト、表示、およびダウンロードできます。SSRS ログファイルは ReportServerService\$1*timestamp*.log という命名規則に従います。これらのレポートサーバーログは、`D:\rdsdbdata\Log\SSRS` ディレクトリにあります (`D:\rdsdbdata\Log` ディレクトリは、エラーログと SQL Server エージェントログの親ディレクトリでもあります)。詳細については、「[データベースログファイルの表示とリスト化](USER_LogAccess.Procedural.Viewing.md)」を参照してください。
既存の SSRS インスタンスの場合、レポートサーバーログにアクセスするために SSRS サービスを再起動する必要がある場合があります。`SSRS` オプションを更新することで、サービスを再起動できます。
詳細については、「[Amazon RDS for Microsoft SQL Server ログの使用方法](Appendix.SQLServer.CommonDBATasks.Logs.md)」を参照してください。
# SSRS ウェブポータルへのアクセス
SSRS ウェブポータルにアクセスするには、次のプロセスを使用します。
1. Secure Sockets Layer (SSL) をオンにします。
1. ドメインユーザーへのアクセス権を付与します。
1. ブラウザとドメインユーザーの認証情報を使用してウェブポータルにアクセスします。
## RDS での SSL の使用
SSRS は、接続に HTTPS SSL プロトコルを使用します。このプロトコルを使用するには、クライアントコンピュータの Microsoft Windows オペレーティングシステムに SSL 証明書をインポートします。
SSL 証明書の詳細については、「[SSL/TLS を使用した DB インスタンスまたはクラスターへの接続の暗号化](UsingWithRDS.SSL.md)」を参照してください。SQL Server での SSL の使用の詳細については、「[Microsoft SQL Server DB インスタンスでの SSL の使用](SQLServer.Concepts.General.SSL.Using.md)」を参照してください。
## ドメインユーザーへのアクセスの許可
新しい SSRS アクティベーションでは、SSRS でのロールの割り当てはありません。ドメインユーザーまたはユーザーグループにウェブポータルへのアクセス権を付与するために、RDS にはストアドプロシージャが用意されています。
**ウェブポータルでドメインユーザーにアクセス権を付与するには**
+ 次のストアドプロシージャを使用します。
```
exec msdb.dbo.rds_msbi_task
@task_type='SSRS_GRANT_PORTAL_PERMISSION',
@ssrs_group_or_username=N'AD_domain\user';
```
ドメインユーザーまたはユーザーグループに `RDS_SSRS_ROLE` システムロールが付与されます。このロールには、次のシステムレベルのタスクが付与されています。
+ レポートを実行
+ ジョブの管理
+ 共有スケジュールの管理
+ 共有スケジュールの表示
ルートフォルダでの `Content Manager` のアイテムレベルのロールも付与されます。
## ウェブポータルへのアクセス
`SSRS_GRANT_PORTAL_PERMISSION` タスクが正常に終了すると、ウェブブラウザを使用してポータルにアクセスできるようになります。ウェブポータル URL の形式を次に示します。
```
https://rds_endpoint:port/Reports
```
この形式では、以下が適用されます。
+ *`rds_endpoint`* - SSRS で使用している RDS DB インスタンスのエンドポイント。
エンドポイントは、DB インスタンスの [**接続とセキュリティ**] タブにあります。詳細については、「[SQL Server DB インスタンスへの接続](USER_ConnectToMicrosoftSQLServerInstance.md)」を参照してください。
+ `port` - `SSRS` オプションで設定した SSRS のリスナーポート。
**ウェブポータルにアクセスするには**
1. ブラウザにウェブポータルの URL を入力します。
```
https://myssrsinstance.cg034itsfake.us-east-1.rds.amazonaws.com:8443/Reports
```
1. `SSRS_GRANT_PORTAL_PERMISSION` タスクでアクセス権を付与したドメインユーザーの認証情報を使用してログインします。
# レポートのデプロイとレポートデータソースの設定
SSRS にレポートをデプロイし、レポートデータソースを設定するには、次の手順に従います。
**Topics**
+ [SSRS へのレポートのデプロイ](#SSRS.Deploy)
+ [レポートのデータソースの設定](#SSRS.ConfigureDataSource)
## SSRS へのレポートのデプロイ
ウェブポータルにアクセスした後は、ウェブポータルにレポートをデプロイできます。ウェブポータルのアップロードツールを使用して、レポートをアップロードしたり、[SQL Server データツール (SSDT)](https://docs.microsoft.com/en-us/sql/ssdt/download-sql-server-data-tools-ssdt) から直接デプロイしたりできます。SSDT からデプロイする場合は、次の点を確認してください。
+ SSDT を起動したユーザーは、SSRS ウェブポータルにアクセスできます。
+ SSRS プロジェクトプロパティの `TargetServerURL` の値は、`ReportServer` サフィックスが付加された RDS DB インスタンスの HTTPS エンドポイントに設定されます。次に例を示します。
```
https://myssrsinstance.cg034itsfake.us-east-1.rds.amazonaws.com:8443/ReportServer
```
## レポートのデータソースの設定
レポートを SSRS にデプロイした後、レポートのデータソースを設定する必要があります。レポートのデータソースを設定するときには、次の点を確認してください。
+ RDS for SQL Server DB インスタンスが AWS Directory Service for Microsoft Active Directory に結合されている場合、接続文字列のデータソース名として完全修飾ドメイン名 (FQDN) を使用してください。例えば、`myssrsinstance.corp-ad.example.com` を使用します。ここで、`myssrsinstance` は DB インスタンス名、`corp-ad.example.com` は完全修飾ドメイン名です。
+ 自己管理型の Active Directory に結合された RDS for SQL Server DB インスタンスの場合、接続文字列のデータソース名として `.` または `LocalHost` を使用します。
# SSRS E メールを使用してレポートを送信する
SSRS には SSRS E メール拡張機能が含まれており、これを使用してユーザーにレポートを送信できます。
SSRS E メールを設定するには、`SSRS` オプション設定を使用します。(詳しくは、「[オプショングループへの SSRS オプションの追加](SSRS.Enabling.md#SSRS.Add)」を参照してください。)
SSRS E メールを設定すると、レポートサーバー上のレポートを購読できます。詳細については、Microsoft ドキュメントの「[レポートサービスでの E メール配信](https://docs.microsoft.com/en-us/sql/reporting-services/subscriptions/e-mail-delivery-in-reporting-services)」を参照してください。
SSRS E メールが RDS 上で機能するためには、AWS Secrets Manager との統合が必要です。Secrets Manager と統合するには、シークレットを作成します。
**注記**
シークレットを後で変更する場合は、オプショングループで `SSRS` オプションも更新する必要があります。
**SSRS E メールのシークレットを作成するには**
1. [AWS Secrets Manager ユーザーガイド](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html)にある「*シークレットを作成する*」のステップに従います。
1. **[Select secret type]** (シークレットタイプの選択) で、**[Other type of secrets]** (他の種類のシークレット) を選択します。
1. **[Key/value pairs]** (キー/値ペア) で、次のように入力します。
+ **SMTP\$1USERNAME** — SMTP サーバーからメールを送信するアクセス許可を持つユーザーを入力します。
+ **SMTP\$1PASSWORD** — SMTP ユーザーのパスワードを入力します。
1. **暗号化キー**では、デフォルトの AWS KMS key を使用しないでください。独自の既存のキーを使用するか、新しく作成します。
KMS キーポリシーでは、`kms:Decrypt` アクションを許可する必要があります。例:
```
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"Service": [
"rds.amazonaws.com"
]
},
"Action": [
"kms:Decrypt"
],
"Resource": "*"
}
```
1. *AWS Secrets Managerユーザーガイド*の「[アクセス許可ポリシーをシークレットにアタッチする](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_resource-policies.html)」のステップに従います。アクセス許可ポリシーは、`rds.amazonaws.com` サービスプリンシパルに `secretsmanager:GetSecretValue` アクションを与えます。
*Confused Deputy* Problem (混乱した代理の問題) を回避するために、ポリシーの `aws:sourceAccount` および `aws:sourceArn` 条件を使用することをお勧めします。`aws:sourceAccount` には AWS アカウント を使用し、`aws:sourceArn` にはオプショングループ ARN を使用します。(詳しくは、「[サービス間での混乱した代理問題の防止](cross-service-confused-deputy-prevention.md)」を参照してください。)
以下の例に示しているのは、アクセス許可ポリシーです。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement" : [ {
"Effect" : "Allow",
"Principal" : {
"Service" : "rds.amazonaws.com"
},
"Action" : "secretsmanager:GetSecretValue",
"Resource" : "*",
"Condition" : {
"StringEquals" : {
"aws:sourceAccount" : "123456789012"
},
"ArnLike" : {
"aws:sourceArn" : "arn:aws:rds:us-west-2:123456789012:og:ssrs-se-2017"
}
}
} ]
}
```
------
その他の例については、「*AWS Secrets Manager ユーザーガイド*」の「[AWS Secrets Manager のアクセス許可ポリシーの例](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples.html)」を参照してください。
# システムレベルのアクセス許可の取り消し
`RDS_SSRS_ROLE` システムロールには、システムレベルのロールの割り当てを削除するための十分なアクセス許可がありません。`RDS_SSRS_ROLE` からユーザーまたはユーザーグループを削除するには、ロールの付与に使用したものと同じストアドプロシージャを使用します。ただし、`SSRS_REVOKE_PORTAL_PERMISSION` タスクタイプを使用します。
**ウェブポータルのドメインユーザーからアクセス権を取り消すには**
+ 次のストアドプロシージャを使用します。
```
exec msdb.dbo.rds_msbi_task
@task_type='SSRS_REVOKE_PORTAL_PERMISSION',
@ssrs_group_or_username=N'AD_domain\user';
```
これにより、ユーザーが `RDS_SSRS_ROLE` システムロールから削除されます。また、ユーザーが `Content Manager` アイテムレベルのロールを持っている場合、このロールからも削除されます。
# タスクのステータスのモニタリング
タスクの権限付与または取り消しのステータスを追跡するには、`rds_fn_task_status` 関数を呼び出します。2 つのパラメータを使用します。1 つめのパラメータは、SSRS に適用されないため、常に `NULL` を設定してください。2 つめのパラメータは、タスク ID を受け入れます。
全タスクのリストを見るには、以下の例にあるように、初期のパラメータを `NULL` に設定し、2 つめのパラメータを `0` に設定します。
```
SELECT * FROM msdb.dbo.rds_fn_task_status(NULL,0);
```
特定のタスクを受け取るには、以下の例にあるように、初期のパラメータを `NULL` に設定し、2 つめのパラメータをタスク ID に設定します。
```
SELECT * FROM msdb.dbo.rds_fn_task_status(NULL,42);
```
`rds_fn_task_status` 機能は次の情報を返します。
| 出力パラメータ | 説明 |
| --- | --- |
| `task_id` | タスクの ID。 |
| `task_type` | SSRS では、次のタスクタイプを使用できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/SSRS.Monitor.html) |
| `database_name` | SSRS タスクは該当しません。 |
| `% complete` | タスクの進行状況の割合。 |
| `duration (mins)` | タスクにかかった時間 (分単位)。 |
| `lifecycle` | タスクのステータス。有効な状態には以下のものがあります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/SSRS.Monitor.html) |
| `task_info` | タスクに関する追加情報。処理中にエラーが発生した場合、この列にエラーに関する情報が含まれます。 |
| `last_updated` | タスクのステータスが最後に更新された日時。 |
| `created_at` | タスクが作成された日時。 |
| `S3_object_arn` | SSRS タスクは該当しません。 |
| `overwrite_S3_backup_file` | SSRS タスクは該当しません。 |
| `KMS_master_key_arn` | SSRS タスクは該当しません。 |
| `filepath` | SSRS タスクは該当しません。 |
| `overwrite_file` | SSRS タスクは該当しません。 |
| `task_metadata` | SSRS タスクに関連付けられたメタデータ。 |
# SSRS データベースの無効化と削除
SSRS を無効にし、SSRS データベースを削除するには、次の手順に従います。
**Topics**
+ [SSRS をオフにする](#SSRS.Disable)
+ [SSRS データベースの削除](#SSRS.Drop)
## SSRS をオフにする
SSRS をオフにするには、オプショングループから `SSRS` オプションを削除します。このオプションを削除しても、SSRS データベースは削除されません。(詳しくは、「[SSRS データベースの削除](#SSRS.Drop)」を参照してください。)
`SSRS` オプションを再び追加することで、SSRS を再びオンにすることができます。SSRS データベースも削除した場合は、同じ DB インスタンスでオプションを再度有効にすると、新しいレポートサーバーデータベースが作成されます。
### コンソール
**SSRS オプションをオプショングループから削除するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. `SSRS` オプションが含まれているオプショングループ (前の例では `ssrs-se-2017`) を選択します。
1. [**オプションの削除**] を選択します。
1. [**オプションの削除**] で、[**削除するオプション**] として [**SSRS**] を選択します。
1. [**すぐに適用**] で、オプションをすぐに削除する場合は [**はい**] を選択し、次のメンテナンスウィンドウで削除する場合は [**いいえ**] を選択します。
1. [**削除**] を選択します。
### CLI
**SSRS オプションをオプショングループから削除するには**
+ 以下のいずれかのコマンドを実行します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds remove-option-from-option-group \
--option-group-name ssrs-se-2017 \
--options SSRS \
--apply-immediately
```
Windows の場合:
```
aws rds remove-option-from-option-group ^
--option-group-name ssrs-se-2017 ^
--options SSRS ^
--apply-immediately
```
## SSRS データベースの削除
`SSRS` オプションを削除しても、レポートサーバーデータベースは削除されません。それらを削除するには、次のストアドプロシージャを使用します。
レポートサーバーデータベースを削除するには、必ず初期に `SSRS` オプションを削除してください。
**SSRS データベースを削除するには**
+ 次のストアドプロシージャを使用します。
```
exec msdb.dbo.rds_drop_ssrs_databases
```
# RDS for SQL Server での Microsoft 分散トランザクションコーディネーターのサポート
*分散トランザクション*は、2 つ以上のネットワークホストが関与するデータベーストランザクションです。RDS for SQL Server では、ホスト間の分散トランザクションをサポートしています。この場合、ホストの 1 つとして次のいずれかを含みます。
+ RDS for SQL Server の DB インスタンス
+ オンプレミスの SQL Server ホスト
+ SQL Server がインストールされている Amazon EC2 ホスト
+ 分散トランザクションをサポートするデータベースエンジンを備えた他の EC2 ホストまたは RDS DB インスタンス
RDS では、SQL Server 2012 以降 (バージョン 11.00.5058.0.v1 以降)、RDS for SQL Server のすべてのエディションで分散トランザクションがサポートされています。サポートは、Microsoft 分散トランザクションコーディネーター (MSDTC) を使用して提供されます。MSDTC の詳細については、Microsoft のドキュメントの「[分散トランザクションコーディネーター](https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ms684146(v=vs.85))」を参照してください。
**Contents**
+ [制限事項](#Appendix.SQLServer.Options.MSDTC.Limitations)
+ [MSDTC の有効化](Appendix.SQLServer.Options.MSDTC.Enabling.md)
+ [MSDTC のオプショングループの作成](Appendix.SQLServer.Options.MSDTC.Enabling.md#Appendix.SQLServer.Options.MSDTC.OptionGroup)
+ [オプショングループへの MSDTC オプションの追加](Appendix.SQLServer.Options.MSDTC.Enabling.md#Appendix.SQLServer.Options.MSDTC.Add)
+ [MSDTC のパラメータグループの作成](Appendix.SQLServer.Options.MSDTC.Enabling.md#MSDTC.CreateParamGroup)
+ [MSDTC のパラメータの変更](Appendix.SQLServer.Options.MSDTC.Enabling.md#ModifyParam.MSDTC)
+ [DB インスタンスとのオプショングループおよびパラメータグループの関連付け](Appendix.SQLServer.Options.MSDTC.Enabling.md#MSDTC.Apply)
+ [MSDTC オプションの変更](Appendix.SQLServer.Options.MSDTC.Enabling.md#Appendix.SQLServer.Options.MSDTC.Modify)
+ [トランザクションの使用](#Appendix.SQLServer.Options.MSDTC.Using)
+ [分散トランザクションの使用](#Appendix.SQLServer.Options.MSDTC.UsingXA)
+ [XA トランザクションの使用](#MSDTC.XA)
+ [トランザクションの追跡の使用](#MSDTC.Tracing)
+ [MSDTC の無効化](Appendix.SQLServer.Options.MSDTC.Disable.md)
+ [RDS for SQL Server の MSDTC のトラブルシューティング](Appendix.SQLServer.Options.MSDTC.Troubleshooting.md)
## 制限事項
RDS for SQL Server で MSDTC を使用する場合は、次の制限が適用されます。
+ MSDTC は、SQL Server データベースミラーリングを使用するインスタンスではサポートされません。詳細については、「[トランザクション - 可用性グループとデータベースミラーリング](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/transactions-always-on-availability-and-database-mirroring?view=sql-server-ver15#non-support-for-distributed-transactions)」を参照してください。
+ `in-doubt xact resolution` パラメータは 1 または 2 に設定する必要があります。詳細については、「[MSDTC のパラメータの変更](Appendix.SQLServer.Options.MSDTC.Enabling.md#ModifyParam.MSDTC)」を参照してください。
+ MSDTC では、分散トランザクションに参加するすべてのホストをホスト名を使用して解決可能にする必要があります。RDS は、ドメインに参加しているインスタンスに対してこの機能を自動的に維持します。ただし、スタンドアロンインスタンスの場合は、必ず DNS サーバーを手動で設定してください。
+ Java Database Connectivity (JDBC) XA トランザクションは、SQL Server 2017 バージョン 14.00.3223.3 以降および SQL Server 2019 でサポートされています。
+ RDS インスタンス上のクライアント動的リンクライブラリ (DLL) に依存する分散トランザクションはサポートされていません。
+ カスタム XA 動的リンクライブラリの使用はサポートされていません。
# MSDTC の有効化
DB インスタンスに対して MSDTC を有効にするには、次のプロセスを使用します。
1. 新しいオプショングループを作成するか、既存のオプショングループを選択します。
1. オプショングループに [`MSDTC`] オプションを追加します。
1. 新しいパラメータグループを作成するか、既存のパラメータグループを選択します。
1. パラメータグループを変更して、`in-doubt xact resolution` パラメータを 1 または 2 に設定します。
1. オプショングループとパラメータグループを DB インスタンスに関連付けます。
## MSDTC のオプショングループの作成
AWS マネジメントコンソール または AWS CLI を使用して、使用する DB インスタンスの SQL Server エンジンおよびバージョンに対応するオプショングループを作成します。
**注記**
既存のオプショングループが正しい SQL Server エンジンおよびバージョンに対応している場合は、それを使用することもできます。
### コンソール
次の手順では、SQL Server Standard Edition 2016 のオプショングループを作成します。
**オプショングループを作成するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. **[Create group]** (グループの作成) を選択します。
1. [**オプショングループの作成**] ウィンドウで、次の操作を行います。
1. [**名前**] に、AWS アカウント内で一意のオプショングループ名 (**msdtc-se-2016** など) を入力します。名前には、英字、数字、ハイフンのみを使用できます。
1. [**説明**] に、オプショングループの簡単な説明 (**MSDTC option group for SQL Server SE 2016** など) を入力します。この説明は表示用に使用されます。
1. [**エンジン**] で [**sqlserver-se**] を選択します。
1. [**メジャーエンジンのバージョン**] で、[**13.00**] を選択します。
1. [**Create**] (作成) を選択します。
### CLI
次の例では、SQL Server Standard Edition 2016 のオプショングループを作成します。
**オプショングループを作成するには**
+ 以下のいずれかのコマンドを使用します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds create-option-group \
--option-group-name msdtc-se-2016 \
--engine-name sqlserver-se \
--major-engine-version 13.00 \
--option-group-description "MSDTC option group for SQL Server SE 2016"
```
Windows の場合:
```
aws rds create-option-group ^
--option-group-name msdtc-se-2016 ^
--engine-name sqlserver-se ^
--major-engine-version 13.00 ^
--option-group-description "MSDTC option group for SQL Server SE 2016"
```
## オプショングループへの MSDTC オプションの追加
次に、AWS マネジメントコンソール または AWS CLI を使用して `MSDTC` オプションをオプショングループに追加します。
次のオプション設定が必要です。
+ **ポート** - MSDTC にアクセスするために使用するポート。指定できる値は、1234、1434、3260、3343、3389、47001 を除く、1150～49151 です。デフォルト値は 5000 です。
使用するポートがファイアウォールルールで有効になっていることを確認します。また、必要に応じて、DB インスタンスに関連付けられているセキュリティグループのインバウンドルールとアウトバウンドルールでこのポートが有効になっていることを確認します。(詳しくは、「[Amazon RDS DB インスタンスに接続できない](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting)」を参照してください。)
+ **セキュリティグループ** - RDS DB インスタンスの VPC セキュリティグループのメンバーシップ。
+ **認証タイプ** - ホスト間の認証モード。次の認証タイプがサポートされています。
+ 相互 - RDS インスタンスは、統合認証を使用して相互に認証されます。このオプションを選択した場合、このオプショングループに関連付けられているすべてのインスタンスがドメインに参加している必要があります。
+ なし - ホスト間での認証は実行されません。本稼働環境でこのモードを使用することは推奨されていません。
+ **トランザクションログサイズ** - MSDTC トランザクションログのサイズ。許容値は、4～1024 MB です。デフォルトサイズは 4 MB です。
次のオプション設定はオプションです。
+ [**インバウンド接続を有効にする**] - このオプショングループに関連付けられているインスタンスへのインバウンド MSDTC 接続を許可するかどうかを指定します。
+ [**アウトバウンド接続を有効にする**] - このオプショングループに関連付けられているインスタンスからのアウトバウンド MSDTC 接続を許可するかどうかを指定します。
+ **XA を有効にする X** - XA トランザクションを許可するかどうかを指定します。XA プロトコルの詳細については、「[XA 仕様](https://publications.opengroup.org/c193)」を参照してください。
+ **SNA LU を有効にする** - SNA LU プロトコルを分散トランザクションに使用できるようにするかどうかを指定します。SNA LU プロトコルのサポートの詳細については、Microsoft ドキュメントの「[Managing IBM CICS LU 6.2 transactions](https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ms685136(v=vs.85))」を参照してください。
### コンソール
**MSDTC オプションを追加するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. 先ほど作成したオプショングループを選択します。
1. [**オプションの追加**] を選択します。
1. [**オプションの詳細**] で、[**オプション名**] として **MSDTC** を選択します。
1. [**オプション設定**] で、次の操作を行います。
1. [**ポート**] に、MSDTC にアクセスするためのポート番号を入力します。デフォルトは **5000** です。
1. **[セキュリティグループ]** で、オプションに関連付ける VPC セキュリティグループを選択します。
1. [**認証タイプ**] で [**相互**] または [**なし**] を選択します。
1. [**トランザクションログのサイズ**] に、4～24 の値を入力します。デフォルト値は **4** です。
1. [**追加設定**] で、次の操作を行います。
1. [**接続**] で、必要に応じて [**インバウンド接続を有効にする**] と [**アウトバウンド接続を有効にする**] を選択します。
1. [**許可されたプロトコル**] で、必要に応じて [**XA を有効にする**] と [**SNA LU を有効にする**] を選択します。
1. [**スケジュール**] で、オプションをすぐに追加するか、次のメンテナンスウィンドウで追加するかを選択します。
1. [**オプションの追加**] を選択します。
このオプションを追加するにあたって再起動は必要ありません。
### CLI
**MSDTC オプションを追加するには**
1. 次の必須のパラメータを使用して、JSON ファイル (`msdtc-option.json` など) を作成します。
```
{
"OptionGroupName":"msdtc-se-2016",
"OptionsToInclude": [
{
"OptionName":"MSDTC",
"Port":5000,
"VpcSecurityGroupMemberships":["sg-0abcdef123"],
"OptionSettings":[{"Name":"AUTHENTICATION","Value":"MUTUAL"},{"Name":"TRANSACTION_LOG_SIZE","Value":"4"}]
}],
"ApplyImmediately": true
}
```
1. オプショングループに [`MSDTC`] オプションを追加します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds add-option-to-option-group \
--cli-input-json file://msdtc-option.json \
--apply-immediately
```
Windows の場合:
```
aws rds add-option-to-option-group ^
--cli-input-json file://msdtc-option.json ^
--apply-immediately
```
再起動は必要ありません。
## MSDTC のパラメータグループの作成
DB インスタンスの SQL Server のエディションとバージョンに対応する `in-doubt xact resolution` パラメータのパラメータグループを作成または変更します。
### コンソール
次の例では、SQL Server Standard Edition 2016 のパラメータグループを作成します。
**パラメータグループを作成するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、**[パラメータグループ]** を選択します。
1. **[パラメータグループの作成]** を選択します。
1. [**パラメータグループの作成**] ペインで、次の操作を行います。
1. [**パラメータグループファミリー**] で、[**sqlserver-se-13.0**] を選択します。
1. [**グループ名**] に、パラメータグループの識別子 (**msdtc-sqlserver-se-13** など) を入力します。
1. [**説明**] に「**in-doubt xact resolution**」と入力します。
1. [**Create**] (作成) を選択します。
### CLI
次の例では、SQL Server Standard Edition 2016 のパラメータグループを作成します。
**パラメータグループを作成するには**
+ 以下のいずれかのコマンドを使用します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds create-db-parameter-group \
--db-parameter-group-name msdtc-sqlserver-se-13 \
--db-parameter-group-family "sqlserver-se-13.0" \
--description "in-doubt xact resolution"
```
Windows の場合:
```
aws rds create-db-parameter-group ^
--db-parameter-group-name msdtc-sqlserver-se-13 ^
--db-parameter-group-family "sqlserver-se-13.0" ^
--description "in-doubt xact resolution"
```
## MSDTC のパラメータの変更
DB インスタンスの SQL Server のエディションとバージョンに対応するパラメータグループの `in-doubt xact resolution` パラメータを変更します。
MSDTC の場合、`in-doubt xact resolution` パラメータに次のいずれかの値を設定します。
+ `1` - `Presume commit`。MSDTC の in-doubt トランザクションは、コミットされたものと見なされます。
+ `2` - `Presume abort`。MSDTC の in-doubt トランザクションは、停止されたものと見なされます。
詳細については、Microsoft ドキュメント の「[in-doubt xact resolution server configuration option](https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/in-doubt-xact-resolution-server-configuration-option)」を参照してください。
### コンソール
次の例では、SQL Server Standard Edition 2016 用に作成したパラメータグループを変更します。
**パラメータグループを変更するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**パラメータグループ**] を選択します。
1. **msdtc-sqlserver-se-13** などのパラメータグループを選択します。
1. [**パラメータ**] で、パラメータのリストを **xact** でフィルタ処理します。
1. **in-doubt xact resolution** を選択します。
1. [**Edit parameters**] を選択します。
1. **1** または **2** を入力します。
1. [**Save changes**] (変更の保存) をクリックします。
### CLI
次の例では、SQL Server Standard Edition 2016 用に作成したパラメータグループを変更します。
**パラメータグループを変更するには**
+ 以下のいずれかのコマンドを使用します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name msdtc-sqlserver-se-13 \
--parameters "ParameterName='in-doubt xact resolution',ParameterValue=1,ApplyMethod=immediate"
```
Windows の場合:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name msdtc-sqlserver-se-13 ^
--parameters "ParameterName='in-doubt xact resolution',ParameterValue=1,ApplyMethod=immediate"
```
## DB インスタンスとのオプショングループおよびパラメータグループの関連付け
AWS マネジメントコンソール または AWS CLI を使用すると、MSDTC オプショングループおよびパラメータグループを DB インスタンスに関連付けることができます。
### コンソール
MSDTC オプショングループおよびパラメータグループを新規または既存の DB インスタンスに関連付けることができます。
+ 新しい DB インスタンスの場合は、インスタンスを起動するときにそれらを関連付けます。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の DB インスタンスの場合は、インスタンスを変更することでそれらを関連付けます。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
**注記**
ドメイン参加済みの既存の DB インスタンスを使用する場合は、このインスタンスに Active Directory ドメインおよび AWS Identity and Access Management (IAM) ロールが既に関連付けられている必要があります。新しいドメイン参加済みのインスタンスを作成する場合は、既存の Active Directory ドメインと IAM ロールを指定します。詳細については、「[RDS for SQL Server による AWS Managed Active Directory の操作](USER_SQLServerWinAuth.md)」を参照してください。
### CLI
MSDTC オプショングループおよびパラメータグループを新規または既存の DB インスタンスに関連付けることができます。
**注記**
既存のドメイン参加済みの DB インスタンスを使用する場合は、このインスタンスに Active Directory ドメインと IAM ロールが既に関連付けられている必要があります。新しいドメイン参加済みのインスタンスを作成する場合は、既存の Active Directory ドメインと IAM ロールを指定します。詳細については、「[RDS for SQL Server による AWS Managed Active Directory の操作](USER_SQLServerWinAuth.md)」を参照してください。
**MSDTC オプショングループおよびパラメータグループを使用して DB インスタンスを作成するには**
+ オプショングループの作成時に使用したものと同じ DB エンジンのタイプとメジャーバージョンを指定します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds create-db-instance \
--db-instance-identifier mydbinstance \
--db-instance-class db.m5.2xlarge \
--engine sqlserver-se \
--engine-version 13.00.5426.0.v1 \
--allocated-storage 100 \
--manage-master-user-password \
--master-username admin \
--storage-type gp2 \
--license-model li \
--domain-iam-role-name my-directory-iam-role \
--domain my-domain-id \
--option-group-name msdtc-se-2016 \
--db-parameter-group-name msdtc-sqlserver-se-13
```
Windows の場合:
```
aws rds create-db-instance ^
--db-instance-identifier mydbinstance ^
--db-instance-class db.m5.2xlarge ^
--engine sqlserver-se ^
--engine-version 13.00.5426.0.v1 ^
--allocated-storage 100 ^
--manage-master-user-password ^
--master-username admin ^
--storage-type gp2 ^
--license-model li ^
--domain-iam-role-name my-directory-iam-role ^
--domain my-domain-id ^
--option-group-name msdtc-se-2016 ^
--db-parameter-group-name msdtc-sqlserver-se-13
```
**DB インスタンスを変更し、MSDTC オプショングループとパラメータグループを関連付けるには**
+ 以下のいずれかのコマンドを使用します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--option-group-name msdtc-se-2016 \
--db-parameter-group-name msdtc-sqlserver-se-13 \
--apply-immediately
```
Windows の場合:
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--option-group-name msdtc-se-2016 ^
--db-parameter-group-name msdtc-sqlserver-se-13 ^
--apply-immediately
```
## MSDTC オプションの変更
`MSDTC` オプションを有効にすると、その設定を変更できます。オプション設定の変更方法の詳細については、「[オプションの設定を変更する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.ModifyOption)」を参照してください。
**注記**
MSDTC オプション設定の一部の変更では、MSDTC サービスを再起動する必要があります。この要件は、実行中の分散トランザクションに影響を与える可能性があります。
## トランザクションの使用
### 分散トランザクションの使用
Amazon RDS for SQL Server では、オンプレミスで実行されている分散トランザクションと同じ方法で分散トランザクションを実行します。
+ .NET フレームワークの `System.Transactions` 昇格可能トランザクションを使用します。これにより、必要になるまで作成を延期することで分散トランザクションが最適化されます。
この場合、昇格は自動的に行われるため、ユーザーが介入する必要はありません。トランザクション内にリソースマネージャーが 1 つのみ存在する場合、昇格は実行されません。暗黙的なトランザクションスコープの詳細については、Microsoft ドキュメントの「[トランザクションスコープを使用した暗黙的なトランザクションの実装](https://docs.microsoft.com/en-us/dotnet/framework/data/transactions/implementing-an-implicit-transaction-using-transaction-scope)」を参照してください。
昇格可能なトランザクションは、次の .NET 実装でサポートされています。
+ ADO.NET 2.0 以降、`System.Data.SqlClient` では SQL Server での昇格可能トランザクションをサポートしています。詳細については、Microsoft のドキュメントの「[SQL Server と System.Transations の統合](https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/system-transactions-integration-with-sql-server)」を参照してください。
+ ODP.NET は `System.Transactions` をサポートしています。ローカルトランザクションは、Oracle Database 11g リリース 1 (バージョン11.1) 以降への `TransactionsScope` スコープで開かれた初期の接続に対して作成されます。2 番目の接続が開かれると、このトランザクションは自動的に分散トランザクションに昇格されます。ODP.NET での分散トランザクションのサポートの詳細については、Oracle ドキュメントの「[Microsoft Distributed Transaction Coordinator Integration](https://docs.oracle.com/en/database/oracle/oracle-data-access-components/18.3/ntmts/using-mts-with-oracledb.html)」を参照してください。
+ `BEGIN DISTRIBUTED TRANSACTION` ステートメントを使用します。詳細については、Microsoft のドキュメントの「[BEGIN DISTRIBUTED TRANSACTION (Transact-SQL)](https://docs.microsoft.com/en-us/sql/t-sql/language-elements/begin-distributed-transaction-transact-sql)」を参照してください。
### XA トランザクションの使用
RDS for SQL Server 2017 バージョン 14.00.3223.3 以降、JDBC を使用して分散トランザクションを制御できます。`MSDTC` オプションで `Enable XA` オプション設定を`true` に設定すると、RDS では JDBC トランザクションが自動的に有効化され、`SqlJDBCXAUser` ロールが `guest` ユーザーに付与されます。これにより、JDBC を使用した分散トランザクションの実行が可能になります。コード例も含めた詳細については、Microsoft のドキュメントの「[XA トランザクションについて](https://docs.microsoft.com/en-us/sql/connect/jdbc/understanding-xa-transactions)」を参照してください。
### トランザクションの追跡の使用
RDS では、トラブルシューティングの目的で MSDTC トランザクションの追跡を制御し、RDS DB インスタンスからこれらをダウンロードできます。トランザクションの追跡セッションは、次の RDS ストアドプロシージャを実行することで制御できます。
```
exec msdb.dbo.rds_msdtc_transaction_tracing 'trace_action',
[@traceall='0|1'],
[@traceaborted='0|1'],
[@tracelong='0|1'];
```
以下のパラメータは必須です。
+ `trace_action` - 追跡アクション。`START`、`STOP` または `STATUS` のいずれかを設定できます。
以下のパラメータはオプションです。
+ `@traceall` - すべての分散トランザクションを追跡するには、1 に設定します。デフォルトは 0 です。
+ `@traceaborted` - キャンセルされた分散トランザクションを追跡するには、1 に設定します。デフォルトは 0 です。
+ `@tracelong` - 長時間実行される分散トランザクションを追跡するには、1 に設定します。デフォルトは 0 です。
**Example START 追跡アクション例**
新しいトランザクション追跡セッションをスタートするには、次のステートメント例を実行します。
```
exec msdb.dbo.rds_msdtc_transaction_tracing 'START',
@traceall='0',
@traceaborted='1',
@tracelong='1';
```
一度にアクティブにできるトランザクション追跡セッションは 1 つだけです。追跡セッションがアクティブなときに新しい追跡セッションの `START` コマンドが発行されると、エラーが返され、アクティブな追跡セッションは変更されません。
**Example STOP 追跡アクション例**
トランザクション追跡セッションを停止するには、次のステートメントを実行します。
```
exec msdb.dbo.rds_msdtc_transaction_tracing 'STOP'
```
このステートメントは、アクティブなトランザクション追跡セッションを停止し、トランザクション追跡データを RDS DB インスタンスのログディレクトリに保存します。出力の初期の行には全体的な結果が含まれ、後続の行はオペレーションの詳細を示します。
追跡セッションが正常に停止した例を次に示します。
```
OK: Trace session has been successfully stopped.
Setting log file to: D:\rdsdbdata\MSDTC\Trace\dtctrace.log
Examining D:\rdsdbdata\MSDTC\Trace\msdtctr.mof for message formats, 8 found.
Searching for TMF files on path: (null)
Logfile D:\rdsdbdata\MSDTC\Trace\dtctrace.log:
OS version 10.0.14393 (Currently running on 6.2.9200)
Start Time
End Time
Timezone is @tzres.dll,-932 (Bias is 0mins)
BufferSize 16384 B
Maximum File Size 10 MB
Buffers Written Not set (Logger may not have been stopped).
Logger Mode Settings (11000002) ( circular paged
ProcessorCount 1
Processing completed Buffers: 1, Events: 3, EventsLost: 0 :: Format Errors: 0, Unknowns: 3
Event traces dumped to d:\rdsdbdata\Log\msdtc_.log
```
詳細情報を使用して、生成されたログファイル名のクエリを実行できます。RDS DB インスタンスからのログファイルのダウンロードの詳細については、「[Amazon RDS ログファイルのモニタリング](USER_LogAccess.md)」を参照してください。
追跡セッションログは、インスタンスに 35 日間残されます。古い追跡セッションのログは自動的に削除されます。
**Example STATUS 追跡アクション例**
トランザクション追跡セッションのステータスを追跡するには、次のステートメントを実行します。
```
exec msdb.dbo.rds_msdtc_transaction_tracing 'STATUS'
```
このステートメントは、結果セットの個別の行として以下を出力します。
```
OK
SessionStatus:
TraceAll:
TraceAborted:
TraceLongLived:
```
初期の行は、操作の全体的な結果を示します。該当する場合は `OK` または `ERROR` と詳細も表示されます。後続の行は、追跡セッションのステータスに関する詳細を示します。
+ `SessionStatus` の値は次のいずれかを指定できます。
+ `Started`追跡セッションが実行中の場合は 。
+ `Stopped`実行中の追跡セッションがない場合は 。
+ 追跡セッションフラグは、`True` コマンドでの設定方法によって `False` または `START` のどちらかになります。
# MSDTC の無効化
MSDTC を無効にするには、`MSDTC` オプションをそのオプショングループから削除します。
## コンソール
**MSDTC オプションをそのオプショングループから削除するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. `MSDTC` オプションが含まれているオプショングループ (前の例では `msdtc-se-2016`) を選択します。
1. [**オプションの削除**] を選択します。
1. [**オプションの削除**] で、[**削除するオプション**] として [**MSCTC**] を選択します。
1. [**すぐに適用**] で、オプションをすぐに削除する場合は [**はい**] を選択し、次のメンテナンスウィンドウで削除する場合は [**いいえ**] を選択します。
1. [**削除**] を選択します。
## CLI
**MSDTC オプションをそのオプショングループから削除するには**
+ 以下のいずれかのコマンドを使用します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds remove-option-from-option-group \
--option-group-name msdtc-se-2016 \
--options MSDTC \
--apply-immediately
```
Windows の場合:
```
aws rds remove-option-from-option-group ^
--option-group-name msdtc-se-2016 ^
--options MSDTC ^
--apply-immediately
```
# RDS for SQL Server の MSDTC のトラブルシューティング
場合によっては、クライアントコンピュータで実行されている MSDTC と RDS for SQL Server DB インスタンスで実行されている MSDTC サービスとの間の接続を確立できないことがあります。その場合は、以下のことを確認してください。
+ DB インスタンスに関連付けられているセキュリティグループのインバウンドルールが正しく設定されている。詳細については、「[Amazon RDS DB インスタンスに接続できない](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting)」を参照してください。
+ クライアントコンピュータが正しく設定されている。
+ クライアントコンピュータの MSDTC ファイアウォールルールが有効になっている。
**クライアントコンピュータを設定するには**
1. [**コンポーネントサービス**] を開きます。
または、[**サービスマネージャー**] で、[**ツール**]、[**コンポーネントサービス**] の順に選択します。
1. [**コンポーネントサービス**]、[**コンピュータ**]、[**マイコンピュータ**]、[**分散トランザクションコーディネーター**] の順に展開します。
1. [**ローカル DTC**] のコンテキスト (右クリック) メニューを開き、[**プロパティ**] を選択します。
1. [**セキュリティ**] タブを選択します。
1. 次の項目をすべて選択します。
+ **ネットワーク DTC アクセス**
+ **受信を許可する**
+ **送信を許可する**
1. 正しい認証モードが選択されていることを確認します。
+ **相互認証を必要とする** - クライアントマシンは、分散トランザクションに参加している他のノードと同じドメインに参加しているか、ドメイン間に信頼関係が設定されています。
+ **認証を必要としない** - 他のすべてのケース。
1. [**OK**] を選択して変更を保存します。
1. サービスの再起動を求めるメッセージが表示されたら、[**はい**] を選択します。
**MSDTC ファイアウォールルールを有効にするには**
1. Windows ファイアウォールを開き、[**詳細設定**] を選択します。
または、[**サーバー マネージャー**] で、[**ツール**] を選択し、[**セキュリティが強化された Windows ファイアウォール**] を選択します。
**注記**
オペレーティングシステムによっては、Windows ファイアウォールを Windows Defender ファイアウォールと呼ぶ場合があります。
1. 左側のペインで [**受信ルール**] を選択します。
1. 次のファイアウォールルールが有効になっていない場合は、有効にします。
+ **分散トランザクションコーディネーター (RPC)**
+ **分散トランザクションコーディネーター (RPC)-EPMAP**
+ **分散トランザクションコーディネーター (TCP-In)**
1. Windows ファイアウォールを閉じます。
# RDS for SQL Server を使用した Microsoft SQL Server リソースガバナー
リソースガバナーは、インスタンスリソースを正確に制御できる SQL Server Enterprise Edition の機能です。これにより、ワークロードが CPU、メモリ、物理 I/O リソースを使用する方法に特定の制限を設定できます。リソースガバナーを使用すると、次のことができます。
+ さまざまなワークロードがインスタンスリソースを共有する方法を管理することで、マルチテナント環境でのリソースの独占を防ぐ
+ ユーザーやアプリケーションごとに特定のリソース制限と優先順位を設定することで、予測可能なパフォーマンスを実現する
既存の RDS for SQL Server DB インスタンスまたは新しい RDS for SQL Server DB インスタンスでリソースガバナーを有効にできます。
リソースガバナーは、次の 3 つの基本概念を使用します。
+ **リソースプール** - インスタンスの物理リソース (CPU、メモリ、I/O) を管理するコンテナ。2 つの組み込みプール (内部プールとデフォルトプール) を取得し、追加のカスタムプールを作成できます。
+ **ワークロードグループ** - 同様の特性を持つデータベースセッションのコンテナ。すべてのワークロードグループはリソースプールに属します。2 つの組み込みワークロードグループ (内部およびデフォルト) を取得し、追加のカスタムワークロードグループを作成できます。
+ **分類** - ユーザー名、アプリケーション名、データベース名、またはホスト名に基づいて、受信セッションを処理するワークロードグループを決定するプロセス。
SQL Server のリソースガバナー機能の詳細については、Microsoft ドキュメントの「[リソースガバナー](https://learn.microsoft.com/en-us/sql/relational-databases/resource-governor/resource-governor?view=sql-server-ver16)」を参照してください。
**Contents**
+ [サポート対象のバージョンとリージョン](#ResourceGovernor.SupportedVersions)
+ [制限と推奨事項](#ResourceGovernor.Limitations)
+ [RDS for SQL Server インスタンスの Microsoft SQL Server リソースガバナーを有効にする](ResourceGovernor.Enabling.md)
+ [`RESOURCE_GOVERNOR` のオプショングループの作成](ResourceGovernor.Enabling.md#ResourceGovernor.OptionGroup)
+ [`RESOURCE_GOVERNOR` オプションのオプショングループへの追加](ResourceGovernor.Enabling.md#ResourceGovernor.Add)
+ [オプショングループを DB インスタンスに関連付ける](ResourceGovernor.Enabling.md#ResourceGovernor.Apply)
+ [RDS for SQL Server インスタンスでの Microsoft SQL Server リソースガバナーの使用](ResourceGovernor.Using.md)
+ [リソースプールの管理](ResourceGovernor.Using.md#ResourceGovernor.ManageResourcePool)
+ [リソースプールの作成](ResourceGovernor.Using.md#ResourceGovernor.CreateResourcePool)
+ [リソースプールの変更](ResourceGovernor.Using.md#ResourceGovernor.AlterResourcePool)
+ [リソースプールの削除](ResourceGovernor.Using.md#ResourceGovernor.DropResourcePool)
+ [ワークロードグループの管理](ResourceGovernor.Using.md#ResourceGovernor.ManageWorkloadGroups)
+ [ワークロードグループを作成する](ResourceGovernor.Using.md#ResourceGovernor.CreateWorkloadGroup)
+ [ワークロードグループの変更](ResourceGovernor.Using.md#ResourceGovernor.AlterWorkloadGroup)
+ [ワークロードグループの削除](ResourceGovernor.Using.md#ResourceGovernor.DropWorkloadGroup)
+ [分類子関数を作成して登録する](ResourceGovernor.Using.md#ResourceGovernor.ClassifierFunction)
+ [分類子関数の削除](ResourceGovernor.Using.md#ResourceGovernor.DropClassifier)
+ [分類子関数の登録解除](ResourceGovernor.Using.md#ResourceGovernor.DeregisterClassifier)
+ [統計をリセットする](ResourceGovernor.Using.md#ResourceGovernor.ResetStats)
+ [リソースガバナーの設定変更](ResourceGovernor.Using.md#ResourceGovernor.ConfigChanges)
+ [TempDB をリソースプールにバインドする](ResourceGovernor.Using.md#ResourceGovernor.BindTempDB)
+ [リソースプールから TempDB をバインド解除する](ResourceGovernor.Using.md#ResourceGovernor.UnbindTempDB)
+ [リソースガバナーのクリーンアップ](ResourceGovernor.Using.md#ResourceGovernor.Cleanup)
+ [マルチ AZ 配置に関する考慮事項](#ResourceGovernor.Considerations)
+ [リードレプリカに関する考慮事項](#ResourceGovernor.ReadReplica)
+ [RDS for SQL Server インスタンスのシステムビューを使用して Microsoft SQL Server リソースガバナーをモニタリングする](ResourceGovernor.Monitoring.md)
+ [リソースプールランタイム統計](ResourceGovernor.Monitoring.md#ResourceGovernor.ResourcePoolStats)
+ [RDS for SQL Server インスタンスの Microsoft SQL Server リソースガバナーを無効にする](ResourceGovernor.Disabling.md)
+ [RDS for SQL Server でリソースガバナーを設定するためのベストプラクティス](ResourceGovernor.BestPractices.md)
## サポート対象のバージョンとリージョン
Amazon RDS は、RDS for SQL Server が利用可能なすべての AWS リージョンで、次の SQL Server バージョンとエディションのリソースガバナーをサポートしています。
+ SQL Server 2022: Developer および Enterprise Edition
+ SQL Server 2019 Enterprise Edition
+ SQL Server 2017 Enterprise Edition
+ SQL Server 2016 Enterprise Edition
## 制限と推奨事項
リソースガバナーには、次の制限と推奨事項が適用されます。
+ エディションとサービスの制限:
+ SQL Server Enterprise Edition でのみ使用できます。
+ リソース管理は SQL Server データベースエンジンに限定されます。Analysis Services、Integration Services、Reporting Services のリソースガバナーはサポートされていません。
+ 設定の制限:
+ すべての設定で Amazon RDS ストアドプロシージャを使用する必要があります。
+ ネイティブ DDL ステートメントと SQL Server Management Studio GUI 設定はサポートされていません。
+ リソースプールパラメータ
+ `rds_` で始まるプール名はサポートされていません。
+ 内部リソースプールとデフォルトリソースプールの変更は許可されません。
+ ユーザー定義のリソースプールでは、次のリソースプールパラメータはサポートされていません。
+ `MIN_MEMORY_PERCENT`
+ `MIN_CPU_PERCENT`
+ `MIN_IOPS_PER_VOLUME`
+ `AFFINITY`
+ ワークロードグループのパラメータ:
+ `rds_` で始まるワークロードグループ名はサポートされていません。
+ 内部ワークロードグループの変更は許可されません。
+ デフォルトのワークロードグループの場合:
+ `REQUEST_MAX_MEMORY_GRANT_PERCENT` パラメータは変更できません。
+ デフォルトのワークロードグループの場合、`REQUEST_MAX_MEMORY_GRANT_PERCENT` は 1～70 である必要があります。
+ 他のすべてのパラメータはロックされており、変更できません。
+ ユーザー定義のワークロードグループでは、すべてのパラメータを変更できます。
+ 分類子関数の制限:
+ 分類子関数は、指定された条件 (ユーザー名、データベース、ホスト、またはアプリケーション名) に基づいて接続をカスタムワークロードグループにルーティングします。
+ それぞれのルーティング条件を持つユーザー定義のワークロードグループを最大 2 つサポートします。
+ 各グループ内で基準を `AND` 条件と組み合わせます。
+ ワークロードグループごとに少なくとも 1 つのルーティング基準が必要です。
+ 上記の分類方法のみがサポートされています。
+ 関数名の先頭には、`rg_classifier_` を付ける必要があります。
+ 条件が一致しない場合のデフォルトのグループ割り当て。
# RDS for SQL Server インスタンスの Microsoft SQL Server リソースガバナーを有効にする
RDS for SQL Server DB インスタンスに `RESOURCE_GOVERNOR` オプションを追加して、リソースガバナーを有効にします。以下のプロセスを使用します。
1. 新しいオプショングループを作成するか、既存のオプショングループを選択します。
1. オプショングループに [`RESOURCE_GOVERNOR`] オプションを追加します。
1. オプショングループを DB インスタンスに関連付けます。
**注記**
オプショングループを使用してリソースガバナーを有効にする場合、再起動は必要ありません。
## `RESOURCE_GOVERNOR` のオプショングループの作成
リソースガバナーを有効にするには、使用する DB インスタンスの SQL Server のエディションとバージョンに対応するオプショングループを作成または変更します。この手順を完了するには、AWS マネジメントコンソール または AWS CLI を使用してください。
### コンソール
次の手順を使用して、SQL Server Enterprise Edition 2022 のオプショングループを作成します。
**オプショングループを作成するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. **[Create group]** (グループの作成) を選択します。
1. [**Create subnet group**(オプショングループの作成)] ウィンドウで以下を行います。
1. [**名前**] に、AWS アカウント内で一意のオプショングループ名 (**resource-governor-ee-2022** など) を入力します。名前には、英字、数字、ハイフンのみを使用できます。
1. [**説明**] に、オプショングループの簡単な説明 (**RESOURCE\$1GOVERNOR option group for SQL Server EE 2022** など) を入力します。この説明は表示用に使用されます。
1. **[エンジン]** で **[sqlserver-ee]** を選択します。
1. [**メジャーエンジンのバージョン**] で、[**16.00**] を選択します。
1. **[作成]** を選択します。
### CLI
次の手順では、SQL Server Enterprise Edition 2022 のオプショングループを作成します。
**オプショングループを作成するには**
+ 以下のいずれかのコマンドを実行します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds create-option-group \
--option-group-name resource-governor-ee-2022 \
--engine-name sqlserver-ee \
--major-engine-version 16.00 \
--option-group-description "RESOURCE_GOVERNOR option group for SQL Server EE 2022"
```
Windows の場合:
```
aws rds create-option-group ^
--option-group-name resource-governor-ee-2022 ^
--engine-name sqlserver-ee ^
--major-engine-version 16.00 ^
--option-group-description "RESOURCE_GOVERNOR option group for SQL Server EE 2022"
```
## `RESOURCE_GOVERNOR` オプションのオプショングループへの追加
次に、AWS マネジメントコンソール または AWS CLI を使用して `RESOURCE_GOVERNOR` オプションをオプショングループに追加します。
### コンソール
**RESOURCE\$1GOVERNOR オプションを追加するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. 作成したオプショングループ (この例では **resource-governor-ee-2022**) を選択します。
1. **[オプションを追加]** を選択します。
1. **[オプションの詳細]** で、**[オプション名]** として **[RESOURCE\$1GOVERNOR]** を選択します。
1. **[スケジュール]** で、オプションをすぐに追加するか、次のメンテナンスウィンドウで追加するかを選択します。
1. **[オプションを追加]** を選択します。
### CLI
**`RESOURCE_GOVERNOR` オプションを追加するには**
+ オプショングループに [`RESOURCE_GOVERNOR`] オプションを追加します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds add-option-to-option-group \
--option-group-name resource-governor-ee-2022 \
--options "OptionName=RESOURCE_GOVERNOR" \
--apply-immediately
```
Windows の場合:
```
aws rds add-option-to-option-group ^
--option-group-name resource-governor-ee-2022 ^
--options "OptionName=RESOURCE_GOVERNOR" ^
--apply-immediately
```
## オプショングループを DB インスタンスに関連付ける
`RESOURCE_GOVERNOR` オプショングループを DB インスタンスに関連付けるには、AWS マネジメントコンソール または AWS CLI を使用します。
### コンソール
リソースガバナーの有効化を完了するには、`RESOURCE_GOVERNOR` オプショングループを新規または既存の DB インスタンスに関連付けます。
+ 新しい DB インスタンスの場合は、インスタンスを起動するときにそれらを関連付けます。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の DB インスタンスの場合は、インスタンスを変更することでそれらを関連付けます。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
### CLI
`RESOURCE_GOVERNOR` オプショングループを新規または既存の DB インスタンスに関連付けることができます。
**`RESOURCE_GOVERNOR` オプショングループを使用してインスタンスを作成するには**
+ オプショングループの作成時に使用したのと同じ DB エンジンのタイプとメジャーバージョンを指定します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds create-db-instance \
--db-instance-identifier mytestsqlserverresourcegovernorinstance \
--db-instance-class db.m5.2xlarge \
--engine sqlserver-ee \
--engine-version 16.00 \
--license-model license-included \
--allocated-storage 100 \
--master-username admin \
--master-user-password password \
--storage-type gp2 \
--option-group-name resource-governor-ee-2022
```
Windows の場合:
```
aws rds create-db-instance ^
--db-instance-identifier mytestsqlserverresourcegovernorinstance ^
--db-instance-class db.m5.2xlarge ^
--engine sqlserver-ee ^
--engine-version 16.00 ^
--license-model license-included ^
--allocated-storage 100 ^
--master-username admin ^
--master-user-password password ^
--storage-type gp2 ^
--option-group-name resource-governor-ee-2022
```
**インスタンスを変更して `RESOURCE_GOVERNOR` オプショングループを関連付けるには**
+ 以下のいずれかのコマンドを実行します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance \
--db-instance-identifier mytestinstance \
--option-group-name resource-governor-ee-2022 \
--apply-immediately
```
Windows の場合:
```
aws rds modify-db-instance ^
--db-instance-identifier mytestinstance ^
--option-group-name resource-governor-ee-2022 ^
--apply-immediately
```
# RDS for SQL Server インスタンスでの Microsoft SQL Server リソースガバナーの使用
リソースガバナーオプションをオプショングループに追加した後も、リソースガバナーはデータベースエンジンレベルでまだアクティブではありません。リソースガバナーを完全に有効にするには、RDS for SQL Server ストアドプロシージャを使用してリソースガバナーオブジェクトを有効にし、必要なリソースガバナーオブジェクトを作成する必要があります。詳細については、「[SQL Server DB インスタンスへの接続](USER_ConnectToMicrosoftSQLServerInstance.md)」を参照してください。
まず、SQL Server データベースに接続し、適切な RDS for SQL Server ストアドプロシージャを呼び出して設定を完了します。データベースに接続する手順については、「[SQL Server DB インスタンスへの接続](USER_ConnectToMicrosoftSQLServerInstance.md)」を参照してください。
各ストアドプロシージャを呼び出す方法については、以下のトピックを参照してください。
**Topics**
+ [リソースプールの管理](#ResourceGovernor.ManageResourcePool)
+ [ワークロードグループの管理](#ResourceGovernor.ManageWorkloadGroups)
+ [分類子関数を作成して登録する](#ResourceGovernor.ClassifierFunction)
+ [分類子関数の削除](#ResourceGovernor.DropClassifier)
+ [分類子関数の登録解除](#ResourceGovernor.DeregisterClassifier)
+ [統計をリセットする](#ResourceGovernor.ResetStats)
+ [リソースガバナーの設定変更](#ResourceGovernor.ConfigChanges)
+ [TempDB をリソースプールにバインドする](#ResourceGovernor.BindTempDB)
+ [リソースプールから TempDB をバインド解除する](#ResourceGovernor.UnbindTempDB)
+ [リソースガバナーのクリーンアップ](#ResourceGovernor.Cleanup)
## リソースプールの管理
### リソースプールの作成
オプショングループでリソースガバナーを有効にすると、`rds_create_resource_pool` を使用してカスタムリソースプールを作成できます。これらのプールを使用すると、CPU、メモリ、IOPS の特定の割合をさまざまなワークロードに割り当てることができます。
**Usage**
```
USE [msdb]
EXEC dbo.rds_create_resource_pool
@pool_name=value,
@MAX_CPU_PERCENT=value,
@CAP_CPU_PERCENT=value,
@MAX_MEMORY_PERCENT=value,
@MAX_IOPS_PER_VOLUME=value
```
以下のパラメータは必須です。
+ `@group_name` - 既存のユーザー定義のワークロードグループの名前です。
+ `@pool_name` - リソースプールのユーザー定義の名前です。*pool\$1name* は英数字で、最大 128 文字で、データベースエンジンインスタンス内で一意である必要があり、データベース識別子のルールに準拠する必要があります。
以下のパラメータはオプションです。
+ `@MAX_CPU_PERCENT` - CPU 競合がある場合にリソースプール内のすべてのリクエストが受け取る最大平均 CPU 帯域幅を指定します。*値*は、デフォルト設定の 100 の整数です。*値*の許容範囲は 1～100 です。
+ `@CAP_CPU_PERCENT` - リソースプール内のすべてのリクエストが受信する CPU 帯域幅のハードキャップを指定します。最大 CPU 帯域幅レベルを指定された値と同じに制限します。*値*は、デフォルト設定の 100 の整数です。*値*の許容範囲は 1～100 です。
+ `@MAX_MEMORY_PERCENT` - このリソースプールのリクエストで使用できるクエリワークスペースメモリの最大量を指定します。*値*は、デフォルト設定の 100 の整数です。*値*の許容範囲は 1～100 です。
+ `@MAX_IOPS_PER_VOLUME` - リソースプールを許可するディスクボリュームあたりの 1 秒あたりの最大 I/O オペレーション (IOPS) を指定します。*値*の許容範囲は 0～2^31-1 (2,147,483,647) です。プールの IOPS 制限を削除するには、0 を指定します。デフォルトは 0 です。
**例**
すべてのデフォルト値を使用してリソースプールを作成する例:
```
--This creates resource pool 'SalesPool' with all default values
USE [msdb]
EXEC rds_create_resource_pool @pool_name = 'SalesPool';
--Apply changes
USE [msdb]
EXEC msdb.dbo.rds_alter_resource_governor_configuration;
--Validate configuration
select * from sys.resource_governor_resource_pools
```
異なるパラメータを指定してリソースプールを作成する例:
```
--creates resource pool
USE [msdb]
EXEC dbo.rds_create_resource_pool
@pool_name='analytics',
@MAX_CPU_PERCENT = 30,
@CAP_CPU_PERCENT = 40,
@MAX_MEMORY_PERCENT = 20;
--Apply changes
EXEC msdb.dbo.rds_alter_resource_governor_configuration;
--Validate configuration
select * from sys.resource_governor_resource_pools
```
### リソースプールの変更
**Usage**
```
USE [msdb]
EXEC dbo.rds_alter_resource_pool
@pool_name=value,
@MAX_CPU_PERCENT=value,
@CAP_CPU_PERCENT=value,
@MAX_MEMORY_PERCENT=value,
@MAX_IOPS_PER_VOLUME=value;
```
以下のパラメータは必須です。
+ `@pool_name` - 既存のユーザー定義リソースプールの名前です。Amazon RDS SQL Server では、デフォルトのリソースプールの変更は許可されていません。
オプションのパラメータを少なくとも 1 つ指定する必要があります。
+ `@MAX_CPU_PERCENT` - CPU 競合がある場合にリソースプール内のすべてのリクエストが受け取る最大平均 CPU 帯域幅を指定します。*値*は、デフォルト設定の 100 の整数です。*値*の許容範囲は 1～100 です。
+ `@CAP_CPU_PERCENT` - リソースプール内のすべてのリクエストが受信する CPU 帯域幅のハードキャップを指定します。最大 CPU 帯域幅レベルを指定された値と同じに制限します。*値*は、デフォルト設定の 100 の整数です。*値*の許容範囲は 1～100 です。
+ `@MAX_MEMORY_PERCENT` - このリソースプールのリクエストで使用できるクエリワークスペースメモリの最大量を指定します。*値*は、デフォルト設定の 100 の整数です。*値*の許容範囲は 1～100 です。
+ `@MAX_IOPS_PER_VOLUME` - リソースプールを許可するディスクボリュームあたりの 1 秒あたりの最大 I/O オペレーション (IOPS) を指定します。*値*の許容範囲は 0～2^31-1 (2,147,483,647) です。プールの IOPS 制限を削除するには、0 を指定します。デフォルトは 0 です。
**例**
```
--This alters resource pool
USE [msdb]
EXEC dbo.rds_alter_resource_pool
@pool_name='analytics',
@MAX_CPU_PERCENT = 10,
@CAP_CPU_PERCENT = 20,
@MAX_MEMORY_PERCENT = 50;
--Apply changes
EXEC msdb.dbo.rds_alter_resource_governor_configuration;
--Validate configuration.
select * from sys.resource_governor_resource_pools
```
### リソースプールの削除
**Usage**
```
USE [msdb]
EXEC dbo.rds_drop_resource_pool
@pool_name=value;
```
以下のパラメータは必須です。
+ `@pool_name` - 既存のユーザー定義リソースプールの名前です。
**注記**
SQL Server では、内部リソースプールまたはデフォルトリソースプールの削除は許可されていません。
**例**
```
--This drops resource pool
USE [msdb]
EXEC dbo.rds_drop_resource_pool
@pool_name='analytics'
--Apply changes
EXEC msdb.dbo.rds_alter_resource_governor_configuration;
--Validate configuration
select * from sys.resource_governor_resource_pools
```
## ワークロードグループの管理
`rds_create_workload_group` および `rds_alter_workload_group` で作成および管理されるワークロードグループを使用すると、クエリグループの重要度レベル、メモリ許可、およびその他のパラメータを設定できます。
### ワークロードグループを作成する
**Usage**
```
USE [msdb]
EXEC dbo.rds_create_workload_group
@group_name = value,
@IMPORTANCE ={ LOW | MEDIUM | HIGH },
@REQUEST_MAX_MEMORY_GRANT_PERCENT =value,
@REQUEST_MAX_CPU_TIME_SEC = value ,
@REQUEST_MEMORY_GRANT_TIMEOUT_SEC = value,
@MAX_DOP = value,
@GROUP_MAX_REQUESTS = value,
@pool_name = value
```
以下のパラメータは必須です。
+ `@pool_name` - 既存のユーザー定義リソースプールの名前です。
+ `@group_name` - 既存のユーザー定義のワークロードグループの名前です。
以下のパラメータはオプションです。
+ `@IMPORTANCE` - ワークロードグループ内のリクエストの相対的な重要度を指定します。デフォルト値は `MEDIUM` です。
+ `@REQUEST_MAX_MEMORY_GRANT_PERCENT` - 1 つのリクエストがプールから取得できるクエリワークスペースメモリの最大量を指定します。*値*は、`MAX_MEMORY_PERCENT` で定義されたリソースプールサイズのパーセンテージです。デフォルト値は 25 です。
+ `@REQUEST_MAX_CPU_TIME_SEC` - バッチリクエストで使用できる CPU の最大時間を秒単位で指定します。*値*は 0 または正の整数である必要があります。*値*のデフォルト設定は 0 です。つまり、無制限です。
+ `@REQUEST_MEMORY_GRANT_TIMEOUT_SEC` - クエリがクエリワークスペースメモリからのメモリ許可が利用可能になるまで待機できる最大時間を秒単位で指定します。*値*は 0 または正の整数である必要があります。*値*のデフォルト設定である 0 では、クエリコストに基づく内部計算を使用して最大時間を決定します。
+ `@MAX_DOP` - 並列クエリ実行の最大並列度 (`MAXDOP`) を指定します。*値*の許容範囲は 0～64 です。*値*のデフォルト設定である 0 では、グローバル設定が使用されます。
+ `@GROUP_MAX_REQUESTS` = ワークロードグループで実行できる同時リクエストの最大数を指定します。*値*は 0 または正の整数である必要があります。*値*のデフォルト設定は 0 で、無制限のリクエストを許可します。
+ `@pool_name` = ワークロードグループを *pool\$1name* で識別されるユーザー定義のリソースプール、または `default` リソースプールに関連付けます。*pool\$1name* が指定されていない場合、ワークロードグループは組み込み `default` プールに関連付けられます。
**例**
```
--This creates workload group named 'analytics'
USE msdb;
EXEC dbo.rds_create_workload_group
@group_name = 'analytics',
@IMPORTANCE = 'HIGH',
@REQUEST_MAX_MEMORY_GRANT_PERCENT = 25,
@REQUEST_MAX_CPU_TIME_SEC = 0,
@REQUEST_MEMORY_GRANT_TIMEOUT_SEC = 0,
@MAX_DOP = 0,
@GROUP_MAX_REQUESTS = 0,
@pool_name = 'analytics';
--Apply changes
EXEC msdb.dbo.rds_alter_resource_governor_configuration;
--Validate configuration
select * from sys.resource_governor_workload_groups
```
### ワークロードグループの変更
**Usage**
```
EXEC msdb.dbo.rds_alter_workload_group
@group_name = value,
@IMPORTANCE = 'LOW|MEDIUM|HIGH',
@REQUEST_MAX_MEMORY_GRANT_PERCENT = value,
@REQUEST_MAX_CPU_TIME_SEC = value,
@REQUEST_MEMORY_GRANT_TIMEOUT_SEC = value,
@MAX_DOP = value,
@GROUP_MAX_REQUESTS = value,
@pool_name = value
```
以下のパラメータは必須です。
+ `@group_name` - デフォルトまたは既存のユーザー定義のワークロードグループの名前です。
**注記**
デフォルトのワークロードグループの `REQUEST_MAX_MEMORY_GRANT_PERCENT` パラメータのみの変更がサポートされています。デフォルトのワークロードグループの場合、`REQUEST_MAX_MEMORY_GRANT_PERCENT` は 1～70 である必要があります。デフォルトのワークロードグループでは、他のパラメータを変更することはできません。すべてのパラメータは、ユーザー定義のワークロードグループで変更できます。
以下のパラメータはオプションです。
+ `@IMPORTANCE` - ワークロードグループ内のリクエストの相対的な重要度を指定します。デフォルト値は MEDIUM です。
+ `@REQUEST_MAX_MEMORY_GRANT_PERCENT` - 1 つのリクエストがプールから取得できるクエリワークスペースメモリの最大量を指定します。*値*は、`MAX_MEMORY_PERCENT` で定義されたリソースプールサイズのパーセンテージです。デフォルト値は 25 です。Amazon RDS では、`REQUEST_MAX_MEMORY_GRANT_PERCENT` は 1～70 である必要があります。
+ `@REQUEST_MAX_CPU_TIME_SEC` - バッチリクエストで使用できる CPU の最大時間を秒単位で指定します。*値*は 0 または正の整数である必要があります。*値*のデフォルト設定は 0 です。つまり、無制限です。
+ `@REQUEST_MEMORY_GRANT_TIMEOUT_SEC` - クエリがクエリワークスペースメモリからのメモリ許可が利用可能になるまで待機できる最大時間を秒単位で指定します。*値*は 0 または正の整数である必要があります。*値*のデフォルト設定である 0 では、クエリコストに基づく内部計算を使用して最大時間を決定します。
+ `@MAX_DOP` - 並列クエリ実行の最大並列度 (MAXDOP) を指定します。*値*の許容範囲は 0～64 です。*値*のデフォルト設定である 0 では、グローバル設定が使用されます。
+ `@GROUP_MAX_REQUESTS` - ワークロードグループで実行できる同時リクエストの最大数を指定します。*値*は 0 または正の整数である必要があります。*値*のデフォルト設定は 0 で、無制限のリクエストを許可します。
+ `@pool_name` - ワークロードグループを *pool\$1name* で識別されるユーザー定義のリソースプールに関連付けます。
**例**
デフォルトのワークロードグループ変更 REQUEST\$1MAX\$1MEMORY\$1GRANT\$1PERCENT を変更する例:
```
--Modify default workload group (set memory grant cap to 10%)
USE msdb
EXEC dbo.rds_alter_workload_group
@group_name = 'default',
@REQUEST_MAX_MEMORY_GRANT_PERCENT=10;
--Apply changes
EXEC msdb.dbo.rds_alter_resource_governor_configuration;
--Validate configuration
SELECT * FROM sys.resource_governor_workload_groups WHERE name='default';
```
デフォルト以外のワークロードグループを変更する例:
```
EXEC msdb.dbo.rds_alter_workload_group
@group_name = 'analytics',
@IMPORTANCE = 'HIGH',
@REQUEST_MAX_MEMORY_GRANT_PERCENT = 30,
@REQUEST_MAX_CPU_TIME_SEC = 3600,
@REQUEST_MEMORY_GRANT_TIMEOUT_SEC = 60,
@MAX_DOP = 4,
@GROUP_MAX_REQUESTS = 100;
--Apply changes
EXEC msdb.dbo.rds_alter_resource_governor_configuration;
```
デフォルト以外のワークロードグループを別のリソースプールに移動する例:
```
EXEC msdb.dbo.rds_alter_workload_group
@group_name = 'analytics',
@pool_name='abc'
--Apply changes
EXEC msdb.dbo.rds_alter_resource_governor_configuration;
--Validate configuration
select * from sys.resource_governor_workload_groups
```
### ワークロードグループの削除
**Usage**
```
EXEC msdb.dbo.rds_drop_workload_group
@group_name = value
```
以下のパラメータは必須です。
+ `@group_name` - 既存のユーザー定義のワークロードグループの名前です。
**例**
```
--Drops a Workload Group:
EXEC msdb.dbo.rds_drop_workload_group
@group_name = 'analytics';
--Apply changes
EXEC msdb.dbo.rds_alter_resource_governor_configuration;
--Validate configuration
select * from sys.resource_governor_workload_groups
```
## 分類子関数を作成して登録する
この手順では、指定された条件 (ユーザー名、データベース、ホスト、またはアプリケーション名) に基づいてカスタムワークロードグループへの接続をルーティングするリソースガバナーの分類子関数をマスターデータベースに作成します。リソースガバナーが有効で、分類子関数がリソースガバナー設定で指定されている場合、関数の出力によって新しいセッションに使用されるワークロードグループが決まります。分類子関数がない場合、すべてのセッションが `default` グループに分類されます。
**の機能**
+ それぞれのルーティング条件で最大 2 つのワークロードグループをサポートします。
+ 各グループ内で基準を `AND` 条件と組み合わせます。
+ ワークロードグループごとに少なくとも 1 つのルーティング基準が必要です。
+ 関数名の先頭には、`rg_classifier_` を付ける必要があります。
+ 条件が一致しない場合のデフォルトのグループ割り当て。
分類子関数には、次の特性と動作があります。
+ 関数はサーバースコープ (マスターデータベース) で定義されます。
+ 関数はスキーマバインディングを使用して定義されます。
+ この関数は、接続プーリングが有効になっている場合でも、新しいセッションごとに評価されます。
+ 関数は、セッションのワークロードグループコンテキストを返します。セッションは、セッションの存続期間中、分類子によって返されるワークロードグループに割り当てられます。
+ 関数が NULL、デフォルト、または存在しないワークロードグループの名前を返す場合、セッションにはデフォルトのワークロードグループコンテキストが与えられます。何らかの理由で関数が失敗した場合も、セッションにはデフォルトのコンテキストが与えられます。
+ 複数の分類子関数を作成できます。ただし、SQL Server では、一度に登録できる分類子関数は 1 つだけです。
+ 分類子名を NULL に設定する登録解除手順 (`EXEC dbo.msdb.rds_alter_resource_governor_configuration @deregister_function = 1;`) を使用して分類子ステータスが削除されるか、(`EXEC dbo.msdb.rds_alter_resource_governor_configuration @classifier_function = ;`) を使用して別の分類子関数が登録されない限り、分類子関数を削除することはできません。
+ 分類子関数がない場合、すべてのセッションがデフォルトグループに分類されます。
+ 分類子関数は、リソースガバナー設定で参照されている間は変更できません。ただし、別の分類子関数を使用するように設定を変更することはできます。分類子を変更する場合は、分類子関数のペアの作成を検討してください。例えば、`rg_classifier_a` と `rg_classifier_b` を作成できます。
**Usage**
```
EXEC msdb.dbo.rds_create_classifier_function
@function_name = value,
@workload_group1 = value,
@user_name1 = value,
@db_name1 = value,
@host_name1 = value,
@app_name1 = value,
@workload_group2 = value,
@user_name2 = value,
@db_name2 = value,
@host_name2 = value,
@app_name2 = value
```
以下のパラメータは必須です。
+ `@function_name` - 分類子関数の名前。`rg_classifier_` で始まる必要があります
+ `@workload_group1` - 最初のワークロードグループの名前
以下のパラメータはオプションです。
(グループ 1 には、これらの基準の少なくとも 1 つを指定する必要があります)
+ `@user_name1` - グループ 1 のログイン名
+ `@db_name1` - グループ 1 のデータベース名
+ `@host_name1` - グループ 1 のホスト名
+ `@app_name1` - グループ 1 のアプリケーション名
(グループ 2 が指定されている場合、少なくとも 1 つの条件を指定する必要があります)
+ `@workload_group2` - 2 番目のワークロードグループの名前
+ `@user_name2` - グループ 2 のログイン名
+ `@db_name2` - グループ 2 のデータベース名
+ `@host_name2` - グループ 2 のホスト名
+ `@app_name2` - グループ 2 のアプリケーション名
**注記**
システムアカウント、データベース、アプリケーション、ホストは制限されています。
**例**
1 つのワークロードグループの基本的な例:
```
/*Create a classifier to route all requests from 'PowerBI' app to workload group
'reporting_group'*/
EXEC msdb.dbo.rds_create_classifier_function
@function_name = 'rg_classifier_a',
@workload_group1 = 'reporting_group',
@app_name1 = 'PowerBI';
--Register the classifier
EXEC msdb.dbo.rds_alter_resource_governor_configuration
@classifier_function = 'rg_classifier_a';
-- Apply changes
EXEC msdb.dbo.rds_alter_resource_governor_configuration
/*Query sys.resource_governor_configuration to validate that resource governor is enabled and is using the classifier function we created and registered*/
use master
go
SELECT OBJECT_SCHEMA_NAME(classifier_function_id) AS classifier_schema_name,
OBJECT_NAME(classifier_function_id) AS classifier_object_name,
is_enabled
FROM sys.resource_governor_configuration;
```
## 分類子関数の削除
**Usage**
```
USE [msdb]
EXEC dbo.rds_drop_classifier_function
@function_name = value;
```
以下のパラメータは必須です。
+ `@function_name` - 既存のユーザー定義分類子関数の名前です。
**例**
```
EXEC msdb.dbo.rds_drop_classifier_function
@function_name = 'rg_classifier_b';
```
## 分類子関数の登録解除
分類子関数の登録を解除するには、この手順を使用します。関数の登録が解除されると、新しいセッションは自動的にデフォルトのワークロードグループに割り当てられます。
**Usage**
```
USE [msdb]
EXEC dbo.rds_alter_resource_governor_configuration
@deregister_function = 1;
```
登録解除には、次のパラメータが必要です。
+ `@deregister_function` は 1 でなければなりません。
**例**
```
EXEC msdb.dbo.rds_alter_resource_governor_configuration
@deregister_function = 1;
GO
-- Apply changes
EXEC msdb.dbo.rds_alter_resource_governor_configuration;
```
## 統計をリセットする
リソースガバナー統計は、前回のサーバー再起動以降に累積されます。特定の時間から統計を収集する必要がある場合は、次の Amazon RDS ストアドプロシージャを使用して統計をリセットできます。
**Usage**
```
USE [msdb]
EXEC dbo.rds_alter_resource_governor_configuration
@reset_statistics = 1;
```
統計をリセットするには、次のパラメータが必要です。
+ `@reset_statistics` は 1 でなければなりません。
## リソースガバナーの設定変更
リソースガバナーが有効になっていない場合、`rds_alter_resource_governor_configuration` はリソースガバナーを有効にします。リソースガバナーを有効にすると、次の結果が得られます。
+ 分類子関数がある場合は、新しいセッションに対して実行され、ワークロードグループに割り当てられます。
+ リソースガバナー設定で指定されたリソース制限が優先され、適用されます。
+ リソースガバナー設定で指定されたリソース制限が優先され、適用されます。
+ リソースガバナーを有効にする前に存在していたリクエストは、リソースガバナーが有効になっているときに行われた設定変更の影響を受ける可能性があります。
+ リソースガバナーを有効にする前からの既存のリクエストは、リソースガバナーが有効になっているときに行われた設定変更の影響を受ける可能性があります。
+ RDS for SQL Server で、リソースガバナー設定の変更を有効にするには、`EXEC msdb.dbo.rds_alter_resource_governor_configuration` を実行する必要があります。
**Usage**
```
USE [msdb]
EXEC dbo.rds_alter_resource_governor_configuration
```
## TempDB をリソースプールにバインドする
Amazon RDS SQL Server バージョン 2019 以降では、`rds_bind_tempdb_metadata_to_resource_pool` を使用して、tempdb メモリ最適化メタデータを特定のリソースプールにバインドできます。
**注記**
tempdb メタデータをリソースプールにバインドする前に、メモリ最適化 tempdb メタデータ機能を有効にする必要があります。Amazon RDS でこの機能を有効にするには、静的パラメータ `tempdb metadata memory-optimized` を使用します。
Amazon RDS で静的パラメータを有効にし、パラメータを有効にするためにフェイルオーバーなしで再起動を実行します。
```
aws rds modify-db-parameter-group \
--db-parameter-group-name test-sqlserver-ee-2022 \
--parameters "ParameterName='tempdb metadata memory-optimized',ParameterValue=True,ApplyMethod=pending-reboot"
```
**Usage**
```
USE [msdb]
EXEC dbo.rds_bind_tempdb_metadata_to_resource_pool
@pool_name=value;
```
以下のパラメータは必須です。
+ `@pool_name` - 既存のユーザー定義リソースプールの名前です。
**注記**
この変更では、メモリ最適化 TempDB メタデータ機能が既に有効になっている場合でも、フェイルオーバーなしで SQL サービスを再起動する必要があります。
## リソースプールから TempDB をバインド解除する
tempdb メモリ最適化メタデータをリソースプールからバインド解除します。
**注記**
この変更を有効にするには、フェイルオーバーなしで SQL サービスを再起動する必要もあります
**Usage**
```
USE [msdb]
EXEC dbo.rds_unbind_tempdb_metadata_from_resource_pool
```
## リソースガバナーのクリーンアップ
この手順では、オプショングループからリソースガバナーオプションを削除した後、関連するすべてのオブジェクトをクリーンアップします。これにより、リソースガバナーを無効にし、デフォルトのワークロードグループをデフォルト設定に戻し、カスタムワークロードグループ、リソースプール、分類子関数を削除します。
**主な特徴**:
+ デフォルトのワークロードグループをデフォルト設定に戻す
+ リソースガバナーを無効にする
+ カスタムワークロードグループを削除する
+ カスタムリソースプールを削除する
+ 分類子関数を削除する
+ 有効になっている場合、tempdb リソースプールバインディングを削除する
**重要**
このクリーンアップは、ワークロードグループにアクティブなセッションがある場合にエラーになる可能性があります。ビジネス要件に従って、アクティブなセッションが終了するのを待つか、アクティブなセッションを終了します。これをメンテナンスウィンドウ中に実行することをお勧めします。
このクリーンアップは、リソースプールが tempdb にバインドされ、フェイルオーバーなしで再起動されていない場合にエラーが発生する可能性があります。リソースプールを tempdb にバインドするか、以前に tempdb からリソースプールをバインド解除した場合は、フェイルオーバーなしで再起動を実行して変更を有効にします。これをメンテナンスウィンドウ中に実行することをお勧めします。
**Usage**
```
USE [msdb]
EXEC dbo.rds_cleanup_resource_governor
```
## マルチ AZ 配置に関する考慮事項
RDS for SQL Server は、マルチ AZ 配置のセカンダリインスタンスにリソースガバナーをレプリケートします。変更された新しいリソースガバナーがセカンダリインスタンスと最後に同期された日時を確認できます。
次のクエリを使用して、レプリケーションの `last_sync_time` を確認します。
```
SELECT * from msdb.dbo.rds_fn_server_object_last_sync_time();
```
クエリ結果で、同期時刻がリソースガバナーの更新時刻または作成時刻を過ぎている場合、リソースガバナーはセカンダリと同期します。
リソースガバナーのレプリケーションを確認するために手動で DB フェイルオーバーを実行するには、まず `last_sync_time` が更新されるのを待ちます。次に、マルチ AZ フェイルオーバーに進みます。
## リードレプリカに関する考慮事項
+ ソース DB インスタンスと同じリージョンの SQL Server レプリカの場合、ソースと同じオプショングループを使用します。オプショングループへの変更は、メンテナンスウィンドウに関係なく、レプリカにすぐに伝達されます。
+ SQL Server クロスリージョンレプリカを作成する場合、RDS により、そのための専有オプショングループが作成されます。
+ SQL Server クロスリージョンレプリカを、その専有オプショングループから削除することはできません。他の DB インスタンスで、SQL Server クロスリージョンレプリカの専有オプショングループを使用することはできません。
+ リソースガバナーオプションはレプリケートされていないオプションです。専用オプショングループから、レプリケートされないオプションを追加または削除できます。
+ SQL Server クロスリージョンリードレプリカを昇格するとき、昇格されたレプリカは、オプションの管理を含め、その他の SQL Server DB インスタンスと同じように動作します。
**注記**
リードレプリカでリソースガバナーを使用する場合は、オプションがオプショングループに追加された後に、Amazon RDS ストアドプロシージャを使用して、リードレプリカでリソースガバナーが手動で設定されていることを確認する必要があります。リソースガバナーの設定は、リードレプリカに自動的にレプリケートされません。また、リードレプリカのワークロードは通常、プライマリインスタンスとは異なります。したがって、ワークロードとインスタンスタイプに基づいてリソース設定をレプリカに適用することをお勧めします。リードレプリカでこれらの Amazon RDS ストアドプロシージャを個別に実行して、リードレプリカでリソースガバナーを設定できます。
# RDS for SQL Server インスタンスのシステムビューを使用して Microsoft SQL Server リソースガバナーをモニタリングする
リソースガバナー統計は、前回のサーバー再起動以降に累積されます。特定の時間から統計を収集する必要がある場合は、次の Amazon RDS ストアドプロシージャを使用して統計をリセットできます。
```
EXEC msdb.dbo.rds_alter_resource_governor_configuration
@reset_statistics = 1;
```
## リソースプールランタイム統計
リソースプールごとに、リソースガバナーは CPU とメモリの使用率、メモリ不足イベント、メモリ許可、I/O、その他の統計情報を追跡します。詳細については、「[sys.dm\$1resource\$1governor\$1resource\$1pools](https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-resource-governor-resource-pools-transact-sql?view=sql-server-ver17)」を参照してください。
次のクエリは、すべてのリソースプールで使用可能な統計のサブセットを返します。
```
SELECT rp.pool_id,
rp.name AS resource_pool_name,
wg.workload_group_count,
rp.statistics_start_time,
rp.total_cpu_usage_ms,
rp.target_memory_kb,
rp.used_memory_kb,
rp.out_of_memory_count,
rp.active_memgrant_count,
rp.total_memgrant_count,
rp.total_memgrant_timeout_count,
rp.read_io_completed_total,
rp.write_io_completed_total,
rp.read_bytes_total,
rp.write_bytes_total,
rp.read_io_stall_total_ms,
rp.write_io_stall_total_ms
FROM sys.dm_resource_governor_resource_pools AS rp
OUTER APPLY (
SELECT COUNT(1) AS workload_group_count
FROM sys.dm_resource_governor_workload_groups AS wg
WHERE wg.pool_id = rp.pool_id
) AS wg;
```
# RDS for SQL Server インスタンスの Microsoft SQL Server リソースガバナーを無効にする
RDS for SQL Server でリソースガバナーを無効にすると、サービスはワークロードリソースの管理を停止します。リソースガバナーを無効にする前に、これがデータベースの接続と設定にどのように影響するかを確認してください。
リソースガバナーを無効にすると、次の結果になります。
+ 新しい接続が開かれたときに、分類子関数は実行されません。
+ 新しい接続は自動的にデフォルトのワークロードグループに分類されます。
+ 既存のワークロードグループとリソースプールの設定はすべてデフォルト値にリセットされます。
+ 制限に達した場合、イベントは発生しません。
+ リソースガバナーの設定は変更できますが、リソースガバナーが有効になるまで変更は適用されません。
リソースガバナーを無効にするには、オプショングループから `RESOURCE_GOVERNOR` オプションを削除します。
## コンソール
以下の手順では、`RESOURCE_GOVERNOR` オプションを削除します。
**RESOURCE\$1GOVERNOR オプションをオプショングループから削除するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. `RESOURCE_GOVERNOR` オプションが含まれているオプショングループ (前の例では `resource-governor-ee-2022`) を選択します。
1. **[オプションを削除]** を選択します。
1. **[削除オプション]** で、**[削除するオプション]** として **[RESOURCE\$1GOVERNOR]** を選択します。
1. **[Apply immediately]** (すぐに適用) で、オプションをすぐに削除する場合は **[Yes]** (はい) を選択し、次のメンテナンスウィンドウで削除する場合は **[No]** (いいえ) を選択します。
1. **[削除]** を選択します。
## CLI
以下の手順では、`RESOURCE_GOVERNOR` オプションを削除します。
**RESOURCE\$1GOVERNOR オプションをオプショングループから削除するには**
+ 以下のいずれかのコマンドを実行します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds remove-option-from-option-group \
--option-group-name resource-governor-ee-2022 \
--options RESOURCE_GOVERNOR \
--apply-immediately
```
Windows の場合:
```
aws rds remove-option-from-option-group ^
--option-group-name resource-governor-ee-2022 ^
--options RESOURCE_GOVERNOR ^
--apply-immediately
```
# RDS for SQL Server でリソースガバナーを設定するためのベストプラクティス
リソースの消費を制御するために、RDS for SQL Server は Microsoft SQL Server のリソースガバナーをサポートしています。以下のベストプラクティスは、一般的な設定の問題を回避し、データベースのパフォーマンスを最適化するのに役立ちます。
1. リソースガバナーの設定は `master` データベースに保存されます。リソースガバナーの設定スクリプトのコピーは必ず個別に保存することをお勧めします。
1. 分類子関数はログイン処理時間を延長するため、分類子の複雑なロジックを避けることをお勧めします。関数が複雑すぎると、Amazon RDS オートメーションセッションなどのログイン遅延や接続タイムアウトが発生する可能性があります。これは、Amazon RDS オートメーションがインスタンスの状態をモニタリングする機能に影響を与える可能性があります。したがって、本番稼働前の環境で分類子関数をテストしてから、本番稼働環境に実装することをお勧めします。
1. ワークロードグループで `REQUEST_MAX_MEMORY_GRANT_PERCENT` に高い値 (70 以上) を設定しないでください。そうしないと、データベースインスタンスが他の同時クエリに十分なメモリを割り当てることができなくなり、メモリ付与タイムアウトエラー (エラー 8645) が発生する可能性があります。逆に、この値を低く (1 未満) 設定したり 0 に設定すると、メモリワークスペースを必要とするクエリ (ソートまたはハッシュオペレーションを含むクエリなど) がユーザー定義のワークロードグループで適切に実行できなくなる可能性があります。RDS は、デフォルトのワークロードグループの値を 1～70 に制限することで、これらの制限を適用します。
1. tempdb をリソースプールにバインドする場合、メモリ最適化 tempdb メタデータをプールにバインドした後、プールが最大設定に達し、`tempdb` を使用するクエリがメモリ不足エラーで失敗する可能性があります。特定の状況では、メモリ不足エラーが発生した場合に SQL Server が停止する可能性があります。これが発生する可能性を減らすには、メモリプールの `MAX_MEMORY_PERCENT` を高い値に設定します。
# 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 に設定します。