";
public static void main(String[] args) throws SQLException {
final Properties properties = new Properties();
final String connectionString = String.format(
"jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCPS)(HOST=%s)(PORT=%d))(CONNECT_DATA=(SID=%s)))",
DB_SERVER_NAME, SSL_PORT, DB_SID);
properties.put("user", DB_USER);
properties.put("password", DB_PASSWORD);
properties.put("oracle.jdbc.J2EE13Compliant", "true");
properties.put("javax.net.ssl.trustStore", KEY_STORE_FILE_PATH);
properties.put("javax.net.ssl.trustStoreType", "JKS");
properties.put("javax.net.ssl.trustStorePassword", KEY_STORE_PASS);
final Connection connection = DriverManager.getConnection(connectionString, properties);
// If no exception, that means handshake has passed, and an SSL connection can be opened
}
}
```
**重要**
データベース接続で SSL/TLS を使用することを決定し、アプリケーションの信頼ストアを更新したら、rds-ca-rsa2048-g1 証明書を使用するようにデータベースを更新できます。ステップについては、「[DB インスタンスまたはクラスターの変更による CA 証明書の更新](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-updating)」のステップ 3 を参照してください。
# RDS for Oracle DB インスタンスでネイティブネットワークの暗号化を使用する
Oracle Database には、ネットワークのデータを暗号化する方法として、ネイティブネットワーク暗号化 (NNE) と Transport Layer Security (TLS) の 2 つがあります。NNE は Oracle 独自のセキュリティ機能ですが、TLS は業界標準です。RDS for Oracle では、Oracle Database のすべてのエディションの NNE がサポートされています。
NNE には TLS と比較して次のような利点があります。
+ NNE オプションの設定を使用して、クライアントとサーバーの NNE を制御できます。
+ `SQLNET.ALLOW_WEAK_CRYPTO_CLIENTS` および `SQLNET.ALLOW_WEAK_CRYPTO`
+ `SQLNET.CRYPTO_CHECKSUM_CLIENT` および `SQLNET.CRYPTO_CHECKSUM_SERVER`
+ `SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT` および `SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER`
+ `SQLNET.ENCRYPTION_CLIENT` および `SQLNET.ENCRYPTION_SERVER`
+ `SQLNET.ENCRYPTION_TYPES_CLIENT` および `SQLNET.ENCRYPTION_TYPES_SERVER`
+ ほとんどの場合、クライアントやサーバーを設定する必要はありません。対照的に、TLS では、クライアントとサーバーの両方を設定する必要があります。
+ 証明書は必要ありません。TLS では、サーバーには証明書が必要です (最終的に期限切れになります)。クライアントには、サーバーの証明書を発行した認証局の信頼できるルート証明書が必要です。
Oracle DB インスタンスの NNE 暗号化を有効にするには、その DB インスタンスに関連付けられているオプショングループに、Oracle NNE オプションを追加します。詳細については、「[Oracle ネイティブネットワーク暗号化](Appendix.Oracle.Options.NetworkEncryption.md)」を参照してください。
**注記**
NNE と TLS の両方を同じ DB インスタンスで使用することはできません。
# Amazon RDS for Oracle の Kerberos 認証の設定
Kerberos 認証を使用して、ユーザーが Amazon RDS for Oracle DB インスタンスに接続する場合に、ユーザーを認証できます。この設定では、DB インスタンスは AWS Directory Service for Microsoft Active Directory と連携します (AWS Managed Microsoft AD とも言う)。ユーザーが、信頼性の高いドメインに接続された RDS for Oracle DB インスタンスを使用して認証を実行すると、Directory Service を使用して作成したディレクトリに認証リクエストが転送されます。
同じディレクトリにすべての認証情報を保持することで時間と労力を節約できます。複数のデータベースインスタンスの認証情報を保存し、管理する一元的な場所が用意されています。ディレクトリを使用することで、セキュリティプロファイル全体を向上することもできます。
# 利用可能なリージョンとバージョン
機能の可用性とサポートは、各データベースエンジンの特定のバージョン、および AWS リージョン によって異なります。Kerberos 認証を使用した RDS for Oracle のバージョンとリージョンの可用性の詳細については、「[Amazon RDS での Kerberos データベース認証でサポートされているリージョンと DB エンジン](Concepts.RDS_Fea_Regions_DB-eng.Feature.KerberosAuthentication.md)」を参照してください。
**注記**
Kerberos 認証は、RDS for Oracle DB インスタンスに廃止された DB インスタンスクラスにはサポートされていません。詳細については、「[RDS for Oracle DB インスタンスクラス](Oracle.Concepts.InstanceClasses.md)」を参照してください。
**Topics**
+ [利用可能なリージョンとバージョン](oracle-kerberos-setting-up.RegionVersionAvailability.md)
+ [Oracle DB インスタンス用に Kerberos を設定する](oracle-kerberos-setting-up.md)
+ [ドメインの DB インスタンスの管理](oracle-kerberos-managing.md)
+ [Oracle を Kerberos 認証に接続する](oracle-kerberos-connecting.md)
# Oracle DB インスタンス用に Kerberos を設定する
AWS Directory Service for Microsoft Active Directory とも呼ばれる AWS Managed Microsoft AD を使用し、Oracle DB インスタンスに Kerberos 認証をセットアップします。Kerberos 認証をセットアップするには、以下のステップを完了します。
+ [ステップ 1: AWS Managed Microsoft AD を使用してディレクトリを作成する](#oracle-kerberos.setting-up.create-directory)
+ [ステップ 2: 信頼関係を作成する](#oracle-kerberos.setting-up.create-forest-trust)
+ [ステップ 3: Amazon RDS の IAM のアクセス許可を設定する](#oracle-kerberos.setting-up.CreateIAMRole)
+ [ステップ 4: ユーザーを作成して設定する](#oracle-kerberos.setting-up.create-users)
+ [ステップ 5: ディレクトリと DB インスタンスの間のクロス VPC トラフィックを有効にする](#oracle-kerberos.setting-up.vpc-peering)
+ [ステップ 6: Oracle DB インスタンスを作成または変更する](#oracle-kerberos.setting-up.create-modify)
+ [ステップ 7: Kerberos 認証 Oracle ログインを作成する](#oracle-kerberos.setting-up.create-logins)
+ [ステップ 8: Oracle クライアントを設定する](#oracle-kerberos.setting-up.configure-oracle-client)
**注記**
セットアップ中、RDS は、*managed\$1service\$1user*@*example.com* という名前の Oracle データベースユーザーを作成し、`CREATE SESSION` 権限を付与します (*example.com* はドメイン名です)。このユーザーは、Directory Service が管理されたアクティブディレクトリ内に作成するユーザーに対応します。RDS は定期的に、Directory Service によって提供される認証情報を使用して Oracle データベースにログインします。その後、RDS はすぐにチケットキャッシュを破棄します。
## ステップ 1: AWS Managed Microsoft AD を使用してディレクトリを作成する
Directory Service はフルマネージド型の Active Directory を AWS クラウド内に作成します。AWS Managed Microsoft AD ディレクトリを作成すると、Directory Service がユーザーに代わって 2 つのドメインコントローラーと 2 つのドメインネームシステム (DNS) サーバーを作成します。ディレクトリサーバーは、VPC 内の異なるサブネットで作成されます。この冗長性によって、障害が発生してもディレクトリにアクセス可能な状態を維持できます。
AWS Managed Microsoft AD ディレクトリを作成すると、Directory Service がユーザーに代わって自動的に以下のタスクを実行します。
+ VPC 内に Active Directory を設定します。
+ 「Admin」のユーザー名と指定されたパスワードを使用して、ディレクトリ管理者アカウントを作成します。このアカウントを使用してディレクトリを管理します。
**注記**
このパスワードは必ず保存してください。Directory Service は保存しません。パスワードはリセットできますが、取得することはできません。
+ ディレクトリコントローラー用セキュリティグループを作成します。
AWS Managed Microsoft AD を起動すると、AWS は組織単位 (OU) を作成します。OU にはディレクトリのオブジェクトがすべて含まれています。この OU には、ディレクトリの作成時に入力した NetBIOS 名がドメインルートにあります。ドメインルートは AWS が所有し、管理します。
AWS Managed Microsoft AD ディレクトリに作成した管理者アカウントには、OU に関する以下の代表的な管理業務用のアクセス権限があります。
+ ユーザーを作成、更新、削除する
+ ファイルやプリントサーバーなどのドメインにリソースを追加して、追加したリソースへのアクセス許可を OU のユーザーとグループに割り当てる
+ 追加の OU やコンテナを作成する
+ 権限を委譲する
+ 削除されたオブジェクトを Active Directory のごみ箱から元に戻す
+ Active Directory Web Service で AD と DNS Windows PowerShell モジュールを実行する
管理者アカウントには、ドメイン全体に関する以下のアクティビティを実行する権限もあります。
+ DNS 設定 (レコード、ゾーン、フォワーダーの追加、削除、更新) を管理する
+ DNS イベントログを参照する
+ セキュリティイベントログを参照する
AWS マネジメントコンソール、AWS CLI、Directory Service API を使用して、ディレクトリを作成します。ディレクトリが Oracle DB インスタンスと通信できるように、ディレクトリセキュリティグループで関連するアウトバウンドポートを必ず開いてください。
**AWS Managed Microsoft AD でディレクトリを作成するには**
1. AWS マネジメントコンソール にサインインし、Directory Service コンソール ([https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/))を開きます。
1. ナビゲーションペインで、[**Directories**]、[**Set up Directory**] の順に選択します。
1. [**AWS Managed Microsoft AD**] を選択します。現状では、AWS Managed Microsoft AD が Amazon RDS で使用できる唯一のオプションです。
1. 次の情報を入力します。
**ディレクトリの DNS 名**
ディレクトリの完全修飾名 (例: **corp.example.com**)。
**ディレクトリの NetBIOS 名**
ディレクトリの短縮名 (例: **CORP**)。
**ディレクトリの説明**
(オプション) ディレクトリの説明。
**Admin パスワード**
ディレクトリ管理者のパスワードです。ディレクトリの作成プロセスでは、ユーザー名「Admin」とこのパスワードを使用して管理者アカウントが作成されます。
ディレクトリ管理者のパスワードに「admin」の単語を含めることはできません。パスワードは大文字と小文字を区別し、8-64 文字にします。また、以下の 4 つのカテゴリうち 3 つから少なくとも 1 文字を含める必要があります。
+ 小文字 (a～z)
+ 大文字 (A～Z)
+ 数字 (0～9)
+ アルファベット以外の文字 (\$1\$1@\$1\$1%^&\$1\$1-\$1=`\$1\$1()\$1\$1[]:;"'<>,.?/)
**パスワードを確認**
管理者のパスワードをもう一度入力します。
1. [**Next (次へ)**] を選択します。
1. [**Networking** ] セクションに次の情報を入力し、[**Next**] を選択します。
**VPC**
ディレクトリ用の VPC。この同じ VPC 内に Oracle DB インスタンスを作成します。
**Subnets**
ディレクトリサーバーのサブネット。2 つのサブネットは、異なるアベイラビリティーゾーンに存在している必要があります。
1. ディレクトリ情報を確認し、必要な変更を加えます。情報が正しい場合は、[**Create directory (ディレクトリの作成)**] を選択します。
![\[作成中のディレクトリ詳細ページ\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/WinAuth2.png)
ディレクトリが作成されるまで、数分かかります。正常に作成されると、[**Status**] 値が [**Active**] に変わります。
ディレクトリに関する情報を表示するには、ディレクトリの一覧で、ディレクトリ名を選択します。[**Directory ID**] の値を書き留めます。この値は、Oracle DB インスタンスを作成または変更するときに必要になります。
![\[ディレクトリの詳細ページ\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/WinAuth3.png)
## ステップ 2: 信頼関係を作成する
AWS Managed Microsoft AD のみを使用する予定の場合は、[ステップ 3: Amazon RDS の IAM のアクセス許可を設定する](#oracle-kerberos.setting-up.CreateIAMRole) に進みます。
セルフマネージド Active Directory を使用して Kerberos 認証を有効にするには、セルフマネージド Active Directory と前の手順で作成した AWS Managed Microsoft AD との間にフォレスト信頼関係を作成する必要があります。信頼は一方向で、AWS Managed Microsoft AD はセルフマネージド Active Directory を信頼します。信頼は、両方の Active Directory が相互に信頼する双方向にすることもできます。Directory Service を使用してフォレストの信頼関係を設定する方法の詳細については、*Directory Service 管理ガイド*の「[信頼関係を作成する場合](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_setup_trust.html)」を参照してください。
## ステップ 3: Amazon RDS の IAM のアクセス許可を設定する
Directory Service を呼び出すには、Amazon RDS にマネージド IAM ポリシー `AmazonRDSDirectoryServiceAccess` を使用する IAM ロールが必要です。このロールにより、Amazon RDS は Directory Service への呼び出しを行うことができます。
**注記**
ロールによるアクセスを許可するには、AWS Security Token Service (AWS STS) エンドポイントを AWS アカウント の AWS リージョン でアクティベートする必要があります。AWS STS エンドポイントはすべての AWS リージョン でデフォルトでアクティブになっているため、他のアクションを実行せずに、エンドポイントを使用することができます。詳細については、「*IAM ユーザーガイド*」の「[AWS リージョン での AWS STS のアクティブ化と非アクティブ化](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html#sts-regions-activate-deactivate)」を参照してください。
### IAM ロールの作成
AWS マネジメントコンソール を使用して DB インスタンスを作成し、コンソールユーザーが `iam:CreateRole` アクセス許可を持っている場合、コンソールは `rds-directoryservice-kerberos-access-role` を自動的に作成します。それ以外の場合は、IAM ロールを手動で作成する必要があります。IAM ロールを手動で作成する場合、[`Directory Service`] を選択し、それに AWS マネージドポリシー `AmazonRDSDirectoryServiceAccess` をアタッチします。
サービス用の IAM ロールを作成する方法の詳細については、*IAM ユーザーガイド*の「[AWS のサービスにアクセス許可を委任するロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)」を参照してください。
**注記**
RDS for Microsoft SQL Server の RDS 用の Windows 認証に使用される IAM ロールは、Oracle 用の RDS には使用できません。
### IAM 信頼ポリシーを手動で作成する
マネージド IAM ポリシー `AmazonRDSDirectoryServiceAccess` を使用する代わりに、必要なアクセス許可を使用してリソースポリシーを作成することもできます。プリンシパルとして `directoryservice.rds.amazonaws.com` と `rds.amazonaws.com` の両方を指定します。
特定のリソースへのアクセスについて、Amazon RDS が別のサービスに付与する許可を制限する場合は、リソースポリシー内で [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) のグローバル条件コンテキストキーを使用することをお勧めします。混乱した代理問題から保護するための最も効果的な方法は、Amazon RDS リソースの完全な ARN を指定しながら、`aws:SourceArn` グローバル条件コンテキストキーを使用することです。詳細については、「[サービス間での混乱した代理問題の防止](cross-service-confused-deputy-prevention.md)」を参照してください。
次の例では、Amazon RDS で `aws:SourceArn` および `aws:SourceAccount` グローバル条件コンテキストキーを使用して、「混乱した代理」問題を回避する方法を示します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": [
"directoryservice.rds.amazonaws.com",
"rds.amazonaws.com"
]
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:rds:us-east-1:123456789012:db:mydbinstance"
},
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
}
]
}
```
------
オプトインリージョンの場合は、リージョンのサービスプリンシパルを `directoryservice.rds.region_name.amazonaws.com` の形式で含める必要もあります。例えば、アフリカ (ケープタウン) リージョンの場合、次の信頼ポリシーを使用します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": [
"directoryservice.rds.amazonaws.com",
"directoryservice.rds.af-south-1.amazonaws.com",
"rds.amazonaws.com"
]
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:rds:af-south-1:123456789012:db:mydbinstance"
},
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
}
]
}
```
------
また、ロールには、以下の IAM ポリシーも必要です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ds:DescribeDirectories",
"ds:AuthorizeApplication",
"ds:UnauthorizeApplication",
"ds:GetAuthorizedApplicationDetails"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
## ステップ 4: ユーザーを作成して設定する
アクティブディレクトリドメインサービスおよびアクティブディレクトリライトウェイトディレクトリサービスのツールの一部である「アクティブディレクトリユーザーとコンピュータ」ツールを使用して、ユーザーを作成できます。この場合、*ユーザー*は、ディレクトリにアクセスできる個別の人またはエンティティを表します。
Directory Service ディレクトリにユーザーを作成するには、Directory Service ディレクトリのメンバーである Windows ベースの Amazon EC2 インスタンスに接続している必要があります。同時に、ユーザーを作成する権限を持つユーザーとしてログインしていなければなりません。Active Directory にユーザーを作成する方法の詳細については、 *AWS Managed Microsoft AD管理ガイド*の「[Directory Serviceでユーザーとグループを管理する](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups.html)」を参照してください。
## ステップ 5: ディレクトリと DB インスタンスの間のクロス VPC トラフィックを有効にする
同じ VPC 内にディレクトリおよび DB インスタンスを配置する場合は、このステップをスキップして [ステップ 6: Oracle DB インスタンスを作成または変更する](#oracle-kerberos.setting-up.create-modify) に進みます。
ディレクトリと DB インスタンスを別の AWS アカウントまたは VPC に配置する場合は、VPC ピア接続または [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) を使用してクロス VPC トラフィックを設定します。次の手順では、VPC ピア接続を使用して VPC 間のトラフィックを有効にします。*Amazon Virtual Private Cloud ピアリング接続ガイド*の「[VPC ピア機能とは](https://docs.aws.amazon.com/vpc/latest/peering/Welcome.html)」の手順に従います。
**VPC ピア接続を使用してクロス VPC トラフィックを有効にするには**
1. 適切な VPC ルーティングを設定し、ネットワークトラフィックが双方向にフローするようにします。
1. DB インスタンスのセキュリティグループが、ディレクトリのセキュリティグループからのインバウンドトラフィックを受信できることを確認します。詳細については、*AWS Managed Microsoft AD 管理ガイド*の「[Directory Service のベストプラクティス](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_best_practices.html)」を参照してください。
1. トラフィックをブロックするネットワークのアクセスコントロールリスト (ACL) ルールがないことを確認します。
別の AWS アカウントがディレクトリを所有している場合は、ディレクトリを共有する必要があります。
**AWS アカウント間でディレクトリを共有するには**
1. DB インスタンスを作成する AWS アカウントとの間でディレクトリの共有を開始するには、*AWS Managed Microsoft AD 管理ガイド*の「[チュートリアル: Directory Service ディレクトリを共有して、シームレスに EC2 ドメインを結合する](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_directory_sharing.html)」の手順を実行します。
1. DB インスタンスのアカウントを使用して、Directory Service コンソールにサインインし、続行する前にドメインが必ず `SHARED` ステータスであることを確認します。
1. DB インスタンスのアカウントを使用して Directory Service コンソールにサインインしている間に、[**ディレクトリ ID**] の値を書き留めておきます。このディレクトリ ID は、DB インスタンスをドメインに結合するために使用します。
## ステップ 6: Oracle DB インスタンスを作成または変更する
ディレクトリで使用する Oracle DB インスタンスを作成または変更します。コンソール、CLI、RDS API を使用して DB インスタンスとディレクトリを関連付けることができます。これには以下の 2 つの方法があります。
+ コンソール、[create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) CLI コマンド、[CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) RDS API オペレーションを使用して新しい Oracle DB インスタンスを作成します。
手順については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ コンソール、[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) CLI コマンド、[ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) RDS API オペレーションを使用して、既存の Oracle DB インスタンスを変更します。
手順については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
+ コンソール、[restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) CLI コマンド、[RestoreDBInstanceFromDBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html) RDS API オペレーションを使用して、DB スナップショットから Oracle DB インスタンスを復元します。
手順については、「[DB インスタンスへの復元](USER_RestoreFromSnapshot.md)」を参照してください。
+ コンソール、[restore-db-instance-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) CLI コマンド、[RestoreDBInstanceToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html) RDS API オペレーションを使用して、Oracle DB インスタンスをポイントインタイムに復元します。
手順については、「[Amazon RDS の DB インスタンスを特定の時点に復元する](USER_PIT.md)」を参照してください。
Kerberos 認証は、VPC 内の Oracle DB インスタンスにのみサポートされています。DB インスタンスは、ディレクトリと同じ VPC または異なる VPC 内にあります。DB インスタンスの作成または変更時に、次の手順を行います。
+ ディレクトリの作成時に、生成されたドメイン識別子 (`d-*` 識別子) を指定します。
+ 作成した IAM ロール名を指定します。
+ DB インスタンスセキュリティグループがディレクトリセキュリティグループからインバウンドトラフィックを受信し、ディレクトリへのアウトバウンドトラフィックを送信できることを確認してください。
DB インスタンスを作成するためにコンソールを使用する場合は、**データベースの認証** セクションの [**パスワードと Kerberos 認証**] を選択します。[**ディレクトリの参照**] を選択してディレクトリを選択するか、[**新しいディレクトリの作成**] を選択します。
![\[DB インスタンスの作成時の Kerberos 認証設定\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/kerberos-authentication.png)
コンソールを使用して DB インスタンスを変更または復元する場合は、[**Kerberos 認証**] セクションでディレクトリを選択するか、[**Create a new directory (新しいディレクトリの作成)**] を選択します。
![\[DB インスタンスの変更または復元時の Kerberos 認証設定\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/kerberos-auth-modify-restore.png)
AWS CLI を使用する場合は、DB インスタンスが、作成したディレクトリを使用できるように、以下のパラメータが必要です。
+ `--domain` パラメータには、ディレクトリの作成時に生成されたドメイン識別子 ("d-\$1" 識別子) を使用します。
+ `--domain-iam-role-name` パラメータには、マネージド IAM ポリシー `AmazonRDSDirectoryServiceAccess` を使用する作成済みのロールを使用します。
例えば、以下の CLI コマンドはディレクトリを使用するように DB インスタンスを変更します。
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--domain d-ID \
--domain-iam-role-name role-name
```
Windows の場合:
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--domain d-ID ^
--domain-iam-role-name role-name
```
**重要**
Kerberos 認証を有効化するために DB インスタンスを変更する場合、変更後 DB インスタンスを再起動します。
**注記**
*MANAGED\$1SERVICE\$1USER* は、RDS の Directory Service によってランダムに生成される名前を持つサービスアカウントです。Kerberos 認証のセットアップ時に、RDS for Oracle は同じ名前のユーザーを作成し、そのユーザーに `CREATE SESSION` 権限を割り当てます。Oracle DB ユーザーは、外部で *MANAGED\$1SERVICE\$1USER@EXAMPLE.COM* と識別されます。*EXAMPLE.COM* はドメインの名前です。RDS は定期的に、Directory Service によって提供される認証情報を使用して Oracle データベースにログインします。その後、RDS はすぐにチケットキャッシュを破棄します。
## ステップ 7: Kerberos 認証 Oracle ログインを作成する
Amazon RDS マスターユーザーの認証情報を使用して、他の DB インスタンスと同様に Oracle DB インスタンスに接続します。DB インスタンスは、AWS Managed Microsoft AD ドメインに接続されています。このように、ドメインの Microsoft Active Directory ユーザーおよびから Oracle ログインおよびユーザーのプロビジョニングができます。標準の Oracle 権限をこれらのログインに付与したり、取り消したりしてデータベースの権限を管理します。
**Microsoft Active Directory のユーザーに Oracle 認証を許可するには**
1. Amazon RDS マスターユーザー認証情報を使用して、Oracle DB インスタンスに接続します。
1. 外部認証されたユーザーを Oracle データベース内に作成します。
次の例では、`KRBUSER@CORP.EXAMPLE.COM` をユーザ名とドメイン名に置き換えます。
```
CREATE USER "KRBUSER@CORP.EXAMPLE.COM" IDENTIFIED EXTERNALLY;
GRANT CREATE SESSION TO "KRBUSER@CORP.EXAMPLE.COM";
```
これでドメインのユーザー (人とアプリケーションの両方) は、Kerberos 認証を使用してドメインに参加しているクライアントマシンから Oracle DB インスタンスに接続できます。
## ステップ 8: Oracle クライアントを設定する
Oracle クライアントを構成するには、次の要件を満たす必要があります。
+ ドメインを指すように、krb5.conf (Linux) または krb5.ini (Windows) という名前の設定ファイルを作成します。この設定ファイルを使用する Oracle クライアントを設定します。
+ TCP/UDP の 53 番ポート (DNS)、Kerberos ポート(マネージド型 Directory Service 向けの 88 番および 464 番)、および TCP の389 番 LDAP ポートを介して、クライアントホストと Directory Service の間でトラフィックが流れているかを確認します。
+ データベースポートを介してクライアントホストと DB インスタンス間でトラフィックが流れることを確認します。
以下は、AWS Managed Microsoft AD のサンプルコンテンツです。
```
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = example.com
admin_server = example.com
}
[domain_realm]
.example.com = CORP.EXAMPLE.COM
example.com = CORP.EXAMPLE.COM
```
以下は、オンプレミス Microsoft AD のサンプルコンテンツです。krb5.conf ファイルまたは krb5.ini ファイルで、*on-prem-ad-server-name* をオンプレミス AD サーバー名に置き換えます。
```
[libdefaults]
default_realm = ONPREM.COM
[realms]
AWSAD.COM = {
kdc = awsad.com
admin_server = awsad.com
}
ONPREM.COM = {
kdc = on-prem-ad-server-name
admin_server = on-prem-ad-server-name
}
[domain_realm]
.awsad.com = AWSAD.COM
awsad.com= AWSAD.COM
.onprem.com = ONPREM.COM
onprem.com= ONPREM.COM
```
**注記**
krb5.ini ファイル または krb5.conf ファイルを設定したら、サーバーを再起動することをお勧めします。
以下は、SQL\$1Plus 構成向けの sqlnet.ora の内容のサンプルです。
```
SQLNET.AUTHENTICATION_SERVICES=(KERBEROS5PRE,KERBEROS5)
SQLNET.KERBEROS5_CONF=path_to_krb5.conf_file
```
SQL 開発者向け構成の例に関しては、Oracle サポートの「[ドキュメント 1609359.1](https://support.oracle.com/epmos/faces/DocumentDisplay?id=1609359.1)」をご参照ください。
# ドメインの DB インスタンスの管理
コンソール、CLI、RDS API を使用して、DB インスタンスと Microsoft Active Directory との関係を管理できます。例えば、Kerberos 認証を有効化するために、Microsoft Active Directory を関連付けることができます。また、Kerberos 認証を無効化するために、Microsoft Active Directory を関連付けを解除することができます。さらに、1 つの Microsoft Active Directory によって外部に認証される DB インスタンスをもう 1 つの Microsoft Active Directory に移動することもできます。
例えば、CLI を使用して次を実行できます。
+ メンバーシップが失敗認めに Kerberos 認証を再度有効化することを試みるには、[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) CLI コマンドを使用し、`--domain` オプションの現在のメンバーシップのディレクトリ ID を指定します。
+ DB インスタンスの Kerberos 認証を無効にするには、[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) CLI コマンドを使用して、`none` オプションに `--domain` を指定します。
+ 1 つのドメインから他のドメインに DB インスタンスを移動するには、[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) CLI コマンドを使用して、`--domain` オプションに新しいドメインのドメイン識別子を指定します。
## ドメインメンバーシップ状態の表示
DB インスタンスを作成または変更した後で、その DB インスタンスは、ドメインのメンバーになります。DB インスタンスのドメインメンバーシップのステータスは、コンソールで表示したり、[describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) CLI コマンドを実行して表示したりすることができます。DB インスタンスのステータスは、以下のいずれかです。
+ `kerberos-enabled` - DB インスタンスは Kerberos 認証を有効化しました。
+ `enabling-kerberos` - AWS は、この DB インスタンスで Kerberos 認証を有効化中です。
+ `pending-enable-kerberos` - この DB インスタンスでは、Kerberos 認証の有効化が保留中になっています。
+ `pending-maintenance-enable-kerberos` - AWS は、次にスケジュールされたメンテナンスウィンドウで、DB インスタンスでの Kerberos 認証の有効化を試みます。
+ `pending-disable-kerberos` - この DB インスタンスでは、Kerberos 認証の無効化が保留中になっています。
+ `pending-maintenance-disable-kerberos` – AWS は、次にスケジュールされたメンテナンスウィンドウで、DB インスタンスでの Kerberos 認証の無効化を試みます。
+ `enable-kerberos-failed` – 設定の問題により、AWS は DB インスタンス上の Kerberos 認証を有効化できませんでした。DB インスタンスを変更するコマンドを再発行する前に、設定の問題を修正します。
+ `disabling-kerberos` - AWS は、この DB インスタンスで Kerberos 認証を無効化中です。
ネットワーク接続の問題や正しくない IAM ロールのために、Kerberos 認証を有効化するリクエストは失敗する可能性があります。DB インスタンスを作成または変更する際に Kerberos 認証を有効化する試みが失敗した場合は、正しい IAM ロールを使用していることを確認してください。次に、DB インスタンスを変更し、ドメインに接続します。
**注記**
Amazon RDS for Oracle を使用する Kerberos 認証でのみ、ドメインの DNS サーバーにトラフィックが送信されます。他のすべての DNS リクエストは、Oracle を実行している DB インスタンスでアウトバウンドのネットワークアクセスとして取り扱われます。Amazon RDS for Oracle を使用するアウトバウンドのネットワークアクセスに関する詳細は、「[カスタム DNS サーバーのセットアップ](Appendix.Oracle.CommonDBATasks.System.md#Appendix.Oracle.CommonDBATasks.CustomDNS)」を参照してください。
## Kerberos キーの強制更新
シークレットキーは、AWS Managed Microsoft AD と Amazon RDS for Oracle DB インスタンス間で共有されます。このキーは、45 日ごとに自動で更新されます。このキーを強制的に更新するには、次の Amazon RDS 手順を実行してください。
```
SELECT rdsadmin.rdsadmin_kerberos_auth_tasks.rotate_kerberos_keytab AS TASK_ID FROM DUAL;
```
**注記**
リードレプリカの設定では、ソース DB インスタンスのみでこの手順を実行可能で、リードレプリカでは実行できません。
`SELECT` ステートメントでは、データ型 `VARCHAR2` のタスクの ID が返ります。実行中のタスクのステータスは bdump ファイルで確認できます。bdump ファイルは `/rdsdbdata/log/trace` ディレクトリにあります。bdump ファイルの名前形式は、以下のとおりです。
```
dbtask-task-id.log
```
タスクの出力ファイルを表示すると、結果を確認できます。
```
SELECT text FROM table(rdsadmin.rds_file_util.read_text_file('BDUMP','dbtask-task-id.log'));
```
*`task-id`* は、この手順で返されたタスク ID に置き換えます。
**注記**
タスクは非同期的に実行されます。
# Oracle を Kerberos 認証に接続する
このセクションは、「[ステップ 8: Oracle クライアントを設定する](oracle-kerberos-setting-up.md#oracle-kerberos.setting-up.configure-oracle-client)」で説明されているように Oracle クライアントをセットアップ済みであることを前提としています。Kerberos 認証により Oracle DB に接続するには、Kerberos 認証タイプを使用してログインします。例えば、Oracle SQL Developer を起動した後で、以下の例に示すように、**[Kerberos 認証]** を認証タイプとして選択します。
![\[Oracle SQL Developer の [データベース接続の新規作成/選択] ダイアログボックスを表示します。[Kerberos 認証] チェックボックスが選択されています。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/ora-kerberos-auth.png)
SQL\$1Plus で Kerberos 認証を使用して Oracle に接続するには:
1. コマンドプロンプトで、次のコマンドを実行します。
```
kinit username
```
*`username`* をユーザー名で置き換え、プロンプトでユーザーに Microsoft Active Directory で保存されているパスワードを入力します。
1. SQL\$1Plus を開き、DNS の名前および Oracle DB インスタンスのポート番号を使用して接続します。
SQL\$1Plus での Oracle DB インスタンスへの接続の詳細については、「[SQL \$1Plus を使用した DB インスタンスへの接続](USER_ConnectToOracleInstance.SQLPlus.md)」を参照してください。
**ヒント**
ネイティブ Windows キャッシュを使用している場合は、sqlnet.ora ファイルで `SQLNET.KERBEROS5_CC_NAME` パラメータを `OSMSFT://` または `MSLSA` に設定して、Microsoft Active Directory に保存されている認証情報を使用することもできます。
# 証明書と Oracle ウォレットを使用した、UTL\$1HTTP アクセスの設定
Amazon RDS は RDS for Oracle DB インスタンスでのアウトバウンドネットワークアクセスをサポートします。DB インスタンスをネットワークに接続するには、次の PL/SQL パッケージを使用できます。
`UTL_HTTP`
このパッケージでは、SQL および PL/SQL から HTTP 呼び出しを実行します。HTTP 経由でインターネット上のデータにアクセスするために使用できます。詳細については、Oracle ドキュメントの「[UTL\$1MAIL](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/UTL_HTTP.html#GUID-A85D2D1F-90FC-45F1-967F-34368A23C9BB)」を参照してください。
`UTL_TCP`
このパッケージは、PL/SQL で TCP/IP クライアント側アクセス機能を提供します。このパッケージは、インターネットプロトコルと E メールを使用する PL/SQL アプリケーションに役立ちます。詳細については、Oracle ドキュメントの「[UTL\$1TCP](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/UTL_TCP.html#GUID-348AFFE8-78B2-4217-AE73-384F46A1D292)」を参照してください。
`UTL_SMTP`
このパッケージは、SMTP コマンドへのインターフェイスを提供します。これにより、クライアントが E メールを SMTP サーバーにディスパッチできるようにします。詳細については、Oracle ドキュメントの「[UTL\$1SMTP](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/UTL_SMTP.html#GUID-F0065C52-D618-4F8A-A361-7B742D44C520)」を参照してください。
次のタスクを完了すると、`UTL_HTTP.REQUEST` を設定できます。これにより、SSL ハンドシェイク中にクライアント認証の証明書を要求するウェブサイトを操作できます。また Oracle ウォレットの生成コマンドや、`DBMS_NETWORK_ACL_ADMIN.APPEND_WALLET_ACE` の手順を修正して、ウェブサイトへの `UTL_HTTP` アクセスに使用するパスワード認証を設定することもできます。詳細については、Oracle Database のドキュメントの「[DBMS\$1NETWORK\$1ACL\$1ADMIN](https://docs.oracle.com/en/database/oracle/oracle-database/21/arpls/DBMS_NETWORK_ACL_ADMIN.html)」を参照してください。
**注記**
`UTL_SMTP` に合わせ次のタスクを変更して、SSL/TLS 経由でメールを送信できるようにします ([Amazon Simple Email Service](https://aws.amazon.com/ses/) を含む)。
**Topics**
+ [UTL\$1HTTP アクセスを設定する際の考慮事項](#utl_http-considerations)
+ [ステップ 1: ウェブサイトのルート証明書を取得する](#website-root-certificate)
+ [ステップ 2: Oracle ウォレットを作成する](#create-oracle-wallet)
+ [ステップ 3: RDS for Oracle インスタンスに、Oracle ウォレットをダウンロードする](#upload-wallet-to-instance)
+ [ステップ 4: ユーザーに Oracle ウォレットへのアクセス許可を付与する](#config-oracle-wallet-user)
+ [ステップ 5: DB インスタンスからウェブサイトへのアクセスを設定する](#config-website-access)
+ [ステップ 6: DB インスタンスからウェブサイトへの接続をテストする](#test_utl_http)
## UTL\$1HTTP アクセスを設定する際の考慮事項
アクセスを設定する前に、以下を考慮してください。
+ UTL\$1MAIL オプションで SMTP を使用することができます。詳細については、「[Oracle UTL\$1MAIL](Oracle.Options.UTLMAIL.md)」を参照してください。
+ リモートホストのドメインネームサーバー (DNS) の名は、以下のいずれかです:
+ パブリックに解決可能。
+ Amazon RDS DB インスタンスのエンドポイント。
+ 独自のDNS サーバーを介して解決可能。詳細については、「[カスタム DNS サーバーのセットアップ](Appendix.Oracle.CommonDBATasks.System.md#Appendix.Oracle.CommonDBATasks.CustomDNS)」を参照してください。
+ 同じ VPC またはピアリング接続先 VPC の Amazon EC2 インスタンスのプライベート DNS 名。この場合、名前がカスタム DNS サーバーを介して解決可能であることを確認してください。また、VPC 設定の `enableDnsSupport` 属性を有効にし、VPC ピア接続の DNS 解決サポートを有効にすることで Amazon が提供する DNS を使用することもできます。詳細については、「[VPC の DNS サポート](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-support)」および「[VPC ピア接続の変更](https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html#modify-peering-connections)」を参照してください。
+ リモート SSL/TLS リソースに安全に接続するには、カスタマイズされた Oracle ウォレット を作成し、アップロードすることをお勧めします。Amazon S3 を Amazon RDS for Oracle 機能と統合することで、Amazon S3 から Oracle DB インスタンスにウォレットをダウンロードします。Oracle 用の Amazon S3 の統合については、「[「Amazon S3 統合」](oracle-s3-integration.md)」を参照してください。
+ Oracle SSL オプションがインスタンスごとに構成されている場合は、SSL/TLS エンドポイントを介して Oracle DB インスタンス間にデータベースリンクを確立することができます。必要な設定はこれだけです。詳細については、「[Oracle Secure Sockets Layer](Appendix.Oracle.Options.SSL.md)」を参照してください。
## ステップ 1: ウェブサイトのルート証明書を取得する
RDS for Oracle DB インスタンスがウェブサイトへのセキュアな接続を確立するには、ルート CA 証明書を追加します。Amazon RDS はルート証明書を使用して、Oracle ウォレットにウェブサイトの証明書を署名します。
ルート証明書は、さまざまな方法で取得できます。例えば、次のオペレーションを実行できます。
1. ウェブサーバーを使用して、証明書で保護されたウェブサイトにアクセスします。
1. 署名に使われたルート証明書をダウンロードします。
AWS のサービスの場合、ルート証明書は通常、[Amazon Trust Services リポジトリ](https://www.amazontrust.com/repository/)にあります。
## ステップ 2: Oracle ウォレットを作成する
ウェブサーバー証明書とクライアント認証証明書の両方を含む Oracle ウォレットを作成します。RDS Oracle インスタンスは、ウェブサーバー証明書を使用して、ウェブサイトへの安全な接続を確立します。ウェブサイトでは、Oracle のデータベースユーザーを認証するために、クライアント証明書が必要です。
認証にクライアント証明書を使用せずに、セキュアな接続を構成したい場合があります。この場合、次の手順で Java キーストアのステップを省略できます。
**Oracle ウォレットを作成するには**
1. ルート証明書とクライアント証明書を 1 つのディレクトリに配置してから、このディレクトリに移動します。
1. .p12 クライアント証明書を、Java キーストアに変換します。
**注記**
認証にクライアント証明書を使用していない場合は、このステップを省略できます。
次の例では、*client\$1certificate.p12* という名前のクライアント証明書を、*client\$1keystore.jks* という名前の Java キーストアに変換します。その後、キーストアは Oracle ウォレットに入ります。キーストアのパスワードは *P12PASSWORD* です。
```
orapki wallet pkcs12_to_jks -wallet ./client_certificate.p12 -jksKeyStoreLoc ./client_keystore.jks -jksKeyStorepwd P12PASSWORD
```
1. 証明書のディレクトリとは別に、Oracle ウォレット用のディレクトリを作成します。
例えば、次の例では `/tmp/wallet` ディレクトリを作成します。
```
mkdir -p /tmp/wallet
```
1. ウォレットディレクトリに、Oracle ウォレットを作成します。
次の例では、Oracle ウォレット パスワードを *P12PASSWORD* に設定します。これは、前のステップで Java キーストアで使用したのと同じパスワードです。同じパスワードを使用すると便利ですが、必須ではありません。`-auto_login` パラメータが自動ログイン機能をオンにするため、アクセスするたびにパスワードを指定する必要はありません。
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
```
orapki wallet create -wallet /tmp/wallet -pwd P12PASSWORD -auto_login
```
1. Java キーストアを、Oracle ウォレットに追加します。
**注記**
認証にクライアント証明書を使用していない場合は、このステップを省略できます。
次の例では、*/tmp/wallet* という Oracle ウォレットに、*client\$1keystore.jks* キーストアを追加します。この例では、Java キーストアと Oracle ウォレットに、同じパスワードを指定します。
```
orapki wallet jks_to_pkcs12 -wallet /tmp/wallet -pwd P12PASSWORD -keystore ./client_keystore.jks -jkspwd P12PASSWORD
```
1. Oracle ウォレットに、対象のウェブサイトのルート証明書を追加します。
次の例では、*Root\$1CA.cer* という名前の証明書を追加します。
```
orapki wallet add -wallet /tmp/wallet -trusted_cert -cert ./Root_CA.cer -pwd P12PASSWORD
```
1. 中間証明書を追加します。
次の例では、*Intermediate.cer* という名前の証明書を追加します。中間証明書をすべてロードするまで、この手順を必要な回数繰り返します。
```
orapki wallet add -wallet /tmp/wallet -trusted_cert -cert ./Intermediate.cer -pwd P12PASSWORD
```
1. 新しく作成した Oracle ウォレットに、必要な証明書があることを確認します。
```
orapki wallet display -wallet /tmp/wallet -pwd P12PASSWORD
```
## ステップ 3: RDS for Oracle インスタンスに、Oracle ウォレットをダウンロードする
このステップでは、まず Oracle ウォレットを Amazon S3 にアップロードし、次に Amazon S3 から RDS for Oracle インスタンスにウォレットをダウンロードします。
**RDS for Oracle DB インスタンスに Oracle ウォレットをダウンロードするには**
1. Oracle との Amazon S3 統合の前提条件を満たしたら、`S3_INTEGRATION` オプションを Oracle DB インスタンスに追加します。使用している Amazon S3 バケットへのアクセス権が、オプションの IAM ルールにあることを確認します。
詳細については、「[「Amazon S3 統合」](oracle-s3-integration.md)」を参照してください。
1. マスターユーザーとして DB インスタンスにログインし、Oracle ウォレットを保持しておく Oracle ディレクトリを作成します。
次の例では、*WALLET\$1DIR* という名前で Oracle のディレクトリを作成しています。
```
EXEC rdsadmin.rdsadmin_util.create_directory('WALLET_DIR');
```
詳細については、「[主要データストレージ領域でのディレクトリの作成と削除](Appendix.Oracle.CommonDBATasks.Misc.md#Appendix.Oracle.CommonDBATasks.NewDirectories)」を参照してください。
1. 作成した Oracle ウォレットを Amazon S3 バケットにアップロードします。
サポートされているアップロード方法は、いずれも使用できます。
1. Oracle ウォレットを再度アップロードする場合は、既存のウォレットを削除します。それ以外の場合は、次のステップに進みます。
次の例では、*cwallet.sso* という名前の、既存のウォレットを削除します。
```
EXEC UTL_FILE.FREMOVE ('WALLET_DIR','cwallet.sso');
```
1. Amazon S3 バケットから Oracle DB インスタンスに Oracle ウォレットをダウンロードします。
次の例では、*cwallet.sso* という名前のウォレットを、*my\$1s3\$1bucket* という名前の Amazon S3 バケットから、*WALLET\$1DIR* という名前の DB インスタンスディレクトリにダウンロードしています。
```
SELECT rdsadmin.rdsadmin_s3_tasks.download_from_s3(
p_bucket_name => 'my_s3_bucket',
p_s3_prefix => 'cwallet.sso',
p_directory_name => 'WALLET_DIR')
AS TASK_ID FROM DUAL;
```
1. (オプション) パスワードで保護された Oracle ウォレットをダウンロードします。
このウォレットは、ウォレットを使用するたびにパスワードを要求する場合にのみ、ダウンロードしてください。次の例では、パスワードで保護された *ewallet.p12* ウォレットをダウンロードしています。
```
SELECT rdsadmin.rdsadmin_s3_tasks.download_from_s3(
p_bucket_name => 'my_s3_bucket',
p_s3_prefix => 'ewallet.p12',
p_directory_name => 'WALLET_DIR')
AS TASK_ID FROM DUAL;
```
1. DB タスクのステータスを確認します。
次の例では、前のステップで返されたタスク ID を、*dbtask-1234567890123-4567.log* に代入します。
```
SELECT TEXT FROM TABLE(rdsadmin.rds_file_util.read_text_file('BDUMP','dbtask-1234567890123-4567.log'));
```
1. Oracle ウォレットの保存に使用している、ディレクトリの内容を確認します。
```
SELECT * FROM TABLE(rdsadmin.rds_file_util.listdir(p_directory => 'WALLET_DIR'));
```
詳細については、「[DB インスタンスディレクトリ内のファイルのリスト化](Appendix.Oracle.CommonDBATasks.Misc.md#Appendix.Oracle.CommonDBATasks.ListDirectories)」を参照してください。
## ステップ 4: ユーザーに Oracle ウォレットへのアクセス許可を付与する
データベースのユーザーを新しく作成するか、既存のユーザーを設定できます。いずれの場合も、証明書を使用したセキュアな接続や、クライアント認証のために、Oracle ウォレットにアクセスするようにユーザーを設定する必要があります。
**Oracle ウォレットのユーザーアクセス許可を付与するには**
1. RDS for Oracle DB インスタンスに、マスターユーザーとしてログインします。
1. 既存のデータベースユーザーを設定しない場合は、新しいユーザーを作成します。それ以外の場合は、次のステップに進みます。
次の例では、*my-user* という名前のデータベースユーザーを作成します。
```
CREATE USER my-user IDENTIFIED BY my-user-pwd;
GRANT CONNECT TO my-user;
```
1. データベースユーザーに、Oracle ウォレットのあるディレクトリに対するアクセス許可を付与します。
次の例では、*my-user* ユーザーに対して、*WALLET\$1DIR* ディレクトリへの読み取りアクセス権限を付与します。
```
GRANT READ ON DIRECTORY WALLET_DIR TO my-user;
```
1. データベースユーザーに対して、`UTL_HTTP` パッケージを使用するアクセス許可を付与します。
次の PL/SQL プログラムは、*my-user* ユーザーに対して、`UTL_HTTP` へのアクセス許可を付与します。
```
BEGIN
rdsadmin.rdsadmin_util.grant_sys_object('UTL_HTTP', UPPER('my-user'));
END;
/
```
1. データベースユーザーに対して、`UTL_FILE` パッケージを使用するアクセス許可を付与します。
次の PL/SQL プログラムは、*my-user* ユーザーに対して、`UTL_FILE` へのアクセス許可を付与します。
```
BEGIN
rdsadmin.rdsadmin_util.grant_sys_object('UTL_FILE', UPPER('my-user'));
END;
/
```
## ステップ 5: DB インスタンスからウェブサイトへのアクセスを設定する
このステップでは、`UTL_HTTP` やアップロードした Oracle ウォレット、クライアント証明書を使用して、対象のウェブサイトに接続できるように、Oracle データベースユーザーを設定します。詳細については、Oracle Database のドキュメントの「[Configuring Access Control to an Oracle Wallet](https://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/managing-fine-grained-access-in-pl-sql-packages-and-types.html#GUID-0BCB5925-A40F-4507-95F9-5DA4A1919EBD)」(Oracle Wallet に対するアクセス制御の設定) を参照してください。
**RDS for Oracle DB インスタンスからウェブサイトへのアクセスを設定するには**
1. RDS for Oracle DB インスタンスに、マスターユーザーとしてログインします。
1. セキュアなポートで、ユーザーと対象のウェブサイトの Host Access Control Entry (ACE) を作成します。
次の例では、*my-user* ユーザーが、セキュアなポート 443 経由で *secret.encrypted-website.com* にアクセスできるように設定します。
```
BEGIN
DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
host => 'secret.encrypted-website.com',
lower_port => 443,
upper_port => 443,
ace => xs$ace_type(privilege_list => xs$name_list('http'),
principal_name => 'my-user',
principal_type => xs_acl.ptype_db));
-- If the program unit results in PLS-00201, set
-- the principal_type parameter to 2 as follows:
-- principal_type => 2));
END;
/
```
**重要**
前述のプログラムユニットでは、次のエラーが発生する可能性があります: `PLS-00201: identifier 'XS_ACL' must be declared`。このエラーが返された場合は、`principal_type` に値を割り当てる行を次の行に置き換えてから、プログラムユニットを再実行します。
```
principal_type => 2));
```
PL/SQL パッケージ `XS_ACL` の定数の詳細については、Oracle Database ドキュメントの「[https://docs.oracle.com/en/database/oracle/oracle-database/19/dbfsg/XS_ACL-package.html#GUID-A157FB28-FE23-4D30-AAEB-8224230517E7](https://docs.oracle.com/en/database/oracle/oracle-database/19/dbfsg/XS_ACL-package.html#GUID-A157FB28-FE23-4D30-AAEB-8224230517E7)」を参照してください。
詳細については、Oracle Database のドキュメントの「[Configure Access Control Lists (ACLs) to External Network Services](https://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/managing-fine-grained-access-in-pl-sql-packages-and-types.html#GUID-3D5B66BC-0277-4887-9CD1-97DB44EB5213)」(外部ネットワークサービスへのアクセス制御リスト (ACL) の構成) を参照してください。
1. (オプション) 標準のポートで、ユーザーと対象のウェブサイトの ACE を作成します。
一部のウェブページが、セキュアポート (443) ではなく標準のウェブサーバーのポート (80) から提供される場合は、標準のポートを使用する必要がある場合があります。
```
BEGIN
DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
host => 'secret.encrypted-website.com',
lower_port => 80,
upper_port => 80,
ace => xs$ace_type(privilege_list => xs$name_list('http'),
principal_name => 'my-user',
principal_type => xs_acl.ptype_db));
-- If the program unit results in PLS-00201, set
-- the principal_type parameter to 2 as follows:
-- principal_type => 2));
END;
/
```
1. アクセスコントロールエントリが存在することを確認します。
```
SET LINESIZE 150
COLUMN HOST FORMAT A40
COLUMN ACL FORMAT A50
SELECT HOST, LOWER_PORT, UPPER_PORT, ACL
FROM DBA_NETWORK_ACLS
ORDER BY HOST;
```
1. データベースユーザーに対して、`UTL_HTTP` パッケージを使用するアクセス許可を付与します。
次の PL/SQL プログラムは、*my-user* ユーザーに対して、`UTL_HTTP` へのアクセス許可を付与します。
```
BEGIN
rdsadmin.rdsadmin_util.grant_sys_object('UTL_HTTP', UPPER('my-user'));
END;
/
```
1. 関連するアクセスコントロールリストが存在することを確認します。
```
SET LINESIZE 150
COLUMN ACL FORMAT A50
COLUMN PRINCIPAL FORMAT A20
COLUMN PRIVILEGE FORMAT A10
SELECT ACL, PRINCIPAL, PRIVILEGE, IS_GRANT,
TO_CHAR(START_DATE, 'DD-MON-YYYY') AS START_DATE,
TO_CHAR(END_DATE, 'DD-MON-YYYY') AS END_DATE
FROM DBA_NETWORK_ACL_PRIVILEGES
ORDER BY ACL, PRINCIPAL, PRIVILEGE;
```
1. クライアント認証で証明書を使用し、接続で Oracle ウォレットを使用するためのアクセス許可を、データベースユーザーに付与します。
**注記**
認証にクライアント証明書を使用していない場合は、このステップを省略できます。
```
DECLARE
l_wallet_path all_directories.directory_path%type;
BEGIN
SELECT DIRECTORY_PATH
INTO l_wallet_path
FROM ALL_DIRECTORIES
WHERE UPPER(DIRECTORY_NAME)='WALLET_DIR';
DBMS_NETWORK_ACL_ADMIN.APPEND_WALLET_ACE(
wallet_path => 'file:/' || l_wallet_path,
ace => xs$ace_type(privilege_list => xs$name_list('use_client_certificates'),
principal_name => 'my-user',
principal_type => xs_acl.ptype_db));
END;
/
```
## ステップ 6: DB インスタンスからウェブサイトへの接続をテストする
このステップでは、`UTL_HTTP` やアップロードした Oracle ウォレット、クライアント証明書を使用してウェブサイトに接続できるように、データベースユーザーを設定します。
**RDS for Oracle DB インスタンスからウェブサイトへのアクセスを設定するには**
1. RDS for Oracle DB インスタンスに、`UTL_HTTP` へのアクセス許可を持つデータベースユーザーとしてログインします。
1. 対象のウェブサイトへ接続する際に、ホストアドレスを解決できることを確認します。
次の例では、*secret.encrypted-website.com* からホストアドレスを取得します。
```
SELECT UTL_INADDR.GET_HOST_ADDRESS(host => 'secret.encrypted-website.com')
FROM DUAL;
```
1. 失敗した接続をテストします。
`UTL_HTTP` は、証明書とともに Oracle ウォレットの場所を要求するため、次のクエリは失敗します。
```
SELECT UTL_HTTP.REQUEST('secret.encrypted-website.com') FROM DUAL;
```
1. `UTL_HTTP.SET_WALLET` を使用し、`DUAL` から選択した場合の、ウェブサイトへのアクセスをテストします。
```
DECLARE
l_wallet_path all_directories.directory_path%type;
BEGIN
SELECT DIRECTORY_PATH
INTO l_wallet_path
FROM ALL_DIRECTORIES
WHERE UPPER(DIRECTORY_NAME)='WALLET_DIR';
UTL_HTTP.SET_WALLET('file:/' || l_wallet_path);
END;
/
SELECT UTL_HTTP.REQUEST('secret.encrypted-website.com') FROM DUAL;
```
1. (オプション) クエリを変数に保存し、`EXECUTE IMMEDIATE` を使用した場合の、ウェブサイトへのアクセスをテストします。
```
DECLARE
l_wallet_path all_directories.directory_path%type;
v_webpage_sql VARCHAR2(1000);
v_results VARCHAR2(32767);
BEGIN
SELECT DIRECTORY_PATH
INTO l_wallet_path
FROM ALL_DIRECTORIES
WHERE UPPER(DIRECTORY_NAME)='WALLET_DIR';
v_webpage_sql := 'SELECT UTL_HTTP.REQUEST(''secret.encrypted-website.com'', '''', ''file:/' ||l_wallet_path||''') FROM DUAL';
DBMS_OUTPUT.PUT_LINE(v_webpage_sql);
EXECUTE IMMEDIATE v_webpage_sql INTO v_results;
DBMS_OUTPUT.PUT_LINE(v_results);
END;
/
```
1. (オプション) ファイルシステム上で、Oracle ウォレットディレクトリの場所を検索します。
```
SELECT * FROM TABLE(rdsadmin.rds_file_util.listdir(p_directory => 'WALLET_DIR'));
```
前のコマンドからの出力を使用して、HTTP リクエストを作成します。例えば、ディレクトリが *rdsdbdata/userdirs/01* である場合、次のクエリを実行します。
```
SELECT UTL_HTTP.REQUEST('https://secret.encrypted-website.com/', '', 'file://rdsdbdata/userdirs/01')
FROM DUAL;
```
# RDS for Oracle で CDB を使用する
Oracle のマルチテナントアーキテクチャでは、コンテナデータベース (CDB) にカスタマーが作成したプラグイン可能なデータベース (PDB) を含めることができます。CDB の詳細については、Oracle Database ドキュメントの「[マルチテナントアーキテクチャの概要](https://docs.oracle.com/en/database/oracle/oracle-database/19/multi/introduction-to-the-multitenant-architecture.html#GUID-267F7D12-D33F-4AC9-AA45-E9CD671B6F22)」を参照してください。
**Topics**
+ [RDS for Oracle CDB の概要](Oracle.Concepts.CDBs.md)
+ [RDS for Oracle CDB の設定](oracle-cdb.configuring.md)
+ [CDB のバックアップと復元](Oracle.Concepts.single-tenant.snapshots.md)
+ [RDS for Oracle の 非 CDB から CDB への変換](oracle-cdb-converting.md)
+ [シングルテナント設定からマルチテナント設定への変換](oracle-single-tenant-converting.md)
+ [RDS for Oracle テナントデータベースを CDB インスタンスに追加する](oracle-cdb-configuring.adding.pdb.md)
+ [RDS for Oracle テナントデータベースの変更](oracle-cdb-configuring.modifying.pdb.md)
+ [RDS for Oracle テナントデータベースを CDB から削除する](oracle-cdb-configuring.deleting.pdb.md)
+ [テナントデータベースの詳細を表示する](oracle-cdb-configuring.describing.pdb.md)
+ [CDB のアップグレード](Oracle.Concepts.single-tenant.upgrades.md)
# RDS for Oracle CDB の概要
Oracle Database 19c 以降を実行している場合、RDS for Oracle DB インスタンスをコンテナデータベース (CDB) として作成できます。Oracle Database 21c 以降では、すべてのデータベースは CDB です。CDB は、RDS for Oracle でテナントデータベースと呼ばれるプラガブルデータベース (PDB) を格納できるという点で、非 CDB とは異なります。PDB は、スキーマとオブジェクトのポータブルコレクションであり、アプリケーションには別のデータベースとして表示されます。
CDB インスタンスを作成するときには、初期テナントデータベース (PDB) を作成します。RDS for Oracle では、クライアントアプリケーションは CDB ではなく PDB とやり取りします。PDB でのエクスペリエンスは、非 CDB でのエクスペリエンスとほぼ同じです。
**Topics**
+ [CDB アーキテクチャのマルチテナント設定](#multi-tenant-configuration)
+ [CDB アーキテクチャのシングルテナント設定](#Oracle.Concepts.single-tenant)
+ [CDB の作成と変換のオプション](#oracle-cdb-creation-conversion)
+ [CDB のユーザーアカウントと権限](#Oracle.Concepts.single-tenant.users)
+ [CDB のパラメータグループファミリー](#Oracle.Concepts.single-tenant.parameters)
+ [RDS for Oracle CDB の制限事項](#Oracle.Concepts.single-tenant-limitations)
## CDB アーキテクチャのマルチテナント設定
RDS for Oracle は、Oracle マルチテナントアーキテクチャのマルチテナント設定 (*CDB アーキテクチャ*とも呼ばれる) をサポートしています。この設定では、RDS for Oracle CDB インスタンスに、データベースのエディションと必要なオプションライセンスに応じて、1～30 個のテナントデータベースを含めることができます。Oracle データベースでは、テナントデータベースは PDB です。DB インスタンスが 19.0.0.0.0.ru-2022-01.r1 以降の Oracle Database を使用する必要があります。
**注記**
Amazon RDS 設定は、単なる Oracle DB エンジンではなく、Amazon RDS の機能であるため、「multitenant」ではなく「multi-tenant」と呼ばれています。同様に、RDS の用語「テナント」は、Oracle PDB だけでなく、RDS 設定のすべてのテナントを指します。RDS のドキュメントの「Oracle マルチテナント」という用語は、オンプレミスデプロイと RDS デプロイの両方に対応する Oracle データベース CDB アーキテクチャのみを指します。
以下の設定を設定できます。
+ テナントデータベース名
+ テナントデータベースのマスターユーザー名
+ テナントデータベースのマスターパスワード (オプションで Secrets Manager と統合)
+ テナントデータベース文字セット
+ テナントデータベース各国語文字セット
テナントデータベース文字セットは CDB の文字セットと異なる場合があります。同じことが各国語文字セットにも当てはまります。最初のテナントデータベースを作成したら、RDS API を使用してテナントデータベースを作成、変更、または削除できます。CDB 名はデフォルトで `RDSCDB` に設定されており、変更できません。詳細については、「[DB インスタンスの設定](USER_CreateDBInstance.Settings.md)」および「[RDS for Oracle テナントデータベースの変更](oracle-cdb-configuring.modifying.pdb.md)」を参照してください。
## CDB アーキテクチャのシングルテナント設定
RDS for Oracle は、シングルテナント設定と呼ばれる Oracle マルチテナントアーキテクチャのレガシー設定をサポートしています。この設定では、RDS for Oracle CDB インスタンスには 1 つのテナント (PDB) しか格納できません。後にさらに PDB を作成することはできません。
## CDB の作成と変換のオプション
Oracle Database 21c は CDB のみをサポートしていますが、Oracle Database 19c は CDB と非 CDB の両方をサポートしています。RDS for Oracle CDB インスタンスはすべて、マルチテナント設定とシングルテナント設定の両方をサポートしています。
### Oracle データベースアーキテクチャの作成、変換、アップグレードのオプション
次の表に、RDS for Oracle Database の作成とアップグレードのさまざまなアーキテクチャオプションを示します。
| リリース | データベース作成オプション | アーキテクチャ変換オプション | メジャーバージョンアップグレードターゲット |
| --- | --- | --- | --- |
| Oracle Database 21c | CDB アーキテクチャのみ | 該当なし | 該当なし |
| Oracle Database 19c | CDB または非 CDB アーキテクチャ | 非 CDB から CDB アーキテクチャへ (April 2021 RU 以降) | Oracle Database 21c CDB |
前の表に示すように、非 CDB を新しいメジャーデータベースバージョンの CDB に直接アップグレードすることはできません。ただし、Oracle Database 19c の非 CDB を Oracle Database 19c CDB に変換してから、Oracle Database 19c CDB を Oracle Database 21c CDB にアップグレードすることはできます。詳細については、「[RDS for Oracle の 非 CDB から CDB への変換](oracle-cdb-converting.md)」を参照してください。
### CDB アーキテクチャ設定の変換オプション
次の表は、RDS for Oracle DB インスタンスのアーキテクチャ設定を変換するためのさまざまなオプションを示しています。
| 現在のアーキテクチャと設定 | CDB アーキテクチャのシングルテナント設定への変換 | CDB アーキテクチャのマルチテナント設定への変換 | 非 CDB アーキテクチャへの変換 |
| --- | --- | --- | --- |
| 非 CDB | サポート対象 | サポート対象\$1 | 該当なし |
| シングルテナント設定を使用した CDB | 該当なし | サポート対象 | サポートされていません |
| マルチテナント設定を使用した CDB | サポートされていません | 該当なし | サポートされていません |
\$1 非 CDB を 1 回の操作でマルチテナント設定に変換することはできません。非 CDB を CDB に変換すると、CDB はシングルテナント設定になります。その後、別の操作でシングルテナントをマルチテナント設定に変換できます。
## CDB のユーザーアカウントと権限
Oracle マルチテナントアーキテクチャでは、すべてのユーザーアカウントが共通ユーザーまたはローカルユーザーのいずれかになります。CDB 共通ユーザーとは、単一のアイデンティティとパスワードが CDB ルート、ならびに既存および将来のすべての PDB で認識されているデータベースユーザーです。対照的に、ローカルユーザーは 1 つの PDB にのみ存在します。
RDS マスターユーザーは PDB 内のローカルユーザーアカウントで、DB インスタンスを作成するときに名前を付けます。新しいユーザーアカウントを作成すると、これらのユーザーも PDB に常駐するローカルユーザーとなります。ユーザーアカウントを使用して新しい PDB を作成したり、既存の PDB の状態を変更したりすることはできません。
`rdsadmin` ユーザーは共通のユーザーアカウントです。このアカウントに存在する RDS for Oracle パッケージを実行できますが、`rdsadmin` としてログインすることはできません。詳細については、Oracle のドキュメントの [About Common Users and Local Users](https://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/managing-security-for-oracle-database-users.html#GUID-BBBD9904-F2F3-442B-9AFC-8ACDD9A588D8) を参照してください。
マルチテナント設定とシングルテナント設定の両方のマスターユーザーの場合、セルフマネージドまたは AWS Secrets Manager によって管理される認証情報を使用できます。シングルテナント設定では、マネージドマスターパスワードに `create-db-instance` などのインスタンスレベルの CLI コマンドを使用します。マルチテナント設定では、マネージドマスターパスワードに `create-tenant-database` などのテナントデータベースコマンドを使用します。Secrets Manager との統合の詳細については、「[Secrets Manager を使用した RDS for Oracle テナントデータベースのマスターユーザーパスワードの管理](rds-secrets-manager.md#rds-secrets-manager-tenant)」を参照してください。
## CDB のパラメータグループファミリー
CDB には、独自のパラメータグループファミリーおよびデフォルトパラメータ値があります。CDB パラメータグループファミリーは次のとおりです。
+ oracle-ee-cdb-21
+ oracle-se2-cdb-21
+ oracle-ee-cdb-19
+ oracle-se2-cdb-19
## RDS for Oracle CDB の制限事項
RDS for Oracle は、オンプレミス CDB で使用できる機能のサブセットをサポートしています。
### CDB の制限事項
以下の制限は、RDS for Oracle に CDB レベルで適用されます。
+ CDB に接続することはできません。常に CDB ではなくテナントデータベース (PDB) に接続します。非 CDB の場合と同様に、PDB のエンドポイントを指定します。唯一の違いは、データベース名に *pdb\$1name* を指定することです。ここで、*pdb\$1name* は PDB のために選択した名前です。
+ マルチテナント設定の CDB をシングルテナント変換の CDB に変換することはできません。マルチテナント設定への変換は一方向で、元に戻すことはできません。
+ DB インスタンスが 19.0.0.0.ru-2022-01.r1 より前の Oracle データベースのリリースを使用している場合は、マルチテナント設定を有効にしたり、マルチテナント設定に変換したりすることはできません。
+ CDB でデータベースアクティビティストリームを使用することはできません。
+ `CDB$ROOT` 内から監査を有効にすることはできません。各 PDB 内で個別に監査を有効にする必要があります。
### テナントデータベース (PDB) の制限事項
RDS for Oracle マルチテナント設定のテナントデータベースには、次の制限が適用されます。
+ テナントデータベースの操作をメンテナンス期間まで延期することはできません。すべての変更はすぐに反映されます。
+ シングルテナント設定を使用する CDB には、テナントデータベースを追加できません。
+ 1 回の操作で、複数のテナントデータベースを追加または変更することはできません。一度に追加または変更できる項目は 1 つのみです。
+ テナントデータベースを `CDB$ROOT` または `PDB$SEED` という名前に変更することはできません。
+ CDB 内のテナントが 1 つのみの場合、そのテナントデータベースは削除できません。
+ すべての DB インスタンスクラスタイプが、RDS for Oracle CDB インスタンスで複数の PDB をサポートするのに十分なリソースを備えているわけではありません。PDB 数が増えると、小規模なインスタンスクラスのパフォーマンスと安定性に影響し、データベースのアップグレードなど、ほとんどのインスタンスレベルの操作にかかる時間が長くなります。
+ `rdsadmin.rdsadmin_util.rename_global_name` を使用して PDB の名前を変更することはできません。代わりに `modify-tenant-database` API を使用する必要があります。
+ 同じ CDB に複数の AWS アカウント を使用して PDB を作成することはできません。PDB は、PDB がホストされている DB インスタンスと同じアカウントが所有しているものである必要があります。
+ CDB 内のすべての PDB は、同じエンドポイントとデータベースリスナーを使用します。
+ 以下の操作は PDB レベルではサポートされていませんが、CDB レベルではサポートされています。
+ バックアップとリカバリ
+ データベースアップグレード
+ メンテナンスアクション
+ 以下の機能は PDB レベルではサポートされていませんが、CDB レベルではサポートされています。
+ オプショングループ (オプションは CDB インスタンスのすべての PDB にインストールされます)
+ パラメータグループ (すべてのパラメータは CDB インスタンスに関連付けられたパラメータグループから導出されます)
+ オンプレミスの CDB アーキテクチャではサポートされているが、RDS for Oracle CDB ではサポートされていない PDB レベルの操作には、次のようなものがあります。
**注記**
以下のリストは完全なものではありません。
+ Application ELB
+ Proxy PDBs
+ PDB の起動または停止
+ PDB のアンプラグとプラギング
CDB へ、または CDB からデータを移動するには、非 CDB と同じ手法を使用します。データ移行に関する詳細については、「[Amazon RDS の Oracle にデータをインポートする](Oracle.Procedural.Importing.md)」を参照してください。
+ PDB レベルでのオプション設定
PDB は CDB オプショングループからオプション設定を継承します。設定オプションの詳細については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。ベストプラクティスについては、[DB パラメータグループを使用する](CHAP_BestPractices.md#CHAP_BestPractices.DBParameterGroup)を参照してください。
+ PDB のパラメータの設定
PDB は CDB からパラメータ設定を継承します。設定オプションの詳細については、「[Oracle DB インスタンスへのオプションの追加](Appendix.Oracle.Options.md)」を参照してください。
+ 同じ CDB 内の PDB に異なるリスナーを設定する
+ Oracle Flashback 機能
# RDS for Oracle CDB の設定
CDB の設定は、非 CDB の設定と似ています。
**Topics**
+ [RDS for Oracle CDB インスタンスの作成](#Oracle.Concepts.single-tenant.creation)
+ [RDS for Oracle CDB での PDB への接続](#Oracle.Concepts.connecting.pdb)
## RDS for Oracle CDB インスタンスの作成
RDS for Oracle では、CDB インスタンスの作成は非 CDB の作成とほとんど同じです。その違いは、DB インスタンスを作成するときに Oracle マルチテナントアーキテクチャを選択し、アーキテクチャ設定 (マルチテナントまたはシングルテナント) を選択することです。マルチテナント設定で CDB を作成するときにタグを作成すると、RDS はそのタグを初期テナントデータベースに伝達します。CDB を作成するには、AWS マネジメントコンソール、AWS CLI、または RDS API を使用します。
### コンソール
**CDB インスタンスを作成するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. Amazon RDS コンソールの右上で、CDB インスタンスを作成する AWS リージョン を選択します。
1. ナビゲーションペインで、[**データベース**] を選択します。
1. [**データベースの作成**] を選択します。
1. [**Choose a database creation method (データベース作成方法を選択)**] で [**Standard Create (スタンダード作成)**] を選択します。
1. [**エンジンのオプション**] で [**Oracle**] を選択します。
1. **[データベース管理のタイプ]** で、**[Amazon RDS]** を選択します。
1. **[アーキテクチャ設定]** では、**[Oracle マルチテナントアーキテクチャ]** を選択します。
1. **[アーキテクチャ設定]** で、次のいずれかを実行します。
+ **[マルチテナント設定]** を選択し、次のステップに進みます。
+ **[シングルテナント設定]** を選択し、ステップ 11 に進みます。
1. (マルチテナント設定) **[テナントデータベース設定]** で、次の変更を行います。
+ **[テナントデータベース名]** には、データベースの名前を入力します。PDB 名は CDB 名 (デフォルトは `RDSCDB`) と異なるものである必要があります。
+ **[テナントデータベースのマスターユーザー名]** には、PDB のマスターユーザー名を入力します。テナントデータベースマスターユーザー名を使用して CDB 自体にログインすることはできません。
+ **[認証情報管理]** では、次のいずれかの認証情報管理オプションを選択します。
+ ** で管理AWS Secrets Manager**
マネージドパスワードは、インスタンス用ではなく、初期テナントデータベース用です。**[暗号化キーを選択]** で、Secrets Manager によって作成される KMS キーと自分で作成したキーのいずれかを選択します。
**注記**
認証情報を管理するための最も安全な手法として、AWS Secrets Manager をお勧めします。別途 料金がかかります。詳細については、「[Amazon RDS および AWS Secrets Manager によるパスワード管理](rds-secrets-manager.md)」を参照してください。
+ **セルフマネージド**
パスワードを指定するには、**[パスワードの自動生成]** チェックボックスが選択されている場合はクリアします。**[マスターパスワード]** と **[マスターパスワードを確認]** に同じパスワードを入力します。
+ **[テナントデータベースの文字セット]** では、PDB の文字セットを選択します。テナントデータベース文字セットとは異なる PDB 文字セットを選択できます。
デフォルトの PDB 文字セットは **AL32UTF8** です。デフォルト以外の PDB 文字セットを選択すると、CDB の作成が遅くなる可能性があります。
**注記**
作成オペレーションで複数のテナントデータベースを指定することはできません。CDB の作成時に PDB が 1 つあります。PDB は、別のオペレーションで既存の CDB に追加できます。
1. (シングルテナント設定) [DB インスタンスの設定](USER_CreateDBInstance.Settings.md) に記載されているオプションに基づいて、必要な設定を選択します。
1. [**設定**] セクションで、[**認証情報の設定**] を開きます。次に、以下の操作を実行します。
1. **[マスターユーザー名]** には、PDB のローカルユーザーの名前を入力します。マスターユーザー名を使用して CDB ルートにログインすることはできません。
1. **[認証情報管理]** では、次のいずれかの認証情報管理オプションを選択します。
+ ** で管理AWS Secrets Manager**
**[暗号化キーを選択]** で、Secrets Manager によって作成される KMS キーと自分で作成したキーのいずれかを選択します。
**注記**
認証情報を管理するための最も安全な手法として、AWS Secrets Manager をお勧めします。別途 料金がかかります。詳細については、「[Amazon RDS および AWS Secrets Manager によるパスワード管理](rds-secrets-manager.md)」を参照してください。
+ **セルフマネージド**
パスワードを指定するには、**[パスワードの自動生成]** チェックボックスが選択されている場合はクリアします。**[マスターパスワード]** と **[マスターパスワードを確認]** に同じパスワードを入力します。
1. 残りのセクションで、DB インスタンス設定を指定します。各設定の詳細については、「[DB インスタンスの設定](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateDBInstance.Settings.html)」を参照してください。
1. **[データベースの作成]** を選択します。
### AWS CLI
マルチテナント設定で CDB を作成するには、以下のパラメータを指定して [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) コマンドを使用します。
+ `--db-instance-identifier`
+ `--db-instance-class`
+ `--engine { oracle-ee-cdb | oracle-se2-cdb }`
+ `--master-username`
+ `--master-user-password`-または-`--manage-master-user-password`
+ `--multi-tenant`(シングルテナント設定の場合は、`multi-tenant` も `--no-multi-tenant` も指定しないでください)
+ `--allocated-storage`
+ `--backup-retention-period`
各設定の詳細については、「[DB インスタンスの設定](USER_CreateDBInstance.Settings.md)」を参照してください。
次の例では、マルチテナント設定で *my-cdb-inst* という名前の RDS for Oracle DB インスタンスを作成します。`--no-multi-tenant` を指定するか `--multi-tenant` を指定しなかった場合、デフォルトの CDB 設定はシングルテナントです。エンジンは、`oracle-ee-cdb`: `oracle-ee` および `--multi-tenant` を指定するとエラーで失敗するコマンドです。初期テナントデータベースの名前は *mypdb* です。
**Example**
Linux、macOS、Unix の場合:
```
1. aws rds create-db-instance \
2. --engine oracle-ee-cdb \
3. --db-instance-identifier my-cdb-inst \
4. --multi-tenant \
5. --db-name mypdb \
6. --allocated-storage 250 \
7. --db-instance-class db.t3.large \
8. --master-username pdb_admin \
9. --manage-master-user-password \
10. --backup-retention-period 3
```
Windows の場合:
```
1. aws rds create-db-instance ^
2. --engine oracle-ee-cdb ^
3. --db-instance-identifier my-cdb-inst ^
4. --multi-tenant ^
5. --db-name mypdb ^
6. --allocated-storage 250 ^
7. --db-instance-class db.t3.large ^
8. --master-username pdb_admin ^
9. --manage-master-user-password \ ^
10. --backup-retention-period 3
```
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
このコマンドでは、次のような出力が生成されます。データベース名、文字セット、各国語文字セット、マスターユーザー、マスターユーザーシークレットは出力に含まれません。この情報は CLI コマンド `describe-tenant-databases` を使用して表示できます。
```
1. {
2. "DBInstance": {
3. "DBInstanceIdentifier": "my-cdb-inst",
4. "DBInstanceClass": "db.t3.large",
5. "MultiTenant": true,
6. "Engine": "oracle-ee-cdb",
7. "DBResourceId": "db-ABCDEFGJIJKLMNOPQRSTUVWXYZ",
8. "DBInstanceStatus": "creating",
9. "AllocatedStorage": 250,
10. "PreferredBackupWindow": "04:59-05:29",
11. "BackupRetentionPeriod": 3,
12. "DBSecurityGroups": [],
13. "VpcSecurityGroups": [
14. {
15. "VpcSecurityGroupId": "sg-0a1bcd2e",
16. "Status": "active"
17. }
18. ],
19. "DBParameterGroups": [
20. {
21. "DBParameterGroupName": "default.oracle-ee-cdb-19",
22. "ParameterApplyStatus": "in-sync"
23. }
24. ],
25. "DBSubnetGroup": {
26. "DBSubnetGroupName": "default",
27. "DBSubnetGroupDescription": "default",
28. "VpcId": "vpc-1234567a",
29. "SubnetGroupStatus": "Complete",
30. ...
```
### RDS API
Amazon RDS API を使用して DB インスタンスを作成するには、[CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) オペレーションを呼び出します。
各設定の詳細については、「[DB インスタンスの設定](USER_CreateDBInstance.Settings.md)」を参照してください。
## RDS for Oracle CDB での PDB への接続
SQL\$1Plus などのユーティリティを使用して PDB に接続できます。SQL\$1Plus のスタンドアロンバージョンを含む Oracle Instant Client をダウンロードするには、[Oracle Instant Client Downloads](https://www.oracle.com/database/technologies/instant-client/downloads.html) を参照してください。
SQL\$1Plus を PDB に接続するには以下の情報が必要です。
+ PDB 名
+ データベースユーザー名とパスワード
+ DB インスタンスのエンドポイント
+ ポート番号
前述の情報を見つける方法については、「[RDS for Oracle DB インスタンスのエンドポイントを見つける](USER_Endpoint.md)」を参照してください。
**Example SQL\$1Plus を使用して PDB に接続するには**
次の例では、*master\$1user\$1name* をマスターユーザーに置き換えてください。また、エンドポイントを DB インスタンスに置き換えて、ポート番号および Oracle SID を含めます。SID 値は DB インスタンスの作成時に指定した PDB の名前であり、DB インスタンス識別子ではありません。
Linux、macOS、Unix の場合:
```
1. sqlplus 'master_user_name@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=endpoint)(PORT=port))(CONNECT_DATA=(SID=pdb_name)))'
```
Windows の場合:
```
1. sqlplus master_user_name@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=endpoint)(PORT=port))(CONNECT_DATA=(SID=pdb_name)))
```
次のような出力が表示されます。
```
SQL*Plus: Release 19.0.0.0.0 Production on Mon Aug 21 09:42:20 2021
```
ユーザーのパスワードを入力すると、SQL プロンプトが表示されます。
```
SQL>
```
**注記**
`sqlplus username/password@LONGER-THAN-63-CHARS-RDS-ENDPOINT-HERE:1521/database-identifier` のような短い形式の接続文字列 (Easy connect または EZCONNECT) は、最大文字数制限に達する可能性があるため、接続には使用しないでください。
# CDB のバックアップと復元
RDS DB スナップショットまたは Recovery Manager (RMAN) を使用して CDB をバックアップおよび復元できます。
## DB スナップショットを使用した CDB のバックアップと復元
DB スナップショットは CDB アーキテクチャでも非 CDB アーキテクチャでも同様に機能します。主な違いは次のとおりです。
+ CDB の DB スナップショットを復元する場合、CDB の名前を変更することはできません。CDB 名は `RDSCDB` であり、変更できません。
+ CDB の DB スナップショットを復元する場合、PDB の名前を変更することはできません。PDB 名は [modify-tenant-database](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyTenantDatabase.html) コマンドを使用して変更できます。
+ スナップショット内のテナントデータベースを検索するには、CLI コマンド [describe-db-snapshot-tenant-databases](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBSnapshotTenantDatabases.html) を使用します。
+ マルチテナントアーキテクチャ設定を使用する CDB スナップショットでは、テナントデータベースを直接操作することはできません。DB スナップショットを復元すると、そのテナントデータベースもすべて復元されます。
+ RDS for Oracle は、テナントデータベースのタグを DB スナップショット内のテナントデータベースに暗黙的にコピーします。テナントデータベースを復元すると、復元されたデータベースにタグが表示されます。
+ DB スナップショットを復元し、`--tags` パラメータを使用して新しいタグを指定すると、新しいタグが既存のすべてのタグを上書きします。
+ タグが付いている CDB インスタンスの DB スナップショットを作成し、`--copy-tags-to-snapshot` を指定すると、RDS for Oracle はテナントデータベースからスナップショット内のテナントデータベースにタグをコピーします。
詳細については、「[Oracle データベースに関する考慮事項](USER_RestoreFromSnapshot.md#USER_RestoreFromSnapshot.Oracle)」を参照してください。
## RMAN を使った CDB のバックアップと復元
RMAN を使用して CDB または個々のテナントデータベースをバックアップおよび復元する方法については、「[Oracle DB インスタンスの一般的な RMAN タスクの実行](Appendix.Oracle.CommonDBATasks.RMAN.md)」を参照してください。
# RDS for Oracle の 非 CDB から CDB への変換
Oracle データベースのアーキテクチャは、非 CDB アーキテクチャから Oracle マルチテナントアーキテクチャ (*CDB アーキテクチャ*とも呼ばれます) に `modify-db-instance` コマンドで変更できます。ほとんどの場合、新しい CDB を作成してデータをインポートするよりも、この手法を使用することをお勧めします。変換操作にはダウンタイムが発生します。
データベースエンジンのバージョンをアップグレードする場合、同じオペレーションでデータベースアーキテクチャを変更することはできません。したがって、Oracle Database 19c 非 CDB を Oracle Database 21c CDB にアップグレードするには、まず 1 つのステップで非 CDB を CDB に変換してから、別のステップで 19c CDB を 21c CDB にアップグレードする必要があります。
非 CDB 変換オペレーションには次の要件があります。
+ DB エンジンタイプに対して `oracle-ee-cdb` または `oracle-se2-cdb` を指定する必要があります。これらの値のみがサポートされています。
+ お使いの DB エンジンが、April 2021 以降のリリースアップデート (RU) で Oracle Database 19c を使用している必要があります。
このオペレーションには次の制約事項があります。
+ CDB を非 CDB に変換することはできません。非 CDB を CDB に変換することしかできません。
+ 非 CDB を 1 回の `modify-db-instance` 呼び出しでマルチテナント設定に変換することはできません。非 CDB を CDB に変換した後、CDB はシングルテナント設定になります。シングルテナント設定をマルチテナント設定に変換するには、`modify-db-instance` をもう一度実行してください。詳細については、「[シングルテナント設定からマルチテナント設定への変換](oracle-single-tenant-converting.md)」を参照してください。
+ Oracle Data Guardが有効になっているプライマリデータベースまたはレプリカデータベースは変換できません。リードレプリカのある非 CDB を変換するには、まずリードレプリカをすべて削除します。
+ 同じオペレーションで DB エンジンのバージョンをアップグレードし、非 CDB を CDB に変換することはできません。
非 CDB を変換する前に、次の点を考慮してください。
+ オプションとパラメータグループの考慮事項は、DB エンジンをアップグレードする場合と同じです。詳細については、「[Oracle のデータベースアップグレードに関する考慮事項](USER_UpgradeDBInstance.Oracle.OGPG.md)」を参照してください。
+ マネージドマスターパスワードを使用する既存の非 CDB インスタンスは、1 回のオペレーションでシングルテナントインスタンスに変換できます。シングルテナントインスタンスはマネージドパスワードを継承します。
+ DB インスタンスに `OEMAGENT` オプションがインストールされている場合は、非 CDB を変換する前にこのオプションを削除することをお勧めします。非 CDB が CDB に変換されたら、オプションを再インストールします。詳細については、「[Enterprise Manager Cloud Control 向け Oracle Management Agent](Oracle.Options.OEMAgent.md)」を参照してください。
+ 変換プロセス中、RDS はオンライン REDO ログサイズをデフォルトの 128M にリセットします。
## コンソール
**非 CDB を CDB に変換するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. Amazon RDS コンソールの右上で、DB インスタンスのある AWS リージョン を選択します。
1. ナビゲーションペインで、**[データベース]** を選択し、CDB インスタンスに変更する 非 CDB インスタンスを選択します。
1. **[Modify]** (変更) を選択します。
1. **[アーキテクチャ設定]** では、**[Oracle マルチテナントアーキテクチャ]** を選択します。変換後、CDB はシングルテナント設定になります。
1. (オプション) **[DB パラメータグループ]** には、CDB インスタンスの新しいパラメータグループを選択します。DB インスタンスを変換するときも、DB インスタンスをアップグレードするときと同じパラメータグループの考慮事項が適用されます。詳細については、「[パラメータグループに関する考慮事項](USER_UpgradeDBInstance.Oracle.OGPG.md#USER_UpgradeDBInstance.Oracle.OGPG.PG)」を参照してください。
1. (オプション) **[オプショングループ]** では、CDB インスタンスの新しいオプショングループを選択します。DB インスタンスを変換するときも、DB インスタンスをアップグレードするときと同じオプショングループの考慮事項が適用されます。詳細については、「[オプショングループに関する考慮事項](USER_UpgradeDBInstance.Oracle.OGPG.md#USER_UpgradeDBInstance.Oracle.OGPG.OG)」を参照してください。
1. (オプション) **[認証情報管理]** では、**[AWS Secrets Manager で管理]** または **[セルフマネージド]** を選択します。詳細については、「[Secrets Manager による DB インスタンスのマスターユーザーパスワードの管理](rds-secrets-manager.md#rds-secrets-manager-db-instance)」を参照してください。
1. すべての変更が正しいことを確認したら、[**Continue**] を選択して変更の概要を確認します。
1. (省略可能) 変更をすぐに適用するには、[**すぐに適用**] を選択します。このオプションを選択すると、ダウンタイムを発生させる場合があります。詳細については、「[スケジュール変更設定の使用](USER_ModifyInstance.ApplyImmediately.md)」を参照してください。
1. 確認ページで、変更内容を確認します。正しい場合は、**[DB インスタンスを変更]** を選択します。
または、[**戻る**] を選択して変更を編集するか、**キャンセル**を選択して変更をキャンセルします。
## AWS CLI
シングルテナント設定で DB インスタンス上の非 CDB を CDB に変換するには、AWS CLI コマンド [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) で `--engine` を `oracle-ee-cdb` または `oracle-se2-cdb` に設定します。詳細については、「[DB インスタンスの設定](USER_ModifyInstance.Settings.md)」を参照してください。
次の例では、*my-non-cdb* という名前の DB インスタンスを変換し、カスタムオプショングループとパラメータグループを指定します。コマンドは、Secrets Manager を使用したパスワード管理も有効にします。
**Example**
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance \
--db-instance-identifier my-non-cdb \
--engine oracle-ee-cdb \
--option-group-name custom-option-group \
--db-parameter-group-name custom-parameter-group \
--manage-master-user-password
```
Windows の場合:
```
aws rds modify-db-instance ^
--db-instance-identifier my-non-cdb ^
--engine oracle-ee-cdb ^
--option-group-name custom-option-group ^
--db-parameter-group-name custom-parameter-group ^
--manage-master-user-password
```
## RDS API
非 CDB を CDB に変換するには、RDS API オペレーション [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) で `Engine` を指定します。
# シングルテナント設定からマルチテナント設定への変換
RDS for Oracle CDB のアーキテクチャは、シングルテナント設定からマルチテナント設定に変更できます。変換前と変換後、CDB には 1 つのテナントデータベース (PDB) が含まれます。DB インスタンスのタグは、変換中に作成された最初のテナントデータベースに伝達されます。
開始する前に、IAM ポリシーにテナントデータベースを作成するアクセス許可があることを確認します。変換中、RDS for Oracle は次のメタデータを新しいテナントデータベースに移行します。
+ マスターユーザー名
+ マネージドマスターパスワード (ソース CDB が Secrets Manager と統合されている場合)
+ データベース名
+ 文字セット
+ 各国語文字セット
変換前に、`describe-db-instances` コマンドを使用して上記の情報を表示します。変換前は、`describe-tenant-database` コマンドを使用して上記の情報を表示できます。
シングルテナントからマルチテナントへの変換には、次の制限事項があります。
+ マルチテナント設定に変換した後、シングルテナント設定に戻すことはできません。この変換は元に戻せません。
+ Oracle Data Guardが有効になっているプライマリデータベースまたはレプリカデータベースは変換できません。
+ 同じオペレーションで DB エンジンのバージョンをアップグレードし、非 CDB を CDB に変換することはできません。
+ 変換中にマネージドマスターユーザーのパスワードを有効化または無効化することはできません。
## コンソール
**シングルテナント設定を使用して CDB をマルチテナント設定に変換するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. Amazon RDS コンソールの右上で、DB インスタンスのある AWS リージョン を選択します。
1. ナビゲーションペインで、**[データベース]** を選択し、CDB インスタンスに変更する 非 CDB インスタンスを選択します。
1. **[Modify]** (変更) を選択します。
1. **[アーキテクチャ設定]** では、**[Oracle マルチテナントアーキテクチャ]** を選択します。
1. **[アーキテクチャ設定]** で、**[マルチテナント設定]** を選択します。
1. (オプション) **[DB パラメータグループ]** には、CDB インスタンスの新しいパラメータグループを選択します。DB インスタンスを変換するときも、DB インスタンスをアップグレードするときと同じパラメータグループの考慮事項が適用されます。
1. (オプション) **[オプショングループ]** では、CDB インスタンスの新しいオプショングループを選択します。DB インスタンスを変換するときも、DB インスタンスをアップグレードするときと同じオプショングループの考慮事項が適用されます。
1. すべての変更が正しいことを確認したら、[**Continue**] を選択して変更の概要を確認します。
1. **[すぐに適用]** を選択します。このオプションは、マルチテナント設定に切り替えるときに必要です。このオプションを選択すると、ダウンタイムを発生させる場合があることに注意してください。
1. 確認ページで、変更内容を確認します。正しい場合は、**[DB インスタンスを変更]** を選択します。
または、[**戻る**] を選択して変更を編集するか、**キャンセル**を選択して変更をキャンセルします。
## AWS CLI
シングルテナント設定を使用して CDB をマルチテナント設定に変換するには、AWS CLI コマンド [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) で `--multi-tenant` を指定します。
次の例では、`my-st-cdb` という名前の DB インスタンスをシングルテナント設定からマルチテナント設定に変換します。`--apply-immediately` オプションは必須です。
**Example**
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance --region us-east-1\
--db-instance-identifier my-st-cdb \
--multi-tenant \
--apply-immediately
```
Windows の場合:
```
aws rds modify-db-instance --region us-east-1 ^
--db-instance-identifier my-st-cdb ^
--multi-tenant ^
--apply-immediately
```
出力は次のようになります。
```
{
"DBInstance": {
"DBInstanceIdentifier": "my-st-cdb",
"DBInstanceClass": "db.r5.large",
"MultiTenant": false,
"Engine": "oracle-ee-cdb",
"DBResourceId": "db-AB1CDE2FGHIJK34LMNOPRLXTXU",
"DBInstanceStatus": "modifying",
"MasterUsername": "admin",
"DBName": "ORCL",
...
"EngineVersion": "19.0.0.0.ru-2022-01.rur-2022-01.r1",
"AutoMinorVersionUpgrade": true,
"ReadReplicaDBInstanceIdentifiers": [],
"LicenseModel": "bring-your-own-license",
"OptionGroupMemberships": [
{
"OptionGroupName": "default:oracle-ee-cdb-19",
"Status": "in-sync"
}
],
...
"PendingModifiedValues": {
"MultiTenant": "true"
}
}
}
```
# RDS for Oracle テナントデータベースを CDB インスタンスに追加する
RDS for Oracle のマルチテナント設定で、テナントデータベースは PDB です。テナントデータベースを追加するには、次の前提条件を満たしていることを確認します。
+ CDB ではマルチテナント設定が有効になっています。詳細については、「[CDB アーキテクチャのマルチテナント設定](Oracle.Concepts.CDBs.md#multi-tenant-configuration)」を参照してください。
+ テナントデータベースを作成するのに必要な IAM アクセス権限があります。
AWS マネジメントコンソール、AWS CLI、または RDS API を使用してテナントデータベースを追加できます。1 回の操作で複数のテナントデータベースを追加することはできません。一度に 1 つずつ追加する必要があります。CDB でバックアップ保持が有効になっている場合、Amazon RDS は新しいテナントデータベースを追加する前後に DB インスタンスをバックアップします。CDB にリードレプリカがある場合は、プライマリ DB インスタンスにのみテナントデータベースを追加できます。Amazon RDS は、レプリカにテナントデータベースを自動的に作成します。レプリケーションの正常性も検証され、テナントが作成される前に、すべてのレプリカが利用可能であり、レプリケーションの遅延が 5 分未満であることが確認されます。
## コンソール
**DB インスタンスにテナントデータベースを追加するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. Amazon RDS コンソールの右上で、テナントデータベースを作成する AWS リージョン を選択します。
1. ナビゲーションペインで、**[Databases]** (データベース) を選択します。
1. テナントデータベースを追加する CDB インスタンスを選択します。DB インスタンスは CDB アーキテクチャのマルチテナント設定を使用する必要があります。
1. **[アクション]** を選択し、**[テナントデータベースを追加]** を選択します。
1. **[テナントデータベース設定]** では、以下の操作を行います。
+ **[テナントデータベース名]** には、新しいデータベースの名前を入力します。
+ **[テナントデータベースのマスターユーザー名]** には、PDB のマスターユーザー名を入力します。
+ 次のいずれかの認証情報管理オプションを選択します。
+ ** で管理AWS Secrets Manager**
**[暗号化キーを選択]** で、Secrets Manager によって作成される KMS キーと自分で作成したキーのいずれかを選択します。
**注記**
認証情報を管理するための最も安全な手法として、AWS Secrets Manager をお勧めします。追加料金が適用されます。AWS Secrets Manager は、リードレプリカを使用するインスタンスではサポートされていません。詳細については、「[Amazon RDS および AWS Secrets Manager によるパスワード管理](rds-secrets-manager.md)」を参照してください。
+ **セルフマネージド**
パスワードを指定するには、**[パスワードの自動生成]** チェックボックスが選択されている場合はクリアします。**[マスターパスワード]** と **[マスターパスワードを確認]** に同じパスワードを入力します。
+ **[追加設定]** で、**[初期データベース名]** に PDB の名前を入力します。デフォルト名の `RDSCDB` がある CDB には名前を付けることはできません。
+ **[テナントデータベースの文字セット]** では、PDB の文字セットを選択します。デフォルトは **AL32UTF8** です。CDB 文字セットとは異なる PDB 文字セットを選択できます。インスタンスにリードレプリカがある場合、カスタム文字セットを使用してテナントを作成することはできません。必要に応じて、リードレプリカを作成する前に、カスタム文字セットを使用してテナントを作成できます。
+ **[テナント全国データベースの文字セット]** では、PDB の全国文字セットを選択します。デフォルトは **AL32UTF8** です。各国文字セットは、`NCHAR` データ型 (`NCHAR`、`NVARCHAR2` および `NCLOB`) を使用する列にのみエンコーディングを指定し、データベースのメタデータには影響しません。
前の設定の詳細については、「[DB インスタンスの設定](USER_CreateDBInstance.Settings.md)」をご参照ください。
1. **[テナントの追加]** を選択します。
## AWS CLI
AWS CLI を使用して CDB にテナントデータベースを追加するには、[create-tenant-database](https://docs.aws.amazon.com/cli/latest/reference/rds/create-tenant-database.html) コマンドを使用し、次の必須パラメータを指定します。
+ `--db-instance-identifier`
+ `--tenant-db-name`
+ `--master-username`
+ `--master-user-password`
次の例では、RDS for Oracle CDB インスタンス *my-cdb-inst* に *mypdb2* という名前のテナントデータベースを作成します。PDB 文字セットは `UTF-16` です。
**Example**
Linux、macOS、Unix の場合:
```
1. aws rds create-tenant-database --region us-east-1 \
2. --db-instance-identifier my-cdb-inst \
3. --tenant-db-name mypdb2 \
4. --master-username mypdb2-admin \
5. --master-user-password mypdb2-pwd \
6. --character-set-name UTF-16
```
Windows の場合:
```
1. aws rds create-tenant-database --region us-east-1 \
2. --db-instance-identifier my-cdb-inst ^
3. --tenant-db-name mypdb2 ^
4. --master-username mypdb2-admin ^
5. --master-user-password mypdb2-pwd ^
6. --character-set-name UTF-16
```
出力は次の例のようになります。
```
...}
"TenantDatabase" :
{
"DbiResourceId" : "db-abc123",
"TenantDatabaseResourceId" : "tdb-bac567",
"TenantDatabaseArn" : "arn:aws:rds:us-east-1:123456789012:db:my-cdb-inst:mypdb2",
"DBInstanceIdentifier" : "my-cdb-inst",
"TenantDBName" : "mypdb2",
"Status" : "creating",
"MasterUsername" : "mypdb2",
"CharacterSetName" : "UTF-16",
...
}
}...
```
# RDS for Oracle テナントデータベースの変更
CDB 内のテナントデータベースは、PDB 名とマスターユーザーパスワードのみを変更できます。次の要件と制限事項に注意してください。
+ DB インスタンス内のテナントデータベースの設定を変更するには、テナントデータベースが存在していなければなりません。
+ 1 回の操作で、複数のテナントデータベースを変更することはできません。一度に変更できるテナントデータベースは 1 つのみです。
+ テナントデータベースの名前を `CDB$ROOT` または `PDB$SEED` に変更することはできません。
+ DB インスタンスにリードレプリカがある場合は、プライマリ DB インスタンスのテナントのみ変更できます。レプリケーションの正常性も検証され、テナントが変更される前にレプリカが利用可能で、レプリケーションの遅延が 5 分未満であることが確認されます。
PDBは、AWS マネジメントコンソール、AWS CLI、または RDS API を使用して変更できます。
## コンソール
**テナントデータベースの PDB 名またはマスターパスワードを変更するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. Amazon RDS コンソールの右上で、テナントデータベースを作成する AWS リージョン を選択します。
1. ナビゲーションペインで、**[Databases]** (データベース) を選択します。
1. データベース名またはマスターユーザーパスワードを変更したいテナントデータベースを選択します。
1. **[Modify]** (変更) を選択します。
1. **[テナントデータベース設定]** では、以下のいずれかの操作を行います。
+ **[テナントデータベース名]** には、新しいデータベースの新しい名前を入力します。
+ **[テナントデータベースのマスターパスワード]** に、新しいパスワードを入力します。
1. **[テナントの変更]** を選択します。
## AWS CLI
AWS CLI を使用してテナントデータベースを変更するには、次のパラメータを指定して [modify-tenant-database](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-tenant-database.html) コマンドを呼び出します。
+ `--db-instance-identifier` *値*
+ `--tenant-db-name value`
+ `[--new-tenant-db-name value]`
+ `[--master-user-password value]`
次の例では、テナントデータベースの名前を DB インスタンス `my-cdb-inst` で `pdb1` から `pdb-hr` に変更します。
**Example**
Linux、macOS、Unix の場合:
```
1. aws rds modify-tenant-database --region us-east-1 \
2. --db-instance-identifier my-cdb-inst \
3. --tenant-db-name pdb1 \
4. --new-tenant-db-name pdb-hr
```
Windows の場合:
```
1. aws rds modify-tenant-database --region us-east-1 ^
2. --db-instance-identifier my-cdb-inst ^
3. --tenant-db-name pdb1 ^
4. --new-tenant-db-name pdb-hr
```
このコマンドでは、次のような出力が生成されます。
```
{
"TenantDatabase" : {
"DbiResourceId" : "db-abc123",
"TenantDatabaseResourceId" : "tdb-bac567",
"TenantDatabaseArn" : "arn:aws:rds:us-east-1:123456789012:db:my-cdb-inst:pdb1",
"DBInstanceIdentifier" : "my-cdb-inst",
"TenantDBName" : "pdb1",
"Status" : "modifying",
"MasterUsername" : "tenant-admin-user"
"Port" : "6555",
"CharacterSetName" : "UTF-16",
"MaxAllocatedStorage" : "1000",
"ParameterGroups": [
{
"ParameterGroupName": "pdb1-params",
"ParameterApplyStatus": "in-sync"
}
],
"OptionGroupMemberships": [
{
"OptionGroupName": "pdb1-options",
"Status": "in-sync"
}
],
"PendingModifiedValues": {
"TenantDBName": "pdb-hr"
}
}
}
```
# RDS for Oracle テナントデータベースを CDB から削除する
AWS マネジメントコンソール、AWS CLI、または RDS API を使用してテナントデータベース (PDB) を削除できます。次の前提条件と制限事項を検討してください。
+ テナントデータベースと DB インスタンスが存在している必要があります。
+ 削除を成功させるには、以下のいずれかの状況が存在している必要があります。
+ テナントデータベースと DB インスタンスが使用可能である。
**注記**
最終スナップショットを作成できますが、`delete-tenant-database` コマンドを発行する前にテナントデータベースと DB インスタンスが使用可能な状態であった場合に限ります。このスナップショットは、DB インスタンスにリードレプリカがある場合にのみ、プライマリインスタンスで作成されます。
+ テナントデータベースを作成しています。
+ DB インスタンスはテナントデータベースを変更しています。
+ DB インスタンスにリードレプリカがある場合、これらの制約はすべてのレプリカに適用されます。
+ 1 回の操作で、複数のテナントデータベースを削除することはできません。
+ CDB 内のテナントが 1 つのみの場合、そのテナントデータベースは削除できません。
+ リードレプリカのテナントデータベースを削除することはできません。プライマリ DB インスタンスのテナントのみを削除できます。レプリケーションの正常性も検証され、テナントが削除される前にレプリケーションの遅延が 5 分未満であることが確認されます。
## コンソール
**テナントデータベースを削除するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、**[データベース]** を選択して、削除するテナントデータベースを選択します。
1. [**アクション**] で、[**削除**] を選択します。
1. DB インスタンスの最終 DB スナップショットを作成するには、[**最終スナップショットを作成しますか?**] を選択します。
1. 最終スナップショットの作成を選択した場合は、[**Final snapshot name (最終スナップショット名)**] を入力します。
1. ボックスに「**delete me**」と入力します。
1. **[削除]** を選択します。
## AWS CLI
AWS CLI を使用してテナントデータベースを削除するには、次のパラメータを指定して [delete-tenant-database](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-tenant-database.html) コマンドを呼び出します。
+ `--db-instance-identifier value`
+ `--tenant-db-name value`
+ `[--skip-final-snapshot | --no-skip-final-snapshot]`
+ `[--final-snapshot-identifier value]`
*次の例では、my-cdb-inst という名前の CDB から *pdb-test* という名前のテナントデータベースを削除します。*デフォルトでは、この操作により最終スナップショットが作成されます。
**Example**
Linux、macOS、Unix の場合:
```
1. aws rds delete-tenant-database --region us-east-1 \
2. --db-instance-identifier my-cdb-inst \
3. --tenant-db-name pdb-test \
4. --final-snapshot-identifier final-snap-pdb-test
```
Windows の場合:
```
1. aws rds delete-tenant-database --region us-east-1 ^
2. --db-instance-identifier my-cdb-inst ^
3. --tenant-db-name pdb-test ^
4. --final-snapshot-identifier final-snap-pdb-test
```
このコマンドでは、次のような出力が生成されます。
```
{
"TenantDatabase" : {
"DbiResourceId" : "db-abc123",
"TenantDatabaseResourceId" : "tdb-bac456",
"TenantDatabaseArn" : "arn:aws:rds:us-east-1:123456789012:db:my-cdb-inst:pdb-test",
"DBInstanceIdentifier" : "my-cdb-inst",
"TenantDBName" : "pdb-test",
"Status" : "deleting",
"MasterUsername" : "pdb-test-admin"
"Port" : "6555",
"CharacterSetName" : "UTF-16",
"MaxAllocatedStorage" : "1000",
"ParameterGroups": [
{
"ParameterGroupName": "tenant-1-params",
"ParameterApplyStatus": "in-sync"
}
],
"OptionGroupMemberships": [
{
"OptionGroupName": "tenant-1-options",
"Status": "in-sync"
}
]
}
}
```
# テナントデータベースの詳細を表示する
テナントデータベースの詳細は、非 CDB や CDB の場合と同じ方法で表示できます。
## コンソール
**テナントデータベースの詳細情報を表示するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. Amazon RDS コンソールの右上で、DB インスタンスのある AWS リージョン を選択します。
1. ナビゲーションペインで、**[Databases]** (データベース) を選択します。
![\[CDB の詳細を表示します。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/cdb-list.png)
上の画像では、唯一のテナントデータベース (PDB) は DB インスタンスの子として表示されています。
1. テナントデータベースの名前を選択します。
![\[PDB の詳細を表示します。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/pdb-details.png)
## AWS CLI
[PDB に関する詳細情報を表示するには、AWS CLI コマンド describe-tenant-databases](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-tenant-databases.html) を使用してください。
次の例では、指定したリージョンのすべてのテナントデータベースについて説明しています。
**Example**
Linux、macOS、Unix の場合:
```
1. aws rds describe-tenant-databases --region us-east-1
```
Windows の場合:
```
1. aws rds describe-tenant-databases --region us-east-1
```
このコマンドでは、次のような出力が生成されます。
```
"TenantDatabases" : [
{
"DBInstanceIdentifier" : "my-cdb-inst",
"TenantDBName" : "pdb-test",
"Status" : "available",
"MasterUsername" : "pdb-test-admin",
"DbiResourceId" : "db-abc123",
"TenantDatabaseResourceId" : "tdb-bac456",
"TenantDatabaseArn" : "arn:aws:rds:us-east-1:123456789012:db:my-cdb-inst:pdb-test",
"CharacterSetName": "AL32UTF8",
"NcharCharacterSetName": "AL16UTF16",
"DeletionProtection": false,
"PendingModifiedValues": {
"MasterUserPassword": "****"
},
"TagList": []
},
{
"DBInstanceIdentifier" : "my-cdb-inst2",
"TenantDBName" : "pdb-dev",
"Status" : "modifying",
"MasterUsername" : "masterrdsuser"
"DbiResourceId" : "db-xyz789",
"TenantDatabaseResourceId" : "tdb-ghp890",
"TenantDatabaseArn" : "arn:aws:rds:us-east-1:123456789012:db:my-cdb-inst2:pdb-dev",
"CharacterSetName": "AL32UTF8",
"NcharCharacterSetName": "AL16UTF16",
"DeletionProtection": false,
"PendingModifiedValues": {
"MasterUserPassword": "****"
},
"TagList": []
},
... other truncated data
```
次の例では、2 番目のリージョンの DB インスタンス `my-cdb-inst` のテナントデータベースについて説明しています。
**Example**
Linux、macOS、Unix の場合:
```
1. aws rds describe-tenant-databases --region us-east-1 \
2. --db-instance-identifier my-cdb-inst
```
Windows の場合:
```
1. aws rds describe-tenant-databases --region us-east-1 ^
2. --db-instance-identifier my-cdb-inst
```
このコマンドでは、次のような出力が生成されます。
```
{
"TenantDatabase": {
"TenantDatabaseCreateTime": "2023-10-19T23:55:30.046Z",
"DBInstanceIdentifier": "my-cdb-inst",
"TenantDBName": "pdb-hr",
"Status": "creating",
"MasterUsername": "tenant-admin-user",
"DbiResourceId": "db-abc123",
"TenantDatabaseResourceId": "tdb-bac567",
"TenantDatabaseARN": "arn:aws:rds:us-west-2:579508833180:pdb-hr:tdb-abcdefghi1jklmno2p3qrst4uvw5xy6zabc7defghi8jklmn90op",
"CharacterSetName": "AL32UTF8",
"NcharCharacterSetName": "AL16UTF16",
"DeletionProtection": false,
"PendingModifiedValues": {
"MasterUserPassword": "****"
},
"TagList": [
{
"Key": "TEST",
"Value": "testValue"
}
]
}
}
```
次の例では、米国東部 (バージニア北部)リージョンの DB インスタンス `pdb1` のテナントデータベースについて説明しています。
**Example**
Linux、macOS、Unix の場合:
```
1. aws rds describe-tenant-databases --region us-east-1 \
2. --db-instance-identifier my-cdb-inst \
3. --tenant-db-name pdb1
```
Windows の場合:
```
1. aws rds describe-tenant-databases --region us-east-1 ^
2. --db-instance-identifier my-cdb-inst ^
3. --tenant-db-name pdb1
```
このコマンドでは、次のような出力が生成されます。
```
{
"TenantDatabases" : [
{
"DbiResourceId" : "db-abc123",
"TenantDatabaseResourceId" : "tdb-bac567",
"TenantDatabaseArn" : "arn:aws:rds:us-east-1:123456789012:db:my-cdb-inst:pdb1"
"DBInstanceIdentifier" : "my-cdb-inst",
"TenantDBName" : "pdb1",
"Status" : "ACTIVE",
"MasterUsername" : "masterawsuser"
"Port" : "1234",
"CharacterSetName": "UTF-8",
"ParameterGroups": [
{
"ParameterGroupName": "tenant-custom-pg",
"ParameterApplyStatus": "in-sync"
}
],
{
"OptionGroupMemberships": [
{
"OptionGroupName": "tenant-custom-og",
"Status": "in-sync"
}
]
}
]
}
```
# CDB のアップグレード
CDB を別の Oracle Database リリースにアップグレードできます。例えば、Oracle Database 19c CDB から Oracle Database 21c CDB にアップグレードできます。アップグレード中にデータベースアーキテクチャを変更することはできません。そのため、非 CDB を CDB にアップグレードしたり、CDB を非 CDB にアップグレードすることはできません。
CDB を CDB にアップグレードする手順は、非 CDB を非 CDB にアップグレードする手順と同じです。詳細については、「[RDS for Oracle DB エンジンのアップグレード](USER_UpgradeDBInstance.Oracle.md)」を参照してください。
# RDS for Oracle DB インスタンスの管理
以下は、RDS for Oracle DB インスタンスで実行する一般的な管理タスクです。一部のタスクは、すべての RDS DB インスタンスで同じです。その他のタスクは、RDS for Oracle に固有です。
次のタスクはすべての RDS データベースに共通ですが、Oracle データベースには特別な考慮事項があります。例えば、Oracle クライアント SQL\$1Plus および SQL Developer を使用して Oracle Database に接続します。
****
| タスク領域 | 関連資料 |
| --- | --- |
| **インスタンスクラス、ストレージ、PIOPS** 本稼働インスタンスを作成する場合は、Amazon RDS でインスタンスクラス、ストレージタイプ、プロビジョンド IOPS がどのように機能するかを学習します。 | [RDS for Oracle DB インスタンスクラス](Oracle.Concepts.InstanceClasses.md) [Amazon RDS ストレージタイプ](CHAP_Storage.md#Concepts.Storage) |
| **マルチ AZ 配置** 本稼働 DB インスタンスは、マルチ AZ 配置を使用する必要があります。マルチ AZ 配置は、DB インスタンスの拡張された可用性、データ堅牢性、および耐障害性を提供します。 | [Amazon RDS でのマルチ AZ 配置の設定と管理](Concepts.MultiAZ.md) |
| ** Amazon VPC** AWS アカウントにデフォルト 仮想プライベートクラウド (VPC) がある場合、DB インスタンスがデフォルト (VPC) 内に自動的に作成されます。アカウントにデフォルト VPC がなく、DB インスタンスを VPC に作成する必要がある場合は、インスタンスを作成する前に VPC とサブネットグループを作成する場合があります。 | [VPC 内の DB インスタンスの使用](USER_VPC.WorkingWithRDSInstanceinaVPC.md) |
| **セキュリティグループ**: デフォルトでは、DB インスタンスはアクセスを防止するファイアウォールを使用します。DB インスタンスにアクセスするために、正しい IP アドレスとネットワーク構成を備えたセキュリティグループを作成する必要があります。 | [セキュリティグループによるアクセス制御](Overview.RDSSecurityGroups.md) |
| **パラメータグループ** DB インスタンスに特定のデータベースパラメータが必要になる場合は、DB インスタンスを作成する前にパラメータグループを作成します。 | [Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md) |
| **オプショングループ** DB インスタンスに特定のデータベースオプションが必要になる場合は、DB インスタンスを作成する前にオプショングループを作成します。 | [Oracle DB インスタンスへのオプションの追加](Appendix.Oracle.Options.md) |
| **DB インスタンスへの接続** セキュリティグループを作成し、それを DB インスタンスに関連付けると、Oracle SQL \$1Plus などのスタンダード的な SQL クライアントアプリケーションを使用して DB インスタンスに接続できます。 | [Oracle DB インスタンスへの接続](USER_ConnectToOracleInstance.md) |
| **バックアップと復元** バックアップが自動的に作成されるように DB インスタンスを設定したり、スナップショットを手動で作成したりできます。そうすることで後で、そのバックアップまたはスナップショットからインスタンスを復元できます。 | [データのバックアップ、復元、エクスポート](CHAP_CommonTasks.BackupRestore.md) |
| **モニタリング** CloudWatch Amazon RDS メトリクス、イベント、および拡張モニタリングを使用することで、Oracle DB インスタンスをモニタリングできます。 | [Amazon RDS コンソールでのメトリクスの表示](USER_Monitoring.md) [Amazon RDS イベントの表示](USER_ListEvents.md) |
| **ログファイル** Oracle DB インスタンスのログファイルにアクセスできます。 | [Amazon RDS ログファイルのモニタリング](USER_LogAccess.md) |
以下では、RDS Oracle 共通の DBA タスクでの、Amazon RDS 専用の実装に関する説明を行います。マネージドサービスエクスペリエンスを提供するうえで、Amazon RDS は DB インスタンスへのシェルアクセスを提供していません。また、RDS では、アドバンストの特権を必要とする特定のシステムの手順やテーブルへのアクセスも制限しています。多くのタスクでは、データベースの管理のための Amazon RDS 専用のツールとして、`rdsadmin` パッケージを実行します。
Oracle を実行する DB インスタンスのための一般的な DBA タスクを次に示します。
+ [システムタスク](Appendix.Oracle.CommonDBATasks.System.md)
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.html)
+ [データベースタスク](Appendix.Oracle.CommonDBATasks.Database.md)
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.html)
+ [ログタスク](Appendix.Oracle.CommonDBATasks.Log.md)
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.html)
+ [RMAN タスク](Appendix.Oracle.CommonDBATasks.RMAN.md)
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.html)
+ [Oracle Scheduler タスク](Appendix.Oracle.CommonDBATasks.Scheduler.md)
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.html)
+ [問題の診断](Appendix.Oracle.CommonDBATasks.Diagnostics.md)
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.html)
+ [その他のタスク](Appendix.Oracle.CommonDBATasks.Misc.md)
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.html)
Oracle との Amazon S3 統合および、OEM Management Agent データベースタスクを実行するため Amazon RDS の手順を使用することも可能です。詳細については、「[「Amazon S3 統合」](oracle-s3-integration.md)」および「[Management Agent を使用したデータベースタスクの実行](Oracle.Options.OEMAgent.md#Oracle.Options.OEMAgent.DBTasks)」を参照してください。
# Oracle DB インスタンスの一般的なシステムタスクの実行
次に、Oracle を実行している Amazon RDS DB インスタンスで、システムに関連する特定の一般的な DBA タスクを実行する方法を示します。マネージド型サービスの操作性を実現するために、Amazon RDS では DB インスタンスへのシェルアクセスは提供していません。また、上位の権限を必要とする特定のシステムプロシージャやシステムテーブルへのアクセスが制限されます。
**Topics**
+ [セッションの切断](Appendix.Oracle.CommonDBATasks.DisconnectingSession.md)
+ [セッションの終了](Appendix.Oracle.CommonDBATasks.KillingSession.md)
+ [セッションでの SQL ステートメントのキャンセル](Appendix.Oracle.CommonDBATasks.CancellingSQL.md)
+ [制限セッションの有効化と無効化](Appendix.Oracle.CommonDBATasks.RestrictedSession.md)
+ [共有プールのフラッシュ](Appendix.Oracle.CommonDBATasks.FlushingSharedPool.md)
+ [SYS オブジェクトへの SELECT または EXECUTE 権限の付与](Appendix.Oracle.CommonDBATasks.TransferPrivileges.md)
+ [SYS オブジェクトに対する SELECT または EXECUTE 権限の取り消し](Appendix.Oracle.CommonDBATasks.RevokePrivileges.md)
+ [Oracle DB インスタンスの RDS\$1X\$1 ビューの管理](Appendix.Oracle.CommonDBATasks.X-dollar.md)
+ [非マスターユーザーへの権限の付与](Appendix.Oracle.CommonDBATasks.PermissionsNonMasters.md)
+ [パスワードを検証するためのカスタム関数の作成](Appendix.Oracle.CommonDBATasks.CustomPassword.md)
+ [カスタム DNS サーバーのセットアップ](#Appendix.Oracle.CommonDBATasks.CustomDNS)
+ [システム診断イベントの設定と設定の解除](Appendix.Oracle.CommonDBATasks.SystemEvents.md)
# セッションの切断
専用サーバープロセスを終了して現在のセッションを切断するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.disconnect` を使用します。`disconnect` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `sid` | number | — | はい | セッション識別子。 |
| `serial` | number | — | はい | セッションのシリアル番号。 |
| `method` | varchar | '即時' | いいえ | 有効な値は `'IMMEDIATE'` または `'POST_TRANSACTION'` です。 |
次の例では、セッションを切断します。
```
begin
rdsadmin.rdsadmin_util.disconnect(
sid => sid,
serial => serial_number);
end;
/
```
セッション識別子とセッションのシリアル番号を取得するには、`V$SESSION` ビューを照会します。次の例では、ユーザー `AWSUSER` のすべてのセッションを取得します。
```
SELECT SID, SERIAL#, STATUS FROM V$SESSION WHERE USERNAME = 'AWSUSER';
```
このメソッドを使用するにはデータベースが開いている必要があります。セッションの切断の詳細については、Oracle ドキュメントの「[ALTER SYSTEM](http://docs.oracle.com/cd/E11882_01/server.112/e41084/statements_2014.htm#SQLRF53166)」を参照してください。
# セッションの終了
セッションを終了するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.kill` を使用します。`kill` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `sid` | number | — | はい | セッション識別子。 |
| `serial` | number | — | はい | セッションのシリアル番号。 |
| `method` | varchar | null | いいえ | 有効な値は `'IMMEDIATE'` または `'PROCESS'` です。`IMMEDIATE` を指定した場合、次のステートメントを実行した場合と同じ結果になります。 ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE
`PROCESS` を指定した場合、セッションに関連付けられたプロセスを終了します。`IMMEDIATE` を使用したセッションの終了に失敗した場合のみ、`PROCESS` を指定してください。 |
セッション識別子とセッションのシリアル番号を取得するには、`V$SESSION` ビューを照会します。次の例では、ユーザー *AWSUSER* のすべてのセッションを取得します。
```
SELECT SID, SERIAL#, STATUS FROM V$SESSION WHERE USERNAME = 'AWSUSER';
```
次の例では、セッションを終了します。
```
BEGIN
rdsadmin.rdsadmin_util.kill(
sid => sid,
serial => serial_number,
method => 'IMMEDIATE');
END;
/
```
次の例では、セッションに関連付けられたプロセスを終了します。
```
BEGIN
rdsadmin.rdsadmin_util.kill(
sid => sid,
serial => serial_number,
method => 'PROCESS');
END;
/
```
# セッションでの SQL ステートメントのキャンセル
セッション内の SQL ステートメントをキャンセルするには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.cancel` を使用します。
**注記**
この手順は Oracle Database 19c (19.0.0)、および RDS for Oracle のすべての上位メジャーバージョンおよびマイナーバージョンでサポートされています。
`cancel` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `sid` | number | — | はい | セッション識別子。 |
| `serial` | number | — | はい | セッションのシリアル番号。 |
| `sql_id` | varchar2 | null | いいえ | SQL ステートメントの SQL 識別子。 |
次の例では、セッション内の SQL ステートメントをキャンセルします。
```
begin
rdsadmin.rdsadmin_util.cancel(
sid => sid,
serial => serial_number,
sql_id => sql_id);
end;
/
```
セッション識別子、セッションのシリアル番号、および SQL ステートメントの SQL 識別子を取得するには、`V$SESSION` ビューを照会します。次の例では、ユーザー `AWSUSER` のすべてのセッションと SQL 識別子を取得します。
```
select SID, SERIAL#, SQL_ID, STATUS from V$SESSION where USERNAME = 'AWSUSER';
```
# 制限セッションの有効化と無効化
制限セッションを有効または無効にするには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.restricted_session` を使用します。`restricted_session` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | はい | 説明 |
| --- | --- | --- | --- | --- |
| `p_enable` | boolean | true | いいえ | 制限セッションを有効にするには `true`、制限セッションを無効にするには `false` に設定します。 |
次の例では、制限セッションを有効化および無効化する方法を示します。
```
/* Verify that the database is currently unrestricted. */
SELECT LOGINS FROM V$INSTANCE;
LOGINS
-------
ALLOWED
/* Enable restricted sessions */
EXEC rdsadmin.rdsadmin_util.restricted_session(p_enable => true);
/* Verify that the database is now restricted. */
SELECT LOGINS FROM V$INSTANCE;
LOGINS
----------
RESTRICTED
/* Disable restricted sessions */
EXEC rdsadmin.rdsadmin_util.restricted_session(p_enable => false);
/* Verify that the database is now unrestricted again. */
SELECT LOGINS FROM V$INSTANCE;
LOGINS
-------
ALLOWED
```
# 共有プールのフラッシュ
共用プールをフラッシュするには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.flush_shared_pool` を使用します。`flush_shared_pool` プロシージャにはパラメータはありません。
次の例では、共有プールをフラッシュします。
```
EXEC rdsadmin.rdsadmin_util.flush_shared_pool;
```
## バッファキャッシュのフラッシュ
バッファキャッシュをフラッシュするには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.flush_buffer_cache` を使用します。`flush_buffer_cache` プロシージャにはパラメータはありません。
次の例では、バッファキャッシュをフラッシュします。
```
EXEC rdsadmin.rdsadmin_util.flush_buffer_cache;
```
## データベースのスマートフラッシュキャッシュのフラッシュ
データベースのスマートフラッシュキャッシュをフラッシュするには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.flush_flash_cache` を使用します。`flush_flash_cache` プロシージャにはパラメータはありません。次の例では、データベースのスマートフラッシュキャッシュをフラッシュします。
```
EXEC rdsadmin.rdsadmin_util.flush_flash_cache;
```
RDS for Oracle でのデータベーススマートフラッシュキャッシュの使用に関する詳細は、「[RDS for Oracle インスタンスストアへの一時データの保存](CHAP_Oracle.advanced-features.instance-store.md)」を参照してください。
# SYS オブジェクトへの SELECT または EXECUTE 権限の付与
通常多くのオブジェクトを含めることができるロールを使用して権限を転送します。1 つのオブジェクトへ権限を付与するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.grant_sys_object` を使用します。このプロシージャは、ロールまたは直接付与によってマスターユーザーに既に付与されている権限のみを付与します。
`grant_sys_object` プロシージャには以下のパラメータがあります。
**重要**
大文字と小文字を区別する識別子を使用してユーザーを作成した場合を除き、すべてのパラメータ値に大文字を使用します。例えば、`CREATE USER myuser` または `CREATE USER MYUSER` を実行すると、データディクショナリに `MYUSER` が保存されます。ただし、`CREATE USER "MyUser"` で二重引用符を使用すると、データディクショナリには `MyUser` が保存されます。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_obj_name` | varchar2 | — | はい | 権限を付与する元のオブジェクトの名前。オブジェクトとして、ディレクトリ、ファンクション、パッケージ、プロシージャ、シーケンス、テーブル、またはビューを指定できます。オブジェクト名のスペルは `DBA_OBJECTS` に表示されているとおりに正確に入力する必要があります。ほとんどのシステムオブジェクトが大文字で定義されるため、初めにこれを試すことをお勧めします。 |
| `p_grantee` | varchar2 | — | はい | 権限を付与する先のオブジェクトの名前。オブジェクトとして、スキーマまたはロールを指定できます。 |
| `p_privilege` | varchar2 | null | はい | — |
| `p_grant_option` | boolean | false | いいえ | 付与オプションで使用するには、`true` に設定します。 |
次の例では、オブジェクト `V_$SESSION` に対する選択権限をユーザー `USER1` に付与します。
```
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'V_$SESSION',
p_grantee => 'USER1',
p_privilege => 'SELECT');
end;
/
```
次の例では、付与オプションを使用して、オブジェクト `V_$SESSION` に対する選択権限をユーザー `USER1` に付与します。
```
begin
rdsadmin.rdsadmin_util.grant_sys_object(
p_obj_name => 'V_$SESSION',
p_grantee => 'USER1',
p_privilege => 'SELECT',
p_grant_option => true);
end;
/
```
オブジェクトに対して権限を付与するには、付与オプションまたは `with admin option` を使用して付与されたロールを通じてアカウントにこれらの権限が直接付与されている必要があります。最も一般的なケースとして、`SELECT` ロールに付与された DBA ビューでの `SELECT_CATALOG_ROLE` 権限の付与があります。このロールが `with admin option` を通じてユーザーにまだ直接付与されていない場合、権限を転送することはできません。DBA 権限がある場合は、そのロールを他のユーザーに直接付与できます。
次の例では、`SELECT_CATALOG_ROLE` と `EXECUTE_CATALOG_ROLE` を `USER1` に付与します。`with admin option` が使用されているため、`USER1` は、`SELECT_CATALOG_ROLE` に許可された SYS オブジェクトへのアクセスを許可できるようになりました。
```
GRANT SELECT_CATALOG_ROLE TO USER1 WITH ADMIN OPTION;
GRANT EXECUTE_CATALOG_ROLE to USER1 WITH ADMIN OPTION;
```
既に `PUBLIC` として許可されたオブジェクトへのアクセスは再許可する必要はありません。`grant_sys_object` プロシージャを使用してアクセスを再許可すると、プロシージャの呼び出しは成功します。
# SYS オブジェクトに対する SELECT または EXECUTE 権限の取り消し
1 つのオブジェクトに対する権限を取り消すには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.revoke_sys_object` を使用します。このプロシージャは、ロールまたは直接付与によってマスターアカウントに既に付与されている権限のみを取り消します。
`revoke_sys_object` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_obj_name` | varchar2 | — | はい | 権限を取り消す対象のオブジェクトの名前。オブジェクトとして、ディレクトリ、ファンクション、パッケージ、プロシージャ、シーケンス、テーブル、またはビューを指定できます。オブジェクト名のスペルは `DBA_OBJECTS` に表示されているとおりに正確に入力する必要があります。ほとんどのシステムオブジェクトが大文字で定義されるため、初めにこれを試すことをお勧めします。 |
| `p_revokee` | varchar2 | — | はい | 権限を取り消す対象のオブジェクトの名前。オブジェクトとして、スキーマまたはロールを指定できます。 |
| `p_privilege` | varchar2 | null | はい | — |
次の例では、オブジェクト `V_$SESSION` に対する選択権限をユーザー `USER1` から取り消します。
```
begin
rdsadmin.rdsadmin_util.revoke_sys_object(
p_obj_name => 'V_$SESSION',
p_revokee => 'USER1',
p_privilege => 'SELECT');
end;
/
```
# Oracle DB インスタンスの RDS\$1X\$1 ビューの管理
`SYS` によってのみアクセス可能な `SYS.X$` 固定テーブルへのアクセスが必要になる場合があります。対象の `X$` テーブルに `SYS.RDS_X$` ビューを作成するには、`rdsadmin.rdsadmin_util` パッケージの手順を使用します。マスターユーザーには、`RDS_X$` ビューに対する `SELECT … WITH GRANT OPTION` 権限が自動的に付与されます。
この `rdsadmin.rdsadmin_util` 手順は、以下の場合に利用できます。
+ まだアップグレードされたことがなく、以下のリリースを使用している既存の DB インスタンス:
+ `21.0.0.0.ru-2023-10.rur-2023-10.r1` 以降の 21c リリース
+ `19.0.0.0.ru-2023-10.rur-2023-10.r1` 以降の 19c リリース
+ 作成した新しい DB インスタンス
+ アップグレードした既存の DB インスタンス
**重要**
内部的には、`rdsadmin.rdsadmin_util` パッケージは `X$` テーブルにビューを作成します。`X$` テーブルは内部システムオブジェクトであり、Oracle Database のドキュメントでは説明されていません。本番用以外のデータベースで特定のビューをテストし、Oracle サポートのガイダンスに従って、本番用のデータベースにのみビューを作成することをお勧めしています。
## RDS\$1X\$1 ビューで使用できる X\$1 固定テーブルを一覧表示する
`RDS_X$` ビューで使用できる X\$1 テーブルを一覧表示するには、RDS プロシージャ `rdsadmin.rdsadmin_util.list_allowed_sys_x$_views` を使用します。この手順はパラメータを受け付けません。次のステートメントは、対象となるすべての `X$` テーブル (サンプル出力を含む) を一覧表示します。
```
SQL> SET SERVEROUTPUT ON
SQL> SELECT * FROM TABLE(rdsadmin.rdsadmin_util.list_allowed_sys_x$_views);
'X$BH'
'X$K2GTE'
'X$KCBWBPD'
'X$KCBWDS'
'X$KGLLK'
'X$KGLOB'
'X$KGLPN'
'X$KSLHOT'
'X$KSMSP'
'X$KSPPCV'
'X$KSPPI'
'X$KSPPSV'
'X$KSQEQ'
'X$KSQRS'
'X$KTUXE'
'X$KQRFP'
```
対象となる `X$` テーブルの一覧は、時間の経過とともに変化する可能性があります。対象となる `X$` 固定テーブルのリストが最新であることを確認するには、定期的に `list_allowed_sys_x$_views` を再実行してください。
## SYS.RDS\$1X\$1 ビューの作成
対象となる `X$` テーブルに `RDS_X$` ビューを作成するには、RDS プロシージャ `rdsadmin.rdsadmin_util.create_sys_x$_view` を使用します。`rdsadmin.rdsadmin_util.list_allowed_sys_x$_views` の出力に一覧表示されているテーブルのビューのみを作成できます。`create_sys_x$_view` 手順は、次のパラメータを受け付けます。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_x$_tbl` | varchar2 | Null | はい | 有効な `X$` テーブル名。値は、`list_allowed_sys_x$_views` によって報告される `X$` テーブルの 1 つである必要があります。 |
| `p_force_creation` | ブール値 | FALSE | いいえ | `X$` テーブルに既に存在する `RDS_X$` ビューを強制的に作成するかどうかを示す値。デフォルトでは、ビューが既に存在する場合、RDS はビューを作成しません。強制的に作成するには、このパラメータを `TRUE` に設定します。 |
次の例では、テーブル `X$KGLOB` で `SYS.RDS_X$KGLOB` ビューを作成します。ビュー名の形式は `RDS_X$tablename` です。
```
SQL> SET SERVEROUTPUT ON
SQL> EXEC rdsadmin.rdsadmin_util.create_sys_x$_view('X$KGLOB');
PL/SQL procedure successfully completed.
```
次のデータディクショナリクエリは、ビュー `SYS.RDS_X$KGLOB` とそのステータスを表示します。マスターユーザーには、このビューに対する `SELECT ... WITH GRANT OPTION` 権限が自動的に付与されます。
```
SQL> SET SERVEROUTPUT ON
SQL> COL OWNER FORMAT A30
SQL> COL OBJECT_NAME FORMAT A30
SQL> COL STATUS FORMAT A30
SQL> SET LINESIZE 200
SQL> SELECT OWNER, OBJECT_NAME, STATUS
FROM DBA_OBJECTS
WHERE OWNER = 'SYS' AND OBJECT_NAME = 'RDS_X$KGLOB';
OWNER OBJECT_NAME STATUS
------------------------------ ------------------------------ ------------------------------
SYS RDS_X$KGLOB VALID
```
**重要**
`X$` テーブルは、アップグレード前とアップグレード後で同じままである保証はありません。RDS for Oracle は、エンジンのアップグレード中に `X$` テーブルで `RDS_X$` ビューを削除して再作成します。次に、マスターユーザーに `SELECT ... WITH GRANT OPTION` 権限を付与します。アップグレード後、必要に応じて対応する `RDS_X$` ビューでデータベースユーザーに権限を付与します。
## SYS.RDS\$1X\$1 ビューの一覧表示
既存の `RDS_X$` ビューを一覧表示するには、RDS プロシージャ `rdsadmin.rdsadmin_util.list_created_sys_x$_views` を使用します。このプロシージャでは、プロシージャ `create_sys_x$_view` によって作成されたビューのみが一覧表示されます。次の例では、対応する `RDS_X$` ビュー (サンプル出力を含む) を持つ `X$` テーブルを一覧表示します。
```
SQL> SET SERVEROUTPUT ON
SQL> COL XD_TBL_NAME FORMAT A30
SQL> COL STATUS FORMAT A30
SQL> SET LINESIZE 200
SQL> SELECT * FROM TABLE(rdsadmin.rdsadmin_util.list_created_sys_x$_views);
XD_TBL_NAME STATUS
------------------------------ ------------------------------
X$BH VALID
X$K2GTE VALID
X$KCBWBPD VALID
3 rows selected.
```
## RDS\$1X\$1 ビューの削除
`SYS.RDS_X$` ビューを削除するには、RDS プロシージャ `rdsadmin.rdsadmin_util.drop_sys_x$_view` を使用します。`rdsadmin.rdsadmin_util.list_allowed_sys_x$_views` の出力に一覧表示されているビューだけを削除できます。`drop_sys_x$_view` 手順は、次のパラメータを受け付けます。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_x$_tbl` | varchar2 | Null | はい | 有効な `X$` 固定テーブル名。この値は、`list_created_sys_x$_views` によって報告される `X$` 固定テーブルの 1 つである必要があります。 |
次の例では、テーブル `X$KGLOB` で作成された `RDS_X$KGLOB` ビューを削除します。
```
SQL> SET SERVEROUTPUT ON
SQL> EXEC rdsadmin.rdsadmin_util.drop_sys_x$_view('X$KGLOB');
PL/SQL procedure successfully completed.
```
次の例は、ビュー `SYS.RDS_X$KGLOB` が削除されたことを示しています (サンプル出力を含む)。
```
SQL> SET SERVEROUTPUT ON
SQL> COL OWNER FORMAT A30
SQL> COL OBJECT_NAME FORMAT A30
SQL> COL STATUS FORMAT A30
SQL> SET LINESIZE 200
SQL> SELECT OWNER, OBJECT_NAME, STATUS
FROM DBA_OBJECTS
WHERE OWNER = 'SYS' AND OBJECT_NAME = 'RDS_X$KGLOB';
no rows selected
```
# 非マスターユーザーへの権限の付与
`SYS` ロールを使用すると、`SELECT_CATALOG_ROLE` スキーマ内の多くのオブジェクトに対する選択権限を付与できます。`SELECT_CATALOG_ROLE` ロールは、データディクショナリビューに対する `SELECT` 権限をユーザーに付与します。次の例では、ユーザー `SELECT_CATALOG_ROLE` にロール `user1` を付与します。
```
GRANT SELECT_CATALOG_ROLE TO user1;
```
`EXECUTE` ロールを使用すると、`SYS` スキーマ内の多くのオブジェクトに対する `EXECUTE_CATALOG_ROLE` 権限を付与できます。`EXECUTE_CATALOG_ROLE` ロールは、データディクショナリのパッケージとプロシージャに対する `EXECUTE` 権限をユーザーに付与します。次の例では、ユーザー *user1* にロール `EXECUTE_CATALOG_ROLE` を付与します。
```
GRANT EXECUTE_CATALOG_ROLE TO user1;
```
次の例では、ロール `SELECT_CATALOG_ROLE` とロール `EXECUTE_CATALOG_ROLE` が許可するアクセス権限を取得します。
```
SELECT *
FROM ROLE_TAB_PRIVS
WHERE ROLE IN ('SELECT_CATALOG_ROLE','EXECUTE_CATALOG_ROLE')
ORDER BY ROLE, TABLE_NAME ASC;
```
次の例では、非マスターユーザー `user1` を作成し、`CREATE SESSION` 権限を付与します。また、データベース *sh.sales* に対する `SELECT` 権限を付与します。
```
CREATE USER user1 IDENTIFIED BY PASSWORD;
GRANT CREATE SESSION TO user1;
GRANT SELECT ON sh.sales TO user1;
```
# パスワードを検証するためのカスタム関数の作成
カスタムパスワード検証関数は、以下の方法で作成できます。
+ スタンダード検証ロジックを使用するには、また `SYS` スキーマに関数を格納するには、`create_verify_function` の手順を使用します。
+ カスタム検証ロジックを使用するには、または `SYS` スキーマに関数を格納しないようにするには、`create_passthrough_verify_fcn` の手順を使用します。
# create\$1verify\$1function プロシージャ
Amazon RDS プロシージャ `rdsadmin.rdsadmin_password_verify.create_verify_function` を使用してパスワードを検証するには、カスタム関数を作成できます。`create_verify_function` プロシージャは、RDS for Oracle のすべてのバージョンでサポートされています。
`create_verify_function` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_verify_function_name` | varchar2 | — | はい | カスタム関数の名前。この関数は、SYS スキーマに作成されます。この関数をユーザープロファイルに割り当てます。 |
| `p_min_length` | number | 8 | いいえ | 必要な文字の最小数。 |
| `p_max_length` | number | 256 | いいえ | 許容された文字の最大数。 |
| `p_min_letters` | number | 1 | いいえ | 必要な文字の最小数。 |
| `p_min_uppercase` | number | 0 | いいえ | 必要な大文字の最小数。 |
| `p_min_lowercase` | number | 0 | いいえ | 必要な小文字の最小数。 |
| `p_min_digits` | number | 1 | いいえ | 必要な数字の最小数。 |
| `p_min_special` | number | 0 | いいえ | 必要な特殊文字の最小数。 |
| `p_min_different_chars` | number | 3 | いいえ | 古いパスワードと新しいパスワードの間で必要な異なる文字の最小数。 |
| `p_disallow_username` | boolean | true | いいえ | パスワードでユーザー名を禁止するには、`true` に設定します。 |
| `p_disallow_reverse` | boolean | true | いいえ | パスワードで反転したユーザー名を禁止するには、`true` に設定します。 |
| `p_disallow_db_name` | boolean | true | いいえ | パスワードでデータベースまたはサーバー名を禁止するには、`true` に設定します。 |
| `p_disallow_simple_strings` | boolean | true | いいえ | パスワードで単純な文字列を禁止するには、`true` に設定します。 |
| `p_disallow_whitespace` | boolean | false | いいえ | パスワードで空白文字を禁止するには、`true` に設定します。 |
| `p_disallow_at_sign` | boolean | false | いいえ | パスワードで「@」文字の使用を禁止するには、`true` に設定します。 |
複数のパスワード検証関数を作成できます。
カスタム関数名に制限があります。カスタム関数名を既存のシステムオブジェクト名と同じにすることはできません。30 文字を超える名前は使用できません。また、名前には文字列として `PASSWORD`、`VERIFY`、`COMPLEXITY`、`ENFORCE`、`STRENGTH` のいずれかを含める必要があります。
次の例では、`CUSTOM_PASSWORD_FUNCTION` という名前の関数を作成します。この関数のパスワードは、最低で 2 つの大文字、1 つの数字、1 つの特殊文字を含む、12 文字以上で構成する必要があります。また、「@」文字は使用できません。
```
begin
rdsadmin.rdsadmin_password_verify.create_verify_function(
p_verify_function_name => 'CUSTOM_PASSWORD_FUNCTION',
p_min_length => 12,
p_min_uppercase => 2,
p_min_digits => 1,
p_min_special => 1,
p_disallow_at_sign => true);
end;
/
```
検証関数のテキストを表示するには、`DBA_SOURCE` を照会します。次の例では、カスタムパスワード関数 `CUSTOM_PASSWORD_FUNCTION` のテキストを取得します。
```
COL TEXT FORMAT a150
SELECT TEXT
FROM DBA_SOURCE
WHERE OWNER = 'SYS'
AND NAME = 'CUSTOM_PASSWORD_FUNCTION'
ORDER BY LINE;
```
検証関数をユーザープロファイルに関連付けるには、`ALTER PROFILE` を使用します。次の例では、`CUSTOM_PASSWORD_FUNCTION` という名前の検証 PL/SQL 関数を `DEFAULT` ユーザープロファイルに関連付けます。`PASSWORD_VERIFY_FUNCTION` は Oracle プロファイルリソース名です。
```
ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION CUSTOM_PASSWORD_FUNCTION;
```
どのユーザープロファイルがどの照合機能に関連付けられているかを確認するには、`DBA_PROFILES` を照会します。次の例では、カスタム検証関数 `CUSTOM_PASSWORD_FUNCTION` に関連付けられたプロファイルを取得します。
```
SELECT * FROM DBA_PROFILES WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION' AND LIMIT = 'CUSTOM_PASSWORD_FUNCTION';
PROFILE RESOURCE_NAME RESOURCE LIMIT
------------------------- -------------------------------- -------- ------------------------
DEFAULT PASSWORD_VERIFY_FUNCTION PASSWORD CUSTOM_PASSWORD_FUNCTION
```
次の例では、すべてのプロシージャとそれらに関連付けられたパスワード検証関数を取得します。
```
SELECT * FROM DBA_PROFILES WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION';
PROFILE RESOURCE_NAME RESOURCE LIMIT
------------------------- -------------------------------- -------- ------------------------
DEFAULT PASSWORD_VERIFY_FUNCTION PASSWORD CUSTOM_PASSWORD_FUNCTION
RDSADMIN PASSWORD_VERIFY_FUNCTION PASSWORD NULL
```
# create\$1passthrough\$1verify\$1fcn プロシージャ
`create_passthrough_verify_fcn` プロシージャは、RDS for Oracle のすべてのバージョンでサポートされています。
Amazon RDS 手順 `rdsadmin.rdsadmin_password_verify.create_passthrough_verify_fcn` を使用してパスワードを検証するには、カスタム関数を作成できます。`create_passthrough_verify_fcn` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_verify_function_name` | varchar2 | — | はい | カスタム検証関数の名前。これは、SYS 関数で作成されるラッパー関数です。検証ロジックは含まれていません。この関数をユーザープロファイルに割り当てます。 |
| `p_target_owner` | varchar2 | — | はい | カスタム検証関数のスキーマ所有者。 |
| `p_target_function_name` | varchar2 | — | はい | 検証ロジックを含む既存のカスタム関数の名前。カスタム関数はブール値を返します。パスワードが有効の場合は `true`、無効の場合は `false` が関数より返ります。 |
次の例では、`PASSWORD_LOGIC_EXTRA_STRONG` という名前の関数のロジックを使用するパスワード検証関数を作成します。
```
begin
rdsadmin.rdsadmin_password_verify.create_passthrough_verify_fcn(
p_verify_function_name => 'CUSTOM_PASSWORD_FUNCTION',
p_target_owner => 'TEST_USER',
p_target_function_name => 'PASSWORD_LOGIC_EXTRA_STRONG');
end;
/
```
検証関数をユーザープロファイルに関連付けるには、`alter profile` を使用します。次の例では、検証関数を `DEFAULT` ユーザープロファイルに関連付けています。
```
ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION CUSTOM_PASSWORD_FUNCTION;
```
## カスタム DNS サーバーのセットアップ
Amazon RDS は、Oracle を実行している DB インスタンスでのアウトバウンドのネットワークアクセスをサポートします。前提条件など、アウトバウンドのネットワークアクセスの詳細については、「[証明書と Oracle ウォレットを使用した、UTL\$1HTTP アクセスの設定](Oracle.Concepts.ONA.md)」を参照してください
Amazon RDS Oracle は、顧客所有のカスタム DNS サーバーでドメイン名サービス (DNS) 解決を許可します。Amazon RDS DB インスタンスからカスタム DNS サーバーを介して完全修飾ドメイン名のみを解決することができます。
カスタム DNS ネームサーバーを設定後、変更を DB インスタンスに反映させるまで約 30 分ほどかかります。DB インスタンスへの変更が反映されたら、すべてのアウトバウンドネットワークトラフィックのポート 53 の DNS サーバーにおいて DNS ルックアップクエリを行う必要があります。
Amazon RDS for Oracle DB インスタンスでカスタム DNS サーバーをセットアップするには、次を実行します。
+ Virtual Private Cloud (VPC) の DHCP オプションで `domain-name-servers` を DNS ネームサーバーの IP アドレスに設定します。詳細については、「[DHCP オプションセット](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html)」を参照してください。
**注記**
`domain-name-servers` オプションが許可する値は 4 つまでになりますが、Amazon RDS DB インスタンスが使用するのは初期の値のみです。
+ DNS サーバーが、パブリック DNS 名、Amazon EC2 プライベート DNS 名、ユーザー固有の DNS 名を含むすべてのルックアップクエリを解決できることを確認します。DNS サーバーが処理できない DNS ルックアップがアウトバウンドネットワークトラフィックにある場合は、状況に適したアップストリーミング DNS プロバイダを必ず設定してください。
+ 512 バイト以下の User Datagram Protocol (UDP) レスポンスを生成するように DNS サーバーを設定します。
+ 1024 バイト以下の Transmission Control Protocol (TCP) レスポンスを生成するように DNS サーバーを設定します。
+ ポート 53 で Amazon RDS DB インスタンスからのインバウンドトラフィックを許可するように DNS サーバーを設定します。DNS サーバーが Amazon VPC にある場合、VPC にはポート 53 で UDP と TCP トラフィックを許可するインバウンドルールを含むセキュリティグループが必要になります。DNS サーバーが Amazon VPC にない場合は、ポート 53 で UDP と TCP インバウンドトラフィックを許可できるように、適切なファイアウォールの allow-listing が必要になります。
詳細については、「[VPC のセキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)」と「[ルールの追加と削除](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#AddRemoveRules)」を参照してください。
+ ポート 53 でアウトバウンドトラフィックを許可するため、Amazon RDS DB インスタンスの VPC を設定します。VPC には、ポート 53 で UDP および TCP トラフィックを許可するアウトバウンドルールを含むセキュリティグループが必要になります。
詳細については、「[VPC のセキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)」と「[ルールの追加と削除](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#AddRemoveRules)」を参照してください。
+ Amazon RDS DB インスタンスと DNS サーバー間のルーティングパスは、DNS トラフィックを許可できるよう適切に設定してください。
+ Amazon RDS DB インスタンスと DNS サーバーが同じ VPC にない場合は、両者の間でピア接続をセットアップする必要があります。詳細については、「[VPC ピア機能とは](https://docs.aws.amazon.com/vpc/latest/peering/Welcome.html)」を参照してください。
# システム診断イベントの設定と設定の解除
セッションレベルで診断イベントを設定および設定解除するには、Oracle SQL ステートメントを使用できます `ALTER SESSION SET EVENTS`。ただし、システムレベルでイベントを設定するには、Oracle SQL を使用できません。代わりに、`rdsadmin.rdsadmin_util` パッケージ内のシステムイベント手順を使用します。システムイベント手順は、次のエンジンバージョンで使用できます。
+ すべての Oracle Database 21c バージョン
+ 19.0.0.0.ru-2020-10.rur-2020-10.r1 以降の Oracle Database 19c バージョン
詳細については、「*Amazon RDS for Oracle リリースノート*」の「[バージョン 19.0.0.0.ru-2020-10.rur-2020-10.r1](https://docs.aws.amazon.com/AmazonRDS/latest/OracleReleaseNotes/oracle-version-19-0.html#oracle-version-RU-RUR.19.0.0.0.ru-2020-10.rur-2020-10.r1)」を参照してください。
**重要**
内部的には、`rdsadmin.rdsadmin_util` パッケージは `ALTER SYSTEM SET EVENTS` ステートメントを使用してイベントを設定します。`ALTER SYSTEM` ステートメントは、Oracle データベースのドキュメントには記載されていません。システム診断イベントによっては、大量のトレース情報を生成したり、競合を引き起こしたり、データベースの可用性に影響を与えることがあります。非稼動のデータベースで特定の診断イベントをテストし、Oracleサポートのガイダンスに従って、本番稼動用のデータベースにのみイベントを設定することをお勧めしています。
## 許可されたシステム診断イベントのリスト化
設定できるシステムイベントをリスト化するには、Amazon RDS の手順 `rdsadmin.rdsadmin_util.list_allowed_system_events`を使用します。この手順はパラメータを受け付けません。
次の例では、設定可能なすべてのシステムイベントをリスト化します。
```
SET SERVEROUTPUT ON
EXEC rdsadmin.rdsadmin_util.list_allowed_system_events;
```
次の出力サンプルは、イベント番号とその説明をリスト化しています。`set_system_event`これらのイベントを設定し、`unset_system_event`設定解除するには、Amazon RDS の手順を使用します。
```
604 - error occurred at recursive SQL level
942 - table or view does not exist
1401 - inserted value too large for column
1403 - no data found
1410 - invalid ROWID
1422 - exact fetch returns more than requested number of rows
1426 - numeric overflow
1427 - single-row subquery returns more than one row
1476 - divisor is equal to zero
1483 - invalid length for DATE or NUMBER bind variable
1489 - result of string concatenation is too long
1652 - unable to extend temp segment by in tablespace
1858 - a non-numeric character was found where a numeric was expected
4031 - unable to allocate bytes of shared memory ("","","","")
6502 - PL/SQL: numeric or value error
10027 - Specify Deadlock Trace Information to be Dumped
10046 - enable SQL statement timing
10053 - CBO Enable optimizer trace
10173 - Dynamic Sampling time-out error
10442 - enable trace of kst for ORA-01555 diagnostics
12008 - error in materialized view refresh path
12012 - error on auto execute of job
12504 - TNS:listener was not given the SERVICE_NAME in CONNECT_DATA
14400 - inserted partition key does not map to any partition
31693 - Table data object failed to load/unload and is being skipped due to error:
```
**注記**
許可されるシステムイベントのリストは、時間の経過とともに変化する可能性があります。対象イベントの最新のリストがあることを確認するには、`rdsadmin.rdsadmin_util.list_allowed_system_events` を使用します。
## システム診断イベントの設定
システムイベントを設定するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.set_system_event` を使用します。`rdsadmin.rdsadmin_util.list_allowed_system_events` の出力にリストされているイベントだけを設定できます。`set_system_event` 手順は、次のパラメータを受け付けます。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_event` | number | — | はい | システムイベント番号。値は、`list_allowed_system_events` によって報告されるイベント番号の 1 つである必要があります。 |
| `p_level` | number | — | はい | イベントレベル。異なるレベル値の説明については、Oracle データベースのドキュメントまたは Oracle サポートを参照してください。 |
手順 `set_system_event`は、次の原則に従って必要な`ALTER SYSTEM SET EVENTS` ステートメントを構築および実行します。
+ イベントタイプ (`context` または `errorstack`) は自動的に決定されます。
+ フォーム内のステートメントは、`ALTER SYSTEM SET EVENTS 'event LEVEL event_level'`コンテキストイベントを設定します。この表記は `ALTER SYSTEM SET EVENTS 'event TRACE NAME CONTEXT FOREVER, LEVEL event_level'` と同等です。
+ フォーム内のステートメントは、`ALTER SYSTEM SET EVENTS 'event ERRORSTACK (event_level)'`エラースタックイベントを設定します。この表記は `ALTER SYSTEM SET EVENTS 'event TRACE NAME ERRORSTACK LEVEL event_level'` と同等です。
次の例では、イベント 942 をレベル 3 に設定し、イベント 10442 をレベル 10 に設定します。サンプル出力が含まれています。
```
SQL> SET SERVEROUTPUT ON
SQL> EXEC rdsadmin.rdsadmin_util.set_system_event(942,3);
Setting system event 942 with: alter system set events '942 errorstack (3)'
PL/SQL procedure successfully completed.
SQL> EXEC rdsadmin.rdsadmin_util.set_system_event(10442,10);
Setting system event 10442 with: alter system set events '10442 level 10'
PL/SQL procedure successfully completed.
```
## 設定されているシステム診断イベントのリスト化
現在設定されているシステムイベントをリスト化するには、Amazon RDS の手順を使用します `rdsadmin.rdsadmin_util.list_set_system_events`。この手順では、`set_system_event` によってシステムレベルで設定されたイベントだけが報告されます。
次の例は、アクティブなシステムイベントをリスト化します。
```
SET SERVEROUTPUT ON
EXEC rdsadmin.rdsadmin_util.list_set_system_events;
```
次のサンプル出力は、イベントのリスト、イベントタイプ、イベントが現在設定されているレベル、およびイベントが設定された時刻を示しています。
```
942 errorstack (3) - set at 2020-11-03 11:42:27
10442 level 10 - set at 2020-11-03 11:42:41
PL/SQL procedure successfully completed.
```
## システム診断イベントの設定解除
システムイベントの設定を解除するには、Amazon RDS の手順を使用します `rdsadmin.rdsadmin_util.unset_system_event`。設定を解除できるのは、`rdsadmin.rdsadmin_util.list_allowed_system_events` の出力にリスト化されたイベントだけです 。`unset_system_event` 手順は、次のパラメータを受け付けます。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_event` | number | — | はい | システムイベント番号。値は、`list_allowed_system_events` によって報告されるイベント番号の 1 つである必要があります。 |
次の例では、イベント 942 と 10442 の設定を解除します。サンプル出力が含まれています。
```
SQL> SET SERVEROUTPUT ON
SQL> EXEC rdsadmin.rdsadmin_util.unset_system_event(942);
Unsetting system event 942 with: alter system set events '942 off'
PL/SQL procedure successfully completed.
SQL> EXEC rdsadmin.rdsadmin_util.unset_system_event(10442);
Unsetting system event 10442 with: alter system set events '10442 off'
PL/SQL procedure successfully completed.
```
# Oracle DB インスタンスの一般的なデータベースタスクの実行
次に、Oracle を実行している Amazon RDS DB インスタンスのデータベースに関連する特定の一般的な DBA タスクを実行する方法を示します。マネージドサービスエクスペリエンスを提供するために、Amazon RDS は DB インスタンスへのシェルアクセスを提供していません。また、Amazon RDS では、高度な特権を必要とする、一部のシステムプロシージャやテーブルへのアクセスが制限されます。
**Topics**
+ [データベースのグローバル名の変更](Appendix.Oracle.CommonDBATasks.RenamingGlobalName.md)
+ [RDS for Oracle でテーブルスペースを使用する](Appendix.Oracle.CommonDBATasks.TablespacesAndDatafiles.md)
+ [RDS for Oracle で一時ファイルを使用する](Appendix.Oracle.CommonDBATasks.using-tempfiles.md)
+ [RDS for Oracle のテーブルスペース、データファイル、一時ファイルのサイズ変更](Appendix.Oracle.CommonDBATasks.ResizeTempSpaceReadReplica.md)
+ [RDS for Oracle のストレージボリューム間のデータの移動](Appendix.Oracle.CommonDBATasks.MovingDataBetweenVolumes.md)
+ [RDS for Oracle での外部テーブルの使用](Appendix.Oracle.CommonDBATasks.External_Tables.md)
# データベースのグローバル名の変更
データベースのグローバル名を変更するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.rename_global_name` を使用します。`rename_global_name` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_new_global_name` | varchar2 | — | はい | データベースの新しいグローバル名。 |
名前の変更を実行するには、データベースが開いている必要があります。データベースのグローバル名の変更の詳細については、Oracle ドキュメントの「[ALTER DATABASE](http://docs.oracle.com/cd/E11882_01/server.112/e41084/statements_1004.htm#SQLRF52547)」を参照してください。
次の例では、データベースのグローバル名を `new_global_name` に変更します。
```
EXEC rdsadmin.rdsadmin_util.rename_global_name(p_new_global_name => 'new_global_name');
```
# RDS for Oracle でテーブルスペースを使用する
RDS for Oracle では、データベースのデータを保存する論理ストレージユニットであるテーブルスペースを使用できます。
**重要**
DB インスタンスにレプリカがある場合は、セッションレベルの変更ではなくパラメータグループ設定を使用してデフォルトのファイルの場所を管理することをお勧めします。プライマリインスタンスのデフォルトファイルの場所に対するセッションレベルの変更は、レプリカに自動的に反映されません。パラメータグループ設定を使用すると、プライマリインスタンスとレプリカインスタンス間で一貫したファイルの場所が確保されます。
**Topics**
+ [RDS for Oracle でのデータベースファイルの場所の指定](#Appendix.Oracle.CommonDBATasks.DatabaseFileLocations)
+ [RDS for Oracle でのテーブルスペースの作成とサイズ設定](#Appendix.Oracle.CommonDBATasks.CreatingTablespacesAndDatafiles)
+ [RDS for Oracle で追加のストレージボリュームにテーブルスペースを作成する](#Appendix.Oracle.CommonDBATasks.CreatingTablespacesWithFileLocations)
+ [RDS for Oracle でのデフォルトのテーブルスペースの設定](#Appendix.Oracle.CommonDBATasks.SettingDefaultTablespace)
+ [RDS for Oracle でのデフォルトの一時テーブルスペースの設定](#Appendix.Oracle.CommonDBATasks.SettingDefTempTablespace)
+ [インスタンスストアに一時テーブルスペースを作成する](#Appendix.Oracle.CommonDBATasks.creating-tts-instance-store)
## RDS for Oracle でのデータベースファイルの場所の指定
RDS for Oracle は、Oracle Managed Files (OMF) を使用してデータベースファイルに名前を付けます。データベースファイルを作成すると、データベースは `DB_CREATE_FILE_DEST` 初期化パラメータの現在の設定に基づいて設定を取得します。
`DB_CREATE_FILE_DEST` 初期化パラメータのデフォルト値は、`/rdsdbdata/db` スタンドアロンデータベースとコンテナ化された (CDB/MT) アーキテクチャ用 `/rdsdbdata/db/pdb` です。DB インスタンスに追加のストレージボリュームがある場合は、ボリュームロケーションに `DB_CREATE_FILE_DEST` を設定できます。例えば、インスタンスに `/rdsdbdata/db` にマウントされたボリュームがある場合、`DB_CREATE_FILE_DEST` をこの値に設定できます。
`DB_CREATE_FILE_DEST` パラメータは、セッションレベルまたは Oracle データベースインスタンスレベルで変更できます。
### インスタンスレベルで DB\$1CREATE\$1FILE\$1SET を変更する
インスタンスレベルでパラメータを変更するには、DB インスタンスに割り当てられたパラメータグループのパラメータを更新して適用します。詳細については、「[RDS for Oracle 初期化パラメータ](Oracle.Concepts.FeatureSupport.Parameters.md)」および「[Amazon RDS の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md)」を参照してください。
### セッションレベルで DB\$1CREATE\$1FILE\$1DEST を変更する
`ALTER SESSION` ステートメントを実行して、セッションレベルでパラメータを変更できます。このアプローチは、インスタンス全体に影響を与えることなく、特定のセッションの特定の場所にデータベースファイルを作成する場合に便利です。
次の例は、現在のパラメータ値を確認し、セッションで変更する方法を示しています。
```
SHOW PARAMETER db_create_file_dest
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_create_file_dest string /rdsdbdata/db
ALTER SESSION SET db_create_file_dest = '/rdsdbdata2/db';
Session altered.
SHOW PARAMETER db_create_file_dest
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_create_file_dest string /rdsdbdata2/db
```
## RDS for Oracle でのテーブルスペースの作成とサイズ設定
テーブルスペースを作成すると、データベースは作成時に `DB_CREATE_FILE_DEST` 初期化パラメータで指定されたストレージボリュームにデータファイルを作成します。データファイルのサイズを指定しない場合、デフォルトの `AUTOEXTEND ON` でテーブルスペースが作成され。最大サイズはありません。次の例では、テーブルスペース *users1* は自動拡張可能です。
```
CREATE TABLESPACE users1;
```
これらのデフォルト設定のため、テーブルスペースはすべての割り当てられたストレージを消費するまで大きくなります。永続テーブルスペースとテンポラリテーブルスペースに適切な最大サイズを指定し、リージョンの使用状況を注意深くモニタリングすることをお勧めします。
次の例では、スタートサイズが 1 ギガバイトのテーブルスペース *users2* を作成します。データファイルのサイズが指定されていても、`AUTOEXTEND ON` が指定されていないため、テーブルスペースは自動拡張できません。
```
CREATE TABLESPACE users2 DATAFILE SIZE 1G;
```
次の例では、スタートサイズが 1 ギガバイト、自動拡張がオン、最大サイズが 10 ギガバイトのテーブルスペース *users3* を作成します。
```
CREATE TABLESPACE users3 DATAFILE SIZE 1G AUTOEXTEND ON MAXSIZE 10G;
```
次の例では、一時テーブルスペース *temp01* を作成します。
```
CREATE TEMPORARY TABLESPACE temp01;
```
`ALTER TABLESPACE` を使用すると、bigfile テーブルスペースをサイズ変更できます。サイズは、キロバイト (K)、メガバイト (M)、ギガバイト (G)、またはテラバイト (T) で指定できます。次の例では、bigfile テーブルスペース *users\$1bf* のサイズを 200 MB に変更します。
```
ALTER TABLESPACE users_bf RESIZE 200M;
```
次の例では、smallfile テーブルスペース *users\$1sf* に追加のデータファイルを追加します。
```
ALTER TABLESPACE users_sf ADD DATAFILE SIZE 100000M AUTOEXTEND ON NEXT 250m MAXSIZE UNLIMITED;
```
## RDS for Oracle で追加のストレージボリュームにテーブルスペースを作成する
追加のストレージボリュームにテーブルスペースを作成するには、`DB_CREATE_FILE_DEST` パラメータをボリュームの場所に変更します。次の例では、ファイルの場所を `/rdsdbdata2/db` に設定します。
```
ALTER SESSION SET db_create_file_dest = '/rdsdbdata2/db';
Session altered.
```
次の例では、追加のボリューム `/rdsdbdata2/db` にテーブルスペースを作成します。
```
CREATE TABLESPACE new_tablespace DATAFILE SIZE 10G;
Tablespace created.
SELECT tablespace_name,file_id,file_name FROM dba_data_files
WHERE tablespace_name = 'NEW_TABLESPACE';
TABLESPACE_NAME FILE_ID FILE_NAME
------------------------- ---------- --------------------------------------------------------------------------------
NEW_TABLESPACE 7 /rdsdbdata2/db/ORCL_A/datafile/o1_mf_newtable_a123b4c5_.dbf
```
smallfile テーブルスペースを作成し、そのデータファイルを異なるストレージボリュームに分散するには、作成後にテーブルスペースにデータファイルを追加します。次の例では、`/rdsdbdata/db` のデフォルトの場所にデータファイルを含むテーブルスペースを作成します。次に、デフォルトの送信先を `/rdsdbdata/db2` に設定します。新しく作成したテーブルスペースにデータファイルを追加すると、データベースはそのファイルを `/rdsdbdata/db2` に保存します。
```
ALTER SESSION SET db_create_file_dest = '/rdsdbdata/db';
Session altered.
CREATE SMALLFILE TABLESPACE smalltbs DATAFILE SIZE 10G;
Tablespace created.
SELECT tablespace_name,file_id,file_name FROM dba_data_files
WHERE tablespace_name = 'SMALLTBS';
TABLESPACE_NAME FILE_ID FILE_NAME
------------------------- ---------- --------------------------------------------------------------------------------
SMALLTBS 8 /rdsdbdata/db/ORCL_A/datafile/o1_mf_smalltbs_n563yryk_.dbf
ALTER SESSION SET db_create_file_dest = '/rdsdbdata2/db';
Session altered.
ALTER TABLESPACE smalltbs ADD DATAFILE SIZE 10G;
Tablespace altered.
SELECT tablespace_name,file_id,file_name FROM dba_data_files
WHERE tablespace_name = 'SMALLTBS';
TABLESPACE_NAME FILE_ID FILE_NAME
------------------------- ---------- --------------------------------------------------------------------------------
SMALLTBS 8 /rdsdbdata/db/ORCL_A/datafile/o1_mf_smalltbs_n563yryk_.dbf
SMALLTBS 9 /rdsdbdata2/db/ORCL_A/datafile/o1_mf_smalltbs_n564004g_.dbf
```
## RDS for Oracle でのデフォルトのテーブルスペースの設定
デフォルトのテーブルスペースを設定するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.alter_default_tablespace` を使用します。`alter_default_tablespace` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `tablespace_name` | varchar | — | はい | デフォルトのテーブルスペースの名前。 |
次の例では、デフォルトのテーブルスペースを *users2* に設定します。
```
EXEC rdsadmin.rdsadmin_util.alter_default_tablespace(tablespace_name => 'users2');
```
## RDS for Oracle でのデフォルトの一時テーブルスペースの設定
デフォルトのテンポラリテーブルスペースを設定するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.alter_default_temp_tablespace` を使用します。`alter_default_temp_tablespace` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `tablespace_name` | varchar | — | はい | デフォルトのテンポラリテーブルスペースの名前。 |
次の例では、デフォルトのテンポラリテーブルスペースを *temp01* に設定します。
```
EXEC rdsadmin.rdsadmin_util.alter_default_temp_tablespace(tablespace_name => 'temp01');
```
## インスタンスストアに一時テーブルスペースを作成する
インスタンスストアに一時テーブルスペースを作成するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.create_inst_store_tmp_tblspace` を使用します。`create_inst_store_tmp_tblspace` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_tablespace_name` | varchar | — | はい | テンポラリテーブルスペースの名前。 |
次の例では、インスタンスストアに一時テーブルスペース *temp01* を作成します。
```
EXEC rdsadmin.rdsadmin_util.create_inst_store_tmp_tblspace(p_tablespace_name => 'temp01');
```
**重要**
`rdsadmin_util.create_inst_store_tmp_tblspace` を実行しても、新しく作成された一時テーブルスペースは、デフォルトの一時テーブルスペースとして自動的に設定されません。これをデフォルトとして設定するには、「[RDS for Oracle でのデフォルトの一時テーブルスペースの設定](#Appendix.Oracle.CommonDBATasks.SettingDefTempTablespace)」を参照してください。
詳細については、「[RDS for Oracle インスタンスストアへの一時データの保存](CHAP_Oracle.advanced-features.instance-store.md)」を参照してください。
# RDS for Oracle で一時ファイルを使用する
## リードレプリカのインスタンスストアへの一時ファイルの追加
プライマリ DB インスタンスで一時テーブルスペースを作成すると、リードレプリカの一時ファイルは作成されません。次のいずれかの理由により、リードレプリカに空の一時テーブルスペースが存在するとします。
+ リードレプリカのテーブルスペースから一時ファイルを削除しました。詳細については、「[リードレプリカの一時ファイルの削除](Appendix.Oracle.CommonDBATasks.dropping-tempfiles-replica.md)」を参照してください。
+ プライマリ DB インスタンスに新しい一時テーブルスペースを作成しました。この場合、RDS for Oracle はメタデータをリードレプリカに同期します。
一時ファイルを空の一時テーブルスペースに追加し、その一時ファイルをインスタンスストアに保存できます。インスタンスストアに一時ファイルを作成するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.add_inst_store_tempfile` を使用します。この手順はリードレプリカでのみ使用できます。 プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_tablespace_name` | varchar | — | はい | リードレプリカの一時テーブルスペースの名前。 |
次の例では、空の一時テーブルスペース *temp01* がリードレプリカに存在します。次のコマンドを実行して、このテーブルスペースの一時ファイルを作成し、インスタンスストアに保存します。
```
EXEC rdsadmin.rdsadmin_util.add_inst_store_tempfile(p_tablespace_name => 'temp01');
```
詳細については、「[RDS for Oracle インスタンスストアへの一時データの保存](CHAP_Oracle.advanced-features.instance-store.md)」を参照してください。
# リードレプリカの一時ファイルの削除
既存の一時テーブルスペースをリードレプリカから削除することはできません。リードレプリカの一時ファイルストレージを Amazon EBS からインスタンスストアに、またはインスタンスストアから Amazon EBS に変更できます。これらの目標を達成するには、次の操作を行います。
1. リードレプリカの一時テーブルスペースにある現在の一時ファイルを削除します。
1. 別のストレージに新しい一時ファイルを作成します。
一時ファイルを削除するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util. drop_replica_tempfiles` を使用します。この手順はリードレプリカでのみ使用できます。`drop_replica_tempfiles` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_tablespace_name` | varchar | — | はい | リードレプリカの一時テーブルスペースの名前。 |
*temp01* という名前の一時テーブルスペースがリードレプリカのインスタンスストアにあると仮定します。次のコマンドを実行して、このテーブルスペースのすべての一時ファイルを削除します。
```
EXEC rdsadmin.rdsadmin_util.drop_replica_tempfiles(p_tablespace_name => 'temp01');
```
詳細については、「[RDS for Oracle インスタンスストアへの一時データの保存](CHAP_Oracle.advanced-features.instance-store.md)」を参照してください。
# RDS for Oracle のテーブルスペース、データファイル、一時ファイルのサイズ変更
デフォルトでは、Oracle テーブルスペースは自動エクステンションをオンにして作成され、最大サイズでは作成されません。これらのデフォルト設定のため、場合によってはテーブルスペースが大きくなりすぎる可能性があります。永続テーブルスペースとテンポラリテーブルスペースに適切な最大サイズを指定し、リージョンの使用状況を注意深くモニタリングすることをお勧めします。
## 永続テーブルスペースの変更
RDS for Oracle DB インスタンスの永続テーブルスペースのサイズを変更するには、以下の Amazon RDS 手順のいずれかを使用してください。
+ `rdsadmin.rdsadmin_util.resize_datafile`
+ `rdsadmin.rdsadmin_util.autoextend_datafile`
`resize_datafile` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_data_file_id` | number | — | はい | サイズ変更するデータファイルの識別子。 |
| `p_size` | varchar2 | — | はい | データファイルのサイズ。サイズをバイト (デフォルト)、キロバイト (K)、メガバイト (M)、またはギガバイト (G) で指定します。 |
`autoextend_datafile` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_data_file_id` | number | — | はい | サイズ変更するデータファイルの識別子。 |
| `p_autoextend_state` | varchar2 | — | はい | 自動拡張機能の状態。`ON` を指定するとデータファイルは自動的に拡張し、`OFF` を指定すると自動拡張はオフになります。 |
| `p_next` | varchar2 | — | いいえ | 次のデータファイル増分のサイズ。サイズをバイト (デフォルト)、キロバイト (K)、メガバイト (M)、またはギガバイト (G) で指定します。 |
| `p_maxsize` | varchar2 | — | いいえ | 自動拡張に許可される最大ディスク容量。サイズをバイト (デフォルト)、キロバイト (K)、メガバイト (M)、またはギガバイト (G) で指定します。`UNLIMITED` を指定するとファイルサイズ制限を削除できます。 |
次の例では、データファイル 4 のサイズを 500 MB に変更します。
```
EXEC rdsadmin.rdsadmin_util.resize_datafile(4,'500M');
```
次の例では、データファイル 4 の自動拡張をオフにします。また、データファイル 5 の自動拡張はオンになり、増分は 128 MB で、最大サイズはありません。
```
EXEC rdsadmin.rdsadmin_util.autoextend_datafile(4,'OFF');
EXEC rdsadmin.rdsadmin_util.autoextend_datafile(5,'ON','128M','UNLIMITED');
```
## 一時テーブルスペースのサイズ変更
RDS for Oracle DB インスタンスの一時テーブルスペース (リードレプリカを含む) のサイズを変更するには、以下の Amazon RDS 手順のいずれかを使用します。
+ `rdsadmin.rdsadmin_util.resize_temp_tablespace`
+ `rdsadmin.rdsadmin_util.resize_tempfile`
+ `rdsadmin.rdsadmin_util.autoextend_tempfile`
`resize_temp_tablespace` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_temp_tablespace_name` | varchar2 | — | はい | サイズを変更するテンポラリテーブルスペースの名前。 |
| `p_size` | varchar2 | — | はい | テーブルスペースのサイズ。サイズをバイト (デフォルト)、キロバイト (K)、メガバイト (M)、またはギガバイト (G) で指定します。 |
`resize_tempfile` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_temp_file_id` | number | — | はい | サイズを変更する一時ファイルの識別子。 |
| `p_size` | varchar2 | — | はい | 一時ファイルのサイズ。サイズをバイト (デフォルト)、キロバイト (K)、メガバイト (M)、またはギガバイト (G) で指定します。 |
`autoextend_tempfile` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_temp_file_id` | number | — | はい | サイズを変更する一時ファイルの識別子。 |
| `p_autoextend_state` | varchar2 | — | はい | 自動拡張機能の状態。`ON` を指定すると一時ファイルは自動的に拡張し、`OFF` を指定すると自動拡張はオフになります。 |
| `p_next` | varchar2 | — | いいえ | 次の一時ファイル増分のサイズ。サイズをバイト (デフォルト)、キロバイト (K)、メガバイト (M)、またはギガバイト (G) で指定します。 |
| `p_maxsize` | varchar2 | — | いいえ | 自動拡張に許可される最大ディスク容量。サイズをバイト (デフォルト)、キロバイト (K)、メガバイト (M)、またはギガバイト (G) で指定します。`UNLIMITED` を指定するとファイルサイズ制限を削除できます。 |
次の例は、`TEMP` という一時テーブルスペースのサイズを 4 ギガバイトに変更します。
```
EXEC rdsadmin.rdsadmin_util.resize_temp_tablespace('TEMP','4G');
```
```
EXEC rdsadmin.rdsadmin_util.resize_temp_tablespace('TEMP','4096000000');
```
次の例は、ファイル識別子が `1` の一時ファイルに基づいて、一時テーブルスペースのサイズを 2 メガバイトに変更します。
```
EXEC rdsadmin.rdsadmin_util.resize_tempfile(1,'2M');
```
次の例では、一時ファイル 1 の自動拡張をオフにします。また、一時ファイル 2 の最大自動拡張サイズも 10 ギガバイト、増分を 100 メガバイトに設定します。
```
EXEC rdsadmin.rdsadmin_util.autoextend_tempfile(1,'OFF');
EXEC rdsadmin.rdsadmin_util.autoextend_tempfile(2,'ON','100M','10G');
```
Oracle DB インスタンスのリードレプリカの詳細については、「[Amazon RDS for Oracle でのリードレプリカの使用](oracle-read-replicas.md)」を参照してください。
# RDS for Oracle のストレージボリューム間のデータの移動
データファイルとデータベースオブジェクトは、プライマリストレージボリュームと追加のストレージボリューム間で移動できます。データを移動する前に、次の点を考慮してください。
+ ソースボリュームとターゲットボリュームには十分な空き領域が必要です。
+ データ移動オペレーションは、両方のボリュームで I/O を消費します。
+ 大きなデータ移動は、データベースのパフォーマンスに影響を与える可能性があります。
+ スナップショットを復元する場合、EBS 遅延ロードの影響を受けると、ストレージボリューム間のデータの移動が遅くなる可能性があります。
**Topics**
+ [RDS for Oracle のボリューム間でのデータファイルの移動](#Appendix.Oracle.CommonDBATasks.MovingDatafiles)
+ [RDS for Oracle のボリューム間でテーブルデータとインデックスを移動する](#Appendix.Oracle.CommonDBATasks.MovingTableData)
+ [追加ボリュームを使用した LOB ストレージの管理](#Appendix.Oracle.CommonDBATasks.ManagingLargeLOBStorage)
## RDS for Oracle のボリューム間でのデータファイルの移動
ストレージボリューム間でデータファイルを移動するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.move_datafile` を使用します。次の要件に注意してください。
+ `move_datafile` プロシージャを実行するには、Oracle Enterprise Edition を使用する必要があります。
+ テーブルスペース `SYSTEM` と `RDSADMIN` を移動することはできません。
`move_datafile` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | 必要 | 説明 |
| --- | --- | --- | --- |
| `p_data_file_id` | number | はい | 移動するデータファイルの ID。 |
| `p_location` | varchar2 | はい | データファイルを移動するストレージボリューム。 |
次の例では、テーブルスペースをデフォルトボリューム `rdsdbdata` から追加ボリューム `rdsdbdata2` に移動します。
```
SQL> SELECT tablespace_name,file_id,file_name FROM dba_data_files
WHERE tablespace_name = 'MYNEWTABLESPACE';
TABLESPACE_NAME FILE_ID FILE_NAME
------------------------- ---------- --------------------------------------------------------------------------------
MYNEWTABLESPACE 6 /rdsdbdata/db/ORCL_A/datafile/o1_mf_mynewtab_n123abcd_.dbf
EXECUTE rdsadmin.rdsadmin_util.move_datafile( 6, 'rdsdbdata2');
PL/SQL procedure successfully completed.
SQL> SELECT tablespace_name,file_id,file_name FROM dba_data_files
WHERE tablespace_name = 'MYNEWTABLESPACE';
TABLESPACE_NAME FILE_ID FILE_NAME
------------------------- ---------- --------------------------------------------------------------------------------
MYNEWTABLESPACE 6 /rdsdbdata2/db/ORCL_A/datafile/o1_mf_mynewtab_n356efgh_.dbf
```
## RDS for Oracle のボリューム間でテーブルデータとインデックスを移動する
追加のストレージボリュームにテーブルスペースを作成することで、データベースストレージを最適化できます。その後、標準の Oracle SQL を使用して、テーブル、インデックス、パーティションなどのオブジェクトをこれらのテーブルスペースに移動できます。このアプローチは、データベースにさまざまなアクセスパターンのデータが含まれている場合のパフォーマンス調整に役立ちます。例えば、アクセス頻度の高い運用データを高性能ストレージボリュームに保存しながら、アクセス頻度の低い履歴データを低コストのストレージボリュームに移動できます。
次の例では、高性能ボリューム `rdsdbdata2` に新しいテーブルスペースを作成します。次に、テーブルがオンラインのときに、テーブルを追加のストレージボリュームに移動します。また、インデックスを同じボリュームに移動します。オンライン中にテーブルを移動してインデックスを再構築するには、Oracle Enterprise Edition が必要です。
```
ALTER SESSION SET db_create_file_dest = '/rdsdbdata2/db';
CREATE TABLESPACE perf_tbs DATAFILE SIZE 10G;
ALTER TABLE employees
MOVE TABLESPACE perf_tbs ONLINE;
ALTER INDEX employees_idx
REBUILD ONLINE TABLESPACE perf_tbs;
```
次の例では、低コストのボリュームにテーブルスペースを作成します。次に、オンラインオペレーションを使用して、テーブルパーティションを低コストのストレージボリュームに移動します。
```
ALTER SESSION SET db_create_file_dest = '/rdsdbdata3/db';
CREATE TABLESPACE hist_tbs DATAFILE SIZE 10G;
ALTER TABLE orders
MOVE PARTITION orders_2022
TABLESPACE hist_tbs ONLINE;
```
次の例では、アクティブなセッションのロングオペレーションをクエリします。
```
SELECT sid,opname,sofar,totalwork,time_remaining,elapsed_seconds
FROM v$session_longops
WHERE time_remaining > 0;
```
次のクエリを使用して、テーブルスペースの使用状況を確認できます。
```
SELECT tablespace_name, used_percent
FROM dba_tablespace_usage_metrics
ORDER BY used_percent DESC;
```
## 追加ボリュームを使用した LOB ストレージの管理
データベースには、大量のストレージを消費するが、アクセス頻度が低い BLOB オブジェクトまたは CLOB オブジェクトを含むテーブルが含まれている場合があります。ストレージを最適化するために、これらの LOB セグメントを追加のストレージボリュームのテーブルスペースに再配置できます。
次の例では、低アクセスデータを対象とした低コストのボリュームで LOB データのテーブルスペースを作成します。次に、このボリュームにデータを保存するテーブルを作成します。
```
ALTER SESSION SET db_create_file_dest = '/rdsdbdata3/db';
CREATE TABLESPACE lob_data DATAFILE SIZE 5G AUTOEXTEND ON NEXT 1G;
CREATE TABLE documents (
doc_id NUMBER PRIMARY KEY,
doc_date DATE,
doc_content CLOB
) TABLESPACE user_data
LOB(doc_content) STORE AS (TABLESPACE lob_data);
```
# RDS for Oracle での外部テーブルの使用
*Oracle 外部テーブル*は、データベースにないデータのテーブルです。代わりに、データはデータベースがアクセスできる外部ファイルにあります。外部テーブルを使用して、データベースにロードしないでデータにアクセスできます。外部テーブルの詳細については、Oracle ドキュメントの「[外部表の管理](http://docs.oracle.com/database/121/ADMIN/tables.htm#ADMIN01507)」を参照してください。
Amazon RDS では、外部テーブルファイルをディレクトリオブジェクトに保存できます。ディレクトリオブジェクトは、新規作成するか、Oracle データベースに定義済みのもの (DATA\$1PUMP\$1DIR ディレクトリなど) を使用できます。ディレクトリオブジェクトの作成方法については、「[主要データストレージ領域でのディレクトリの作成と削除](Appendix.Oracle.CommonDBATasks.Misc.md#Appendix.Oracle.CommonDBATasks.NewDirectories)」を参照してください。Amazon RDS Oracle DB インスタンスのディレクトリオブジェクトを一覧表示するには、ALL\$1DIRECTORIES ビューをクエリできます。
**注記**
ディレクトリオブジェクトは、インスタンスで使用されているメインのデータストレージ領域 (Amazon EBS ボリューム) を参照します。データファイル、REDO ログ、監査、追跡、およびその他のファイルで使用される領域は、割り当てられたストレージの消費としてカウントされます。
外部データファイルを Oracle データベース間で移行するには、[DBMS\$1FILE\$1TRANSFER](https://docs.oracle.com/database/121/ARPLS/d_ftran.htm#ARPLS095) パッケージまたは [UTL\$1FILE](https://docs.oracle.com/database/121/ARPLS/u_file.htm#ARPLS069) パッケージを使用できます。外部データファイルは、移行元のデータベースのディレクトリから、移行先のデータベースの指定されたディレクトリに移行されます。`DBMS_FILE_TRANSFER` の使用の詳細については、「[Oracle Data Pump を使用したインポート](Oracle.Procedural.Importing.DataPump.md)」を参照してください。
移行した外部データファイルを使用して、外部テーブルを作成できます。次の例では、USER\$1DIR1 ディレクトリの `emp_xt_file1.txt` ファイルを使用する外部テーブルを作成します。
```
CREATE TABLE emp_xt (
emp_id NUMBER,
first_name VARCHAR2(50),
last_name VARCHAR2(50),
user_name VARCHAR2(20)
)
ORGANIZATION EXTERNAL (
TYPE ORACLE_LOADER
DEFAULT DIRECTORY USER_DIR1
ACCESS PARAMETERS (
RECORDS DELIMITED BY NEWLINE
FIELDS TERMINATED BY ','
MISSING FIELD VALUES ARE NULL
(emp_id,first_name,last_name,user_name)
)
LOCATION ('emp_xt_file1.txt')
)
PARALLEL
REJECT LIMIT UNLIMITED;
```
Amazon RDS Oracle DB インスタンスにあるデータを外部データファイル内に移行するとします。この場合、外部テーブルを作成し、データベースのテーブルから選択したデータを外部データファイルに入力できます。例えば、次の SQL ステートメントでは、データベースの `orders_xt` テーブルをクエリすることで `orders` 外部テーブルを作成します。
```
CREATE TABLE orders_xt
ORGANIZATION EXTERNAL
(
TYPE ORACLE_DATAPUMP
DEFAULT DIRECTORY DATA_PUMP_DIR
LOCATION ('orders_xt.dmp')
)
AS SELECT * FROM orders;
```
この例では、データは DATA\$1PUMP\$1DIR ディレクトリの `orders_xt.dmp` ファイルに入力されます。
# データベースのチェックポイント機能
データベースのチェックポイントを作成するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.checkpoint` を使用します。`checkpoint` プロシージャにはパラメータはありません。
次の例では、データベースのチェックポイントを作成します。
```
EXEC rdsadmin.rdsadmin_util.checkpoint;
```
# 分散復旧の設定
分散復旧を設定するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.enable_distr_recovery` と `disable_distr_recovery` を使用します。このプロシージャにはパラメータはありません。
次の例では、分散復旧を有効にします。
```
EXEC rdsadmin.rdsadmin_util.enable_distr_recovery;
```
次の例では、分散復旧を無効にします。
```
EXEC rdsadmin.rdsadmin_util.disable_distr_recovery;
```
# データベースタイムゾーンの設定
以下の方法で、Amazon RDS Oracle データベースのタイムゾーンを設定できます。
+ `Timezone` オプション
`Timezone` オプションは、ホストレベルでタイムゾーンを変更し、`SYSDATE` など、すべての日付列と値に影響します。詳細については、「[Oracle のタイムゾーン](Appendix.Oracle.Options.Timezone.md)」を参照してください。
+ Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.alter_db_time_zone`
`alter_db_time_zone` プロシージャは、特定のデータ型のみのタイムゾーンを変更し、`SYSDATE` は変更しません。タイムゾーンの設定に関する他の制限については、[Oracle ドキュメント](http://docs.oracle.com/cd/B19306_01/server.102/b14225/ch4datetime.htm#i1006705)に示されています。
**注記**
Oracle Scheduler のデフォルトのタイムゾーンを設定することもできます。詳細については、「[Oracle Scheduler ジョブのタイムゾーンの設定](Appendix.Oracle.CommonDBATasks.Scheduler.md#Appendix.Oracle.CommonDBATasks.Scheduler.TimeZone)」を参照してください。
`alter_db_time_zone` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_new_tz` | varchar2 | — | はい | 指定したリージョンまたは協定世界時 (UTC) からの絶対オフセットとしての新しいタイムゾーン。有効なオフセットの範囲は -12:00 〜 \$114:00 です。 |
以下の例では、タイムゾーンを UTC \$1 3 時間に変更します。
```
EXEC rdsadmin.rdsadmin_util.alter_db_time_zone(p_new_tz => '+3:00');
```
以下の例では、タイムゾーンをアフリカ/アルジェーのタイムゾーンに変更します。
```
EXEC rdsadmin.rdsadmin_util.alter_db_time_zone(p_new_tz => 'Africa/Algiers');
```
`alter_db_time_zone` プロシージャを使用してタイムゾーンを変更した後、変更を有効にするために DB インスタンスを再起動します。詳細については、「[ DB インスタンスの再起動](USER_RebootInstance.md)」を参照してください。タイムゾーンのアップグレードについては、「[タイムゾーンに関する考慮事項](USER_UpgradeDBInstance.Oracle.OGPG.md#USER_UpgradeDBInstance.Oracle.OGPG.DST)」を参照してください。
# 自動ワークロードリポジトリ (AWR) を使用したパフォーマンスレポートの生成
パフォーマンスデータを収集してレポートを生成するにあたって、Oracle では自動ワークロードリポジトリ (AWR) を推奨しています。AWR には、Oracle Database Enterprise Edition と診断パックおよびチューニングパックのライセンスが必要です。AWR を有効にするには、初期化パラメータ `CONTROL_MANAGEMENT_PACK_ACCESS` に、`DIAGNOSTIC` または `DIAGNOSTIC+TUNING` を設定します。
## RDS での AWR レポートの使用
AWR レポートを生成するには、`awrrpt.sql` などのスクリプトを実行します。これらのスクリプトは、データベースホストサーバーにインストールされます。Amazon RDS では、ホストに直接アクセスすることはできません。ただし、Oracle Database の別のインストールから SQL スクリプトのコピーを取得することは可能です。
また、`SYS.DBMS_WORKLOAD_REPOSITORY` PL/SQL パッケージでプロシージャを実行して AWR を使用することもできます。このパッケージを使用して、ベースラインとスナップショットを管理したり、ASH および AWR レポートを表示したりできます。例えば、テキスト形式で AWR レポートを生成するには、`DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_TEXT` プロシージャを実行します。ただし、これらの AWR レポートには、AWS マネジメントコンソール からはアクセスできません。
AWR を使用する場合は、`rdsadmin.rdsadmin_diagnostic_util` プロシージャを使用することをお勧めします。これらのプロシージャを使用すると、次の項目を生成できます。
+ AWR レポート
+ アクティブセッション履歴 (ASH) レポート
+ 自動データベース診断モニター (ADDM) レポート
+ AWR データの Oracle Data Pump Export ダンプファイル
`rdsadmin_diagnostic_util` プロシージャは、レポートを DB インスタンスファイルシステムに保存します。これらのレポートには、コンソールからアクセスできます。`rdsadmin.rds_file_util` プロシージャを使用してレポートにアクセスしたり、S3 統合オプションを使用して Amazon S3 にコピーされたレポートにアクセスすることもできます。詳細については、「[DB インスタンスディレクトリ内のファイルの読み取り](Appendix.Oracle.CommonDBATasks.Misc.md#Appendix.Oracle.CommonDBATasks.ReadingFiles)」および「[「Amazon S3 統合」](oracle-s3-integration.md)」を参照してください。
以下の Amazon RDS for Oracle DB エンジンバージョンの `rdsadmin_diagnostic_util` 手順を使用できます。
+ すべての Oracle Database 21c バージョン
+ 19.0.0.0.ru-2020-04.rur-2020-04.r1 以上の Oracle Database 19c バージョン
レプリケーションシナリオで診断レポートを使用する方法を説明しているブログについては、「[Amazon RDS for Oracle リードレプリカの AWR レポートを生成する](https://aws.amazon.com/blogs/database/generate-awr-reports-for-amazon-rds-for-oracle-read-replicas/)」を参照してください。
## Diagnostic Utility Package の一般的なパラメータ
`rdsadmin_diagnostic_util` パッケージを使用して AWR および ADDM を管理する場合は、通常、次のパラメータを使用します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.AWR.html)
rdsadmin\$1diagnostic\$1util パッケージで ASH を管理する場合は、通常、次のパラメータを使用します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.AWR.html)
## AWR レポートの生成
AWR レポートを生成するには、`rdsadmin.rdsadmin_diagnostic_util.awr_report` の手順を使用します。
次の例は、スナップショット範囲 101～106 の AWR レポートを生成します。出力テキストファイルには `awrrpt_101_106.txt` という名前が付けられます。このレポートには、AWS マネジメントコンソール からアクセスできます。
```
EXEC rdsadmin.rdsadmin_diagnostic_util.awr_report(101,106,'TEXT');
```
次の例は、スナップショット範囲 63～65 の HTML レポートを生成します。出力 HTML ファイルには `awrrpt_63_65.html` という名前が付けられます。プロシージャによって、レポートが `AWR_RPT_DUMP` という名前のデフォルト以外のデータベースディレクトリに書き込まれます。
```
EXEC rdsadmin.rdsadmin_diagnostic_util.awr_report(63,65,'HTML','AWR_RPT_DUMP');
```
## ダンプファイルへの AWR データの抽出
AWR データをダンプファイルに抽出するには、`rdsadmin.rdsadmin_diagnostic_util.awr_extract` プロシージャを使用します。この関数は PDB レベルでのみ使用できます。
次の例は、スナップショット範囲 101～106 を抽出します。出力ダンプファイルには `awrextract_101_106.dmp` という名前が付けられます。このファイルには、コンソールからアクセスできます。
```
EXEC rdsadmin.rdsadmin_diagnostic_util.awr_extract(101,106);
```
次の例は、スナップショット範囲 63～65 を抽出します。出力ダンプファイルには `awrextract_63_65.dmp` という名前が付けられます。ファイルは、`AWR_RPT_DUMP` という名前のデフォルト以外のデータベースディレクトリに保存されます。
```
EXEC rdsadmin.rdsadmin_diagnostic_util.awr_extract(63,65,'AWR_RPT_DUMP');
```
## ADDM レポートの生成
ADDM レポートを生成するには、`rdsadmin.rdsadmin_diagnostic_util.addm_report` プロシージャを使用します。
次の例は、スナップショット範囲 101～106 の ADDM レポートを生成します。出力テキストファイルには `addmrpt_101_106.txt` という名前が付けられます。レポートには、コンソールからアクセスできます。
```
EXEC rdsadmin.rdsadmin_diagnostic_util.addm_report(101,106);
```
次の例は、スナップショット範囲 63～65 の ADDM レポートを生成します。出力テキストファイルには `addmrpt_63_65.txt` という名前が付けられます。ファイルは、`ADDM_RPT_DUMP` という名前のデフォルト以外のデータベースディレクトリに保存されます。
```
EXEC rdsadmin.rdsadmin_diagnostic_util.addm_report(63,65,'ADDM_RPT_DUMP');
```
## ASH レポートの生成
ASH レポートを生成するには、`rdsadmin.rdsadmin_diagnostic_util.ash_report` プロシージャを使用します。
次の例では、14 分前から現在の時刻までのデータを含む ASH レポートを生成します。出力ファイルの名前は `ashrptbegin_timeend_time.txt` の形式を使用し、`begin_time` および `end_time` は `YYYYMMDDHH24MISS` の形式を使用します。ファイルには、コンソールからアクセスできます。
```
BEGIN
rdsadmin.rdsadmin_diagnostic_util.ash_report(
begin_time => SYSDATE-14/1440,
end_time => SYSDATE,
report_type => 'TEXT');
END;
/
```
次の例では、2019 年 11 月 18 日の午後 6:07 から 2019 年 11 月 18 日の午後 6:15 までのデータを含む ASH レポートを生成します。出力 HTML レポートの名前は `ashrpt_20190918180700_20190918181500.html` です。レポートは、`AWR_RPT_DUMP` という名前のデフォルト以外のデータベースディレクトリに保存されます。
```
BEGIN
rdsadmin.rdsadmin_diagnostic_util.ash_report(
begin_time => TO_DATE('2019-09-18 18:07:00', 'YYYY-MM-DD HH24:MI:SS'),
end_time => TO_DATE('2019-09-18 18:15:00', 'YYYY-MM-DD HH24:MI:SS'),
report_type => 'html',
dump_directory => 'AWR_RPT_DUMP');
END;
/
```
## コンソールまたは CLI からの AWR レポートへのアクセス
AWR レポートにアクセスしたり、ダンプファイルをエクスポートしたりするには、AWS マネジメントコンソール または AWS CLI を使用します。詳細については、「[データベースログファイルのダウンロード](USER_LogAccess.Procedural.Downloading.md)」を参照してください。
# VPC の DB インスタンスで使用するデータベースリンクの調整
同じ Virtual Private Cloud (VPC) 内またはピア接続された VPC 内の Amazon RDS DB インスタンスで Oracle データベースリンクを使用するには、2 つの DB インスタンス間に有効なルートが存在する必要があります。VPC ルーティングテーブルおよびネットワークアクセス制御リスト (ACL) を使用して、DB インスタンス間の有効なルートを確認します。
各 DB インスタンスのセキュリティグループは他の DB インスタンスの受信と送信を許可する必要があります。インバウンドルールとアウトバウンドルールは、同じ VPC またはピアリング接続先 VPC からセキュリティグループを参照できます。詳細については、「[セキュリティグループの更新によるピア VPC セキュリティグループの参照](https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html#vpc-peering-security-groups)」を参照してください。
VPC で DHCP オプションセットを使用してカスタム DNS サーバーを設定した場合、カスタム DNS サーバーはデータベースリンクターゲットの名前を解決できる必要があります。詳細については、「[カスタム DNS サーバーのセットアップ](Appendix.Oracle.CommonDBATasks.System.md#Appendix.Oracle.CommonDBATasks.CustomDNS)」を参照してください。
Oracle Data Pump でのデータベースリンクの使用の詳細については、「[Oracle Data Pump を使用したインポート](Oracle.Procedural.Importing.DataPump.md)」を参照してください。
# DB インスタンスのデフォルトエディションの設定
データベースオブジェクトは、エディションと呼ばれるプライベート環境で再定義できます。エディションベースの再定義を使用して、最小限のダウンタイムでアプリケーションのデータベースオブジェクトをアップグレードできます。
Amazon RDS Oracle DB インスタンスのデフォルトエディションは、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.alter_default_edition` を使用して設定できます。
次の例では、Amazon RDS Oracle DB インスタンスのデフォルトエディションを `RELEASE_V1` に設定します。
```
EXEC rdsadmin.rdsadmin_util.alter_default_edition('RELEASE_V1');
```
次の例では、Amazon RDS Oracle DB インスタンスのデフォルトエディションを Oracle のデフォルトに設定し直します。
```
EXEC rdsadmin.rdsadmin_util.alter_default_edition('ORA$BASE');
```
Oracle エディションベースの再定義の詳細については、Oracle ドキュメントの「[エディションおよびエディションに基づく再定義の概要](https://docs.oracle.com/database/121/ADMIN/general.htm#ADMIN13167)」を参照してください。
# SYS.AUD\$1 テーブルの監査を有効にする
データベースの監査証跡テーブル `SYS.AUD$` の監査を有効にするには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_master_util.audit_all_sys_aud_table` を使用します。サポートされている監査プロパティは、`ALL` のみです。個々のステートメントまたはオペレーションは監査することもしないこともできません。
監査の有効化は、次のバージョンを実行している Oracle DB インスタンスでサポートされています。
+ Oracle Database 21c (21.0.0)
+ Oracle Database 19c (19.0.0)
`audit_all_sys_aud_table` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_by_access` | boolean | true | いいえ | `true` を監査するには、`BY ACCESS` に設定します。`false` を監査するには、`BY SESSION` に設定します。 |
以下のクエリでは、データベースの `SYS.AUD$` に対する現在の監査設定が返ります。
```
SELECT * FROM DBA_OBJ_AUDIT_OPTS WHERE OWNER='SYS' AND OBJECT_NAME='AUD$';
```
以下のコマンドでは、`ALL` `SYS.AUD$` の `BY ACCESS` の監査を有効にします。
```
EXEC rdsadmin.rdsadmin_master_util.audit_all_sys_aud_table;
EXEC rdsadmin.rdsadmin_master_util.audit_all_sys_aud_table(p_by_access => true);
```
以下のコマンドでは、`ALL` `SYS.AUD$` の `BY SESSION` の監査を有効にします。
```
EXEC rdsadmin.rdsadmin_master_util.audit_all_sys_aud_table(p_by_access => false);
```
詳細については、Oracle ドキュメントの「[AUDIT (従来の監査)](https://docs.oracle.com/en/database/oracle/oracle-database/12.2/sqlrf/AUDIT-Traditional-Auditing.html#GUID-ADF45B07-547A-4096-8144-50241FA2D8DD)」を参照してください。
# SYS.AUD\$1 テーブルの監査を無効にする
データベースの監査証跡テーブル `SYS.AUD$` の監査を無効にするには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_master_util.noaudit_all_sys_aud_table` を使用します。この手順では、パラメータは使用しません。
以下のクエリでは、データベースの `SYS.AUD$` に対する現在の監査設定が返ります。
```
SELECT * FROM DBA_OBJ_AUDIT_OPTS WHERE OWNER='SYS' AND OBJECT_NAME='AUD$';
```
以下のコマンドでは、`ALL` の `SYS.AUD$` の監査が無効にされます。
```
EXEC rdsadmin.rdsadmin_master_util.noaudit_all_sys_aud_table;
```
詳細については、Oracle ドキュメントの「[NOAUDIT (従来の監査)](https://docs.oracle.com/en/database/oracle/oracle-database/12.2/sqlrf/NOAUDIT-Traditional-Auditing.html#GUID-9D8EAF18-4AB3-4C04-8BF7-37BD0E15434D)」を参照してください。
# 中断したオンラインインデックス構築のクリーンアップ
失敗したオンラインインデックス構築をクリーンアップするには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_dbms_repair.online_index_clean` を使用します。
`online_index_clean` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `object_id` | binary\$1integer | `ALL_INDEX_ID` | いいえ | インデックスのオブジェクト ID。通常、ORA-08104 エラーテキストからのオブジェクト ID を使用できます。 |
| `wait_for_lock` | binary\$1integer | `rdsadmin.rdsadmin_dbms_repair.lock_wait` | いいえ | デフォルトの `rdsadmin.rdsadmin_dbms_repair.lock_wait` を指定して、基盤となるオブジェクトのロックを取得することを試みます。ロックが失敗した場合は、内部制限に達するまで再試行できます。 `rdsadmin.rdsadmin_dbms_repair.lock_nowait` を指定して、基盤となるオブジェクトのロックを取得することを試みることができますが、ロックが失敗すると再試行はできません。 |
以下の例は、失敗したオンラインインデックス構築のクリーンアップを示しています。
```
declare
is_clean boolean;
begin
is_clean := rdsadmin.rdsadmin_dbms_repair.online_index_clean(
object_id => 1234567890,
wait_for_lock => rdsadmin.rdsadmin_dbms_repair.lock_nowait
);
end;
/
```
詳細については、Oracle ドキュメントの「[ONLINE\$1INDEX\$1CLEAN Function](https://docs.oracle.com/database/121/ARPLS/d_repair.htm#ARPLS67555)」を参照してください。
# 破損ブロックのスキップ
インデックスとテーブルのスキャンの中に破損ブロックをスキップするには、`rdsadmin.rdsadmin_dbms_repair` パッケージを使用します。
以下の手順では、`sys.dbms_repair.admin_table` 手順の機能をラップし、パラメータを取得しません。
+ `rdsadmin.rdsadmin_dbms_repair.create_repair_table`
+ `rdsadmin.rdsadmin_dbms_repair.create_orphan_keys_table`
+ `rdsadmin.rdsadmin_dbms_repair.drop_repair_table`
+ `rdsadmin.rdsadmin_dbms_repair.drop_orphan_keys_table`
+ `rdsadmin.rdsadmin_dbms_repair.purge_repair_table`
+ `rdsadmin.rdsadmin_dbms_repair.purge_orphan_keys_table`
以下の手順では、Oracle データベースの `DBMS_REPAIR` パッケージの対応物として、同じパラメータを取得します。
+ `rdsadmin.rdsadmin_dbms_repair.check_object`
+ `rdsadmin.rdsadmin_dbms_repair.dump_orphan_keys`
+ `rdsadmin.rdsadmin_dbms_repair.fix_corrupt_blocks`
+ `rdsadmin.rdsadmin_dbms_repair.rebuild_freelists`
+ `rdsadmin.rdsadmin_dbms_repair.segment_fix_status`
+ `rdsadmin.rdsadmin_dbms_repair.skip_corrupt_blocks`
データベースの破損の処理の詳細については、Oracle のドキュメントの「[DBMS\$1REPAIR](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_REPAIR.html#GUID-B8EC4AB3-4D6A-46C9-857F-4ED53CD9C948)」を参照してください。
**Example 破損ブロックへの対応**
この例では、破損ブロックに応答するための基本的なワークフローを示しています。ステップは、ブロックの破損の場所と性質によって異なります。
破損ブロックを修復する前に、「[DBMS\$1REPAIR](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_REPAIR.html#GUID-B8EC4AB3-4D6A-46C9-857F-4ED53CD9C948)」ドキュメントをよく確認してください。
**インデックスとテーブルのスキャン中に破損ブロックをスキップするには**
1. 修復テーブルが存在しない場合は、以下のプロシージャを実行して作成します。
```
EXEC rdsadmin.rdsadmin_dbms_repair.create_repair_table;
EXEC rdsadmin.rdsadmin_dbms_repair.create_orphan_keys_table;
```
1. 適切な場合は、以下の手順を実行して、既存のレコードを確認し、消去します。
```
SELECT COUNT(*) FROM SYS.REPAIR_TABLE;
SELECT COUNT(*) FROM SYS.ORPHAN_KEY_TABLE;
SELECT COUNT(*) FROM SYS.DBA_REPAIR_TABLE;
SELECT COUNT(*) FROM SYS.DBA_ORPHAN_KEY_TABLE;
EXEC rdsadmin.rdsadmin_dbms_repair.purge_repair_table;
EXEC rdsadmin.rdsadmin_dbms_repair.purge_orphan_keys_table;
```
1. 以下の手順を実行して、破損ブロックを確認します。
```
SET SERVEROUTPUT ON
DECLARE v_num_corrupt INT;
BEGIN
v_num_corrupt := 0;
rdsadmin.rdsadmin_dbms_repair.check_object (
schema_name => '&corruptionOwner',
object_name => '&corruptionTable',
corrupt_count => v_num_corrupt
);
dbms_output.put_line('number corrupt: '||to_char(v_num_corrupt));
END;
/
COL CORRUPT_DESCRIPTION FORMAT a30
COL REPAIR_DESCRIPTION FORMAT a30
SELECT OBJECT_NAME, BLOCK_ID, CORRUPT_TYPE, MARKED_CORRUPT,
CORRUPT_DESCRIPTION, REPAIR_DESCRIPTION
FROM SYS.REPAIR_TABLE;
SELECT SKIP_CORRUPT
FROM DBA_TABLES
WHERE OWNER = '&corruptionOwner'
AND TABLE_NAME = '&corruptionTable';
```
1. `skip_corrupt_blocks` プロシージャを使用して、該当するテーブルの破損スキップを有効または無効にします。状況によっては、新しいテーブルにデータを抽出してから、破損ブロックを含むテーブルを削除することが必要になる場合もあります。
以下の手順を実行して、該当するテーブルの破損スキップを有効にします。
```
begin
rdsadmin.rdsadmin_dbms_repair.skip_corrupt_blocks (
schema_name => '&corruptionOwner',
object_name => '&corruptionTable',
object_type => rdsadmin.rdsadmin_dbms_repair.table_object,
flags => rdsadmin.rdsadmin_dbms_repair.skip_flag);
end;
/
select skip_corrupt from dba_tables where owner = '&corruptionOwner' and table_name = '&corruptionTable';
```
以下の手順を実行して、破損スキップを無効にします。
```
begin
rdsadmin.rdsadmin_dbms_repair.skip_corrupt_blocks (
schema_name => '&corruptionOwner',
object_name => '&corruptionTable',
object_type => rdsadmin.rdsadmin_dbms_repair.table_object,
flags => rdsadmin.rdsadmin_dbms_repair.noskip_flag);
end;
/
select skip_corrupt from dba_tables where owner = '&corruptionOwner' and table_name = '&corruptionTable';
```
1. すべての修復作業が完了したら、以下の手順を実行して修復テーブルを削除します。
```
EXEC rdsadmin.rdsadmin_dbms_repair.drop_repair_table;
EXEC rdsadmin.rdsadmin_dbms_repair.drop_orphan_keys_table;
```
## ごみ箱を空にする
テーブルを削除しても、Oracle データベースはただちにストレージ領域を削除しません。データベースによってテーブルの名前が変更され、テーブルと関連オブジェクトがごみ箱に入れられます。ごみ箱を空にすると、これらのアイテムが削除され、ストレージ領域が解放されます。
ごみ箱全体を空にするには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.purge_dba_recyclebin` を使用します。ただし、このプロシージャでは、 `SYS` および `RDSADMIN` オブジェクトのごみ箱は空になりません。これらのオブジェクトを消去する必要がある場合は、AWS サポートにお問い合わせください。
次の例は、ごみ箱全体を空にします。
```
EXEC rdsadmin.rdsadmin_util.purge_dba_recyclebin;
```
# フルリダクションのデフォルト表示値の設定
Amazon RDS Oracle インスタンスでの完全リダクションのデフォルトの表示値を変更するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.dbms_redact_upd_full_rdct_val` を使用します。リダクションポリシーは、Oracle データベースのドキュメントで説明されているように、`DBMS_REDACT` PL/SQL パッケージを使用して作成することに注意してください。`dbms_redact_upd_full_rdct_val` プロシージャは、既存のポリシーの影響を受けるさまざまなデータ型について表示する文字を指定します。
`dbms_redact_upd_full_rdct_val` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_number_val` | 数値 | Null | いいえ | `NUMBER` データ型の列のデフォルト値を変更します。 |
| `p_binfloat_val` | binary\$1float | Null | いいえ | `BINARY_FLOAT` データ型の列のデフォルト値を変更します。 |
| `p_bindouble_val` | binary\$1double | Null | いいえ | `BINARY_DOUBLE` データ型の列のデフォルト値を変更します。 |
| `p_char_val` | char | Null | いいえ | `CHAR` データ型の列のデフォルト値を変更します。 |
| `p_varchar_val` | varchar2 | Null | いいえ | `VARCHAR2` データ型の列のデフォルト値を変更します。 |
| `p_nchar_val` | nchar | Null | いいえ | `NCHAR` データ型の列のデフォルト値を変更します。 |
| `p_nvarchar_val` | nvarchar2 | Null | いいえ | `NVARCHAR2` データ型の列のデフォルト値を変更します。 |
| `p_date_val` | date | Null | いいえ | `DATE` データ型の列のデフォルト値を変更します。 |
| `p_ts_val` | timestamp | Null | いいえ | `TIMESTAMP` データ型の列のデフォルト値を変更します。 |
| `p_tswtz_val` | timestamp with time zone | Null | いいえ | `TIMESTAMP WITH TIME ZONE` データ型の列のデフォルト値を変更します。 |
| `p_blob_val` | blob | Null | いいえ | `BLOB` データ型の列のデフォルト値を変更します。 |
| `p_clob_val` | clob | Null | いいえ | `CLOB` データ型の列のデフォルト値を変更します。 |
| `p_nclob_val` | nclob | Null | いいえ | `NCLOB` データ型の列のデフォルト値を変更します。 |
次の例では、`CHAR` データ型のデフォルトのリダクション値を \$1 に変更します。
```
EXEC rdsadmin.rdsadmin_util.dbms_redact_upd_full_rdct_val(p_char_val => '*');
```
次の例では、`NUMBER`、`DATE`、および `CHAR` データ型のデフォルトのリダクション値を変更します。
```
BEGIN
rdsadmin.rdsadmin_util.dbms_redact_upd_full_rdct_val(
p_number_val=>1,
p_date_val=>to_date('1900-01-01','YYYY-MM-DD'),
p_varchar_val=>'X');
END;
/
```
`dbms_redact_upd_full_rdct_val` プロシージャを使用してフルリダクションのデフォルト値を変更した後、変更を有効にするために DB インスタンスを再起動します。詳細については、「[ DB インスタンスの再起動](USER_RebootInstance.md)」を参照してください。
# Oracle DB インスタンスの一般的なログ関連タスクの実行
次に、Oracle を実行している Amazon RDS DB インスタンスへのログ記録に関連する一般的な DBA タスクの実行方法を示します。マネージド型サービスの操作性を実現するために、Amazon RDS では DB インスタンスへのシェルアクセスは提供していません。また、上位の権限を必要とする特定のシステムプロシージャやシステムテーブルへのアクセスが制限されます。
詳細については、「[Amazon RDS for Oracle データベースのログファイル](USER_LogAccess.Concepts.Oracle.md)」を参照してください。
**Topics**
+ [強制ログ作成の設定](#Appendix.Oracle.CommonDBATasks.SettingForceLogging)
+ [サプリメンタルロギングの設定](#Appendix.Oracle.CommonDBATasks.AddingSupplementalLogging)
+ [オンラインログファイルを切り替える](#Appendix.Oracle.CommonDBATasks.SwitchingLogfiles)
+ [オンライン REDO ログの追加](#Appendix.Oracle.CommonDBATasks.RedoLogs)
+ [オンライン REDO ログの削除](#Appendix.Oracle.CommonDBATasks.DroppingRedoLogs)
+ [オンライン REDO ログのサイズ変更](Appendix.Oracle.CommonDBATasks.ResizingRedoLogs.md)
+ [アーカイブ REDO ログの保持](Appendix.Oracle.CommonDBATasks.RetainRedoLogs.md)
+ [オンライン およびアーカイブ REDO ログへのアクセス](Appendix.Oracle.CommonDBATasks.Log.Download.md)
+ [Amazon S3 からのアーカイブ REDO ログのダウンロード](Appendix.Oracle.CommonDBATasks.download-redo-logs.md)
## 強制ログ作成の設定
強制ログ作成モードでは、Oracle はテンポラリテーブルスペースとテンポラリセグメントの変更を除き、すべての変更をデータベースに記録します (`NOLOGGING` 句は無視されます)。詳細については、Oracle ドキュメントの「[FORCE LOGGING モードの指定](https://docs.oracle.com/cd/E11882_01/server.112/e25494/create.htm#ADMIN11096)」を参照してください。
強制ログ作成を設定するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.force_logging` を使用します。`force_logging` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | はい | 説明 |
| --- | --- | --- | --- | --- |
| `p_enable` | boolean | true | いいえ | データベースを強制ログ作成モードに設定するには `true`、データベースを強制ログ作成モードから解除するには `false` に設定します。 |
次の例では、データベースを強制ログ作成モードに設定します。
```
EXEC rdsadmin.rdsadmin_util.force_logging(p_enable => true);
```
## サプリメンタルロギングの設定
補足的なログ記録を有効にすると、LogMiner には、チェーンされた行とクラスター化されたテーブルをサポートするために必要な情報が表示されます。サプリメンタルロギングの詳細については、Oracle ドキュメントの「[サプリメンタルロギング](https://docs.oracle.com/cd/E11882_01/server.112/e22490/logminer.htm#SUTIL1582)」を参照してください。
Oracle データベースでは、デフォルトではサプリメンタルロギングが有効になっていません。サプリメンタルロギングを有効/無効にするには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.alter_supplemental_logging` を使用します。Amazon RDS が Oracle DB インスタンスのアーカイブ REDO ログの保持を管理する方法の詳細については、「[アーカイブ REDO ログの保持](Appendix.Oracle.CommonDBATasks.RetainRedoLogs.md)」を参照してください。
`alter_supplemental_logging` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_action` | varchar2 | — | はい | サプリメンタルロギングを追加するには `'ADD'`、サプリメンタルロギングを削除するには `'DROP'`。 |
| `p_type` | varchar2 | null | いいえ | サプリメンタルロギングのタイプ。有効な値は、`'ALL'`、`'FOREIGN KEY'`、`'PRIMARY KEY'`、`'UNIQUE'`、`PROCEDURAL` のいずれかです。 |
次の例では、補足ログを有効にします。
```
begin
rdsadmin.rdsadmin_util.alter_supplemental_logging(
p_action => 'ADD');
end;
/
```
次の例では、すべての固定長の最大サイズの列に対して補足ログを有効にします。
```
begin
rdsadmin.rdsadmin_util.alter_supplemental_logging(
p_action => 'ADD',
p_type => 'ALL');
end;
/
```
次の例では、プライマリキー列に対して補足ログを有効にします。
```
begin
rdsadmin.rdsadmin_util.alter_supplemental_logging(
p_action => 'ADD',
p_type => 'PRIMARY KEY');
end;
/
```
## オンラインログファイルを切り替える
ログファイルを切り替えるには、Amazon RDS のプロシージャ `rdsadmin.rdsadmin_util.switch_logfile` を使用します。`switch_logfile` プロシージャにはパラメータはありません。
次の例では、ログファイルを切り替えています。
```
EXEC rdsadmin.rdsadmin_util.switch_logfile;
```
## オンライン REDO ログの追加
Oracle を実行している Amazon RDS DB インスタンスには、初期から 4 つのオンライン REDO ログ (それぞれ 128 MB) があります。別の REDO ログを追加するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.add_logfile` を使用します。
`add_logfile` プロシージャには以下のパラメータがあります。
**注記**
パラメータは相互に排他的です。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `bytes` | positive | null | いいえ | ログファイルのサイズ (バイト単位)。 このパラメータは、ログのサイズが 2,147,483,648 バイト (2 GiB) 未満の場合にのみ使用します。それ以外の場合、RDS はエラーを発行します。このバイト値を超えるログサイズの場合は、代わりに `p_size` パラメータを使用します。 |
| `p_size` | varchar2 | — | はい | ログファイルのサイズは、キロバイト (K)、メガバイト (M)、またはギガバイト (G) です。 |
次のコマンドは 100 MB のログファイルを追加します。
```
EXEC rdsadmin.rdsadmin_util.add_logfile(p_size => '100M');
```
## オンライン REDO ログの削除
REDO ログを削除するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.drop_logfile` を使用します。`drop_logfile` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `grp` | positive | — | はい | ログのグループ番号。 |
次の例では、グループ番号 3 のログを削除します。
```
EXEC rdsadmin.rdsadmin_util.drop_logfile(grp => 3);
```
ステータスが未使用または非アクティブのログのみを削除できます。次の例では、ログのステータスを取得します。
```
SELECT GROUP#, STATUS FROM V$LOG;
GROUP# STATUS
---------- ----------------
1 CURRENT
2 INACTIVE
3 INACTIVE
4 UNUSED
```
# オンライン REDO ログのサイズ変更
Oracle を実行している Amazon RDS DB インスタンスには、初期から 4 つのオンライン REDO ログ (それぞれ 128 MB) があります。次の例では、Amazon RDS プロシージャを使用してログをそれぞれ 128 MB から 512 MB にサイズ変更する方法を示します。
```
/* Query V$LOG to see the logs. */
/* You start with 4 logs of 128 MB each. */
SELECT GROUP#, BYTES, STATUS FROM V$LOG;
GROUP# BYTES STATUS
---------- ---------- ----------------
1 134217728 INACTIVE
2 134217728 CURRENT
3 134217728 INACTIVE
4 134217728 INACTIVE
/* Add four new logs that are each 512 MB */
EXEC rdsadmin.rdsadmin_util.add_logfile(bytes => 536870912);
EXEC rdsadmin.rdsadmin_util.add_logfile(bytes => 536870912);
EXEC rdsadmin.rdsadmin_util.add_logfile(bytes => 536870912);
EXEC rdsadmin.rdsadmin_util.add_logfile(bytes => 536870912);
/* Query V$LOG to see the logs. */
/* Now there are 8 logs. */
SELECT GROUP#, BYTES, STATUS FROM V$LOG;
GROUP# BYTES STATUS
---------- ---------- ----------------
1 134217728 INACTIVE
2 134217728 CURRENT
3 134217728 INACTIVE
4 134217728 INACTIVE
5 536870912 UNUSED
6 536870912 UNUSED
7 536870912 UNUSED
8 536870912 UNUSED
/* Drop each inactive log using the group number. */
EXEC rdsadmin.rdsadmin_util.drop_logfile(grp => 1);
EXEC rdsadmin.rdsadmin_util.drop_logfile(grp => 3);
EXEC rdsadmin.rdsadmin_util.drop_logfile(grp => 4);
/* Query V$LOG to see the logs. */
/* Now there are 5 logs. */
select GROUP#, BYTES, STATUS from V$LOG;
GROUP# BYTES STATUS
---------- ---------- ----------------
2 134217728 CURRENT
5 536870912 UNUSED
6 536870912 UNUSED
7 536870912 UNUSED
8 536870912 UNUSED
/* Switch logs so that group 2 is no longer current. */
EXEC rdsadmin.rdsadmin_util.switch_logfile;
/* Query V$LOG to see the logs. */
/* Now one of the new logs is current. */
SQL>SELECT GROUP#, BYTES, STATUS FROM V$LOG;
GROUP# BYTES STATUS
---------- ---------- ----------------
2 134217728 ACTIVE
5 536870912 CURRENT
6 536870912 UNUSED
7 536870912 UNUSED
8 536870912 UNUSED
/* If the status of log 2 is still "ACTIVE", issue a checkpoint to clear it to "INACTIVE". */
EXEC rdsadmin.rdsadmin_util.checkpoint;
/* Query V$LOG to see the logs. */
/* Now the final original log is inactive. */
select GROUP#, BYTES, STATUS from V$LOG;
GROUP# BYTES STATUS
---------- ---------- ----------------
2 134217728 INACTIVE
5 536870912 CURRENT
6 536870912 UNUSED
7 536870912 UNUSED
8 536870912 UNUSED
# Drop the final inactive log.
EXEC rdsadmin.rdsadmin_util.drop_logfile(grp => 2);
/* Query V$LOG to see the logs. */
/* Now there are four 512 MB logs. */
SELECT GROUP#, BYTES, STATUS FROM V$LOG;
GROUP# BYTES STATUS
---------- ---------- ----------------
5 536870912 CURRENT
6 536870912 UNUSED
7 536870912 UNUSED
8 536870912 UNUSED
```
# アーカイブ REDO ログの保持
アーカイブ REDO ログを、Oracle LogMiner (`DBMS_LOGMNR`) などの製品で使用できるように DB インスタンスにローカルで保持できます。REDO ログを保持した後、LogMiner を使用してログを分析できます。詳細については、Oracle ドキュメントの「[LogMiner を使用した REDO ログファイルの分析](http://docs.oracle.com/cd/E11882_01/server.112/e22490/logminer.htm)」を参照してください。
アーカイブされた REDO ログを保持するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.set_configuration` を使用します。この手順を Oracle Data Guard のプライマリインスタンスで使用すると、RDS はプライマリインスタンスとオープンリードレプリカでのアーカイブログ保持設定を変更しますが、マウントされたレプリカでは変更しません。RDS は、マウントされたレプリカに最新のアーカイブ REDO ログを短期間保持します。RDS は、マウントされたレプリカにダウンロードされた古いログを自動的に削除します。
`set_configuration` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `name` | varchar | — | はい | 更新する設定の名前。アーカイブ REDO ログの保持時間を変更するには、名前を `archivelog retention hours` に設定します。 |
| `value` | varchar | — | はい | 設定の値。値をログを保持する時間数に設定します。 |
次の例では、24 時間分の REDO ログを保持します。
```
begin
rdsadmin.rdsadmin_util.set_configuration(
name => 'archivelog retention hours',
value => '24');
end;
/
commit;
```
**注記**
変更を反映するにはコミットが必要です。
アーカイブ REDOログが DB インスタンスに保持される期間を表示するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.show_configuration` を使用します。
次の例は、ログの保持時間を示しています。
```
set serveroutput on
EXEC rdsadmin.rdsadmin_util.show_configuration;
```
出力は、`archivelog retention hours` の現在の設定を示します。次の出力は、アーカイブ REDO ログを 48 時間保持することを示しています。
```
NAME:archivelog retention hours
VALUE:48
DESCRIPTION:ArchiveLog expiration specifies the duration in hours before archive/redo log files are automatically deleted.
```
アーカイブ REDO ログは、DB インスタンス上に保持されるので、DB インスタンスにログ用の十分な割り当て済みストレージがあることを確認します。DB インスタンスが過去 X 時間に使用した容量を調べるには、次のクエリを実行できます。X は時間数に置き換えます。
```
SELECT SUM(BLOCKS * BLOCK_SIZE) bytes
FROM V$ARCHIVED_LOG
WHERE FIRST_TIME >= SYSDATE-(X/24) AND DEST_ID=1;
```
DB インスタンスのバックアップ保持期間にゼロより大きな値が設定されている場合のみ、RDS for Oracle がアーカイブ REDO ログを生成します。デフォルトでは、バックアップ保持期間は 0 より大きな値になっています。
アーカイブされたログの保持期間が終了すると、RDS for Oracle はアーカイブされた REDO ログを、DB インスタンスから削除します。DB インスタンスを特定の時点の状態に復元できるようにするために、Amazon RDS は、アーカイブされた REDO ログを、バックアップ保持期間に基づいて DB インスタンスの外部に保持します。バックアップ保持期間の変更方法については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
**注記**
アーカイブ REDO ログをダウンロードするために JDBC を Linux で使用している場合、レイテンシー時間と接続のリセットが長くなることがあります。このような場合、原因は Java クライアントの乱数ジェネレーターのデフォルト設定にある可能性があります。ブロックしない乱数ジェネレーターを使用するように JDBC ドライバを設定することをお勧めします。
# オンライン およびアーカイブ REDO ログへのアクセス
GoldenGate、Attunity、Informatica などの外部ツールを使用して、オンライン REDO ログファイルやアーカイブ REDO ログファイルにアクセスすることがあります。これらのファイルにアクセスするには、次の手順を実行します。
1. 物理ファイルパスへの読み取り専用アクセスを提供する、ディレクトリオブジェクトを作成します。
`rdsadmin.rdsadmin_master_util.create_archivelog_dir` および `rdsadmin.rdsadmin_master_util.create_onlinelog_dir` を使用します。
1. PL/SQL を使用してファイルを読み取ります。
ファイルは、PL/SQL により読み取ることができます。ディレクトリオブジェクトからファイルを読み込む方法については、「[DB インスタンスディレクトリ内のファイルのリスト化](Appendix.Oracle.CommonDBATasks.Misc.md#Appendix.Oracle.CommonDBATasks.ListDirectories)」および「[DB インスタンスディレクトリ内のファイルの読み取り](Appendix.Oracle.CommonDBATasks.Misc.md#Appendix.Oracle.CommonDBATasks.ReadingFiles)」を参照してください。
トランザクションログへのアクセスがサポートされるのは、以下のリリースです。
+ Oracle Database 21c
+ Oracle Database 19c
以下のコードでは、オンライン REDO ログファイルやアーカイブ REDO ログファイルに読み取り専用アクセスを提供するディレクトリが作成されます。
**重要**
また、このコードによって、`DROP ANY DIRECTORY` 権限は取り消されます。
```
EXEC rdsadmin.rdsadmin_master_util.create_archivelog_dir;
EXEC rdsadmin.rdsadmin_master_util.create_onlinelog_dir;
```
次のコードでは、オンラインの REDO ログファイルやアーカイブ REDO ログファイルのディレクトリを削除します。
```
EXEC rdsadmin.rdsadmin_master_util.drop_archivelog_dir;
EXEC rdsadmin.rdsadmin_master_util.drop_onlinelog_dir;
```
次のコードでは、`DROP ANY DIRECTORY` 権限の付与と取り消しを行います。
```
EXEC rdsadmin.rdsadmin_master_util.revoke_drop_any_directory;
EXEC rdsadmin.rdsadmin_master_util.grant_drop_any_directory;
```
# Amazon S3 からのアーカイブ REDO ログのダウンロード
`rdsadmin.rdsadmin_archive_log_download` パッケージを使用して、アーカイブ REDO ログを DB インスタンスにダウンロードできます。アーカイブ REDO ログが DB インスタンス上から失われた場合は、Amazon S3 から再度ダウンロードすることが可能です。その後、ログを取り出したり、データベースの復旧またはレプリケート用に使用したりできます。
**注記**
アーカイブされた REDO ログは、リードレプリカインスタンスにダウンロードすることはできません。
## アーカイブ RED Oログのダウンロード:基本的なステップ
アーカイブ REDO ログを使用できるかどうかは、以下に挙げる保存ポリシーによって異なります。
+ バックアップ保持ポリシー - このポリシー内のログは Amazon S3 で使用できます。このポリシー外のログは削除されています。
+ アーカイブログ保持ポリシー - このポリシー内のログは、DB インスタンスで使用できます。このポリシー外のログは削除されています。
インスタンスにログがなく、バックアップ保持期間によって保護されている場合は、`rdsadmin.rdsadmin_archive_log_download` を使用して、再度ダウンロードしてください。RDS for Oracle は、ログをDB インスタンスの `/rdsdbdata/log/arch` ディレクトリに保存します。
**Amazon S3 からアーカイブ REDO ログをダウンロードするには**
1. 保持期間を設定して、ダウンロードしたアーカイブ REDO ログを必要な期間保持します。忘れずに変更を `COMMIT` します。
RDS は、ダウンロードしたログを、ログがダウンロードされた時点から、アーカイブされたログ保持ポリシーに従って保持します。保持ポリシーを設定する方法については、「[アーカイブ REDO ログの保持](Appendix.Oracle.CommonDBATasks.RetainRedoLogs.md)」を参照してください。
1. アーカイブログの保持ポリシーに対する変更が有効になるまで、最大 5 分待機します。
1. `rdsadmin.rdsadmin_archive_log_download` により、アーカイブ REDO ログを Amazon S3 からダウンロードします。
詳細については、「[単一のアーカイブ REDO ログのダウンロード](#Appendix.Oracle.CommonDBATasks.download-redo-logs.single-log)」および「[一連のアーカイブ REDO ログのダウンロード](#Appendix.Oracle.CommonDBATasks.download-redo-logs.series)」を参照してください。
**注記**
RDS は、ダウンロードの実行前に、利用可能なストレージを自動的に確認します。要求されたログで大量の領域が消費される場合は、アラートが表示されます。
1. Amazon S3 からのログのダウンロードが、正常に実行されたことを確認します。
ダウンロードタスクのステータスは、bdump ファイルで確認できます。bdump ファイルには、パス名 `/rdsdbdata/log/trace/dbtask-task-id.log` が含まれています。前出のダウンロードステップで実行した `SELECT` ステートメントでは、タスク ID が `VARCHAR2` データ型で返されます。詳細については、「[ファイル転送のステータスをモニタリングする](oracle-s3-integration.using.md#oracle-s3-integration.using.task-status)」で類似の例をご確認ください。
## 単一のアーカイブ REDO ログのダウンロード
単一のアーカイブ REDO ログを `/rdsdbdata/log/arch` ディレクトリにダウンロードするには、`rdsadmin.rdsadmin_archive_log_download.download_log_with_seqnum` を使用します。このプロシージャには次のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `seqnum` | number | — | はい | アーカイブ REDO ログのシーケンス番号。 |
次の例では、シーケンス番号 20 のログをダウンロードしています。
```
SELECT rdsadmin.rdsadmin_archive_log_download.download_log_with_seqnum(seqnum => 20)
AS TASK_ID
FROM DUAL;
```
## 一連のアーカイブ REDO ログのダウンロード
一連のアーカイブ REDO ログを `/rdsdbdata/log/arch` ディレクトリにダウンロードするには、`download_logs_in_seqnum_range` を使用します。ダウンロードできるログの数は、リクエストごとに 300 に制限されています。`download_logs_in_seqnum_range` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `start_seq` | number | — | はい | 全体のスタートシーケンス番号。 |
| `end_seq` | number | — | はい | 全体の終了シーケンス番号。 |
次の例では、シーケンス番号が 50 から 100 までのログをダウンロードしています。
```
SELECT rdsadmin.rdsadmin_archive_log_download.download_logs_in_seqnum_range(start_seq => 50, end_seq => 100)
AS TASK_ID
FROM DUAL;
```
# Oracle DB インスタンスの一般的な RMAN タスクの実行
次のセクションでは、Oracle を実行している Amazon RDS DB インスタンスで Oracle Recovery Manager (RMAN) DBA タスクを実行する方法について説明します。マネージドサービスエクスペリエンスを提供するために、Amazon RDS は DB インスタンスへのシェルアクセスを提供していません。また、高度な特権を必要とする特定のシステムプロシージャやテーブルへのアクセスを制限しています。
Amazon RDS パッケージ `rdsadmin.rdsadmin_rman_util` を使用して、Amazon RDS for Oracle データベースのディスクへの RMAN バックアップを実行します。`rdsadmin.rdsadmin_rman_util` パッケージは、データベースファイル、テーブルスペース、およびアーカイブされた REDO ログの完全バックアップと増分バックアップをサポートしています。
RMAN バックアップが完了したら、バックアップファイルを Amazon RDS for Oracle DB インスタンスホスト以外にコピーできます。これを行うのは、RDS ホスト以外に復元してバックアップを長期保存するためです。例えば、バックアップファイルを Amazon S3 バケットにコピーできます。詳細については、「[「Amazon S3 統合」](oracle-s3-integration.md)」を参照してください。
RMAN バックアップのバックアップファイルは、手動で削除するまでは、Amazon RDS DB インスタンスホストに残ります。ディレクトリからファイルを削除するには、Oracle プロシージャ `UTL_FILE.FREMOVE` を使用できます。詳細については、Oracle データベースドキュメントの「[FREMOVE プロシージャ](https://docs.oracle.com/database/121/ARPLS/u_file.htm#ARPLS70924)」を参照してください。
RMAN を使用して RDS for Oracle DB インスタンスを復元することはできません。ただし、RMAN を使用して、バックアップをオンプレミスまたは Amazon EC2 インスタンスに復元することはできます。詳細については、ブログ記事「[Amazon RDS for Oracle インスタンスをセルフマネージドインスタンスに復元する](https://aws.amazon.com/blogs/database/restore-an-amazon-rds-for-oracle-instance-to-a-self-managed-instance/)」を参照してください。
**注記**
Amazon RDS for Oracle の別の DB インスタンスにバックアップして復元するには、引き続き Amazon RDS のバックアップおよび復元機能を使用できます。詳細については、「[データのバックアップ、復元、エクスポート](CHAP_CommonTasks.BackupRestore.md)」を参照してください。
**Topics**
+ [RMAN バックアップの前提条件](Appendix.Oracle.CommonDBATasks.RMAN-requirements.md)
+ [RMAN プロシージャの共通パラメータ](Appendix.Oracle.CommonDBATasks.CommonParameters.md)
+ [RDS for Oracle でのデータベースファイルの検証](Appendix.Oracle.CommonDBATasks.ValidateDBFiles.md)
+ [ブロック変更追跡の有効化/無効化](Appendix.Oracle.CommonDBATasks.BlockChangeTracking.md)
+ [アーカイブ REDO ログのクロスチェック](Appendix.Oracle.CommonDBATasks.Crosscheck.md)
+ [アーカイブ REDO ログファイルのバックアップ](Appendix.Oracle.CommonDBATasks.BackupArchivedLogs.md)
+ [データベースの完全バックアップの実行](Appendix.Oracle.CommonDBATasks.BackupDatabaseFull.md)
+ [テナントデータベースの完全バックアップの実行](Appendix.Oracle.CommonDBATasks.BackupTenantDatabaseFull.md)
+ [データベースの増分バックアップの実行](Appendix.Oracle.CommonDBATasks.BackupDatabaseIncremental.md)
+ [テナントデータベースの増分バックアップの実行](Appendix.Oracle.CommonDBATasks.BackupTenantDatabaseIncremental.md)
+ [テーブルスペースのバックアップ](Appendix.Oracle.CommonDBATasks.BackupTablespace.md)
+ [コントロールファイルのバックアップ](Appendix.Oracle.CommonDBATasks.backup-control-file.md)
+ [ブロックメディアリカバリの実行](Appendix.Oracle.CommonDBATasks.block-media-recovery.md)
# RMAN バックアップの前提条件
`rdsadmin.rdsadmin_rman_util` パッケージを使用してデータベースをバックアップする前に、以下の前提条件を満たしていることを確認してください。
+ RDS for Oracle データベースが `ARCHIVELOG` モードであることを確認してください。このモードを有効にするには、バックアップ保持期間をゼロ以外の値に設定します。
+ アーカイブされた REDO ログをバックアップしたり、アーカイブされた REDO ログを含む完全バックアップまたは増分バックアップを実行する場合は、REDO ログの保持期間をゼロ以外の値に設定する必要があります。リカバリ時にデータベースファイルの整合性を保つには、アーカイブされたREDO ログが必要です。詳細については、「[アーカイブ REDO ログの保持](Appendix.Oracle.CommonDBATasks.RetainRedoLogs.md)」を参照してください。
+ DB インスタンスにバックアップを保持するのに十分な空き容量があることを確認してください。データベースをバックアップするときには、プロシージャ呼び出しのパラメータとして Oracle ディレクトリオブジェクトを指定します。RMAN は、指定されたディレクトリにファイルを配置します。デフォルトのディレクトリ (`DATA_PUMP_DIR` など) を使用するか、新しいディレクトリを作成できます。詳細については、「[主要データストレージ領域でのディレクトリの作成と削除](Appendix.Oracle.CommonDBATasks.Misc.md#Appendix.Oracle.CommonDBATasks.NewDirectories)」を参照してください。
CloudWatch メトリクス `FreeStorageSpace` を使用して、RDS for Oracle インスタンスの現在の空き容量をモニタリングできます。RMAN はフォーマットされたブロックのみをバックアップし、圧縮をサポートしますが、データベースの現在のサイズを超える空き容量を確保しておくことをお勧めします。
# RMAN プロシージャの共通パラメータ
RMAN のタスクを実行するには、Amazon RDS パッケージ `rdsadmin.rdsadmin_rman_util` を使用できます。いくつかのパラメータは、パッケージ内のすべてのプロシージャに共通です。パッケージ内の共通パラメータは以下のとおりです。
****
| パラメータ名 | データ型 | 有効な値 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- | --- |
| `p_directory_name` | varchar2 | データベースの有効なディレクトリ名。 | — | はい | バックアップファイルを含めるディレクトリの名前。 |
| `p_label` | varchar2 | `a-z`, `A-Z`, `0-9`, `'_'`, `'-'`, `'.'` | — | いいえ | バックアップファイル名に含まれている一意の文字列。 上限は 30 文字です。 |
| `p_owner` | varchar2 | `p_directory_name` に指定されたディレクトリの有効な所有者。 | — | はい | バックアップファイルを含めるディレクトリの所有者。 |
| `p_tag` | varchar2 | `a-z`, `A-Z`, `0-9`, `'_'`, `'-'`, `'.'` | NULL | いいえ | 日次、週次、増分レベルのバックアップなど、バックアップの目的または使用方法を示すためにバックアップを区別できるようにする目的で使用する文字列。 上限は 30 文字です。タグでは、大文字と小文字は区別されません。タグは、入力する際に使用されるのが大文字か小文字かに関係なく、常に大文字で格納されます。 タグは一意である必要はないので、複数のバックアップに同じタグを付けることができます。 タグを指定しない場合、RMAN は、`TAGYYYYMMDDTHHMMSS` の形式を使用してデフォルトのタグを自動的に割り当てます。ここで *YYYY* は年、*MM* は月、*DD* は日、*HH* は時間 (24 時間形式)、*MM* は分、*SS* は秒です。日付と時刻は、RMAN がバックアップを開始した日時を示します。 例えば、2019-09-27 の 21:45:17 に開始されたバックアップに対して、バックアップに `TAG20190927T214517` というタグが付けられることがあります。 `p_tag` パラメータは、以下の Amazon RDS for Oracle DB エンジンバージョンでサポートされています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.CommonParameters.html) |
| `p_compress` | boolean | `TRUE`, `FALSE` | `FALSE` | いいえ | BASIC バックアップ圧縮を行うには `TRUE` を指定します。 BASIC バックアップ圧縮を無効にするには `FALSE` を指定します。 |
| `p_include_archive_logs` | boolean | `TRUE`, `FALSE` | `FALSE` | いいえ | アーカイブ REDO ログをバックアップに含めるには、`TRUE` を指定します。 アーカイブ REDO ログをバックアップから除外するには、`FALSE` を指定します。 アーカイブ REDO ログをバックアップに含める場合は、`rdsadmin.rdsadmin_util.set_configuration` プロシージャを使用して保持期間を 1 時間以上に設定します。また、バックアップを実行する直前に `rdsadmin.rdsadmin_rman_util.crosscheck_archivelog` プロシージャを呼び出します。そうしないと、アーカイブ REDO ログファイルが Amazon RDS 管理プロシージャで削除されて見つからないため、バックアップは失敗する場合があります。 |
| `p_include_controlfile` | boolean | `TRUE`, `FALSE` | `FALSE` | いいえ | 制御ファイルをバックアップに含めるには、`TRUE` を指定します。 制御ファイルをバックアップから除外するには、`FALSE` を指定します。 |
| `p_optimize` | boolean | `TRUE`, `FALSE` | `TRUE` | いいえ | バックアップの最適化を有効にするには、`TRUE` を指定します。アーカイブ REDO ログを含める場合は、バックアップサイズが縮小されます。 バックアップの最適化を無効にするには、`FALSE` を指定します。 |
| `p_parallel` | number | Oracle Database Enterprise Edition (EE) の場合は `1`〜`254` の有効な整数 `1`その他の Oracle データベースエディションの場合は | `1` | いいえ | チャネルの数。 |
| `p_rman_to_dbms_output` | boolean | `TRUE`, `FALSE` | `FALSE` | いいえ | `TRUE` の場合、RMAN 出力は `DBMS_OUTPUT` ディレクトリのファイルに加えて、`BDUMP` パッケージに送信されます。SQL\$1Plus で、`SET SERVEROUTPUT ON` を使用して出力を確認します。 `FALSE` の場合、RMAN 出力は `BDUMP` ディレクトリのファイルにのみ送信されます。 |
| `p_section_size_mb` | number | 有効な整数 | `NULL` | いいえ | セクションサイズのメガバイト (MB)。 各ファイルを指定されたセクションサイズに分割し、パラレルして検証します。 `NULL` の場合、パラメータは無視されます。 |
| `p_validation_type` | varchar2 | `'PHYSICAL'`, `'PHYSICAL+LOGICAL'` | `'PHYSICAL'` | いいえ | 破損の検出のレベル。 物理的な破損を確認するには、`'PHYSICAL'` を指定します。物理的な破損の一例は、ヘッダーおよびフッターの不一致によるブロックです。 物理的な破損に加えて論理的な不整合を確認するには、`'PHYSICAL+LOGICAL'` を指定します。論理的な破損の一例は破損ブロックです。 |
# RDS for Oracle でのデータベースファイルの検証
Amazon RDS パッケージ `rdsadmin.rdsadmin_rman_util` を使用して、Amazon RDS for Oracle のデータベースファイル (データファイル、テーブルスペース、制御ファイル、およびサーバーパラメータファイル (SPFILE) など) を検証できます。
RMAN の検証の詳細については、Oracle ドキュメントの「[データベースファイルおよびバックアップの検証](https://docs.oracle.com/database/121/BRADV/rcmvalid.htm#BRADV90063)」と「[VALIDATE](https://docs.oracle.com/database/121/RCMRF/rcmsynta2025.htm#RCMRF162)」を参照してください。
**Topics**
+ [データベースの検証](#Appendix.Oracle.CommonDBATasks.ValidateDB)
+ [テナントデータベースの検証](#Appendix.Oracle.CommonDBATasks.ValidateTenantDB)
+ [テーブルスペースの検証](#Appendix.Oracle.CommonDBATasks.ValidateTablespace)
+ [制御ファイルの検証](#Appendix.Oracle.CommonDBATasks.ValidateControlFile)
+ [SPFILE の検証](#Appendix.Oracle.CommonDBATasks.ValidateSpfile)
+ [Oracle データファイルの検証](#Appendix.Oracle.CommonDBATasks.ValidateDataFile)
## データベースの検証
RDS の Oracle データベースで使用されているすべての関連ファイルを検証するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_rman_util.validate_database` を使用します。
このプロシージャでは、以下の RMAN タスクの共通パラメータを使用します。
+ `p_validation_type`
+ `p_parallel`
+ `p_section_size_mb`
+ `p_rman_to_dbms_output`
詳細については、「[RMAN プロシージャの共通パラメータ](Appendix.Oracle.CommonDBATasks.CommonParameters.md)」を参照してください。
次の例では、パラメータのデフォルト値を使用してデータベースを検証します。
```
EXEC rdsadmin.rdsadmin_rman_util.validate_database;
```
次の例では、パラメータの指定値を使用してデータベースを検証します。
```
BEGIN
rdsadmin.rdsadmin_rman_util.validate_database(
p_validation_type => 'PHYSICAL+LOGICAL',
p_parallel => 4,
p_section_size_mb => 10,
p_rman_to_dbms_output => FALSE);
END;
/
```
`p_rman_to_dbms_output` パラメータを `FALSE` に設定すると、RMAN 出力は `BDUMP` ディレクトリのファイルに書き込まれます。
`BDUMP` ディレクトリのファイルを表示するには、次の `SELECT` ステートメントを実行します。
```
SELECT * FROM table(rdsadmin.rds_file_util.listdir('BDUMP')) order by mtime;
```
`BDUMP` ディレクトリのファイルの内容を表示するには、次の `SELECT` ステートメントを実行します。
```
SELECT text FROM table(rdsadmin.rds_file_util.read_text_file('BDUMP','rds-rman-validate-nnn.txt'));
```
ファイル名を、表示するファイルの名前に置き換えます。
## テナントデータベースの検証
コンテナデータベース (CDB) 内のテナントデータベースのデータファイルを検証するには、Amazon RDS のプロシージャ `rdsadmin.rdsadmin_rman_util.validate_tenant` を使用します。
このプロシージャは現在のテナントデータベースにのみ適用され、以下の RMAN タスクの共通パラメータを使用します。
+ `p_validation_type`
+ `p_parallel`
+ `p_section_size_mb`
+ `p_rman_to_dbms_output`
詳細については、「[RMAN プロシージャの共通パラメータ](Appendix.Oracle.CommonDBATasks.CommonParameters.md)」を参照してください。このプロシージャは、以下の DB エンジンバージョンでサポートされています。
+ Oracle Database 21c (21.0.0) CDB
+ Oracle Database 19c (19.0.0) CDB
次の例では、パラメータのデフォルト値を使用して現行のテナントデータベースを検証します。
```
EXEC rdsadmin.rdsadmin_rman_util.validate_tenant;
```
次の例では、パラメータの指定値を使用して現行のテナントデータベースを検証します。
```
BEGIN
rdsadmin.rdsadmin_rman_util.validate_tenant(
p_validation_type => 'PHYSICAL+LOGICAL',
p_parallel => 4,
p_section_size_mb => 10,
p_rman_to_dbms_output => FALSE);
END;
/
```
`p_rman_to_dbms_output` パラメータを `FALSE` に設定すると、RMAN 出力は `BDUMP` ディレクトリのファイルに書き込まれます。
`BDUMP` ディレクトリのファイルを表示するには、次の `SELECT` ステートメントを実行します。
```
SELECT * FROM table(rdsadmin.rds_file_util.listdir('BDUMP')) order by mtime;
```
`BDUMP` ディレクトリのファイルの内容を表示するには、次の `SELECT` ステートメントを実行します。
```
SELECT text FROM table(rdsadmin.rds_file_util.read_text_file('BDUMP','rds-rman-validate-nnn.txt'));
```
ファイル名を、表示するファイルの名前に置き換えます。
## テーブルスペースの検証
テーブルスペースに関連付けられたファイルを検証するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_rman_util.validate_tablespace` を使用します。
このプロシージャでは、以下の RMAN タスクの共通パラメータを使用します。
+ `p_validation_type`
+ `p_parallel`
+ `p_section_size_mb`
+ `p_rman_to_dbms_output`
詳細については、「[RMAN プロシージャの共通パラメータ](Appendix.Oracle.CommonDBATasks.CommonParameters.md)」を参照してください。
このプロシージャでは、次の追加のパラメータも使用します。
****
| パラメータ名 | データ型 | 有効な値 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- | --- |
| `p_tablespace_name` | varchar2 | 有効なテーブルスペース名 | — | はい | テーブルスペースの名前。 |
## 制御ファイルの検証
Amazon RDS Oracle DB インスタンスで使用されている制御ファイルのみを検証するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_rman_util.validate_current_controlfile` を使用します。
このプロシージャでは、次の RMAN タスクの共通パラメータを使用します。
+ `p_validation_type`
+ `p_rman_to_dbms_output`
詳細については、「[RMAN プロシージャの共通パラメータ](Appendix.Oracle.CommonDBATasks.CommonParameters.md)」を参照してください。
## SPFILE の検証
Amazon RDS Oracle DB インスタンスで使用されているサーバーパラメータファイル (SPFILE) を検証するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_rman_util.validate_spfile` を使用します。
このプロシージャでは、次の RMAN タスクの共通パラメータを使用します。
+ `p_validation_type`
+ `p_rman_to_dbms_output`
詳細については、「[RMAN プロシージャの共通パラメータ](Appendix.Oracle.CommonDBATasks.CommonParameters.md)」を参照してください。
## Oracle データファイルの検証
データファイルを検証するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_rman_util.validate_datafile` を使用します。
このプロシージャでは、以下の RMAN タスクの共通パラメータを使用します。
+ `p_validation_type`
+ `p_parallel`
+ `p_section_size_mb`
+ `p_rman_to_dbms_output`
詳細については、「[RMAN プロシージャの共通パラメータ](Appendix.Oracle.CommonDBATasks.CommonParameters.md)」を参照してください。
このプロシージャでは、以下の追加のパラメータも使用します。
****
| パラメータ名 | データ型 | 有効な値 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- | --- |
| `p_datafile` | varchar2 | 有効なデータファイル ID 番号または完全なパスを含む有効なデータファイル名 | — | はい | データファイル ID 番号 (`v$datafile.file#` より) またはパスを含む詳細なデータファイル名 (`v$datafile.name` より)。 |
| `p_from_block` | number | 有効な整数 | `NULL` | いいえ | データファイル内で検証が始まるブロックの番号。これが `NULL` の場合、`1` が使用されます。 |
| `p_to_block` | number | 有効な整数 | `NULL` | いいえ | データファイル内で検証が終わるブロックの番号。これが `NULL` の場合、データファイルの最大ブロックが使用されます。 |
# ブロック変更追跡の有効化/無効化
ブロック変更の追跡は、トラッキングファイル内の変更されたブロックを記録します。この手法により、RMAN 増分バックアップのパフォーマンスを向上させることができます。詳細は、Oracle Database のドキュメントの「[ ブロック変更の追跡を使用した増分バックアップのパフォーマンスの向上 ](https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/backing-up-database.html#GUID-4E1F605A-76A7-48D0-9D9B-7343B4327E2A)」を参照してください。
RMAN 機能はリードレプリカではサポートされていません。ただし、高可用性戦略の一環として、手順 `rdsadmin.rdsadmin_rman_util.enable_block_change_tracking` に従って読み取り専用レプリカでブロック追跡を有効にすることもできます。この読み取り専用レプリカをソース DB インスタンスに昇格すると、新しいソースインスタンスでブロック変更追跡が有効になります。そのため、インスタンスは高速増分バックアップの恩恵を受けることができます。
ブロック変更の追跡手順は、次の DB エンジンバージョンの Enterprise Edition でのみサポートされています。
+ Oracle Database 21c (21.0.0)
+ Oracle Database 19c (19.0.0)
**注記**
シングルテナント CDB では、以下のオペレーションは機能しますが、お客様が表示可能なメカニズムはオペレーションの現在のステータスを検出できません。「[RDS for Oracle CDB の制限事項](Oracle.Concepts.CDBs.md#Oracle.Concepts.single-tenant-limitations)」も参照してください。
DB インスタンスのブロック変更の追跡を有効にするには、Amazon RDS 手順 `rdsadmin.rdsadmin_rman_util.enable_block_change_tracking` を使用します。ブロック変更の追跡を無効にするには、`disable_block_change_tracking`を使用します。これらのプロシージャではパラメータを使用しません。
使用している DB インスタンスでブロック変更追跡が有効になっているかどうかを確認するには、次のクエリを実行します。
```
SELECT STATUS, FILENAME FROM V$BLOCK_CHANGE_TRACKING;
```
次の例では、DB インスタンスのブロック変更追跡を有効にします。
```
EXEC rdsadmin.rdsadmin_rman_util.enable_block_change_tracking;
```
次の例では、DB インスタンスのブロック変更追跡を無効にします。
```
EXEC rdsadmin.rdsadmin_rman_util.disable_block_change_tracking;
```
# アーカイブ REDO ログのクロスチェック
Amazon RDS プロシージャ `rdsadmin.rdsadmin_rman_util.crosscheck_archivelog` を使用して、アーカイブ REDO ログをクロスチェックできます。
このプロシージャを使用して、制御ファイルに登録済みのアーカイブ REDO ログをクロスチェックし、必要に応じて期限切れのログレコードを削除できます。RMAN によってバックアップが作成されると、制御ファイルにレコードが作成されます。時間の経過に伴って、これらのレコードのために制御ファイルのサイズが肥大します。期限切れのレコードは定期的に削除することをお勧めします。
**注記**
スタンダードの Amazon RDS バックアップでは RMAN を使用しないため、レコードは制御ファイルに作成されません。
このプロシージャでは、RMAN タスクの共通パラメータ `p_rman_to_dbms_output` を使用します。
詳細については、「[RMAN プロシージャの共通パラメータ](Appendix.Oracle.CommonDBATasks.CommonParameters.md)」を参照してください。
このプロシージャでは、次の追加のパラメータも使用します。
****
| パラメータ名 | データ型 | 有効な値 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- | --- |
| `p_delete_expired` | boolean | `TRUE`, `FALSE` | `TRUE` | いいえ | `TRUE` の場合、期限切れのアーカイブ REDO ログレコードを制御ファイルから削除します。 `FALSE` の場合、期限切れのアーカイブ REDO ログレコードを制御ファイルに保持します。 |
このプロシージャは、以下の Amazon RDS for Oracle DB エンジンバージョンでサポートされています。
+ Oracle Database 21c (21.0.0)
+ Oracle Database 19c (19.0.0)
次の例では、制御ファイル内のアーカイブ REDO ログレコードを期限切れとしてマークしますが、レコードは削除しません。
```
BEGIN
rdsadmin.rdsadmin_rman_util.crosscheck_archivelog(
p_delete_expired => FALSE,
p_rman_to_dbms_output => FALSE);
END;
/
```
次の例では、期限切れのアーカイブ REDO ログレコードを制御ファイルから削除します。
```
BEGIN
rdsadmin.rdsadmin_rman_util.crosscheck_archivelog(
p_delete_expired => TRUE,
p_rman_to_dbms_output => FALSE);
END;
/
```
# アーカイブ REDO ログファイルのバックアップ
Amazon RDS パッケージ `rdsadmin.rdsadmin_rman_util` を使用して Amazon RDS Oracle DB インスタンスのアーカイブ REDO ログをバックアップできます。
アーカイブ REDO ログをバックアップするプロシージャは、以下の Amazon RDS for Oracle DB エンジンバージョンでサポートされています。
+ Oracle Database 21c (21.0.0)
+ Oracle Database 19c (19.0.0)
**Topics**
+ [すべてのアーカイブ REDO ログのバックアップ](#Appendix.Oracle.CommonDBATasks.BackupArchivedLogs.All)
+ [日付範囲からのアーカイブ REDO ログのバックアップ](#Appendix.Oracle.CommonDBATasks.BackupArchivedLogs.Date)
+ [SCN 範囲からのアーカイブ REDO ログのバックアップ](#Appendix.Oracle.CommonDBATasks.BackupArchivedLogs.SCN)
+ [シーケンス番号範囲からのアーカイブ REDO ログのバックアップ](#Appendix.Oracle.CommonDBATasks.BackupArchivedLogs.Sequence)
## すべてのアーカイブ REDO ログのバックアップ
Amazon RDS Oracle DB インスタンスのすべてのアーカイブ REDO ログをバックアップするには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_rman_util.backup_archivelog_all` を使用します。
このプロシージャでは、以下の RMAN タスクの共通パラメータを使用します。
+ `p_owner`
+ `p_directory_name`
+ `p_label`
+ `p_parallel`
+ `p_compress`
+ `p_rman_to_dbms_output`
+ `p_tag`
詳細については、「[RMAN プロシージャの共通パラメータ](Appendix.Oracle.CommonDBATasks.CommonParameters.md)」を参照してください。
次の例では、DB インスタンスのすべてのアーカイブ REDO ログをバックアップします。
```
BEGIN
rdsadmin.rdsadmin_rman_util.backup_archivelog_all(
p_owner => 'SYS',
p_directory_name => 'MYDIRECTORY',
p_parallel => 4,
p_tag => 'MY_LOG_BACKUP',
p_rman_to_dbms_output => FALSE);
END;
/
```
## 日付範囲からのアーカイブ REDO ログのバックアップ
日付範囲を指定して Amazon RDS Oracle DB インスタンスの特定のアーカイブ REDO ログをバックアップするには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_rman_util.backup_archivelog_date` を使用します。日付範囲では、どのアーカイブ REDO ログをバックアップするかを指定します。
このプロシージャでは、以下の RMAN タスクの共通パラメータを使用します。
+ `p_owner`
+ `p_directory_name`
+ `p_label`
+ `p_parallel`
+ `p_compress`
+ `p_rman_to_dbms_output`
+ `p_tag`
詳細については、「[RMAN プロシージャの共通パラメータ](Appendix.Oracle.CommonDBATasks.CommonParameters.md)」を参照してください。
このプロシージャでは、以下の追加のパラメータも使用します。
****
| パラメータ名 | データ型 | 有効な値 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- | --- |
| `p_from_date` | date | ディスクにあるアーカイブ REDO ログの `start_date`～`next_date` の日付。この値は、`p_to_date` で指定した値以下にする必要があります。 | — | はい | アーカイブログのバックアップのスタート日。 |
| `p_to_date` | date | ディスクにあるアーカイブ REDO ログの `start_date`～`next_date` の日付。この値は、`p_from_date` で指定した値以上にする必要があります。 | — | はい | アーカイブログのバックアップの終了日。 |
次の例では、DB インスタンスの日付範囲のアーカイブ REDO ログをバックアップします。
```
BEGIN
rdsadmin.rdsadmin_rman_util.backup_archivelog_date(
p_owner => 'SYS',
p_directory_name => 'MYDIRECTORY',
p_from_date => '03/01/2019 00:00:00',
p_to_date => '03/02/2019 00:00:00',
p_parallel => 4,
p_tag => 'MY_LOG_BACKUP',
p_rman_to_dbms_output => FALSE);
END;
/
```
## SCN 範囲からのアーカイブ REDO ログのバックアップ
システム変更番号 (SCN) 範囲を指定して Amazon RDS Oracle DB インスタンスの特定のアーカイブ REDO ログをバックアップするには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_rman_util.backup_archivelog_scn` を使用します。SCN 範囲では、どのアーカイブ REDO ログをバックアップするかを指定します。
このプロシージャでは、以下の RMAN タスクの共通パラメータを使用します。
+ `p_owner`
+ `p_directory_name`
+ `p_label`
+ `p_parallel`
+ `p_compress`
+ `p_rman_to_dbms_output`
+ `p_tag`
詳細については、「[RMAN プロシージャの共通パラメータ](Appendix.Oracle.CommonDBATasks.CommonParameters.md)」を参照してください。
このプロシージャでは、以下の追加のパラメータも使用します。
****
| パラメータ名 | データ型 | 有効な値 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- | --- |
| `p_from_scn` | number | ディスクにあるアーカイブ REDO ログの SCN。この値は、`p_to_scn` で指定した値以下にする必要があります。 | — | はい | アーカイブログのバックアップのスタート SCN。 |
| `p_to_scn` | number | ディスクにあるアーカイブ REDO ログの SCN。この値は、`p_from_scn` で指定した値以上にする必要があります。 | — | はい | アーカイブログのバックアップの終了 SCN。 |
次の例では、DB インスタンスの SCN 範囲のアーカイブ REDO ログをバックアップします。
```
BEGIN
rdsadmin.rdsadmin_rman_util.backup_archivelog_scn(
p_owner => 'SYS',
p_directory_name => 'MYDIRECTORY',
p_from_scn => 1533835,
p_to_scn => 1892447,
p_parallel => 4,
p_tag => 'MY_LOG_BACKUP',
p_rman_to_dbms_output => FALSE);
END;
/
```
## シーケンス番号範囲からのアーカイブ REDO ログのバックアップ
シーケンス番号範囲を指定して Amazon RDS Oracle DB インスタンスの特定のアーカイブ REDO ログをバックアップするには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_rman_util.backup_archivelog_sequence` を使用します。シーケンス番号範囲では、どのアーカイブ REDO ログをバックアップするかを指定します。
このプロシージャでは、以下の RMAN タスクの共通パラメータを使用します。
+ `p_owner`
+ `p_directory_name`
+ `p_label`
+ `p_parallel`
+ `p_compress`
+ `p_rman_to_dbms_output`
+ `p_tag`
詳細については、「[RMAN プロシージャの共通パラメータ](Appendix.Oracle.CommonDBATasks.CommonParameters.md)」を参照してください。
このプロシージャでは、以下の追加のパラメータも使用します。
****
| パラメータ名 | データ型 | 有効な値 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- | --- |
| `p_from_sequence` | number | ディスクにあるアーカイブ REDO ログのシーケンス番号。この値は、`p_to_sequence` で指定した値以下にする必要があります。 | — | はい | アーカイブログのバックアップのスタートシーケンス番号。 |
| `p_to_sequence` | number | ディスクにあるアーカイブ REDO ログのシーケンス番号。この値は、`p_from_sequence` で指定した値以上にする必要があります。 | — | はい | アーカイブログのバックアップの終了シーケンス番号。 |
次の例では、DB インスタンスのシーケンス番号範囲のアーカイブ REDO ログをバックアップします。
```
BEGIN
rdsadmin.rdsadmin_rman_util.backup_archivelog_sequence(
p_owner => 'SYS',
p_directory_name => 'MYDIRECTORY',
p_from_sequence => 11160,
p_to_sequence => 11160,
p_parallel => 4,
p_tag => 'MY_LOG_BACKUP',
p_rman_to_dbms_output => FALSE);
END;
/
```
# データベースの完全バックアップの実行
Amazon RDS プロシージャ `rdsadmin.rdsadmin_rman_util.backup_database_full` を使用してバックアップに含まれているデータファイルのすべてのブロックのバックアップを実行します。
このプロシージャでは、以下の RMAN タスクの共通パラメータを使用します。
+ `p_owner`
+ `p_directory_name`
+ `p_label`
+ `p_parallel`
+ `p_section_size_mb`
+ `p_include_archive_logs`
+ `p_optimize`
+ `p_compress`
+ `p_rman_to_dbms_output`
+ `p_tag`
詳細については、「[RMAN プロシージャの共通パラメータ](Appendix.Oracle.CommonDBATasks.CommonParameters.md)」を参照してください。
このプロシージャは、以下の Amazon RDS for Oracle DB エンジンバージョンでサポートされています。
+ Oracle Database 21c (21.0.0)
+ Oracle Database 19c (19.0.0)
次の例では、パラメータの値を指定して DB インスタンスの完全バックアップを実行します。
```
BEGIN
rdsadmin.rdsadmin_rman_util.backup_database_full(
p_owner => 'SYS',
p_directory_name => 'MYDIRECTORY',
p_parallel => 4,
p_section_size_mb => 10,
p_tag => 'FULL_DB_BACKUP',
p_rman_to_dbms_output => FALSE);
END;
/
```
# テナントデータベースの完全バックアップの実行
コンテナデータベース (CDB) 内のテナントデータベースに含まれているすべてのデータブロックのバックアップを実行します。Amazon RDS プロシージャ `rdsadmin.rdsadmin_rman_util.backup_tenant_full` を使用します。このプロシージャは現在のデータベースバックアップにのみ適用され、以下の RMAN タスクの共通パラメータを使用します。
+ `p_owner`
+ `p_directory_name`
+ `p_label`
+ `p_parallel`
+ `p_section_size_mb`
+ `p_include_archive_logs`
+ `p_optimize`
+ `p_compress`
+ `p_rman_to_dbms_output`
+ `p_tag`
詳細については、「[RMAN プロシージャの共通パラメータ](Appendix.Oracle.CommonDBATasks.CommonParameters.md)」を参照してください。
`rdsadmin_rman_util.backup_tenant_full` プロシージャは、以下の RDS for Oracle DB エンジンバージョンでサポートされています。
+ Oracle Database 21c (21.0.0) CDB
+ Oracle Database 19c (19.0.0) CDB
次の例では、パラメータの指定値を指定して、現行のテナントデータベースの完全バックアップを実行します。
```
BEGIN
rdsadmin.rdsadmin_rman_util.backup_tenant_full(
p_owner => 'SYS',
p_directory_name => 'MYDIRECTORY',
p_parallel => 4,
p_section_size_mb => 10,
p_tag => 'FULL_TENANT_DB_BACKUP',
p_rman_to_dbms_output => FALSE);
END;
/
```
# データベースの増分バックアップの実行
Amazon RDS プロシージャ `rdsadmin.rdsadmin_rman_util.backup_database_incremental` を使用して DB インスタンスの増分バックアップを実行できます。
増分バックアップの詳細については、Oracle ドキュメントの「[増分バックアップ](https://docs.oracle.com/database/121/RCMRF/rcmsynta006.htm#GUID-73642FF2-43C5-48B2-9969-99001C52EB50__BGBHABHH)」を参照してください。
このプロシージャでは、以下の RMAN タスクの共通パラメータを使用します。
+ `p_owner`
+ `p_directory_name`
+ `p_label`
+ `p_parallel`
+ `p_section_size_mb`
+ `p_include_archive_logs`
+ `p_include_controlfile`
+ `p_optimize`
+ `p_compress`
+ `p_rman_to_dbms_output`
+ `p_tag`
詳細については、「[RMAN プロシージャの共通パラメータ](Appendix.Oracle.CommonDBATasks.CommonParameters.md)」を参照してください。
このプロシージャは、以下の Amazon RDS for Oracle DB エンジンバージョンでサポートされています。
+ Oracle Database 21c (21.0.0)
+ Oracle Database 19c (19.0.0)
このプロシージャでは、次の追加のパラメータも使用します。
****
| パラメータ名 | データ型 | 有効な値 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- | --- |
| `p_level` | number | `0`, `1` | `0` | いいえ | フル増分バックアップを有効にするには、`0` を指定します。 非累積増分バックアップを有効にするには、`1` を指定します。 |
次の例では、パラメータの値を指定して DB インスタンスの増分バックアップを実行します。
```
BEGIN
rdsadmin.rdsadmin_rman_util.backup_database_incremental(
p_owner => 'SYS',
p_directory_name => 'MYDIRECTORY',
p_level => 1,
p_parallel => 4,
p_section_size_mb => 10,
p_tag => 'MY_INCREMENTAL_BACKUP',
p_rman_to_dbms_output => FALSE);
END;
/
```
# テナントデータベースの増分バックアップの実行
CDB 内の現在のテナントデータベースの増分バックアップを実行できます。Amazon RDS プロシージャ `rdsadmin.rdsadmin_rman_util.backup_tenant_incremental` を使用します。
増分バックアップの詳細については、Oracle Database ドキュメントの「[増分バックアップ](https://docs.oracle.com/database/121/RCMRF/rcmsynta006.htm#GUID-73642FF2-43C5-48B2-9969-99001C52EB50__BGBHABHH)」を参照してください。
このプロシージャは現在のテナントデータベースにのみ適用され、以下の RMAN タスクの共通パラメータを使用します。
+ `p_owner`
+ `p_directory_name`
+ `p_label`
+ `p_parallel`
+ `p_section_size_mb`
+ `p_include_archive_logs`
+ `p_include_controlfile`
+ `p_optimize`
+ `p_compress`
+ `p_rman_to_dbms_output`
+ `p_tag`
詳細については、「[RMAN プロシージャの共通パラメータ](Appendix.Oracle.CommonDBATasks.CommonParameters.md)」を参照してください。
このプロシージャは、以下の Amazon RDS for Oracle DB エンジンバージョンでサポートされています。
+ Oracle Database 21c (21.0.0) CDB
+ Oracle Database 19c (19.0.0) CDB
このプロシージャでは、次の追加のパラメータも使用します。
****
| パラメータ名 | データ型 | 有効な値 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- | --- |
| `p_level` | number | `0`, `1` | `0` | いいえ | フル増分バックアップを有効にするには、`0` を指定します。 非累積増分バックアップを有効にするには、`1` を指定します。 |
次の例では、パラメータの指定値を指定して、現行のテナントデータベースの増分バックアップを実行します。
```
BEGIN
rdsadmin.rdsadmin_rman_util.backup_tenant_incremental(
p_owner => 'SYS',
p_directory_name => 'MYDIRECTORY',
p_level => 1,
p_parallel => 4,
p_section_size_mb => 10,
p_tag => 'MY_INCREMENTAL_BACKUP',
p_rman_to_dbms_output => FALSE);
END;
/
```
# テーブルスペースのバックアップ
Amazon RDS プロシージャ `rdsadmin.rdsadmin_rman_util.backup_tablespace` を使用してテーブルスペースをバックアップできます。
このプロシージャでは、以下の RMAN タスクの共通パラメータを使用します。
+ `p_owner`
+ `p_directory_name`
+ `p_label`
+ `p_parallel`
+ `p_section_size_mb`
+ `p_include_archive_logs`
+ `p_include_controlfile`
+ `p_optimize`
+ `p_compress`
+ `p_rman_to_dbms_output`
+ `p_tag`
詳細については、「[RMAN プロシージャの共通パラメータ](Appendix.Oracle.CommonDBATasks.CommonParameters.md)」を参照してください。
このプロシージャでは、次の追加のパラメータも使用します。
****
| パラメータ名 | データ型 | 有効な値 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- | --- |
| `p_tablespace_name` | varchar2 | 有効なテーブルスペース名。 | — | はい | バックアップするテーブルスペースの名前。 |
このプロシージャは、以下の Amazon RDS for Oracle DB エンジンバージョンでサポートされています。
+ Oracle Database 21c (21.0.0)
+ Oracle Database 19c (19.0.0)
次の例では、パラメータの値を指定してテーブルスペースバックアップを実行します。
```
BEGIN
rdsadmin.rdsadmin_rman_util.backup_tablespace(
p_owner => 'SYS',
p_directory_name => 'MYDIRECTORY',
p_tablespace_name => 'MYTABLESPACE',
p_parallel => 4,
p_section_size_mb => 10,
p_tag => 'MYTABLESPACE_BACKUP',
p_rman_to_dbms_output => FALSE);
END;
/
```
# コントロールファイルのバックアップ
Amazon RDS プロシージャ `rdsadmin.rdsadmin_rman_util.backup_current_controlfile` を使用して、コントロールファイルをバックアップできます。
このプロシージャでは、以下の RMAN タスクの共通パラメータを使用します。
+ `p_owner`
+ `p_directory_name`
+ `p_label`
+ `p_compress`
+ `p_rman_to_dbms_output`
+ `p_tag`
詳細については、「[RMAN プロシージャの共通パラメータ](Appendix.Oracle.CommonDBATasks.CommonParameters.md)」を参照してください。
このプロシージャは、以下の Amazon RDS for Oracle DB エンジンバージョンでサポートされています。
+ Oracle Database 21c (21.0.0)
+ Oracle Database 19c (19.0.0)
次の例では、パラメータに指定した値を使用して、コントロールファイルをバックアップします。
```
BEGIN
rdsadmin.rdsadmin_rman_util.backup_current_controlfile(
p_owner => 'SYS',
p_directory_name => 'MYDIRECTORY',
p_tag => 'CONTROL_FILE_BACKUP',
p_rman_to_dbms_output => FALSE);
END;
/
```
# ブロックメディアリカバリの実行
Amazon RDS プロシージャ `rdsadmin.rdsadmin_rman_util.recover_datafile_block` を使用して、ブロックメディアリカバリと呼ばれる個々のデータブロックを復元できます。この重複された手順を使用して、個々のデータブロックまたはデータブロックの範囲を復元できます。
このプロシージャでは、次の RMAN タスクの共通パラメータを使用します。
+ `p_rman_to_dbms_output`
詳細については、「[RMAN プロシージャの共通パラメータ](Appendix.Oracle.CommonDBATasks.CommonParameters.md)」を参照してください。
このプロシージャでは、以下の追加のパラメータを使用します。
****
| パラメータ名 | データ型 | 有効な値 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- | --- |
| `p_datafile` | `NUMBER` | 有効なデータファイル ID 番号。 | — | はい | 破損ブロックを含むデータファイル。次のいずれかの方法でデータファイルを指定します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.block-media-recovery.html) |
| `p_block` | `NUMBER` | 有効な整数。 | — | はい | 復元する個々のブロックの数。 次のパラメータは相互に排他的です。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.block-media-recovery.html) |
| `p_from_block` | `NUMBER` | 有効な整数。 | — | はい | 復元するブロックの範囲の最初のブロック番号。 次のパラメータは相互に排他的です。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.block-media-recovery.html) |
| `p_to_block` | `NUMBER` | 有効な整数。 | — | はい | 復元するブロックの範囲内の最後のブロック番号。 次のパラメータは相互に排他的です。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.block-media-recovery.html) |
このプロシージャは、以下の Amazon RDS for Oracle DB エンジンバージョンでサポートされています。
+ Oracle Database 21c (21.0.0)
+ Oracle Database 19c (19.0.0)
次の例では、データファイル 5 のブロック 100 を復元します。
```
BEGIN
rdsadmin.rdsadmin_rman_util.recover_datafile_block(
p_datafile => 5,
p_block => 100,
p_rman_to_dbms_output => TRUE);
END;
/
```
次の例では、データファイル 5 のブロック 100～150 を復元します。
```
BEGIN
rdsadmin.rdsadmin_rman_util.recover_datafile_block(
p_datafile => 5,
p_from_block => 100,
p_to_block => 150,
p_rman_to_dbms_output => TRUE);
END;
/
```
# Oracle DB インスタンスの一般的なスケジューリングタスクの実行
`SYS`が所有する一部のスケジューラジョブは、通常のデータベースオペレーションを妨げる可能性があります。このような場合、Oracle サポートはスケジュールを変更することを推奨しています。`SYS` ジョブを有効または無効にする必要がある場合は、本番環境に実装する前に、テスト環境のスケジュールされたジョブでオペレーションをテストします。Amazon RDS パッケージ`rdsadmin.rdsadmin_dbms_scheduler`を使用して、`SYS`が所有する Oracle スケジューラジョブのタスクを実行します。
`rdsadmin.rdsadmin_dbms_scheduler` 手順は、以下の表に示す Amazon RDS for Oracle DB エンジンバージョンでサポートされています。このパッケージを使用する場合は、表に示されている `SYS` ジョブを指定できます。
| データベースリリース | デフォルトで有効のジョブ | デフォルトで無効のジョブ |
| --- | --- | --- |
| Oracle Database 19c | BSLN_MAINTAIN_STATS_JOB
CLEANUP_NON_EXIST_OBJ
CLEANUP_ONLINE_IND_BUILD
CLEANUP_ONLINE_PMO
CLEANUP_TAB_IOT_PMO
CLEANUP_TRANSIENT_PKG
CLEANUP_TRANSIENT_TYPE
DRA_REEVALUATE_OPEN_FAILURES
FILE_SIZE_UPD
ORA$AUTOTASK_CLEAN
PMO_DEFERRED_GIDX_MAINT_JOB
PURGE_LOG
RSE$CLEAN_RECOVERABLE_SCRIPT
SM$CLEAN_AUTO_SPLIT_MERGE
| FGR$AUTOPURGE_JOB
FILE_WATCHER
HM_CREATE_OFFLINE_DICTIONARY
LOAD_OPATCH_INVENTORY
ORA$PREPLUGIN_BACKUP_JOB
XMLDB_NFS_CLEANUP_JOB
|
| Oracle Database 21c | BSLN_MAINTAIN_STATS_JOB
CLEANUP_NON_EXIST_OBJ
CLEANUP_ONLINE_IND_BUILD
CLEANUP_ONLINE_PMO
CLEANUP_TAB_IOT_PMO
CLEANUP_TRANSIENT_PKG
CLEANUP_TRANSIENT_TYPE
DRA_REEVALUATE_OPEN_FAILURES
FILE_SIZE_UPD
ORA$AUTOTASK_CLEAN
PMO_DEFERRED_GIDX_MAINT_JOB
PURGE_LOG
| FGR$AUTOPURGE_JOB
FILE_WATCHER
HM_CREATE_OFFLINE_DICTIONARY
LOAD_OPATCH_INVENTORY
ORA$PREPLUGIN_BACKUP_JOB
ORA$_ATSK_AUTOSTS
XMLDB_NFS_CLEANUP_JOB
|
## Oracle Scheduler プロシージャの共通パラメータ
Oracle Scheduler のタスクを実行するには、Amazon RDS パッケージ `rdsadmin.rdsadmin_dbms_scheduler` を使用します。いくつかのパラメータは、パッケージ内のすべてのプロシージャに共通です。パッケージ内の共通パラメータは以下のとおりです。
****
| パラメータ名 | データ型 | 有効な値 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- | --- |
| `name` | varchar2 | 「[Oracle DB インスタンスの一般的なスケジューリングタスクの実行](#Appendix.Oracle.CommonDBATasks.Scheduler)」の表に記載されている手順 | — | はい | 変更するジョブの名前。 |
| `attribute` | varchar2 | `'REPEAT_INTERVAL'`,`'SCHEDULE_NAME'` | – | はい | 変更する属性。 ジョブの繰り返し間隔を変更するには、`'REPEAT_INTERVAL'` を指定します。 ジョブのスケジュール名を変更するには、`'SCHEDULE_NAME'` を指定します。 |
| `value` | varchar2 | 使用される属性に応じて、有効なスケジュール間隔またはスケジュール名。 | – | はい | 属性の新しい値。 |
## DBMS\$1SCHEDULER ジョブの変更
Oracle 手順`dbms_scheduler.set_attribute`を使用して、Oracle スケジューラの特定のコンポーネントを変更します。詳細については、Oracle ドキュメントの「[DBMS\$1SCHEDULER](https://docs.oracle.com/database/121/ARPLS/d_sched.htm#ARPLS72235)」と「[SET\$1ATTRIBUTE プロシージャ](https://docs.oracle.com/database/121/ARPLS/d_sched.htm#ARPLS72399)」を参照してください。
Amazon RDS DB インスタンスを使用するときは、オブジェクト名にスキーマ名 `SYS` を付加します。次の例では、Monday ウィンドウオブジェクトのリソースプラン属性を設定します。
```
BEGIN
DBMS_SCHEDULER.SET_ATTRIBUTE(
name => 'SYS.MONDAY_WINDOW',
attribute => 'RESOURCE_PLAN',
value => 'resource_plan_1');
END;
/
```
## 自動タスクメンテナンスウィンドウの変更
Amazon RDS for Oracle インスタンスは、メンテナンスウィンドウのデフォルト設定で作成されます。オプティマイザ統計収集などの自動メンテナンスタスクは、これらのウィンドウで実行されます。デフォルトでは、メンテナンスウィンドウは Oracle Database リソースマネージャーをオンにします。
`DBMS_SCHEDULER`パッケージを使用して。ウィンドウを変更します。次のような理由から、メンテナンスウィンドウの設定を変更する必要がある場合があります。
+ メンテナンスジョブを別の時間に実行するか、異なる設定で実行するか、まったく実行しないようにする。例えば、ウィンドウの継続時間を変更したり、繰り返し時間と間隔を変更したりできます。
+ メンテナンス中にリソースマネージャーを有効にしたときの、パフォーマンスへの影響を回避する必要があります。例えば、デフォルトのメンテナンスプランが指定されていて、データベースがロードされている間にメンテナンスウィンドウが開いた場合、`resmgr:cpu quantum`のような待機イベントを表示する必要があります。この待機イベントは、データベースリソースマネージャーに関連しています。次のオプションがあります。
+ DB インスタンスのオフピーク時にメンテナンスウィンドウがアクティブであることを確認します。
+ デフォルトのメンテナンスプランを無効にするには、空の文字列に`resource_plan`属性を設定します。
+ パラメータグループの`resource_manager_plan`パラメータを`FORCE:`に設定します。インスタンスでエンタープライズエディションを使用している場合、この設定により、データベースリソースマネージャープランがアクティブ化されなくなります。
**メンテナンスウィンドウの設定を変更するには**
1. Oracle SQL クライアントを使用して、データベースに接続します。
1. スケジューラウィンドウの現在の設定をクエリします。
次の例では、`MONDAY_WINDOW`の設定をクエリします。
```
SELECT ENABLED, RESOURCE_PLAN, DURATION, REPEAT_INTERVAL
FROM DBA_SCHEDULER_WINDOWS
WHERE WINDOW_NAME='MONDAY_WINDOW';
```
次の出力は、ウィンドウがデフォルト値を使用していることを示しています。
```
ENABLED RESOURCE_PLAN DURATION REPEAT_INTERVAL
--------------- ------------------------------ ---------------- ------------------------------
TRUE DEFAULT_MAINTENANCE_PLAN +000 04:00:00 freq=daily;byday=MON;byhour=22
;byminute=0; bysecond=0
```
1. `DBMS_SCHEDULER`パッケージを使用して、ウィンドウを変更します。
次の例では、リソースプランを null に設定して、リソースマネージャーがメンテナンスウィンドウ中に実行されないようにします。
```
BEGIN
-- disable the window to make changes
DBMS_SCHEDULER.DISABLE(name=>'"SYS"."MONDAY_WINDOW"',force=>TRUE);
-- specify the empty string to use no plan
DBMS_SCHEDULER.SET_ATTRIBUTE(name=>'"SYS"."MONDAY_WINDOW"', attribute=>'RESOURCE_PLAN', value=>'');
-- re-enable the window
DBMS_SCHEDULER.ENABLE(name=>'"SYS"."MONDAY_WINDOW"');
END;
/
```
次の例では、ウィンドウの最大時間を 2 時間に設定します。
```
BEGIN
DBMS_SCHEDULER.DISABLE(name=>'"SYS"."MONDAY_WINDOW"',force=>TRUE);
DBMS_SCHEDULER.SET_ATTRIBUTE(name=>'"SYS"."MONDAY_WINDOW"', attribute=>'DURATION', value=>'0 2:00:00');
DBMS_SCHEDULER.ENABLE(name=>'"SYS"."MONDAY_WINDOW"');
END;
/
```
次の例では、繰り返し間隔を毎週月曜日の午前 10 時に設定します。
```
BEGIN
DBMS_SCHEDULER.DISABLE(name=>'"SYS"."MONDAY_WINDOW"',force=>TRUE);
DBMS_SCHEDULER.SET_ATTRIBUTE(name=>'"SYS"."MONDAY_WINDOW"', attribute=>'REPEAT_INTERVAL', value=>'freq=daily;byday=MON;byhour=10;byminute=0;bysecond=0');
DBMS_SCHEDULER.ENABLE(name=>'"SYS"."MONDAY_WINDOW"');
END;
/
```
## Oracle Scheduler ジョブのタイムゾーンの設定
Oracle Scheduler のタイムゾーンを変更するには、Oracle プロシージャ `dbms_scheduler.set_scheduler_attribute` を使用できます。`dbms_scheduler` パッケージの詳細については、Oracle ドキュメントの [DBMS\$1SCHEDULER](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_SCHEDULER.html) および [SET\$1SCHEDULER\$1ATTRIBUTE](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_SCHEDULER.html#GUID-2AB97BF7-7154-4E6C-933F-B2659B18A907) を参照してください。
**現在のタイムゾーン設定を変更するには**
1. SQL Developer などのクライアントを使用してデータベースに接続します。詳細については、「[Oracle SQL Developer を使用した DB インスタンスへの接続](USER_ConnectToOracleInstance.SQLDeveloper.md)」を参照してください。
1. デフォルトのタイムゾーンを以下のように設定し、`time_zone_name` をお客様のタイムゾーンに置き換えます。
```
BEGIN
DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE(
attribute => 'default_timezone',
value => 'time_zone_name'
);
END;
/
```
以下の例では、タイムゾーンをアジア/上海に変更します。
以下に示すように、まず現在のタイムゾーンをクエリします。
```
SELECT VALUE FROM DBA_SCHEDULER_GLOBAL_ATTRIBUTE WHERE ATTRIBUTE_NAME='DEFAULT_TIMEZONE';
```
出力は、現在のタイムゾーンが ETC/UTC であることを示しています。
```
VALUE
-------
Etc/UTC
```
次に、タイムゾーンをアジア/上海に設定します。
```
BEGIN
DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE(
attribute => 'default_timezone',
value => 'Asia/Shanghai'
);
END;
/
```
システムのタイムゾーンの変更の詳細については、「[Oracle のタイムゾーン](Appendix.Oracle.Options.Timezone.md)」を参照してください。
## SYS が所有する Oracle Scheduler ジョブの無効化
SYS ユーザーが所有する Oracle Scheduler ジョブを無効にするには、`rdsadmin.rdsadmin_dbms_scheduler.disable` プロシージャを使用します。
このプロシージャでは、Oracle Scheduler タスクの共通パラメータ `name` を使用します。詳細については、「[Oracle Scheduler プロシージャの共通パラメータ](#Appendix.Oracle.CommonDBATasks.Scheduler.CommonParameters)」を参照してください。
次の例では、`SYS.CLEANUP_ONLINE_IND_BUILD` Oracle Scheduler ジョブを無効にします。
```
BEGIN
rdsadmin.rdsadmin_dbms_scheduler.disable('SYS.CLEANUP_ONLINE_IND_BUILD');
END;
/
```
## SYS が所有する Oracle Scheduler ジョブを有効にする
SYS が所有する Oracle Scheduler ジョブを有効にするには、`rdsadmin.rdsadmin_dbms_scheduler.enable` プロシージャを使用します。
このプロシージャでは、Oracle Scheduler タスクの共通パラメータ `name` を使用します。詳細については、「[Oracle Scheduler プロシージャの共通パラメータ](#Appendix.Oracle.CommonDBATasks.Scheduler.CommonParameters)」を参照してください。
次の例では、`SYS.CLEANUP_ONLINE_IND_BUILD` Oracle Scheduler ジョブを有効にします。
```
BEGIN
rdsadmin.rdsadmin_dbms_scheduler.enable('SYS.CLEANUP_ONLINE_IND_BUILD');
END;
/
```
## CALENDAR タイプのジョブに対する Oracle Scheduler の繰り返し間隔の変更
`CALENDAR` タイプ の SYS 所有の Oracle Scheduler ジョブの繰り返し間隔を変更するには、`rdsadmin.rdsadmin_dbms_scheduler.disable` プロシージャを使用します。
このプロシージャでは、以下の Oracle Scheduler タスクの共通パラメータを使用します。
+ `name`
+ `attribute`
+ `value`
詳細については、「[Oracle Scheduler プロシージャの共通パラメータ](#Appendix.Oracle.CommonDBATasks.Scheduler.CommonParameters)」を参照してください。
次の例では、`SYS.CLEANUP_ONLINE_IND_BUILD` Oracle Scheduler ジョブの繰り返し間隔を変更します。
```
BEGIN
rdsadmin.rdsadmin_dbms_scheduler.set_attribute(
name => 'SYS.CLEANUP_ONLINE_IND_BUILD',
attribute => 'repeat_interval',
value => 'freq=daily;byday=FRI,SAT;byhour=20;byminute=0;bysecond=0');
END;
/
```
## NAMED タイプのジョブに対する Oracle Scheduler の繰り返し間隔の変更
一部の Oracle Scheduler ジョブでは、間隔ではなくスケジュール名が使用されます。このようなタイプのジョブの場合、マスターユーザースキーマに新しい名前付きスケジュールを作成する必要があります。これを行うには、スタンダードの `sys.dbms_scheduler.create_schedule` プロシージャを使用します。また、`rdsadmin.rdsadmin_dbms_scheduler.set_attribute procedure` を使用して、新しい名前付きスケジュールをジョブに割り当てます。
このプロシージャでは、以下の Oracle Scheduler タスクの共通パラメータを使用します。
+ `name`
+ `attribute`
+ `value`
詳細については、「[Oracle Scheduler プロシージャの共通パラメータ](#Appendix.Oracle.CommonDBATasks.Scheduler.CommonParameters)」を参照してください。
次の例では、`SYS.BSLN_MAINTAIN_STATS_JOB` Oracle Scheduler ジョブの繰り返し間隔を変更します。
```
BEGIN
DBMS_SCHEDULER.CREATE_SCHEDULE (
schedule_name => 'rds_master_user.new_schedule',
start_date => SYSTIMESTAMP,
repeat_interval => 'freq=daily;byday=MON,TUE,WED,THU,FRI;byhour=0;byminute=0;bysecond=0',
end_date => NULL,
comments => 'Repeats daily forever');
END;
/
BEGIN
rdsadmin.rdsadmin_dbms_scheduler.set_attribute (
name => 'SYS.BSLN_MAINTAIN_STATS_JOB',
attribute => 'schedule_name',
value => 'rds_master_user.new_schedule');
END;
/
```
## Oracle Scheduler ジョブ作成のオートコミットをオフにする
`DBMS_SCHEDULER.CREATE_JOB` が Oracle Scheduler ジョブを作成すると、すぐにジョブが作成され、変更がコミットされます。次の操作を行うには、Oracle Scheduler ジョブの作成をユーザートランザクションに組み込むことが必要な場合があります。
+ ユーザートランザクションがロールバックされたら、Oracle Schedule ジョブをロールバックします。
+ メインユーザートランザクションがコミットされたら、Oracle Scheduler ジョブを作成します。
`rdsadmin.rdsadmin_dbms_scheduler.set_no_commit_flag` プロシージャを使用してこの動作をオンにできます。この手順では、パラメータは使用しません。このプロシージャは、次の RDS for Oracle リリースで使用できます。
+ 21.0.0.0.ru-2022-07.rur-2022-07.r1 以上
+ 19.0.0.0.ru-2022-07.rur-2022-07.r1 以上
次の例では、Oracle Scheduler のオートコミットをオフにし、Oracle Scheduler ジョブを作成してから、トランザクションをロールバックします。オートコミットがオフになっているため、データベースは Oracle Scheduler ジョブの作成もロールバックします。
```
BEGIN
rdsadmin.rdsadmin_dbms_scheduler.set_no_commit_flag;
DBMS_SCHEDULER.CREATE_JOB(job_name => 'EMPTY_JOB',
job_type => 'PLSQL_BLOCK',
job_action => 'begin null; end;',
auto_drop => false);
ROLLBACK;
END;
/
PL/SQL procedure successfully completed.
SELECT * FROM DBA_SCHEDULER_JOBS WHERE JOB_NAME='EMPTY_JOB';
no rows selected
```
# RDS for Oracle DB インスタンスの問題の診断
Oracle Databaseは、データベースの問題を調査するために使用できる障害診断能力インフラストラクチャを備えています。Oracle の用語では、*問題*は、コードのバグやデータの破損などの重大なエラーです。*インシデント*とは、問題の発生です。同じエラーが 3 回発生した場合、このインフラストラクチャには、この問題の 3 つのインシデントが示されます。詳細は、Oracle Databaseドキュメントの「[問題の診断と解決](https://docs.oracle.com/en/database/oracle/oracle-database/19/admin/diagnosing-and-resolving-problems.html#GUID-8DEB1BE0-8FB9-4FB2-A19A-17CF6F5791C3)」を参照してください。
自動診断リポジトリコマンドインタープリタ (ADRCI) ユーティリティは、診断データの管理に使用する Oracle コマンドラインツールです。例えば、このツールを使用して問題を調査し、診断データをパッケージ化することができます。*インシデントパッケージ*には、特定の問題を参照する 1 つのインシデントまたはすべてのインシデントの診断データが含まれます。.zipファイルとして実装されているインシデントパッケージを Oracle サポートにアップロードできます。
マネージドサービスエクスペリエンスを提供するために、Amazon RDS は ADRCI へのシェルアクセスを提供していません。RDS for Oracle DB インスタンスの診断タスクを実行するには、Amazon RDS パッケージ `rdsadmin.rdsadmin_adrci_util` を使用します。
`rdsadmin_adrci_util` で関数を使用すると、問題やインシデントをリストしてパッケージ化でき、トレースファイルも表示できます。すべての関数はタスク ID を返します。この ID は、`dbtask-task_id.log` のように ADRCI 出力を含むログファイルの名前の一部を形成します。ログファイルは BDUMP ディレクトリにあります。[データベースログファイルのダウンロード](USER_LogAccess.Procedural.Downloading.md) で説明した手順に従って、ログファイルをダウンロードできます。
## 診断手順の共通パラメータ
診断タスクを実行するには、 Amazon RDS パッケージ `rdsadmin.rdsadmin_adrci_util` 内の関数を使用します。パッケージ内の共通パラメータは以下のとおりです。
****
| パラメータ名 | データ型 | 有効な値 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- | --- |
| `incident_id` | number | 有効なインシデント ID または null | Null | いいえ | 値が null の場合、関数はすべてのインシデントを表示します。値が null ではなく、有効なインシデント ID を指定している場合は、関数は指定されたインシデントを表示します。 |
| `problem_id` | number | 有効な問題 ID または null | Null | いいえ | 値が null の場合、関数はすべての問題を表示します。値が null ではなく、有効な問題 ID を表す場合、関数は指定された問題を表示します。 |
| `last` | number | 0 より大きい有効な整数、または null | Null | いいえ | 値が null の場合、関数は最大 50 個の項目を表示します。値が null でない場合、関数は指定された数を表示します。 |
## インシデントのリスト化
Oracle の診断インシデントを一覧表示するには、Amazon RDS 関数 `rdsadmin.rdsadmin_adrci_util.list_adrci_incidents` を使用します。インシデントは、ベーシックモードまたは詳細モードのいずれかでリストできます。デフォルトでは、この関数は最新の 50 件のインシデントをリストします。
この関数は、以下の共通パラメータを使用します。
+ `incident_id`
+ `problem_id`
+ `last`
`incident_id` と `problem_id` を指定すると、`incident_id` は `problem_id` より優先されます。詳細については、「[診断手順の共通パラメータ](#Appendix.Oracle.CommonDBATasks.CommonDiagParameters)」を参照してください。
この関数は、次の追加パラメータを使用します。
****
| パラメータ名 | データ型 | 有効な値 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- | --- |
| `detail` | boolean | TRUE 、、または FALSE | `FALSE` | いいえ | `TRUE` の場合、関数はインシデントを詳細モードでリストします。`FALSE` の場合、この関数はインシデントをベーシックモードでリストします。 |
すべてのインシデントを一覧表示するには、引数を指定せずに `rdsadmin.rdsadmin_adrci_util.list_adrci_incidents` 関数をクエリします。クエリはタスク ID を返します。
```
SQL> SELECT rdsadmin.rdsadmin_adrci_util.list_adrci_incidents AS task_id FROM DUAL;
TASK_ID
------------------
1590786706158-3126
```
または、引数を指定せずに `rdsadmin.rdsadmin_adrci_util.list_adrci_incidents` 関数を呼び出し、出力を SQL クライアント変数に保存します。変数は、他のステートメントで使用できます。
```
SQL> VAR task_id VARCHAR2(80);
SQL> EXEC :task_id := rdsadmin.rdsadmin_adrci_util.list_adrci_incidents;
PL/SQL procedure successfully completed.
```
ログファイルを読み取るには、Amazon RDS プロシージャ `rdsadmin.rds_file_util.read_text_file` を呼び出します。ファイル名の一部としてタスク ID を指定します。次の出力は、53523、53522、53521 の 3 つのインシデントを示しています。
```
SQL> SELECT * FROM TABLE(rdsadmin.rds_file_util.read_text_file('BDUMP', 'dbtask-'||:task_id||'.log'));
TEXT
-------------------------------------------------------------------------------------------------------------------------
2020-05-29 21:11:46.193 UTC [INFO ] Listing ADRCI incidents.
2020-05-29 21:11:46.256 UTC [INFO ]
ADR Home = /rdsdbdata/log/diag/rdbms/orcl_a/ORCL:
*************************************************************************
INCIDENT_ID PROBLEM_KEY CREATE_TIME
----------- ----------------------------------------------------------- ----------------------------------------
53523 ORA 700 [EVENT_CREATED_INCIDENT] [942] [SIMULATED_ERROR_003 2020-05-29 20:15:20.928000 +00:00
53522 ORA 700 [EVENT_CREATED_INCIDENT] [942] [SIMULATED_ERROR_002 2020-05-29 20:15:15.247000 +00:00
53521 ORA 700 [EVENT_CREATED_INCIDENT] [942] [SIMULATED_ERROR_001 2020-05-29 20:15:06.047000 +00:00
3 rows fetched
2020-05-29 21:11:46.256 UTC [INFO ] The ADRCI incidents were successfully listed.
2020-05-29 21:11:46.256 UTC [INFO ] The task finished successfully.
14 rows selected.
```
特定のインシデントをリストするには、`incident_id` パラメータを使用してその ID を指定します。次の例では、インシデント 53523 のみのログファイルをクエリします。
```
SQL> EXEC :task_id := rdsadmin.rdsadmin_adrci_util.list_adrci_incidents(incident_id=>53523);
PL/SQL procedure successfully completed.
SQL> SELECT * FROM TABLE(rdsadmin.rds_file_util.read_text_file('BDUMP', 'dbtask-'||:task_id||'.log'));
TEXT
------------------------------------------------------------------------------------------------------------------
2020-05-29 21:15:25.358 UTC [INFO ] Listing ADRCI incidents.
2020-05-29 21:15:25.426 UTC [INFO ]
ADR Home = /rdsdbdata/log/diag/rdbms/orcl_a/ORCL:
*************************************************************************
INCIDENT_ID PROBLEM_KEY CREATE_TIME
-------------------- ----------------------------------------------------------- ---------------------------------
53523 ORA 700 [EVENT_CREATED_INCIDENT] [942] [SIMULATED_ERROR_003 2020-05-29 20:15:20.928000 +00:00
1 rows fetched
2020-05-29 21:15:25.427 UTC [INFO ] The ADRCI incidents were successfully listed.
2020-05-29 21:15:25.427 UTC [INFO ] The task finished successfully.
12 rows selected.
```
## 問題のリスト化
Oracle の診断問題を一覧表示するには、Amazon RDS 関数 `rdsadmin.rdsadmin_adrci_util.list_adrci_problems` を使用します。
デフォルトでは、この関数は最新の 50 個の問題をリストします。
この関数は、共通パラメータ `problem_id` と `last` を使用します。詳細については、「[診断手順の共通パラメータ](#Appendix.Oracle.CommonDBATasks.CommonDiagParameters)」を参照してください。
すべての問題のタスク ID を取得するには、引数を指定せずに `rdsadmin.rdsadmin_adrci_util.list_adrci_problems` 関数を呼び出し、出力を SQL クライアント可変に格納します。
```
SQL> EXEC :task_id := rdsadmin.rdsadmin_adrci_util.list_adrci_problems;
PL/SQL procedure successfully completed.
```
ログファイルを読み込むには、ファイル名の一部としてタスク ID を指定し、`rdsadmin.rds_file_util.read_text_file` 関数を呼び出します。次の出力では、ログファイルには 1、2、3 の 3 つの問題が表示されます。
```
SQL> SELECT * FROM TABLE(rdsadmin.rds_file_util.read_text_file('BDUMP', 'dbtask-'||:task_id||'.log'));
TEXT
----------------------------------------------------------------------------------------------------------------------
2020-05-29 21:18:50.764 UTC [INFO ] Listing ADRCI problems.
2020-05-29 21:18:50.829 UTC [INFO ]
ADR Home = /rdsdbdata/log/diag/rdbms/orcl_a/ORCL:
*************************************************************************
PROBLEM_ID PROBLEM_KEY LAST_INCIDENT LASTINC_TIME
---------- ----------------------------------------------------------- ------------- ---------------------------------
2 ORA 700 [EVENT_CREATED_INCIDENT] [942] [SIMULATED_ERROR_003 53523 2020-05-29 20:15:20.928000 +00:00
3 ORA 700 [EVENT_CREATED_INCIDENT] [942] [SIMULATED_ERROR_002 53522 2020-05-29 20:15:15.247000 +00:00
1 ORA 700 [EVENT_CREATED_INCIDENT] [942] [SIMULATED_ERROR_001 53521 2020-05-29 20:15:06.047000 +00:00
3 rows fetched
2020-05-29 21:18:50.829 UTC [INFO ] The ADRCI problems were successfully listed.
2020-05-29 21:18:50.829 UTC [INFO ] The task finished successfully.
14 rows selected.
```
次の例では、問題 3 のみをリストします。
```
SQL> EXEC :task_id := rdsadmin.rdsadmin_adrci_util.list_adrci_problems(problem_id=>3);
PL/SQL procedure successfully completed.
```
問題 3 のログファイルを読み込むには、`rdsadmin.rds_file_util.read_text_file` を呼び出します。ファイル名の一部としてタスク ID を指定します。
```
SQL> SELECT * FROM TABLE(rdsadmin.rds_file_util.read_text_file('BDUMP', 'dbtask-'||:task_id||'.log'));
TEXT
-------------------------------------------------------------------------
2020-05-29 21:19:42.533 UTC [INFO ] Listing ADRCI problems.
2020-05-29 21:19:42.599 UTC [INFO ]
ADR Home = /rdsdbdata/log/diag/rdbms/orcl_a/ORCL:
*************************************************************************
PROBLEM_ID PROBLEM_KEY LAST_INCIDENT LASTINC_TIME
---------- ----------------------------------------------------------- ------------- ---------------------------------
3 ORA 700 [EVENT_CREATED_INCIDENT] [942] [SIMULATED_ERROR_002 53522 2020-05-29 20:15:15.247000 +00:00
1 rows fetched
2020-05-29 21:19:42.599 UTC [INFO ] The ADRCI problems were successfully listed.
2020-05-29 21:19:42.599 UTC [INFO ] The task finished successfully.
12 rows selected.
```
## インシデントパッケージの作成
Amazon RDS 関数 `rdsadmin.rdsadmin_adrci_util.create_adrci_package` を使用してインシデントパッケージを作成できます。出力は、Oracle サポートに提供できる .zip ファイルです。
この関数は、以下の共通パラメータを使用します。
+ `problem_id`
+ `incident_id`
上記のパラメータのいずれかを必ず指定してください。両方のパラメータを指定した場合、`incident_id` は `problem_id` をオーバーライドします。詳細については、「[診断手順の共通パラメータ](#Appendix.Oracle.CommonDBATasks.CommonDiagParameters)」を参照してください。
特定のインシデントのパッケージを作成するには、`rdsadmin.rdsadmin_adrci_util.create_adrci_package` パラメータを指定して Amazon RDS 関数 `incident_id` を呼び出します。次の例では、インシデント 53523 のパッケージを作成します。
```
SQL> EXEC :task_id := rdsadmin.rdsadmin_adrci_util.create_adrci_package(incident_id=>53523);
PL/SQL procedure successfully completed.
```
ログファイルを読み込むには、`rdsadmin.rds_file_util.read_text_file` を呼び出します。ファイル名の一部としてタスク ID を指定することができます。出力は、インシデントパッケージ `ORA700EVE_20200529212043_COM_1.zip` を生成したことを示しています。
```
SQL> SELECT * FROM TABLE(rdsadmin.rds_file_util.read_text_file('BDUMP', 'dbtask-'||:task_id||'.log'));
TEXT
--------------------------------------------------------------------------------------------------------------------------------------
2020-05-29 21:20:43.031 UTC [INFO ] The ADRCI package is being created.
2020-05-29 21:20:47.641 UTC [INFO ] Generated package 1 in file /rdsdbdata/log/trace/ORA700EVE_20200529212043_COM_1.zip, mode complete
2020-05-29 21:20:47.642 UTC [INFO ] The ADRCI package was successfully created.
2020-05-29 21:20:47.642 UTC [INFO ] The task finished successfully.
```
特定の問題の診断データをパッケージ化するには、`problem_id` パラメータを使用してその ID を指定します。次の例では、問題 3 のデータのみをパッケージ化します。
```
SQL> EXEC :task_id := rdsadmin.rdsadmin_adrci_util.create_adrci_package(problem_id=>3);
PL/SQL procedure successfully completed.
```
タスク出力を読み取るには、ファイル名の一部としてタスク ID を指定して `rdsadmin.rds_file_util.read_text_file` を呼び出します。出力は、インシデントパッケージ `ORA700EVE_20200529212111_COM_1.zip` を生成したことを示しています。
```
SQL> SELECT * FROM TABLE(rdsadmin.rds_file_util.read_text_file('BDUMP', 'dbtask-'||:task_id||'.log'));
TEXT
------------------------------------------------------------------------------------------------------------------------------------------------------------
2020-05-29 21:21:11.050 UTC [INFO ] The ADRCI package is being created.
2020-05-29 21:21:15.646 UTC [INFO ] Generated package 2 in file /rdsdbdata/log/trace/ORA700EVE_20200529212111_COM_1.zip, mode complete
2020-05-29 21:21:15.646 UTC [INFO ] The ADRCI package was successfully created.
2020-05-29 21:21:15.646 UTC [INFO ] The task finished successfully.
```
ログファイルをダウンロードすることもできます。詳細については、「[データベースログファイルのダウンロード](USER_LogAccess.Procedural.Downloading.md)」を参照してください。
## トレースファイルの表示
Amazon RDS 関数 `rdsadmin.rdsadmin_adrci_util.show_adrci_tracefile` を使用すると、trace ディレクトリの下にあるトレースファイルと、現在の ADR ホームにあるすべてのインシデントディレクトリを一覧表示できます。トレースファイルとインシデントトレースファイルの内容を表示することもできます。
この関数は、次のパラメータを使用します。
****
| パラメータ名 | データ型 | 有効な値 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- | --- |
| `filename` | varchar2 | 有効なトレースファイル名 | Null | いいえ | 値が null の場合、関数はすべてのトレースファイルを表示します。null でない場合、関数は指定されたファイルを表示します。 |
トレースファイルを表示するには、Amazon RDS 関数 `rdsadmin.rdsadmin_adrci_util.show_adrci_tracefile` を呼び出します。
```
SQL> EXEC :task_id := rdsadmin.rdsadmin_adrci_util.show_adrci_tracefile;
PL/SQL procedure successfully completed.
```
トレースファイル名をリストするには、ファイル名の一部としてタスク ID を指定して、Amazon RDS プロシージャ `rdsadmin.rds_file_util.read_text_file` を呼び出します。
```
SQL> SELECT * FROM TABLE(rdsadmin.rds_file_util.read_text_file('BDUMP', 'dbtask-'||:task_id||'.log')) WHERE TEXT LIKE '%/alert_%';
TEXT
---------------------------------------------------------------
diag/rdbms/orcl_a/ORCL/trace/alert_ORCL.log.2020-05-28
diag/rdbms/orcl_a/ORCL/trace/alert_ORCL.log.2020-05-27
diag/rdbms/orcl_a/ORCL/trace/alert_ORCL.log.2020-05-26
diag/rdbms/orcl_a/ORCL/trace/alert_ORCL.log.2020-05-25
diag/rdbms/orcl_a/ORCL/trace/alert_ORCL.log.2020-05-24
diag/rdbms/orcl_a/ORCL/trace/alert_ORCL.log.2020-05-23
diag/rdbms/orcl_a/ORCL/trace/alert_ORCL.log.2020-05-22
diag/rdbms/orcl_a/ORCL/trace/alert_ORCL.log.2020-05-21
diag/rdbms/orcl_a/ORCL/trace/alert_ORCL.log
9 rows selected.
```
次の例では、`alert_ORCL.log` の出力を生成します。
```
SQL> EXEC :task_id := rdsadmin.rdsadmin_adrci_util.show_adrci_tracefile('diag/rdbms/orcl_a/ORCL/trace/alert_ORCL.log');
PL/SQL procedure successfully completed.
```
ログファイルを読み込むには、`rdsadmin.rds_file_util.read_text_file` を呼び出します。ファイル名の一部としてタスク ID を指定します。出力には、alert\$1ORCL.log の初期の 10 行が表示されます。
```
SQL> SELECT * FROM TABLE(rdsadmin.rds_file_util.read_text_file('BDUMP', 'dbtask-'||:task_id||'.log')) WHERE ROWNUM <= 10;
TEXT
-----------------------------------------------------------------------------------------
2020-05-29 21:24:02.083 UTC [INFO ] The trace files are being displayed.
2020-05-29 21:24:02.128 UTC [INFO ] Thu May 28 23:59:10 2020
Thread 1 advanced to log sequence 2048 (LGWR switch)
Current log# 3 seq# 2048 mem# 0: /rdsdbdata/db/ORCL_A/onlinelog/o1_mf_3_hbl2p8xs_.log
Thu May 28 23:59:10 2020
Archived Log entry 2037 added for thread 1 sequence 2047 ID 0x5d62ce43 dest 1:
Fri May 29 00:04:10 2020
Thread 1 advanced to log sequence 2049 (LGWR switch)
Current log# 4 seq# 2049 mem# 0: /rdsdbdata/db/ORCL_A/onlinelog/o1_mf_4_hbl2qgmh_.log
Fri May 29 00:04:10 2020
10 rows selected.
```
ログファイルをダウンロードすることもできます。詳細については、「[データベースログファイルのダウンロード](USER_LogAccess.Procedural.Downloading.md)」を参照してください。
# Oracle DB インスタンスのその他のタスクの実行
次に、Oracle を実行している Amazon RDS DB インスタンスでその他の DBA タスクを実行する方法を示します。マネージド型サービスの操作性を実現するために、Amazon RDS では DB インスタンスへのシェルアクセスは提供していません。また、上位の権限を必要とする特定のシステムプロシージャやシステムテーブルへのアクセスが制限されます。
**Topics**
+ [主要データストレージ領域でのディレクトリの作成と削除](#Appendix.Oracle.CommonDBATasks.NewDirectories)
+ [DB インスタンスディレクトリ内のファイルのリスト化](#Appendix.Oracle.CommonDBATasks.ListDirectories)
+ [DB インスタンスディレクトリ内のファイルの読み取り](#Appendix.Oracle.CommonDBATasks.ReadingFiles)
+ [Opatch ファイルへのアクセス](#Appendix.Oracle.CommonDBATasks.accessing-opatch-files)
+ [アドバイザータスクの管理](#Appendix.Oracle.CommonDBATasks.managing-advisor-tasks)
+ [テーブルスペースの転送](rdsadmin_transport_util.md)
## 主要データストレージ領域でのディレクトリの作成と削除
ディレクトリを作成するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.create_directory` を使用します。最大 10,000 個のディレクトリを作成でき、すべてメインデータストレージ領域に配置されます。ディレクトリを作成するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.drop_directory` を使用します。
`create_directory` および `drop_directory` プロシージャには、以下の必須パラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_directory_name` | VARCHAR2 | — | はい | ディレクトリの名前。 |
次の例では、新しいディレクトリ `PRODUCT_DESCRIPTIONS` を作成します。
```
EXEC rdsadmin.rdsadmin_util.create_directory(p_directory_name => 'product_descriptions');
```
データディクショナリは、ディレクトリ名を大文字で保存します。`DBA_DIRECTORIES` を照会することで、ディレクトリを一覧表示できます。システムによって実際のホストパス名が自動的に選択されます。以下の例では、`PRODUCT_DESCRIPTIONS` という名前のディレクトリのディレクトリパスを取得しています。
```
SELECT DIRECTORY_PATH
FROM DBA_DIRECTORIES
WHERE DIRECTORY_NAME='PRODUCT_DESCRIPTIONS';
DIRECTORY_PATH
----------------------------------------
/rdsdbdata/userdirs/01
```
DB インスタンスのマスターユーザー名には、新しいディレクトリでの読み取りおよび書き込み権限があり、他のユーザーにアクセスを許可できます。`EXECUTE` 権限は、DB インスタンス上のディレクトリでは使用できません。ディレクトリはメインデータストレージ領域に作成され、領域および I/O 帯域幅を消費します。
以下の例では、`PRODUCT_DESCRIPTIONS` という名前のディレクトリを削除します。
```
EXEC rdsadmin.rdsadmin_util.drop_directory(p_directory_name => 'product_descriptions');
```
**注記**
Oracle SQL コマンド `DROP DIRECTORY` を使用してディレクトリを削除することもできます。
ディレクトリを削除してもその内容は削除されません。`rdsadmin.rdsadmin_util.create_directory` プロシージャはパス名を再利用できるため、削除されたディレクトリのファイルが新たに作成されたディレクトリに存在する可能性があります。ディレクトリを削除する前に、`UTL_FILE.FREMOVE` を使用してディレクトリからファイルを削除することをお勧めします。詳細については、Oracle ドキュメントの「[FREMOVE プロシージャ](https://docs.oracle.com/database/121/ARPLS/u_file.htm#ARPLS70924)」を参照してください。
## DB インスタンスディレクトリ内のファイルのリスト化
ディレクトリ内のファイルを一覧表示するには、Amazon RDS プロシージャ `rdsadmin.rds_file_util.listdir` を使用します。このプロシージャは Oracle レプリカではサポートされていません。`listdir` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_directory` | varchar2 | — | はい | 一覧表示するディレクトリの名前。 |
次の例では、ディレクトリ `PRODUCT_DESCRIPTIONS` に対する読み取り/書き込み権限をユーザー `rdsadmin` に付与し、このディレクトリ内のファイルを一覧表示します。
```
GRANT READ,WRITE ON DIRECTORY PRODUCT_DESCRIPTIONS TO rdsadmin;
SELECT * FROM TABLE(rdsadmin.rds_file_util.listdir(p_directory => 'PRODUCT_DESCRIPTIONS'));
```
## DB インスタンスディレクトリ内のファイルの読み取り
テキストファイルを読み取るには、Amazon RDS プロシージャ `rdsadmin.rds_file_util.read_text_file` を使用します。`read_text_file` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_directory` | varchar2 | — | はい | ファイルを含むディレクトリの名前。 |
| `p_filename` | varchar2 | — | はい | 読み取るファイルの名前。 |
次の例では `rice.txt` ディレクトリの `PRODUCT_DESCRIPTIONS` ファイルを読み取ります。
```
declare
fh sys.utl_file.file_type;
begin
fh := utl_file.fopen(location=>'PRODUCT_DESCRIPTIONS', filename=>'rice.txt', open_mode=>'w');
utl_file.put(file=>fh, buffer=>'AnyCompany brown rice, 15 lbs');
utl_file.fclose(file=>fh);
end;
/
```
次の例では、ディレクトリ `rice.txt` からファイル `PRODUCT_DESCRIPTIONS` を読み取ります。
```
SELECT * FROM TABLE
(rdsadmin.rds_file_util.read_text_file(
p_directory => 'PRODUCT_DESCRIPTIONS',
p_filename => 'rice.txt'));
```
## Opatch ファイルへのアクセス
Opatch は、Oracle ソフトウェアへのパッチの適用とロールバックを可能にする Oracle ユーティリティです。データベースに適用されているパッチを判別するための Oracle のメカニズムは、`opatch lsinventory` コマンドです。Bring Your Own License (BYOL) の顧客のサービスリクエストを開くために、Oracle サポートは `lsinventory` ファイルをリクエストします。Opatch によって生成される `lsinventory_detail` ファイルをリクエストする場合もあります。
マネージドサービスエクスペリエンスを提供するために、Amazon RDS には Opatch へのシェルアクセスは用意されていません。代わりに、BDUMP ディレクトリの`lsinventory-dbv.txt`には、現在のエンジンのバージョンに関連するパッチ情報が含まれています。マイナーアップグレードまたはメジャーアップグレードを実行すると、Amazon RDS はパッチを適用してから 1 時間以内に`lsinventory-dbv.txt`を更新します。適用されたパッチを確認するには、`lsinventory-dbv.txt`を読み取ります。このアクションは、`opatch lsinventory`コマンドの実行に似ています。
**注記**
このセクションの例では、BDUMP ディレクトリ名を `BDUMP` としています。リードレプリカでは、BDUMP ディレクトリ名が異なります。BDUMP 名を取得するためにリードレプリカに対してクエリ `V$DATABASE.DB_UNIQUE_NAME` を実行する方法については、「[ファイルのリスト化](USER_LogAccess.Concepts.Oracle.md#USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles.ViewingBackgroundDumpDest)」を参照してください。
インベントリファイルは Amazon RDS 命名規則 `lsinventory-dbv.txt` および `lsinventory_detail-dbv.txt` を使用します。ここで、*dbv* は DB バージョンの完全な名前です。`lsinventory-dbv.txt` ファイルはすべての DB バージョンで使用できます。対応する `lsinventory_detail-dbv.txt` は、19.0.0.0、ru-2020-01.rur-2020-01.r1 以降で利用できます。
例えば、DB のバージョンが 19.0.0.0.ru-2021-07.rur-2021-07.r1 の場合、インベントリファイルは以下の名前になります。
```
lsinventory-19.0.0.0.ru-2021-07.rur-2021-07.r1.txt
lsinventory_detail-19.0.0.0.ru-2021-07.rur-2021-07.r1.txt
```
DB エンジンの現在のバージョンと一致するファイルをダウンロードしてください。
### コンソール
**コンソールを使用してインベントリファイルをダウンロードするには**
1. Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**データベース**] を選択します。
1. 表示するログファイルのある DB インスタンスの名前を選択します。
1. [**ログとイベント**] タブを選択します。
1. [**ログ**] セクションまで下にスクロールします。
1. [**ログ**] セクションで、`lsinventory` を検索します。
1. アクセスするファイルを選択し、[**ダウンロード**] を選択します。
### SQL
SQL クライアントで `lsinventory-dbv.txt` を読み取るには、`SELECT` ステートメントを使用できます。この手法では、`rdsadmin` 関数として `rdsadmin.rds_file_util.read_text_file` または `rdsadmin.tracefile_listing` のいずれかを使用します。
以下のサンプルクエリでは、*dbv* を Oracle DB のバージョンに置き換えます。例えば、DB のバージョンは 19.0.0.0.ru-2020-04.rur-2020-04.r1 です。
```
SELECT text
FROM TABLE(rdsadmin.rds_file_util.read_text_file('BDUMP', 'lsinventory-dbv.txt'));
```
### PL/SQL
SQL クライアントで `lsinventory-dbv.txt` を読み取るには、PL/SQL プログラムを作成します。このプログラムは、`utl_file` を使用してファイルを読み取り、`dbms_output` を使用して出力します。これらは、Oracle が提供するパッケージです。
以下のサンプルプログラムでは、*dbv* を Oracle DB のバージョンに置き換えます。例えば、DB のバージョンは 19.0.0.0.ru-2020-04.rur-2020-04.r1 です。
```
SET SERVEROUTPUT ON
DECLARE
v_file SYS.UTL_FILE.FILE_TYPE;
v_line VARCHAR2(1000);
v_oracle_home_type VARCHAR2(1000);
c_directory VARCHAR2(30) := 'BDUMP';
c_output_file VARCHAR2(30) := 'lsinventory-dbv.txt';
BEGIN
v_file := SYS.UTL_FILE.FOPEN(c_directory, c_output_file, 'r');
LOOP
BEGIN
SYS.UTL_FILE.GET_LINE(v_file, v_line,1000);
DBMS_OUTPUT.PUT_LINE(v_line);
EXCEPTION
WHEN no_data_found THEN
EXIT;
END;
END LOOP;
END;
/
```
または、`rdsadmin.tracefile_listing` をクエリし、出力をファイルにスプールします。以下の例では、出力を `/tmp/tracefile.txt` にスプールします。
```
SPOOL /tmp/tracefile.txt
SELECT *
FROM rdsadmin.tracefile_listing
WHERE FILENAME LIKE 'lsinventory%';
SPOOL OFF;
```
## アドバイザータスクの管理
Oracle Database には、多数のアドバイザーが含まれています。各アドバイザーは、自動タスクと手動タスクをサポートします。`rdsadmin.rdsadmin_util` パッケージ内のプロシージャを使用して、いくつかのアドバイザータスクを管理できます。
アドバイザータスク手順は、次のエンジンバージョンで使用できます。
+ Oracle Database 21c (21.0.0)
+ Version 19.0.0.0.ru-2021-01.rur-2021-01.r1 以上の Oracle Database 19c バージョン
詳細については、「*Amazon RDS for Oracle リリースノート*」の「[バージョン 19.0.0.0.ru-2021-01.rur-2021-01.r1](https://docs.aws.amazon.com/AmazonRDS/latest/OracleReleaseNotes/oracle-version-19-0.html#oracle-version-RU-RUR.19.0.0.0.ru-2021-01.rur-2021-01.r1)」を参照してください。
**Topics**
+ [アドバイザータスクのパラメータの設定](#Appendix.Oracle.CommonDBATasks.setting-task-parameters)
+ [AUTO\$1STATS\$1ADVISOR\$1TASK を無効にする](#Appendix.Oracle.CommonDBATasks.dropping-advisor-task)
+ [AUTO\$1STATS\$1ADVISOR\$1TASK を再度有効にする](#Appendix.Oracle.CommonDBATasks.recreating-advisor-task)
### アドバイザータスクのパラメータの設定
一部のアドバイザータスクのパラメータを設定するには、Amazon RDS 手順 `rdsadmin.rdsadmin_util.advisor_task_set_parameter` を使用します。`advisor_task_set_parameter` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_task_name` | varchar2 | — | はい | パラメータを変更するアドバイザータスクの名前。以下の値が有効です。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.Misc.html) |
| `p_parameter` | varchar2 | — | はい | タスクパラメータの名前。アドバイザータスクの有効なパラメータを検索するには、次のクエリを実行します。*p\$1task\$1name* を `p_task_name` の有効な値に置き換えます: COL PARAMETER_NAME FORMAT a30
COL PARAMETER_VALUE FORMAT a30
SELECT PARAMETER_NAME, PARAMETER_VALUE
FROM DBA_ADVISOR_PARAMETERS
WHERE TASK_NAME='p_task_name'
AND PARAMETER_VALUE != 'UNUSED'
ORDER BY PARAMETER_NAME;
|
| `p_value` | varchar2 | — | はい | タスクパラメータの値。タスクパラメータの有効な値を検索するには、次のクエリを実行します。*p\$1task\$1name* を `p_task_name` の有効な値に置き換えます: COL PARAMETER_NAME FORMAT a30
COL PARAMETER_VALUE FORMAT a30
SELECT PARAMETER_NAME, PARAMETER_VALUE
FROM DBA_ADVISOR_PARAMETERS
WHERE TASK_NAME='p_task_name'
AND PARAMETER_VALUE != 'UNUSED'
ORDER BY PARAMETER_NAME;
|
次の PL/SQL プログラムは `ACCEPT_PLANS` を `FALSE` の `SYS_AUTO_SPM_EVOLVE_TASK` に設定します。SQL Plan Management の自動化タスクでは、プランが検証され、その結果のレポートが生成されますが、プランを自動的には進化させません。レポートを使用して、新しい SQL 計画ベースラインを識別し、手動で受け入れることができます。
```
BEGIN
rdsadmin.rdsadmin_util.advisor_task_set_parameter(
p_task_name => 'SYS_AUTO_SPM_EVOLVE_TASK',
p_parameter => 'ACCEPT_PLANS',
p_value => 'FALSE');
END;
```
次の PL/SQL プログラムは `EXECUTION_DAYS_TO_EXPIRE` を `10` の `AUTO_STATS_ADVISOR_TASK` に設定します。事前定義されたタスク `AUTO_STATS_ADVISOR_TASK` は、メンテナンスウィンドウで 1 日 1 回自動的に実行されます。この例では、タスク実行の保持期間を 10 日に設定します。
```
BEGIN
rdsadmin.rdsadmin_util.advisor_task_set_parameter(
p_task_name => 'AUTO_STATS_ADVISOR_TASK',
p_parameter => 'EXECUTION_DAYS_TO_EXPIRE',
p_value => '10');
END;
```
### AUTO\$1STATS\$1ADVISOR\$1TASK を無効にする
`AUTO_STATS_ADVISOR_TASK` を無効にするには、Amazon RDS 手順 `rdsadmin.rdsadmin_util.advisor_task_drop` を使用します。`advisor_task_drop` 手順は、次のパラメータを受け付けます。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_task_name` | varchar2 | — | はい | 無効にするアドバイザータスクの名前。唯一の有効な値は `AUTO_STATS_ADVISOR_TASK` です。 |
次のコマンドは `AUTO_STATS_ADVISOR_TASK` をドロップします。
```
EXEC rdsadmin.rdsadmin_util.advisor_task_drop('AUTO_STATS_ADVISOR_TASK')
```
`rdsadmin.rdsadmin_util.dbms_stats_init` を使用して `AUTO_STATS_ADVISOR_TASK` を再度有効にすることができます。
### AUTO\$1STATS\$1ADVISOR\$1TASK を再度有効にする
`AUTO_STATS_ADVISOR_TASK` を再度有効にするには、Amazon RDS 手順 `rdsadmin.rdsadmin_util.dbms_stats_init` を使用します。`dbms_stats_init` 手順では、パラメータは使用しません。
次のコマンドは `AUTO_STATS_ADVISOR_TASK` を再度有効にします。
```
EXEC rdsadmin.rdsadmin_util.dbms_stats_init()
```
# テーブルスペースの転送
Amazon RDS パッケージ `rdsadmin.rdsadmin_transport_util` を使用して、オンプレミスの Oracle データベースから RDS for Oracle DB インスタンスにテーブルスペースのセットをコピーします。物理レベルでは、この転送可能テーブルスペース機能は、ソースデータファイルとメタデータファイルをターゲットインスタンスに増分的にコピーします。ファイルは、Amazon EFS または Amazon S3 のいずれかを使用して転送できます。詳細については、「[Oracle トランスポータブル表領域を使用した移行](oracle-migrating-tts.md)」を参照してください。
**Topics**
+ [転送されたテーブルスペースを DB インスタンスにインポートする](rdsadmin_transport_util_import_xtts_tablespaces.md)
+ [転送可能テーブルスペースメタデータを DB インスタンスにインポートする](rdsadmin_transport_util_import_xtts_metadata.md)
+ [テーブルスペースのインポート後の孤立ファイルを一覧表示する](rdsadmin_transport_util_list_xtts_orphan_files.md)
+ [テーブルスペースのインポート後に孤立したデータファイルを削除する](rdsadmin_transport_util_cleanup_incomplete_xtts_import.md)
# 転送されたテーブルスペースを DB インスタンスにインポートする
プロシージャ `rdsadmin.rdsadmin_transport_util.import_xtts_tablespaces` を使用して、ソース DB インスタンスから以前にエクスポートしたテーブルスペースを復元します。トランスポートフェーズでは、読み取り専用のテーブルスペースをバックアップし、Data Pump メタデータをエクスポートし、これらのファイルをターゲット DB インスタンスに転送して、テーブルスペースをインポートします。詳細については、「[フェーズ 4: 表領域をトランスポートする](oracle-migrating-tts.md#oracle-migrating-tts.final-br-phase)」を参照してください。
## 構文
```
FUNCTION import_xtts_tablespaces(
p_tablespace_list IN CLOB,
p_directory_name IN VARCHAR2,
p_platform_id IN NUMBER DEFAULT 13,
p_parallel IN INTEGER DEFAULT 0) RETURN VARCHAR2;
```
## パラメータ
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_tablespace_list` | `CLOB` | — | はい | インポートするテーブルスペースのリスト。 |
| `p_directory_name` | `VARCHAR2` | — | はい | テーブルスペースのバックアップを含むディレクトリ。 |
| `p_platform_id` | `NUMBER` | `13` | いいえ | バックアップフェーズで指定したものと一致するプラットフォーム ID を指定します。プラットフォームのリストを検索するには、`V$TRANSPORTABLE_PLATFORM` をクエリします。デフォルトのプラットフォームは Linux x86 64 ビットで、これはリトルエンディアンです。 |
| `p_parallel` | `INTEGER` | `0` | いいえ | 並列処理の度合い。デフォルトでは、並列処理は無効になっています。 |
## 例
以下の例では、表領域*TBS1*、*TBS2*、および *TBS3* をディレクトリ *DATA\$1PUMP\$1DIR* からインポートします。ソースプラットフォームは AIX ベースのシステム (64 ビット) で、プラットフォーム ID は `6` です。プラットフォーム ID は、`V$TRANSPORTABLE_PLATFORM` をクエリすることで確認できます。
```
VAR task_id CLOB
BEGIN
:task_id:=rdsadmin.rdsadmin_transport_util.import_xtts_tablespaces(
'TBS1,TBS2,TBS3',
'DATA_PUMP_DIR',
p_platform_id => 6);
END;
/
PRINT task_id
```
# 転送可能テーブルスペースメタデータを DB インスタンスにインポートする
プロシージャ `rdsadmin.rdsadmin_transport_util.import_xtts_metadata` を使用して、転送可能テーブルスペースメタデータを RDS for Oracle DB インスタンスにインポートします。操作中、メタデータのインポートのステータスがテーブル `rdsadmin.rds_xtts_operation_info` に表示されます。詳細については、「[ステップ 5: ターゲット DB インスタンスに表領域メタデータをインポートする](oracle-migrating-tts.md#oracle-migrating-tts.transport.import-dmp)」を参照してください。
## 構文
```
PROCEDURE import_xtts_metadata(
p_datapump_metadata_file IN SYS.DBA_DATA_FILES.FILE_NAME%TYPE,
p_directory_name IN VARCHAR2,
p_exclude_stats IN BOOLEAN DEFAULT FALSE,
p_remap_tablespace_list IN CLOB DEFAULT NULL,
p_remap_user_list IN CLOB DEFAULT NULL);
```
## パラメータ
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_datapump_metadata_file` | `SYS.DBA_DATA_FILES.FILE_NAME%TYPE` | — | はい | 転送可能テーブルスペースのメタデータを含む Oracle Data Pumpファイルの名前。 |
| `p_directory_name` | `VARCHAR2` | — | はい | Data Pump ファイルを含むディレクトリ。 |
| `p_exclude_stats` | `BOOLEAN` | `FALSE` | いいえ | 統計を除外するかどうかを示すフラグ。 |
| `p_remap_tablespace_list` | `CLOB` | NULL | いいえ | メタデータのインポート中に再マップされるテーブルスペースのリスト。形式 `from_tbs:to_tbs` を使用します。例えば、`users:user_data` と指定します。 |
| `p_remap_user_list` | `CLOB` | NULL | いいえ | メタデータのインポート中に再マップされるユーザースキーマのリスト。形式 `from_schema_name:to_schema_name` を使用します。例えば、`hr:human_resources` と指定します。 |
## 例
この例では、ディレクトリ *DATA\$1PUMP\$1DIR* にあるファイル *xttdump.dmp* からテーブルスペースメタデータをインポートします。
```
BEGIN
rdsadmin.rdsadmin_transport_util.import_xtts_metadata('xttdump.dmp','DATA_PUMP_DIR');
END;
/
```
# テーブルスペースのインポート後の孤立ファイルを一覧表示する
`rdsadmin.rdsadmin_transport_util.list_xtts_orphan_files` プロシージャを使用して、テーブルスペースのインポート後に孤立したデータファイルを一覧表示します。データファイルを特定したら、`rdsadmin.rdsadmin_transport_util.cleanup_incomplete_xtts_import` を呼び出して削除できます。
## 構文
```
FUNCTION list_xtts_orphan_files RETURN xtts_orphan_files_list_t PIPELINED;
```
## 例
次の例では、`rdsadmin.rdsadmin_transport_util.list_xtts_orphan_files` プロシージャを呼び出します。出力には、孤立した 2 つのデータファイルが表示されます。
```
SQL> SELECT * FROM TABLE(rdsadmin.rdsadmin_transport_util.list_xtts_orphan_files);
FILENAME FILESIZE
-------------- ---------
datafile_7.dbf 104865792
datafile_8.dbf 104865792
```
# テーブルスペースのインポート後に孤立したデータファイルを削除する
`rdsadmin.rdsadmin_transport_util.list_xtts_orphan_files` プロシージャを使用して、テーブルスペースのインポート後に孤立したデータファイルを削除します。このコマンドを実行すると、`BDUMP` ディレクトリに、名前形式 `rds-xtts-delete_xtts_orphaned_files-YYYY-MM-DD.HH24-MI-SS.FF.log` を使用するログファイルが生成されます。プロシージャ `rdsadmin.rdsadmin_transport_util.cleanup_incomplete_xtts_import` を使用して、孤立したファイルを見つけます。プロシージャ `rdsadmin.rds_file_util.read_text_file` を呼び出することによって、ログファイルを読み取ることができます。詳細については、「[フェーズ 6: 残ったファイルをクリーンアップする](oracle-migrating-tts.md#oracle-migrating-tts.cleanup)」を参照してください。
## 構文
```
PROCEDURE cleanup_incomplete_xtts_import(
p_directory_name IN VARCHAR2);
```
## パラメータ
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_directory_name` | `VARCHAR2` | — | はい | 孤立したデータファイルを含むディレクトリ。 |
## 例
次の例では、*DATA\$1PUMP\$1DIR* にある孤立したデータファイルを削除します。
```
BEGIN
rdsadmin.rdsadmin_transport_util.cleanup_incomplete_xtts_import('DATA_PUMP_DIR');
END;
/
```
次の例では、前のコマンドで生成されたログファイルを読み取ります。
```
SELECT *
FROM TABLE(rdsadmin.rds_file_util.read_text_file(
p_directory => 'BDUMP',
p_filename => 'rds-xtts-delete_xtts_orphaned_files-2023-06-01.09-33-11.868894000.log'));
TEXT
--------------------------------------------------------------------------------
orphan transported datafile datafile_7.dbf deleted.
orphan transported datafile datafile_8.dbf deleted.
```
# RDS for Oracle でストレージを使用する
すべての RDS for Oracle インスタンスにはプライマリストレージボリュームがあります。ストレージ容量を増やすには、DB インスタンスに最大 3 つの追加のストレージボリュームをアタッチできます。ワークロードの要件に応じて、ボリュームごとに gp3 ストレージと io2 ストレージのいずれかを選択します。例えば、頻繁にアクセスされるデータを io2 ボリュームに配置し、履歴データを gp3 ボリュームに配置することができます。
追加のストレージボリュームを使用すると、次の利点が得られます。
+ **拡張容量** – 最大 3 つの追加ストレージボリュームをアタッチして、DB インスタンスごとに合計ストレージを最大 256 TiB までスケールします。
+ **柔軟なストレージ設定とパフォーマンスの最適化** – さまざまなストレージタイプ (gp3 と io2) を混在させて、データアクセスパターンに基づいてコストとパフォーマンスの両方を最適化します。高性能 io2 ストレージのアクセス頻度の高いデータを、費用対効果の高い gp3 ストレージのアーカイブデータから分離します。
+ **必要に応じてストレージ容量を拡張および削減する** – データ移行中と同様に、追加のストレージが必要な場合はボリュームをアタッチし、後でボリュームを削除します。このようにして、DB インスタンスストレージの合計を拡張および削減できます。
+ **オンラインデータ移動** – Oracle データベースの組み込み機能を使用して、ダウンタイムなしでボリューム間でデータを移動します。
**注記**
追加のストレージボリュームを削除することはできますが、プライマリボリュームを削除することはできません。
**Topics**
+ [RDS for Oracle で追加のストレージボリュームを使用する際の考慮事項](#User_Oracle_AdditionalStorage.considerations)
+ [RDS for Oracle で追加のストレージボリュームを使用する場合の制限](#User_Oracle_AdditionalStorage.limitations)
+ [RDS for Oracle の追加ストレージボリュームを使用したデータベース管理オペレーション](#User_Oracle_AdditionalStorage.DBManagement)
+ [RDS for Oracle を使用してストレージボリュームを追加、削除、または変更する](User_Oracle_AdditionalStorage.ModifyStorageVolumes.md)
+ [RDS for Oracle で追加のストレージボリュームを使用してデータをバックアップおよび復元する](User_Oracle_AdditionalStorage.BackupRestore.md)
+ [RDS for Oracle の追加ストレージボリュームのユースケース](User_Oracle_AdditionalStorage.UseCases.md)
## RDS for Oracle で追加のストレージボリュームを使用する際の考慮事項
RDS for Oracle で追加のストレージボリュームを使用する場合は、次の点を考慮してください。
+ インスタンスごとに最大 3 つのストレージボリュームを追加できます。
+ 追加のストレージボリュームでは、次のボリューム名を使用する必要があります。
+ rdsdbdata2
+ rdsdbdata3
+ rdsdbdata4
+ 汎用 SSD (gp3) およびプロビジョンド IOPS SSD (io2) ストレージタイプのみを追加できます。
+ Oracle のオンライン再配置機能を使用して、アプリケーションの実行中にボリューム間でデータを移動できます。
+ DB インスタンスを変更して追加のストレージボリュームを作成すると、RDS はスケジュールの変更設定に関係なく、ストレージボリュームをすぐに作成します。ストレージボリュームの追加はオンラインオペレーションであり、データベースのパフォーマンスには影響しません。「[スケジュール変更設定の使用](USER_ModifyInstance.ApplyImmediately.md)」を参照してください。
最適なパフォーマンスを得るには、追加のストレージボリュームを使用する際に以下を確認してください。
+ データ移動計画
+ オフピーク時に大きな動きをスケジュールする
+ 大きなオペレーションを小さなチャンクに分割する
+ 移動中にシステムリソースをモニタリングする
+ リソース管理
+ 両方のボリュームに十分な空き領域を確保する
+ AWR または Statspack を使用して I/O パターンをモニタリングする
+ ストレージフルシナリオを監視する
+ ベストプラクティス
+ 可能な場合はオンラインデータファイル再配置オペレーションを使用する
+ 適切なインデックスを維持する
+ スペースの使用状況を定期的にモニタリングする
レプリカで追加のストレージボリュームを使用する場合:
+ 追加のストレージボリュームがある DB インスタンスの RDS for Oracle レプリカを作成する場合、RDS はレプリカに追加のストレージボリュームを自動的に設定します。ただし、プライマリ DB インスタンスのストレージボリュームに加えられた後続の変更は、レプリカに自動的に適用されません。
+ ボリューム間でデータファイルの場所を管理する場合は、プライマリインスタンスとレプリカインスタンス間の一貫した動作を確保するために、セッションレベルの変更ではなくパラメータグループ設定を使用することをお勧めします。
## RDS for Oracle で追加のストレージボリュームを使用する場合の制限
RDS for Oracle での追加のストレージボリュームの使用には、次の制限が適用されます。
+ 64GiB 未満のメモリを持つインスタンスタイプには、大きなストレージボリュームをサポートするのに十分なメモリがないため、ストレージボリュームを追加することはできません。
+ 追加のストレージボリュームの最小ストレージサイズは 200GiB です。DB インスタンスのプライマリストレージボリュームは、追加のストレージボリュームをアタッチするために 200GiB 以上である必要があります。DB インスタンスの最大ストレージサイズは、すべてのボリュームで合計 256 TiB です。
+ 追加のストレージボリュームを持つ DB インスタンスでは、以下の機能はサポートされていません。
+ クロスリージョン自動バックアップ
+ ストレージの自動スケーリング (追加のストレージボリューム用)
+ クロスアカウントスナップショットコピー
+ パブリックスナップショット
+ プライマリストレージボリューム (`rdsdbdata`) を削除することはできませんが、空である限り、他の追加のストレージボリュームを削除できます。
+ オンライン REDO ログ、アーカイブされた REDO ログ、および制御ファイルを追加のストレージボリュームに保存することはできません。これらのファイルは、プライマリストレージボリューム (`rdsdbdata`) にのみ保存できます。
## RDS for Oracle の追加ストレージボリュームを使用したデータベース管理オペレーション
RDS for Oracle で追加のストレージボリュームを使用しながら、テーブルスペースの作成やストレージボリューム間のデータの移動などのデータベース管理オペレーションを実行できます。追加のストレージボリュームを使用したデータベース管理オペレーションの詳細については、以下のセクションを参照してください。
+ [RDS for Oracle でのデータベースファイルの場所の指定](Appendix.Oracle.CommonDBATasks.TablespacesAndDatafiles.md#Appendix.Oracle.CommonDBATasks.DatabaseFileLocations)
+ [RDS for Oracle でのテーブルスペースの作成とサイズ設定](Appendix.Oracle.CommonDBATasks.TablespacesAndDatafiles.md#Appendix.Oracle.CommonDBATasks.CreatingTablespacesAndDatafiles)
+ [RDS for Oracle のボリューム間でのデータファイルの移動](Appendix.Oracle.CommonDBATasks.MovingDataBetweenVolumes.md#Appendix.Oracle.CommonDBATasks.MovingDatafiles)
# RDS for Oracle を使用してストレージボリュームを追加、削除、または変更する
AWS マネジメントコンソールまたは AWS CLI を使用して、追加のストレージボリュームを追加、変更、削除できます。すべてのオペレーションでは、`additional-storage-volumes` パラメータを指定して `modify-db-instance` コマンドを使用します。
**重要**
ストレージボリュームを追加または削除すると、バックアップ保留中のアクションとブラックアウトウィンドウが作成されます。バックアップワークフローが完了すると、ブラックアウトウィンドウが閉じます。
## ストレージボリュームの追加
プライマリストレージボリュームに加えて最大 3 つのストレージボリュームを追加できます。RDS for Oracle DB インスタンスに新しいストレージボリュームを追加するには、`additional-storage-volumes` パラメータを指定して `modify-db-instance` コマンドを使用します。
次のコードスニペットは、4000 プロビジョニング IOPS 名 `rdsdbdata3` を持つ 5,000 GiB の汎用 SSD (gp3) ボリュームを追加します。
```
aws rds modify-db-instance \
--db-instance-identifier my-oracle-instance \
--region us-east-1 \
--additional-storage-volumes '[
{
"VolumeName":"rdsdbdata3",
"StorageType":"gp3",
"AllocatedStorage":5000
"IOPS":4000}
]' \
--apply-immediately
```
## ストレージボリュームの変更
追加のストレージボリュームのストレージタイプ、割り当てられたストレージサイズ、IOPS、ストレージスループット設定を変更できます。次のコードスニペットは、`rdsdbdata2` ボリュームの IOPS 設定を変更します。
```
aws rds modify-db-instance \
--db-instance-identifier my-oracle-instance \
--region us-east-1 \
--additional-storage-volumes '[
{
"VolumeName":"rdsdbdata2",
"IOPS":8000}
]' \
--apply-immediately
```
**注記**
インスタンスに追加した追加のストレージボリュームのストレージ割り当てを減らすことはできません。
## ストレージボリュームの削除
不要になった追加のストレージボリュームは、RDS for Oracle DB インスタンスから削除できます。ボリュームを削除する前に、ボリュームからすべてのデータベースファイルを移動し、それを参照しているデータベースオブジェクトがないことを確認してください。ボリュームステータスが `Not-in-use` になっていることを確認します。追加のストレージボリュームを削除することはできますが、プライマリストレージボリュームを削除することはできません。
**警告**
追加のストレージボリュームを削除する前に、データベースファイルがボリュームに保存されていないことを確認してください。アクティブなデータベースファイルを持つボリュームを削除すると、データベースが破損する原因となります。
次の例では、`rdsdbdata4` ボリュームを削除しています。
```
aws rds modify-db-instance \
--db-instance-identifier my-oracle-instance \
--region us-east-1 \
--additional-storage-volumes '[
{
"VolumeName":"rdsdbdata2",
"SetForDelete":true}
]' \
--apply-immediately
```
# RDS for Oracle で追加のストレージボリュームを使用してデータをバックアップおよび復元する
自動バックアップを使用して、追加のストレージボリュームを含む DB インスタンスで DB スナップショットを作成できます。すべてのバックアップオペレーションには、プライマリボリュームと追加のストレージボリュームの両方が含まれます。追加のストレージボリュームで DB インスタンスのポイントインタイムリカバリを使用することもできます。データベースを復元するときに、ストレージボリュームを追加できます。既存のボリュームのストレージ設定を変更することもできます。スナップショットからデータベースを復元するときに、追加のストレージボリュームを削除することはできません。
**Topics**
+ [手動スナップショットを作成する](#User_Oracle_AdditionalStorage.BackupRestore.ManualSnapshots)
+ [手動スナップショットの復元](#User_Oracle_AdditionalStorage.BackupRestore.RestoreSnapshots)
+ [ポイントインタイムリカバリ](#User_Oracle_AdditionalStorage.BackupRestore.PitR)
## 手動スナップショットを作成する
次の例では、追加のストレージボリュームを使用してデータベースの手動スナップショットを作成します。
```
aws rds create-db-snapshot \
--db-instance-identifier my-oracle-asv-instance \
--db-snapshot-identifier my-snapshot
```
## 手動スナップショットの復元
スナップショットから復元する場合、新しいストレージボリュームを追加したり、既存のボリュームの IOPS またはスループット設定を変更したりできます。次の例では、スナップショットから DB インスタンスを復元し、`rdsdbdata2` ボリュームの IOPS 設定を変更します。
```
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier my-restored-instance \
--db-snapshot-identifier my-snapshot \
--region us-east-1 \
--additional-storage-volumes '[
{
"VolumeName":"rdsdbdata2",
"IOPS":5000
}
]'
```
## ポイントインタイムリカバリ
ポイントインタイムリカバリ (PITR) 中に、カスタム設定で新しいストレージボリュームを追加できます。次の例では、PITR を実行し、`rdsdbdata2` ボリュームに対して 5000 IOPS と 200 MB/秒のストレージスループットを備えた新しい 5,000 GiB 汎用 SSD (gp3) を追加します。
```
aws rds restore-db-instance-to-point-in-time \
--source-db-instance-identifier my-source-instancemy-source-instance \
--target-db-instance my-pitr-instance\
--use-latest-restorable-time \
--region us-east-1 \
--additional-storage-volumes '[
{
"VolumeName":"rdsdbdata2",
"StorageType":"gp3",
"AllocatedStorage":5000,
"IOPS":5000,
"StorageThroughput":200
}
]'
```
# RDS for Oracle の追加ストレージボリュームのユースケース
追加のストレージボリュームは、さまざまなデータベース管理シナリオをサポートします。以下のセクションでは、一般的なユースケースと実装アプローチについて説明します。
**Topics**
+ [64 TiB を超えるストレージ容量の拡張](#User_Oracle_AdditionalStorage.UseCases.Extendingstoragecapacity)
+ [アクセス頻度の高いデータとアクセス頻度の低いデータを別々のボリュームにストレージの階層化](#User_Oracle_AdditionalStorage.UseCases.Storagetiering)
+ [データのロードとアンロード用の一時ストレージ](#User_Oracle_AdditionalStorage.UseCases.Temporarystorage)
+ [追加のストレージボリュームで Oracle トランスポータブル表領域を使用する](#User_Oracle_AdditionalStorage.UseCases.TransportableTablespaces)
## 64 TiB を超えるストレージ容量の拡張
プライマリストレージボリュームが 64 TiB の制限に近づいたが、データベースにより多くのストレージ容量が必要な場合、追加のストレージボリュームを使用できます。`modify-db-instance` コマンドを使用して、それぞれ最大 64TiB の追加のストレージボリュームを DB インスタンスにアタッチできます。追加のストレージボリュームをアタッチした後、追加のストレージボリュームにテーブルスペースを作成し、標準の Oracle SQL を使用してテーブル、インデックス、パーティションなどのオブジェクトをこれらのテーブルスペースに移動できます。詳細については、「[RDS for Oracle の追加ストレージボリュームを使用したデータベース管理オペレーション](User_Oracle_AdditionalStorage.md#User_Oracle_AdditionalStorage.DBManagement)」を参照してください。
## アクセス頻度の高いデータとアクセス頻度の低いデータを別々のボリュームにストレージの階層化
ボリューム間で異なるストレージタイプを設定することで、追加のストレージボリュームを使用してコストとパフォーマンスを最適化できます。例えば、費用対効果の高い汎用 (gp3) ストレージボリュームに履歴データを保存しながら、頻繁にアクセスされるデータに高性能のプロビジョンド IOPS SSD ストレージ (io2) ボリュームを使用できます。標準の Oracle コマンドを使用して、特定のデータベースオブジェクト (テーブル、インデックス、パーティション) をこれらのテーブルスペースに移動できます。詳細については、「[RDS for Oracle の追加ストレージボリュームを使用したデータベース管理オペレーション](User_Oracle_AdditionalStorage.md#User_Oracle_AdditionalStorage.DBManagement)」を参照してください。
## データのロードとアンロード用の一時ストレージ
次のステップでは、追加のストレージボリュームを、大規模なデータロードまたはエクスポートの一時ストレージとして使用できます。
+ 次のコマンドを使用して、追加のストレージボリュームにディレクトリを作成します。
```
BEGIN
rdsadmin.rdsadmin_util.create_directory(
p_directory_name => 'DATA_PUMP_DIR2',
p_database_volume_name => 'rdsdbdata2');
END;
/
```
+ ディレクトリを作成したら、「[Oracle Data Pump を使用したインポート](Oracle.Procedural.Importing.DataPump.md)」で説明されている手順に従って、データを新しいディレクトリにエクスポートおよびインポートします。
+ オペレーションが完了したら、ファイルを削除し、オプションでボリュームを削除してストレージコストを節約します。追加のストレージボリュームは、ボリュームが空である場合にのみ削除できます。
## 追加のストレージボリュームで Oracle トランスポータブル表領域を使用する
追加のストレージボリュームを使用して、Oracle のトランスポータブル表領域を使用して、次のステップでデータファイルを追加のストレージボリュームに移動できます。
+ 追加のストレージボリュームを使用してトランスポータブル表領域をターゲットデータベースにインポートする前に、セッションレベルで `db_create_file_dest` パラメータを設定します。
```
ALTER SESSION SET db_create_file_dest = '/rdsdbdata2/db';
VAR x CLOB;
BEGIN
:x := rdsadmin.rdsadmin_transport_util.import_xtts_tablespaces(
p_tablespace_list => 'TBTEST1',
p_directory_name => 'XTTS_DIR_DATA2',
p_platform_id => 13);
END;
/
PRINT :x;
```
+ トランスポータブル表領域のインポートステータスを確認します。
```
ALTER SESSION SET nls_date_format = 'DD.MM.YYYY HH24:MI:SS';
COL xtts_operation_start_utc FORMAT A30
COL xtts_operation_end_utc FORMAT A30
COL xtts_operation_state FORMAT A30
COL xtts_operation_type FORMAT A30
SELECT xtts_operation_start_utc, xtts_operation_type, xtts_operation_state
FROM rdsadmin.rds_xtts_operation_info;
```
+ トランスポータブル表領域のインポートが完了したら、トランスポータブル表領域メタデータをインポートします。
```
BEGIN
rdsadmin.rdsadmin_transport_util.import_xtts_metadata(
p_datapump_metadata_file => 'xttdump.dmp',
p_directory_name => 'XTTS_DIR_DATA2');
END;
/
```
# RDS for Oracle の高度な機能の設定
RDS for Oracle は、HugePages、インスタンスストア、拡張データ型など、さまざまな高度な機能をサポートしています。
**Topics**
+ [RDS for Oracle インスタンスストアへの一時データの保存](CHAP_Oracle.advanced-features.instance-store.md)
+ [サポートされている RDS for Oracle インスタンスで HugePages をオンにする](Oracle.Concepts.HugePages.md)
+ [RDS for Oracle で拡張データ型を有効にする](Oracle.Concepts.ExtendedDataTypes.md)
# RDS for Oracle インスタンスストアへの一時データの保存
サポートされている RDS for Oracle DB のインスタンスクラスで、一時テーブルスペースとデータベースのスマートフラッシュキャッシュ (フラッシュキャッシュ) 用のインスタンスストアを使用します。
**Topics**
+ [RDS for Oracle インスタンスストアの概要](#CHAP_Oracle.advanced-features.instance-store.overview)
+ [RDS for Oracle インスタンスストアの有効化](#CHAP_Oracle.advanced-features.instance-store.Enable)
+ [RDS for Oracle インスタンスストアの設定](CHAP_Oracle.advanced-features.instance-store.configuring.md)
+ [Oracle リードレプリカ上のインスタンスストアでの作業](CHAP_Oracle.advanced-features.instance-store.replicas.md)
+ [インスタンスストアと Amazon EBS の一時テーブルスペースグループの設定](CHAP_Oracle.advanced-features.instance-store.temp-ebs.md)
+ [RDS for Oracle インスタンスストアの削除](#CHAP_Oracle.advanced-features.instance-store.Disable)
## RDS for Oracle インスタンスストアの概要
*インスタンスストア*は、RDS for Oracle DB インスタンスに一時ブロックレベルのストレージを提供します。インスタンスストアは、頻繁に変更される情報を一時的に保存するために使用できます。
インスタンスストアは、ホストコンピュータに物理的にアタッチされた不揮発性メモリエクスプレス (NVMe) デバイスをベースにしています。このストレージは、低レイテンシー、ランダム I/O パフォーマンス、シーケンシャル読み取りスループットを実現するために最適化されています。
インスタンスストアのサイズは DB インスタンスタイプによって異なります。インスタンスストアの詳細については、*Linux インスタンス向け Amazon Elastic Compute Cloud ユーザーガイド*の「[Amazon EC2 インスタンスストア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)」を参照してください。
**Topics**
+ [RDS for Oracle インスタンスストア内のデータのタイプ](#CHAP_Oracle.advanced-features.instance-store.overview.uses)
+ [RDS for Oracle インスタンスストアの利点](#CHAP_Oracle.advanced-features.instance-store.overview.benefits)
+ [サポートされている RDS for Oracle インスタンスストアのインスタンスクラス](#CHAP_Oracle.advanced-features.instance-store.overview.instance-classes)
+ [RDS for Oracle インスタンスストアでサポートされているエンジンバージョン](#CHAP_Oracle.advanced-features.instance-store.overview.db-versions)
+ [RDS for Oracle インスタンスストアでサポートされている AWS リージョン](#CHAP_Oracle.advanced-features.instance-store.overview.regions)
+ [RDS for Oracle インスタンスストアのコスト](#CHAP_Oracle.advanced-features.instance-store.overview.cost)
### RDS for Oracle インスタンスストア内のデータのタイプ
インスタンスストアには、次のタイプの RDS for Oracle 一時データを配置できます。
一時テーブルスペース
Oracle Database は、一時テーブルスペースを使用して、メモリに収まらない中間クエリ結果を保存します。クエリのサイズが大きいと、一時的にキャッシュする必要はあるが、永続化する必要はない大量の中間データが生成されることがあります。特に、一時テーブルスペースは、ソート、ハッシュ集計、および結合に役立ちます。RDS for Oracle DB インスタンスがエンタープライズエディションまたはスタンダードエディション 2 を使用している場合は、インスタンスストアに一時テーブルスペースを配置できます。
フラッシュキャッシュ
フラッシュキャッシュは、従来のパスでの単一ブロックのランダム読み取りのパフォーマンスを向上させます。ベストプラクティスは、アクティブなデータセットのほとんどを収容できるようにキャッシュのサイズを設定することです。RDS for Oracle DB インスタンスがエンタープライズエディションを使用している場合は、フラッシュキャッシュをインスタンスストアに配置できます。
デフォルトでは、インスタンスストアは一時テーブルスペース用に設定されていますが、フラッシュキャッシュ用には設定されていません。Oracle データファイルとデータベースログファイルは、インスタンスストアに配置できません。
### RDS for Oracle インスタンスストアの利点
失ってもかまわない一時ファイルとキャッシュを保存するためにインスタンスストアを使用することを検討してください。DB のパフォーマンスを改善したい場合、またはワークロードの増加が Amazon EBS ストレージのパフォーマンス上の問題を引き起こしている場合は、インスタンスストアをサポートするインスタンスクラスにスケーリングすることを検討してください。
一時テーブルスペースとフラッシュキャッシュをインスタンスストアに配置すると、次のような利点があります。
+ 読み込みのレイテンシーを短縮
+ 高スループット
+ Amazon EBS ボリュームの負荷を軽減
+ Amazon EBS の負荷が軽減されるため、ストレージとスナップショットのコストが削減されます
+ 高い IOPS をプロビジョニングする必要性が減り、全体的なコストが下がる可能性がある
一時的なテーブルスペースをインスタンスストアに配置すると、一時スペースを使用するクエリのパフォーマンスがすぐに向上します。フラッシュキャッシュをインスタンスストアに配置すると、通常、キャッシュされたブロック読み取りのレイテンシーは Amazon EBS の読み取りよりもはるかに短くなります。フラッシュキャッシュは、パフォーマンスを向上させる前に「ウォームアップ」する必要があります。データベースバッファキャッシュからブロックが期限切れになると、データベースがフラッシュキャッシュにブロックを書き込むため、キャッシュは自動的にウォームアップします。
**注記**
キャッシュ管理のため、フラッシュキャッシュが原因でパフォーマンスのオーバーヘッドが発生する場合があります。本番環境でフラッシュキャッシュを有効にする前に、ワークロードを分析し、テスト環境でキャッシュをテストすることをお勧めします。
### サポートされている RDS for Oracle インスタンスストアのインスタンスクラス
Amazon RDS は、次の DB インスタンスクラスのインスタンスストアをサポートしています。
+ db.m5d
+ db.m6id
+ db.r5d
+ db.r6id
+ db.x2idn
+ db.x2iedn
RDS for Oracle は、BYOL ライセンスモデルでのみ前述の DB インスタンスクラスをサポートします。詳細については、「[サポートされている RDS for Oracle DB インスタンスクラス](Oracle.Concepts.InstanceClasses.md#Oracle.Concepts.InstanceClasses.Supported)」および「[EE および SE2 の Bring Your Own License (BYOL)](Oracle.Concepts.Licensing.md#Oracle.Concepts.Licensing.BYOL)」を参照してください。
サポート対象の DB インスタンスタイプのインスタンスストレージの合計を確認するには、AWS CLI で次のコマンドを実行します。
**Example**
```
aws ec2 describe-instance-types \
--filters "Name=instance-type,Values=*5d.*large*,*6id.*large*" \
--query "InstanceTypes[?contains(InstanceType,'m5d')||contains(InstanceType,'r5d')||contains(InstanceType,'m6id')||contains(InstanceType,'r6id')][InstanceType, InstanceStorageInfo.TotalSizeInGB]" \
--output table
```
前述のコマンドは、インスタンスストアの未フォーマットデバイスサイズを返します。RDS for Oracle は、このスペースのごく一部を設定に使用します。一時テーブルスペースまたはフラッシュキャッシュに使用できるインスタンスストア内のスペースは、少し小さくなっています。
### RDS for Oracle インスタンスストアでサポートされているエンジンバージョン
インスタンスストアは、以下の RDS for Oracle エンジンバージョンでサポートされています。
+ 21.0.0.0.ru-2022-01.rur-2022-01.r1 以上の Oracle Database 21c バージョン
+ 19.0.0.0.ru-2021-10.rur-2021-10.r1 以上の Oracle Database 19c バージョン
### RDS for Oracle インスタンスストアでサポートされている AWS リージョン
インスタンスストアは、これらのインスタンスタイプの 1 つ以上がサポートされているすべての AWS リージョン で使用できます。db.m5d と db.r5d インスタンスクラスの詳細については、「[ DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。Amazon RDS for Oracle でサポートされるインスタンスクラスの詳細については、「[RDS for Oracle DB インスタンスクラス](Oracle.Concepts.InstanceClasses.md)」を参照してください。
### RDS for Oracle インスタンスストアのコスト
インスタンスストアのコストは、有効になっているインスタンスストアのコストに組み込まれます。RDS for Oracle DB インスタンスでインスタンスストアを有効にしても、追加料金は発生しません。instance-store turned on インスタンスの詳細については、「[サポートされている RDS for Oracle インスタンスストアのインスタンスクラス](#CHAP_Oracle.advanced-features.instance-store.overview.instance-classes)」を参照してください。
## RDS for Oracle インスタンスストアの有効化
RDS for Oracle テンポラリデータのインスタンスストアを有効にするには、次のいずれかの操作を行います。
+ サポートされているインスタンスクラスを使用して RDS for Oracle DB インスタンスを作成します。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ サポートされているインスタンスクラスを使用するように既存の RDS for Oracle DB インスタンスを変更します。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
# RDS for Oracle インスタンスストアの設定
デフォルトでは、インスタンスストア領域の 100% が一時テーブルスペースに割り当てられます。フラッシュキャッシュと一時テーブルスペースに領域を割り当てるようにインスタンスストアを設定するには、インスタンスのパラメータグループに次のパラメータを設定します。
**db\$1flash\$1cache\$1size=\$1DBInstanceStore\$1\$10,2,4,6,8,10\$1/10\$1**
このパラメータは、フラッシュキャッシュに割り当てられるストレージ容量を指定します。このパラメータは、Oracle Database Enterprise Edition でのみ有効です。デフォルト値は `{DBInstanceStore*0/10}` です。`db_flash_cache_size` にゼロ以外の値を設定した場合、RDS for Oracle インスタンスはインスタンスの再起動後にフラッシュキャッシュを有効にします。
**rds.instance\$1store\$1temp\$1size=\$1DBInstanceStore\$1\$10,2,4,6,8,10\$1/10\$1**
このパラメータは、一時テーブルスペースに割り当てられるストレージスペースの量を指定します。デフォルト値は `{DBInstanceStore*10/10}` です。このパラメータは Oracle Database Enterprise Edition では変更可能で、Standard Edition 2 では読み取り専用です `rds.instance_store_temp_size` にゼロ以外の値を設定すると、Amazon RDS はインスタンスストアのスペースを一時テーブルスペースに割り当てます。
インスタンスストアを使用しない DB インスタンスには、`db_flash_cache_size` および `rds.instance_store_temp_size` パラメータを設定できます。この場合、両方の設定が `0` に評価され、機能がオフになります。この場合、異なるインスタンスサイズやインスタンスストアを使用しないインスタンスに同じパラメータグループを使用できます。これらのパラメータを変更する場合は、変更を反映させるために関連するインスタンスを再起動してください。
一時テーブルスペースにスペースを割り当てても、Amazon RDS は一時テーブルスペースを自動的に作成しません。インスタンスストアに一時テーブルスペースを作成する方法については、「[インスタンスストアに一時テーブルスペースを作成する](Appendix.Oracle.CommonDBATasks.TablespacesAndDatafiles.md#Appendix.Oracle.CommonDBATasks.creating-tts-instance-store)」を参照してください。
前述のパラメータの合計値は、10/10 または 100% を超えてはなりません。次の表は、有効なパラメータ設定と無効なパラメータ設定を示しています。
| db\$1flash\$1cache\$1size 設定 | rds.instance\$1store\$1temp\$1size 設定 | 説明 |
| --- | --- | --- |
| db\$1flash\$1cache\$1size=\$1DBInstanceStore\$10/10\$1 | rds.instance\$1store\$1temp\$1size=\$1DBInstanceStore\$110/10\$1 | これは、Oracle Database のすべてのエディションで有効な設定です。Amazon RDS は、インスタンスストアスペースの 100% を一時テーブルスペースに割り当てます。これがデフォルトです。 |
| db\$1flash\$1cache\$1size=\$1DBInstanceStore\$110/10\$1 | rds.instance\$1store\$1temp\$1size=\$1DBInstanceStore\$10/10\$1 | これは、Oracle Database Enterprise Edition でのみ有効な設定です。Amazon RDS はインスタンスストア容量の 100% をフラッシュキャッシュに割り当てます。 |
| db\$1flash\$1cache\$1size=\$1DBInstanceStore\$12/10\$1 | rds.instance\$1store\$1temp\$1size=\$1DBInstanceStore\$18/10\$1 | これは、Oracle Database Enterprise Edition でのみ有効な設定です。Amazon RDS はインスタンスストア容量の 20% をフラッシュキャッシュに、インスタンスストア容量の 80% を一時テーブルスペースに割り当てます。 |
| db\$1flash\$1cache\$1size=\$1DBInstanceStore\$16/10\$1 | rds.instance\$1store\$1temp\$1size=\$1DBInstanceStore\$14/10\$1 | これは、Oracle Database Enterprise Edition でのみ有効な設定です。Amazon RDS は、インスタンスストア容量の 60% をフラッシュキャッシュに、40% のインスタンスストア容量を一時テーブルスペースに割り当てます。 |
| db\$1flash\$1cache\$1size=\$1DBInstanceStore\$12/10\$1 | rds.instance\$1store\$1temp\$1size=\$1DBInstanceStore\$14/10\$1 | これは、Oracle Database Enterprise Edition でのみ有効な設定です。Amazon RDS は、インスタンスストア容量の 20% をフラッシュキャッシュに、40% のインスタンスストア容量を一時テーブルスペースに割り当てます。 |
| db\$1flash\$1cache\$1size=\$1DBInstanceStore\$18/10\$1 | rds.instance\$1store\$1temp\$1size=\$1DBInstanceStore\$18/10\$1 | インスタンスストア容量の合計パーセンテージが 100% を超えているため、これは無効な設定です。このような場合、Amazon RDS は試行に失敗します。 |
## DB インスタンスタイプを変更する際の考慮事項
DB インスタンスタイプを変更すると、インスタンスストアのフラッシュキャッシュまたは一時テーブルスペースの設定に影響する可能性があります。以下の変更とその影響を考慮してください。
**インスタンスストアをサポートする DB インスタンスをスケールアップまたはスケールダウンします。**
次の値は、インスタンスストアの新しいサイズに比例して増減します。
+ フラッシュキャッシュの新しいサイズ。
+ インスタンスストアにある一時テーブルスペースに割り当てられた容量。
例えば、db.m5d.4xlarge インスタンスで `db_flash_cache_size={DBInstanceStore*6/10}` を設定すると約 340 GB のフラッシュキャッシュ容量が提供されます。インスタンスタイプを db.m5d.8xlarge にスケールアップすると、フラッシュキャッシュ容量は約 680 GB に増加します。
**インスタンスストアを使用しない DB インスタンスを、インスタンスストアを使用するインスタンスに変更します。**
`db_flash_cache_size` を `0` より大きい値に設定すると、フラッシュキャッシュが設定されます。`rds.instance_store_temp_size` を `0` より大きい値に設定すると、インスタンスストア領域は一時テーブルスペースが使用できるように割り当てられます。RDS for Oracle は、一時ファイルをインスタンスストアに自動的に移動しません。割り当てられたスペースの使用方法については、「[インスタンスストアに一時テーブルスペースを作成する](Appendix.Oracle.CommonDBATasks.TablespacesAndDatafiles.md#Appendix.Oracle.CommonDBATasks.creating-tts-instance-store)」または「[リードレプリカのインスタンスストアへの一時ファイルの追加](Appendix.Oracle.CommonDBATasks.using-tempfiles.md#Appendix.Oracle.CommonDBATasks.adding-tempfile-replica)」を参照してください。
**インスタンスストアを使用する DB インスタンスを、インスタンスストアを使用しないインスタンスに変更します。**
この場合、RDS for Oracle はフラッシュキャッシュを削除します。RDS は、Amazon EBS ボリュームのインスタンスストアに現在置かれている一時ファイルを再作成します。新しい一時ファイルの最大サイズは、`rds.instance_store_temp_size` パラメータの以前のサイズです。
# Oracle リードレプリカ上のインスタンスストアでの作業
リードレプリカは、インスタンスストアのフラッシュキャッシュと一時テーブルスペースをサポートします。フラッシュキャッシュはプライマリ DB インスタンスと同じように機能しますが、一時テーブルスペースについては以下の違いに注意してください。
+ リードレプリカでは一時テーブルスペースを作成できません。プライマリインスタンスに新しい一時テーブルスペースを作成すると、RDS for Oracle は一時ファイルなしでテーブルスペース情報をレプリケートします。新しい一時ファイルを追加するには、次のいずれかの操作を行います。
+ Amazon RDS プロシージャ `rdsadmin.rdsadmin_util.add_inst_store_tempfile` を使用します。RDS for Oracle は、リードレプリカのインスタンスストアに一時ファイルを作成し、指定された一時テーブルスペースに追加します。
+ `ALTER TABLESPACE … ADD TEMPFILE` コマンドを実行します。RDS for Oracle は一時ファイルを Amazon EBS ストレージに配置します。
**注記**
一時ファイルのサイズとストレージタイプは、プライマリ DB インスタンスとリードレプリカで異なる場合があります。
+ デフォルトの一時テーブルスペース設定は、プライマリ DB インスタンスでのみ管理できます。RDS for Oracle は、すべてのリードレプリカに設定を複製します。
+ 一時テーブルスペースグループはプライマリ DB インスタンスでのみ設定できます。RDS for Oracle は、すべてのリードレプリカに設定を複製します。
# インスタンスストアと Amazon EBS の一時テーブルスペースグループの設定
インスタンスストアと Amazon EBS の両方の一時テーブルスペースを含むように一時テーブルスペースグループを設定できます。この方法は、`rds.instance_store_temp_size` の最大設定で許容される容量を超える一時ストレージが必要な場合に便利です。
インスタンスストアと Amazon EBS の両方で一時テーブルスペースグループを設定すると、2 つのテーブルスペースのパフォーマンス特性が大きく異なります。Oracle Database は、内部アルゴリズムに基づいてクエリを処理するテーブルスペースを選択します。そのため、同様のクエリではパフォーマンスが異なる場合があります。
通常、次のようにインスタンスストアに一時テーブルスペースを作成します。
1. インスタンスストアに一時テーブルスペースを作成します。
1. 新しいテーブルスペースをデータベースのデフォルトの一時テーブルスペースとして設定します。
インスタンスストアのテーブルスペースサイズが不十分な場合は、次のように追加の一時ストレージを作成できます。
1. インスタンスストアの一時テーブルスペースを一時テーブルスペースグループに割り当てます。
1. Amazon EBS に新しい一時テーブルスペースがない場合は、作成してください。
1. Amazon EBS の一時テーブルスペースを、インスタンスストアテーブルスペースを含む同じテーブルスペースグループに割り当てます。
1. テーブルスペースグループをデフォルトの一時テーブルスペースとして設定します。
次の例では、インスタンスストア内の一時テーブルスペースのサイズがアプリケーションの要件を満たしていないことを前提としています。この例では、インスタンスストアに一時テーブルスペース `temp_in_inst_store` を作成し、それをテーブルスペースグループ `temp_group` に割り当て、このグループに `temp_in_ebs` という名前の既存の Amazon EBS テーブルスペースを追加し、このグループをデフォルトの一時テーブルスペースとして設定します。
```
SQL> EXEC rdsadmin.rdsadmin_util.create_inst_store_tmp_tblspace('temp_in_inst_store');
PL/SQL procedure successfully completed.
SQL> ALTER TABLESPACE temp_in_inst_store TABLESPACE GROUP temp_group;
Tablespace altered.
SQL> ALTER TABLESPACE temp_in_ebs TABLESPACE GROUP temp_group;
Tablespace altered.
SQL> EXEC rdsadmin.rdsadmin_util.alter_default_temp_tablespace('temp_group');
PL/SQL procedure successfully completed.
SQL> SELECT * FROM DBA_TABLESPACE_GROUPS;
GROUP_NAME TABLESPACE_NAME
------------------------------ ------------------------------
TEMP_GROUP TEMP_IN_EBS
TEMP_GROUP TEMP_IN_INST_STORE
SQL> SELECT PROPERTY_VALUE FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME='DEFAULT_TEMP_TABLESPACE';
PROPERTY_VALUE
--------------
TEMP_GROUP
```
## RDS for Oracle インスタンスストアの削除
インスタンスストアを削除するには、インスタンスストアをサポートしないインスタンスタイプ (db.m5 または db.r5 ) を使用するように RDS for Oracle DB インスタンスを変更します。
# サポートされている RDS for Oracle インスタンスで HugePages をオンにする
Amazon RDS for Oracle は、データベースのスケーラビリティを増大する Linux Kernel の HugePages をサポートしています。HugePages により、ページのテーブルを小さくし、メモリ管理の CPU 経過時間を減少することで、大規模なデータベースインスタンスのパフォーマンスを向上できます。詳細については、Oracle ドキュメントの「[HugePages の概要](https://docs.oracle.com/database/121/UNXAR/appi_vlm.htm#UNXAR400)」を参照してください。
HugePages は、RDS for Oracle の次のバージョンとエディションで使用できます。
`use_large_pages` パラメータは、DB インスタンスで HugePages を有効にするかどうかを制御します。このパラメータに設定できる値は、`ONLY`、`FALSE`、および `{DBInstanceClassHugePagesDefault}` です。Oracle のデフォルト DB パラメータグループでは、`use_large_pages` パラメータが `{DBInstanceClassHugePagesDefault}` に設定されます。
DB インスタンスで HugePages を自動的に有効にするかどうかを制御するには、`DBInstanceClassHugePagesDefault` 式の可変をパラメータグループで使用します。値は次のように決定されます。
+ 以下の表に示す DB インスタンスクラスの場合、`DBInstanceClassHugePagesDefault` はデフォルトで常に `FALSE` と評価されます。`use_large_pages` は `FALSE` と評価されます。DB インスタンスクラスのメモリが 14 GiB 以上であれば、これらの DB インスタンスクラス用に HugePages を手動で有効化できます。
+ 以下の表に示していない DB インスタンスクラスで、DB インスタンスクラスのメモリが 14 GiB 未満の場合は、`DBInstanceClassHugePagesDefault` は常に `FALSE` と評価されます。また、`use_large_pages` は `FALSE` と評価されます。
+ 以下の表に示していない DB インスタンスクラスで、インスタンスクラスのメモリが 14 GiB 以上、100 GiB 未満の場合は、`DBInstanceClassHugePagesDefault` はデフォルトで `TRUE` と評価されます。また、`use_large_pages` は `ONLY` と評価されます。HugePages を手動で無効にするには、`use_large_pages` を `FALSE` に設定します。
+ 次の表に示していない DB インスタンスクラスで、インスタンスクラスのメモリが 100 GiB 以上の場合は、`DBInstanceClassHugePagesDefault` は常に `TRUE` と評価されます。また、`use_large_pages` は `ONLY` と評価され、HugePages を無効にすることはできません。
HugePages は、以下の DB インスタンスクラスに対してはデフォルトで有効になりません。
****
| DB インスタンスクラスファミリー | HugePages がデフォルトで有効になっていない DB インスタンスクラス |
| --- | --- |
| db.m5 | db.m5.large |
| db.m4 | db.m4.large、db.m4.xlarge、db.m4.2xlarge、db.m4.4xlarge、db.m4.10xlarge |
| db.t3 | db.t3.micro、db.t3.small、db.t3.medium、db.t3.large |
DB インスタンスクラスの詳細については、「[ DB インスタンスクラスのハードウェア仕様](Concepts.DBInstanceClass.Summary.md)」を参照してください。
新規または既存の DB インスタンスで HugePages を手動で有効にするには、`use_large_pages` パラメータを `ONLY` に設定します。Oracle 自動メモリ管理 (AMM) では HugePages を使用できません。`use_large_pages` パラメータを `ONLY` に設定するには、`memory_target` と `memory_max_target` の両方を `0` に設定する必要もあります。DB インスタンスの DB パラメータを設定する詳細については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
`sga_target`、`sga_max_size` と `pga_aggregate_target` パラメータも設定できます。システムグローバルエリア (SGA) とプログラムグローバルエリア (PGA) のメモリパラメータを設定する場合には、値をまとめて追加します。この合計を使用可能なインスタンスメモリ (`DBInstanceClassMemory`) から減算して、HugePages の割当量を超える空きメモリを判断します。使用可能なインスタンスメモリ全体の少なくとも 10% または 2 GiB のどちらか少ない方を空きメモリとして残す必要があります。
パラメータを設定したら、DB インスタンスを再起動して変更を有効にする必要があります。詳細については、「[ DB インスタンスの再起動](USER_RebootInstance.md)」を参照してください。
**注記**
Oracle DB インスタンスは、フェイルオーバーなしでインスタンスが再起動されるまで、SGA 関連の初期化パラメータへの変更が延期されます。Amazon RDS コンソールで [**Reboot (再起動)**] を選択しますが、[*Reboot with failover (フェイルオーバーありで再起動)*] を選択**しない**でください。AWS CLI で、`reboot-db-instance` パラメータを指定して `--no-force-failover` コマンドを呼び出します。DB インスタンスは、フェイルオーバー中、またはインスタンスを再起動させる他のメンテナンスオペレーション中に、SGA 関連のパラメータを処理しません。
HugePages を手動で有効化する場合の HugePages のパラメータ設定の例を次に示します。必要に応じて値を設定してください。
```
1. memory_target = 0
2. memory_max_target = 0
3. pga_aggregate_target = {DBInstanceClassMemory*1/8}
4. sga_target = {DBInstanceClassMemory*3/4}
5. sga_max_size = {DBInstanceClassMemory*3/4}
6. use_large_pages = ONLY
```
パラメータグループに以下のパラメータ値を設定したとします。
```
1. memory_target = IF({DBInstanceClassHugePagesDefault}, 0, {DBInstanceClassMemory*3/4})
2. memory_max_target = IF({DBInstanceClassHugePagesDefault}, 0, {DBInstanceClassMemory*3/4})
3. pga_aggregate_target = IF({DBInstanceClassHugePagesDefault}, {DBInstanceClassMemory*1/8}, 0)
4. sga_target = IF({DBInstanceClassHugePagesDefault}, {DBInstanceClassMemory*3/4}, 0)
5. sga_max_size = IF({DBInstanceClassHugePagesDefault}, {DBInstanceClassMemory*3/4}, 0)
6. use_large_pages = {DBInstanceClassHugePagesDefault}
```
パラメータグループは、100 GiB 未満のメモリを持つ db.r4 DB インスタンスクラスによって使用されます。これらのパラメータ設定と `use_large_pages` を `{DBInstanceClassHugePagesDefault}` に設定した場合、HugePages は db.r4 インスタンスで有効になります。
別の例として、パラメータグループに以下のパラメータ値を設定した場合を考えます。
```
1. memory_target = IF({DBInstanceClassHugePagesDefault}, 0, {DBInstanceClassMemory*3/4})
2. memory_max_target = IF({DBInstanceClassHugePagesDefault}, 0, {DBInstanceClassMemory*3/4})
3. pga_aggregate_target = IF({DBInstanceClassHugePagesDefault}, {DBInstanceClassMemory*1/8}, 0)
4. sga_target = IF({DBInstanceClassHugePagesDefault}, {DBInstanceClassMemory*3/4}, 0)
5. sga_max_size = IF({DBInstanceClassHugePagesDefault}, {DBInstanceClassMemory*3/4}, 0)
6. use_large_pages = FALSE
```
パラメータグループは、メモリが 100 GiB 未満の DB インスタンスクラス db.r4 と db.r5 インスタンスの両方で使用されます。これらのパラメータ設定では、db.r4 および db.r5 インスタンスで HugePages が無効になります。
**注記**
このパラメータグループをメモリが 100 GiB 以上の db.r4 DB インスタンスクラス、または db.r5 DB インスタンスクラスで使用すると、`FALSE` の `use_large_pages` 設定はオーバーライドされ、`ONLY` に設定されます。この場合、オーバーライドに関する通知がユーザーに送信されます。
DB インスタンスで HugePages が有効になると、拡張モニタリングを有効にして HugePages の情報を表示できます。詳細については、「[拡張モニタリングを使用した OS メトリクスのモニタリング](USER_Monitoring.OS.md)」を参照してください。
# RDS for Oracle で拡張データ型を有効にする
Amazon RDS for Oracle は、拡張データ型をサポートします。拡張データ型では、`VARCHAR2`、`NVARCHAR2`、および `RAW` データ型の最大サイズは 32,767 バイトです。拡張データ型を使用する場合、`MAX_STRING_SIZE` パラメータを `EXTENDED` に設定します。詳細については、Oracle ドキュメントの「[拡張データ型](https://docs.oracle.com/database/121/SQLRF/sql_elements001.htm#SQLRF55623)」を参照してください。
拡張データ型を使用しない場合は、`MAX_STRING_SIZE` パラメータを `STANDARD` (デフォルト) のままにします。この場合、サイズ制限は、`VARCHAR2` および `NVARCHAR2` データ型で 4,000 バイト、RAW データ型で 2,000 バイトです。
新しい DB インスタンス、または既存の DB インスタンスで拡張データ型を有効にできます。新しい DB インスタンスの場合、拡張データ型を有効にすると、通常、DB インスタンスの作成時間が長くなります。既存の DB インスタンスでは、変換プロセス中は DB インスタンスは無効です。
## 拡張データ型に関する考慮事項
DB インスタンスの拡張データ型を有効にするときには、次の点を考慮してください。
+ 新規または既存の DB インスタンスの拡張データ型を有効にする場合は、変更を有効にするためにインスタンスを再起動する必要があります。
+ 拡張データ型を有効にすると、DB インスタンスでデータ型の標準サイズを使用するように戻すことはできません。`MAX_STRING_SIZE` パラメータを `STANDARD` に戻すと、`incompatible-parameters` ステータスになります。
+ 拡張データ型を使用する DB インスタンスを復元する場合、`MAX_STRING_SIZE` パラメータを `EXTENDED` に設定して、パラメータグループを設定する必要があります。復元中は、デフォルトのパラメータグループ、または、他のパラメータグループの `MAX_STRING_SIZE` を `STANDARD` に設定すると、`incompatible-parameters` ステータスになります。
+ DB インスタンスステータスが `incompatible-parameters` の設定のために `MAX_STRING_SIZE` の場合、`MAX_STRING_SIZE` パラメータを `EXTENDED` に設定して DB インスタンスを再起動するまで、DB インスタンスは使用できません。
## 新しい DB インスタンスで拡張データ型を有効にする
`MAX_STRING_SIZE` を `EXTENDED` に設定して DB インスタンスを作成すると、インスタンスの `MAX_STRING_SIZE` はデフォルトの `STANDARD` に設定されます。インスタンスを再起動して、変更を有効にします。
**新しい DB インスタンスで拡張データ型を有効にするには**
1. パラメータグループ内の `MAX_STRING_SIZE` パラメータを `EXTENDED` に設定する。
新しいパラメータグループを作成するか、既存のパラメータグループを変更して、パラメータを設定できます。
詳細については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
1. 新しい RDS for Oracle DB インスタンスを作成します。
詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
1. パラメータグループを、DB インスタンスで `EXTENDED` に設定された `MAX_STRING_SIZE` に関連付けます。
詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
1. DB インスタンスを再起動してパラメータの変更を有効にします。
詳細については、「[ DB インスタンスの再起動](USER_RebootInstance.md)」を参照してください。
## 既存の DB インスタンスで拡張データ型を有効にするには
DB インスタンスを変更して拡張データ型を有効にすると、RDS は、拡張サイズを使用するようにデータベース内のデータを変換します。変換とダウンタイムは、パラメータの変更後にデータベースを次に再起動したときに発生します。DB インスタンスは変換中は利用できません。
データの変換に要する時間は、DB インスタンスクラス、データベースのサイズ、および前回の DB スナップショットの時刻によって異なります。ダウンタイムを減らすには、再起動の直前にスナップショットを取ることを検討してください。これにより、変換ワークフロー中に行われるバックアップの時間が短縮されます。
**注記**
拡張データ型を有効にすると、変換中はポイントインタイムの復元を実行できません。変換の直前または変換後の時間に復元することができます。
**既存の DB インスタンスで拡張データ型を有効にするには**
1. データベースのスナップショットを作成します。
データベースに無効なオブジェクトがある場合、Amazon RDS はそれらの再コンパイルを試みます。Amazon RDS が無効なオブジェクトを再コンパイルできない場合、拡張データ型への変換は失敗する可能性があります。スナップショットを使用すると、変換に問題がある場合にデータベースを復元できます。変換前に無効なオブジェクトがないかを常に確認して、無効なオブジェクトを修正または削除してください。本番データベースの場合は、初期に DB インスタンスのコピーで変換プロセスをテストすることをお勧めします。
詳細については、「[Amazon RDS のシングル AZ DB インスタンスの DB スナップショットの作成](USER_CreateSnapshot.md)」を参照してください。
1. パラメータグループ内の `MAX_STRING_SIZE` パラメータを `EXTENDED` に設定する。
新しいパラメータグループを作成するか、既存のパラメータグループを変更して、パラメータを設定できます。
詳細については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
1. DB インスタンスを修正して `MAX_STRING_SIZE` を `EXTENDED` に設定したパラメータグループと関連付けます。
詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
1. DB インスタンスを再起動してパラメータの変更を有効にします。
詳細については、「[ DB インスタンスの再起動](USER_RebootInstance.md)」を参照してください。
# Amazon RDS の Oracle にデータをインポートする
Amazon RDS for Oracle DB インスタンスにデータをインポートする方法は、次の条件によって異なります。
+ 保有しているデータの量
+ データベース内のデータベースオブジェクトの数
+ データベース内のさまざまなデータベースオブジェクト
例えば、要件に応じて、次のツールを使用できます。
+ Oracle SQL Developer — シンプルな 20 MB のデータベースを 1 つインポートできます。
+ Oracle Data Pump – 複雑なデータベースや、サイズが数百メガバイトまたは数テラバイトのデータベースをインポートできます。例えば、オンプレミスのデータベースから RDS for Oracle DB インスタンスにテーブルスペースを転送できます。Amazon S3 または Amazon EFS を使用して、データファイルとメタデータを転送できます。詳細については、[Oracle トランスポータブル表領域を使用した移行](oracle-migrating-tts.md)、[Amazon EFS の統合](oracle-efs-integration.md)、および[「Amazon S3 統合」](oracle-s3-integration.md)を参照してください。
+ AWS Database Migration Service (AWS DMS) — ダウンタイムなしでデータベースを移行できます。AWS DMS の詳細については、「[AWS Database Migration Service とは](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html)」およびブログ記事「[AWS DMS を使用してほぼゼロのダウンタイムで Oracle データベースを移行する](https://aws.amazon.com/blogs/database/migrating-oracle-databases-with-near-zero-downtime-using-aws-dms/)」参照してください。
**重要**
前述の移行方法のいずれかを使用する前に、データベースをバックアップすることをお勧めします。データのインポート後に、スナップショットを作成して RDS for Oracle DB インスタンスをバックアップできます。後で、スナップショットを復元できます。詳細については、「[データのバックアップ、復元、エクスポート](CHAP_CommonTasks.BackupRestore.md)」を参照してください。
多くのデータベースエンジンでは、ターゲットデータベースに切り替える準備ができるまで、進行中のレプリケーションを続行できます。AWS DMS を使用して、同じデータベースエンジンまたは異なるエンジンから RDS for Oracle に移行できます。別のデータベースエンジンから移行する場合は、AWS Schema Conversion Tool を使用します。これにより、AWS DMS では移行できないスキーマオブジェクトを移行できます。
**Topics**
+ [Oracle SQL Developer を使用したインポート](Oracle.Procedural.Importing.SQLDeveloper.md)
+ [Oracle トランスポータブル表領域を使用した移行](oracle-migrating-tts.md)
+ [Oracle Data Pump を使用したインポート](Oracle.Procedural.Importing.DataPump.md)
+ [Oracle エクスポート/インポートを使用したインポート](Oracle.Procedural.Importing.ExportImport.md)
+ [Oracle SQL\$1Loader を使用したインポート](Oracle.Procedural.Importing.SQLLoader.md)
+ [Oracle マテリアライズドビューを使用した移行](Oracle.Procedural.Importing.Materialized.md)
# Oracle SQL Developer を使用したインポート
Oracle SQL Developer は、Oracle によって無償で配布されるグラフィカルな Java ツールです。SQL Developer には、2 つの Oracle データベース間でデータを移行したり、MySQL などの他のデータベースから Oracle データベースへデータを移行したりするためのオプションが用意されています。このツールは、小規模なデータベースの移行に最適です。
このツールは、デスクトップコンピュータ (Windows、Linux、Mac) またはいずれか 1 つのサーバーにインストールできます。SQL Developer をインストールすると、SQL Developer を使用して移行元のデータベースと移行先のデータベースに接続できます。[Tools] メニューの **[Database Copy]** コマンドを使用して、Amazon RDS インスタンスにデータをコピーします。
SQL Developer をダウンロードするには、[ http://www.oracle.com/technetwork/developer-tools/sql-developer](http://www.oracle.com/technetwork/developer-tools/sql-developer) にアクセスしてください。
データの移行を開始する前に、Oracle SQL Developer 製品のドキュメントを読むことをお勧めします。Oracle には、MySQL や SQL Server などの他のデータベースから移行する方法に関するドキュメントも用意されています。詳細については、Oracle のドキュメントの [http://www.oracle.com/technetwork/database/migration](http://www.oracle.com/technetwork/database/migration) を参照してください。
# Oracle トランスポータブル表領域を使用した移行
Oracle トランスポータブル表領域機能を使用して、オンプレミスの Oracle データベースから RDS for Oracle DB インスタンスにテーブルスペースのセットをコピーできます。物理レベルでは、Amazon EFS または Amazon S3 を使用して、ソースデータファイルとメタデータファイルをターゲット DB インスタンスに転送します。トランスポータブルテーブルスペース機能は `rdsadmin.rdsadmin_transport_util` パッケージを使用します。このプロシージャの構文とセマンティクスについては、「[テーブルスペースの転送](rdsadmin_transport_util.md)」を参照してください。
表領域をトランスポートする方法を説明したブログ記事については、「[Migrate Oracle Databases to AWS using transportable tablespace](https://aws.amazon.com/blogs/database/migrate-oracle-databases-to-aws-using-transportable-tablespace/)」と「[Amazon RDS for Oracle Transportable Tablespaces using RMAN](https://aws.amazon.com/blogs/database/amazon-rds-for-oracle-transportable-tablespaces-using-rman/)」を参照してください。
**Topics**
+ [Oracle トランスポータブル表領域の概要](#oracle-migrating-tts.overview)
+ [フェーズ 1: ソースホストをセットアップする](#oracle-migrating-tts.setup-phase)
+ [フェーズ 2: 表領域のフルバックアップを準備する](#oracle-migrating-tts.initial-br-phase)
+ [フェーズ 3: 増分バックアップを作成および転送する](#oracle-migrating-tts.roll-forward-phase)
+ [フェーズ 4: 表領域をトランスポートする](#oracle-migrating-tts.final-br-phase)
+ [フェーズ 5: 転送された表領域を検証する](#oracle-migrating-tts.validate)
+ [フェーズ 6: 残ったファイルをクリーンアップする](#oracle-migrating-tts.cleanup)
## Oracle トランスポータブル表領域の概要
トランスポータブル表領域セットは、トランスポートされる表領域セットのデータファイルと、表領域メタデータを含むエクスポートダンプファイルで構成されます。トランスポータブル表領域などの物理的な移行ソリューションでは、物理ファイル (データファイル、構成ファイル、Data Pump ダンプファイル) を転送します。
**Topics**
+ [トランスポータブル表領域のメリットとデメリット](#oracle-migrating-tts.overview.benefits)
+ [トランスポータブル表領域の制限事項](#oracle-migrating-tts.limitations)
+ [トランスポータブル表領域の前提条件](#oracle-migrating-tts.requirements)
### トランスポータブル表領域のメリットとデメリット
ダウンタイムを最小限に抑えて 1 つ以上の大きな表領域を RDS に移行する必要がある場合は、トランスポータブル表領域を使用することをお勧めします。トランスポータブル表領域には、論理移行に比べて次のような利点があります。
+ ダウンタイムは他のほとんどの Oracle 移行ソリューションよりも短いです。
+ トランスポータブル表領域機能は物理ファイルのみをコピーするため、論理移行で発生する可能性のあるデータ整合性エラーや論理的な破損を回避できます。
+ 追加のライセンスは必要ありません。
+ 例えば、Oracle Solaris プラットフォームから Linux など、さまざまなプラットフォームやエンディアンネスタイプにわたって表領域のセットを移行できます。ただし、Windows サーバーとの間で表領域を転送したり、Windows サーバーから転送することはサポートされていません。
**注記**
Linux は完全にテスト済みでサポートされています。すべての UNIX バリエーションでテストされているわけではありません。
トランスポータブル表領域を使用する場合は、Amazon S3 または Amazon EFS を使用してデータを転送できます。
+ EFS を使用する場合、バックアップはインポート中も EFS ファイルシステムに残ります。ファイルは後で削除できます。この手法では、DB インスタンスに EBS ストレージをプロビジョニングする必要はありません。このため、S3 ではなく Amazon EFS を使用することをお勧めします。詳細については、「[Amazon EFS の統合](oracle-efs-integration.md)」を参照してください。
+ S3 を使用する場合、DB インスタンスに接続された EBS ストレージに RMAN バックアップをダウンロードします。インポート中、ファイルは EBS ストレージに残ります。インポート後にこのスペースを解放できます。このスペースは DB インスタンスに割り当てられたままです。
トランスポータブル表領域の主な欠点は、Oracle Database に関する比較的高度な知識が必要なことです。詳細は、*Oracle Database 管理者ガイド*の「[データベース間での表領域のトランスポート](https://docs.oracle.com/en/database/oracle/oracle-database/19/admin/transporting-data.html#GUID-F7B2B591-AA88-4D16-8DCF-712763923FFB)」を参照してください。
### トランスポータブル表領域の制限事項
RDS for Oracle でこの機能を使用する場合、Oracle データベースのトランスポータブル表領域の制限が適用されます。詳細は、*Oracle Database 管理者ガイド*の「[トランスポータブル表領域の制限]( https://docs.oracle.com/en/database/oracle/oracle-database/19/admin/transporting-data.html#GUID-DAB51E42-9BBC-4001-B5CB-0ECDBE128787)」および「[データのトランスポートに関する一般的な制限](https://docs.oracle.com/en/database/oracle/oracle-database/19/admin/transporting-data.html#GUID-28800719-6CB9-4A71-95DD-4B61AA603173)」を参照してください。RDS for Oracle のトランスポータブル表領域には、さらに次の制限があることに注意してください。
+ ソースデータベースとターゲットデータベースのどちらも Standard Edition 2 (SE2) を使用できません。Enterprise Edition のみがサポートされています。
+ Oracle Database 11g データベースをソースとして使用することはできません。RMAN クロスプラットフォームトランスポータブルテーブルスペース機能は、Oracle Database 11g がサポートしていない RMAN トランスポートメカニズムに依存しています。
+ トランスポータブル表領域を使用して RDS for Oracle DB インスタンスからデータを移行することはできません。トランスポータブル表領域は、データを RDS for Oracle DB インスタンスに移行するときのみに使用できます。
+ Windows オペレーティングシステムはサポートされていません。
+ 表領域を下位リリースレベルのデータベースにトランスポートすることはできません。ターゲットデータベースは、ソースデータベースと同じかそれ以降のリリースレベルでなければいけません。例えば、表領域を Oracle Database 21c から Oracle Database 19c にトランスポートすることはできません。
+ `SYSTEM` および `SYSAUX` などの管理上の表領域はトランスポートできません。
+ PL/SQL パッケージ、Java クラス、ビュー、トリガー、シーケンス、ユーザー、ロール、一時テーブルなどの非データオブジェクトは転送できません。データ以外のオブジェクトを転送するには、手動で作成するか、Data Pump メタデータのエクスポートとインポートを使用します。詳細については、「[Oracle サポートノート 1454872.1](https://support.oracle.com/knowledge/Oracle%20Cloud/1454872_1.html)」を参照してください。
+ 暗号化された表領域や暗号化された列を使用する表領域はトランスポートできません。
+ Amazon S3 を使用してファイルを転送する場合、サポートされる最大ファイルサイズは 5 TiB です。
+ ソースデータベースが Spatial などの Oracle オプションを使用している場合は、ターゲットデータベースで同じオプションが設定されていない限り、表領域をトランスポートできません。
+ Oracle レプリカ構成の RDS for Oracle DB インスタンスに表領域をトランスポートできません。回避策としては、すべてのレプリカを削除し、表領域をトランスポートしてから、レプリカを再作成できます。
### トランスポータブル表領域の前提条件
開始する前に、以下のタスクを完了します。
+ My Oracle Support の次のドキュメントに記載されているトランスポータブル表領域の要件を確認してください。
+ [クロスプラットフォーム増分バックアップを使用したトランスポータブル表領域のダウンタイムの短縮 (Doc ID 2471245.1)](https://support.oracle.com/epmos/faces/DocumentDisplay?id=2471245.1)
+ [トランスポータブル表領域 (TTS) 制限事項 : 詳細、リファレンス、適用バージョン (Doc ID 1454872.1)](https://support.oracle.com/epmos/faces/DocumentDisplay?id=1454872.1)
+ [トランスポータブル表領域（TTS）に関する主な注意事項 -- よくある質問と問題 (Doc ID 1166564.1)](https://support.oracle.com/epmos/faces/DocumentDisplay?id=1166564.1)
+ エンディアンネス変換の計画 ソースプラットフォーム ID を指定すると、RDS for Oracle はエンディアンネスを自動的に変換します。プラットフォーム ID の確認方法については、「[同一 Data Guard 構成の異機種間プライマリおよびフィジカルスタンバイに関する Data Guard のサポート(Doc ID 413484.1)](https://support.oracle.com/epmos/faces/DocumentDisplay?id=413484.1)」を参照してください。
+ ターゲット DB インスタンスでトランスポータブル表領域機能が有効になっていることを確認してください。この機能は、次のクエリを実行しても `ORA-20304` エラーが表示されない場合にのみ有効になります。
```
SELECT * FROM TABLE(rdsadmin.rdsadmin_transport_util.list_xtts_orphan_files);
```
トランスポータブル表領域機能が有効になっていない場合は、DB インスタンスを再起動します。詳細については、「[ DB インスタンスの再起動](USER_RebootInstance.md)」を参照してください。
+ タイムゾーンファイルがソースとターゲットのデータベース間で同じであることを確認します。
+ ソースとターゲットのデータベースの文字セットが、次のいずれかの要件を満たしていることを確認します。
+ 文字セットは同じです。
+ 文字セットに互換性があります。互換性要件のリストについては、Oracle データベースドキュメントの「[General Limitations on Transporting Data](https://docs.oracle.com/en/database/oracle/oracle-database/19/spmdu/general-limitations-on-transporting-data.html#GUID-28800719-6CB9-4A71-95DD-4B61AA603173)」を参照してください。
+ Amazon S3 を使用してファイルを転送する予定がある場合は、以下を実行してください。
+ Amazon S3 バケットをファイル転送に使用でき、この Amazon S3 バケットが、DB インスタンスと同じ AWS リージョン内にあることを確認します。手順については、*Amazon Simple Storage Service 入門ガイド*の「[バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html)」を参照してください。
+ Amazon RDS 統合用の Amazon S3 バケットは、「[Amazon S3 と RDS for Oracle を統合する IAM アクセス許可の設定](oracle-s3-integration.preparing.md)」の手順に従って準備してください。
+ Amazon EFS を使用してファイルを転送する場合は、[Amazon EFS の統合](oracle-efs-integration.md) の手順に従って EFS を設定したことを確認してください。
+ ターゲット DB インスタンスで自動バックアップを有効にすることを強くお勧めします。[メタデータのインポートステップ](#oracle-migrating-tts.transport.import-dmp)は失敗する可能性があるため、DB インスタンスをインポート前の状態に復元できることが重要です。それによって、表領域を再度バックアップ、転送、インポートする必要がなくなります。
## フェーズ 1: ソースホストをセットアップする
このステップでは、My Oracle Support から提供されているトランスポート表領域スクリプトをコピーし、必要な構成ファイルを設定します。次のステップでは、*ソースホスト*は、*ターゲットインスタンス*にトランスポートされる表領域を含むデータベースを実行しています。
**ソースホストを設定するには**
1. Oracle ホームのオーナーとしてソースホストにログインします。
1. `ORACLE_HOME` および `ORACLE_SID` 環境変数がソースデータベースを指していることを確認してください。
1. 管理者としてデータベースにログインし、タイムゾーンバージョン、DB 文字セット、および各国語文字セットがターゲットデータベースと同じであることを確認します。
```
SELECT * FROM V$TIMEZONE_FILE;
SELECT * FROM NLS_DATABASE_PARAMETERS
WHERE PARAMETER IN ('NLS_CHARACTERSET','NLS_NCHAR_CHARACTERSET');
```
1. [Oracle Support ノート 2471245.1](https://support.oracle.com/epmos/faces/DocumentDisplay?id=2471245.1) の説明に従って、トランスポータブル表領域ユーティリティを設定します。
セットアップには、ソースホスト上の `xtt.properties` ファイルの編集が含まれます。次のサンプル `xtt.properties` ファイルは、`/dsk1/backups` ディレクトリ内の 3 つの表領域のバックアップを指定しています。これらは、ターゲット DB インスタンスにトランスポートする予定の表領域です。また、エンディアンネスを自動的に変換するソースプラットフォーム ID も指定します。
**注記**
有効なプラットフォーム ID については、「[同一 Data Guard 構成の異機種間プライマリおよびフィジカルスタンバイに関する Data Guard のサポート(Doc ID 413484.1)](https://support.oracle.com/epmos/faces/DocumentDisplay?id=413484.1)」を参照してください。
```
#linux system
platformid=13
#list of tablespaces to transport
tablespaces=TBS1,TBS2,TBS3
#location where backup will be generated
src_scratch_location=/dsk1/backups
#RMAN command for performing backup
usermantransport=1
```
## フェーズ 2: 表領域のフルバックアップを準備する
このフェーズでは、初めて表領域をバックアップし、そのバックアップをターゲットホストに転送してから、プロシージャ `rdsadmin.rdsadmin_transport_util.import_xtts_tablespaces` を使用して表領域を復元します。このフェーズが完了すると、最初の表領域バックアップはターゲット DB インスタンスに保存され、増分バックアップで更新できます。
**Topics**
+ [ステップ 1: ソースホストの表領域をバックアップする](#oracle-migrating-tts.backup-full)
+ [ステップ 2: バックアップファイルをターゲット DB インスタンスに転送する](#oracle-migrating-tts.transfer-full)
+ [ステップ 3: ターゲット DB インスタンスに表領域をインポートする](#oracle-migrating-tts.initial-tts-import)
### ステップ 1: ソースホストの表領域をバックアップする
このステップでは、`xttdriver.pl` スクリプトを使用して表領域のフルバックアップを作成します。`xttdriver.pl` の出力は、`TMPDIR` 環境変数に格納されます。
**表領域をバックアップするには**
1. 表領域が読み取り専用モードの場合は、`ALTER TABLESPACE` 権限を持つユーザーとしてソースデータベースにログインし、表領域を読み取り/書き込みモードにします。それ以外の場合は、次のステップに進みます。
次の例では`tbs1`、`tbs2`、`tbs3` を読み取り/書き込みモードにします。
```
ALTER TABLESPACE tbs1 READ WRITE;
ALTER TABLESPACE tbs2 READ WRITE;
ALTER TABLESPACE tbs3 READ WRITE;
```
1. `xttdriver.pl` スクリプトを使用して表領域をバックアップします。オプションで、`--debug` を指定してデバッグモードでスクリプトを実行できます。
```
export TMPDIR=location_of_log_files
cd location_of_xttdriver.pl
$ORACLE_HOME/perl/bin/perl xttdriver.pl --backup
```
### ステップ 2: バックアップファイルをターゲット DB インスタンスに転送する
このステップでは、バックアップファイルと設定ファイルをスクラッチの場所からターゲット DB インスタンスにコピーします。以下のオプションのいずれかを選択してください。
+ ソースホストとターゲットホストが Amazon EFS ファイルシステムを共有する場合は、`cp` などのオペレーティングシステムユーティリティを使用して、バックアップファイルと `res.txt` ファイルをスクラッチの場所から共有ディレクトリにコピーします。その後、[ステップ 3: ターゲット DB インスタンスに表領域をインポートする](#oracle-migrating-tts.initial-tts-import)に進みます。
+ バックアップを Amazon S3 バケットにステージングする必要がある場合は、以下の手順を実行してください。
![\[Amazon S3 または Amazon EFS を使用してファイルを転送します。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/oracle-tts.png)
#### ステップ 2.2: Amazon S3 バケットにダンプファイルをアップロードする
バックアップと `res.txt` ファイルをスクラッチディレクトリから Amazon S3 バケットにアップロードします。詳細については、*Amazon Simple Storage Service 開発者ガイド*の「[オブジェクトのアップロード](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html)」を参照してください。
#### ステップ 2.3: バックアップを Amazon S3 バケットからターゲット DB インスタンスにダウンロードする
このステップでは、プロシージャ `rdsadmin.rdsadmin_s3_tasks.download_from_s3` を使用して RDS for Oracle DB インスタンスにバックアップをダウンロードします。
**Amazon S3 バケットからバックアップをダウンロードするには**
1. SQL\$1Plus または Oracle SQL Developer を起動し、RDS for Oracle DB インスタンスにログインします。
1. Amazon RDS プロシージャ `rdsadmin.rdsadmin_s3_tasks.download_from_s3` を使用して、Amazon S3 バケットからターゲット DB インスタンスにバックアップをダウンロードします。次の例では、`amzn-s3-demo-bucket` という名前の Amazon S3 バケットから `DATA_PUMP_DIR` ディレクトリにファイルをすべてダウンロードします。
```
EXEC UTL_FILE.FREMOVE ('DATA_PUMP_DIR', 'res.txt');
SELECT rdsadmin.rdsadmin_s3_tasks.download_from_s3(
p_bucket_name => 'amzn-s3-demo-bucket',
p_directory_name => 'DATA_PUMP_DIR')
AS TASK_ID FROM DUAL;
```
`SELECT` ステートメントでは、データ型 `VARCHAR2` のタスクの ID が返ります。詳細については、「[Amazon S3 バケットから Oracle DB インスタンスにファイルをダウンロードする](oracle-s3-integration.using.md#oracle-s3-integration.using.download)」を参照してください。
### ステップ 3: ターゲット DB インスタンスに表領域をインポートする
プロシージャ `rdsadmin.rdsadmin_transport_util.import_xtts_tablespaces` を使用して、表領域をターゲット DB インスタンスに復元します。このプロシージャは、データファイルを正しいエンディアン形式に自動的に変換します。
Linux 以外のプラットフォームからインポートする場合は、`import_xtts_tablespaces` を呼び出すときに `p_platform_id` パラメータを使用してソースプラットフォームを指定します。指定するプラットフォーム ID が、[ステップ 2: ソースホストに表領域メタデータをエクスポートする](#oracle-migrating-tts.transport.export) の `xtt.properties` ファイルで指定されたものと一致していることを確認してください。
**ターゲット DB インスタンスに表領域をインポートする**
1. Oracle SQL クライアントを起動し、ターゲット RDS for Oracle DB インスタンスにマスターユーザーとしてログインします。
1. インポートする表領域とバックアップを含むディレクトリを指定して、`rdsadmin.rdsadmin_transport_util.import_xtts_tablespaces` プロシージャを実行します。
以下の例では、表領域*TBS1*、*TBS2*、および *TBS3* をディレクトリ *DATA\$1PUMP\$1DIR* からインポートします。ソースプラットフォームは AIX ベースのシステム (64 ビット) で、プラットフォーム ID は `6` です。プラットフォーム ID は、`V$TRANSPORTABLE_PLATFORM` をクエリすることで確認できます。
```
VAR task_id CLOB
BEGIN
:task_id:=rdsadmin.rdsadmin_transport_util.import_xtts_tablespaces(
'TBS1,TBS2,TBS3',
'DATA_PUMP_DIR',
p_platform_id => 6);
END;
/
PRINT task_id
```
1. (オプション) テーブル `rdsadmin.rds_xtts_operation_info` にクエリを実行して進行状況を監視します。`xtts_operation_state` 列には、`EXECUTING`、`COMPLETED`、または `FAILED` という値が表示されます。
```
SELECT * FROM rdsadmin.rds_xtts_operation_info;
```
**注記**
実行時間が長い操作の場合は、`V$SESSION_LONGOPS`、`V$RMAN_STATUS`、`V$RMAN_OUTPUT` にクエリを実行することもできます。
1. 前のステップのタスク ID を使用して、完了したインポートのログを表示します。
```
SELECT * FROM TABLE(rdsadmin.rds_file_util.read_text_file('BDUMP', 'dbtask-'||'&task_id'||'.log'));
```
インポートが正常に完了したことを確認してから、次の手順に進みます。
## フェーズ 3: 増分バックアップを作成および転送する
このフェーズでは、ソースデータベースがアクティブな間、定期的に増分バックアップを作成して転送します。この手法を実行することで、最終的な表領域バックアップのサイズが小さくなります。複数の増分バックアップを行う場合、最後の増分バックアップの後に `res.txt` ファイルをコピーしてから、ターゲットインスタンスに適用する必要があります。
手順は [フェーズ 2: 表領域のフルバックアップを準備する](#oracle-migrating-tts.initial-br-phase) と同じですが、インポートの手順が任意である点が異なります。
## フェーズ 4: 表領域をトランスポートする
このフェーズでは、読み取り専用の表領域をバックアップし、Data Pump メタデータをエクスポートし、これらのファイルをターゲットホストに転送して、表領域とメタデータの両方をインポートします。
**Topics**
+ [ステップ 1: 読み取り専用の表領域をバックアップする](#oracle-migrating-tts.final-backup)
+ [ステップ 2: ソースホストに表領域メタデータをエクスポートする](#oracle-migrating-tts.transport.export)
+ [ステップ 3: (Amazon S3 のみ) バックアップファイルとエクスポートファイルをターゲット DB インスタンスに転送する](#oracle-migrating-tts.transport)
+ [ステップ 4: ターゲット DB インスタンスに表領域をインポートする](#oracle-migrating-tts.restore-full)
+ [ステップ 5: ターゲット DB インスタンスに表領域メタデータをインポートする](#oracle-migrating-tts.transport.import-dmp)
### ステップ 1: 読み取り専用の表領域をバックアップする
このステップは [ステップ 1: ソースホストの表領域をバックアップする](#oracle-migrating-tts.backup-full) と同じですが、重要な違いが 1 つあります。最後に表領域をバックアップする前に、表領域を読み取り専用モードにします。
次の例では、`tbs1`、`tbs2`、`tbs3` を読み取り専用モードにします。
```
ALTER TABLESPACE tbs1 READ ONLY;
ALTER TABLESPACE tbs2 READ ONLY;
ALTER TABLESPACE tbs3 READ ONLY;
```
### ステップ 2: ソースホストに表領域メタデータをエクスポートする
ソースホストで `expdb` ユーティリティを実行して、表領域メタデータをエクスポートします。次の例では、表領域 *TBS1*、*TBS2*、および *TBS3* を *DATA\$1PUMP\$1DIR* ディレクトリのダンプファイル *xttdump.dmp* にエクスポートします。
```
expdp username/pwd \
dumpfile=xttdump.dmp \
directory=DATA_PUMP_DIR \
statistics=NONE \
transport_tablespaces=TBS1,TBS2,TBS3 \
transport_full_check=y \
logfile=tts_export.log
```
*DATA\$1PUMP\$1DIR* が Amazon EFS の共有ディレクトリである場合は、スキップして [ステップ 4: ターゲット DB インスタンスに表領域をインポートする](#oracle-migrating-tts.restore-full) に進んでください。
### ステップ 3: (Amazon S3 のみ) バックアップファイルとエクスポートファイルをターゲット DB インスタンスに転送する
Amazon S3 を使用して表領域バックアップと Data Pump エクスポートファイルをステージングする場合は、次の手順を実行してください。
#### ステップ 3.1: バックアップとダンプファイルをソースホストから Amazon S3 バケットにアップロードする
バックアップとダンプファイルをソースホストから Amazon S3 バケットにアップロードします。詳細については、*Amazon Simple Storage Service 開発者ガイド*の「[オブジェクトのアップロード](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html)」を参照してください。
#### ステップ 3.2: バックアップとダンプファイルを Amazon S3 バケットからターゲット DB インスタンスにダウンロードする
このステップでは、プロシージャ `rdsadmin.rdsadmin_s3_tasks.download_from_s3` を使用して RDS for Oracle DB インスタンスにバックアップとダンプファイルをダウンロードします。「[ステップ 2.3: バックアップを Amazon S3 バケットからターゲット DB インスタンスにダウンロードする](#oracle-migrating-tts.download-full)」のステップを実行してください。
### ステップ 4: ターゲット DB インスタンスに表領域をインポートする
`rdsadmin.rdsadmin_transport_util.import_xtts_tablespaces` プロシージャを使用して表領域を復元します。このプロシージャの構文とセマンティクスについては、「[転送されたテーブルスペースを DB インスタンスにインポートする](rdsadmin_transport_util_import_xtts_tablespaces.md)」を参照してください。
**重要**
最後の表領域のインポートが完了したら、次のステップは [Oracle Data Pump メタデータのインポート](#oracle-migrating-tts.transport.export)です。インポートが失敗した場合、DB インスタンスを失敗前の状態に戻すことが重要です。そのため、[Amazon RDS のシングル AZ DB インスタンスの DB スナップショットの作成](USER_CreateSnapshot.md) の手順に従って DB インスタンスの DB スナップショットを作成することをお勧めします。スナップショットにはインポートされたすべての表領域が含まれるため、インポートが失敗した場合でも、バックアップとインポートのプロセスを繰り返す必要はありません。
ターゲット DB インスタンスで自動バックアップがオンになっていて、メタデータをインポートする前に有効なスナップショットが開始されたことを Amazon RDS が検出しない場合、RDS はスナップショットの作成を試みます。インスタンスのアクティビティに応じて、このスナップショットは成功する場合と成功しない場合があります。有効なスナップショットが検出されないか、スナップショットを開始できない場合、メタデータのインポートはエラーを出して終了します。
**ターゲット DB インスタンスに表領域をインポートする**
1. Oracle SQL クライアントを起動し、ターゲット RDS for Oracle DB インスタンスにマスターユーザーとしてログインします。
1. インポートする表領域とバックアップを含むディレクトリを指定して、`rdsadmin.rdsadmin_transport_util.import_xtts_tablespaces` プロシージャを実行します。
以下の例では、表領域*TBS1*、*TBS2*、および *TBS3* をディレクトリ *DATA\$1PUMP\$1DIR* からインポートします。
```
BEGIN
:task_id:=rdsadmin.rdsadmin_transport_util.import_xtts_tablespaces('TBS1,TBS2,TBS3','DATA_PUMP_DIR');
END;
/
PRINT task_id
```
1. (オプション) テーブル `rdsadmin.rds_xtts_operation_info` にクエリを実行して進行状況を監視します。`xtts_operation_state` 列には、`EXECUTING`、`COMPLETED`、または `FAILED` という値が表示されます。
```
SELECT * FROM rdsadmin.rds_xtts_operation_info;
```
**注記**
実行時間が長い操作の場合は、`V$SESSION_LONGOPS`、`V$RMAN_STATUS`、`V$RMAN_OUTPUT` にクエリを実行することもできます。
1. 前のステップのタスク ID を使用して、完了したインポートのログを表示します。
```
SELECT * FROM TABLE(rdsadmin.rds_file_util.read_text_file('BDUMP', 'dbtask-'||'&task_id'||'.log'));
```
インポートが正常に完了したことを確認してから、次の手順に進みます。
1. [Amazon RDS のシングル AZ DB インスタンスの DB スナップショットの作成](USER_CreateSnapshot.md) の指示に従って DB スナップショットを手動で作成します。
### ステップ 5: ターゲット DB インスタンスに表領域メタデータをインポートする
このステップでは、`rdsadmin.rdsadmin_transport_util.import_xtts_metadata` プロシージャを使用して RDS for Oracle DB インスタンスにトランスポータブル表領域メタデータをインポートします。このプロシージャの構文とセマンティクスについては、「[転送可能テーブルスペースメタデータを DB インスタンスにインポートする](rdsadmin_transport_util_import_xtts_metadata.md)」を参照してください。操作中、インポートのステータスがテーブル `rdsadmin.rds_xtts_operation_info` に表示されます。
**重要**
メタデータをインポートする前に、表領域をインポートした後に DB スナップショットが正常に作成されたことを確認することを強くお勧めします。インポートステップが失敗した場合は、DB インスタンスを復元し、インポートエラーに対処してから、インポートを再試行してください。
**データポンプメタデータを RDS for Oracle DB インスタンスにインポートします**
1. Oracle SQL クライアントを起動し、ターゲット DB インスタンスにマスターユーザーとしてログインします。
1. トランスポートされた表領域にスキーマを所有するユーザーがまだ存在しない場合は、それらのユーザーを作成します。
```
CREATE USER tbs_owner IDENTIFIED BY password;
```
1. ダンプファイルの名前とディレクトリの場所を指定して、メタデータをインポートします。
```
BEGIN
rdsadmin.rdsadmin_transport_util.import_xtts_metadata('xttdump.dmp','DATA_PUMP_DIR');
END;
/
```
1. (オプション) トランスポータブル表領域の履歴テーブルにクエリを実行して、メタデータインポートのステータスを確認します。
```
SELECT * FROM rdsadmin.rds_xtts_operation_info;
```
このオペレーションが完了すると、表領域は読み取り専用モードになります。
1. (オプション) ログファイルを表示します。
次の例では、BDUMP ディレクトリの内容を一覧表示し、インポートログをクエリします。
```
SELECT * FROM TABLE(rdsadmin.rds_file_util.listdir(p_directory => 'BDUMP'));
SELECT * FROM TABLE(rdsadmin.rds_file_util.read_text_file(
p_directory => 'BDUMP',
p_filename => 'rds-xtts-import_xtts_metadata-2023-05-22.01-52-35.560858000.log'));
```
## フェーズ 5: 転送された表領域を検証する
このオプションのステップでは、`rdsadmin.rdsadmin_rman_util.validate_tablespace` プロシージャを使用してトランスポートされた表領域を検証し、表領域を読み取り/書き込みモードにします。
**転送されたデータを検証するには**
1. SQL\$1Plus または SQL Developer を起動し、ターゲット DB インスタンスにマスターユーザーとしてログインします。
1. `rdsadmin.rdsadmin_rman_util.validate_tablespace` プロシージャを使用して表領域を検証します。
```
SET SERVEROUTPUT ON
BEGIN
rdsadmin.rdsadmin_rman_util.validate_tablespace(
p_tablespace_name => 'TBS1',
p_validation_type => 'PHYSICAL+LOGICAL',
p_rman_to_dbms_output => TRUE);
rdsadmin.rdsadmin_rman_util.validate_tablespace(
p_tablespace_name => 'TBS2',
p_validation_type => 'PHYSICAL+LOGICAL',
p_rman_to_dbms_output => TRUE);
rdsadmin.rdsadmin_rman_util.validate_tablespace(
p_tablespace_name => 'TBS3',
p_validation_type => 'PHYSICAL+LOGICAL',
p_rman_to_dbms_output => TRUE);
END;
/
```
1. 表領域を読み取り/書き込みモードにします。
```
ALTER TABLESPACE TBS1 READ WRITE;
ALTER TABLESPACE TBS2 READ WRITE;
ALTER TABLESPACE TBS3 READ WRITE;
```
## フェーズ 6: 残ったファイルをクリーンアップする
このオプションのステップでは、不要なファイルをすべて削除します。`rdsadmin.rdsadmin_transport_util.list_xtts_orphan_files` プロシージャを使用して、テーブルスペースのインポート後に孤立したデータファイルを一覧表示して、`rdsadmin.rdsadmin_transport_util.list_xtts_orphan_files` プロシージャを使用して削除します。これらのプロシージャの構文とセマンティクスについては、「[テーブルスペースのインポート後の孤立ファイルを一覧表示する](rdsadmin_transport_util_list_xtts_orphan_files.md)」および「[テーブルスペースのインポート後に孤立したデータファイルを削除する](rdsadmin_transport_util_cleanup_incomplete_xtts_import.md)」を参照してください。
**残ったファイルをクリーンアップするには**
1. 次のように *DATA\$1PUMP\$1DIR* の古いバックアップを削除します。
1. `rdsadmin.rdsadmin_file_util.listdir` を実行してバックアップファイルを一覧表示します。
```
SELECT * FROM TABLE(rdsadmin.rds_file_util.listdir(p_directory => 'DATA_PUMP_DIR'));
```
1. `UTL_FILE.FREMOVE` を呼び出して、バックアップを 1 つずつ削除します。
```
EXEC UTL_FILE.FREMOVE ('DATA_PUMP_DIR', 'backup_filename');
```
1. 表領域をインポートしたが、これらの表領域のメタデータをインポートしなかった場合は、孤立したデータファイルを次のように削除できます。
1. 削除する必要のある孤立したデータファイルを一覧表示します。次の例では、`rdsadmin.rdsadmin_transport_util.list_xtts_orphan_files` プロシージャを呼び出します。
```
SQL> SELECT * FROM TABLE(rdsadmin.rdsadmin_transport_util.list_xtts_orphan_files);
FILENAME FILESIZE
-------------- ---------
datafile_7.dbf 104865792
datafile_8.dbf 104865792
```
1. `rdsadmin.rdsadmin_transport_util.cleanup_incomplete_xtts_import` プロシージャを実行して、孤立したファイルを削除します。
```
BEGIN
rdsadmin.rdsadmin_transport_util.cleanup_incomplete_xtts_import('DATA_PUMP_DIR');
END;
/
```
クリーンアップ操作により、`BDUMP` ディレクトリに名前形式 `rds-xtts-delete_xtts_orphaned_files-YYYY-MM-DD.HH24-MI-SS.FF.log` を使用するログファイルが生成されます。
1. 前のステップで生成されたログファイルを読み込みます。次の例ではログ `rds-xtts-delete_xtts_orphaned_files-2023-06-01.09-33-11.868894000.log` を読み取ります。
```
SELECT *
FROM TABLE(rdsadmin.rds_file_util.read_text_file(
p_directory => 'BDUMP',
p_filename => 'rds-xtts-delete_xtts_orphaned_files-2023-06-01.09-33-11.868894000.log'));
TEXT
--------------------------------------------------------------------------------
orphan transported datafile datafile_7.dbf deleted.
orphan transported datafile datafile_8.dbf deleted.
```
1. 表領域をインポートし、これらの表領域のメタデータをインポートしたものの、互換性エラーやその他の Oracle Data Pump の問題が発生した場合は、次のように部分的にトランスポートされたデータファイルをクリーンアップします。
1. `DBA_TABLESPACES` クエリを実行して、部分的にトランスポートされたデータファイルを含む表領域を一覧表示します。
```
SQL> SELECT TABLESPACE_NAME FROM DBA_TABLESPACES WHERE PLUGGED_IN='YES';
TABLESPACE_NAME
--------------------------------------------------------------------------------
TBS_3
```
1. 表領域と部分的にトランスポートされたデータファイルを削除します。
```
DROP TABLESPACE TBS_3 INCLUDING CONTENTS AND DATAFILES;
```
# Oracle Data Pump を使用したインポート
Oracle Data Pump は、Oracle データのダンプファイルへのエクスポートおよび別の Oracle データベースへのインポートを行うことができるユーティリティです。Oracle Data Pump は、Oracle エクスポート/インポートユーティリティとして長期間使用されてきました。Oracle Data Pump は、Oracle データベースから Amazon RDS DB インスタンスに大量のデータを移行する際に推奨される方法でもあります。
このセクションの例では、Oracle データベースにデータをインポートする 1 つの方法を示していますが、Oracle Data Pump では他の手法もサポートしています。詳細については、[Oracle Database のドキュメント](https://docs.oracle.com/en/database/oracle/oracle-database/19/sutil/oracle-data-pump.html#GUID-501A9908-BCC5-434C-8853-9A6096766B5A)を参照してください。
このセクションの例では `DBMS_DATAPUMP` パッケージを使用します。同じタスクは、Oracle Data Pump コマンドラインユーティリティの `impdp` および `expdp` を使用して実行できます。これらのユーティリティは、Oracle インスタントクライアントを含む Oracle クライアントインストールの一部としてリモートホストにインストールできます。詳細については、「[Oracle Instant Client を使用した Amazon RDS for Oracle DB インスタンスの Data Pumpのインポートまたはエクスポートを実行する方法](https://aws.amazon.com/premiumsupport/knowledge-center/rds-oracle-instant-client-datapump/)」を参照してください。
**Topics**
+ [Oracle Data Pump の概要](#Oracle.Procedural.Importing.DataPump.Overview)
+ [Oracle Data Pump と Amazon S3 バケットを使用したデータのインポート](#Oracle.Procedural.Importing.DataPump.S3)
+ [Oracle Data Pump とデータベースリンクを使用したデータのインポート](#Oracle.Procedural.Importing.DataPump.DBLink)
## Oracle Data Pump の概要
Oracle Data Pump は、次のコンポーネントで構成されています。
+ コマンドラインクライアントの `expdp` および `impdp`
+ `DBMS_DATAPUMP` PL/SQL パッケージ
+ `DBMS_METADATA` PL/SQL パッケージ
以下のシナリオで Oracle Data Pump を使用できます。
+ Oracle データベース (オンプレミスまたは Amazon EC2 インスタンス) から RDS for Oracle DB インスタンスにデータをインポートする。
+ RDS for Oracle DB インスタンスから Oracle データベース (オンプレミスまたは Amazon EC2 インスタンス) にデータをインポートする。
+ RDS for Oracle DB インスタンス間でデータをインポートする (例: EC2-Classic から VPC へのデータ移行)。
Oracle Data Pump ユーティリティをダウンロードするには、Oracle Technical Network ウェブサイトの「[Oracle Database ソフトウェア・ダウンロード](http://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html)」を参照してください。Oracle Database のバージョン間で移行する場合の互換性に関する考慮事項については、[Oracle Database のドキュメント](https://docs.oracle.com/en/database/oracle/oracle-database/19/sutil/oracle-data-pump-overview.html#GUID-BAA3B679-A758-4D55-9820-432D9EB83C68)を参照してください。
### Oracle Data Pump のワークフロー
通常、Oracle Data Pump は、以下の段階を踏んで使用します。
1. ソースデータベースのダンプファイルにデータをエクスポートします。
1. ダンプファイルを、ターゲットの RDS for Oracle DB インスタンスにアップロードします。ダンプファイルを転送するには、Amazon S3 バケットを使用するか、2 つのデータベース間のデータベースリンクを使用します。
1. ダンプファイルから RDS for Oracle DB インスタンスにデータをインポートします。
### Oracle Data Pump のベストプラクティス
Oracle Data Pump を使用して RDS for Oracle インスタンスにデータをインポートする場合は、次のベストプラクティスをお勧めします。
+ 特定のスキーマやオブジェクトをインポートするには、`schema` または `table` モードでインポートを実行します。
+ インポートするスキーマをアプリケーションに必要なスキーマに制限します。
+ `full` モードでのインポートまたはシステムが管理するコンポーネントのスキーマのインポートは行わないでください。
RDS for Oracle では `SYS` または `SYSDBA` 管理ユーザーへのアクセスが許可されていないため、これらのアクションによって Oracle データディレクトリが損傷し、データベースの安定性が影響を受ける可能性があります。
+ 大量のデータをロードする場合は、以下の操作を実行します。
1. ダンプファイルを、ターゲットの RDS for Oracle DB インスタンスに転送します。
1. インスタンスのDB スナップショットを取得します。
1. インポートをテストして、これが成功することを確認します。
データベースコンポーネントが無効の場合は、DB インスタンスを削除後、DB スナップショットから再作成します。復元された DB インスタンスには、DB スナップショットの作成時に DB インスタンス上でステージングされたダンプファイルがすべて含まれています。
+ Oracle Data Pump エクスポートパラメータ `TRANSPORT_TABLESPACES`、`TRANSPORTABLE`、または `TRANSPORT_FULL_CHECK` を使用して作成されたダンプファイルはインポートしないでください。RDS for Oracle DB インスタンスでは、これらのダンプファイルのインポートはサポートされていません。
+ `SYS`、`SYSTEM`、`RDSADMIN`、`RDSSEC`、`RDS_DATAGUARD` の Oracle スケジューラオブジェクトを含み、以下のカテゴリに属するダンプファイルをインポートしないでください。
+ ジョブ
+ プログラム
+ スケジュール
+ チェーン
+ Rules
+ 評価コンテキスト
+ ルールセット
RDS for Oracle DB インスタンスでは、これらのダンプファイルのインポートはサポートされていません。
+ サポートされていない Oracle Scheduler オブジェクトを除外するには、Data Pump エクスポート時に追加のディレクティブを使用します。`DBMS_DATAPUMP` を使用する場合は、`METADATA_FILTER` の前に `DBMS_METADATA.START_JOB` をさらに追加します。
```
DBMS_DATAPUMP.METADATA_FILTER(
v_hdnl,
'EXCLUDE_NAME_EXPR',
q'[IN (SELECT NAME FROM SYS.OBJ$
WHERE TYPE# IN (66,67,74,79,59,62,46)
AND OWNER# IN
(SELECT USER# FROM SYS.USER$
WHERE NAME IN ('RDSADMIN','SYS','SYSTEM','RDS_DATAGUARD','RDSSEC')
)
)
]',
'PROCOBJ'
);
```
`expdp` を使用する場合は、次の例に示す `exclude` ディレクティブを含むパラメータファイルを作成します。その後、`PARFILE=parameter_file` コマンドで `expdp` を使用します。
```
exclude=procobj:"IN
(SELECT NAME FROM sys.OBJ$
WHERE TYPE# IN (66,67,74,79,59,62,46)
AND OWNER# IN
(SELECT USER# FROM SYS.USER$
WHERE NAME IN ('RDSADMIN','SYS','SYSTEM','RDS_DATAGUARD','RDSSEC')
)
)"
```
## Oracle Data Pump と Amazon S3 バケットを使用したデータのインポート
次のインポートプロセスでは、Oracle Data Pump と Amazon S3 バケットを使用します。ステップは次のとおりです。
1. Oracle [DBMS\$1DATAPUMP](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_DATAPUMP.html) パッケージを使用して、ソースデータベースのデータをエクスポートします。
1. ダンプファイルを Amazon S3 バケットに配置します。
1. Amazon S3 バケットから、ターゲットの Amazon RDS for Oracle DB インスタンスの `DATA_PUMP_DIR` ディレクトリにダンプファイルをダウンロードします。
1. `DBMS_DATAPUMP` パッケージを使用して、コピーしたダンプファイルのデータを RDS for Oracle DB インスタンス内にインポートします。
**Topics**
+ [Oracle Data Pump と Amazon S3 バケットを使用したデータのインポートの要件](#Oracle.Procedural.Importing.DataPumpS3.requirements)
+ [ステップ 1: RDS for Oracle のターゲットの DB インスタンスのデータベースユーザーに特権を付与する](#Oracle.Procedural.Importing.DataPumpS3.Step1)
+ [ステップ 2: DBMS\$1DATAPUMP を使用してデータをダンプファイルにエクスポートする](#Oracle.Procedural.Importing.DataPumpS3.Step2)
+ [ステップ 3: Amazon S3 バケットにダンプファイルをアップロードする](#Oracle.Procedural.Importing.DataPumpS3.Step3)
+ [ステップ 4: ダンプファイルを Amazon S3 バケットからターゲット DB インスタンスにダウンロードする](#Oracle.Procedural.Importing.DataPumpS3.Step4)
+ [ステップ 5: DBMS\$1DATAPUMP を使用してダンプファイルをターゲット DB インスタンスにインポートする](#Oracle.Procedural.Importing.DataPumpS3.Step5)
+ [ステップ 6: クリーンアップ](#Oracle.Procedural.Importing.DataPumpS3.Step6)
### Oracle Data Pump と Amazon S3 バケットを使用したデータのインポートの要件
このプロセスには、次の要件があります。
+ Amazon S3 バケットをファイル転送に使用でき、この Amazon S3 バケットが、DB インスタンスと同じ AWS リージョン リージョン内にあることを確認します。手順については、*Amazon Simple Storage Service 入門ガイド*の「[バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html)」を参照してください。
+ Amazon S3 バケットにアップロードするオブジェクトは、5 TB 以下にする必要があります。Amazon S3 でオブジェクトを操作する方法については、[Amazon Simple Storage Service ユーザーガイド](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingObjects.html)を参照してください。
**注記**
ダンプファイルが5 TBを超える場合、並列オプションを使用して Oracle Data Pump エクスポートを実行できます。このオペレーションは、個々のファイルの 5 TB の制限を超えないように複数のダンプファイルにデータを分散します。
+ Amazon RDS 統合用の Amazon S3 バケットは、「[Amazon S3 と RDS for Oracle を統合する IAM アクセス許可の設定](oracle-s3-integration.preparing.md)」の手順に従って準備してください。
+ 移行元のインスタンスと移行先の DB インスタンスにダンプファイルを保存するための十分なストレージ領域が必要です。
**注記**
このプロセスでは、`DATA_PUMP_DIR` ディレクトリ (すべての Oracle DB インスタンスで事前に設定されているディレクトリ) にダンプファイルをインポートします。このディレクトリはデータファイルと同じストレージボリュームにあります。ダンプファイルをインポートした場合、既存の Oracle データファイルのスペース占有率は高くなります。そのため、DB インスタンスではスペースの追加占有に対応できることを確認する必要があります。インポートしたダンプファイルは、`DATA_PUMP_DIR` ディレクトリから自動的に削除またはパージされることはありません。インポートしたダンプファイルを削除するには、Oracle ウェブサイトにある [UTL\$1FILE.FREMOVE](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/UTL_FILE.html#GUID-09B09C2A-2C21-4F70-BF04-D0EEA7B59CAF) を使用します。
### ステップ 1: RDS for Oracle のターゲットの DB インスタンスのデータベースユーザーに特権を付与する
このステップでは、データのインポート先となるスキーマを作成し、ユーザーに必要な特権を付与します。
**RDS for Oracle ターゲットインスタンスでユーザーを作成し、必要な特権を付与するには**
1. SQL\$1Plus や Oracle SQL Developer を使用して、データをインポートする先の RDS for Oracle DB インスタンスにマスターユーザーとしてログインします。DB インスタンスへの接続方法については、「[Oracle DB インスタンスへの接続](USER_ConnectToOracleInstance.md)」を参照ください。
1. データをインポートする前に、必要なテーブルスペースを作成します。詳細については、「[RDS for Oracle でのテーブルスペースの作成とサイズ設定](Appendix.Oracle.CommonDBATasks.TablespacesAndDatafiles.md#Appendix.Oracle.CommonDBATasks.CreatingTablespacesAndDatafiles)」を参照してください。
1. データのインポート先のユーザーアカウントが存在しない場合は、ユーザーアカウントを作成し、必要なアクセス許可とロールを付与します。データを複数のユーザースキーマにインポートする場合は、各ユーザーアカウントを作成し、それぞれ必要な権限およびロールを付与します。
例えば、以下の SQL ステートメントでは、新しいユーザーを作成して、ユーザーが所有するスキーマ内にデータをインポートするために必要な特権とロールを付与します。`schema_1` を、このステップおよび次のステップのスキーマ名に置き換えます。
```
CREATE USER schema_1 IDENTIFIED BY my_password;
GRANT CREATE SESSION, RESOURCE TO schema_1;
ALTER USER schema_1 QUOTA 100M ON users;
```
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
前のステートメントでは、新規ユーザーに特権 `CREATE SESSION` とロール `RESOURCE` を付与します。インポートするデータベースオブジェクトによっては、特権とロールの追加が必要になる場合があります。
### ステップ 2: DBMS\$1DATAPUMP を使用してデータをダンプファイルにエクスポートする
ダンプファイルを作成するには、`DBMS_DATAPUMP` パッケージを使用します。
**Oracle データをダンプファイルにエクスポートするには**
1. 管理ユーザーとして、SQL Plus または Oracle SQL Developer を使用してソースの RDS for Oracle DB インスタンスに接続します。移行元のデータベースが RDS for Oracle DB インスタンスである場合は、Amazon RDS マスターユーザーとして接続します。
1. `DBMS_DATAPUMP` プロシージャを呼び出して、データをエクスポートします。
次のスクリプトでは、`DATA_PUMP_DIR` ディレクトリ内の `sample.dmp` という名前のダンプファイルに `SCHEMA_1` スキーマをエクスポートします。`SCHEMA_1` をエクスポートするスキーマの名前に置き換えます。
```
DECLARE
v_hdnl NUMBER;
BEGIN
v_hdnl := DBMS_DATAPUMP.OPEN(
operation => 'EXPORT',
job_mode => 'SCHEMA',
job_name => null
);
DBMS_DATAPUMP.ADD_FILE(
handle => v_hdnl ,
filename => 'sample.dmp' ,
directory => 'DATA_PUMP_DIR',
filetype => dbms_datapump.ku$_file_type_dump_file
);
DBMS_DATAPUMP.ADD_FILE(
handle => v_hdnl,
filename => 'sample_exp.log',
directory => 'DATA_PUMP_DIR' ,
filetype => dbms_datapump.ku$_file_type_log_file
);
DBMS_DATAPUMP.METADATA_FILTER(v_hdnl,'SCHEMA_EXPR','IN (''SCHEMA_1'')');
DBMS_DATAPUMP.METADATA_FILTER(
v_hdnl,
'EXCLUDE_NAME_EXPR',
q'[IN (SELECT NAME FROM SYS.OBJ$
WHERE TYPE# IN (66,67,74,79,59,62,46)
AND OWNER# IN
(SELECT USER# FROM SYS.USER$
WHERE NAME IN ('RDSADMIN','SYS','SYSTEM','RDS_DATAGUARD','RDSSEC')
)
)
]',
'PROCOBJ'
);
DBMS_DATAPUMP.START_JOB(v_hdnl);
END;
/
```
**注記**
Data Pump は非同期的にジョブを開始します。Data Pump ジョブのモニタリングについては、Oracle ドキュメントの「[ジョブステータスのモニタリング](https://docs.oracle.com/en/database/oracle/oracle-database/19/sutil/oracle-data-pump-overview.html#GUID-E365D74E-12CD-495C-BA23-5A55F679C7E7)」を参照してください。
1. (オプション) `rdsadmin.rds_file_util.read_text_file` プロシージャを呼び出してエクスポートログの内容を表示します。詳細については、「[DB インスタンスディレクトリ内のファイルの読み取り](Appendix.Oracle.CommonDBATasks.Misc.md#Appendix.Oracle.CommonDBATasks.ReadingFiles)」を参照してください。
### ステップ 3: Amazon S3 バケットにダンプファイルをアップロードする
Amazon RDS プロシージャ `rdsadmin.rdsadmin_s3_tasks.upload_to_s3` を使用して、Amazon S3 バケットにダンプファイルをコピーします。次の例では、`DATA_PUMP_DIR` ディレクトリのすべてのファイルを、`amzn-s3-demo-bucket` という名前の Amazon S3 バケットにアップロードします。
```
SELECT rdsadmin.rdsadmin_s3_tasks.upload_to_s3(
p_bucket_name => 'amzn-s3-demo-bucket',
p_directory_name => 'DATA_PUMP_DIR')
AS TASK_ID FROM DUAL;
```
`SELECT` ステートメントでは、データ型 `VARCHAR2` のタスクの ID が返ります。詳細については、「[RDS for Oracle DB インスタンスから Amazon S3 バケットにファイルをアップロードする](oracle-s3-integration.using.md#oracle-s3-integration.using.upload)」を参照してください。
### ステップ 4: ダンプファイルを Amazon S3 バケットからターゲット DB インスタンスにダウンロードする
Amazon RDS プロシージャ `rdsadmin.rdsadmin_s3_tasks.download_from_s3` を使用して、このステップを実行します。ファイルをディレクトリにダウンロードするとき、ディレクトリに同じ名前のファイルが既に存在する場合、プロシージャ `download_from_s3` はダウンロードをスキップします。ダウンロードディレクトリからファイルを削除するには、Oracle ウェブサイトにある [UTL\$1FILE.FREMOVE](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/UTL_FILE.html#GUID-09B09C2A-2C21-4F70-BF04-D0EEA7B59CAF) を使用します。
**ダンプファイルをダウンロードするには**
1. SQL\$1Plus または Oracle SQL Developer を起動し、Amazon RDS ターゲットの Oracle DB インスタンスにマスターとしてログインします。
1. Amazon RDS プロシージャ `rdsadmin.rdsadmin_s3_tasks.download_from_s3` を使用してダンプファイルをダウンロードします。
次の例では、`amzn-s3-demo-bucket` という名前の Amazon S3 バケットからディレクトリ `DATA_PUMP_DIR` にすべてのファイルをダウンロードします。
```
SELECT rdsadmin.rdsadmin_s3_tasks.download_from_s3(
p_bucket_name => 'amzn-s3-demo-bucket',
p_directory_name => 'DATA_PUMP_DIR')
AS TASK_ID FROM DUAL;
```
`SELECT` ステートメントでは、データ型 `VARCHAR2` のタスクの ID が返ります。詳細については、「[Amazon S3 バケットから Oracle DB インスタンスにファイルをダウンロードする](oracle-s3-integration.using.md#oracle-s3-integration.using.download)」を参照してください。
### ステップ 5: DBMS\$1DATAPUMP を使用してダンプファイルをターゲット DB インスタンスにインポートする
`DBMS_DATAPUMP` を使用して、RDS for Oracle DB インスタンスにスキーマをインポートします。`METADATA_REMAP` などの追加オプションが必要になる場合があります。
**ターゲット DB インスタンスにデータをインポートするには**
1. SQL\$1Plus または SQL Developer を起動し、RDS for Oracle DB インスタンスにマスターユーザーとしてログインします。
1. `DBMS_DATAPUMP` プロシージャを呼び出して、データをインポートします。
次の例では、`sample_copied.dmp` からターゲット DB インスタンスに *SCHEMA\$11* データをインポートします。
```
DECLARE
v_hdnl NUMBER;
BEGIN
v_hdnl := DBMS_DATAPUMP.OPEN(
operation => 'IMPORT',
job_mode => 'SCHEMA',
job_name => null);
DBMS_DATAPUMP.ADD_FILE(
handle => v_hdnl,
filename => 'sample_copied.dmp',
directory => 'DATA_PUMP_DIR',
filetype => dbms_datapump.ku$_file_type_dump_file);
DBMS_DATAPUMP.ADD_FILE(
handle => v_hdnl,
filename => 'sample_imp.log',
directory => 'DATA_PUMP_DIR',
filetype => dbms_datapump.ku$_file_type_log_file);
DBMS_DATAPUMP.METADATA_FILTER(v_hdnl,'SCHEMA_EXPR','IN (''SCHEMA_1'')');
DBMS_DATAPUMP.START_JOB(v_hdnl);
END;
/
```
**注記**
Data Pump ジョブは非同期的に開始されます。Data Pump ジョブのモニタリングについては、Oracle ドキュメントの「[ジョブステータスのモニタリング](https://docs.oracle.com/en/database/oracle/oracle-database/19/sutil/oracle-data-pump-overview.html#GUID-E365D74E-12CD-495C-BA23-5A55F679C7E7)」を参照してください。インポートログの内容は、`rdsadmin.rds_file_util.read_text_file` の手順を使用して表示できます。詳細については、「[DB インスタンスディレクトリ内のファイルの読み取り](Appendix.Oracle.CommonDBATasks.Misc.md#Appendix.Oracle.CommonDBATasks.ReadingFiles)」を参照してください。
1. ターゲット DB インスタンスのスキーマテーブルを一覧表示して、データのインポートを検証します。
例えば、次のクエリでは、`SCHEMA_1` のテーブル数が返ります。
```
SELECT COUNT(*) FROM DBA_TABLES WHERE OWNER='SCHEMA_1';
```
### ステップ 6: クリーンアップ
データをインポートしたら、保管が不要になったファイルは削除できます。
**不要なファイルを削除するには**
1. SQL\$1Plus または SQL Developer を起動し、RDS for Oracle DB インスタンスにマスターユーザーとしてログインします。
1. 次のコマンドを使用して `DATA_PUMP_DIR` のファイルを一覧表示します。
```
SELECT * FROM TABLE(rdsadmin.rds_file_util.listdir('DATA_PUMP_DIR')) ORDER BY MTIME;
```
1. `DATA_PUMP_DIR` 内の不要になったファイルを削除するには、次のコマンドを使用します。
```
EXEC UTL_FILE.FREMOVE('DATA_PUMP_DIR','filename');
```
例えば、次のコマンドは、`sample_copied.dmp` という名前のファイルが削除されます。
```
EXEC UTL_FILE.FREMOVE('DATA_PUMP_DIR','sample_copied.dmp');
```
## Oracle Data Pump とデータベースリンクを使用したデータのインポート
次のインポートプロセスでは、Oracle Data Pump と Oracle [DBMS\$1FILE\$1TRANSFER](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_FILE_TRANSFER.html) パッケージを使用します。ステップは次のとおりです。
1. ソースの Oracle データベース (オンプレミスデータベース、Amazon EC2 インスタンス、または RDS for Oracle DB インスタンス) に接続します。
1. [DBMS\$1DATAPUMP](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_DATAPUMP.html) を使用してデータをエクスポートします。
1. `DBMS_FILE_TRANSFER.PUT_FILE` を使用して、Oracle インスタンスのダンプファイルを、データベースリンクを使用して接続されているターゲットの RDS for Oracle DB インスタンスの `DATA_PUMP_DIR` ディレクトリにコピーします。
1. ` DBMS_DATAPUMP` パッケージを使用して、コピーしたダンプファイルのデータを RDS for Oracle DB インスタンス内にインポートします。
Oracle Data Pump と `DBMS_FILE_TRANSFER` バケットを使用したインポートプロセスでは、次のステップを使用します。
**Topics**
+ [Oracle Data Pump とデータベースリンクを使用したデータのインポートの要件](#Oracle.Procedural.Importing.DataPumpDBLink.requirements)
+ [ステップ 1: RDS for Oracle のターゲットの DB インスタンスのユーザーに特権を付与する](#Oracle.Procedural.Importing.DataPumpDBLink.Step1)
+ [ステップ 2: ソースデータベースのユーザーに特権を付与する](#Oracle.Procedural.Importing.DataPumpDBLink.Step2)
+ [ステップ 3: DBMS\$1DATAPUMP を使用してダンプファイルを作成する](#Oracle.Procedural.Importing.DataPumpDBLink.Step3)
+ [ステップ 4: 移行先の DB インスタンスへのデータベースリンクを作成する](#Oracle.Procedural.Importing.DataPumpDBLink.Step4)
+ [ステップ 5: DBMS\$1FILE\$1TRANSFER を使用して、エクスポートされたダンプファイルをターゲットの DB インスタンスにコピーする](#Oracle.Procedural.Importing.DataPumpDBLink.Step5)
+ [ステップ 6: DBMS\$1DATAPUMP を使用してターゲットの DB インスタンスにデータファイルをインポートする](#Oracle.Procedural.Importing.DataPumpDBLink.Step6)
+ [ステップ 7: クリーンアップ](#Oracle.Procedural.Importing.DataPumpDBLink.Step7)
### Oracle Data Pump とデータベースリンクを使用したデータのインポートの要件
このプロセスには、次の要件があります。
+ `DBMS_FILE_TRANSFER` パッケージと `DBMS_DATAPUMP` パッケージに対する実行権限が必要です。
+ 移行元の DB インスタンスの `DATA_PUMP_DIR` ディレクトリに対する書き込み権限が必要です。
+ 移行元のインスタンスと移行先の DB インスタンスにダンプファイルを保存するための十分なストレージ領域が必要です。
**注記**
このプロセスでは、`DATA_PUMP_DIR` ディレクトリ (すべての Oracle DB インスタンスで事前に設定されているディレクトリ) にダンプファイルをインポートします。このディレクトリはデータファイルと同じストレージボリュームにあります。ダンプファイルをインポートした場合、既存の Oracle データファイルのスペース占有率は高くなります。そのため、DB インスタンスではスペースの追加占有に対応できることを確認する必要があります。インポートしたダンプファイルは、`DATA_PUMP_DIR` ディレクトリから自動的に削除またはパージされることはありません。インポートしたダンプファイルを削除するには、Oracle ウェブサイトにある [UTL\$1FILE.FREMOVE](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/UTL_FILE.html#GUID-09B09C2A-2C21-4F70-BF04-D0EEA7B59CAF) を使用します。
### ステップ 1: RDS for Oracle のターゲットの DB インスタンスのユーザーに特権を付与する
RDS for Oracle のターゲットの DB インスタンスのユーザーに特権を付与するには、次のステップを行います。
1. SQL Plus または Oracle SQL Developer を使用して、データをインポートする RDS for Oracle DB インスタンスに接続します。Amazon RDS マスターユーザーとして接続します。DB インスタンスへの接続方法については、「[Oracle DB インスタンスへの接続](USER_ConnectToOracleInstance.md)」を参照してください。
1. データをインポートする前に、必要なテーブルスペースを作成します。詳細については、「[RDS for Oracle でのテーブルスペースの作成とサイズ設定](Appendix.Oracle.CommonDBATasks.TablespacesAndDatafiles.md#Appendix.Oracle.CommonDBATasks.CreatingTablespacesAndDatafiles)」を参照してください。
1. データのインポート先のユーザーアカウントが存在しない場合は、ユーザーアカウントを作成し、必要なアクセス許可とロールを付与します。データを複数のユーザースキーマにインポートする場合は、各ユーザーアカウントを作成し、それぞれ必要な特権およびロールを付与します。
例えば、以下のコマンドでは、*schema\$11* という名前の新しいユーザーを作成して、このユーザーのスキーマ内にデータをインポートするために必要なアクセス許可とロールを付与します。
```
CREATE USER schema_1 IDENTIFIED BY my-password;
GRANT CREATE SESSION, RESOURCE TO schema_1;
ALTER USER schema_1 QUOTA 100M ON users;
```
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
この前の例では、新規ユーザーに特権 `CREATE SESSION` とロール `RESOURCE` を付与します。インポートするデータベースオブジェクトによっては、特権とロールの追加が必要になる場合があります。
**注記**
`schema_1` を、このステップおよび次のステップのスキーマ名に置き換えます。
### ステップ 2: ソースデータベースのユーザーに特権を付与する
SQL \$1Plus または Oracle SQL Developer を使用して、インポートするデータが含まれている RDS for Oracle DB インスタンスに接続します。必要に応じて、ユーザーアカウントを作成し、必要なアクセス許可を付与します。
**注記**
移行元のデータベースが Amazon RDS インスタンスの場合、このステップは省略できます。エクスポートを行うには、Amazon RDS マスターユーザーアカウントを使用します。
次のコマンドでは、新しいユーザーを作成し、必要なアクセス許可を付与します。
```
CREATE USER export_user IDENTIFIED BY my-password;
GRANT CREATE SESSION, CREATE TABLE, CREATE DATABASE LINK TO export_user;
ALTER USER export_user QUOTA 100M ON users;
GRANT READ, WRITE ON DIRECTORY data_pump_dir TO export_user;
GRANT SELECT_CATALOG_ROLE TO export_user;
GRANT EXECUTE ON DBMS_DATAPUMP TO export_user;
GRANT EXECUTE ON DBMS_FILE_TRANSFER TO export_user;
```
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
### ステップ 3: DBMS\$1DATAPUMP を使用してダンプファイルを作成する
ダンプファイルを作成するには、次の手順に従います。
1. 管理ユーザーまたはステップ 2 で作成したユーザーとして、SQL\$1Plus または Oracle SQL Developer を使用してソースの Oracle インスタンスに接続します。移行元のデータベースが Amazon RDS for Oracle DB インスタンスである場合は、Amazon RDS マスターユーザーとして接続します。
1. Oracle Data Pump ユーティリティを使用してダンプファイルを作成します。
次のスクリプトでは、`DATA_PUMP_DIR` ディレクトリに *sample.dmp* というダンプファイルを作成します。
```
DECLARE
v_hdnl NUMBER;
BEGIN
v_hdnl := DBMS_DATAPUMP.OPEN(
operation => 'EXPORT' ,
job_mode => 'SCHEMA' ,
job_name => null
);
DBMS_DATAPUMP.ADD_FILE(
handle => v_hdnl,
filename => 'sample.dmp' ,
directory => 'DATA_PUMP_DIR' ,
filetype => dbms_datapump.ku$_file_type_dump_file
);
DBMS_DATAPUMP.ADD_FILE(
handle => v_hdnl ,
filename => 'sample_exp.log' ,
directory => 'DATA_PUMP_DIR' ,
filetype => dbms_datapump.ku$_file_type_log_file
);
DBMS_DATAPUMP.METADATA_FILTER(
v_hdnl ,
'SCHEMA_EXPR' ,
'IN (''SCHEMA_1'')'
);
DBMS_DATAPUMP.METADATA_FILTER(
v_hdnl,
'EXCLUDE_NAME_EXPR',
q'[IN (SELECT NAME FROM sys.OBJ$
WHERE TYPE# IN (66,67,74,79,59,62,46)
AND OWNER# IN
(SELECT USER# FROM SYS.USER$
WHERE NAME IN ('RDSADMIN','SYS','SYSTEM','RDS_DATAGUARD','RDSSEC')
)
)
]',
'PROCOBJ'
);
DBMS_DATAPUMP.START_JOB(v_hdnl);
END;
/
```
**注記**
Data Pump ジョブは非同期的に開始されます。Data Pump ジョブのモニタリングについては、Oracle ドキュメントの「[ジョブステータスのモニタリング](https://docs.oracle.com/en/database/oracle/oracle-database/19/sutil/oracle-data-pump-overview.html#GUID-E365D74E-12CD-495C-BA23-5A55F679C7E7)」を参照してください。エクスポートログの内容は、`rdsadmin.rds_file_util.read_text_file` の手順を使用して表示できます。詳細については、「[DB インスタンスディレクトリ内のファイルの読み取り](Appendix.Oracle.CommonDBATasks.Misc.md#Appendix.Oracle.CommonDBATasks.ReadingFiles)」を参照してください。
### ステップ 4: 移行先の DB インスタンスへのデータベースリンクを作成する
移行元の DB インスタンスと移行先の DB インスタンスの間にデータベースリンクを作成します。データベースリンクを作成してエクスポートダンプファイルを転送するには、DB インスタンスとのネットワーク接続がローカルの Oracle インスタンスに必要です。
このステップでは、前のステップと同じユーザーアカウントを使用して接続します。
同じ VPC 内またはピア接続された VPC 内の 2 つの DB インスタンス間のデータベースリンクを作成する場合、2 つの DB インスタンス間には有効なルートがある必要があります。各 DB インスタンスのセキュリティグループは他の DB インスタンスの受信と送信を許可する必要があります。セキュリティグループのインバウンドルールとアウトバウンドルールは、同じ VPC またはピアリング接続先 VPC からセキュリティグループを参照できます。詳細については、「[VPC の DB インスタンスで使用するデータベースリンクの調整](Appendix.Oracle.CommonDBATasks.DBLinks.md)」を参照してください。
次のコマンドでは、ターゲットの DB インスタンスの Amazon RDS マスターユーザーに接続する `to_rds` という名前のデータベースリンクを作成します。
```
CREATE DATABASE LINK to_rds
CONNECT TO IDENTIFIED BY
USING '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=)
(PORT=))(CONNECT_DATA=(SID=)))';
```
### ステップ 5: DBMS\$1FILE\$1TRANSFER を使用して、エクスポートされたダンプファイルをターゲットの DB インスタンスにコピーする
`DBMS_FILE_TRANSFER` を使用して、移行元のデータベースインスタンスから移行先の DB インスタンスにダンプファイルをコピーします。次のスクリプトでは、ソースのインスタンスから *to\$1rds* という名前のターゲットのデータベースリンク (前のステップで作成) に sample.dmp というダンプファイルをコピーします。
```
BEGIN
DBMS_FILE_TRANSFER.PUT_FILE(
source_directory_object => 'DATA_PUMP_DIR',
source_file_name => 'sample.dmp',
destination_directory_object => 'DATA_PUMP_DIR',
destination_file_name => 'sample_copied.dmp',
destination_database => 'to_rds' );
END;
/
```
### ステップ 6: DBMS\$1DATAPUMP を使用してターゲットの DB インスタンスにデータファイルをインポートする
Oracle Data Pump を使用してスキーマを DB インスタンスにインポートします。METADATA\$1REMAP などの追加オプションが必要になる場合があります。
Amazon RDS マスターユーザーアカウントで DB インスタンスに接続し、インポートを実行します。
```
DECLARE
v_hdnl NUMBER;
BEGIN
v_hdnl := DBMS_DATAPUMP.OPEN(
operation => 'IMPORT',
job_mode => 'SCHEMA',
job_name => null);
DBMS_DATAPUMP.ADD_FILE(
handle => v_hdnl,
filename => 'sample_copied.dmp',
directory => 'DATA_PUMP_DIR',
filetype => dbms_datapump.ku$_file_type_dump_file );
DBMS_DATAPUMP.ADD_FILE(
handle => v_hdnl,
filename => 'sample_imp.log',
directory => 'DATA_PUMP_DIR',
filetype => dbms_datapump.ku$_file_type_log_file);
DBMS_DATAPUMP.METADATA_FILTER(v_hdnl,'SCHEMA_EXPR','IN (''SCHEMA_1'')');
DBMS_DATAPUMP.START_JOB(v_hdnl);
END;
/
```
**注記**
Data Pump ジョブは非同期的に開始されます。Data Pump ジョブのモニタリングについては、Oracle ドキュメントの「[ジョブステータスのモニタリング](https://docs.oracle.com/en/database/oracle/oracle-database/19/sutil/oracle-data-pump-overview.html#GUID-E365D74E-12CD-495C-BA23-5A55F679C7E7)」を参照してください。インポートログの内容は、`rdsadmin.rds_file_util.read_text_file` の手順を使用して表示できます。詳細については、「[DB インスタンスディレクトリ内のファイルの読み取り](Appendix.Oracle.CommonDBATasks.Misc.md#Appendix.Oracle.CommonDBATasks.ReadingFiles)」を参照してください。
DB インスタンスでユーザーのテーブルを表示することで、データのインポートを検証できます。例えば、次のクエリでは、`schema_1` のテーブル数が返ります。
```
SELECT COUNT(*) FROM DBA_TABLES WHERE OWNER='SCHEMA_1';
```
### ステップ 7: クリーンアップ
データをインポートしたら、保管が不要になったファイルは削除できます。次のコマンドを使用して `DATA_PUMP_DIR` のファイルを一覧表示できます。
```
SELECT * FROM TABLE(rdsadmin.rds_file_util.listdir('DATA_PUMP_DIR')) ORDER BY MTIME;
```
`DATA_PUMP_DIR` 内の不要になったファイルを削除するには、次のコマンドを使用します。
```
EXEC UTL_FILE.FREMOVE('DATA_PUMP_DIR','');
```
例えば、次のコマンドは、`"sample_copied.dmp"` という名前のファイルが削除されます。
```
EXEC UTL_FILE.FREMOVE('DATA_PUMP_DIR','sample_copied.dmp');
```
# Oracle エクスポート/インポートを使用したインポート
次のような場合、Oracle エクスポート/インポートユーティリティを使用して移行することも検討できます。
+ データサイズが小さい。
+ 2 進浮動小数点数や倍精度浮動小数点数などのデータ型を必要としない。
インポートプロセスにより、必要なスキーマオブジェクトが作成されます。したがって、オブジェクトを事前に作成するためのスクリプトを実行する必要はありません。
Oracle エクスポートユーティリティとインポートユーティリティをインストールする最も簡単な方法は、Oracle Instant Client をインストールすることです。ソフトウェアをダウンロードするには、[https://www.oracle.com/database/technologies/instant-client.html](https://www.oracle.com/database/technologies/instant-client.html) にアクセスしてください。ドキュメントについては、*Oracle Database Utilities* マニュアルの「[Instant Client for SQL\$1Loader、エクスポート、およびインポート](https://docs.oracle.com/en/database/oracle/oracle-database/21/sutil/instant-client-sql-loader-export-import.html#GUID-FF1B6F75-09F5-4911-9317-9776FAD15965)」を参照してください。
**テーブルをエクスポートしてからインポートするには**
1. `exp` コマンドを使用して、移行元のデータベースからテーブルをエクスポートします。
次のコマンドは、`tab1`、`tab2`、`tab3` という名前のテーブルをエクスポートします。ダンプファイルは `exp_file.dmp` です。
```
exp cust_dba@ORCL FILE=exp_file.dmp TABLES=(tab1,tab2,tab3) LOG=exp_file.log
```
エクスポートでは、指定されたテーブルのスキーマとデータを含むバイナリダンプファイルが作成されます。
1. `imp` コマンドを使用して、このスキーマとデータを移行先のデータベースにインポートします。
次のコマンドは、ダンプファイル `exp_file.dmp` からテーブル `tab1`、`tab2`、および `tab3` をインポートします。
```
imp cust_dba@targetdb FROMUSER=cust_schema TOUSER=cust_schema \
TABLES=(tab1,tab2,tab3) FILE=exp_file.dmp LOG=imp_file.log
```
ユーザーのニーズに合うと考えられるエクスポートまたはインポートの使用方法は、他にもあります。詳細については、Oracle Database のドキュメントを参照してください。
# Oracle SQL\$1Loader を使用したインポート
含まれるオブジェクトの数が制限されている大規模なデータベースには、Oracle SQL\$1Loader が適しているかもしれません。移行元のデータベースからのエクスポートと移行先のデータベースへの読み込みのプロセスは、スキーマに固有のものであるため、次の例では、サンプルのスキーマオブジェクトを作成し、移行元からエクスポートして、移行先のデータベースにデータを読み込みます。
Oracle SQL\$1Loader をインストールする最も簡単な方法は、Oracle Instant Client をインストールすることです。ソフトウェアをダウンロードするには、[https://www.oracle.com/database/technologies/instant-client.html](https://www.oracle.com/database/technologies/instant-client.html) にアクセスしてください。ドキュメントについては、*Oracle Database Utilities* マニュアルの「[Instant Client for SQL\$1Loader、エクスポート、およびインポート](https://docs.oracle.com/en/database/oracle/oracle-database/21/sutil/instant-client-sql-loader-export-import.html#GUID-FF1B6F75-09F5-4911-9317-9776FAD15965)」を参照してください。
**Oracle SQL\$1Loader を使用してデータをインポートするには**
1. 次の SQL ステートメントを使用して、サンプルの移行元テーブルを作成します。
```
CREATE TABLE customer_0 TABLESPACE users
AS (SELECT ROWNUM id, o.*
FROM ALL_OBJECTS o, ALL_OBJECTS x
WHERE ROWNUM <= 1000000);
```
1. 移行先の RDS for Oracle DB インスタンスで、データを読み込むための移行先テーブルを作成します。`WHERE 1=2` 句を使用すると、`ALL_OBJECTS` の構造体がコピーされますが、どの行もコピーされません。
```
CREATE TABLE customer_1 TABLESPACE users
AS (SELECT 0 AS ID, OWNER, OBJECT_NAME, CREATED
FROM ALL_OBJECTS
WHERE 1=2);
```
1. 移行元のデータベースからテキストファイルにデータをエクスポートします。以下の例では SQL\$1Plus を使用しています。移行するデータについて、データベース内のすべてのオブジェクトをエクスポートするためのスクリプトの生成が必要になる場合があります。
```
ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY/MM/DD HH24:MI:SS'
SET LINESIZE 800 HEADING OFF FEEDBACK OFF ARRAY 5000 PAGESIZE 0
SPOOL customer_0.out
SET MARKUP HTML PREFORMAT ON
SET COLSEP ','
SELECT id, owner, object_name, created
FROM customer_0;
SPOOL OFF
```
1. データの詳細について記述した制御ファイルを作成します。このステップを実行するためのスクリプトを記述する必要がある場合があります。
```
cat << EOF > sqlldr_1.ctl
load data
infile customer_0.out
into table customer_1
APPEND
fields terminated by "," optionally enclosed by '"'
(
id POSITION(01:10) INTEGER EXTERNAL,
owner POSITION(12:41) CHAR,
object_name POSITION(43:72) CHAR,
created POSITION(74:92) date "YYYY/MM/DD HH24:MI:SS"
)
```
必要に応じて、ステージング領域 (Amazon EC2 インスタンスなど) に上のコードで生成したファイルをコピーします。
1. 移行先のデータベース用の適切なユーザー名とパスワードで SQL\$1Loader を使用して、データをインポートします。
```
sqlldr cust_dba@targetdb CONTROL=sqlldr_1.ctl BINDSIZE=10485760 READSIZE=10485760 ROWS=1000
```
# Oracle マテリアライズドビューを使用した移行
大規模なデータセットを効率的に移行するために、Oracle マテリアライズドビューのレプリケーションを使用することができます。レプリケーションを使用すると、移行先テーブルと移行元テーブルとの同期を継続的に維持できます。このため、必要に応じて、後から Amazon RDS に切り替えることができます。
マテリアライズドビューを使用して移行する前に、以下の前提条件を満たしていることを確認してください。
+ 移行先のデータベースから移行元のデータベースへのアクセスを設定します。次の例では、移行元データベースでアクセスルールが有効になっており、移行先の RDS for Oracle データベースが SQL\$1Net を経由して移行元にアクセスすることが許可されています。
+ RDS for Oracle DB インスタンスから移行元のデータベースへのデータベースリンクを作成します。
**マテリアライズドビューを使用してデータを移行するには**
1. 同じパスワードで認証できるユーザーアカウントを、移行元と移行先の RDS for Oracle インスタンスの両方に作成します。次の例では、`dblink_user` という名前のユーザーを作成します。
```
CREATE USER dblink_user IDENTIFIED BY my-password
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp;
GRANT CREATE SESSION TO dblink_user;
GRANT SELECT ANY TABLE TO dblink_user;
GRANT SELECT ANY DICTIONARY TO dblink_user;
```
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
1. 新しく作成したユーザーを使用して、移行先の RDS for Oracle インスタンスから移行元のインスタンスへのデータベースリンクを作成します。
```
CREATE DATABASE LINK remote_site
CONNECT TO dblink_user IDENTIFIED BY my-password
USING '(description=(address=(protocol=tcp) (host=my-host)
(port=my-listener-port)) (connect_data=(sid=my-source-db-sid)))';
```
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
1. リンクをテストします。
```
SELECT * FROM V$INSTANCE@remote_site;
```
1. 移行元のインスタンスで、プライマリキーを持つサンプルテーブルとマテリアライズドビューのログを作成します。
```
CREATE TABLE customer_0 TABLESPACE users
AS (SELECT ROWNUM id, o.*
FROM ALL_OBJECTS o, ALL_OBJECTS x
WHERE ROWNUM <= 1000000);
ALTER TABLE customer_0 ADD CONSTRAINT pk_customer_0 PRIMARY KEY (id) USING INDEX;
CREATE MATERIALIZED VIEW LOG ON customer_0;
```
1. 移行先の RDS for Oracle DB インスタンスで、マテリアライズドビューを作成します。
```
CREATE MATERIALIZED VIEW customer_0
BUILD IMMEDIATE REFRESH FAST
AS (SELECT *
FROM cust_dba.customer_0@remote_site);
```
1. 移行先の RDS for Oracle DB インスタンスで、マテリアライズドビューを更新します。
```
EXEC DBMS_MVIEW.REFRESH('CUSTOMER_0', 'f');
```
1. マテリアライズドビューを削除し、`PRESERVE TABLE` 句を含めて、マテリアライズドビューコンテナテーブルとその内容を保持します。
```
DROP MATERIALIZED VIEW customer_0 PRESERVE TABLE;
```
保持したテーブル名は、削除したマテリアライズドビューと同じです。
# Amazon RDS for Oracle でのリードレプリカの使用
Oracle DB インスタンス間のレプリケーションを設定するには、レプリカデータベースを作成します。Amazon RDS リードレプリカの概要については、[Amazon RDS リードレプリカの概要概要](USER_ReadRepl.md#USER_ReadRepl.Overview) を参照してください。Oracle レプリカと他の DB エンジンの違いの概要については、[DB エンジンのリードレプリカ間の違い](USER_ReadRepl.Overview.Differences.md) を参照してください。
**Topics**
+ [RDS for Oracle レプリカの概要](oracle-read-replicas.overview.md)
+ [RDS for Oracle レプリカの要件と考慮事項](oracle-read-replicas.limitations.md)
+ [Oracle レプリカの作成の準備](oracle-read-replicas.Configuration.md)
+ [マウントモードでの RDS for Oracle レプリカの作成](oracle-read-replicas.creating-in-mounted-mode.md)
+ [RDS for Oracle レプリカモードの変更](oracle-read-replicas.changing-replica-mode.md)
+ [RDS for Oracle レプリカのバックアップの使用](oracle-read-replicas.backups.md)
+ [Oracle Data ata Guard のスイッチオーバー操作の実行](oracle-replication-switchover.md)
+ [RDS for Oracle レプリカのトラブルシューティング](oracle-read-replicas.troubleshooting.md)
+ [RDS for Oracle を使用した REDO トランスポート圧縮](oracle-read-replicas.redo-transport-compression.md)
# RDS for Oracle レプリカの概要
*Oracle レプリカ*データベースは、プライマリデータベースの物理コピーです。読み取り専用モードの Oracle レプリカは、*リードレプリカ*と呼ばれます。マウントモードの Oracle レプリカは、*マウントされたレプリカ*と呼ばれます。Oracle データベースでは、レプリカへの書き込みは許可されませんが、レプリカを昇格して書き込み可能にすることができます。昇格したリードレプリカには、昇格をリクエストされた時点までのレプリケートされたデータがあります。
次のビデオでは、RDS for Oracle の災害対策ついて紹介します。
[](http://www.youtube.com/watch?v=-XpzhIevwVg)
詳細については、ブログ記事「[Amazon RDS for Oracle クロスリージョン自動バックアップによる管理された災害対策 – パート 1](https://aws.amazon.com/blogs/database/managed-disaster-recovery-with-amazon-rds-for-oracle-cross-region-automated-backups-part-1/)」および「[Amazon RDS for Oracle クロスリージョン自動バックアップによる管理された災害対策 – パート 2](https://aws.amazon.com/blogs/database/part-2-managed-disaster-recovery-with-amazon-rds-for-oracle-xrab/)」を参照してください。
**Topics**
+ [読み取り専用レプリカとマウントされたレプリカ](#oracle-read-replicas.overview.modes)
+ [CDB のレプリカを読み取る](#oracle-read-replicas.overview.data-guard)
+ [アーカイブされた REDO ログの保持](#oracle-read-replicas.overview.log-retention)
+ [Oracle レプリケーション中の停止](#oracle-read-replicas.overview.outages)
## 読み取り専用レプリカとマウントされたレプリカ
Oracle レプリカを作成または変更する場合、次のモードのいずれかにすることができます。
[Read-only]
これがデフォルトです。Active Data Guard は、ソースデータベースからすべてのリードレプリカデータベースに変更を送信し、適用します。
1 つのソース DB インスタンスから最大 5 つのリードレプリカを作成できます。すべての DB エンジンに適用されるリードレプリカの一般的な情報については、「[DB インスタンスのリードレプリカの操作](USER_ReadRepl.md)」を参照してください。Oracle Data Guard の詳細については、Oracle ドキュメントの「[Oracle Data Guard の概要および管理](https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/oracle-data-guard-concepts.html#GUID-F78703FB-BD74-4F20-9971-8B37ACC40A65)」を参照してください。
マウント
この場合、レプリケーションでは Oracle Data Guard が使用されますが、レプリカデータベースはユーザー接続を受け付けません。マウントされたレプリカの主な用途は、クロスリージョンの災害対策です。
マウントされたレプリカは、読み取り専用のワークロードを処理できません。マウントされたレプリカは、アーカイブログ保持ポリシーに関係なく、適用後にアーカイブ REDO ログファイルを削除します。
同じソース DB インスタンスに対して、マウントされた DB レプリカと読み取り専用 DB レプリカを組み合わせて作成できます。読み取り専用レプリカをマウントモードに変更したり、マウントされたレプリカを読み取り専用モードに変更したりできます。いずれの場合も、Oracle データベースはアーカイブログの保持設定を維持します。
## CDB のレプリカを読み取る
RDS for Oracle は、シングルテナント設定とマルチテナント設定の両方で、Oracle Database 19c および 21c CDB について、Data Guard リードレプリカをサポートしています。CDB 以外と同様に、CDB でもリードレプリカを作成、管理、および昇格できます。マウントされたレプリカもサポートされています。次の利点を得ることができます。
+ マネージドディザスタリカバリ、高可用性、レプリカへの読み取り専用アクセス
+ 別の AWS リージョン でリードレプリカを作成する機能。
+ 既存の RDS リードレプリカ API との統合: [CreateDBInstanceReadReplica](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstanceReadReplica.html)、[PromoteReadReplica](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_PromoteReadReplica.html)、および [SwitchoverReadReplica](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_SwitchoverReadReplica.html)
この機能を使用するには、レプリカとプライマリ DB インスタンスの両方に Active Data Guard ライセンスと Oracle Database Enterprise Edition ライセンスが必要です。CDB アーキテクチャの使用に関連する追加コストはありません。お支払いいただくのは DB インスタンスに対してのみです。
CDB アーキテクチャのシングルテナント設定とマルチテナント設定の詳細については、「[RDS for Oracle CDB の概要](Oracle.Concepts.CDBs.md)」を参照してください。
## アーカイブされた REDO ログの保持
プライマリ DB インスタンスにクロスリージョンのリードレプリカがない場合、Amazon RDS for Oracle は、ソース DB インスタンスで最低 2 時間のアーカイブ REDO ログを保持します。これは、`rdsadmin.rdsadmin_util.set_configuration` の `archivelog retention hours` の設定に関係なく当てはまります。
RDSは、2時間後、またはアーカイブログの保持時間の設定が経過した後のいずれか長い方の時間後に、ソース DBインスタンスからログを削除します。ログがデータベースに正常に適用された場合にのみ、アーカイブログの保持時間設定が経過すると、RDS はログをリードレプリカから削除します。
プライマリ DB インスタンスには、1 つ以上のクロスリージョンのリードレプリカが存在する場合があります。その場合 Amazon RDS for Oracle は、ソース DB インスタンスのトランザクションログが転送され、すべてのクロスリージョンリードレプリカに適用されるまで保持します。`rdsadmin.rdsadmin_util.set_configuration` については、[アーカイブ REDO ログの保持](Appendix.Oracle.CommonDBATasks.RetainRedoLogs.md)を参照してください。
## Oracle レプリケーション中の停止
リードレプリカを作成すると、Amazon RDS はソース DB インスタンスの DB スナップショットを取得し、レプリケーションを開始します。DB スナップショットオペレーションが始まると、ソース DB インスタンスでごく短時間の I/O 停止が発生します。通常、I/O 停止は約 1 秒続きます。ソース DB インスタンスがマルチ AZ 配置の場合は、I/O 停止を回避できます。スナップショットがセカンダリ DB インスタンスから取得されるためです。
DB スナップショットは Oracle レプリカになります。Amazon RDS は、サービスを中断することなく、ソースデータベースとレプリカに対して必要なパラメータとアクセス許可を設定します。同様に、レプリカを削除する場合も、停止は発生しません。
# RDS for Oracle レプリカの要件と考慮事項
Oracle レプリカを作成する前に、以下の要件と考慮事項を確認してください。
**Topics**
+ [RDS for Oracle レプリカのバージョンとライセンス要件](#oracle-read-replicas.limitations.versions-and-licenses)
+ [RDS for Oracle レプリカのオプショングループの制限事項](#oracle-read-replicas.limitations.options)
+ [RDS for Oracle レプリカのバックアップと復元に関する考慮事項](#oracle-read-replicas.limitations.backups)
+ [RDS for Oracle レプリカに関する Oracle Data Guard の要件と制限事項](#oracle-read-replicas.data-guard.requirements)
+ [RDS for Oracle レプリカのマルチテナント設定の制限](#oracle-read-replicas.limitations.multitenant)
+ [RDS for Oracle レプリカに関するその他の考慮事項](#oracle-read-replicas.limitations.miscellaneous)
## RDS for Oracle レプリカのバージョンとライセンス要件
RDS for Oracle レプリカを作成する前に、次の点を考慮してください。
+ レプリカが読み取り専用モードの場合は、Active Data Guard ライセンスがあることを確認してください。レプリカをマウントモードにした場合、Active Data Guard ライセンスは必要ありません。マウントされたレプリカをサポートするのは、Oracle DB エンジンだけです。
+ Oracle レプリカは、Oracle Enterprise Edition (EE) でのみサポートされています。
+ 非 CDB の Oracle レプリカは、Oracle Database 19c を実行している非 CDB インスタンスを使用して作成された DB インスタンスでのみサポートされます。
+ Oracle レプリカは、2 つ以上の vCPU を持つ DB インスタンスクラスで実行されている DB インスタンスでのみ使用できます。ソース DB インスタンスは、db.t3.small インスタンスクラスを使用できません。
+ ソース DB インスタンスとそのすべてのレプリカの Oracle DB エンジンバージョンは同じである必要があります。Amazon RDS では、レプリカのメンテナンスウィンドウに関係なく、ソース DB インスタンスのアップグレード後すぐにレプリカのアップグレードが行われます。クロスリージョンレプリカのメジャーバージョンアップグレードの場合、Amazon RDS は自動的に以下を実行します。
+ ターゲットバージョンのオプショングループを生成します。
+ 元のオプショングループから新しいオプショングループにすべてのオプションとオプション設定をコピーします。
+ アップグレードされたクロスリージョンレプリカを新しいオプショングループに関連付けます。
DB エンジンバージョンのアップグレードの詳細については、「[RDS for Oracle DB エンジンのアップグレード](USER_UpgradeDBInstance.Oracle.md)」を参照してください。
## RDS for Oracle レプリカのオプショングループの制限事項
RDS for Oracle レプリカのオプショングループを使用する場合は、次の点を考慮してください。
+ ソースとレプリカが同じ AWS リージョンにある場合、ソース DB インスタンスオプショングループとは異なるレプリカオプショングループを使用することはできません。
ソースオプショングループまたはソースオプショングループメンバーシップへの変更はレプリカに反映されます。これらの変更は、レプリカのメンテナンスウィンドウに関係なく、出典 DB インスタンスに適用された後すぐにレプリカに適用されます。オプショングループの詳細については、「[オプショングループを使用する](USER_WorkingWithOptionGroups.md)」を参照してください。
+ RDS for Oracle クロスリージョンレプリカを、レプリカ用に自動的に作成された専用オプショングループから削除することはできません。
+ RDS for Oracle クロスリージョンレプリカの専用オプショングループを他の DB インスタンスに追加することはできません。
+ RDS for Oracle クロスリージョンレプリカの専用オプショングループからは、レプリケートされていないオプションを追加または削除することはできません。ただし、次のオプションは除きます。
+ `NATIVE_NETWORK_ENCRYPTION`
+ `OEM`
+ `OEM_AGENT`
+ `SSL`
RDS for Oracle クロスリージョンレプリカに他のオプションを追加するには、ソース DB インスタンスのオプショングループに追加します。オプションは、すべての出典 DB インスタンスのレプリカにもインストールされます。ライセンス供与オプションについては、レプリカに十分なライセンスがあることを確認してください。
RDS for Oracle クロスリージョンレプリカを昇格するとき、昇格されたレプリカは、オプションの管理を含め、他の Oracle DB インスタンスと同じように動作します。レプリカは、明示的にまたはソース DB インスタンスを削除して暗黙的に昇格できます。
オプショングループの詳細については、「[オプショングループを使用する](USER_WorkingWithOptionGroups.md)」を参照してください。
+ RDS for Oracle クロスリージョンレプリカに `EFS_INTEGRATION` オプションを追加することはできません。
## RDS for Oracle レプリカのバックアップと復元に関する考慮事項
RDS for Oracle レプリカを作成する前に、次の点を考慮してください。
+ RDS for Oracle レプリカのスナップショットを作成したり、自動バックアップを有効にしたりするには、必ずバックアップ保持期間を手動で設定してください。自動バックアップは、デフォルトでは有効になっていません。
+ レプリカのバックアップを復元するときは、バックアップが実行された時刻ではなく、データベース時刻に復元することになります。データベース時刻は、バックアップのデータにトランザクションが最後に適用された時刻を指します。レプリカはプライマリよりも数分または数時間遅れることがあるため、この違いは重大です。
差を確認するには、`describe-db-snapshots` コマンドを使用します。レプリカのバックアップのデータベース時間である `snapshotDatabaseTime` と、プライマリデータベースで最後に適用されたトランザクションである `OriginalSnapshotCreateTime` を比較します。
## RDS for Oracle レプリカに関する Oracle Data Guard の要件と制限事項
RDS for Oracle レプリカを作成する前に、次の要件と制限事項に注意してください。
+ プライマリ DB インスタンスがマルチテナントアーキテクチャのシングルテナントまたはマルチテナント構成を使用している場合は、次の点を考慮してください。
+ Enterprise Edition では Oracle Database 19c 以降を使用する必要があります。
+ プライマリ CDB インスタンスは `ACTIVE` ライフサイクルにある必要があります。
+ CDB 以外のプライマリインスタンスを CDB インスタンスに変換し、そのレプリカを同じ操作で変換することはできません。代わりに、CDB 以外のレプリカを削除し、プライマリ DB インスタンスを CDB に変換してから、新しいレプリカを作成してください。
+ プライマリ DB インスタンスのログイントリガーで、`RDS_DATAGUARD` ユーザーへのアクセス、および `AUTHENTICATED_IDENTITY` の値が `RDS_DATAGUARD` または `rdsdb` であるすべてのユーザーへのアクセスを許可する必要があります。また、トリガーで `RDS_DATAGUARD` ユーザーの現在のスキーマを設定しないでください。
+ Data Guard ブローカープロセスからの接続のブロックを回避するには、制限セッションを有効にしないでください。制限セッションの詳細については、「[制限セッションの有効化と無効化](Appendix.Oracle.CommonDBATasks.RestrictedSession.md)」を参照してください。
## RDS for Oracle レプリカのマルチテナント設定の制限
RDS for Oracle レプリカでマルチテナント設定を使用する場合は、次の制限に注意してください。
+ テナントデータベースを作成、削除、または変更できるのは、プライマリ DB インスタンス上のみです。これらの変更は、レプリカに自動的に伝播されます。
+ RDS for Oracle のプライマリ、ソース、またはレプリカのテナントデータベースをカスタム文字セットを使用して作成することはできません。カスタム文字セットが必要な場合は、DB インスタンスのリードレプリカを作成する前にテナントデータベースを作成します。
## RDS for Oracle レプリカに関するその他の考慮事項
RDS for Oracle レプリカを作成する前に、次の点を考慮してください。
+ 追加のストレージボリュームがある DB インスタンスの RDS for Oracle レプリカを作成する場合、RDS はレプリカに追加のストレージボリュームを自動的に設定します。ただし、プライマリ DB インスタンスのストレージボリュームに加えられた後続の変更は、レプリカに自動的に適用されません。
+ プライマリ DB インスタンスにストレージボリュームを追加した場合、RDS はレプリカにストレージボリュームを自動的に追加しません。追加のストレージボリュームを追加するには、レプリカを変更する必要があります。
+ プライマリ DB インスタンスのストレージサイズや IOPS などのストレージボリューム設定を変更しても、RDS はレプリカのストレージボリュームを自動的に変更しません。ストレージボリュームの設定を更新するには、レプリカを変更する必要があります。
+ ボリューム間でデータファイルの場所を管理する場合、プライマリインスタンスで行われた変更はレプリカに自動的に同期されないことに注意してください。
+ 読み取り専用レプリカの場合: パラメータグループ設定を使用してデフォルトのファイルの場所を制御するか、作成後に手動でファイルを移動できます。
+ マウントされたレプリカの場合: プライマリデータベース内のデータファイルの場所を手動で変更するには、それらの変更を反映するためにマウントされたレプリカを再作成する必要があります。これを回避するには、パラメータグループ設定を使用してデフォルトのファイルの場所を管理することをお勧めします。
+ DB インスタンスが 1 つ以上のクロスリージョンレプリカのソースである場合、ソース DB は、すべてのクロスリージョンレプリカに適用されるまで、アーカイブされた REDO ログファイルに保持されます。アーカイブされた REDO ログにより、ストレージの消費が増える場合があります。
+ RDS 自動化の中断を避けるために、システムトリガーでは、特定のユーザーがプライマリデータベースとレプリカデータベースへのログオンを許可する必要があります。[システムトリガー](https://docs.oracle.com/en/database/oracle/oracle-database/19/lnpls/plsql-triggers.html#GUID-FE23FCE8-DE36-41EF-80A9-6B4B49E80E5B)には、DDL、ログオン、およびデータベースロールトリガーが含まれます。以下のサンプルコードに記載されているユーザーを除外するために、トリガーにコードを追加することをお勧めします。
```
-- Determine who the user is
SELECT SYS_CONTEXT('USERENV','AUTHENTICATED_IDENTITY') INTO CURRENT_USER FROM DUAL;
-- The following users should always be able to login to either the Primary or Replica
IF CURRENT_USER IN ('master_user', 'SYS', 'SYSTEM', 'RDS_DATAGUARD', 'rdsdb') THEN
RETURN;
END IF;
```
+ ブロック変更の追跡は、読み取り専用レプリカではサポートされますが、マウントされたレプリカではサポートされません。マウントされたレプリカを読み取り専用レプリカに変更し、ブロック変更の追跡を有効にすることができます。詳細については、「[ブロック変更追跡の有効化/無効化](Appendix.Oracle.CommonDBATasks.BlockChangeTracking.md)」を参照してください。
+ ソースデータベースが Secrets Manager でマスターユーザー認証情報を管理する場合、Oracle リードレプリカを作成することはできません。
# Oracle レプリカの作成の準備
レプリカの使用をスタートする前に、次のタスクを実行します。
**Topics**
+ [自動バックアップの有効化](#oracle-read-replicas.configuration.autobackups)
+ [強制ログ記録モードの有効化](#oracle-read-replicas.configuration.force-logging)
+ [ログ記録設定の変更](#oracle-read-replicas.configuration.logging-config)
+ [MAX\$1STRING\$1SIZE パラメータの設定](#oracle-read-replicas.configuration.string-size)
+ [コンピューティングとストレージのリソース計画](#oracle-read-replicas.configuration.planning-resources)
## 自動バックアップの有効化
DB インスタンスがソース DB インスタンスとして機能するには、必ずソース DB インスタンスで自動バックアップを有効にします。この手順の実行方法については、「[自動バックアップの有効化](USER_WorkingWithAutomatedBackups.Enabling.md)」を参照してください。
## 強制ログ記録モードの有効化
強制ログ記録モードを有効化することを推奨します。強制ログ記録モードでは、`NOLOGGING` がデータ定義言語 (DDL) ステートメントとともに使用されている場合でも、Oracle データベースは REDO レコードを書き込みます。
**強制ログ記録モードを有効にするには**
1. SQL Developer などのクライアントツールを使用して、Oracle データベースにログインします。
1. 次の手順を実行して、強制ログモードを有効にします。
```
exec rdsadmin.rdsadmin_util.force_logging(p_enable => true);
```
この手順の詳細については、「[強制ログ作成の設定](Appendix.Oracle.CommonDBATasks.Log.md#Appendix.Oracle.CommonDBATasks.SettingForceLogging)」を参照してください。
## ログ記録設定の変更
サイズ *m* の *n* 個のオンライン REDO ログの場合、RDS はプライマリ DB インスタンスとすべてのレプリカにサイズ *m* の *n*\$11 個のスタンバイログを自動的に作成します。プライマリのログ記録設定を変更するたびに、その変更はレプリカに自動的に反映されます。
ログ記録設定を変更する場合は、以下のガイドラインを考慮してください。
+ DB インスタンスをレプリカのソースにする前に変更を完了することをお勧めします。RDS for Oracle は、ソースになった後のインスタンスの更新もサポートしています。
+ プライマリ DB インスタンスのログ記録設定を変更する前に、各レプリカに新しい設定に対応するのに十分なストレージがあることを確認してください。
DB インスタンスのログ設定を変更するには、Amazon RDS の手順 `rdsadmin.rdsadmin_util.add_logfile` と `rdsadmin.rdsadmin_util.drop_logfile` を使用します。詳細については、「[オンライン REDO ログの追加](Appendix.Oracle.CommonDBATasks.Log.md#Appendix.Oracle.CommonDBATasks.RedoLogs)」および「[オンライン REDO ログの削除](Appendix.Oracle.CommonDBATasks.Log.md#Appendix.Oracle.CommonDBATasks.DroppingRedoLogs)」を参照してください。
## MAX\$1STRING\$1SIZE パラメータの設定
Oracle レプリカを作成する前に、`MAX_STRING_SIZE` パラメータの設定が、ソース DB インスタンスおよびそのレプリカと同じであることを確認します。そのためには、同じパラメータグループと関連付けます。ソースとレプリカのパラメータグループが異なる場合は、`MAX_STRING_SIZE` を同じ値に設定できます。このパラメータの設定の詳細については、「[新しい DB インスタンスで拡張データ型を有効にする](Oracle.Concepts.ExtendedDataTypes.md#Oracle.Concepts.ExtendedDataTypes.CreateDBInstance)」を参照してください。
## コンピューティングとストレージのリソース計画
ソース DB インスタンスとそのレプリカのサイズが、運用負荷に合わせる上でコンピューティングとストレージの観点から適切に設定されていることを確認してください。レプリカのコンピューティング、ネットワーク、またはストレージがリソースの容量に達すると、レプリカはソースからの変更の受信または適用を停止します。Amazon RDS for Oracle が、ソース DB インスタンスとそのレプリカ間のレプリカラグの軽減のために介入することはありません。レプリカのストレージや CPU リソースは、そのソースや他のレプリカとは独立して変更することができます。
# マウントモードでの RDS for Oracle レプリカの作成
デフォルトでは、Oracle レプリカは読み取り専用です。マウントモードでレプリカを作成するには、コンソール、AWS CLI、RDS API のいずれかを使用します。
## コンソール
**ソース Oracle DB インスタンスからマウントされたレプリカを作成するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、**データベース** を選択します。
1. マウントされたレプリカのソースとして使用する Oracle DB インスタンスを選択します。
1. **アクション**で**レプリカの作成**を選択します。
1. **レプリカモード**で、**マウント**を選択します。
1. 使用する設定を選択します。**DB インスタンス識別子**に、リードレプリカの名前を入力します。必要に応じて他の設定を変更します。
1. **リージョン**で、マウントされたレプリカを起動するリージョンを選択します。
1. インスタンスサイズとストレージタイプを選択します。リードレプリカでもソース DB インスタンスと同じ DB インスタンスクラスとストレージタイプを使用することをお勧めします。
1. **マルチ AZ 配置**で**スタンバイインスタンスの作成**を選択して、マウントされたレプリカのフェイルオーバーをサポートするために別のアベイラビリティーゾーンにレプリカのスタンバイを作成します。ソースのデータベースがマルチ AZ DB インスタンスであるかどうかに関係なく、マウントされたレプリカをマルチ AZ DB インスタンスとして作成できます。
1. 使用する他の設定を選択します。
1. **レプリカの作成**を選択します。
**データベース**ページで、マウントされたレプリカにロールとして [レプリカ] が割り当てられます。
## AWS CLI
マウントモードで Oracle レプリカを作成するには、`--replica-mode` コマンド [create-db-instance-read-replica](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance-read-replica.html) で `mounted` を AWS CLI に設定します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds create-db-instance-read-replica \
--db-instance-identifier myreadreplica \
--source-db-instance-identifier mydbinstance \
--replica-mode mounted
```
Windows の場合:
```
aws rds create-db-instance-read-replica ^
--db-instance-identifier myreadreplica ^
--source-db-instance-identifier mydbinstance ^
--replica-mode mounted
```
読み取り専用レプリカをマウント状態に変更するには、`--replica-mode` コマンド [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) で `mounted` を AWS CLI に設定します。マウントされたレプリカを読み取り専用モードにするには、`--replica-mode` を `open-read-only` に設定します。
## RDS API
マウントモードで Oracle レプリカを作成するには、RDS API オペレーション [CreateDBInstanceReadReplica](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstanceReadReplica.html) で `ReplicaMode=mounted` を指定します。
# RDS for Oracle レプリカモードの変更
既存のレプリカのレプリカモードを変更するには、コンソール、AWS CLI、RDS API のいずれかを使用します。マウントモードに変更すると、レプリカはすべてのアクティブな接続を切断します。読み取り専用モードに変更すると、Amazon RDS は Active Data Guard を初期化します。
変更には数分かかる場合があります。オペレーション中、DB インスタンスのステータスは **modifying** に変わります。ステータス変更の詳細については、「[ Amazon RDS DB インスタンスのステータスの表示](accessing-monitoring.md#Overview.DBInstance.Status)」を参照してください。
## コンソール
**Oracleレプリカのレプリカモードをマウントから読み取り専用に変更するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**データベース**] を選択します。
1. マウントされたレプリカのデータベースを選択します。
1. **Modify** を選択します。
1. [**レプリカモード**] で、[**読み取り専用**] を選択します。
1. 変更する他の設定を選択します。
1. **[Continue]** (続行) をクリックします。
1. [**変更のスケジューリング**] で、[**すぐに適用**] を選択します。
1. [**DB インスタンスの変更**] を選択します。
## AWS CLI
リードレプリカをマウントモードに変更するには、`--replica-mode` コマンド [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) で `mounted` を AWS CLI に設定します。マウントされたレプリカを読み取り専用モードに変更するには、`--replica-mode` を `open-read-only` に設定します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance \
--db-instance-identifier myreadreplica \
--replica-mode mode
```
Windows の場合:
```
aws rds modify-db-instance ^
--db-instance-identifier myreadreplica ^
--replica-mode mode
```
## RDS API
読み取り専用レプリカをマウントモードに変更するには、[ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstanceReadReplica.html) で `ReplicaMode=mounted` を設定します。マウントされたレプリカを読み取り専用モードに変更するには、`ReplicaMode=read-only` を設定します。
# RDS for Oracle レプリカのバックアップの使用
RDS for Oracle レプリカのバックアップを作成および復元できます。自動バックアップと手動スナップショットの両方がサポートされています。詳細については、「[データのバックアップ、復元、エクスポート](CHAP_CommonTasks.BackupRestore.md)」を参照してください。以下のセクションでは、プライマリと RDS for Oracle レプリカのバックアップ管理の主な違いについて説明します。
## RDS for Oracle レプリカのバックアップを有効にする
Oracle レプリカでは、デフォルトで自動バックアップが有効になっていません。バックアップ保持期間を 0 以外の正の値に設定することで、自動バックアップを有効にします。
### コンソール
**自動バックアップをすぐに有効にするには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、**[データベース]** を選択し、変更する DB インスタンスまたはマルチ AZ DB クラスターを選択します。
1. **[Modify]** (変更) を選択します。
1. **[バックアップ保持期間]** で、ゼロ以外の正の値 (3 日など) を選択します。
1. [**Continue**] を選択します。
1. **[すぐに適用]** を選択します。
1. **[DB インスタンスの変更]** または **[クラスターの変更]** を選択して変更を保存し、自動バックアップを有効にします。
### AWS CLI
自動バックアップを有効にするには、AWS CLI の [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) コマンドまたは [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) コマンドを使用します。
以下のパラメータを含めます。
+ `--db-instance-identifier` (またはマルチ AZ DB クラスターの場合は `--db-cluster-identifier`)
+ `--backup-retention-period`
+ `--apply-immediately` または `--no-apply-immediately`
次の例では、バックアップ保持期間を 3 日に設定して、自動バックアップを有効にします。変更はすぐに適用されます。
**Example**
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance \
--db-instance-identifier my_db_instance \
--backup-retention-period 3 \
--apply-immediately
```
Windows の場合:
```
aws rds modify-db-instance ^
--db-instance-identifier my_db_instance ^
--backup-retention-period 3 ^
--apply-immediately
```
### RDS API
自動バックアップを有効にするには、以下の必須パラメータを指定して RDS API の [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) オペレーションまたは [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) オペレーションを使用します。
+ `DBInstanceIdentifier`、または `DBClusterIdentifier`
+ `BackupRetentionPeriod`
## RDS for Oracle レプリカのバックアップの復元
Oracle レプリカのバックアップは、プライマリインスタンスのバックアップを復元する場合と同様に復元できます。詳細については次を参照してください:
+ [DB インスタンスへの復元](USER_RestoreFromSnapshot.md)
+ [Amazon RDS の DB インスタンスを特定の時点に復元する](USER_PIT.md)
レプリカバックアップを復元する際の主な考慮事項は、復元する時点を決定することです。データベースの時刻では、バックアップ時にデータにトランザクションが最後に適用された時刻を参照します。レプリカのバックアップを復元するときは、バックアップが完了した時刻ではなく、データベースの時刻に復元することになります。RDS for Oracle レプリカはプライマリよりも数分または数時間遅れることがあるため、この違いは重大です。このため、レプリカのバックアップのデータベースの時刻、つまり復元する時点は、バックアップ作成時刻よりもはるかに早い場合があります。
データベースの時刻と作成時刻の差を確認するには、`describe-db-snapshots` コマンドを使用します。レプリカのバックアップのデータベース時間である `SnapshotDatabaseTime` と、プライマリデータベースで最後に適用されたトランザクションである `OriginalSnapshotCreateTime` を比較します。次の例は、2 つの時刻の差を示しています。
```
aws rds describe-db-snapshots \
--db-instance-identifier my-oracle-replica
--db-snapshot-identifier my-replica-snapshot
{
"DBSnapshots": [
{
"DBSnapshotIdentifier": "my-replica-snapshot",
"DBInstanceIdentifier": "my-oracle-replica",
"SnapshotDatabaseTime": "2022-07-26T17:49:44Z",
...
"OriginalSnapshotCreateTime": "2021-07-26T19:49:44Z"
}
]
}
```
# Oracle Data ata Guard のスイッチオーバー操作の実行
*スイッチオーバー*では、プライマリデータベースとスタンバイデータベースとの間でロールが入れ替わります。スイッチオーバー中、元のプライマリデータベースはスタンバイロールに移行し、元のスタンバイデータベースはプライマリロールに移行します。
Oracle Data Guard 環境では、プライマリデータベースは 1 つ以上のスタンバイデータベースをサポートします。プライマリデータベースからスタンバイデータベースへ、マネージド型のスイッチオーバーベースのロール移行を実行できます。*スイッチオーバー*では、プライマリデータベースとスタンバイデータベースとの間でロールが入れ替わります。スイッチオーバー中、元のプライマリデータベースはスタンバイロールに移行し、元のスタンバイデータベースはプライマリロールに移行します。
**Topics**
+ [Oracle Data Guard のスイッチオーバー機能の概要](#oracle-replication-switchover.overview)
+ [Oracle Data Guard のスイッチオーバーの要件](oracle-switchover.preparing.md)
+ [Oracle Data Guard のスイッチオーバーの開始](oracle-switchover.initiating.md)
+ [Oracle Data Guard のスイッチオーバーのモニタリング](oracle-switchover.monitoring.md)
## Oracle Data Guard のスイッチオーバー機能の概要
Amazon RDS は、Oracle データベースレプリカの完全マネージド型のスイッチオーバーベースのロール移行をサポートしています。マウントされているか、読み取り専用で開いているスタンバイデータベースへのスイッチオーバーのみを開始できます。
レプリカは、個別の AWS リージョンに配置するか、単一のリージョン内における複数の異なるアベイラビリティーゾーン (AZ) に配置できます。すべての AWS リージョンがサポートされています。
![\[スタンバイインスタンスを切り替えると、このインスタンスがプライマリ DB インスタンスになります。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/read-replica-switchover.png)
スイッチオーバーは、リードレプリカの昇格とは異なります。スイッチオーバーでは、ソース DB インスタンスとレプリカ DB インスタンスの役割が入れ替わります。昇格では、リードレプリカはソース DB インスタンスになりますが、ソース DB インスタンスはレプリカになりません。詳細については、「[リードレプリカをスタンドアロン DB インスタンスに昇格させる](USER_ReadRepl.Promote.md)」を参照してください。
**Topics**
+ [Oracle Data ata Guard スイッチオーバーの利点](#oracle-replication-switchover.overview.benefits)
+ [サポートされている Oracle Database のバージョン](#oracle-replication-switchover.overview.engine-support)
+ [Oracle Data Guard のスイッチオーバーの費用](#oracle-replication-switchover.overview.cost)
+ [Oracle Data Guard のスイッチオーバーの仕組み](#oracle-replication-switchover.overview.how-it-works)
### Oracle Data ata Guard スイッチオーバーの利点
RDS for Oracle のリードレプリカと同様に、マネージド型スイッチオーバーは Oracle Data Guard に依存しています。このオペレーションは、データ損失がゼロになるように設計されています。Amazon RDS は、スイッチオーバーの次の要素を自動化します。
+ 新しいスタンバイデータベースを元のスタンバイデータベースと同じ状態 (マウントされているか、読み取り専用)、プライマリデータベースと指定されたスタンバイデータベースのロールを逆にする
+ データの整合性を確保する
+ 移行後もレプリケーション構成を維持する
+ 新しいスタンバイデータベースのロールが元のプライマリロールに戻ることができることで、逆転の繰り返しをサポートする
### サポートされている Oracle Database のバージョン
Oracle Data Guard スイッチオーバーは、Oracle Database 19c 以降のリリースでサポートされています。
### Oracle Data Guard のスイッチオーバーの費用
Oracle Data Guard のスイッチオーバー機能には追加コストはかかりません。Oracle Database Enterprise Edition には、マウントモードのスタンバイデータベースのサポートが含まれています。スタンバイデータベースを読み取り専用モードで開くには、Oracle Active Data Guard オプションが必要です。
### Oracle Data Guard のスイッチオーバーの仕組み
Oracle Data Guard のスイッチオーバーはフルマネージド型操作です。スタンバイデータベースのスイッチオーバーを開始するには、CLI コマンド `switchover-read-replica` を実行します。すると、Amazon RDS はレプリケーション構成のプライマリロールとスタンバイロールを変更します。
*オリジナルのスタンバイ*と*オリジナルのプライマリ*がスイッチオーバー前のロールです。*新しいスタンバイ*と*新しいプライマリ*がスイッチオーバー後のロールです。*バイスタンダーのレプリカ*は、Oracle Data Guard 環境ではスタンバイデータベースとして機能しますが、ロールの切り替えは行わないレプリカデータベースです。
**Topics**
+ [Oracle Data Guard のスイッチオーバーのステージ](#oracle-replication-switchover.overview.how-it-works.during-switchover)
+ [Oracle Data Guard のスイッチオーバー操作後](#oracle-replication-switchover.overview.how-it-works.after-switchover)
#### Oracle Data Guard のスイッチオーバーのステージ
スイッチオーバーを実行するには、Amazon RDS が次のステップを実行する必要があります。
1. 元のプライマリデータベースの新しいトランザクションをブロックします。スイッチオーバー中、Amazon RDS は Oracle Data Guard 設定のすべてのデータベースのレプリケーションを中断します。スイッチオーバー中、元のプライマリデータベースは書き込み要求を処理できません。
1. 未適用のトランザクションを元のスタンバイデータベースに送り、適用します。
1. 新しいスタンバイデータベースを読み取り専用モードまたはマウントモードで再起動します。モードは、スイッチオーバー前の元のスタンバイデータベースのオープン状態によって異なります。
1. 新しいプライマリデータベースを読み取り/書き込みモードで開きます。
#### Oracle Data Guard のスイッチオーバー操作後
Amazon RDS は、プライマリデータベースとスタンバイデータベースのロールを切り替えます。アプリケーションを再接続し、その他の必要な構成を実行するのはユーザーです。
**Topics**
+ [成功基準](#oracle-replication-switchover.overview.how-it-works.after-switchover.success)
+ [新しいプライマリデータベースへの接続](#oracle-replication-switchover.overview.how-it-works.after-switchover.connection)
+ [新しいプライマリデータベースの構成](#oracle-replication-switchover.overview.how-it-works.after-switchover.success.configuration)
##### 成功基準
Oracle Data Guard のスイッチオーバーは、元のスタンバイデータベースが次の処理を実行したときに成功したと判断できます。
+ 新しいプライマリデータベースとしてのロールに移行する
+ 再構成を完了する
ダウンタイムを抑えるため、新しいプライマリデータベースはできるだけ早くアクティブになります。Amazon RDS はバイスタンダーのレプリカを非同期で設定するため、これらのレプリカは元のプライマリデータベースの後でアクティブになる可能性があります。
##### 新しいプライマリデータベースへの接続
Amazon RDS は、スイッチオーバー後、現在のデータベース接続を新しいプライマリデータベースに伝達しません。Oracle Data Guard のスイッチオーバーが完了したら、アプリケーションを新しいプライマリデータベースに再接続します。
##### 新しいプライマリデータベースの構成
新しいプライマリデータベースへのスイッチオーバーを実行するために、Amazon RDS は元のスタンバイデータベースのモードをオープンに変更します。ロールの変更がデータベースの唯一の変更です。Amazon RDS によって Multi-AZ レプリケーションなどの機能は設定されません。
オプションが異なるクロスリージョンレプリカへのスイッチオーバーを実行しても、新しいプライマリデータベースでは独自のオプションが保持されます。Amazon RDS は元のプライマリデータベースのオプションを移行しません。元のプライマリデータベースで SSL、NNE、OEM、OEM\$1AGENT などのオプションが指定されている場合も、Amazon RDS はそれらを新しいプライマリデータベースに伝達しません。
# Oracle Data Guard のスイッチオーバーの要件
Oracle Data Guard のスイッチオーバーを開始する前に、レプリケーション環境が次の要件を満たしていることを確認します。
+ 元のスタンバイデータベースがマウントされているか、読み取り専用で開かれている。
+ 元のスタンバイデータベースで自動バックアップが有効になっている。
+ 元のプライマリデータベースと元のスタンバイデータベースが `available` 状態である。
+ 元のプライマリデータベースと元のスタンバイデータベースに、`required`、`next window`、または `in progress` 状態の保留中のメンテナンスアクションがない。これらの状態のアクションはスイッチオーバーをブロックします。保留中のメンテナンス更新のステータスを確認する方法については、「[保留中のメンテナンス更新の表示](USER_UpgradeDBInstance.Maintenance.md#USER_UpgradeDBInstance.Maintenance.Viewing)」を参照してください。
保留中のメンテナンスアクションが `available` 状態の場合は、スイッチオーバーをブロックしません。RDS for Oracle は、オペレーティングシステム (OS) の更新を `available` 状態で頻繁にリリースします。これらの保留中の OS 更新は、次回のメンテナンスウィンドウにスケジュールして `next window` 状態にしない限り、スイッチオーバーをブロックしません。
**注記**
スケジュールされたメンテナンスアクションを延期してスイッチオーバーを実行できるようにする場合は、RDS コンソールで **[アクション]**、**[アップグレードを延期]** の順に選択します。スイッチオーバーがブロックされないようにするには、保留中のメンテナンスアクションを適用するか、メンテナンスウィンドウをスイッチオーバー前の間隔に移動することもできます。詳細については、re:Post の記事「[How to remove RDS pending maintenance items](https://repost.aws/questions/QUV3dBjmVVRnmVV1pAlzjx1w/how-to-remove-rds-pending-maintenance-item)」を参照してください。
+ 元のスタンバイデータベースがレプリケーション状態である。
+ プライマリデータベースまたはスタンバイデータベースのいずれかがスイッチオーバーライフサイクルで、現在スイッチオーバーを開始しようとしていない。スイッチオーバー後にレプリカデータベースの再構成中、Amazon RDS は別のスイッチオーバーを開始できないようにします。
**注記**
*バイスタンダーのレプリカ*とは、スイッチオーバーの対象ではない Oracle Data Guard 構成のレプリカです。バイスタンダーのレプリカは、スイッチオーバー時、どのような状態でもかまいません。
+ 元のスタンバイデータベースが、元のプライマリデータベースの構成と希望に近い構成になっている。元のプライマリデータベースと元のスタンバイデータベースでオプションが異なるシナリオを想定します。スイッチオーバーが完了しても、Amazon RDS では、新しいプライマリデータベースを元のプライマリデータベースと同じオプションで自動的には再設定しません。
+ 切り替えを開始する前に、目的のマルチ AZ 配置を設定します。Amazon RDS では、切り替えの一環としてマルチ AZ を管理しません。マルチ AZ 配置はそのままになります。
db\$1maz がマルチ AZ 配置のプライマリデータベースで、db\$1saz がシングル AZ レプリカであると仮定します。db\$1maz から db\$1saz への切り替えを開始します。その後、db\$1maz はマルチ AZ レプリカデータベースになり、db\$1saz はシングル AZ プライマリデータベースになります。これで、新しいプライマリデータベースは マルチ AZ 配置によって保護されなくなりました。
+ クロスリージョンの切り替えに備え、プライマリデータベースはレプリケーション設定以外の DB インスタンスと同じオプショングループを使用しません。クロスリージョンの切り替えを正常に行うには、現在のプライマリデータベースとそのリードレプリカが、現在のプライマリデータベースのオプショングループを使用する DB インスタンスのみである必要があります。そうではない場合、Amazon RDS が切り替えを妨げます。
# Oracle Data Guard のスイッチオーバーの開始
RDS for Oracle リードレプリカをプライマリロールに切り替え、以前のプライマリ DB インスタンスをレプリカロールに切り替えることができます。
## コンソール
**Oracle リードレプリカをプライマリ DB ロールに切り替えるには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. Amazon RDS コンソールで、[**Databases (データベース)**] を選択します。
[**Databases (データベース)**] ペインが表示されます。各リードレプリカには､[**Role (ロール)**] 列に [**Replica (レプリカ)**] があります｡
1. プライマリロールに切り替えるリードレプリカを選択します。
1. **[Actions]** (アクション) で、**[Switch over replica]** (レプリカを切り替える) を選択します。
1. **[I acknowledge]** (承認します) を選択します。次に、**[Switch over replica]** (レプリカを切り替える) を選択します。
1. **[Databases]** (データベース) ページで、スイッチオーバーの進行状況をモニタリングします。
![\[Oracle Data Guard のスイッチオーバーの進行状況をモニタリングする\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/oracle-switchover-progress.png)
スイッチオーバーが完了すると、ターゲットのロールが**レプリカ**から**ソース**に変わります。
![\[ソースデータベースとレプリカデータベースのロールが変更されます。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/oracle-switchover-complete.png)
## AWS CLI
Oracle レプリカをプライマリ DB ロールに切り替えるには、AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/switchover-read-replica.html](https://docs.aws.amazon.com/cli/latest/reference/rds/switchover-read-replica.html) コマンドを使用します。次の例では、*replica-to-be-made-primary* という名前の Oracle レプリカを新しいプライマリデータベースに切り替えます。
**Example**
Linux、macOS、Unix の場合:
```
aws rds switchover-read-replica \
--db-instance-identifier replica-to-be-made-primary
```
Windows の場合:
```
aws rds switchover-read-replica ^
--db-instance-identifier replica-to-be-made-primary
```
## RDS API
Oracle レプリカをプライマリ DB ロールに切り替えるには、必須パラメータ `DBInstanceIdentifier` を使用して、Amazon RDS API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_SwitchoverReadReplica.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_SwitchoverReadReplica.html) 操作を呼び出します。このパラメータは、プライマリ DB ロールを継承する Oracle レプリカの名前を指定します。
# Oracle Data Guard のスイッチオーバーのモニタリング
インスタンスの状態を確認するには、AWS CLI コマンド `describe-db-instances` を使用します。次のコマンドでは、DB インスタンス *orcl2* のステータスをモニタリングします。このデータベースは、スイッチオーバー前はスタンバイデータベースでしたが、スイッチオーバー後は新しいプライマリデータベースになります。
```
aws rds describe-db-instances \
--db-instance-identifier orcl2
```
スイッチオーバーが正常に完了したことを確認するには、`V$DATABASE.OPEN_MODE` のクエリを実行します。新しいプライマリデータベースの値が `READ WRITE` であることを確認します。
```
SELECT OPEN_MODE FROM V$DATABASE;
```
スイッチオーバー関連のイベントを検索するには、AWS CLI コマンド `describe-events` を使用します。次の例では、*orcl2* インスタンスのイベントを検索します。
```
aws rds describe-events \
--source-identifier orcl2 \
--source-type db-instance
```
# RDS for Oracle レプリカのトラブルシューティング
このセクションでは、レプリケーションに関する潜在的な問題と解決策について説明します。
**Topics**
+ [Oracle レプリケーションラグのモニタリング](#oracle-read-replicas.troubleshooting.lag)
+ [トリガーを追加または変更した後の Oracle レプリケーションの失敗をトラブルシューティングする](#oracle-read-replicas.troubleshooting.triggers)
## Oracle レプリケーションラグのモニタリング
Amazon CloudWatch のレプリケーションラグをモニタリングするには、Amazon RDS `ReplicaLag` メトリクスを表示します。レプリケーションのラグタイムについては、「[リードレプリケーションのモニタリング](USER_ReadRepl.Monitoring.md)」および「[Amazon RDS の Amazon CloudWatch メトリクス](rds-metrics.md)」を参照してください。
リードレプリカのラグタイムが長すぎる場合は、次のビューをクエリします。
+ `V$ARCHIVED_LOG` - リードレプリカに適用されたコミットが表示されます。
+ `V$DATAGUARD_STATS` - `ReplicaLag` メトリクスを占めるコンポーネントの詳細を示します。
+ `V$DATAGUARD_STATUS` - Oracle の内部レプリケーションプロセスのログ出力を示します。
マウントされたレプリカの場合、ラグタイムが長すぎる場合は、`V$` ビューをクエリすることができません。代わりに、以下の手順を実行します。
+ CloudWatch で `ReplicaLag` メトリクスをチェックします。
+ コンソールでレプリカのアラートログファイルを確認します。回復メッセージでエラーを探します。メッセージにはログシーケンス番号が記載されていて、これをプライマリシーケンス番号と比較できます。(詳しくは、「[Amazon RDS for Oracle データベースのログファイル](USER_LogAccess.Concepts.Oracle.md)」を参照してください。)
## トリガーを追加または変更した後の Oracle レプリケーションの失敗をトラブルシューティングする
トリガーを追加または変更し、その後レプリケーションが失敗した場合は、問題はトリガーにある可能性があります。トリガーで、レプリケーションから RDS で必要な次のユーザーアカウントが除外されていることを確認します。
+ 管理者権限を持つユーザーアカウント
+ `SYS`
+ `SYSTEM`
+ `RDS_DATAGUARD`
+ `rdsdb`
(詳しくは、「[RDS for Oracle レプリカに関するその他の考慮事項](oracle-read-replicas.limitations.md#oracle-read-replicas.limitations.miscellaneous)」を参照してください。)
# RDS for Oracle を使用した REDO トランスポート圧縮
RDS for Oracle REDO トランスポート圧縮を使用して、プライマリ DB インスタンスとスタンバイレプリカ間のレプリケーションパフォーマンスを向上させます。これは、ネットワーク帯域幅が限られている環境や高レイテンシーの接続で特に役立ちます。
## REDO トランスポート圧縮のライセンスの取得
REDO トランスポート圧縮は、[Oracle Advanced Compression](//www.oracle.com/database/advanced-compression/) オプションの一部です。REDO トランスポート圧縮を使用するには、Oracle Advanced Compression オプションの有効なライセンスが必要です。ライセンス情報については、Oracle の担当者にお問い合わせください。
## REDO トランスポート圧縮の設定
REDO トランスポート圧縮を設定するには、`rds.replica.redo_compression` パラメータを使用できます。このパラメータは、Oracle バージョン 19c および 21c で使用できます。
`rds.replica.redo_compression` パラメータには、次の値を指定できます。
+ `DISABLE` – REDO トランスポート圧縮を無効にするデフォルト値。
+ `ENABLE` – デフォルトのアルゴリズム [ZLIB](https://zlib.net/) による REDO トランスポート圧縮を有効にする値。
+ `ZLIB` – ZLIB アルゴリズムを使用して REDO トランスポート圧縮を明示的に有効にする値。これにより、圧縮率が向上します。
+ `LZO` – 特に解凍中に圧縮速度を最適化する [LZO](https://www.oberhumer.com/opensource/lzo/) アルゴリズムを使用して、REDO トランスポート圧縮を明示的に有効にする値。
## REDO トランスポート圧縮のパフォーマンスに関する考慮事項
圧縮および解凍オペレーションは、プライマリインスタンスとスタンバイインスタンスの両方で CPU リソースを消費します。REDO トランスポート圧縮を使用する場合は、インスタンスリソースの使用状況とネットワーク条件を考慮してください。
## REDO トランスポート圧縮に関連するトピック
REDO トランスポート圧縮の設定の詳細については、次のリソースを参照してください。
+ [Amazon RDS DB インスタンスの DB パラメータグループ](USER_WorkingWithDBInstanceParamGroups.md)
+ Oracle Database 19c リリースノートの「[RedoCompression](https://docs.oracle.com/en/database/oracle/oracle-database/19/dgbkr/oracle-data-guard-broker-properties.html#GUID-5E6DDFD0-6196-48EB-94AF-21A1AFBB7DE1)」
# Oracle DB インスタンスへのオプションの追加
Amazon RDS では、オプションは追加機能です。次に、OracleDB エンジンを実行している Amazon RDS インスタンスに追加できるオプションの説明を示します。
**Topics**
+ [Oracle DB オプションの概要](Appendix.Oracle.Options.overview.md)
+ [「Amazon S3 統合」](oracle-s3-integration.md)
+ [Oracle Application Express (APEX)](Appendix.Oracle.Options.APEX.md)
+ [Amazon EFS の統合](oracle-efs-integration.md)
+ [Oracle Java Virtual Machine](oracle-options-java.md)
+ [Oracle Enterprise Manager](Oracle.Options.OEM.md)
+ [Oracle Label Security](Oracle.Options.OLS.md)
+ [Oracle Locator](Oracle.Options.Locator.md)
+ [Oracle ネイティブネットワーク暗号化](Appendix.Oracle.Options.NetworkEncryption.md)
+ [Oracle OLAP](Oracle.Options.OLAP.md)
+ [Oracle Secure Sockets Layer](Appendix.Oracle.Options.SSL.md)
+ [Oracle Spatial](Oracle.Options.Spatial.md)
+ [Oracle SQLT](Oracle.Options.SQLT.md)
+ [Oracle Statspack](Appendix.Oracle.Options.Statspack.md)
+ [Oracle のタイムゾーン](Appendix.Oracle.Options.Timezone.md)
+ [Oracle のタイムゾーンファイルの自動アップグレード](Appendix.Oracle.Options.Timezone-file-autoupgrade.md)
+ [Oracle Transparent Data Encryption](Appendix.Oracle.Options.AdvSecurity.md)
+ [Oracle UTL\$1MAIL](Oracle.Options.UTLMAIL.md)
+ [Oracle XML DB](Appendix.Oracle.Options.XMLDB.md)
# Oracle DB オプションの概要
Oracle Database のオプションを有効にするには、オプショングループにオプションを追加してから、そのオプショングループを DB インスタンスに関連付けます。(詳しくは、「[オプショングループを使用する](USER_WorkingWithOptionGroups.md)」を参照してください。)
**Topics**
+ [Oracle Database オプションの概要](#Appendix.Oracle.Options.summary)
+ [異なるエディションでサポートされるオプション](#Appendix.Oracle.Options.editions)
+ [特定のオプションのメモリ要件](#Appendix.Oracle.Options.memory)
## Oracle Database オプションの概要
Oracle DB インスタンスには次のオプションを追加できます。
****
| オプション | オプション ID |
| --- | --- |
| [「Amazon S3 統合」](oracle-s3-integration.md) | `S3_INTEGRATION` |
| [Oracle Application Express (APEX)](Appendix.Oracle.Options.APEX.md) | `APEX` `APEX-DEV` |
| [Oracle Enterprise Manager](Oracle.Options.OEM.md) | `OEM` `OEM_AGENT` |
| [Oracle Java Virtual Machine](oracle-options-java.md) | `JVM` |
| [Oracle Label Security](Oracle.Options.OLS.md) | `OLS` |
| [Oracle Locator](Oracle.Options.Locator.md) | `LOCATOR` |
| [Oracle ネイティブネットワーク暗号化](Appendix.Oracle.Options.NetworkEncryption.md) | `NATIVE_NETWORK_ENCRYPTION` |
| [Oracle OLAP](Oracle.Options.OLAP.md) | `OLAP` |
| [Oracle Secure Sockets Layer](Appendix.Oracle.Options.SSL.md) | `SSL` |
| [Oracle Spatial](Oracle.Options.Spatial.md) | `SPATIAL` |
| [Oracle SQLT](Oracle.Options.SQLT.md) | `SQLT` |
| [Oracle Statspack](Appendix.Oracle.Options.Statspack.md) | `STATSPACK` |
| [Oracle のタイムゾーン](Appendix.Oracle.Options.Timezone.md) | `Timezone` |
| [Oracle のタイムゾーンファイルの自動アップグレード](Appendix.Oracle.Options.Timezone-file-autoupgrade.md) | `TIMEZONE_FILE_AUTOUPGRADE` |
| [Oracle Transparent Data Encryption](Appendix.Oracle.Options.AdvSecurity.md) | `TDE` |
| [Oracle UTL\$1MAIL](Oracle.Options.UTLMAIL.md) | `UTL_MAIL` |
| [Oracle XML DB](Appendix.Oracle.Options.XMLDB.md) | `XMLDB` |
## 異なるエディションでサポートされるオプション
RDS for Oracle では、サポートされていないエディションにオプションを追加できません。さまざまな Oracle Database エディションでサポートされている RDS オプションを確認するには、`aws rds describe-option-group-options` コマンドを使用します。次の例は、Oracle Database 19c エンタープライズエディションでサポートされているオプションを一覧表示しています。
```
aws rds describe-option-group-options \
--engine-name oracle-ee \
--major-engine-version 19
```
詳細については、*AWS CLI コマンドリファレンス*の [describe-option-group-options](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-option-group-options.html) を参照してください。
## 特定のオプションのメモリ要件
一部のオプションは、DB インスタンスで実行するために追加のメモリが必要です。例えば、Oracle Enterprise Manager Database Control には約 300 MB の RAM が使用されます。サイズの小さい DB インスタンスに対してこのオプションを有効にした場合は、パフォーマンスの問題やメモリ不足のエラーが発生することがあります。データベースの RAM 使用量を少なくするために、Oracle パラメータを調整できます。また、より大きな DB インスタンスにスケールアップすることもできます。
# 「Amazon S3 統合」
RDS for Oracle DB インスタンスと Amazon S3 バケットの間でファイルを転送することができます。Oracle Data Pump などの Oracle Database の機能と Amazon S3 統合を使用できます。例えば、Amazon S3 の Data Pump ファイルを RDS for Oracle DB インスタンスにダウンロードすることができます。詳細については、「[Amazon RDS の Oracle にデータをインポートする](Oracle.Procedural.Importing.md)」を参照してください。
**注記**
DB インスタンスと Amazon S3 バケットは同じ AWS リージョン に存在する必要があります。
**Topics**
+ [Amazon S3 と RDS for Oracle を統合する IAM アクセス許可の設定](oracle-s3-integration.preparing.md)
+ [Amazon S3 統合オプションの追加](oracle-s3-integration.preparing.option-group.md)
+ [Amazon RDS for Oracle と Amazon S3 バケットの間でファイルを転送する](oracle-s3-integration.using.md)
+ [Amazon S3 統合のトラブルシューティング](#oracle-s3-integration.troubleshooting)
+ [Amazon S3 統合オプションの削除](oracle-s3-integration.removing.md)
# Amazon S3 と RDS for Oracle を統合する IAM アクセス許可の設定
RDS for Oracle が Amazon S3 と統合するには、DB インスタンスが Amazon S3 バケットにアクセスできる必要があります。DB インスタンスで使用される Amazon VPC は Amazon S3 エンドポイントへのアクセスを提供する必要はありません。
RDS for Oracle は、あるアカウントの DB インスタンスと別のアカウントの Amazon S3 バケットの間のファイルの転送をサポートしています。追加のステップが必要な場合は、以下のセクションで説明します。
**Topics**
+ [ステップ 1: Amazon RDS ロール用の IAM ポリシーを作成する](#oracle-s3-integration.preparing.policy)
+ [ステップ 2: (オプション) Amazon S3 バケットの IAM ポリシーを作成する](#oracle-s3-integration.preparing.policy-bucket)
+ [ステップ 3: DB インスタンスの IAM ロールを作成し、ポリシーをアタッチする](#oracle-s3-integration.preparing.role)
+ [ステップ 4: IAM ロールを RDS for Oracle DB インスタンスに関連付ける](#oracle-s3-integration.preparing.instance)
## ステップ 1: Amazon RDS ロール用の IAM ポリシーを作成する
このステップでは、Amazon S3 バケットと RDS DB インスタンスの間のファイル転送に必要なアクセス許可を持つ AWS Identity and Access Management (IAM) ポリシーを作成します。このステップは、S3 バケットが既に作成されていることを前提としています。
ポリシーを作成する前に、次の情報を書き留めます。
+ バケットの Amazon リソースネーム (ARN)
+ お客様の AWS KMS キーの ARN、バケットが SSE-KMS または SSE-S3 暗号化を使用している場合
**注記**
RDS for Oracle DB インスタンスは、SSE-C で暗号化された Amazon S3 バケットにアクセスできません。
詳細については、「*Amazon Simple Storage Service ユーザーガイド*」の「[サーバー側の暗号化を使用したデータの保護](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html)」を参照してください。
### コンソール
**Amazon S3 バケットへのアクセスを Amazon RDS に許可する IAM ポリシーを作成するには**
1. [IAM マネジメントコンソール](https://console.aws.amazon.com/iam/home?#home)を開きます。
1. [**Access management (アクセス管理)**] で、[**Policies (ポリシー)**] を選択します。
1. **[ポリシーを作成]** を選択します。
1. [**Visual editor**] タブで、[**Choose a service**] を選択し、[**S3**] を選択します。
1. [**Actions (アクション)**] で [**Expand all (すべて展開)**] を選択し、Amazon S3 バケットから Amazon RDS にファイルを転送するために必要なバケットのアクセス許可とオブジェクトのアクセス許可を選択します。例えば、以下を実行してください。
+ [**List (リスト)**] を展開し、[**ListBucket**] を選択します。
+ [**Read (読み取り)**] を展開し、[**GetObject**] を選択します。
+ **[Write (書き込み)]** を展開し、**[PutObject]**、**[DeleteObject]**、**[AbortMultipartUpload]**、**[ListMultipartUploadParts]** を選択します。マルチパートアップロードのアクセス許可は、大きなファイル (100 MB 以上) を Amazon S3 にアップロードするときに必要です。
+ **[Permissions management]** (アクセス許可の管理) を展開し、**PutObjectAcl** を選択します。このアクセス許可は、別のアカウントが所有するバケットにファイルをアップロードする予定で、このアカウントがバケットの内容を完全に制御する必要がある場合に必要です。
*オブジェクトのアクセス許可*は、Amazon S3 のオブジェクトオペレーションのアクセス許可です。バケット自体ではなくバケット内のオブジェクトに付与する必要があります。詳細については、「[オブジェクトオペレーションに対するアクセス許可](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-with-s3-actions.html#using-with-s3-actions-related-to-objects)」を参照してください。
1. **[リソース]** を選択し、次の操作を行います。
1. **[特定]** を選択します。
1. **[バケット]** では、**[ARN を追加]** を選択します。バケット ARN を入力します。バケット名は自動的に入力されます。その後、**[Add]** (追加) を選択します。
1. **[オブジェクト]** リソースが表示されている場合は、**[ARN を追加]** を選択してリソースを手動で追加するか、**[すべて]** を選択します。
**注記**
Amazon S3 バケット内の特定のファイルやフォルダにのみアクセスすることを Amazon RDS に許可するには、[**Amazon リソースネーム (ARN)**] に、より具体的な ARN 値を設定します。Amazon S3 のアクセスポリシーの定義方法については、「[Amazon S3 リソースへのアクセス許可の管理](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html)」を参照してください。
1. (オプション) ポリシーにリソースを追加するには、[**Add addition permissions (アクセス許可を追加する)**] を選択します。例えば、以下を実行してください。
1. バケットがカスタム KMS キーで暗号化されている場合は、サービスの **KMS** を選択します。
1. **[手動アクション]** では、以下を選択します。
+ **暗号化**
+ **[ReEncrypt from]** および **[ReEncrypt to]**
+ **Decrypt**
+ **DescribeKey**
+ **GenerateDataKey**
1. **[リソース]** で **[特定]** を選択します。
1. **[キー]** では、**[ARN を追加]** を選択します。リソースとしてカスタムキーの ARN を入力し、**[追加]** を選択します。
詳細については、*Amazon Simple Storage Service ユーザーガイド*の「[Protecting Data Using Server-Side Encryption with KMS keys Stored in AWS Key Management Service (SSE-KMS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html)」を参照してください。
1. Amazon RDS が他のバケットにアクセスするためにアクセスが必要な場合は、これらのバケットの ARN を追加します。オプションで、Amazon S3 内のすべてのバケットとオブジェクトへのアクセスを許可できます。
1. [**次へ: タグ**]、[**次へ: レビュー**] の順に選択します。
1. [** 名前**] に、IAM ポリシーの名前 (例: `rds-s3-integration-policy`) を設定します。この名前は、IAM ロールを作成して DB インスタンスに関連付ける際に使用します。オプションで [**Description**] 値を追加することもできます。
1. [**Create policy**] (ポリシーの作成) を選択します。
### AWS CLI
Amazon S3 バケットに Amazon RDS へのアクセス許可を付与する AWS Identity and Access Management IAM ポリシーを作成します。ポリシーを作成したら、ポリシーの ARN を書き留めます。この ARN は、後のステップで必要になります。
必要なアクセスのタイプに基づき、適切なアクションをポリシーに含めます。
+ `GetObject` - Amazon S3 バケットから Amazon RDS へのファイルの転送に必要。
+ `ListBucket` - Amazon S3 バケットから Amazon RDS へのファイルの転送に必要。
+ `PutObject` - Amazon RDS から Amazon S3 バケットへのファイルの転送に必要。
+ `AbortMultipartUpload` – マルチパートアップロードで、大きなファイル (100 MB 以上) を Amazon RDS から Amazon S3 バケットに転送するときに必要です。
+ `ListMultipartUploadParts` – マルチパートアップロードで、大きなファイル (100 MB 以上) を Amazon RDS から Amazon S3 バケットに転送するときに必要です。
以下の AWS CLI コマンドでは、これらのオプションを指定して、`rds-s3-integration-policy` という名前の IAM ポリシーを作成します。このポリシーでは、`amzn-s3-demo-bucket` という名前のバケットへのアクセス権が付与されます。
**Example**
Linux、macOS、Unix の場合:
```
aws iam create-policy \
--policy-name rds-s3-integration-policy \
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3integration",
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:PutObject",
"s3:AbortMultipartUpload",
"s3:ListMultipartUploadParts"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}'
```
次の例には、カスタム KMS キーのアクセス許可が含まれています。
```
aws iam create-policy \
--policy-name rds-s3-integration-policy \
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3integration",
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:PutObject",
"kms:Decrypt",
"kms:Encrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey",
"kms:DescribeKey",
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*",
"arn:aws:kms:::your-kms-arn"
]
}
]
}'
```
Windows の場合:
```
aws iam create-policy ^
--policy-name rds-s3-integration-policy ^
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3integration",
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:PutObject",
"s3:AbortMultipartUpload",
"s3:ListMultipartUploadParts"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}'
```
次の例には、カスタム KMS キーのアクセス許可が含まれています。
```
aws iam create-policy ^
--policy-name rds-s3-integration-policy ^
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3integration",
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:PutObject",
"kms:Decrypt",
"kms:Encrypt",
"kms:ReEncrypt",
"kms:GenerateDataKey",
"kms:DescribeKey",
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*",
"arn:aws:kms:::your-kms-arn"
]
}
]
}'
```
## ステップ 2: (オプション) Amazon S3 バケットの IAM ポリシーを作成する
このステップは、次の条件でのみ必要です。
+ あるアカウント (アカウント A) から Amazon S3 バケットにファイルをアップロードし、別のアカウント (アカウント B) からファイルにアクセスする予定です。
+ アカウント B がバケットを所有しています。
+ アカウント B は、バケットにロードされたオブジェクトを完全に制御する必要があります。
上記の条件が適用されない場合は、[ステップ 3: DB インスタンスの IAM ロールを作成し、ポリシーをアタッチする](#oracle-s3-integration.preparing.role) に進みます。
バケットポリシーを作成するために、以下のものがあることを確認します。
+ アカウント A のアカウント ID
+ アカウント A のユーザー名
+ アカウント B の Amazon S3 バケットの ARN 値
### コンソール
**バケットポリシーを作成または編集するには**
1. AWS マネジメントコンソール にサインインし、Amazon S3 コンソール ([https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)) を開きます。
1. [**Buckets (バケット)**] リストで、バケットポリシーを作成するバケットの名前、またはバケットポリシーを編集するバケットの名前を選択します。
1. [**Permissions (アクセス許可)**] を選択します。
1. **[バケットポリシー]** で **[編集]** を選択します。バケットポリシーの編集ページが開きます。
1. **[バケットポリシーを編集]** ページで、「*Amazon S3 ユーザーガイド*」の **[ポリシーの例]** を確認するか、**[ポリシージェネレーター]** を選択してポリシーを自動的に生成するか、**[ポリシー]** セクションで JSON を編集します。
**ポリシージェネレーター**を選択すると、AWS ポリシージェネレーターが新しいウィンドウで開きます。
1. **ポリシーの種類の選択**の **AWS ポリシーポリシージェネレータ**ページで、** S3 バケットポリシー**を選択します。
1. 提供されたフィールドに情報を入力してステートメントを追加し、**ステートメントの追加**を選択します。追加するステートメントの数だけ繰り返します。ポリシーステートメントの詳細については、*IAM ユーザーガイド*の [IAM JSON ポリシーのエレメントのリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)を参照してください。
**注記**
便宜上、**バケットポリシーの編集**ページでは、現在のバケットの**バケット ARN** (Amazonリソース名) が**ポリシー**テキストフィールドの上に表示されます。この ARN をコピーして、**AWSポリシージェネレータ**のステートメントで使用できます。
1. ステートメントの追加が完了したら、**ポリシーの生成**を選択します。
1. 生成されたポリシーテキストをコピーし、[**閉じる**] を選択すると、Amazon S3 コンソールの**バケットポリシーの編集**ページに戻ります。
1. 左 **ポリシー** ボックスで、既存のポリシーを編集するか、ポリシージェネレータからバケットポリシーを貼り付けます。ポリシーを保存する前に、セキュリティ警告、エラー、一般的な警告、および提案を解決してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ExamplePermissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/account-A-user"
},
"Action": [
"s3:PutObject",
"s3:PutObjectAcl"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-destination-bucket",
"arn:aws:s3:::amzn-s3-demo-destination-bucket/*"
]
}
]
}
```
------
1. **変更の保存**を選択すると、[バケット許可] のページへ戻ります。
## ステップ 3: DB インスタンスの IAM ロールを作成し、ポリシーをアタッチする
このステップは、IAM ポリシーを [ステップ 1: Amazon RDS ロール用の IAM ポリシーを作成する](#oracle-s3-integration.preparing.policy) で作成したことを前提としています。このステップでは、RDS for Oracle DB インスタンスのロールを作成し、ロールにポリシーをアタッチします。
### コンソール
**Amazon S3 バケットへのアクセスを Amazon RDS に許可する IAM ロールを作成するには**
1. [IAM マネジメントコンソール](https://console.aws.amazon.com/iam/home?#home)を開きます。
1. ナビゲーションペインで **Roles (ロール) ** を選択してください。
1. [**ロールの作成**] を選択してください。
1. **[AWS サービス]** を選択してください。
1. **[他の AWS サービスのユースケース]** で、**[RDS]** を選択し、次に **[RDS — データベースにロールを追加]** を選択します。次に、**[次へ]** を選択します。
1. **[アクセス許可ポリシー]** の **[検索]** に、[ステップ 1: Amazon RDS ロール用の IAM ポリシーを作成する](#oracle-s3-integration.preparing.policy) で作成した IAM ポリシーの名前を入力し、リストに表示されたポリシーを選択します。次に、**[次へ]** を選択します。
1. **[ロール名]** に、`rds-s3-integration-role` などの IAM ロール名を入力します。オプションで [**Description**] 値を追加することもできます。
1. [**ロールの作成**] を選択してください。
### AWS CLI
**ロールを作成してポリシーをアタッチするには**
1. Amazon S3 バケットにアクセスするには、お客様に代わって Amazon RDS が引き受けることのできる IAM ロールを作成します。
リソースベースの信頼関係では [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) を使用します。
次の AWS CLI コマンドでは、この目的で `rds-s3-integration-role` という名前のロールを作成します。
**Example**
Linux、macOS、Unix の場合:
```
aws iam create-role \
--role-name rds-s3-integration-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "my_account_ID",
"aws:SourceArn": "arn:aws:rds:Region:my_account_ID:db:dbname"
}
}
}
]
}'
```
Windows の場合:
```
aws iam create-role ^
--role-name rds-s3-integration-role ^
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "my_account_ID",
"aws:SourceArn": "arn:aws:rds:Region:my_account_ID:db:dbname"
}
}
}
]
}'
```
詳細については、*IAM ユーザーガイド*の「[IAM ユーザーにアクセス許可を委任するロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)」を参照してください。
1. ロールが作成されたら、このロールの ARN を書き留めます。この ARN は、後のステップで必要になります。
1. 作成したポリシーを、作成したロールにアタッチします。
以下の AWS CLI コマンドでは、`rds-s3-integration-role` という名前のロールにこのポリシーをアタッチします。
**Example**
Linux、macOS、Unix の場合:
```
aws iam attach-role-policy \
--policy-arn your-policy-arn \
--role-name rds-s3-integration-role
```
Windows の場合:
```
aws iam attach-role-policy ^
--policy-arn your-policy-arn ^
--role-name rds-s3-integration-role
```
`your-policy-arn` を、以前のステップで書き留めたポリシー ARN に置き換えます。
## ステップ 4: IAM ロールを RDS for Oracle DB インスタンスに関連付ける
Amazon S3 統合のアクセス許可を設定する最後のステップは、IAM ロールを DB インスタンスに関連付けることです。次の要件に注意してください。
+ 必須の Amazon S3 アクセス許可ポリシーがアタッチされた IAM ロールへのアクセスが許可されている必要があります。
+ RDS for Oracle DB インスタンスには、一度に 1 つの IAM ロールのみを関連付けることができます。
+ DB インスタンスは、**[使用可能]** の状態である必要があります。
### コンソール
**IAM ロールを RDS for Oracle DB インスタンスに関連付けるには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインから [**Databases (データベース)**] を選択します。
1. 詳細を表示する RDS for Oracle DB インスタンスの名前を選択します。
1. 「**接続性とセキュリティ**」 タブで、ページ下部の**IAM ロールを管理する** セクションまでスクロールダウンします。
1. **[このインスタンスに IAM ロールを追加]** で、[ステップ 3: DB インスタンスの IAM ロールを作成し、ポリシーをアタッチする](#oracle-s3-integration.preparing.role) で作成したロールを選択します。
1. [**機能**] で、[**S3\$1INTEGRATION**] を選択します。
![\[S3_INTEGRATION ロールの追加\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/ora-s3-integration-role.png)
1. [**Add role**] を選択します。
### AWS CLI
以下の AWS CLI コマンドでは、`mydbinstance` という名前の Oracle DB インスタンスにこのロールを追加します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds add-role-to-db-instance \
--db-instance-identifier mydbinstance \
--feature-name S3_INTEGRATION \
--role-arn your-role-arn
```
Windows の場合:
```
aws rds add-role-to-db-instance ^
--db-instance-identifier mydbinstance ^
--feature-name S3_INTEGRATION ^
--role-arn your-role-arn
```
`your-role-arn` を、以前のステップで書き留めたロール ARN に置き換えます。`S3_INTEGRATION` オプションには `--feature-name` が指定されている必要があります。
# Amazon S3 統合オプションの追加
Amazon RDS for Oracle と Amazon S3 を統合するには、DB インスタンスが `S3_INTEGRATION` オプションを含むオプショングループに関連付けられている必要があります。
## コンソール
**Amazon S3 統合用のオプショングループを設定するには**
1. 新しいオプショングループを作成するか、`S3_INTEGRATION` オプションを追加する既存のオプショングループを識別します。
オプショングループの作成の詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
1. オプショングループに [`S3_INTEGRATION`] オプションを追加します。
オプショングループへのオプションの追加の詳細については、「[オプショングループにオプションを追加する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption)」を参照してください。
1. 新しい RDS for Oracle DB インスタンスを作成し、オプショングループをそのインスタンスに関連付けるか、オプショングループを関連付けるように RDS for Oracle DB インスタンスを変更します。
DB インスタンスの作成については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
DB インスタンスの変更については、[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)を参照してください。
## AWS CLI
**Amazon S3 統合用のオプショングループを設定するには**
1. 新しいオプショングループを作成するか、`S3_INTEGRATION` オプションを追加する既存のオプショングループを識別します。
オプショングループの作成の詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
1. オプショングループに [`S3_INTEGRATION`] オプションを追加します。
例えば、以下の AWS CLI コマンドでは、`S3_INTEGRATION` オプションを、**myoptiongroup** という名前のオプショングループに追加します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds add-option-to-option-group \
--option-group-name myoptiongroup \
--options OptionName=S3_INTEGRATION,OptionVersion=1.0
```
Windows の場合:
```
aws rds add-option-to-option-group ^
--option-group-name myoptiongroup ^
--options OptionName=S3_INTEGRATION,OptionVersion=1.0
```
1. 新しい RDS for Oracle DB インスタンスを作成し、オプショングループをそのインスタンスに関連付けるか、オプショングループを関連付けるように RDS for Oracle DB インスタンスを変更します。
DB インスタンスの作成については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
RDS for Oracle DB インスタンスの変更方法については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
# Amazon RDS for Oracle と Amazon S3 バケットの間でファイルを転送する
RDS for Oracle DB インスタンスと Amazon S3 バケット間でファイルを転送するには、Amazon RDS パッケージ `rdsadmin_s3_tasks` を使用できます。アップロード時に GZIP でファイルを圧縮し、ダウンロード時に解凍することができます。
**Topics**
+ [ファイル転送の要件と制限](#oracle-s3-integration.using.reqs)
+ [RDS for Oracle DB インスタンスから Amazon S3 バケットにファイルをアップロードする](#oracle-s3-integration.using.upload)
+ [Amazon S3 バケットから Oracle DB インスタンスにファイルをダウンロードする](#oracle-s3-integration.using.download)
+ [ファイル転送のステータスをモニタリングする](#oracle-s3-integration.using.task-status)
## ファイル転送の要件と制限
DB インスタンスと Amazon S3 バケットの間でファイルを転送する前に、次の点に注意してください。
+ `rdsadmin_s3_tasks` パッケージは、単一のディレクトリにあるファイルを転送します。転送にサブディレクトリを含めることはできません。
+ Amazon S3 バケット内の最大オブジェクトサイズは 5 TB です。
+ `rdsadmin_s3_tasks` によって作成されたタスクは非同期的に実行されます。
+ `DATA_PUMP_DIR` などの Data Pump ディレクトリ、またはユーザーが作成したディレクトリからファイルをアップロードできます。`adump`、`bdump`、または `trace` ディレクトリなど、Oracle バックグラウンドプロセスで使用されるディレクトリからファイルをアップロードすることはできません。
+ ダウンロードできるファイル数は、`download_from_s3` の場合、プロシージャコールあたり 2000 ファイルに制限されています。Amazon S3 から 2000 を超えるファイルをダウンロードする必要がある場合は、ダウンロードを別々のアクションに分割し、1 回のプロシージャコールあたりのファイル数が 2000 を超えないようにしてください。
+ ダウンロードフォルダにファイルが存在し、同じ名前のファイルをダウンロードしようとすると、`download_from_s3` ではダウンロードをスキップします。ダウンロードディレクトリからファイルを削除するには、PL/SQL プロシージャ [UTL\$1FILE.FREMOVE](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/UTL_FILE.html#GUID-09B09C2A-2C21-4F70-BF04-D0EEA7B59CAF) を使用します。
## RDS for Oracle DB インスタンスから Amazon S3 バケットにファイルをアップロードする
DB インスタンスから Amazon S3 バケットにファイルをアップロードするには、プロシージャ `rdsadmin.rdsadmin_s3_tasks.upload_to_s3` を使用します。例えば、Oracle Recovery Manager (RMAN) のバックアップファイルまたは Oracle Data Pump ファイルをアップロードすることができます。オブジェクトの操作方法の詳細については、[Amazon Simple Storage Service ユーザーガイド](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingObjects.html)を参照してください。RMAN バックアップの詳細については、「[Oracle DB インスタンスの一般的な RMAN タスクの実行](Appendix.Oracle.CommonDBATasks.RMAN.md)」を参照してください。
`rdsadmin.rdsadmin_s3_tasks.upload_to_s3` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_bucket_name` | VARCHAR2 | – | 必須 | ファイルをアップロードする Amazon S3 バケットの名前。 |
| `p_directory_name` | VARCHAR2 | – | 必須 | ファイルのアップロード元の Oracle ディレクトリオブジェクトの名前。ディレクトリは、ユーザーが作成した任意のディレクトリオブジェクト、または Data Pump ディレクトリ (例: `DATA_PUMP_DIR`) です。`adump`、`bdump`、または `trace` など、バックグラウンドプロセスで使用されるディレクトリからファイルをアップロードすることはできません。 ファイルは、指定したディレクトリからのみアップロードできます。指定したディレクトリのサブディレクトリにファイルをアップロードすることはできません。 |
| `p_s3_prefix` | VARCHAR2 | – | 必須 | ファイルをアップロードする Amazon S3 ファイル名のプレフィックス。プレフィックスが空の場合は、指定された Amazon S3 バケットの最上位レベルにすべてのファイルがアップロードされますが、そのファイル名にプレフィックスは付加されません。 例えば、プレフィックスが `folder_1/oradb` の場合、ファイルは `folder_1` にアップロードされます。この場合、ファイルにはそれぞれ `oradb` プレフィックスが追加されます。 |
| `p_prefix` | VARCHAR2 | – | 必須 | アップロードするファイル名が一致する必要があるファイル名のプレフィックス。プレフィックスが空の場合は、指定されたディレクトリ内のファイルがすべてアップロードされます。 |
| `p_compression_level` | NUMBER | `0` | オプション | GZIP 圧縮のレベル。有効な値の範囲は `0`～`9` です。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/oracle-s3-integration.using.html) |
| `p_bucket_owner_full_control` | VARCHAR2 | – | optional | バケットのアクセスコントロールリスト。有効な値は、null と `FULL_CONTROL` のみです。この設定は、あるアカウント (アカウント A) から別のアカウント (アカウント B) が所有するバケットにファイルをアップロードし、アカウント B がファイルを完全に制御する必要がある場合にのみ必要です。 |
`rdsadmin.rdsadmin_s3_tasks.upload_to_s3` プロシージャの戻り値はタスク ID です。
次の例では、`DATA_PUMP_DIR` ディレクトリ内のすべてのファイルを *amzn-s3-demo-bucket* という名前の Amazon S3 バケットにアップロードします。ファイルは圧縮されません。
```
SELECT rdsadmin.rdsadmin_s3_tasks.upload_to_s3(
p_bucket_name => 'amzn-s3-demo-bucket',
p_prefix => '',
p_s3_prefix => '',
p_directory_name => 'DATA_PUMP_DIR')
AS TASK_ID FROM DUAL;
```
次の例では、`db` ディレクトリ内のプレフィックス `DATA_PUMP_DIR` のついたすべてのファイルを、`amzn-s3-demo-bucket` という名前の Amazon S3 バケットにアップロードします。Amazon RDS は、最高レベルの GZIP 圧縮をファイルに適用します。
```
SELECT rdsadmin.rdsadmin_s3_tasks.upload_to_s3(
p_bucket_name => 'amzn-s3-demo-bucket',
p_prefix => 'db',
p_s3_prefix => '',
p_directory_name => 'DATA_PUMP_DIR',
p_compression_level => 9)
AS TASK_ID FROM DUAL;
```
次の例では、`DATA_PUMP_DIR` ディレクトリのすべてのファイルを、`amzn-s3-demo-bucket` という名前の Amazon S3 バケットにアップロードします。ファイルは、`dbfiles` フォルダにアップロードされます。この例では、GZIP 圧縮レベルは *1* です。これは最も速い圧縮レベルです。
```
SELECT rdsadmin.rdsadmin_s3_tasks.upload_to_s3(
p_bucket_name => 'amzn-s3-demo-bucket',
p_prefix => '',
p_s3_prefix => 'dbfiles/',
p_directory_name => 'DATA_PUMP_DIR',
p_compression_level => 1)
AS TASK_ID FROM DUAL;
```
次の例では、`DATA_PUMP_DIR` ディレクトリのすべてのファイルを、`amzn-s3-demo-bucket` という名前の Amazon S3 バケットにアップロードします。ファイルは `dbfiles` フォルダにアップロードされ、各ファイル名の先頭には `ora` が付加されます。圧縮は適用されません。
```
SELECT rdsadmin.rdsadmin_s3_tasks.upload_to_s3(
p_bucket_name => 'amzn-s3-demo-bucket',
p_prefix => '',
p_s3_prefix => 'dbfiles/ora',
p_directory_name => 'DATA_PUMP_DIR')
AS TASK_ID FROM DUAL;
```
次の例では、コマンドはアカウント A で実行されるものの、アカウント B でバケットの内容を完全に制御する必要があることを前提としています。コマンド `rdsadmin_s3_tasks.upload_to_s3` は、`s3bucketOwnedByAccountB` という名前のバケットに `DATA_PUMP_DIR` ディレクトリ内のすべてのファイルを転送します。アクセスコントロールは、アカウント B がバケット内のファイルにアクセスできるように、`FULL_CONTROL` に設定されています。GZIP 圧縮レベルは *6* で、速度とファイルサイズのバランスが取れています。
```
SELECT rdsadmin.rdsadmin_s3_tasks.upload_to_s3(
p_bucket_name => 's3bucketOwnedByAccountB',
p_prefix => '',
p_s3_prefix => '',
p_directory_name => 'DATA_PUMP_DIR',
p_bucket_owner_full_control => 'FULL_CONTROL',
p_compression_level => 6)
AS TASK_ID FROM DUAL;
```
それぞれの例では、`SELECT` ステートメントでは、タスクの ID が `VARCHAR2` データ型で返ります。
タスクの出力ファイルを表示すると、結果を確認できます。
```
SELECT text FROM table(rdsadmin.rds_file_util.read_text_file('BDUMP','dbtask-task-id.log'));
```
*`task-id`* は、この手順で返されたタスク ID に置き換えます。
**注記**
タスクは非同期的に実行されます。
## Amazon S3 バケットから Oracle DB インスタンスにファイルをダウンロードする
Amazon S3 バケットから RDS for Oracle インスタンスにファイルをダウンロードするには、Amazon RDS プロシージャ (`rdsadmin.rdsadmin_s3_tasks.download_from_s3`) を使用します。
`download_from_s3` プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_bucket_name` | VARCHAR2 | – | 必須 | ファイルのダウンロード元の Amazon S3 バケットの名前。 |
| `p_directory_name` | VARCHAR2 | – | 必須 | ファイルをダウンロードする Oracle ディレクトリオブジェクトの名前。ディレクトリは、ユーザーが作成した任意のディレクトリオブジェクト、または Data Pump ディレクトリ (例: `DATA_PUMP_DIR`) です。 |
| `p_error_on_zero_downloads` | VARCHAR2 | FALSE | オプションです。 | Amazon S3 バケット内のどのオブジェクトもプレフィックスと一致しない場合に、タスクによってエラーを発生させるかどうかを決定するフラグ。このパラメータが設定されていないか、FALSE (デフォルト) に設定されている場合、タスクはオブジェクトが見つからなかったというメッセージを出力しますが、例外が発生したり、エラーになったりすることはありません。このパラメータが TRUE の場合、タスクでは例外が発生し、エラーになります。 一致テストでエラーになる可能性のあるプレフィックス仕様の例としては、`' import/test9.log'` のようにプレフィックスにスペースが入るもの、または `test9.log` や `test9.LOG` のように大文字と小文字が一致しないものがあります。 |
| `p_s3_prefix` | VARCHAR2 | – | 必須 | ダウンロードするファイル名が一致する必要があるファイル名のプレフィックス。プレフィックスを空にすると、指定された Amazon S3 バケット内の最上位ファイルがすべてダウンロードされますが、バケットのフォルダ内のファイルはダウンロードされません。 この手順では、プレフィックスと一致する初期のレベルのフォルダからのみ、Amazon S3 オブジェクトをダウンロードします。指定されたプレフィックスに一致する多層のディレクトリはダウンロードされません。 例えば、Amazon S3 バケットのフォルダ構造が `folder_1/folder_2/folder_3` とします。`'folder_1/folder_2/'` プレフィックスを指定します。この場合、`folder_2` のファイルのみダウンロードされ、`folder_1` または `folder_3` のファイルはダウンロードされません。 その代わりに、`'folder_1/folder_2'` を指定する場合、`folder_1` プレフィックスに一致する、`'folder_2'` のファイルはすべてダウンロードされますが、`folder_2` のファイルはダウンロードされません。 |
| `p_decompression_format` | VARCHAR2 | – | オプションです。 | 解凍形式。有効な値は、解凍しない場合は `NONE`、解凍する場合は `GZIP` です。 |
`rdsadmin.rdsadmin_s3_tasks.download_from_s3` プロシージャの戻り値はタスク ID です。
次の例では、`amzn-s3-demo-bucket` という名前の Amazon S3 バケットのファイルをすべて、`DATA_PUMP_DIR` ディレクトリにダウンロードします。ファイルは圧縮されていないため、解凍は適用されません。
```
SELECT rdsadmin.rdsadmin_s3_tasks.download_from_s3(
p_bucket_name => 'amzn-s3-demo-bucket',
p_directory_name => 'DATA_PUMP_DIR')
AS TASK_ID FROM DUAL;
```
以下の例では、`db` という名前の Amazon S3 バケット内にある、プレフィックス `amzn-s3-demo-bucket` がついたファイルをすべて、`DATA_PUMP_DIR` ディレクトリにダウンロードします。ファイルは GZIP で圧縮されているため、解凍が適用されます。`p_error_on_zero_downloads` パラメータはプレフィックスエラーチェックを有効にするため、プレフィックスがバケット内のどのファイルとも一致しない場合、タスクでは例外が発生し、エラーになります。
```
SELECT rdsadmin.rdsadmin_s3_tasks.download_from_s3(
p_bucket_name => 'amzn-s3-demo-bucket',
p_s3_prefix => 'db',
p_directory_name => 'DATA_PUMP_DIR',
p_decompression_format => 'GZIP',
p_error_on_zero_downloads => 'TRUE')
AS TASK_ID FROM DUAL;
```
以下の例では、`myfolder/` という名前の Amazon S3 バケット内にある `amzn-s3-demo-bucket` フォルダ内のファイルをすべて、`DATA_PUMP_DIR` ディレクトリにダウンロードします。Amazon S3 フォルダを指定するには、`p_s3_prefix` パラメータを使用します。アップロードされたファイルは GZIP で圧縮されますが、ダウンロード中は解凍されません。
```
SELECT rdsadmin.rdsadmin_s3_tasks.download_from_s3(
p_bucket_name => 'amzn-s3-demo-bucket',
p_s3_prefix => 'myfolder/',
p_directory_name => 'DATA_PUMP_DIR',
p_decompression_format => 'NONE')
AS TASK_ID FROM DUAL;
```
次の例では、`DATA_PUMP_DIR` ディレクトリに `amzn-s3-demo-bucket` という名前の Amazon S3 バケット内のファイル `mydumpfile.dmp` をダウンロードします。解凍は適用されません。
```
SELECT rdsadmin.rdsadmin_s3_tasks.download_from_s3(
p_bucket_name => 'amzn-s3-demo-bucket',
p_s3_prefix => 'mydumpfile.dmp',
p_directory_name => 'DATA_PUMP_DIR')
AS TASK_ID FROM DUAL;
```
それぞれの例では、`SELECT` ステートメントでは、タスクの ID が `VARCHAR2` データ型で返ります。
タスクの出力ファイルを表示すると、結果を確認できます。
```
SELECT text FROM table(rdsadmin.rds_file_util.read_text_file('BDUMP','dbtask-task-id.log'));
```
*`task-id`* は、この手順で返されたタスク ID に置き換えます。
**注記**
タスクは非同期的に実行されます。
ディレクトリからファイルを削除するには、Oracle プロシージャ `UTL_FILE.FREMOVE` を使用できます。詳細については、Oracle ドキュメントの「[FREMOVE プロシージャ](https://docs.oracle.com/database/121/ARPLS/u_file.htm#ARPLS70924)」を参照してください。
## ファイル転送のステータスをモニタリングする
ファイル転送タスクでは、スタート時と完了時に Amazon RDS イベントが発行されます。イベントメッセージには、ファイル転送のタスク ID が含まれています。イベントの表示の詳細については、「[Amazon RDS イベントの表示](USER_ListEvents.md)」を参照してください。
実行中のタスクのステータスは bdump ファイルで確認できます。bdump ファイルは `/rdsdbdata/log/trace` ディレクトリにあります。bdump ファイルの名前形式は、以下のとおりです。
```
dbtask-task-id.log
```
`task-id` を、モニタリングするタスクの ID に置き換えます。
**注記**
タスクは非同期的に実行されます。
bdump ファイルの中身を表示するには、`rdsadmin.rds_file_util.read_text_file` ストアドプロシージャを使用します。例えば、次のクエリでは、bdump ファイル (`dbtask-1234567890123-1234.log`) の中身が返ります。
```
SELECT text FROM table(rdsadmin.rds_file_util.read_text_file('BDUMP','dbtask-1234567890123-1234.log'));
```
次のサンプルは、転送が失敗したときのログファイルを示しています。
```
TASK_ID
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1234567890123-1234
TEXT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2023-04-17 18:21:33.993 UTC [INFO ] File #1: Uploading the file /rdsdbdata/datapump/A123B4CDEF567890G1234567890H1234/sample.dmp to Amazon S3 with bucket name amzn-s3-demo-bucket and key sample.dmp.
2023-04-17 18:21:34.188 UTC [ERROR] RDS doesn't have permission to write to Amazon S3 bucket name amzn-s3-demo-bucket and key sample.dmp.
2023-04-17 18:21:34.189 UTC [INFO ] The task failed.
```
## Amazon S3 統合のトラブルシューティング
トラブルシューティングのヒントについては、AWS re:Post の記事「[Amazon RDS for Oracle と Amazon S3 を統合する際の問題をトラブルシューティングするにはどうすればよいですか?](https://repost.aws/en/knowledge-center/rds-oracle-s3-integration)」を参照してください。
# Amazon S3 統合オプションの削除
DB インスタンスから Amazon S3 統合オプションを削除できます。
Amazon S3 統合オプションを DB インスタンスから削除するには、次のいずれかを実行します。
+ 複数の DB インスタンスから Amazon S3 統合オプションを削除するには、DB インスタンスが属しているオプショングループから `S3_INTEGRATION` オプションを削除します。この変更はそのオプショングループを使用するすべての DB インスタンスに影響します。詳細については、「[オプショングループからオプションを削除する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.RemoveOption)」を参照してください。
+ 1 つの DB インスタンスから Amazon S3 統合オプションを削除するには、インスタンスを変更し、`S3_INTEGRATION` オプションを含まない別のオプショングループを指定します。デフォルト (空) のオプショングループや別のカスタムオプショングループを指定できます。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
# Oracle Application Express (APEX)
Amazon RDS では、`APEX` および `APEX-DEV` オプションを使用した Oracle Application Express (APEX) がサポートされています。Oracle APEX は、ランタイム環境として、あるいはウェブベースのアプリケーション用の完全開発環境としてデプロイできます。Oracle APEX を使用して、ウェブブラウザ内でアプリケーション全体を構築できます。詳細については、Oracle ドキュメントの [Oracle Application Express](https://apex.oracle.com/) を参照してください。
**Topics**
+ [Oracle APEX コンポーネント](#Appendix.Oracle.Options.APEX.components)
+ [要件と制限](Appendix.Oracle.Options.APEX.Requirements.md)
+ [Oracle APEX と Oracle Rest Data Services (ORDS) のセットアップ](Appendix.Oracle.Options.APEX.settingUp.md)
+ [Oracle Rest Data Services (ORDS) の設定](Appendix.Oracle.Options.APEX.ORDSConf.md)
+ [Oracle APEX のアップグレードと削除](Appendix.Oracle.Options.APEX.UpgradeandRemove.md)
## Oracle APEX コンポーネント
Oracle APEX は、次の主要コンポーネントで構成されています。
+ Oracle APEX アプリケーションおよびコンポーネントのメタデータを格納する*リポジトリ*。リポジトリは、テーブル、インデックス、および Amazon RDS DB インスタンスにインストールされている他のオブジェクトで構成されます。
+ Oracle APEX クライアントとの HTTP 通信を管理する*リスナー*。リスナーは別個のホスト (Amazon EC2 インスタンス、社内のオンプレミスサーバー、またはデスクトップコンピュータなど) に配置します。リスナーは、ウェブブラウザからの受信接続を受け入れ、処理するためにそれらを Amazon RDS DB インスタンスに転送した後、リポジトリからの結果をブラウザに戻します。
Amazon RDS for Oracle は、次のタイプのリスナーをサポートしています。
+ Oracle APEX バージョン 5.0 以降では、Oracle REST Data Services (ORDS) バージョン 19.1 以上を使用します。サポートされている最新バージョンの Oracle APEX および ORDS を使用することをお勧めします。このドキュメントでは、下位互換性のためだけに古いバージョンについて説明しています。
+ Oracle APEX バージョン 4.1.1 では、Oracle APEX リスナーのバージョン 1.1.4 を使用できます。
+ Oracle HTTP Server や`mod_plsql` リスナーを使用できます。
**注記**
Amazon RDS では、埋込み PL/SQL ゲートウェイの Oracle XML DB HTTP サーバーを Oracle APEX のリスナーとしてサポートしません。一般的に、Oracle では、インターネット上で稼働するアプリケーションで埋め込みの PL/SQL ゲートウェイを使用しないことが推奨されています。
詳細については、Oracle ドキュメントの「[Web リスナーの選択について](https://docs.oracle.com/database/apex-5.1/HTMIG/choosing-web-listener.htm#HTMIG29321)」を参照してください。
RDS for Oracle DB インスタンスに `APEX` オプションと `APEX-DEV` オプションを追加すると、Amazon RDS は Oracle APEX リポジトリのみをインストールします。リスナーを別のホストにインストールします。
# 要件と制限
このトピックでは、Oracle APEX と ORDS の要件と制限を一覧表示します。
## Oracle APEX バージョンの要件
`APEX` オプションは、DB インスタンスの DB インスタンスクラスでストレージを使用します。以下に、Oracle APEX でサポートされているバージョンおよびおよそのストレージ要件を示します。
****
| Oracle APEX バージョン | ストレージの要件 | サポートされている Oracle Database のバージョン | 注意事項 |
| --- | --- | --- | --- |
| Oracle APEX バージョン 24.2.v1 | 114 MiB | すべて | このバージョンには、パッチ 37885097: PSE BUNDLE FOR APEX 24.2 (PSES ON TOP OF 24.2.0)、PATCH\$1VERSION 4 が含まれています。 |
| Oracle APEX バージョン 24.1.v1 | 112 MiB | すべて | このバージョンには、パッチ 36695709: PSE BUNDLE FOR APEX 24.1 (PSES ON TOP OF 24.1.0), PATCH\$1VERSION 3 が含まれています。EC2 インスタンスにインストールするのにまったく同じ APEX イメージバージョンが必要な場合は、パッチ 37544819: 24.1.3 PSE BUNDLE FOR APEX 24.1 (PSES ON TOP OF 24.1.0) をダウンロードします。 |
| Oracle APEX バージョン 23.2.v1 | 110 MiB | すべて | このバージョンには、パッチ 35895964: PSE BUNDLE FOR APEX 23.2 (PSES ON TOP OF 23.2.0)、PATCH\$1VERSION 6 が含まれています。EC2 インスタンスにインストールするのにまったく同じ APEX イメージバージョンが必要な場合は、パッチ 37593125: 23.2.6 PSE BUNDLE FOR APEX 23.2 (PSES ON TOP OF 23.2.0) をダウンロードします。 |
| Oracle APEX バージョン 23.1.v1 | 106 MiB | すべて | このバージョンには、パッチ 35283657: PSE BUNDLE FOR APEX 23.1 (PSES ON TOP OF 23.1.0), PATCH\$1VERSION 2 が含まれています。 |
| Oracle APEX バージョン 22.2.v1 | 106 MiB | すべて | このバージョンには、パッチ 34628174: PSE BUNDLE FOR APEX 22.2 (PSES ON TOP OF 22.2.0)、PATCH\$1VERSION 4 が含まれています。 |
| Oracle APEX バージョン 22.1.v1 | 124 MiB | すべて | このバージョンには、パッチ 34020981: PSE BUNDLE FOR APEX 22.1 (PSES ON TOP OF 22.1.0)、PATCH\$1VERSION 6 が含まれています。 |
| Oracle APEX バージョン 21.2.v1 | 125 MiB | すべて | このバージョンには、パッチ 33420059: PSE BUNDLE FOR APEX 21.2 (PSES ON TOP OF 21.2.0)、PATCH\$1VERSION 8 が含まれています。 |
| Oracle APEX バージョン 21.1.v1 | 125 MiB | すべて | このバージョンには、パッチ 32598392 (PSE BUNDLE FOR APEX 21.1、PATCH\$1VERSION 3) が含まれています。 |
| Oracle APEX バージョン 20.2.v1 | 148 MiB | Oracle Database 21c を除くすべて | このバージョンには、パッチ 32006852 (PSE BUNDLE FOR APEX 20.2、PATCH\$1VERSION 2020.11.12) が含まれています。以下のクエリを実行すると、パッチの番号と日付を確認できます。 SELECT PATCH_VERSION, PATCH_NUMBER
FROM APEX_PATCHES;
|
| Oracle APEX バージョン 20.1.v1 | 173 MiB | Oracle Database 21c を除くすべて | このバージョンには、パッチ 30990551 (PSE BUNDLE FOR APEX 20.1, PATCH\$1VERSION 2020.07.15) が含まれています。 |
| Oracle APEX バージョン 19.2.v1 | 149 MiB | Oracle Database 21c を除くすべて | |
| Oracle APEX バージョン 19.1.v1 | 148 MiB | Oracle Database 21c を除くすべて | |
ダウンロード可能な Oracle APEX.zip ファイルについては、Oracle のウェブサイトで「[Oracle APEX Prior Release Archives](https://www.oracle.com/tools/downloads/apex-all-archives-downloads.html)」を参照してください。
## Oracle APEX および ORDS の前提条件
Oracle APEX と ORDS を使用する際、以下の前提条件に注意してください。
+ システムは Java ランタイム環境 (JRE) を使用する必要があります。
+ Oracle クライアントのインストールには次が含まれている必要があります。
+ 管理タスク用の SQL\$1Plus または SQL Developer
+ RDS for Oracle DB インスタンスへの接続を設定するための Oracle Net Services
## Oracle APEX の制限事項
`APEX_version` ユーザーアカウントは、Amazon RDS によって管理され、ユーザーが変更することはできません。したがって、このユーザーにデータベースプロファイルを適用したり、パスワードルールを適用したりすることはできません。`APEX_version` のプロファイルとパスワードの設定は Oracle と AWS によって事前定義されており、Amazon RDS のセキュリティ要件を満たすように設計されています。
# Oracle APEX と Oracle Rest Data Services (ORDS) のセットアップ
次のトピックでは、Oracle APEX と ORDS のセットアップに必要な手順を示します。
**Topics**
+ [APEX および APEX-DEV オプションの DB インスタンスへの追加](#Appendix.Oracle.Options.APEX.Add)
+ [DB インスタンスのパブリックユーザーアカウントのロック解除](#Appendix.Oracle.Options.APEX.PublicUser)
+ [Oracle APEX の RESTful サービスの設定](#Appendix.Oracle.Options.APEX.ConfigureRESTful)
+ [ORDS を別のホストにインストールする準備](#Appendix.Oracle.Options.APEX.ORDS.ords-setup)
+ [Oracle APEX リスナーの設定](#Appendix.Oracle.Options.APEX.Listener)
## APEX および APEX-DEV オプションの DB インスタンスへの追加
RDS for Oracle DB インスタンスに `APEX` および `APEX-DEV` オプションを追加するには、次の手順を実行します。
1. 新しいオプショングループを作成するか、既存のオプショングループをコピーまたは変更します。
1. オプショングループに `APEX` と `APEX-DEV` オプションを追加します。
1. オプショングループを DB インスタンスに関連付けます。
`APEX` オプションと `APEX-DEV` オプションを追加すると、DB インスタンスが自動的に再起動する間に短時間の停止が発生します。
**注記**
`APEX_MAIL` は、`APEX` オプションがインストールされている場合に使用できます。`APEX_MAIL` パッケージの実行権限が `PUBLIC` に付与されるため、APEX 管理者アカウントを使用する必要はありません。
**APEX オプションと APEX-DEV オプションを DB インスタンスに追加するには**
1. 使用するオプショングループを決定します。新しいオプショングループを作成することも、既存のオプショングループを使用することもできます。既存のオプショングループを使用する場合は、次のステップは飛ばしてください。または、次の設定でカスタム DB オプショングループを作成します。
1. [**Engine**] で、使用する Oracle のエディションを選択します。`APEX` オプションと `APEX-DEV` オプションは、すべてのエディションでサポートされます。
1. [**メジャーエンジンのバージョン**] で、DB インスタンスのバージョンを選択します。
詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
1. オプショングループにオプションを追加します。Oracle APEX ランタイム環境のみをデプロイする場合には、`APEX` オプションのみを追加します。完全なデプロイ環境をデプロイするには、`APEX` と `APEX-DEV` の両方のオプションを追加します。
**[バージョン]** で、使用する Oracle APEX のバージョンを選択します。
**重要**
1 つ以上の DB インスタンスに既にアタッチされている既存のオプショングループに `APEX` オプションまたは `APEX-DEV` オプションを追加すると、短時間の停止が発生します。この停止の間、すべての DB インスタンスが自動的に再起動されます。
オプションの追加方法の詳細については、「[オプショングループにオプションを追加する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption)」を参照してください。
1. 新規または既存の DB インスタンスに、DB オプショングループを適用します。
+ 新規 DB インスタンスの場合は、インスタンスを起動するときにオプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の DB インスタンスの場合は、インスタンスを修正し、新しいオプショングループを添付することで、オプショングループを適用します。既存の DB インスタンスに `APEX` オプションまたは `APEX-DEV` オプションを追加すると、DB インスタンスが自動的に再起動する間に短時間の停止が発生します。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
## DB インスタンスのパブリックユーザーアカウントのロック解除
`APEX` オプションまたは `APEX-DEV` オプションを DB インスタンスにインストールしたら、次の操作を必ず実行してください。
1. `APEX_PUBLIC_USER` アカウントのパスワードを変更します。
1. アカウントのロックを解除します。
Oracle SQL\$1Plus コマンドラインユーティリティを使用してこれを行うことができます。DB インスタンスにマスターユーザーとして接続し、次のコマンドを発行します。`new_password` を任意のパスワードに置き換えます。
```
1. ALTER USER APEX_PUBLIC_USER IDENTIFIED BY new_password;
2. ALTER USER APEX_PUBLIC_USER ACCOUNT UNLOCK;
```
## Oracle APEX の RESTful サービスの設定
Oracle APEX で RESTful サービスを設定するには (APEX 4.1.1.V1 では必要ありません)、SQL\$1Plus を使用して、マスターユーザーとして DB インスタンスに接続します。接続したら、`rdsadmin.rdsadmin_run_apex_rest_config` ストアドプロシージャを実行します。ストアドプロシージャを実行するときは、次のユーザーにパスワードを提供します。
+ `APEX_LISTENER`
+ `APEX_REST_PUBLIC_USER`
ストアドプロシージャは `apex_rest_config.sql` スクリプトを実行し、そのスクリプトによりそれらのユーザーの新しいデータベースアカウントが作成されます。
**注記**
Oracle APEX バージョン 4.1.1.v1 に対する設定は不要です。この Oracle APEX バージョンに限り、ストアドプロシージャの実行は不要です。
次のコマンドはストアドプロシージャを実行します。
```
1. EXEC rdsadmin.rdsadmin_run_apex_rest_config('apex_listener_password', 'apex_rest_public_user_password');
```
## ORDS を別のホストにインストールする準備
別個のホスト (Amazon EC2 インスタンス、社内のオンプレミスサーバー、またはデスクトップコンピュータなど) にインストールします。このセクションの例では、ホストが Linux を実行し、`myapexhost.example.com` という名前が付けられていることを前提としています。
ORDS をインストールする前に、権限のない OS ユーザーを作成し、Oracle APEX インストールファイルをダウンロードして解凍する必要があります。
**ORDS のインストールを準備するには**
1. `myapexhost.example.com` として `root` にログインします。
1. リスナーのインストールを所有する権限を持っていない OS ユーザーを作成します。以下のコマンドでは、*apexuser* という名前の新規ユーザーを作成します。
```
useradd -d /home/apexuser apexuser
```
以下のコマンドは、新規ユーザーにパスワードを割り当てます。
```
passwd apexuser;
```
1. `myapexhost.example.com` に `apexuser` としてログインし、Oracle APEX のインストールファイルを Oracle から `/home/apexuser` ディレクトリにダウンロードします。
+ [http://www.oracle.com/technetwork/developer-tools/apex/downloads/index.html](http://www.oracle.com/technetwork/developer-tools/apex/downloads/index.html)
+ [Oracle Application Express Prior Release Archives](http://www.oracle.com/technetwork/developer-tools/apex/downloads/all-archives-099381.html)
1. ファイルを `/home/apexuser` ディレクトリに解凍します。
```
unzip apex_version.zip
```
ファイルは、`apex` ディレクトリ内に `/home/apexuser` ディレクトリとして解凍されます。
1. `myapexhost.example.com` に `apexuser` としてログインしている間に Oracle から Oracle REST Data Services ファイルを `/home/apexuser` ディレクトリにダウンロードします。[http://www.oracle.com/technetwork/developer-tools/apex-listener/downloads/index.html](http://www.oracle.com/technetwork/developer-tools/apex-listener/downloads/index.html)
## Oracle APEX リスナーの設定
**注記**
Oracle APEX リスナーは非推奨です。
Amazon RDS for Oracle は、引き続き Oracle APEX バージョン 4.1.1 および Oracle APEX リスナーバージョン 1.1.4 をサポートします。サポートされている最新バージョンの Oracle APEX および ORDS を使用することをお勧めします。
Oracle APEX Listener は別個のホストにインストールします (Amazon EC2 インスタンス、社内のオンプレミスサーバー、またはデスクトップコンピュータ)。ここでは、ホスト名が `myapexhost.example.com` であり、ホストで Linux が実行されていることが前提です。
### Oracle APEX リスナーのインストールの準備
Oracle APEX リスナーをインストールする前に、権限のない OS ユーザーを作成し、Oracle APEX インストールファイルをダウンロードして解凍する必要があります。
**Oracle APEX リスナーのインストールを準備するには**
1. `myapexhost.example.com` として `root` にログインします。
1. リスナーのインストールを所有する権限を持っていない OS ユーザーを作成します。以下のコマンドでは、*apexuser* という名前の新規ユーザーを作成します。
```
useradd -d /home/apexuser apexuser
```
以下のコマンドは、新規ユーザーにパスワードを割り当てます。
```
passwd apexuser;
```
1. `myapexhost.example.com` に `apexuser` としてログインし、Oracle APEX のインストールファイルを Oracle から `/home/apexuser` ディレクトリにダウンロードします。
+ [http://www.oracle.com/technetwork/developer-tools/apex/downloads/index.html](http://www.oracle.com/technetwork/developer-tools/apex/downloads/index.html)
+ [Oracle Application Express Prior Release Archives](http://www.oracle.com/technetwork/developer-tools/apex/downloads/all-archives-099381.html)
1. ファイルを `/home/apexuser` ディレクトリに解凍します。
```
unzip apex_.zip
```
ファイルは、`apex` ディレクトリ内に `/home/apexuser` ディレクトリとして解凍されます。
1. `myapexhost.example.com` に `apexuser` としてログインしている間に、Oracle APEX Listener ファイルを Oracle から `/home/apexuser` ディレクトリにダウンロードします。
#### Oracle APEX リスナーのインストールと設定
Oracle APEX を使用する前に、`apex.war` ファイルをダウンロードし、Java を使用して Oracle APEX リスナーをインストールしてから、リスナーを起動する必要があります。
**Oracle APEX リスナーをインストールして設定するには**
1. Oracle APEX リスナーに基づいて新しいディレクトリを作成し、リスナーファイルを開きます。
以下のコードを実行します。
```
mkdir /home/apexuser/apexlistener
cd /home/apexuser/apexlistener
unzip ../apex_listener.version.zip
```
1. 以下の コードを実行します。
```
java -Dapex.home=./apex -Dapex.images=/home/apexuser/apex/images -Dapex.erase -jar ./apex.war
```
1. 次のプログラムプロンプトの情報を入力します。
+ APEX Listener Administrator のユーザー名。デフォルト値は *adminlistener* です。
+ APEX Listener Administrator のパスワード。
+ APEX リスナーマネージャのユーザー名。デフォルトは *managerlistener* です。
+ APEX Listener Administrator のパスワード。
プログラムは、次のように設定を完了するために必要な URL を出力します。
```
INFO: Please complete configuration at: http://localhost:8080/apex/listenerConfigure
Database is not yet configured
```
1. Oracle Application Express を使用できるように、Oracle APEX リスナーを実行したままにします。この設定手順を完了したら、リスナーをバックグラウンドで実行できます。
1. ウェブブラウザから、Oracle APEX リスナープログラムが提供する URL にアクセスします。Oracle Application Express Listener の管理ウィンドウが表示されます。次の情報を入力します。
+ **Username** - `APEX_PUBLIC_USER`
+ **[Password]** - *APEX\$1PUBLIC\$1USER* のパスワード このパスワードは、以前に Oracle APEX リポジトリの設定時に指定したパスワードです。詳細については、「[DB インスタンスのパブリックユーザーアカウントのロック解除](#Appendix.Oracle.Options.APEX.PublicUser)」を参照してください。
+ **Connection Type** - Basic
+ **Hostname** - Amazon RDS DB インスタンスのエンドポイント。`mydb.f9rbfa893tft.us-east-1.rds.amazonaws.com` など。
+ **[Port**] - 1521
+ **SID** - Amazon RDS DB インスタンスのデータベースの名前。`mydb` など。
1. [**Apply**] を選択します。Oracle APEX の管理ウィンドウが表示されます。
1. Oracle APEX の `admin` ユーザーのパスワードを設定します。これを行うには、SQL\$1Plus を使用して DB インスタンスにマスターユーザーとして接続し、次のコマンドを実行します。
```
1. EXEC rdsadmin.rdsadmin_util.grant_apex_admin_role;
2. grant APEX_ADMINISTRATOR_ROLE to master;
3. @/home/apexuser/apex/apxchpwd.sql
```
`master` を自身のマスターユーザー名に置き換えます。`apxchpwd.sql` スクリプトによってプロンプトが表示されたら、新しい `admin` パスワードを入力します。
1. ブラウザで Oracle APEX の管理ウィンドウに戻り、**[管理]** を選択します。次に、[**Application Express Internal Administration**] を選択します。認証情報を求められたら、以下の情報を入力します。
+ **User name** - `admin`
+ **Password** - `apxchpwd.sql` スクリプトを使用して設定したパスワード。
[**Login**] を選択し、その `admin` ユーザーの新しいパスワードを設定します。
これで、リスナーを使用する準備ができました。
# Oracle Rest Data Services (ORDS) の設定
次のトピックでは、ORDS 21 および 22 の設定オプションを一覧表示します。
**Topics**
+ [ORDS 21 以前のインストールと設定](#Appendix.Oracle.Options.APEX.ORDS)
+ [ORDS 22 以降のインストールと設定](#Appendix.Oracle.Options.APEX.ORDS22)
## ORDS 21 以前のインストールと設定
これで、Oracle APEX で使用する Oracle Rest Data Services (ORDS) をインストールして設定する準備が整いました。Oracle APEX バージョン 5.0 以降では、ORDS バージョン 19.1～21 を使用します。ORDS 22 以降をインストールする方法については、「[ORDS 22 以降のインストールと設定](#Appendix.Oracle.Options.APEX.ORDS22)」を参照してください。
リスナーは別個のホスト (Amazon EC2 インスタンス、社内のオンプレミスサーバー、またはデスクトップコンピュータなど) にインストールします。このセクションの例では、ホストの名前が `myapexhost.example.com` であり、ホストが Linux を実行していると仮定します。
**Oracle APEX で使用する ORDS 21 以前をインストールして設定するには**
1. [Oracle REST data services](https://www.oracle.com/database/technologies/appdev/rest-data-services-downloads-212.html) に移動し、Readme を確認します。必要なバージョンの Java がインストールされていることを確認します。
1. ORDS インストール用の新しいディレクトリを作成します。
```
mkdir /home/apexuser/ORDS
cd /home/apexuser/ORDS
```
1. [Oracle REST Data Services](https://www.oracle.com/database/technologies/appdev/rest-data-services-downloads-212.html) から、ファイル `ords.version.number.zip` をダウンロードします。
1. ファイルを `/home/apexuser/ORDS` ディレクトリに解凍します。
1. マルチテナントデータベースに ORDS をインストールする場合は、ファイル `/home/apexuser/ORDS/params/ords_params.properties` に次の行を追加します。
```
pdb.disable.lockdown=false
```
1. マスターユーザーに ORDS のインストールに必要な権限を付与します。
Oracle APEX のオプションをインストールしたら、ORDS スキーマをインストールするために必要な権限をマスターユーザーに付与します。これを行うには、データベースに接続し、次のコマンドを実行します。`MASTER_USER` をマスターユーザーの (大文字で記述した) 名前に置き換えます。
**重要**
大文字と小文字を区別する識別子を使用してユーザーを作成した場合を除き、ユーザー名を入力する際には大文字を使用します。例えば、`CREATE USER myuser` または `CREATE USER MYUSER` を実行すると、データディクショナリに `MYUSER` が保存されます。ただし、`CREATE USER "MyUser"` で二重引用符を使用すると、データディクショナリには `MyUser` が保存されます。詳細については、「[SYS オブジェクトへの SELECT または EXECUTE 権限の付与](Appendix.Oracle.CommonDBATasks.TransferPrivileges.md)」を参照してください。
```
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_OBJECTS', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_ROLE_PRIVS', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_TAB_COLUMNS', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('USER_CONS_COLUMNS', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('USER_CONSTRAINTS', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('USER_OBJECTS', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('USER_PROCEDURES', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('USER_TAB_COLUMNS', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('USER_TABLES', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('USER_VIEWS', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('WPIUTL', 'MASTER_USER', 'EXECUTE', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_SESSION', 'MASTER_USER', 'EXECUTE', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_UTILITY', 'MASTER_USER', 'EXECUTE', true);
```
**注記**
これらのコマンドは、ORDS バージョン 19.1 以降に適用されます。
1. ダウンロードした ords.war ファイルを使用して ORDS スキーマをインストールします。
```
java -jar ords.war install advanced
```
プログラムが以下の情報のプロンプトを表示します。デフォルト値は角括弧で囲まれています。詳細については、Oracle ドキュメントの [Introduction to Oracle REST Data Services](https://docs.oracle.com/en/database/oracle/oracle-rest-data-services/20.2/aelig/installing-REST-data-services.html#GUID-6F7B4E61-B730-4E73-80B8-F53299123730) を参照してください。
+ 設定データを保存する場所を入力します。
「*/home/apexuser/ORDS*」と入力します。これは ORDS 設定ファイルの場所です。
+ 使用するデータベース接続タイプを指定します。[1] ベーシック、[2] TNS、[3] カスタム URL に対応する番号を入力します [1]:
目的の接続タイプを選択します。
+ データベースサーバーの名前を入力します [localhost]: *DB\$1instance\$1endpoint*
デフォルト値を選択するか、適切な値を入力します。
+ データベースリスナーポートを入力します [1521]: *DB\$1instance\$1port*
デフォルト値を選択するか、適切な値を入力します。
+ データベースサービス名を指定するには 1 を、データベース SID を指定するには 2 を入力してください [1]:
`2` を選択して、データベース SID を指定します。
+ データベース SID [xe]
デフォルト値を選択するか、適切な値を入力します。
+ Oracle REST Data Services スキーマを検証/インストールする場合は 1 を、このステップをスキップする場合は 2 を入力します [1]:
[] を選択します`1` このステップでは、ORDS\$1PUBLIC\$1USER という名前の Oracle REST Data Services プロキシユーザーを作成します。
+ ORDS\$1PUBLIC\$1USER のデータベースパスワードを入力します。
パスワードを入力し、確認のためにもう一度入力します。
+ Oracle REST Data Services のスキーマを検証するには、管理者権限でログインする必要があります。
管理者ユーザー名: *master\$1user*
*master\$1user*: *master\$1user\$1password* のデータパスワードを入力する
パスワードを確認する: *master\$1user\$1password*
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
+ ORDS\$1METADATA [SYSAUX] のデフォルトのテーブルスペースを入力します。
ORDS\$1METADATA [TEMP] のテンポラリテーブルスペースを入力します。
ORDS\$1PUBLIC\$1USER [USERS] のデフォルトのテーブルスペースを入力します。
ORDS\$1PUBLIC\$1USER [TEMP] のテンポラリテーブルスペースを入力します。
+ PL/SQL Gateway を使用する場合は 1 を入力し、このステップをスキップするには 2 を入力します。Oracle Application Express を使用している場合、または mod\$1plsql から移行する場合は、1 [1] を入力する必要があります。
デフォルト値を選択します。
+ PL/SQL ゲートウェイデータベースのユーザー名として [APEX\$1PUBLIC\$1USER] を入力します。
デフォルト値を選択します。
+ APEX\$1PUBLIC\$1USER のデータベースパスワードを入力します。
パスワードを入力し、確認のためにもう一度入力します。
+ 1 を入力して、Application Express RESTful Services データベースユーザー (APEX\$1LISTENER、APEX\$1REST\$1PUBLIC\$1USER) のパスワードを指定するか、2 を入力して、このステップをスキップします [1]:
APEX 4.1.1.V1 に対して `2` を選択するか、他のすべての APEX バージョンに対して `1` を選択します。
+ [APEX 4.1.1.v1 では不要] APEX\$1LISTENER のデータベースパスワード
パスワードを入力し (必要な場合)、確認のためにもう一度入力します。
+ [APEX 4.1.1.v1 では不要] APEX\$1REST\$1PUBLIC\$1USER のデータベースパスワード
パスワードを入力し (必要な場合)、確認のためにもう一度入力します。
+ 有効にする機能に対応する番号を入力します。
SQL Developer Web、REST Enabled SQL、および Database API 機能をすべて有効にするには、`1` を入力します。
+ スタンドアロンモードでスタートする場合は 1 を、終了する場合は 2 を入力します [1]:
`1` と入力します。
+ APEX 静的リソースの場所を入力します。
APEX インストールファイルを `/home/apexuser` に解凍した場合は、「`/home/apexuser/apex/images`」と入力します。それ以外の場合は、`unzip_path/apex/images` を入力します。*unzip\$1path* は、ファイルを解凍したディレクトリです。
+ HTTP を使用する場合は 1 を、HTTPS を使用する場合は 2 を入力します [1]:
`1` を入力する場合は、HTTP ポートを指定します。`2` を入力する場合は、HTTPS ポートと SSL ホスト名を指定します。HTTPS オプションでは、証明書を提供する方法を指定するように求められます。
+ 自己署名証明書を使用するには、`1` を入力します。
+ 独自の証明書を提供するには、`2` を入力します。`2` を入力する場合は、SSL 証明書のパス、およびその証明書のシークレットキーのパスを指定します。
1. APEX `admin` ユーザーのパスワードを設定します。これを行うには、SQL\$1Plus を使用して DB インスタンスにマスターユーザーとして接続し、次のコマンドを実行します。
```
1. EXEC rdsadmin.rdsadmin_util.grant_apex_admin_role;
2. grant APEX_ADMINISTRATOR_ROLE to master;
3. @/home/apexuser/apex/apxchpwd.sql
```
`master` を自身のマスターユーザー名に置き換えます。`apxchpwd.sql` スクリプトによってプロンプトが表示されたら、新しい `admin` パスワードを入力します。
1. ORDS リスナーを起動します。以下の コードを実行します。
```
java -jar ords.war
```
ORDS を初めてスタートすると、APEX の静的リソースの場所を指定するように求められます。このイメージフォルダは、APEX のインストールディレクトリ内の `/apex/images` ディレクトリにあります。
1. ブラウザで Oracle APEX の管理ウィンドウに戻り、**[管理]** を選択します。次に、[**Application Express Internal Administration**] を選択します。認証情報を求められたら、以下の情報を入力します。
+ **User name** - `admin`
+ **Password** - `apxchpwd.sql` スクリプトを使用して設定したパスワード。
[**Login**] を選択し、その `admin` ユーザーの新しいパスワードを設定します。
これで、リスナーを使用する準備ができました。
## ORDS 22 以降のインストールと設定
これで、Oracle APEX で使用する Oracle Rest Data Services (ORDS) をインストールして設定する準備が整いました。このセクションの例では、別個のホストの名前が `myapexhost.example.com` であり、ホストが Linux を実行していると仮定します。ORDS 22 の手順は、以前のリリースの手順とは異なります。
**Oracle APEX で使用するための ORDS 22 以降をインストールして設定するには**
1. [Oracle REST data services](http://www.oracle.com/technetwork/developer-tools/rest-data-services/downloads/index.html) に移動し、ダウンロードする ORDS バージョンの Readme を確認します。必要なバージョンの Java がインストールされていることを確認します。
1. ORDS インストール用の新しいディレクトリを作成します。
```
mkdir /home/apexuser/ORDS
cd /home/apexuser/ORDS
```
1. [Oracle REST Data Services](http://www.oracle.com/technetwork/developer-tools/rest-data-services/downloads/index.html) から、ファイル `ords.version.number.zip` または `ords-latest.zip` をダウンロードします。
1. ファイルを `/home/apexuser/ORDS` ディレクトリに解凍します。
1. マスターユーザーに ORDS のインストールに必要な権限を付与します。
`APEX` オプションをインストールしたら、ORDS スキーマをインストールするために必要な権限をマスターユーザーに付与します。これを行うには、データベースにログインして、以下のコマンドを実行します。`MASTER_USER` をマスターユーザーの (大文字で記述した) 名前に置き換えます。
**重要**
大文字と小文字を区別する識別子を使用してユーザーを作成した場合を除き、ユーザー名を入力する際には大文字を使用します。例えば、`CREATE USER myuser` または `CREATE USER MYUSER` を実行すると、データディクショナリに `MYUSER` が保存されます。ただし、`CREATE USER "MyUser"` で二重引用符を使用すると、データディクショナリには `MyUser` が保存されます。詳細については、「[SYS オブジェクトへの SELECT または EXECUTE 権限の付与](Appendix.Oracle.CommonDBATasks.TransferPrivileges.md)」を参照してください。
```
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_OBJECTS', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_ROLE_PRIVS', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_TAB_COLUMNS', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('USER_CONS_COLUMNS', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('USER_CONSTRAINTS', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('USER_OBJECTS', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('USER_PROCEDURES', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('USER_TAB_COLUMNS', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('USER_TABLES', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('USER_VIEWS', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('WPIUTL', 'MASTER_USER', 'EXECUTE', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_SESSION', 'MASTER_USER', 'EXECUTE', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_UTILITY', 'MASTER_USER', 'EXECUTE', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_LOB', 'MASTER_USER', 'EXECUTE', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_ASSERT', 'MASTER_USER', 'EXECUTE', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_OUTPUT', 'MASTER_USER', 'EXECUTE', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_SCHEDULER', 'MASTER_USER', 'EXECUTE', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('HTP', 'MASTER_USER', 'EXECUTE', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('OWA', 'MASTER_USER', 'EXECUTE', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('WPG_DOCLOAD', 'MASTER_USER', 'EXECUTE', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_CRYPTO', 'MASTER_USER', 'EXECUTE', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_METADATA', 'MASTER_USER', 'EXECUTE', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_SQL', 'MASTER_USER', 'EXECUTE', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('UTL_SMTP', 'MASTER_USER', 'EXECUTE', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_NETWORK_ACL_ADMIN', 'MASTER_USER', 'EXECUTE', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('SESSION_PRIVS', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_USERS', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_NETWORK_ACL_PRIVILEGES', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_NETWORK_ACLS', 'MASTER_USER', 'SELECT', true);
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_REGISTRY', 'MASTER_USER', 'SELECT', true);
```
**注記**
上記のコマンドは、ORDS 22 以降に適用されます。
1. ダウンロードした `ords` スクリプトを使用して、ORDS スキーマをインストールします。設定ファイルとログファイルを格納するディレクトリを指定します。Oracle Corporation では、これらのディレクトリを ORDS 製品ソフトウェアが含まれているディレクトリ内に配置しないことを推奨しています。
```
mkdir -p /home/apexuser/ords_config /home/apexuser/ords_logs
/home/apexuser/ORDS/bin/ords \
--config /home/apexuser/ords_config \
install --interactive --log-folder /home/apexuser/ords_logs
```
コンテナデータベース (CDB) アーキテクチャを実行する DB インスタンスでは、ORDS 23.3 以降を使用し、ORDS のインストール時に `--pdb-skip-disable-lockdown` 引数を渡します。
```
/home/apexuser/ORDS/bin/ords \
--config /home/apexuser/ords_config \
install --interactive --log-folder /home/apexuser/ords_logs --pdb-skip-disable-lockdown
```
プログラムが以下の情報のプロンプトを表示します。デフォルト値は角括弧で囲まれています。詳細については、Oracle ドキュメントの [Introduction to Oracle REST Data Services](https://docs.oracle.com/en/database/oracle/oracle-rest-data-services/20.2/aelig/installing-REST-data-services.html#GUID-6F7B4E61-B730-4E73-80B8-F53299123730) を参照してください。
+ `Choose the type of installation:`
**2** を選択して ORDS スキーマをデータベースにインストールし、ローカルの ORDS 設定ファイルにデータベース接続プールを作成します。
+ `Specify the database connection type to use. Enter number for [1] Basic [2] TNS [3] Custom URL:`
目的の接続タイプを選択します。この例では、ユーザーが **1** を選択することを前提としています。
+ `Enter the name of the database server [localhost]:` ***DB\$1instance\$1endpoint***
デフォルト値を選択するか、適切な値を入力します。
+ `Enter the database listener port [1521]:` ***DB\$1instance\$1port***
デフォルト **1521** を選択するか、適切な値を入力します。
+ `Enter the database service name [orcl]:`
RDS for Oracle DB インスタンスで使用するデータベース名を入力します。
+ `Provide database user name with administrator privileges`
RDS for Oracle DB インスタンスのマスターユーザー名を入力します。
+ `Enter the database password for [username]:`
RDS for Oracle DB インスタンスのマスターパスワードを入力します。
+ `Enter the default tablespace for ORDS_METADATA and ORDS_PUBLIC_USER [SYSAUX]:`
+ `Enter the temporary tablespace for ORDS_METADATA [TEMP]. Enter the default tablespace for ORDS_PUBLIC_USER [USERS]. Enter the temporary tablespace for ORDS_PUBLIC_USER [TEMP].`
+ `Enter a number to select additional feature(s) to enable [1]:`
+ `Enter a number to configure and start ORDS in standalone mode [1]: `
**2** を選択して ORDS をスタンドアロンモードですぐに起動しないようにします。
+ `Enter a number to select the protocol [1] HTTP`
+ `Enter the HTTP port [8080]:`
+ `Enter the APEX static resources location:`
Oracle APEX インストールファイル (`/home/apexuser/apex/images`) へのパスを入力します。
1. Oracle APEX の `admin` ユーザーのパスワードを設定します。これを行うには、SQL\$1Plus を使用して DB インスタンスにマスターユーザーとして接続し、次のコマンドを実行します。
```
1. EXEC rdsadmin.rdsadmin_util.grant_apex_admin_role;
2. grant APEX_ADMINISTRATOR_ROLE to master;
3. @/home/apexuser/apex/apxchpwd.sql
```
`master` を自身のマスターユーザー名に置き換えます。`apxchpwd.sql` スクリプトによってプロンプトが表示されたら、新しい `admin` パスワードを入力します。
1. `ords` スクリプトで `serve` コマンドを使用して ORDS をスタンドアロンモードで実行します。実稼働環境へのデプロイでは、Apache Tomcat や Oracle WebLogic Server など、サポートされている Java EE アプリケーションサーバーの使用を検討します。詳細については、Oracle Database ドキュメントの「[Oracle REST Data Services のデプロイおよびモニター](https://docs.oracle.com/en/database/oracle/oracle-rest-data-services/23.1/ordig/deploying-and-monitoring-oracle-rest-data-services.html#GUID-6791F5DF-AC67-4885-BFFA-B80964C17EC9)」を参照してください。
```
/home/apexuser/ORDS/bin/ords \
--config /home/apexuser/ords_config serve \
--port 8193 \
--apex-images /home/apexuser/apex/images
```
ORDS が実行中でも Oracle APEX インストールにアクセスできない場合、次のエラーが (特に非 CDB インスタンスで) 表示されることがあります。
```
The procedure named apex_admin could not be accessed, it may not be declared, or the user executing this request may not have been granted execute privilege on the procedure, or a function specified by security.requestValidationFunction configuration property has prevented access.
```
このエラーを修正するには、`ords` スクリプトで `config` コマンドを実行して ORDS が使用するリクエスト検証機能を変更します。デフォルトでは、ORDS は CDB インスタンスでのみサポートされている `ords_util.authorize_plsql_gateway` プロシージャを使用します。非 CDB インスタンスでは、このプロシージャを `wwv_flow_epg_include_modules.authorize` パッケージに変更できます。ユースケースに応じてリクエスト検証関数を設定するためのベストプラクティスについては、Oracle Database のドキュメントと Oracle Support を参照してください。
1. ブラウザで Oracle APEX の管理ウィンドウに戻り、**[管理]** を選択します。次に、[**Application Express Internal Administration**] を選択します。認証情報を求められたら、以下の情報を入力します。
+ **User name** - `admin`
+ **Password** - `apxchpwd.sql` スクリプトを使用して設定したパスワード。
[**Login**] を選択し、その `admin` ユーザーの新しいパスワードを設定します。
これで、リスナーを使用する準備ができました。
# Oracle APEX のアップグレードと削除
Oracle APEX をアップグレードまたは削除するには、このトピックの手順に従います。
**Topics**
+ [Oracle APEX バージョンのアップグレード](#Appendix.Oracle.Options.APEX.Upgrade)
+ [APEX オプションと APEX-DEV オプションの削除](#Appendix.Oracle.Options.APEX.Remove)
## Oracle APEX バージョンのアップグレード
**重要**
Oracle APEX をアップグレードする前に、DB インスタンスをバックアップします。詳細については、「[Amazon RDS のシングル AZ DB インスタンスの DB スナップショットの作成](USER_CreateSnapshot.md)」および「[Oracle DB アップグレードのテスト](USER_UpgradeDBInstance.Oracle.UpgradeTesting.md)」を参照してください。
Oracle APEX を DB インスタンスと共にアップグレードするには、以下を実行します。
+ DB インスタンスのアップグレードしたバージョン用に新規のオプショングループを作成します。
+ 新規のオプショングループに、アップグレードしたバージョンの `APEX` オプションと `APEX-DEV` オプションを追加します。DB インスタンスが使用するそのほかのすべてのオプションを含めるようにします。詳細については、「[オプショングループに関する考慮事項](USER_UpgradeDBInstance.Oracle.OGPG.md#USER_UpgradeDBInstance.Oracle.OGPG.OG)」を参照してください。
+ DB インスタンスをアップグレードするときに、アップグレードした DB インスタンスに新規のオプショングループを指定します。
Oracle APEX のバージョンのアップグレード後に、以前のバージョンの Oracle APEX スキーマがデータベースに残存する場合があります。不要な場合は、アップグレード後に古い Oracle APEX スキーマをデータベースから削除できます。
Oracle APEX バージョンをアップグレードする場合、以前の Oracle APEX バージョンで RESTful サービスが設定されていないときは、RESTful サービスを設定することをお勧めします。詳細については、「[Oracle APEX の RESTful サービスの設定](Appendix.Oracle.Options.APEX.settingUp.md#Appendix.Oracle.Options.APEX.ConfigureRESTful)」を参照してください。
DB インスタンスのメジャーバージョンアップグレードを行う際、ターゲットデータベースのバージョンと互換性のない Oracle APEX バージョンを使用していることに気付く場合があります。このような場合は、DB インスタンスをアップグレードする前に、Oracle APEX のバージョンをアップグレードできます。最初に Oracle APEX をアップグレードすると、DB インスタンスのアップグレードに要する時間を短縮できます。
**注記**
Oracle APEX をアップグレードしたら、アップグレードしたバージョンで使用するリスナーをインストールして設定します。手順については、「[Oracle APEX リスナーの設定](Appendix.Oracle.Options.APEX.settingUp.md#Appendix.Oracle.Options.APEX.Listener)」を参照してください。
## APEX オプションと APEX-DEV オプションの削除
DB インスタンスから `APEX` オプションと `APEX-DEV` オプションを削除できます。これらのオプションを DB インスタンスから削除するには、次のいずれかを実行します。
+ 複数の DB インスタンスから `APEX` オプションと `APEX-DEV` オプションを削除するには、それらが属しているオプショングループから両オプションを削除します。この変更はそのオプショングループを使用するすべての DB インスタンスに影響します。複数の DB インスタンスにアタッチされているオプショングループからオプションを削除すると、DB インスタンスが再起動される間、短時間の停止が発生します。
詳細については、「[オプショングループからオプションを削除する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.RemoveOption)」を参照してください。
+ 1 つの DB インスタンスから `APEX` オプションと `APEX-DEV` オプションを削除するには、DB インスタンスを変更し、これらのオプションを含まない別のオプショングループを指定します。デフォルト (空) のオプショングループや別のカスタムオプショングループを指定できます。オプションを削除する場合、DB インスタンスが自動的に再起動される間、短時間の停止が発生します。
詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
DB インスタンスから `APEX` オプションと `APEX-DEV` オプションを削除すると、APEX スキーマがデータベースから削除されます。
# Amazon EFS の統合
Amazon Elastic File System (Amazon EFS) は、サーバーレスで伸縮自在なファイルストレージを提供するため、ストレージ容量およびパフォーマンスのプロビジョニングや管理を行わずにファイルデータを共有できます。Amazon EFS では、ファイルシステムを作成し、NFS バージョン 4.0 および 4.1 (NFSv4) プロトコルを使用して VPC にマウントできます。そうすることで、他の POSIX 準拠のファイルシステムと同様に EFS ファイルシステムを使用できます。一般的な情報については、「[Amazon Elastic ファイルシステムとは](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)」および AWS ブログの「[Amazon RDS for Oracle と Amazon EFS の統合](https://aws.amazon.com//blogs/database/integrate-amazon-rds-for-oracle-with-amazon-efs/)」を参照してください。
**Topics**
+ [Amazon EFS 統合の概要](#oracle-efs-integration.overview)
+ [Amazon EFS と RDS for Oracle を統合するネットワークアクセス許可の設定](oracle-efs-integration.network.md)
+ [Amazon EFS と RDS for Oracle を統合する IAM アクセス許可の設定](oracle-efs-integration.iam.md)
+ [EFS\$1INTEGRATION (EFS 統合) オプションの追加](oracle-efs-integration.adding.md)
+ [Amazon EFS ファイルシステムのアクセス許可の設定](oracle-efs-integration.file-system.md)
+ [RDS for Oracle と Amazon EFS ファイルシステム間のファイルの転送](oracle-efs-integration.transferring.md)
+ [EFS\$1INTEGRATION (EFS 統合) オプションの削除](oracle-efs-integration.removing.md)
+ [Amazon EFS 統合のトラブルシューティング](oracle-efs-integration.troubleshooting.md)
## Amazon EFS 統合の概要
Amazon EFS では、RDS for Oracle DB インスタンスと Amazon EFS ファイルシステムの間でファイルを転送できます。例えば、EFS を使用して次のユースケースをサポートできます。
+ アプリケーションと複数のデータベースサーバー間でファイルシステムを共有します。
+ トランスポータブル表領域データファイルなど、移行関連ファイル用の共有ディレクトリを作成します。詳細については、「[Oracle トランスポータブル表領域を使用した移行](oracle-migrating-tts.md)」を参照してください。
+ サーバーに追加のストレージスペースを割り当てることなく、アーカイブされた REDO ログファイルを保存および共有できます。
+ `UTL_FILE` などの Oracle Database ユーティリティを使用してファイルの読み取りおよび書き込みを行います。
### Amazon EFS 統合のメリット
他のデータ転送ソリューションではなく EFS ファイルシステムを選択すると、次のようなメリットがあります。
+ Amazon EFS および RDS for Oracle DB インスタンスの間で Oracle Data Pump ファイルを転送できます。Data Pump は EFS ファイルシステムから直接インポートするため、これらのファイルをローカルにコピーする必要はありません。詳細については、「[Amazon RDS の Oracle にデータをインポートする](Oracle.Procedural.Importing.md)」を参照してください。
+ データ移行は、データベースリンクを使用するよりも高速です。
+ RDS for Oracle DB インスタンスで、ファイルを保存するためのストレージ容量を割り当てることが回避できます。
+ EFS ファイルシステムでは、ストレージをプロビジョニングしなくてもストレージを自動的にスケーリングできます。
+ Amazon EFS 統合には最低料金やセットアップ費用はありません。お支払いいただくのは、使用分の料金だけです。
+ Amazon EFS 統合は、転送時のデータの暗号化と保存時の暗号化の 2 つの形式の暗号化をサポートしています。転送時のデータの暗号化は、TLS バージョン 1.2 を使用してデフォルトで有効になっています。Amazon EFS ファイルシステムを作成する場合、保管時のデータの暗号化を有効にすることができます。詳細については、「*Amazon Elastic File System ユーザーガイド*」の「[保管中のデータの暗号化](https://docs.aws.amazon.com/efs/latest/ug/encryption-at-rest.html)」を参照してください。
### Amazon EFS 統合の要件
以下の要件を満たしていることを確認してください。
+ データベースは 19.0.0.0.ru-2022-07.rur-2022-07.r1 以降のデータベースを実行している必要があります。
+ DB インスタンスおよび EFS ファイルシステムは、同じ AWS リージョン、VPC、AWS アカウントである必要があります。RDS for Oracle は、EFS のクロスアカウントおよびクロスリージョンアクセスをサポートしていません。
+ VPC では **[DNS 解決]** と **[DNS ホスト名]** の両方を有効にする必要があります。詳細については、*Amazon Virtual Private Cloud ユーザーガイド*の「[DNS attributes for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-support)」(VPC の DNS 属性) を参照してください。
+ `mount` コマンドで DNS 名を使用する場合は、VPC が Amazon が提供する DNS サーバーを使用するように設定されていることを確認してください。カスタム DNS サーバーはサポートされていません。
+ RDS 以外のソリューションを使用して EFS ファイルシステムをバックアップする必要があります。RDS for Oracle は、EFS ファイルシステムの自動バックアップや手動 DB スナップショットをサポートしていません。詳細については、「[Amazon EFS ファイルシステムのバックアップ](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html)」を参照してください。
# Amazon EFS と RDS for Oracle を統合するネットワークアクセス許可の設定
RDS for Oracle を Amazon EFS と統合するには、DB インスタンスが EFS ファイルシステムにネットワークアクセスできることを確認してください。詳細については、*Amazon Elastic File System ユーザーガイド* の「[NFS クライアントの Amazon EFS ファイルシステムへのネットワークアクセス制御](https://docs.aws.amazon.com/efs/latest/ug/NFS-access-control-efs.html)」を参照してください。
**Topics**
+ [セキュリティグループによるネットワークアクセス制御](#oracle-efs-integration.network.inst-access)
+ [ファイルシステムポリシーによるネットワークアクセスの制御](#oracle-efs-integration.network.file-system-policy)
## セキュリティグループによるネットワークアクセス制御
VPC セキュリティグループなどのネットワーク層セキュリティメカニズムを使用して、DB インスタンスから EFS ファイルシステムへのアクセスを制御できます。DB インスタンスの EFS ファイルシステムへのアクセスを許可するには、EFS ファイルシステムが次の要件を満たしていることを確認してください。
+ EFS マウント ターゲットは、RDS for Oracle DB インスタンスによって使用されるすべてのアベイラビリティーゾーンにあります。
*EFS マウントターゲット*は、Amazon EFS ファイルシステムをマウントできる NFSv4 エンドポイントの IP アドレスを提供します。DNS 名を使用してファイルシステムをマウントすると、EC2 インスタンスと同じアベイラビリティーゾーンの EFS マウントターゲットの IP アドレスに解決されます。
別の AZ の DB インスタンスが同じ EFS ファイルシステムを使用するように設定できます。マルチ AZ の場合、配置内の AZ ごとにマウントポイントが必要です。別の AZ への DB への DB インスタンスの移動が必要になる場合があります。そのため、VPC 内の各 AZ で EFS マウントポイントを作成することをお勧めします。デフォルトでは、コンソールを使用して新しい EFS ファイルシステムを作成すると、RDS はすべての AZ のマウントターゲットを作成します。
+ セキュリティグループは、マウントターゲットにアタッチされます。
+ セキュリティグループには、TCP/2049 (タイプ NFS) で RDS for Oracle DB インスタンスのネットワークサブネットまたはセキュリティグループを許可するインバウンドルールがあります。
詳細については、「*Amazon Elastic File System ユーザーガイド*」の「[Creating Amazon EFS file systems](https://docs.aws.amazon.com/efs/latest/ug/creating-using-create-fs.html#configure-efs-network-access)」(Amazon EFS ファイルシステムの作成) と「[マウントターゲットとセキュリティグループの作成と管理](https://docs.aws.amazon.com/efs/latest/ug/accessing-fs.html)」を参照してください。
## ファイルシステムポリシーによるネットワークアクセスの制御
Amazon EFS と RDS for Oracle の統合は、デフォルト (空) のEFS ファイルシステムポリシーで動作します。デフォルトのポリシーでは、認証に IAM を使用しません。代わりに、マウントターゲットを使用して、ファイルシステムに接続できる匿名クライアントへのフルアクセスを許可します。デフォルトポリシーは、ファイルシステムの作成時を含め、ユーザーが設定したファイルシステムポリシーが有効ではない場合は常に有効になります。詳細については、*Amazon Elastic File System ユーザーガイド*の「[EFS ファイルシステムポリシー](https://docs.aws.amazon.com/efs/latest/ug/iam-access-control-nfs-efs.html#default-filesystempolicy)」を参照してください。
RDS for Oracle を含むすべてのクライアントの EFS ファイルシステムへのアクセスを強化するために、IAM アクセス許可を設定できます。この方法で、ファイルシステムポリシーを作成します。詳細については、*Amazon Elastic File System ユーザーガイド*の「[ファイルシステムポリシーの作成](https://docs.aws.amazon.com/efs/latest/ug/create-file-system-policy.html)」を参照してください。
# Amazon EFS と RDS for Oracle を統合する IAM アクセス許可の設定
デフォルトでは、Amazon EFS 統合機能は IAM ロールを使用しません。`USE_IAM_ROLE` オプション設定は `FALSE` です。RDS for Oracle と Amazon EFS および IAM ロールを統合するには、DB インスタンスが Amazon EFS ファイルシステムにアクセスするために IAM アクセス許可を持っている必要があります。
**Topics**
+ [ステップ 1: DB インスタンスの IAM ロールを作成し、ポリシーをアタッチする](#oracle-efs-integration.iam.role)
+ [ステップ 2: Amazon EFS ファイルシステムのファイルシステムポリシーを作成します。](#oracle-efs-integration.iam.policy)
+ [ステップ 3: IAM ロールを RDS for Oracle DB インスタンスに関連付ける](#oracle-efs-integration.iam.instance)
## ステップ 1: DB インスタンスの IAM ロールを作成し、ポリシーをアタッチする
このステップでは、RDS for Oracle DB インスタンスのロールを作成し、Amazon RDS が EFS ファイルシステムにアクセスできるようにします。
### コンソール
**Amazon RDS が EFS ファイルシステムへのアクセスを許可する IAM ロールを作成するには**
1. [IAM マネジメントコンソール](https://console.aws.amazon.com/iam/home?#home)を開きます。
1. ナビゲーションペインで **Roles (ロール) ** を選択してください。
1. [**Create role**] を選択します。
1. [**AWS のサービス**] で、[**RDS**] を選択します。
1. [**ユースケースの選択**] で、[**RDS - Add Role to Database (ロールをデータベースに追加する)**] を選択します。
1. [**次へ**] を選択します。
1. アクセス許可ポリシーを追加しないでください。[**次へ**] を選択します。
1. [**ロール名**] を IAM ロールの名前 (例: `rds-efs-integration-role`) に設定します。オプションで [**Description**] 値を追加することもできます。
1. [**ロールの作成**] を選択してください。
### AWS CLI
サービスのアクセス許可を特定のリソースに限定するには、リソースベースの信頼関係で [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) を使用します。
次の AWS CLI コマンドでは、この目的で `rds-efs-integration-role` という名前のロールを作成します。
**Example**
Linux、macOS、Unix の場合:
```
aws iam create-role \
--role-name rds-efs-integration-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": my_account_ID,
"aws:SourceArn": "arn:aws:rds:Region:my_account_ID:db:dbname"
}
}
}
]
}'
```
Windows の場合:
```
aws iam create-role ^
--role-name rds-efs-integration-role ^
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": my_account_ID,
"aws:SourceArn": "arn:aws:rds:Region:my_account_ID:db:dbname"
}
}
}
]
}'
```
詳細については、*IAM ユーザーガイド*の「[IAM ユーザーにアクセス許可を委任するロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)」を参照してください。
## ステップ 2: Amazon EFS ファイルシステムのファイルシステムポリシーを作成します。
このステップでは、EFS ファイルシステムのファイルシステムポリシーを作成します。
**EFS ファイルシステムポリシーを作成または編集するには**
1. [EFS 管理コンソール](https://console.aws.amazon.com/efs/home?#home)を開きます。
1. [**File Systems (ファイルシステム)**] を選択します。
1. [**File systems (ファイルシステム)**] ページで、ファイルシステムポリシーを編集または作成する対象のファイルシステムを選択します。そのファイルシステムの詳細ページが表示されます。
1. **[File system policy]** (ファイルシステムポリシー) タブを選択します。
ポリシーが空の場合は、デフォルトの EFS ファイルシステムポリシーが使用されます。詳細については、*Amazon Elastic File System ユーザーガイド*の「[EFS ファイルシステムポリシー](https://docs.aws.amazon.com/efs/latest/ug/iam-access-control-nfs-efs.html#default-filesystempolicy )」を参照してください。
1. **[編集]** を選択します。[**File system policy (ファイルシステムポリシー)**] ページが表示されます。
1. **[Policy editor]** (ポリシーエディタ) で次のようなポリシーを入力し、**[Save]** (保存) を選択します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "ExamplePolicy01",
"Statement": [
{
"Sid": "ExampleStatement01",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/rds-efs-integration-role"
},
"Action": [
"elasticfilesystem:ClientMount",
"elasticfilesystem:ClientWrite",
"elasticfilesystem:ClientRootAccess"
],
"Resource": "arn:aws:elasticfilesystem:us-east-1:123456789012:file-system/fs-1234567890abcdef0"
}
]
}
```
------
## ステップ 3: IAM ロールを RDS for Oracle DB インスタンスに関連付ける
このステップでは、IAM ロールを DB インスタンスに関連付けます。以下の要件に注意してください。
+ 必須の Amazon EFS アクセス許可ポリシーがアタッチされた IAM ロールへのアクセスが許可されている必要があります。
+ RDS for Oracle DB インスタンスには、一度に 1 つの IAM ロールのみを関連付けることができます。
+ インスタンスのステータスは **[Available]** (使用可能) である必要があります。
詳細については、*Amazon Elastic File System ユーザーガイド*の「[Amazon EFS の ID とアクセス管理](https://docs.aws.amazon.com/efs/latest/ug/auth-and-access-control.html)」を参照してください。
### コンソール
**IAM ロールを RDS for Oracle DB インスタンスに関連付けるには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. [**データベース**] をクリックします。
1. データベースインスタンスが使用できない場合は、[**Actions (アクション)**]、[**Start (スタート)**] の順に選択します。インスタンスのステータスに [**Started (スタート済み)**] と表示されたら、次のステップに進みます。
1. 詳細を表示する Oracle DB インスタンスの名前を選択します。
1. 「**接続性とセキュリティ**」 タブで、ページ下部の**IAM ロールを管理する** セクションまでスクロールダウンします。
1. **IAM ロールをこのインスタンスに追加する**セクションに追加するロールを選択します。
1. **[Feature]** (機能) で、**[EFS\$1INTEGRATION]** (EFS 統合) を選択します。
1. [**Add role**] を選択します。
### AWS CLI
以下の AWS CLI コマンドでは、`mydbinstance` という名前の Oracle DB インスタンスにこのロールを追加します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds add-role-to-db-instance \
--db-instance-identifier mydbinstance \
--feature-name EFS_INTEGRATION \
--role-arn your-role-arn
```
Windows の場合:
```
aws rds add-role-to-db-instance ^
--db-instance-identifier mydbinstance ^
--feature-name EFS_INTEGRATION ^
--role-arn your-role-arn
```
`your-role-arn` を、以前のステップで書き留めたロール ARN に置き換えます。`EFS_INTEGRATION` オプションには `--feature-name` が指定されている必要があります。
# EFS\$1INTEGRATION (EFS 統合) オプションの追加
Amazon RDS for Oracle と Amazon EFS を統合するには、DB インスタンスが `EFS_INTEGRATION` オプションを含むオプショングループに関連付けられている必要があります。
同じオプショングループに属する複数の Oracle DB インスタンスは、同じ EFS ファイルシステムを共有します。異なる DB インスタンスは同じデータにアクセスできますが、異なる Oracle ディレクトリを使用することでアクセスを分割できます。詳細については、「[RDS for Oracle と Amazon EFS ファイルシステム間のファイルの転送](oracle-efs-integration.transferring.md)」を参照してください。
## コンソール
**Amazon EFS 統合用のオプショングループを設定するには**
1. 新しいオプショングループを作成するか、`EFS_INTEGRATION` オプションを追加する既存のオプショングループを識別します。
オプショングループの作成の詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
1. オプショングループに [`EFS_INTEGRATION`] オプションを追加します。`EFS_ID` ファイルシステム ID を指定し、`USE_IAM_ROLE` フラグを設定する必要があります。
詳細については、「[オプショングループにオプションを追加する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption)」を参照してください。
1. 次のいずれかの方法を使用して、オプショングループを DB インスタンスに関連付けます。
+ 新しい Oracle DB インスタンスを作成して、オプショングループを関連付けます。DB インスタンスの作成については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ Oracle DB インスタンスを変更し、オプショングループを関連付けます。Oracle DB インスタンスの変更方法については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
## AWS CLI
**EFS 統合用のオプショングループを設定するには**
1. 新しいオプショングループを作成するか、`EFS_INTEGRATION` オプションを追加する既存のオプショングループを識別します。
オプショングループの作成の詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
1. オプショングループに [`EFS_INTEGRATION`] オプションを追加します。
例えば、以下の AWS CLI コマンドでは、`EFS_INTEGRATION` オプションを、**myoptiongroup** という名前のオプショングループに追加します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds add-option-to-option-group \
--option-group-name myoptiongroup \
--options "OptionName=EFS_INTEGRATION,OptionSettings=\
[{Name=EFS_ID,Value=fs-1234567890abcdef0},{Name=USE_IAM_ROLE,Value=TRUE}]"
```
Windows の場合:
```
aws rds add-option-to-option-group ^
--option-group-name myoptiongroup ^
--options "OptionName=EFS_INTEGRATION,OptionSettings=^
[{Name=EFS_ID,Value=fs-1234567890abcdef0},{Name=USE_IAM_ROLE,Value=TRUE}]"
```
1. 次のいずれかの方法を使用して、オプショングループを DB インスタンスに関連付けます。
+ 新しい Oracle DB インスタンスを作成して、オプショングループを関連付けます。DB インスタンスの作成については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ Oracle DB インスタンスを変更し、オプショングループを関連付けます。Oracle DB インスタンスの変更方法については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
# Amazon EFS ファイルシステムのアクセス許可の設定
デフォルトでは、ルートユーザー (UID `0`) のみが読み取り、書き込み、実行のアクセス許可を持ちます。他のユーザーがファイルシステムを変更できるようにするには、ルートユーザーは、明示的にアクセス許可を付与する必要があります。RDS for Oracle DB インスタンスのユーザーは `others` カテゴリに含まれます。詳細については、*Amazon Elastic File System ユーザーガイド*の「[ネットワークファイルシステム (NFS) レベルでのユーザー、グループ、アクセス許可の操作](https://docs.aws.amazon.com/efs/latest/ug/accessing-fs-nfs-permissions.html)」を参照してください。
RDS for Oracle DB インスタンスによって EFS ファイルシステムのファイルを読み書きできるようにするには、次の手順を実行します。
+ Amazon EC2 またはオンプレミスインスタンスに、EFS ファイルシステムをローカルでマウントします。
+ きめ細かいアクセス許可を設定します。
例えば、`other` ユーザーに EFS ファイルシステムのルートへの書き込み許可を付与するには、このディレクトリで `chmod 777` を実行します。詳細については、*Amazon Elastic File System ユーザーガイド*の「[Amazon EFS ファイルシステムのユースケースとアクセス許可の例](https://docs.aws.amazon.com/efs/latest/ug/accessing-fs-nfs-permissions.html#accessing-fs-nfs-permissions-ex-scenarios)」を参照してください。
# RDS for Oracle と Amazon EFS ファイルシステム間のファイルの転送
RDS for Oracle インスタンスと Amazon EFS ファイルシステム間でファイルを転送するには、Oracle ディレクトリを 1 つまたは複数作成し、DB インスタンスのアクセスを制御する EFS ファイルシステム権限を設定します。
**Topics**
+ [Oracle ディレクトリの作成](#oracle-efs-integration.transferring.od)
+ [EFS ファイルシステム間のデータ転送: 例](#oracle-efs-integration.transferring.upload)
## Oracle ディレクトリの作成
ディレクトリを作成するには、`rdsadmin.rdsadmin_util.create_directory_efs` のプロシージャを使用します。 プロシージャには以下のパラメータがあります。
****
| パラメータ名 | データ型 | デフォルト | 必須 | 説明 |
| --- | --- | --- | --- | --- |
| `p_directory_name` | VARCHAR2 | – | はい | Oracle ディレクトリの名前。 |
| `p_path_on_efs` | VARCHAR2 | – | はい | EFS ファイルシステムのパス。パス名のプレフィックスには `/rdsefs-fsid/` パターンが使用されています。*fsid* は EFS ファイルシステム ID のプレースホルダーです。 例えば、`fs-1234567890abcdef0` という名前の EFS ファイルシステムがあり、この `mydir` という名前のファイルシステムにサブディレクトリを作成する場合、次の値を指定できます。 /rdsefs-fs-1234567890abcdef0/mydir
|
`fs-1234567890abcdef0` という EFS ファイルシステムに、`/datapump1` という名前のサブディレクトリを作成したとします。次の例では、EFS ファイルシステムの `/datapump1` ディレクトリを指す Oracle ディレクトリ `DATA_PUMP_DIR_EFS` を作成しています。`p_path_on_efs` パラメータのファイルシステムパス値の先頭には文字列 `/rdsefs-` が付きます。
```
BEGIN
rdsadmin.rdsadmin_util.create_directory_efs(
p_directory_name => 'DATA_PUMP_DIR_EFS',
p_path_on_efs => '/rdsefs-fs-1234567890abcdef0/datapump1');
END;
/
```
## EFS ファイルシステム間のデータ転送: 例
次の例では、Oracle Data Pump を使用して、`MY_TABLE` という名前のテーブルを `datapump.dmp` ファイルにエクスポートしています。このファイルは EFS ファイルシステムにあります。
```
DECLARE
v_hdnl NUMBER;
BEGIN
v_hdnl := DBMS_DATAPUMP.OPEN(operation => 'EXPORT', job_mode => 'TABLE', job_name=>null);
DBMS_DATAPUMP.ADD_FILE(
handle => v_hdnl,
filename => 'datapump.dmp',
directory => 'DATA_PUMP_DIR_EFS',
filetype => dbms_datapump.ku$_file_type_dump_file);
DBMS_DATAPUMP.ADD_FILE(
handle => v_hdnl,
filename => 'datapump-exp.log',
directory => 'DATA_PUMP_DIR_EFS',
filetype => dbms_datapump.ku$_file_type_log_file);
DBMS_DATAPUMP.METADATA_FILTER(v_hdnl,'NAME_EXPR','IN (''MY_TABLE'')');
DBMS_DATAPUMP.START_JOB(v_hdnl);
END;
/
```
次の例では、Oracle Data Pump を使用して、`MY_TABLE` という名前のテーブルを `datapump.dmp` ファイルからインポートしています。このファイルは EFS ファイルシステムにあります。
```
DECLARE
v_hdnl NUMBER;
BEGIN
v_hdnl := DBMS_DATAPUMP.OPEN(
operation => 'IMPORT',
job_mode => 'TABLE',
job_name => null);
DBMS_DATAPUMP.ADD_FILE(
handle => v_hdnl,
filename => 'datapump.dmp',
directory => 'DATA_PUMP_DIR_EFS',
filetype => dbms_datapump.ku$_file_type_dump_file );
DBMS_DATAPUMP.ADD_FILE(
handle => v_hdnl,
filename => 'datapump-imp.log',
directory => 'DATA_PUMP_DIR_EFS',
filetype => dbms_datapump.ku$_file_type_log_file);
DBMS_DATAPUMP.METADATA_FILTER(v_hdnl,'NAME_EXPR','IN (''MY_TABLE'')');
DBMS_DATAPUMP.START_JOB(v_hdnl);
END;
/
```
詳細については、「[Amazon RDS の Oracle にデータをインポートする](Oracle.Procedural.Importing.md)」を参照してください。
# EFS\$1INTEGRATION (EFS 統合) オプションの削除
`EFS_INTEGRATION` オプションを削除する手順は、複数の DB インスタンスからオプションを削除するか、単一のインスタンスから削除するかによって異なります。
| DB インスタンス数 | アクション | 関連情報 |
| --- | --- | --- |
| 複数 | DB インスタンスが所属するオプショングループから EFS\$1INTEGRATION オプションを削除します。この変更は、そのオプショングループを使用するすべてのインスタンスに影響します。 | [オプショングループからオプションを削除する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.RemoveOption) |
| 単一 | DB インスタンスを修正して、EFS\$1INTEGRATION オプションが含まれない別オプショングループを指定します。デフォルト (空) のオプショングループや別のカスタムオプショングループを指定できます。 | [Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md) |
`EFS_INTEGRATION` オプションを削除した後、オプションで、DB インスタンスに接続された EFS ファイルシステムを削除できます。
# Amazon EFS 統合のトラブルシューティング
RDS for Oracle DB インスタンスは、Amazon EFS ファイルシステムとの接続をモニタリングしています。モニタリングによって問題が検出されると、その問題を修正して RDS コンソールにイベントを公開しようとする場合があります。詳細については、「[Amazon RDS イベントの表示](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ListEvents.html)」を参照してください。
このセクションの情報を使用して、Amazon EFS 統合を使用する際の一般的な問題の診断と修正を行います。
| Notification | 説明 | Action |
| --- | --- | --- |
| `The EFS for RDS Oracle instance instance_name isn't available on the primary host. NFS port 2049 of your EFS isn't reachable.` | DB インスタンスが、EFS ファイルシステムと通信できない。 | 以下を確認してください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/oracle-efs-integration.troubleshooting.html) |
| `The EFS isn't reachable.` | `EFS_INTEGRATION` オプションのインストール中にエラーが発生した。 | 以下を確認してください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/oracle-efs-integration.troubleshooting.html) |
| `The associated role with your DB instance wasn't found.` | `EFS_INTEGRATION` オプションのインストール中にエラーが発生した。 | IAM ロールが RDS for Oracle DB インスタンスに関連付けられていることを確認してください。 |
| `The associated role with your DB instance wasn't found.` | `EFS_INTEGRATION` オプションのインストール中にエラーが発生した。RDS for Oracle は、`USE_IAM_ROLE` オプション設定が `TRUE` の DB スナップショットから復元されました。 | IAM ロールが RDS for Oracle DB インスタンスに関連付けられていることを確認してください。 |
| `The associated role with your DB instance wasn't found.` | `EFS_INTEGRATION` オプションのインストール中にエラーが発生した。RDS for Oracle は、`USE_IAM_ROLE` オプション設定が `TRUE` のオールインワン CloudFormation テンプレートから作成されました。 | 回避策として、以下のステップを実行します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/oracle-efs-integration.troubleshooting.html) |
| `PLS-00302: component 'CREATE_DIRECTORY_EFS' must be declared` | このエラーは、Amazon EFS をサポートしていないバージョンの RDS for Oracle を使用している場合に発生する可能性があります。 | RDS for Oracle DB インスタンスのバージョン 19.0.0.0.ru-2022-07.rur-2022-07.r1 以降を使用していることを確認してください。 |
| `Read access of your EFS is denied. Check your file system policy.` | DB インスタンスは EFS ファイルシステムを読み取ることができません。 | EFS ファイルシステムが IAM ロールまたは EFS ファイルシステムレベルでの読み取りアクセスを許可していることを確認してください。 |
| 該当なし | DB インスタンスは EFS ファイルシステムに書き込むことができません。 | 次のステップを実行します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/oracle-efs-integration.troubleshooting.html) |
# Oracle Java Virtual Machine
Amazon RDS は、`JVM` オプションを使用することで Oracle Java Virtual Machine (JVM) をサポートします。Oracle Java では、SQL スキーマと関数が提供され、Oracle データベース内で Oracle Java の機能を活用できます。詳細については、Oracle ドキュメントの「[Oracle Database における Java の概要](https://docs.oracle.com/database/121/JJDEV/chone.htm)」を参照してください。Oracle JVM は、Oracle Database 21c (21.0.0) および Oracle Database 19c (19.0.0) のすべてのバージョンで使用できます。
## Oracle JVM に関する考慮事項
Amazon RDS の Java 実装のアクセス許可セットは制限されています。マスターユーザーには `RDS_JAVA_ADMIN` ロールが付与されます。このロールでは、`JAVA_ADMIN` ロールによって付与される特権のサブセットを付与します。`RDS_JAVA_ADMIN` ロールに付与される特権を一覧表示するには、DB インスタンスで次のクエリを実行します。
```
SELECT * FROM dba_java_policy
WHERE grantee IN ('RDS_JAVA_ADMIN', 'PUBLIC')
AND enabled = 'ENABLED'
ORDER BY type_name, name, grantee;
```
## Oracle JVM の前提条件
Oracle Java を使用するための前提条件は次のとおりです。
+ DB インスタンスが十分な大きさのクラスである必要があります。Oracle Java は、db.t3.small DB インスタンスクラスではサポートされていません。詳細については、「[ DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。
+ DB インスタンスで [**マイナーバージョン自動アップグレード**] が有効になっている必要があります。このオプションにより、リリースされた DB エンジンのマイナーバージョンアップグレードが、自動的に DB インスタンスに適用されるようになります。Amazon RDS では、このオプションを使用して、DB インスタンスに対し最新の Oracle パッチセット更新 (PSU)、またはリリース更新 (RU) を行います。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
## Oracle JVM のベストプラクティス
Oracle Java を使用するためのベストプラクティスは次のとおりです。
+ セキュリティを最大にするためには、`JVM` オプションを Secure Sockets Layer (SSL) で使用します。詳細については、「[Oracle Secure Sockets Layer](Appendix.Oracle.Options.SSL.md)」を参照してください。
+ ネットワークアクセスを制限するように、DB インスタンスを設定します。詳細については、「[VPC の DB インスタンスにアクセスするシナリオ](USER_VPC.Scenarios.md)」および「[VPC 内の DB インスタンスの使用](USER_VPC.WorkingWithRDSInstanceinaVPC.md)」を参照してください。
+ 次の条件を満たす場合は、TLSv1.2 をサポートするように HTTPS エンドポイントの設定を更新します。
+ Oracle Java Virtual Machine (JVM) を使用して、TLSv1 または TLSv1.1 プロトコルを介して HTTPS エンドポイントを接続します。
+ エンドポイントは TLSv1.2 プロトコルをサポートしていません。
+ 2021 年 4 月リリースの更新を Oracle DB に適用していません。
エンドポイント設定を更新することで、HTTPS エンドポイントへの JVM の接続が確実に引き続き機能するようにします。Oracle JRE および JDK の TLS の変更の詳細については、[Oracle JRE and JDK Cryptographic Roadmap](https://java.com/en/jre-jdk-cryptoroadmap.html) を参照してください。
## Oracle JVM オプションの追加
DB インスタンスに `JVM` オプションを追加する一般的な手順は以下のとおりです。
1. 新しいオプショングループを作成するか、既存のオプショングループをコピーまたは変更します。
1. オプショングループに [] オプションを追加します。
1. オプショングループを DB インスタンスに関連付けます。
`JVM` オプションが追加されるあいだ、短い停止が発生します。オプションを追加した後に DB インスタンスを再起動する必要はありません。オプショングループがアクティブになると、すぐに Oracle Java が使用可能となります。
**注記**
この停止中、パスワード検証機能は一時的に無効になります。また、停止中にパスワード検証機能に関連するイベントを確認することもできます。Oracle DB インスタンスが使用可能になる前に、パスワード検証機能が再び有効になります。
**JVM オプションを DB インスタンスに追加するには**
1. 使用するオプショングループを決定します。新しいオプショングループを作成することも、既存のオプショングループを使用することもできます。既存のオプショングループを使用する場合は、次のステップは飛ばしてください。または、次の設定でカスタム DB オプショングループを作成します。
+ [**Engine (エンジン)**] に、DB インスタンスによって使用される DB エンジン ([**oracle-ee**]、[**oracle-se**]、[**oracle-se1**]、または [**oracle-se2**]) を選択します。
+ [**メジャーエンジンのバージョン**] で、DB インスタンスのバージョンを選択します。
詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
1. オプショングループに [**JVM**] オプションを追加します。オプションの追加方法の詳細については、「[オプショングループにオプションを追加する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption)」を参照してください。
1. 新規または既存の DB インスタンスに、DB オプショングループを適用します。
+ 新しい DB インスタンスの場合は、インスタンスを起動するときにオプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の DB インスタンスの場合は、インスタンスを修正し、新しいオプショングループを添付することで、オプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
1. ユーザーに必要なアクセス権限を付与します。
Amazon RDS マスターユーザーには、`JVM` オプションを使用するアクセス許可がデフォルトで付与されています。他のユーザーがこれらのアクセス許可を必要とする場合は、SQL クライアントのマスターユーザーとして DB インスタンスに接続し、そのユーザーにアクセス許可を付与します。
次の例では、`JVM` オプションを使用するアクセス許可を `test_proc` ユーザーに付与しています。
```
create user test_proc identified by password;
CALL dbms_java.grant_permission('TEST_PROC', 'oracle.aurora.security.JServerPermission', 'LoadClassInPackage.*', '');
```
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
ユーザーにアクセス許可が付与されると、次のクエリで出力が返されます。
```
select * from dba_java_policy where grantee='TEST_PROC';
```
**注記**
Oracle ユーザー名では大文字と小文字が区別され、通常すべて大文字が使用されます。
## Oracle JVM オプションの削除
DB インスタンスから `JVM` オプションを削除できます。オプションが削除されるあいだ、短い停止が発生します。`JVM` オプションを削除した後に DB インスタンスを再起動する必要はありません。
**警告**
`JVM` オプションを削除すると、DB インスタンスがオプションの一部として有効であったデータ型を使用している場合、データ損失が発生する可能性があります。続行する前にデータをバックアップしてください。詳細については、「[データのバックアップ、復元、エクスポート](CHAP_CommonTasks.BackupRestore.md)」を参照してください。
`JVM` オプションを DB インスタンスから削除するには、次のいずれかを実行します。
+ `JVM` オプションを所属するオプショングループから削除します。この変更はそのオプショングループを使用するすべての DB インスタンスに影響します。詳細については、「[オプショングループからオプションを削除する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.RemoveOption)」を参照してください。
+ DB インスタンスを修正して、`JVM` オプションが含まれない別オプショングループを指定します。この変更は、単一の DB インスタンスに影響します。デフォルト (空) のオプショングループや別のカスタムオプショングループを指定できます。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
# Oracle Enterprise Manager
Amazon RDS は Oracle Enterprise Manager (OEM) をサポートしています。OEM は、エンタープライズ情報技術の統合管理用の Oracle 製品ラインです。
Amazon RDS は、Oracle Database 19c の非 CDB または CDB で OEM をサポートしています。次の表で、サポートされている OEM オプションについて説明します。
****
| オプション | オプション ID | サポートされている OEM のリリース |
| --- | --- | --- |
| [OEM Database Express](Appendix.Oracle.Options.OEM_DBControl.md) | `OEM` | OEM Database Express 19c |
| [OEM Management Agent](Oracle.Options.OEMAgent.md) | `OEM_AGENT` | OEM Cloud Control for 13c |
**注記**
OEM Database または OEM Management Agent を使用できますが、両方を使用することはできません。
# Oracle Enterprise Manager Database Express
Amazon RDS は OEM オプションの使用を通じて、Oracle Enterprise Manager Database Express (EM Express) をサポートします。Amazon RDS は、CDB または非 CDB アーキテクチャを使用する EM Express for Oracle Database 19c をサポートします。
EM Express は、データベースに含まれるウェブベースのデータベース管理ツールで、開いている場合のみ使用できます。主要なパフォーマンス管理機能と基本的なデータベース管理機能をサポートしています。詳細については、Oracle Database ドキュメントの「[Introduction to Oracle Enterprise Manager Database Express](https://docs.oracle.com/en/database/oracle/oracle-database/19/admqs/getting-started-with-database-administration.html#GUID-BA75AD46-D22E-4914-A31E-C395CD6A2BBA)」を参照してください。
**注記**
EM Express は、db.t3.small DB インスタンスクラスではサポートされていません。DB インスタンスクラスの詳細については、「[RDS for Oracle DB インスタンスクラス](Oracle.Concepts.InstanceClasses.md)」を参照してください。
## OEM オプション設定
Amazon RDS は、OEM オプションの次の設定をサポートします。
****
| オプション設定 | 有効な値 | 説明 |
| --- | --- | --- |
| **ポート** – | 整数値 | EM Express をリッスンする RDS for Oracle DB インスタンスのポート。デフォルトは 5500 です。 |
| ** セキュリティグループ** | — | [**Port**] へのアクセス権限を持つセキュリティグループ。 |
## ステップ 1: OEM オプションの追加
DB インスタンスに OEM オプションを追加する一般的な手順は以下のとおりです。
1. 新しいオプショングループを作成するか、既存のオプショングループをコピーまたは変更します。
1. オプショングループにオプションを追加します。
1. オプショングループを DB インスタンスに関連付けます。
OEM オプションを追加する場合、DB インスタンスが自動的に再起動する間に短い停止が発生します。
**OEM オプションを DB インスタンスに追加するには**
1. 使用するオプショングループを決定します。新しいオプショングループを作成することも、既存のオプショングループを使用することもできます。既存のオプショングループを使用する場合は、次のステップは飛ばしてください。または、次の設定でカスタム DB オプショングループを作成します。
1. [**Engine**] で DB インスタンスの Oracle エディションを選択します。
1. [**メジャーエンジンのバージョン**] で、DB インスタンスのバージョンを選択します。
詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
1. オプショングループに OEM オプションを追加し、オプションを設定します。オプションの追加方法の詳細については、「[オプショングループにオプションを追加する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption)」を参照してください。各設定の詳細については、「[OEM オプション設定](#Appendix.Oracle.Options.OEM_DBControl.Options)」を参照してください。
**注記**
すでに 1 つ以上の DB インスタンスにアタッチされている既存のオプショングループに OEM オプションを追加すると、すべての DB インスタンスが自動的に再起動する間に短い停止が発生します。
1. 新規または既存の DB インスタンスに、DB オプショングループを適用します。
+ 新しい DB インスタンスの場合は、インスタンスを起動するときにオプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の DB インスタンスの場合は、インスタンスを修正し、新しいオプショングループを添付することで、オプショングループを適用します。OEM オプションを追加する場合、DB インスタンスが自動的に再起動する間に短い停止が発生します。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
**注記**
AWS CLI を使用して OEM オプションを追加することもできます。例については、「[オプショングループにオプションを追加する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption)」を参照してください。
## ステップ 2: (CDB のみ) DBSNMP ユーザーアカウントのロック解除
DB インスタンスが CDB アーキテクチャを使用している場合は、EM Express に `DBSNMP` としてログインする必要があります。CDB では、`DBSNMP` は共通ユーザーです。デフォルトでは、このアカウントはロックされています。DB インスタンスが CDB アーキテクチャを使用しない場合は、このステップをスキップします。
**CDB インスタンスで DBSNMP ユーザーアカウントをロック解除するには**
1. SQL\$1Plus または別の Oracle SQL アプリケーションで、マスターユーザーとして DB インスタンスにログインします。
1. 次のストアドプロシージャを実行して、`DBSNMP` アカウントのロックを解除します。
```
1. EXEC rdsadmin.rdsadmin_util.reset_oem_agent_password('new_password');
```
プロシージャが存在しないことを示すエラーが表示された場合は、CDB インスタンスを再起動して自動的にインストールします。詳細については、「[ DB インスタンスの再起動](USER_RebootInstance.md)」を参照してください。
## ステップ 3: ブラウザから EM Express にアクセスする
ウェブブラウザから EM Express にアクセスすると、ログインウィンドウが表示され、ユーザー名とパスワードを求められます。
**ブラウザから EM Express にアクセスするには**
1. Amazon RDS DB インスタンスのエンドポイントと EM Express ポートを特定します。Amazon RDS DB インスタンスのエンドポイントを見つける方法については、「[RDS for Oracle DB インスタンスのエンドポイントを見つける](USER_Endpoint.md)」を参照してください。
1. ブラウザのロケーターバーに URL を次の形式で入力します。
```
https://endpoint.rds.amazonaws.com:port/em
```
例えば、Amazon RDS DB インスタンスのエンドポイントが `mydb.a1bcde234fgh.us-east-1.rds.amazonaws.com` で、EM Express ポートが `1158` の場合、EM Express にアクセスする URL は次のようになります。
```
1. https://mydb.f9rbfa893tft.us-east-1.rds.amazonaws.com:1158/em
```
1. ログインの詳細の入力を求められたら、データベースアーキテクチャに応じて、次のいずれかのアクションを実行します。
**データベースが非 CDB の場合**
DB インスタンスのマスターユーザー名とマスターパスワードを入力します。
**データベースが CDB の場合**
ユーザーに `DBSNMP` と入力し、`DBSNMP` のパスワードを入力します。`Container` フィールドは空白のままにします。
## OEM データベース設定の変更
OEM データベースを有効にすると、オプションのセキュリティグループ設定を変更できます。
オプショングループを DB インスタンスに関連付けた後に OEM ポート番号を変更することはできません。DB インスタンスの OEM ポート番号を変更するには、以下の作業を行います。
1. 新しいオプショングループを作成します。
1. 新しいポート番号の OEM オプションを新しいオプショングループに追加します。
1. DB インスタンスから既存のオプショングループを削除します。
1. 新しいオプショングループを DB インスタンスに追加します。
オプション設定の変更方法の詳細については、「[オプションの設定を変更する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.ModifyOption)」を参照してください。各設定の詳細については、「[OEM オプション設定](#Appendix.Oracle.Options.OEM_DBControl.Options)」を参照してください。
## OEM Database Express タスクの実行
Amazon RDS プロシージャを使用して、特定の OEM Database Express のタスクを実行できます。これらの手順を実行すると、以下のタスクを実行できます。
**注記**
OEM Database Express のタスクは非同期で実行されます。
**Topics**
+ [OEM Database Express のウェブサイトフロントエンドを Adobe Flash に切り替える](#Appendix.Oracle.Options.OEM_DBControl.DBTasks.FrontEndToFlash)
+ [OEM Database Express のウェブサイトフロントエンドを Oracle JET に切り替える](#Appendix.Oracle.Options.OEM_DBControl.DBTasks.FrontEndToOracleJET)
### OEM Database Express のウェブサイトフロントエンドを Adobe Flash に切り替える
**注記**
このタスクは、Oracle Database 19c 非 CDB でのみ使用できます。
Oracle Database 19c 以降では、以前の OEM Database Express ユーザーインターフェイスは非推奨になりました。このユーザーインターフェイスは Adobe Flash に基づいていました。代わりに、OEM Database Express は Oracle JET で構築されたインターフェイスを使用するようになりました。新しいインターフェイスで問題が発生した場合は、非推奨の Flash ベースのインターフェイスに戻すことができます。新しいインターフェイスで発生する可能性のある問題として、OEM Database Express にログインした後に `Loading` 画面が停止することがあります。また、Flash ベースのバージョンの OEM Database Express に存在していた特定の機能を見逃す可能性もあります。
OEM Database Express のウェブサイトフロントエンドを Adobe Flash に切り替えるには、Amazon RDS プロシージャ`rdsadmin.rdsadmin_oem_tasks.em_express_frontend_to_flash` を実行します 。このプロシージャは、`execemx emx` SQL コマンドに相当します。
セキュリティのベストプラクティスでは、Adobe Flash の使用は推奨されていません。Flash ベースの OEM Database Express に戻すことはできますが、可能であれば、JET ベースの OEM Database Express のウェブサイトを使用することをお勧めします。Adobe Flash を使用するように戻した後で、Oracle JET の使用に切り替える場合は、 `rdsadmin.rdsadmin_oem_tasks.em_express_frontend_to_jet` プロシージャを使用します。Oracle データベースにアップグレードすると、新しいバージョンの Oracle JET では、OEM Database Express の JET 関連の問題が解決される場合があります。Oracle JET への切り替えの詳細については、「[OEM Database Express のウェブサイトフロントエンドを Oracle JET に切り替える](#Appendix.Oracle.Options.OEM_DBControl.DBTasks.FrontEndToOracleJET)」を参照してください。
**注記**
リードレプリカの出典 DB インスタンスからこのタスクを実行すると、リードレプリカは OEM Database Express ウェブサイトフロントエンドを Adobe Flash に切り替えます。
次のプロシージャの呼び出しでは、OEM Database Express ウェブサイトを Adobe Flash に切り替えるタスクを作成し、タスクの ID を返します。
```
SELECT rdsadmin.rdsadmin_oem_tasks.em_express_frontend_to_flash() as TASK_ID from DUAL;
```
タスクの出力ファイルを表示すると、結果を確認できます。
```
SELECT text FROM table(rdsadmin.rds_file_util.read_text_file('BDUMP','dbtask-task-id.log'));
```
*`task-id`* は、この手順で返されたタスク ID に置き換えます。Amazon RDS プロシージャ `rdsadmin.rds_file_util.read_text_file` の詳細については、「[DB インスタンスディレクトリ内のファイルの読み取り](Appendix.Oracle.CommonDBATasks.Misc.md#Appendix.Oracle.CommonDBATasks.ReadingFiles)」を参照してください。
AWS マネジメントコンソール の [**ログとイベント** ] セクションでログエントリを検索して、タスクの出力ファイルの内容を `task-id` に表示することもできます。
### OEM Database Express のウェブサイトフロントエンドを Oracle JET に切り替える
**注記**
このタスクは、Oracle Database 19c 非 CDB でのみ使用できます。
OEM Database Express のウェブサイトフロントエンドを Oracle JET に切り替えるには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_oem_tasks.em_express_frontend_to_jet` を実行します。このプロシージャは、`execemx omx` SQL コマンドに相当します。
デフォルトでは、19c 以降を実行している Oracle DB インスタンス用の OEM Database Express ウェブサイトは Oracle JET を使用します。`rdsadmin.rdsadmin_oem_tasks.em_express_frontend_to_flash` プロシージャを使用して OEM Database Express のウェブサイトフロントエンドを Adobe Flash に切り替えた場合は、Oracle JET に戻すことができます。これを行うには、`rdsadmin.rdsadmin_oem_tasks.em_express_frontend_to_jet` プロシージャを使用します。Adobe Flash への切り替えの詳細については、「[OEM Database Express のウェブサイトフロントエンドを Adobe Flash に切り替える](#Appendix.Oracle.Options.OEM_DBControl.DBTasks.FrontEndToFlash)」を参照してください。
**注記**
リードレプリカの出典 DB インスタンスからこのタスクを実行すると、リードレプリカによって OEM Database Express ウェブサイトフロントエンドが Oracle JET に切り替わります。
次のプロシージャの呼び出しでは、OEM Database Express ウェブサイトを Oracle JET に切り替えるタスクを作成し、タスクの ID を返します。
```
SELECT rdsadmin.rdsadmin_oem_tasks.em_express_frontend_to_jet() as TASK_ID from DUAL;
```
タスクの出力ファイルを表示すると、結果を確認できます。
```
SELECT text FROM table(rdsadmin.rds_file_util.read_text_file('BDUMP','dbtask-task-id.log'));
```
*`task-id`* は、この手順で返されたタスク ID に置き換えます。Amazon RDS プロシージャ `rdsadmin.rds_file_util.read_text_file` の詳細については、「[DB インスタンスディレクトリ内のファイルの読み取り](Appendix.Oracle.CommonDBATasks.Misc.md#Appendix.Oracle.CommonDBATasks.ReadingFiles)」を参照してください。
AWS マネジメントコンソール の [**ログとイベント** ] セクションでログエントリを検索して、タスクの出力ファイルの内容を `task-id` に表示することもできます。
## OEM データベースオプションの削除
DB インスタンスから OEM オプションを削除できます。OEM オプションを削除する場合、インスタンスが自動的に再起動する間に短い停止が発生します。そのため、OEM オプションを削除した後に DB インスタンスを再起動する必要はありません。
OEM オプションを DB インスタンスから削除するには、次のいずれかを実行します。
+ OEM オプションを、所属するオプショングループから削除します。この変更はそのオプショングループを使用するすべての DB インスタンスに影響します。詳細については、「[オプショングループからオプションを削除する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.RemoveOption)」を参照してください。
+ DB インスタンスを修正して、OEM オプションが含まれない別オプショングループを指定します。この変更は、単一の DB インスタンスに影響します。デフォルト (空) のオプショングループや別のカスタムオプショングループを指定できます。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
# Enterprise Manager Cloud Control 向け Oracle Management Agent
Oracle Enterprise Manager (OEM) Management Agent は、ホスト上で実行中のターゲットをモニタリングし、その情報を中間層 Oracle Management Service (OMS) に送信するソフトウェアコンポーネントです。Amazon RDS は `OEM_AGENT` オプションを使用して Management Agent をサポートします。
詳細については、Oracle ドキュメントの「[Oracle Enterprise Manager Cloud Control 12c の概要](http://docs.oracle.com/cd/E24628_01/doc.121/e25353/overview.htm)」と「[Oracle Enterprise Manager Cloud Control 13c の概要](http://docs.oracle.com/cd/E63000_01/EMCON/overview.htm#EMCON109)」を参照してください。
**Topics**
+ [Management Agent の要件](#Oracle.Options.OEMAgent.PreReqs)
+ [OMS ホスト通信の前提条件](#Oracle.Options.OEMAgent.PreReqs.host)
+ [Management Agent の制限](#Oracle.Options.OEMAgent.limitations)
+ [Management Agent のオプション設定](#Oracle.Options.OEMAgent.Options)
+ [Management Agent オプションを DB インスタンス用に有効にする](#Oracle.Options.OEMAgent.Enable)
+ [Management Agent オプションの削除](#Oracle.Options.OEMAgent.Remove)
+ [Management Agent を使用したデータベースタスクの実行](#Oracle.Options.OEMAgent.DBTasks)
## Management Agent の要件
以下は、Management Agent を使用するための一般的な要件です。
+ DB インスタンスは Oracle Database 19c (19.0.0.0) を実行している必要があります。CDB アーキテクチャまたは非 CDB アーキテクチャのいずれかを使用できます。
+ DB インスタンスに接続するように設定されている Oracle Management Service (OMS) が必要です。次の OMS 要件に注意してください。
+ Management Agent のバージョン 13.5.0.0.v2 および 13.5.0.0.v3 には、OMS バージョン 13.5.0.23 または 24.1 が必要です。
+ Management Agent のバージョン 13.5.0.0.v1 には、OMS バージョン 13.5.0.0 または 24.1 が必要です。
+ Management Agent のバージョン 13.4.0.9.v1 および 13.4.0.9.v2 には、OMS バージョン 13.4.0.9 以降と 32198287 のパッチが必要です。
+ ほとんどの場合、OMS から DB インスタンスへの接続を許可するように VPC を設定する必要があります。Amazon Virtual Private Cloud (Amazon VPC) についてあまり詳しくない場合は、「[チュートリアル: DB インスタンスで使用する VPC を作成する (IPv4 専用)](CHAP_Tutorials.WebServerDB.CreateVPC.md)」のステップを完了してから続行することをお勧めします。
+ Management Agent は、Oracle Enterprise Manager Cloud Control for 12c および 13c で使用できます。OEM リリース用の十分なストレージ領域があることを確認します。
+ OEM 13c リリース 5 では 8.5 GiB 以上
+ OEM 13c リリース 4 では 8.5 GiB 以上
+ OEM 13c リリース 3 では 8.5 GiB 以上
+ OEM 13c リリース 2 では 5.5 GiB 以上
+ OEM 13c リリース 1 では 4.5 GiB 以上
+ OEM 12c では 2.5 GiB 以上
+ Management Agent バージョン `OEM_AGENT 13.2.0.0.v3` および `13.3.0.0.v2` を使用している場合、また、TCPS 接続を使用する場合は、Oracle ドキュメントの「[ターゲットデータベースと通信するためのサードパーティー CA 証明書の設定](https://docs.oracle.com/cd/E73210_01/EMSEC/GUID-8337AD48-1A32-4CD5-84F3-256FAE93D043.htm#EMSEC15996)」の手順に従ってください。また、Oracle Doc ID 2241358.1 の Oracle のドキュメントの指示に従って、OMS の JDK を更新します。このステップにより、データベースがサポートするすべての暗号スイートが OMS でサポートされるようになります。
**注記**
Management Agent と DB インスタンス間の TCPS 接続は、Management Agent の `OEM_AGENT 13.2.0.0.v3`、`13.3.0.0.v2`、`13.4.0.9.v1` 以上のバージョンでサポートされます。
## OMS ホスト通信の前提条件
OMS ホストと Amazon RDS DB インスタンスが通信できることを確認してください。以下の操作を実行します。
+ OMS ホストがファイアウォールの内側にある場合、Management Agent から OMS ホストに接続するには、ファイアウォール に DB インスタンスの IP アドレスを追加します。OMS のファイアウォールで次のネットワークトラフィックが許可されていることを確認します。
OMS ホストから DB インスタンスへ
OMS ホストからデータベースリスナーポート (デフォルトは 1521) および OEM エージェントポート (デフォルトは 3872) へのトラフィックを許可する一方向ファイアウォールルールを設定します。
DB インスタンスから OMS ホストへ
DB インスタンスから OMS HTTP ポート (デフォルトは 4903) へのトラフィックを許可する一方向ファイアウォールルールを設定します。
+ OMS にパブリックに解決可能なホスト名がある場合、OMS から Management Agent に接続するには、セキュリティグループに OMS アドレスを追加します。セキュリティグループには、DB リスナーポートと Management Agent ポートへのアクセスを許可するインバウンドルールが必要です。セキュリティの作成とインバウンドルールの追加の例については、「[チュートリアル: DB インスタンスで使用する VPC を作成する (IPv4 専用)](CHAP_Tutorials.WebServerDB.CreateVPC.md)」を参照してください。
+ OMS にパブリックに解決可能なホスト名がない場合、OMS から Management Agent に接続するには、以下のいずれかを使用します。
+ OMS がプライベート VPC の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスでホストされている場合、VPC ペアリングを設定して OMS から Management Agent に接続できます。詳細については、「[VPC 内の DB インスタンスに別の VPC 内の EC2 インスタンスからアクセスする](USER_VPC.Scenarios.md#USER_VPC.Scenario3)」を参照してください。
+ OMS がオンプレミスでホストされている場合、VPN 接続を設定して OMS から Management Agent へのアクセスを許可できます。VPN 接続の詳細については、「[インターネット経由でクライアントアプリケーションから VPC 内の DB インスタンスにアクセスする](USER_VPC.Scenarios.md#USER_VPC.Scenario4)」または「[VPN 接続](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html)」を参照してください。
+ OEM Management Agent バージョン 13.5.0.0 (v1-v3) を 24.1 OMS ホストに接続するには、設定オプション `TLSv1.2` で TLS 1.2 プロトコルを使用するように `MINIMUM_TLS_VERSION` を設定します。
## Management Agent の制限
Management Agent の使用にあたってのいくつかの制限を以下に挙げます。
+ カスタム Oracle Management Agent イメージを指定することはできません。
+ ジョブの実行やデータベースのパッチなど、ホスト認証情報を必要とする管理タスクはサポートされません。
+ ホストメトリクスおよびプロセスリストが実際のシステムの状態を反映しているかは、保証されていません。したがって、OEM を使用してルートファイルシステムまたはマウントポイントファイルシステムをモニタリングしないでください。オペレーティングシステムのモニタリングの詳細については、「[拡張モニタリングを使用した OS メトリクスのモニタリング](USER_Monitoring.OS.md)」を参照してください。
+ 自動検出はサポートされていません。手動でデータベースターゲットを追加する必要があります。
+ OMS モジュールの可用性はデータベースのエディションによって異なります。例えば、データベースのパフォーマンス診断およびモジュール調整は、Oracle Database Enterprise Edition でのみ使用できます。
+ Management Agent は増設メモリとコンピューティングリソースを消費します。`OEM_AGENT` オプションを有効にしてパフォーマンスの問題が発生する場合、DB インスタンスのクラスをスケールアップすることをお勧めします。詳細については、「[ DB インスタンスクラス](Concepts.DBInstanceClass.md)」および「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
+ Amazon RDS ホストで `OEM_AGENT` を実行しているユーザーには、アラートログへのオペレーティングシステムアクセス権がありません。したがって、OEM の `DB Alert Log` と `DB Alert Log Error Status` のメトリクスを収集することはできません。
## Management Agent のオプション設定
Amazon RDS は Management Agent オプションの次の設定をサポートします。
| オプション設定 | 必須 | 有効な値 | 説明 |
| --- | --- | --- | --- |
| **バージョン** (`AGENT_VERSION`) | はい | `13.5.0.0.v3` `13.5.0.0.v2` `13.5.0.0.v1` `13.4.0.9.v2` `13.4.0.9.v1` `13.3.0.0.v2` `13.3.0.0.v1` `13.2.0.0.v3` `13.2.0.0.v2` `13.2.0.0.v1` `13.1.0.0.v1` | Management Agent ソフトウェアのバージョン。サポートされる最小のバージョンは、`13.1.0.0.v1` です。 AWS CLI オプション名は `OptionVersion` です。 AWS GovCloud (US) リージョンでは、13.1 バージョンは利用できません。 |
| **ポート** (`AGENT_PORT`) | はい | 整数値 | OMS ホストをリッスンする DB インスタンスのポート。デフォルトは 3872 です。OMS ホストは、このポートへのアクセス権限があるセキュリティグループに属さなければなりません。 AWS CLI オプション名は `Port` です。 |
| ** セキュリティグループ** | はい | 既存のセキュリティグループ | [**Port**] へのアクセス権限を持つセキュリティグループ。OMS ホストは、このセキュリティグループに属さなければなりません。 AWS CLI オプション名は `VpcSecurityGroupMemberships` または `DBSecurityGroupMemberships` です。 |
| **OMS\$1HOST** | はい | 文字列値、例えば *my.example.oms* | OMS のパブリックに解決可能なホスト名または IP アドレスです。 AWS CLI オプション名は `OMS_HOST` です。 |
| **OMS\$1PORT** | はい | 整数値 | Management Agent をリッスンする OMS ホストの HTTPS アップロードポート。 HTTPS アップロードポートを確認するには、OMS ホストに接続し、次のコマンドを実行します (`SYSMAN` のパスワードが必要)。 emctl status oms -details AWS CLI オプション名は `OMS_PORT` です。 |
| **AGENT\$1REGISTRATION\$1PASSWORD** | はい | 文字列値 | Management Agent が OMS に対して自身を認証するために使用するパスワード。`OEM_AGENT` オプションを有効化する前に、OMS に永続的なパスワードを作成することをお勧めします。永続的なパスワードを使用すると、複数の Amazon RDS データベース間で、Management Agent オプショングループを共有できます。 AWS CLI オプション名は `AGENT_REGISTRATION_PASSWORD` です。 |
| **ALLOW\$1TLS\$1ONLY** | いいえ | `true`、`false` (デフォルト値) | エージェントがサーバーとしてリッスンしている間 `TLSv1` プロトコルのみをサポートするように、OEM エージェントを構成する値。この設定はサポートされなくなりました。Management Agent バージョン 13.1.0.0.v1 以降では、デフォルトで Transport Layer Security (TLS) がサポートされています。 |
| **MINIMUM\$1TLS\$1VERSION** | いいえ | `TLSv1` (デフォルト)`TLSv1.2` | エージェントがサーバーとしてリッスンしている間 OEM エージェントがサポートする、最小 TLS バージョンを指定する値。サポートされなくなったエージェントバージョンでは、`TLSv1` 設定のみがサポートされています。 13.5.0.0 (v1-v3) を 24.1 OMS ホストに接続するには、これを `TLSv1.2` に設定します。 |
| **TLS\$1CIPHER\$1SUITE** | いいえ | 「[Management Agent のオプション設定](#Oracle.Options.OEMAgent.Options)」を参照してください。 | エージェントがサーバーとしてリッスンしている間 OEM エージェントによって使用される、TLS 暗号スイートを指定する値。 |
次の表は、Management Agent オプションがサポートする TLS 暗号スイートの一覧です。
| 暗号スイート | サポートされる Agent のバージョン | FedRAMP 準拠 |
| --- | --- | --- |
| TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | すべて | いいえ |
| TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256 | 13.1.0.0.v1 以降 | いいえ |
| TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 13.2.0.0.v3 以降 | いいえ |
| TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA256 | 13.2.0.0.v3 以降 | いいえ |
| TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 13.2.0.0.v3 以降 | はい |
| TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 13.2.0.0.v3 以降 | はい |
| TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256 | 13.2.0.0.v3 以降 | はい |
| TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384 | 13.2.0.0.v3 以降 | はい |
| TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 | 13.4.0.9.v1 以降 | はい |
| TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384 | 13.4.0.9.v1 以降 | はい |
### 暗号スイートと証明書の互換性
RDS for Oracle は、RSA 証明書と楕円曲線デジタル署名アルゴリズム (ECDSA) 証明書の両方をサポートしています。DB インスタンスの OEM エージェントオプションを設定するときは、`TLS_CIPHER_SUITE` オプション設定で指定した暗号スイートが DB インスタンスで使用される証明書タイプと互換性があることを確認する必要があります。
次の表は、証明書タイプと暗号スイート間の互換性を示しています。
| [証明書タイプ] | 互換性のある暗号スイート | 互換性のない暗号スイート |
| --- | --- | --- |
| RSA 証明書 (rds-ca-2019、rds-ca-rsa2048-g1、rds-ca-rsa4096-g1) | TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256 TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384 |
| ECDSA 証明書 (rds-ca-ecc384-g1) | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384 | TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256 TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384 |
`TLS_CIPHER_SUITE` オプション設定で暗号スイートを指定するときは、DB インスタンスで使用される証明書タイプと互換性があることを確認してください。DB インスタンスの証明書タイプと互換性のない暗号スイートを含む OEM エージェントオプションにオプショングループを関連付けようとすると、オペレーションは失敗し、非互換性を示すエラーメッセージが表示されます。
## Management Agent オプションを DB インスタンス用に有効にする
Management Agent オプションを有効にするには、次の手順を実行します。
**Topics**
+ [ステップ 1: DB インスタンスに Management Agent オプションを追加する](#Oracle.Options.OEMAgent.Add)
+ [ステップ 2: DBSNMP ユーザーアカウントのロックを解除する](#Oracle.Options.OEMAgent.DBSNMP)
+ [ステップ 3: Management Agent コンソールにターゲットを追加する](#Oracle.Options.OEMAgent.Using)
### ステップ 1: DB インスタンスに Management Agent オプションを追加する
Management Agent オプションを DB インスタンスに追加するには、次の手順を実行します。
1. 新しいオプショングループを作成するか、既存のオプショングループをコピーまたは変更します。
1. オプショングループに [] オプションを追加します。
1. オプショングループを DB インスタンスに関連付けます。
エラーが発生した場合は、特定の問題の解決に関する情報について、[My Oracle Support](https://support.oracle.com/) のドキュメントを確認します。
Management Agent オプションを追加した後に DB インスタンスを再起動する必要はありません。オプショングループがアクティブになると、すぐに OEM Agent がアクティブになります。
OMS ホストで信頼できないサードパーティーの証明書が使用されている場合は、Amazon RDS より次のエラーが返ります。
```
You successfully installed the OEM_AGENT option. Your OMS host is using an untrusted third party certificate.
Configure your OMS host with the trusted certificates from your third party.
```
このエラーが返った場合、Management Agent オプションは問題が解決するまで有効になりません。問題の修正については、My Oracle Support ドキュメント「[2202569.1](https://support.oracle.com/epmos/faces/DocContentDisplay?id=2202569.1)」を参照してください。
#### コンソール
**Management Agent オプションを DB インスタンスに追加するには**
1. 使用するオプショングループを決定します。新しいオプショングループを作成することも、既存のオプショングループを使用することもできます。既存のオプショングループを使用する場合は、次のステップは飛ばしてください。または、次の設定でカスタム DB オプショングループを作成します。
1. [**Engine**] で DB インスタンスの Oracle エディションを選択します。
1. [**メジャーエンジンのバージョン**] で、DB インスタンスのバージョンを選択します。
詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
1. オプショングループに [**OEM\$1AGENT**] オプションを追加し、オプションを設定します。オプションの追加方法の詳細については、「[オプショングループにオプションを追加する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption)」を参照してください。各設定の詳細については、「[Management Agent のオプション設定](#Oracle.Options.OEMAgent.Options)」を参照してください。
1. 新規または既存の DB インスタンスに、DB オプショングループを適用します。
+ 新規 DB インスタンスの場合は、インスタンスを起動するときにオプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の DB インスタンスの場合は、インスタンスを修正し、新しいオプショングループを添付することで、オプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
#### AWS CLI
次の例では、AWS CLI の [add-option-to-option-group](https://docs.aws.amazon.com/cli/latest/reference/rds/add-option-to-option-group.html) コマンドを使用して、`OEM_AGENT` オプションを `myoptiongroup` オプショングループに追加しています。
Linux、macOS、Unix の場合:
```
aws rds add-option-to-option-group \
--option-group-name "myoptiongroup" \
--options OptionName=OEM_AGENT,OptionVersion=13.1.0.0.v1,Port=3872,VpcSecurityGroupMemberships=sg-1234567890,OptionSettings=[{Name=OMS_HOST,Value=my.example.oms},{Name=OMS_PORT,Value=4903},{Name=AGENT_REGISTRATION_PASSWORD,Value=password}] \
--apply-immediately
```
Windows の場合:
```
aws rds add-option-to-option-group ^
--option-group-name "myoptiongroup" ^
--options OptionName=OEM_AGENT,OptionVersion=13.1.0.0.v1,Port=3872,VpcSecurityGroupMemberships=sg-1234567890,OptionSettings=[{Name=OMS_HOST,Value=my.example.oms},{Name=OMS_PORT,Value=4903},{Name=AGENT_REGISTRATION_PASSWORD,Value=password}] ^
--apply-immediately
```
### ステップ 2: DBSNMP ユーザーアカウントのロックを解除する
Management Agent は、`DBSNMP` ユーザーアカウントを使用してデータベースに接続し、問題を Oracle Enterprise Manager に報告します。CDB では、`DBSNMP` は共通ユーザーです。このユーザーアカウントは、Management Agent と OEM Database Express の両方に必要です。デフォルトでは、このアカウントはロックされています。このアカウントのロック解除手順は、データベースが非 CDB アーキテクチャを使用しているか CDB アーキテクチャを使用しているかによって異なります。
**DBSNMP ユーザーアカウントのロックを解除するには**
1. SQL\$1Plus または別の Oracle SQL アプリケーションで、マスターユーザーとして DB インスタンスにログインします。
1. データベースアーキテクチャに応じて、次のいずれかのアクションを実行します。
**データベースが非 CDB の場合**
次の SQL ステートメントを実行します。
```
1. ALTER USER dbsnmp IDENTIFIED BY new_password ACCOUNT UNLOCK;
```
**データベースが CDB の場合**
次のストアドプロシージャを実行して、`DBSNMP` アカウントのロックを解除します。
```
1. EXEC rdsadmin.rdsadmin_util.reset_oem_agent_password('new_password');
```
プロシージャが存在しないことを示すエラーが表示された場合は、CDB インスタンスを再起動して自動的にインストールします。詳細については、「[ DB インスタンスの再起動](USER_RebootInstance.md)」を参照してください。
### ステップ 3: Management Agent コンソールにターゲットを追加する
DB インスタンスをターゲットとして追加するには、エンドポイントとポートがわかっていることを確認してください。Amazon RDS DB インスタンスのエンドポイントを見つける方法については、「[RDS for Oracle DB インスタンスのエンドポイントを見つける](USER_Endpoint.md)」を参照してください。データベースが CDB アーキテクチャを使用している場合は、`CDB$ROOT` コンテナをターゲットとして個別に追加します。
**Management Agent コンソールにターゲットを追加するには**
1. OMS コンソールで、[**Setup**]、[**Add Target**]、[**Add Targets Manually**] の順に選択します。
1. [**Add Targets Declaratively by Specifying Target Monitoring Properties**] を選択します。
1. [**Target Type**] で、[**Database Instance**] を選択します。
1. [**Monitoring Agent (モニタリングエージェント)**] で、RDS DB インスタンス識別子と同じ識別子のエージェントを選択します。
1. [**Add Manually**] を選択します。
1. Amazon RDS DB インスタンスのエンドポイントを入力するか、ホスト名リストから選択します。指定されたホスト名が Amazon RDS DB インスタンスのエンドポイントと一致することを確認します。
1. 次のデータベースのプロパティを指定します。
+ [**ターゲット名**] に、名前を入力します。
+ [**Database system name (データベースシステム名)**] に名前を入力します。
+ [**Monitor username (モニターユーザーネーム)**] に **dbsnmp** と入力します。
+ **[モニターパスワード]** に [ステップ 2: DBSNMP ユーザーアカウントのロックを解除する](#Oracle.Options.OEMAgent.DBSNMP) のパスワードを入力します。
+ [**ロール**] に **normal** と入力します。
+ [**Oracle home path (Oracle ホームパス)**] に **/oracle** と入力します。
+ [**Listener Machine name**] には、エージェント識別子があらかじめ表示されます。
+ [**Port (ポート)**] にデータベースポートを入力します。RDS のデフォルトのポート番号は 1521 です。
+ [**Database name (データベース名)**] には、データベースの名前を入力します。データベースが CDB の場合、この名前は `RDSCDB` です。
1. [**Test Connection**] を選択します。
1. **[次へ]** を選択します。ターゲットデータベースは、モニタリング対象リソースのリストに表示されます。
## Management Agent オプションの削除
DB インスタンスから OEM Agent を削除できます。OEM Agent を削除した後、DB インスタンスを再起動する必要はありません。
OEM Agent を DB インスタンスから削除するには、次のいずれかを実行します。
+ OEM Agent オプションを、所属するオプショングループから削除します。この変更はそのオプショングループを使用するすべての DB インスタンスに影響します。詳細については、「[オプショングループからオプションを削除する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.RemoveOption)」を参照してください。
+ DB インスタンスを修正して、OEM Agent オプションが含まれない別オプショングループを指定します。この変更は、単一の DB インスタンスに影響します。デフォルト (空) のオプショングループや別のカスタムオプショングループを指定できます。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
## Management Agent を使用したデータベースタスクの実行
Amazon RDS 手順を使用して、Management Agent で特定の EMCTL コマンドを実行できます。これらの手順を実行すると、以下のタスクを実行できます。
**注記**
タスクは非同期的に実行されます。
**Topics**
+ [Management Agent を保護する](#Oracle.Options.OEMAgent.DBTasks.SecureAgent)
+ [Management Agent のステータスの取得](#Oracle.Options.OEMAgent.DBTasks.GetAgentStatus)
+ [Management Agent の再起動](#Oracle.Options.OEMAgent.DBTasks.RestartAgent)
+ [Management Agent でモニタリングするターゲットのリスト化](#Oracle.Options.OEMAgent.DBTasks.ListTargets)
+ [Management Agent でモニタリングする取集スレッドのリスト化](#Oracle.Options.OEMAgent.DBTasks.ListCollectionThreads)
+ [Management Agent のステータスの削除](#Oracle.Options.OEMAgent.DBTasks.ClearState)
+ [Management Agent に OMS をアップロードさせる](#Oracle.Options.OEMAgent.DBTasks.ForceUploadOMS)
+ [OMS への ping](#Oracle.Options.OEMAgent.DBTasks.PingOMS)
+ [実行中のタスクのステータスの表示](#Oracle.Options.OEMAgent.DBTasks.ViewTaskStatus)
### Management Agent を保護する
Management Agent を保護するには、Amazon RDS 手順 `rdsadmin.rdsadmin_oem_agent_tasks.secure_oem_agent` を実行します。この手順は、`emctl secure agent` コマンドの実行に相当します。
次の手順では、管理エージェントを保護するタスクを作成し、タスクの ID を返します。
```
SELECT rdsadmin.rdsadmin_oem_agent_tasks.secure_oem_agent as TASK_ID from DUAL;
```
タスクの出力ファイルを表示し、結果を確認するには、「[実行中のタスクのステータスの表示](#Oracle.Options.OEMAgent.DBTasks.ViewTaskStatus)」を参照してください。
### Management Agent のステータスの取得
Management Agent のステータスを取得するには、Amazon RDS のプロシージャ `rdsadmin.rdsadmin_oem_agent_tasks.get_status_oem_agent` を実行します。このプロシージャは、`emctl status agent` コマンドに相当します。
次の手順では、管理エージェントのステータスを取得するタスクを作成し、タスクの ID を返します。
```
SELECT rdsadmin.rdsadmin_oem_agent_tasks.get_status_oem_agent() as TASK_ID from DUAL;
```
タスクの出力ファイルを表示し、結果を確認するには、「[実行中のタスクのステータスの表示](#Oracle.Options.OEMAgent.DBTasks.ViewTaskStatus)」を参照してください。
### Management Agent の再起動
Management Agent を再起動するには、Amazon RDS 手順 `rdsadmin.rdsadmin_oem_agent_tasks.restart_oem_agent` を実行します。この手順は、`emctl stop agent` および `emctl start agent` コマンドの実行に相当します。
次の手順では、管理エージェントを再起動するタスクを作成し、タスクの ID を返します。
```
SELECT rdsadmin.rdsadmin_oem_agent_tasks.restart_oem_agent as TASK_ID from DUAL;
```
タスクの出力ファイルを表示し、結果を確認するには、「[実行中のタスクのステータスの表示](#Oracle.Options.OEMAgent.DBTasks.ViewTaskStatus)」を参照してください。
### Management Agent でモニタリングするターゲットのリスト化
Management Agent によってモニタリングされるターゲットをリスト化するには、Amazon RDS 手順 `rdsadmin.rdsadmin_oem_agent_tasks.list_targets_oem_agent` を実行します。この手順は、`emctl config agent listtargets` コマンドの実行に相当します。
次の手順では、管理エージェントによってモニタリングされるターゲットを一覧表示するタスクを作成し、タスクの ID を返します。
```
SELECT rdsadmin.rdsadmin_oem_agent_tasks.list_targets_oem_agent as TASK_ID from DUAL;
```
タスクの出力ファイルを表示し、結果を確認するには、「[実行中のタスクのステータスの表示](#Oracle.Options.OEMAgent.DBTasks.ViewTaskStatus)」を参照してください。
### Management Agent でモニタリングする取集スレッドのリスト化
管理エージェントによってモニタリングされる、実行中、準備完了、スケジュール済みの収集スレッドをすべて一覧表示するには、Amazon RDS プロシージャ `rdsadmin.rdsadmin_oem_agent_tasks.list_clxn_threads_oem_agent` を実行します。このプロシージャは、`emctl status agent scheduler` コマンドに相当します。
次の手順では、収集スレッドを一覧表示するタスクを作成し、タスクの ID を返します。
```
SELECT rdsadmin.rdsadmin_oem_agent_tasks.list_clxn_threads_oem_agent() as TASK_ID from DUAL;
```
タスクの出力ファイルを表示し、結果を確認するには、「[実行中のタスクのステータスの表示](#Oracle.Options.OEMAgent.DBTasks.ViewTaskStatus)」を参照してください。
### Management Agent のステータスの削除
Management Agent のステータスを削除するには、Amazon RDS の手順 `rdsadmin.rdsadmin_oem_agent_tasks.clearstate_oem_agent` を実行します。この手順は、`emctl clearstate agent` コマンドの実行に相当します。
次の手順では、管理エージェントの状態をクリアするタスクを作成し、タスクの ID を返します。
```
SELECT rdsadmin.rdsadmin_oem_agent_tasks.clearstate_oem_agent() as TASK_ID from DUAL;
```
タスクの出力ファイルを表示し、結果を確認するには、「[実行中のタスクのステータスの表示](#Oracle.Options.OEMAgent.DBTasks.ViewTaskStatus)」を参照してください。
### Management Agent に OMS をアップロードさせる
Management Agent に関連付けられた Oracle Management Server (OMS) をアップロードするには、Amazon RDS のプロシージャ `rdsadmin.rdsadmin_oem_agent_tasks.upload_oem_agent` を実行します。この手順は、`emclt upload agent` コマンドの実行に相当します。
次の手順では、関連付けられている OMS を管理エージェントにアップロードさせるタスクを作成し、タスクの ID を返します。
```
SELECT rdsadmin.rdsadmin_oem_agent_tasks.upload_oem_agent() as TASK_ID from DUAL;
```
タスクの出力ファイルを表示し、結果を確認するには、「[実行中のタスクのステータスの表示](#Oracle.Options.OEMAgent.DBTasks.ViewTaskStatus)」を参照してください。
### OMS への ping
Management Agent の OMS を ping するには、Amazon RDS の手順 `rdsadmin.rdsadmin_oem_agent_tasks.ping_oms_oem_agent` を実行します。この手順は、`emctl pingOMS` コマンドの実行に相当します。
次の手順では、管理エージェントの OMS に ping を送信するタスクを作成し、タスクの ID を返します。
```
SELECT rdsadmin.rdsadmin_oem_agent_tasks.ping_oms_oem_agent() as TASK_ID from DUAL;
```
タスクの出力ファイルを表示し、結果を確認するには、「[実行中のタスクのステータスの表示](#Oracle.Options.OEMAgent.DBTasks.ViewTaskStatus)」を参照してください。
### 実行中のタスクのステータスの表示
実行中のタスクのステータスは bdump ファイルで確認できます。bdump ファイルは `/rdsdbdata/log/trace` ディレクトリにあります。bdump ファイルの名前形式は、以下のとおりです。
```
dbtask-task-id.log
```
タスクをモニタリングしたい場合は、`task-id` を、モニタリングするタスクの ID に置き換えます。
bdump ファイルの内容を表示するには、Amazon RDS 手順 `rdsadmin.rds_file_util.read_text_file` を実行します。次のクエリは、`dbtask-1546988886389-2444.log` bdump ファイルの中身を返します。
```
SELECT text FROM table(rdsadmin.rds_file_util.read_text_file('BDUMP','dbtask-1546988886389-2444.log'));
```
このAmazon RDS 手順 `rdsadmin.rds_file_util.read_text_file` の詳細については、「[DB インスタンスディレクトリ内のファイルの読み取り](Appendix.Oracle.CommonDBATasks.Misc.md#Appendix.Oracle.CommonDBATasks.ReadingFiles)」を参照してください。
# Oracle Label Security
Amazon RDS は OLS オプションの使用を通じて Oracle Database の Oracle Enterprise Edition 用のOracle Label Security をサポートします。
ほとんどのデータベースセキュリティでは、オブジェクトレベルでアクセスを制御します。Oracle Label Security は、個別のテーブル行へのアクセスのきめ細かい制御を提供します。例えば、Label Security を使用して、ポリシーベースの管理モデルで規制コンプライアンスを適用できます。Label Security ポリシーを使用して機密データへのアクセスを制御し、適切なクリアランスレベルを持つユーザーのみにアクセスを制限できます。詳細については、Oracle ドキュメントの「[Introduction to Oracle Label Security](https://docs.oracle.com/database/121/OLSAG/intro.htm#OLSAG001)」を参照してください。
**Topics**
+ [Oracle Label Security の要件](#Oracle.Options.OLS.PreReqs)
+ [Oracle Label Security を使用する際の考慮事項](#Oracle.Options.OLS.Using)
+ [Oracle Label Security オプションの追加](#Oracle.Options.OLS.Add)
+ [トラブルシューティング](#Oracle.Options.OLS.Troubleshooting)
## Oracle Label Security の要件
Oracle Label Security に関する次の要件を理解してください。
+ DB インスタンスでは Bring-Your-Own-License モデルを使用する必要があります。詳細については、「[RDS for Oracle のライセンスオプション](Oracle.Concepts.Licensing.md)」を参照してください。
+ Oracle Enterprise Edition の有効なライセンスと、ソフトウェア更新ライセンスおよびサポートが必要です。
+ Oracle ライセンスには、Label Security オプションが必要です。
## Oracle Label Security を使用する際の考慮事項
Oracle Label Security を使用するには、テーブルの特定の行へのアクセスを制御するポリシーを作成します。詳細については、Oracle ドキュメントの「[Creating an Oracle Label Security Policy](https://docs.oracle.com/database/121/OLSAG/getstrtd.htm#OLSAG3096)」を参照してください。
以下の点を考慮してください。
+ Oracle Label Security は、固定かつ永続オプションです。このオプションは固定的なものであり、オプショングループから削除することはできません。Oracle Label Security をオプショングループに追加して DB インスタンスに関連付けた場合、後で DB インスタンスに別のオプショングループを関連付けることはできますが、このグループには Oracle Label Security オプションも含める必要があります。
+ Label Security を操作する場合、すべてのアクションを `LBAC_DBA` ロールとして実行します。DB インスタンスのマスターユーザーには `LBAC_DBA` ロールが付与されます。他のユーザーが Label Security ポリシーを管理できるように、`LBAC_DBA` ロールを他のユーザーに付与できます。
+ Oracle Label Security へのアクセスが必要な新規ユーザーに `OLS_ENFORCEMENT` パッケージへのアクセス権を付与するようにしてください。`OLS_ENFORCEMENT` パッケージへのアクセス権を付与するには、DB インスタンスにマスターユーザーとして接続し、次の SQL ステートメントを実行します。
```
GRANT ALL ON LBACSYS.OLS_ENFORCEMENT TO username;
```
+ Oracle Enterprise Manager (OEM) Cloud Control を使用して、Label Security を設定することができます。Amazon RDS は Management Agent オプションを通じて OEM Cloud Control をサポートします。詳細については、「[Enterprise Manager Cloud Control 向け Oracle Management Agent](Oracle.Options.OEMAgent.md)」を参照してください。
## Oracle Label Security オプションの追加
DB インスタンスに Oracle Label Security オプションを追加する一般的な手順は以下のとおりです。
1. 新しいオプショングループを作成するか、既存のオプショングループをコピーまたは変更します。
1. オプショングループにオプションを追加します。
**重要**
Oracle Label Security は、固定かつ永続オプションです。
1. オプショングループを DB インスタンスに関連付けます。
Label Security オプションの追加後、オプショングループがアクティブになるとすぐに、Label Security がアクティブになります。
**Label Security オプションを DB インスタンスに追加するには**
1. 使用するオプショングループを決定します。新しいオプショングループを作成することも、既存のオプショングループを使用することもできます。既存のオプショングループを使用する場合は、次のステップは飛ばしてください。または、次の設定でカスタム DB オプショングループを作成します。
1. [**Engine**] で、[**oracle-ee**] を選択します。
1. [**メジャーエンジンのバージョン**] で、DB インスタンスのバージョンを選択します。
詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
1. オプショングループに [**OLS**] オプションを追加します。オプションの追加方法の詳細については、「[オプショングループにオプションを追加する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption)」を参照してください。
**重要**
すでに 1 つ以上の DB インスタンスにアタッチされている既存のオプショングループに Label Security を追加すると、すべての DB インスタンスが再起動されます。
1. 新規または既存の DB インスタンスに、DB オプショングループを適用します。
+ 新規 DB インスタンスの場合は、インスタンスを起動するときにオプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の DB インスタンスの場合は、インスタンスを修正し、新しいオプショングループを添付することで、オプショングループを適用します。既存の DB インスタンスに Label Security オプションを追加すると、DB インスタンスを自動的に再起動している間に短い停止が発生します。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
## トラブルシューティング
Oracle Label Security を使用するときに発生する可能性のある問題を次に示します。
****
| 問題 | トラブルシューティングの推奨事項 |
| --- | --- |
| ポリシーを作成しようとすると、次のようなエラーメッセージが表示されます: `insufficient authorization for the SYSDBA package`。 | Oracle の Label Security 機能の既知の問題により、16～24 文字のユーザーネームを持つユーザーは、Label Security のコマンドを実行することができません。文字数が異なる新しいユーザーを作成し、LBAC\$1DBA を新しいユーザーに付与し、新しいユーザーとしてログインして、新しいユーザーとして OLS コマンドを実行します。詳細については、Oracle サポートにお問い合わせください。 |
# Oracle Locator
Amazon RDS は、`LOCATOR` オプションを使用することで Oracle Locator をサポートします。Oracle Locator は、インターネットとワイヤレスベースのアプリケーションをサポートするために一般的に必要な機能とパートナーベースの GIS ソリューションを提供します。Oracle Locator は Oracle Spatial の制限付きのサブネットです。詳細については、Oracle ドキュメントの [Oracle Locator](https://docs.oracle.com/database/121/SPATL/sdo_locator.htm#SPATL340) を参照してください。
**重要**
Oracle Locator を使用する際、共通脆弱性評価システム (CVSS) のスコアが 9 以上、またはそのほかのセキュリティ脆弱性の報告によりセキュリティ脆弱性がある場合に、Amazon RDS は自動的に DB インスタンスを最新の Oracle PSU にアップデートします。
## サポートされている Oracle Locator のデータベースリリース
RDS for Oracle は、Oracle Database 19c について Oracle Locator をサポートしています。Oracle Locator は Oracle データベース 21c ではサポートされていませんが、その機能は Oracle Spatial オプションで使用できます。以前は、Spatial オプションには追加のライセンスが必要でした。Oracle Locator は Oracle Spatial 機能のサブセットの 1 つであり、追加のライセンスは必要ありませんでした。2019 年、Oracle は Oracle Spatial のすべての機能が Enterprise Edition と Standard Edition 2 のライセンスに追加費用なしで含まれたことを発表しました。その結果、Oracle Spatial オプションに追加のライセンスは必要なくなりました。詳細については、Oracle Database Insider ブログの [Machine Learning, Spatial and Graph - No License Required\$1](https://blogs.oracle.com/database/post/machine-learning-spatial-and-graph-no-license-required) (機械学習、Spatial と Graph のライセンスが不要に) を参照してください。
## Oracle Locator の前提条件
Oracle Locator を使用するための前提条件は次のとおりです。
+ DB インスタンスが十分なクラスである必要があります。Oracle Locator は、db.t3.small DB インスタンスクラスではサポートされていません。詳細については、「[RDS for Oracle DB インスタンスクラス](Oracle.Concepts.InstanceClasses.md)」を参照してください。
+ DB インスタンスで [**マイナーバージョン自動アップグレード**] が有効になっている必要があります。このオプションにより、DB インスタンスは、(それが利用可能になった時点で) DB エンジンのマイナーバージョンアップグレードを自動的に受信できるようになります。これは、Oracle の Java 仮想マシン (JVM) をインストールする、すべてのオプションに必須です。Amazon RDS では、このオプションを使用して、DB インスタンスに対し最新の Oracle パッチセット更新 (PSU)、またはリリース更新 (RU) を行います。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
## Oracle Locator のベストプラクティス
Oracle Locator を使用するためのベストプラクティスは次のとおりです。
+ セキュリティを最大にするためには、`LOCATOR` オプションを Secure Sockets Layer (SSL) で使用します。詳細については、「[Oracle Secure Sockets Layer](Appendix.Oracle.Options.SSL.md)」を参照してください。
+ DB インスタンスへのアクセスを制限するように、DB インスタンスを設定します。詳細については、「[VPC の DB インスタンスにアクセスするシナリオ](USER_VPC.Scenarios.md)」および「[VPC 内の DB インスタンスの使用](USER_VPC.WorkingWithRDSInstanceinaVPC.md)」を参照してください。
## Oracle Locator オプションの追加
DB インスタンスに `LOCATOR` オプションを追加する一般的な手順は以下のとおりです。
1. 新しいオプショングループを作成するか、既存のオプショングループをコピーまたは変更します。
1. オプショングループに [] オプションを追加します。
1. オプショングループを DB インスタンスに関連付けます。
DB インスタンスに Oracle Java Virtual Machine (JVM) がインストールされて*いない*場合、`LOCATOR` オプションが追加されている間は短時間停止します。Oracle Java Virtual Machine (JVM) がすでに DB インスタンスにインストールされている場合、停止は発生しません。オプションを追加した後に DB インスタンスを再起動する必要はありません。オプショングループがアクティブになると、すぐに Oracle Locator が使用可能となります。
**注記**
この停止中、パスワード検証機能は一時的に無効になります。また、停止中にパスワード検証機能に関連するイベントを確認することもできます。Oracle DB インスタンスが使用可能になる前に、パスワード検証機能が再び有効になります。
**`LOCATOR` オプションを DB インスタンスに追加するには**
1. 使用するオプショングループを決定します。新しいオプショングループを作成することも、既存のオプショングループを使用することもできます。既存のオプショングループを使用する場合は、次のステップは飛ばしてください。または、次の設定でカスタム DB オプショングループを作成します。
1. [**エンジン**] で DB インスタンスの Oracle エディションを選択します。
1. [**メジャーエンジンのバージョン**] で、DB インスタンスのバージョンを選択します。
詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
1. オプショングループに [**LOCATOR**] オプションを追加します。オプションの追加方法の詳細については、「[オプショングループにオプションを追加する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption)」を参照してください。
1. 新規または既存の DB インスタンスに、DB オプショングループを適用します。
+ 新規 DB インスタンスの場合は、インスタンスを起動するときにオプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の DB インスタンスの場合は、インスタンスを修正し、新しいオプショングループを添付することで、オプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
## Oracle Locator を使用する
Oracle Locator オプションを有効にしたら、使用をスタートできます。Oracle Locator の機能のみ使用する必要があります。Oracle Spatial のライセンスがない場合には、Oracle Spatial の機能は使用しないでください。
Oracle Locator デサポートされている機能の一覧については、Oracle ドキュメントで [Features Included with Locator](https://docs.oracle.com/database/121/SPATL/sdo_locator.htm#GUID-EC6DEA23-8FD7-4109-A0C1-93C0CE3D6FF2__CFACCEEG) を参照してください。
Oracle Locator デサポートされていない機能の一覧については、Oracle ドキュメントで [Features Not Included with Locator](https://docs.oracle.com/database/121/SPATL/sdo_locator.htm#GUID-EC6DEA23-8FD7-4109-A0C1-93C0CE3D6FF2__CFABACEA) を参照してください。
## Oracle Locator オプションの削除
`LOCATOR` オプションが提供するデータ型を使用するすべてのオブジェクトを削除したら、そのオプションを DB インスタンスから削除できます。DB インスタンスに Oracle Java Virtual Machine (JVM) がインストールされて*いない*場合、`LOCATOR` オプションの削除中にサービスが短時間停止します。Oracle Java Virtual Machine (JVM) がすでに DB インスタンスにインストールされている場合、停止は発生しません。`LOCATOR` オプションを削除した後に DB インスタンスを再起動する必要はありません。
**`LOCATOR` オプションを削除するには**
1. データをバックアップします。
**警告**
オプションの一部として有効化されたデータ型がインスタンスで使用されている場合、`LOCATOR` オプションを削除すると、データが失われる可能性があります。詳細については、「[データのバックアップ、復元、エクスポート](CHAP_CommonTasks.BackupRestore.md)」を参照してください。
1. 既存のオブジェクトが、`LOCATOR` オプションのデータ型や機能を参照しているかどうかを確認します。
`LOCATOR` オプションが存在する場合、`LOCATOR` オプションを持たない新しいオプショングループを適用すると、インスタンスが停止することがあります。次のクエリを使用して、オブジェクトを識別できます。
```
SELECT OWNER, SEGMENT_NAME, TABLESPACE_NAME, BYTES/1024/1024 mbytes
FROM DBA_SEGMENTS
WHERE SEGMENT_TYPE LIKE '%TABLE%'
AND (OWNER, SEGMENT_NAME) IN
(SELECT DISTINCT OWNER, TABLE_NAME
FROM DBA_TAB_COLUMNS
WHERE DATA_TYPE='SDO_GEOMETRY'
AND OWNER <> 'MDSYS')
ORDER BY 1,2,3,4;
SELECT OWNER, TABLE_NAME, COLUMN_NAME
FROM DBA_TAB_COLUMNS
WHERE DATA_TYPE = 'SDO_GEOMETRY'
AND OWNER <> 'MDSYS'
ORDER BY 1,2,3;
```
1. `LOCATOR` オプションのデータ型や機能を参照するすべてのオブジェクトを削除します。
1. 次のいずれかを行ってください。
+ `LOCATOR` オプションを所属するオプショングループから削除します。この変更はそのオプショングループを使用するすべての DB インスタンスに影響します。詳細については、「[オプショングループからオプションを削除する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.RemoveOption)」を参照してください。
+ DB インスタンスを修正して、`LOCATOR` オプションが含まれない別オプショングループを指定します。この変更は、単一の DB インスタンスに影響します。デフォルト (空) のオプショングループや別のカスタムオプショングループを指定できます。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
# Oracle ネイティブネットワーク暗号化
Amazon RDS は、Oracle ネイティブネットワーク暗号化 (NNE) をサポートしています。`NATIVE_NETWORK_ENCRYPTION` オプションを使用すると、DB インスタンスとの間でデータを移動するときにデータを暗号化できます。Amazon RDS では、Oracle Database のすべてのエディションの NNE がサポートされています。
Oracle ネイティブネットワーク暗号化の詳細な説明はこのガイドでは取り上げませんが、配置で使用するソリューションを決定する前に各アルゴリズムおよびキーの長所と短所を理解する必要があります。Oracle ネイティブネットワークの暗号化で使用できるアルゴリズムとキーについては、Oracle ドキュメントの「[Configuring Network Data Encryption](http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/11g/r2/prod/security/network_encrypt/ntwrkencrypt.htm)」を参照してください。AWS セキュリティの詳細については、[AWS セキュリティセンター](https://aws.amazon.com/security)を参照してください。
**注記**
ネイティブネットワーク暗号化または Secure Sockets Layer を使用できますが、両方を使用することはできません。詳細については、「[Oracle Secure Sockets Layer](Appendix.Oracle.Options.SSL.md)」を参照してください。
**Topics**
+ [NATIVE\$1NETWORK\$1ENCRYPTION オプション設定](Oracle.Options.NNE.Options.md)
+ [NATIVE\$1NETWORK\$1ENCRYPTION オプションの追加](Oracle.Options.NNE.Add.md)
+ [sqlnet.ora で NNE 値を設定する](Oracle.Options.NNE.Using.md)
+ [NATIVE\$1NETWORK\$1ENCRYPTION オプション設定](Oracle.Options.NNE.ModifySettings.md)
+ [NATIVE\$1NETWORK\$1ENCRYPTION オプションの削除](Oracle.Options.NNE.Remove.md)
# NATIVE\$1NETWORK\$1ENCRYPTION オプション設定
暗号化要件は、サーバーとクライアントの両方で指定できます。DB インスタンスは、データベースリンクを使用して別のデータベースに接続する場合などに、クライアントとして機能します。サーバー側で暗号化の強制を回避できます。例えば、サーバーで必要としているからといって、すべてのクライアント通信で暗号化の使用を強制することはありません。この場合、`SQLNET.*CLIENT` オプションを使用してクライアント側で暗号化を強制できます。
Amazon RDS は、`NATIVE_NETWORK_ENCRYPTION` オプションの次の設定をサポートします。
**注記**
オプション設定の値をコンマで区切る場合は、コンマの後にスペースを挿入しないでください。
****
| オプション設定 | 有効な値 | デフォルト値 | 説明 |
| --- | --- | --- | --- |
| `SQLNET.ALLOW_WEAK_CRYPTO_CLIENTS` | `TRUE`, `FALSE` | `TRUE` | 非セキュア暗号を使用しているクライアントでデータベースへの接続を試行したときのサーバーの動作。`TRUE` の場合、2021 年 7 月 PSU パッチが適用されていなくても、クライアントでの接続が可能です。 設定を `FALSE` にすると、クライアントで 2021 年 7 月 PSU パッチが適用された場合にだけ、データベースへの接続が可能です。`SQLNET.ALLOW_WEAK_CRYPTO_CLIENTS` を `FALSE` に設定する前に、次の条件が満たされていることを確認してください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Oracle.Options.NNE.Options.html) |
| `SQLNET.ALLOW_WEAK_CRYPTO` | `TRUE`, `FALSE` | `TRUE` | 非セキュア暗号を使用しているクライアントでデータベースへの接続を試行したときのサーバーの動作。次の暗号はセキュアではないと見なされます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Oracle.Options.NNE.Options.html) 設定を `TRUE` にすると、クライアントで前述の非セキュア暗号を使用した場合に接続できます。 設定を `FALSE` にすると、クライアントで前述の非セキュア暗号を使用した場合にデータベースが接続を阻止します。`SQLNET.ALLOW_WEAK_CRYPTO` を `FALSE` に設定する前に、次の条件が満たされていることを確認してください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Oracle.Options.NNE.Options.html) |
| `SQLNET.CRYPTO_CHECKSUM_CLIENT` | `Accepted`, `Rejected`, `Requested`, `Required` | `Requested` | クライアント、またはクライアントとして機能しているサーバーが DB インスタンスに接続する場合のデータ整合性動作。DB インスタンスでデータベースリンクが使用されている場合、そのインスタンスはクライアントとして機能します。 `Requested` は、DB インスタンスによるチェックサムの実行をクライアントで必要としないことを示しています。 |
| `SQLNET.CRYPTO_CHECKSUM_SERVER` | `Accepted`, `Rejected`, `Requested`, `Required` | `Requested` | クライアント、またはクライアントとして機能しているサーバーが DB インスタンスに接続する場合のデータ整合性動作。DB インスタンスでデータベースリンクが使用されている場合、そのインスタンスはクライアントとして機能します。 `Requested` は、クライアントによるチェックサムの実行を DB インスタンスで必要としないことを示しています。 |
| `SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT` | `SHA256`, `SHA384`, `SHA512`, `SHA1`, `MD5` | `SHA256`, `SHA384`, `SHA512` | チェックサムアルゴリズムのリスト。 1 つの値を指定することも、カンマで区切られた値リストを指定することもできます。コンマを使用する場合は、コンマの後にスペースを挿入しないでください。スペースを挿入すると、`InvalidParameterValue` エラーが発生します。 このパラメータと `SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER ` には、共通の暗号が必要です。 |
| `SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER` | `SHA256`, `SHA384`, `SHA512`, `SHA1`, `MD5` | `SHA256`, `SHA384`, `SHA512`, `SHA1`, `MD5` | チェックサムアルゴリズムのリスト。 1 つの値を指定することも、カンマで区切られた値リストを指定することもできます。コンマを使用する場合は、コンマの後にスペースを挿入しないでください。スペースを挿入すると、`InvalidParameterValue` エラーが発生します。 このパラメータと `SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT` には、共通の暗号が必要です。 |
| `SQLNET.ENCRYPTION_CLIENT` | `Accepted`, `Rejected`, `Requested`, `Required` | `Requested` | クライアント、またはクライアントとして機能しているサーバーが DB インスタンスに接続する場合のクライアントの暗号化動作。DB インスタンスでデータベースリンクが使用されている場合、そのインスタンスはクライアントとして機能します。 `Requested` は、クライアントでサーバーからのトラフィックを暗号化する必要がないことを示しています。 |
| `SQLNET.ENCRYPTION_SERVER` | `Accepted`, `Rejected`, `Requested`, `Required` | `Requested` | クライアント、またはクライアントとして機能しているサーバーが DB インスタンスに接続する場合のサーバーの暗号化動作。DB インスタンスでデータベースリンクが使用されている場合、そのインスタンスはクライアントとして機能します。 `Requested` は、DB インスタンスでクライアントからのトラフィックを暗号化する必要がないことを示します。 |
| `SQLNET.ENCRYPTION_TYPES_CLIENT` | `RC4_256`, `AES256`, `AES192`, `3DES168`, `RC4_128`, `AES128`, `3DES112`, `RC4_56`, `DES`, `RC4_40`, `DES40` | `RC4_256`, `AES256`, `AES192`, `3DES168`, `RC4_128`, `AES128`, `3DES112`, `RC4_56`, `DES`, `RC4_40`, `DES40` | クライアントによって使用される暗号化アルゴリズムのリスト。クライアントは、各アルゴリズムが順序どおりに使用され、アルゴリズムが成功するか、リストの末尾に到達するまでサーバー入力の復号を試みます。 Amazon RDS は、Oracle による次のデフォルトリストを使用します。RDS は `RC4_256` で始まり、リストの下の方へ順番に進みます。順序を変更したり、DB インスタンスで受け入れられるアルゴリズムを制限したりすることができます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Oracle.Options.NNE.Options.html) 1 つの値を指定することも、カンマで区切られた値リストを指定することもできます。コンマの場合は、コンマの後にスペースを挿入しないでください。スペースを挿入しないと、`InvalidParameterValue` エラーが発生します。 このパラメータと `SQLNET.SQLNET.ENCRYPTION_TYPES_SERVER` には、共通の暗号が必要です。 |
| `SQLNET.ENCRYPTION_TYPES_SERVER` | `RC4_256`, `AES256`, `AES192`, `3DES168`, `RC4_128`, `AES128`, `3DES112`, `RC4_56`, `DES`, `RC4_40`, `DES40` | `RC4_256`, `AES256`, `AES192`, `3DES168`, `RC4_128`, `AES128`, `3DES112`, `RC4_56`, `DES`, `RC4_40`, `DES40` | DB インスタンスによって使用された暗号化アルゴリズムのリスト。DB インスタンスは、各アルゴリズムを順序どおりに使用し、アルゴリズムが成功するか、リストの末尾に到達するまでクライアントの復号を試みます。 Amazon RDS は、Oracle による次のデフォルトリストを使用します。順序を変更したり、クライアントで受け入れられるアルゴリズムを制限したりすることができます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Oracle.Options.NNE.Options.html) 1 つの値を指定することも、カンマで区切られた値リストを指定することもできます。コンマの場合は、コンマの後にスペースを挿入しないでください。スペースを挿入しないと、`InvalidParameterValue` エラーが発生します。 このパラメータと `SQLNET.SQLNET.ENCRYPTION_TYPES_SERVER` には、共通の暗号が必要です。 |
# NATIVE\$1NETWORK\$1ENCRYPTION オプションの追加
DB インスタンスに `NATIVE_NETWORK_ENCRYPTION` オプションを追加する一般的なプロセスは以下のとおりです。
1. 新しいオプショングループを作成するか、既存のオプショングループをコピーまたは変更します。
1. オプショングループに [] オプションを追加します。
1. オプショングループを DB インスタンスに関連付けます。
オプショングループがアクティブになると、NNE がアクティブになります。
**AWS マネジメントコンソール を使用して DB インスタンスに NATIVE\$1NETWORK\$1ENCRYPTION オプションを追加するには**
1. [**Engine**] で、使用する Oracle のエディションを選択します。NNE はすべてのエディションでサポートされます。
1. [**メジャーエンジンのバージョン**] で、DB インスタンスのバージョンを選択します。
詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
1. **NATIVE\$1NETWORK\$1ENCRYPTION** オプションをオプショングループに追加します。オプションの追加方法の詳細については、「[オプショングループにオプションを追加する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption)」を参照してください。
**注記**
**NATIVE\$1NETWORK\$1ENCRYPTION** オプションを追加した後に DB インスタンスを再起動する必要はありません。オプショングループがアクティブになると、すぐに NNE がアクティブになります。
1. 新規または既存の DB インスタンスに、DB オプショングループを適用します。
+ 新規 DB インスタンスの場合は、インスタンスを起動するときにオプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の DB インスタンスの場合は、インスタンスを修正し、新しいオプショングループを添付することで、オプショングループを適用します。**NATIVE\$1NETWORK\$1ENCRYPTION** オプションを追加した後に DB インスタンスを再起動する必要はありません。オプショングループがアクティブになると、すぐに NNE がアクティブになります。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
# sqlnet.ora で NNE 値を設定する
Oracle ネイティブネットワーク暗号化を使用すると、サーバー側とクライアント側でネットワーク暗号化を設定できます。クライアントとは DB インスタンスへの接続に使用されるコンピュータです。slqnet.ora では、次のクライアント設定を指定できます。
+ `SQLNET.ALLOW_WEAK_CRYPTO`
+ `SQLNET.ALLOW_WEAK_CRYPTO_CLIENTS`
+ `SQLNET.CRYPTO_CHECKSUM_CLIENT`
+ `SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT`
+ `SQLNET.ENCRYPTION_CLIENT`
+ `SQLNET.ENCRYPTION_TYPES_CLIENT`
詳細については、Oracle ドキュメントの「[Oracle サーバーおよびクライアントのネットワークデータ暗号化と整合性の設定](http://docs.oracle.com/cd/E11882_01/network.112/e40393/asoconfg.htm)」を参照してください。
DB インスタンスでアプリケーションからの接続リクエストが拒否される場合があります。例えば、クライアント側の暗号化アルゴリズムとサーバー側の暗号化アルゴリズムが一致しない場合、拒否される可能性があります。Oracle ネイティブネットワーク暗号化をテストするには、クライアントの sqlnet.ora ファイルに次の行を追加します。
```
DIAG_ADR_ENABLED=off
TRACE_DIRECTORY_CLIENT=/tmp
TRACE_FILE_CLIENT=nettrace
TRACE_LEVEL_CLIENT=16
```
接続が試行されると、前の行により `/tmp/nettrace*` というトレースファイルがクライアントに生成されます。トレースファイルには、接続に関する情報が含まれています。Oracle ネイティブネットワーク暗号化を使用した場合の接続に関連する問題の詳細については、「Oracle Database ドキュメント」の「[暗号化と整合性のネゴシエーションについて](http://docs.oracle.com/cd/E11882_01/network.112/e40393/asoconfg.htm#autoId12)」を参照してください。
# NATIVE\$1NETWORK\$1ENCRYPTION オプション設定
`NATIVE_NETWORK_ENCRYPTION` オプションを有効にすると、その設定を変更できます。現在、`NATIVE_NETWORK_ENCRYPTION` オプション設定は、AWS CLI または RDS API でのみ変更できます。 コンソールは使用できません。次の例では、オプションで 2 つの設定を変更します。
```
aws rds add-option-to-option-group \
--option-group-name my-option-group \
--options "OptionName=NATIVE_NETWORK_ENCRYPTION,OptionSettings=[{Name=SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER,Value=SHA256},{Name=SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER,Value=SHA256}]" \
--apply-immediately
```
CLI を使用したオプション設定の変更方法の詳細については、「[AWS CLI](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.ModifyOption.CLI)」を参照してください。各設定の詳細については、「[NATIVE\$1NETWORK\$1ENCRYPTION オプション設定](Oracle.Options.NNE.Options.md)」を参照してください。
**Topics**
+ [CRYPTO\$1CHECKSUM\$1\$1 値の変更](#Oracle.Options.NNE.ModifySettings.checksum)
+ [ALLOW\$1WEAK\$1CRYPTO\$1 設定の変更](#Oracle.Options.NNE.ModifySettings.encryption)
## CRYPTO\$1CHECKSUM\$1\$1 値の変更
**NATIVE\$1NETWORK\$1ENCRYPTION** オプション設定を変更する場合は、次のオプション設定に共通の暗号が少なくとも 1 つあることを確認してください。
+ `SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER`
+ `SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT`
次の例は、`SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER` を変更するシナリオを示しています。`CRYPTO_CHECKSUM_TYPES_CLIENT`、`CRYPTO_CHECKSUM_TYPES_SERVER` の両方が `SHA256` を使用するため、設定は有効です。
| オプション設定 | 変更前の値 | 変更後の値 |
| --- | --- | --- |
| `SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT` | `SHA256`, `SHA384`, `SHA512` | 変更なし |
| `SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER` | `SHA256`, `SHA384`, `SHA512`, `SHA1`, `MD5` | SHA1,MD5,SHA256 |
別の例では、`SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER` をデフォルト設定から `SHA1,MD5` に変更するとします。この場合、`SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT` を 必ず `SHA1` または `MD5` に設定してください。これらのアルゴリズムは `SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT` のデフォルト値に含まれていません。
## ALLOW\$1WEAK\$1CRYPTO\$1 設定の変更
`SQLNET.ALLOW_WEAK_CRYPTO*` オプションをデフォルト値から `FALSE` に設定する場合は、次の条件が満たされていることを確認してください。
+ `SQLNET.ENCRYPTION_TYPES_SERVER` と `SQLNET.ENCRYPTION_TYPES_CLIENT` には、一致するセキュアな暗号化方式が 1 つあります。方式が `DES`、`3DES`、または `RC4` (すべてのキーの長さ) ではない場合、セキュアと見なされます。
+ `SQLNET.CHECKSUM_TYPES_SERVER` と `SQLNET.CHECKSUM_TYPES_CLIENT` には、一致するセキュアなチェックサム方式が 1 つあります。方式が `MD5` ではない場合、セキュアと見なされます。
+ クライアントで 2021 年 7 月 PSU パッチが適用されます。クライアントにパッチが適用されていない場合、クライアントでの接続が失われ、`ORA-12269` エラーを受け取ります。
次の例は サンプル NNE 設定を示しています。`SQLNET.ENCRYPTION_TYPES_SERVER` と `SQLNET.ENCRYPTION_TYPES_CLIENT` をFALSE に設定して、非セキュア接続をブロックすると仮定します。チェックサムオプションの設定は、どちらにも `SHA256` が含まれているため、前提条件を満たしています。ただし、`SQLNET.ENCRYPTION_TYPES_CLIENT` と `SQLNET.ENCRYPTION_TYPES_SERVER` では、非セキュアな暗号化方式である `DES`、`3DES`、および `RC4` が使用されます。したがって、`SQLNET.ALLOW_WEAK_CRYPTO*` オプションを `FALSE` に設定する場合は、まず `SQLNET.ENCRYPTION_TYPES_SERVER` と `SQLNET.ENCRYPTION_TYPES_CLIENT` をセキュアな暗号化方式 (`AES256` など) に設定します。
| オプション設定 | 値 |
| --- | --- |
| `SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT` | `SHA256`, `SHA384`, `SHA512` |
| `SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER` | SHA1,MD5,SHA256 |
| `SQLNET.ENCRYPTION_TYPES_CLIENT` | `RC4_256`, `3DES168`, `DES40` |
| `SQLNET.ENCRYPTION_TYPES_SERVER` | `RC4_256`, `3DES168`, `DES40` |
# NATIVE\$1NETWORK\$1ENCRYPTION オプションの削除
DB インスタンスから NNE を削除できます。
`NATIVE_NETWORK_ENCRYPTION` オプションを DB インスタンスから削除するには、次のいずれかを実行します。
+ 複数の DB インスタンスからオプションを削除するには、それらが属しているオプショングループから `NATIVE_NETWORK_ENCRYPTION` オプションを削除します。この変更はそのオプショングループを使用するすべての DB インスタンスに影響します。`NATIVE_NETWORK_ENCRYPTION` オプションを削除した後に DB インスタンスを再起動する必要はありません。詳細については、「[オプショングループからオプションを削除する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.RemoveOption)」を参照してください。
+ 1 つの DB インスタンスからオプションを削除するには、DB インスタンスを変更し、`NATIVE_NETWORK_ENCRYPTION` オプションを含まない別のオプショングループを指定します。デフォルト (空) のオプショングループや別のカスタムオプショングループを指定できます。`NATIVE_NETWORK_ENCRYPTION` オプションを削除した後に DB インスタンスを再起動する必要はありません。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
# Oracle OLAP
Amazon RDS は、`OLAP` オプションを使用することで Oracle OLAP をサポートします。このオプションは、Oracle DB インスタンスのオンライン分析処理 (OLAP) を提供します。Oracle OLAP を使用すると、OLAP スタンダードに従って次元オブジェクトやキューブを作成することにより、大量のデータを分析できます。詳細については、[Oracle のドキュメント](https://docs.oracle.com/en/database/oracle/oracle-database/19/olaug/index.html)を参照してください。
**重要**
Oracle OLAP を使用する際、共通脆弱性評価システム (CVSS) のスコアが 9 以上、またはそのほかのセキュリティ脆弱性の報告によりセキュリティ脆弱性がある場合に、Amazon RDS は自動的に DB インスタンスを最新の Oracle PSU にアップデートします。
Amazon RDS は、Oracle Database 19c 以降の Enterprise Edition の Oracle OLAP をサポートしています。
## Oracle OLAP の前提条件
Oracle OLAP を使用するための前提条件は次のとおりです。
+ Oracle から Oracle OLAP のライセンスを入手する必要があります。詳細については、Oracle のドキュメントの [Licensing Information](https://docs.oracle.com/en/database/oracle/oracle-database/19/dblic/Licensing-Information.html#GUID-B6113390-9586-46D7-9008-DCC9EDA45AB4) を参照してください。
+ DB インスタンスは、十分な性能のインスタンスクラスのものである必要があります。Oracle OLAP は、db.t3.small DB インスタンスクラスではサポートされていません。詳細については、「[RDS for Oracle DB インスタンスクラス](Oracle.Concepts.InstanceClasses.md)」を参照してください。
+ DB インスタンスで [**マイナーバージョン自動アップグレード**] が有効になっている必要があります。このオプションにより、DB インスタンスは、(それが利用可能になった時点で) DB エンジンのマイナーバージョンアップグレードを自動的に受信できるようになります。これは、Oracle の Java 仮想マシン (JVM) をインストールする、すべてのオプションに必須です。Amazon RDS では、このオプションを使用して、DB インスタンスに対し最新の Oracle パッチセット更新 (PSU)、またはリリース更新 (RU) を行います。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
+ DB インスタンスに `OLAPSYS` というユーザーが存在していないことが必要です。存在している場合、OLAP オプションのインストールは失敗します。
## Oracle OLAP のベストプラクティス
Oracle OLAP を使用するためのベストプラクティスは次のとおりです。
+ セキュリティを最大にするためには、`OLAP` オプションを Secure Sockets Layer (SSL) で使用します。詳細については、「[Oracle Secure Sockets Layer](Appendix.Oracle.Options.SSL.md)」を参照してください。
+ DB インスタンスへのアクセスを制限するように、DB インスタンスを設定します。詳細については、「[VPC の DB インスタンスにアクセスするシナリオ](USER_VPC.Scenarios.md)」および「[VPC 内の DB インスタンスの使用](USER_VPC.WorkingWithRDSInstanceinaVPC.md)」を参照してください。
## Oracle OLAP オプションの追加
DB インスタンスに `OLAP` オプションを追加する一般的な手順は以下のとおりです。
1. 新しいオプショングループを作成するか、既存のオプショングループをコピーまたは変更します。
1. オプショングループに [] オプションを追加します。
1. オプショングループを DB インスタンスに関連付けます。
DB インスタンスに Oracle Java Virtual Machine (JVM) がインストールされて*いない*場合、`OLAP` オプションが追加されている間は短時間停止します。Oracle Java Virtual Machine (JVM) がすでに DB インスタンスにインストールされている場合、停止は発生しません。オプションを追加した後に DB インスタンスを再起動する必要はありません。オプショングループがアクティブになると、すぐに Oracle OLAP が使用可能となります。
**OLAP オプションを DB インスタンスに追加するには**
1. 使用するオプショングループを決定します。新しいオプショングループを作成することも、既存のオプショングループを使用することもできます。既存のオプショングループを使用する場合は、次のステップは飛ばしてください。または、次の設定でカスタム DB オプショングループを作成します。
+ [**エンジン**] で DB インスタンスの Oracle エディションを選択します。
+ [**メジャーエンジンのバージョン**] で、DB インスタンスのバージョンを選択します。
詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
1. オプショングループに [**OLAP**] オプションを追加します。オプションの追加方法の詳細については、「[オプショングループにオプションを追加する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption)」を参照してください。
1. 新規または既存の DB インスタンスに、DB オプショングループを適用します。
+ 新しい DB インスタンスの場合は、インスタンスを起動するときにオプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の DB インスタンスの場合は、インスタンスを修正し、新しいオプショングループを添付することで、オプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
## Oracle OLAP の使用
Oracle OLAP オプションを有効にしたら、使用をスタートできます。Oracle OLAP でサポートされている機能のリストについては、[Oracle のドキュメント](https://docs.oracle.com/en/database/oracle/oracle-database/19/olaug/overview.html#GUID-E2056FE4-C623-4D29-B7D8-C4762F941966)を参照してください。
## Oracle OLAP オプションの削除
`OLAP` オプションが提供するデータ型を使用するすべてのオブジェクトを削除したら、そのオプションを DB インスタンスから削除できます。DB インスタンスに Oracle Java Virtual Machine (JVM) がインストールされて*いない*場合、`OLAP` オプションの削除中にサービスが短時間停止します。Oracle Java Virtual Machine (JVM) がすでに DB インスタンスにインストールされている場合、停止は発生しません。`OLAP` オプションを削除した後に DB インスタンスを再起動する必要はありません。
**`OLAP` オプションを削除するには**
1. データをバックアップします。
**警告**
オプションの一部として有効化されたデータ型がインスタンスで使用されている場合、`OLAP` オプションを削除すると、データが失われる可能性があります。詳細については、「[データのバックアップ、復元、エクスポート](CHAP_CommonTasks.BackupRestore.md)」を参照してください。
1. 既存のオブジェクトが、`OLAP` オプションのデータ型や機能を参照しているかどうかを確認します。
1. `OLAP` オプションのデータ型や機能を参照するすべてのオブジェクトを削除します。
1. 次のいずれかを行ってください。
+ `OLAP` オプションを所属するオプショングループから削除します。この変更はそのオプショングループを使用するすべての DB インスタンスに影響します。詳細については、「[オプショングループからオプションを削除する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.RemoveOption)」を参照してください。
+ DB インスタンスを修正して、`OLAP` オプションが含まれない別オプショングループを指定します。この変更は、単一の DB インスタンスに影響します。デフォルト (空) のオプショングループや別のカスタムオプショングループを指定できます。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
# Oracle Secure Sockets Layer
RDS for Oracle DB インスタンスの SSL 暗号化を有効するには、その DB インスタンスに関連付けられているオプショングループに、Oracle SSL オプションを追加します。Oracle からの要求があるため、Amazon RDS では SSL 接続のために 2 番目のポートを使用しています。この方法では、クリアテキストと SSL 暗号化の両方の通信を、DB インスタンスと SQL\$1Plus 間で同時に実行できます。例えば、このポートで SSL 暗号化通信を使用して VPC 外部のリソースと通信する一方で、このポートでクリアテキスト通信を使用して VPC 内の他のリソースと通信できます。
**注記**
同じ RDS for Oracle DB インスタンスで SSL またはネイティブネットワークの暗号化 (NNE) のいずれかを使用できますが、両方使用することはできません。SSL 暗号化を使用する場合は、他のすべての接続の暗号化を無効にする必要があります。詳細については、「[Oracle ネイティブネットワーク暗号化](Appendix.Oracle.Options.NetworkEncryption.md)」を参照してください。
SSL/TLS と NNE は、Oracle Advanced Security の一部ではなくなりました。RDS for Oracle では、以下のデータベースバージョンのすべてのライセンスされたエディションで、SSL 暗号化を使用できます。
+ Oracle Database 21c (21.0.0)
+ Oracle Database 19c (19.0.0)
**Topics**
+ [Oracle SSL オプションの TLS バージョン](#Appendix.Oracle.Options.SSL.TLS)
+ [Oracle SSL オプションの暗号スイート](#Appendix.Oracle.Options.SSL.CipherSuites)
+ [FIPS のサポート](#Appendix.Oracle.Options.SSL.FIPS)
+ [暗号スイートと証明書の互換性](#Appendix.Oracle.Options.SSL.CertificateCompatibility)
+ [SSL オプションの追加](Appendix.Oracle.Options.SSL.OptionGroup.md)
+ [RDS for Oracle DB インスタンスで SSL を使用するように SQL\$1Plus を設定する](Appendix.Oracle.Options.SSL.ClientConfiguration.md)
+ [SSL を使用した RDS for Oracle DB インスタンスへの接続](Appendix.Oracle.Options.SSL.Connecting.md)
+ [JDBC を介した SSL 接続のセットアップ](Appendix.Oracle.Options.SSL.JDBC.md)
+ [SSL 接続で DN を一致させる](Appendix.Oracle.Options.SSL.DNMatch.md)
+ [SSL 接続のトラブルシューティング](Appendix.Oracle.Options.SSL.troubleshooting.md)
## Oracle SSL オプションの TLS バージョン
Amazon RDS for Oracle は、Transport Layer Security (TLS) バージョン 1.0 および 1.2 をサポートしています。新しい Oracle SSL オプションを追加するときは、`SQLNET.SSL_VERSION` を有効な値に明示的に設定します。オプション設定には、次の値を使用できます。
+ `"1.0"` - クライアントは、TLS バージョン 1.0 のみを使用して DB インスタンスに接続できます。既存の Oracle SSL オプションで、`SQLNET.SSL_VERSION` は自動的に `"1.0"` に設定されます。必要に応じて設定を変更できます。
+ `"1.2"` - クライアントは、TLS 1.2 のみを使用して DB インスタンスに接続できます。
+ `"1.2 or 1.0"` - クライアントは、TLS 1.2 または 1.0 のいずれかを使用して DB インスタンスに接続できます。
## Oracle SSL オプションの暗号スイート
Amazon RDS for Oracle は、複数の SSL 暗号スイートをサポートしています。デフォルトでは、Oracle SSL オプションは `SSL_RSA_WITH_AES_256_CBC_SHA` 暗号スイートを使用するように設定されています。SSL 接続で使用する別の暗号スイートを指定するには、`SQLNET.CIPHER_SUITE` オプション設定を使用します。
`SQLNET.CIPHER_SUITE` には複数の値を指定することができます。この手法は、DB インスタンス間にデータベースリンクがあり、暗号スイートを更新する場合に便利です。
次の表は、Oracle Database 19c および 21c のすべてのエディションでの RDS for Oracle の SSL サポートをまとめたものです。
| 暗号スイート (SQLNET.CIPHER\$1SUITE) | TLS バージョン (SQLNET.SSL\$1VERSION) | FIPS のサポート | FedRAMP 準拠 |
| --- | --- | --- | --- |
| SSL\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA (デフォルト) | 1.0 および 1.2 | あり | いいえ |
| SSL\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA256 | 1.2 | あり | いいえ |
| SSL\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 | 1.2 | あり | いいえ |
| TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 | 1.2 | はい | あり |
| TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1SHA256 | 1.2 | はい | あり |
| TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384 | 1.2 | はい | あり |
| TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256 | 1.2 | はい | あり |
| TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 1.2 | はい | あり |
| TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 1.2 | はい | あり |
| TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 | 1.2 | はい | あり |
| TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384 | 1.2 | はい | あり |
## FIPS のサポート
RDS for Oracle では、連邦情報処理規格 (FIPS) 140-2 標準を使用できます。FIPS 140-2 は、暗号化モジュールのセキュリティ要件を規定する米国政府のスタンダード規格です。FIPS 標準は、Oracle SSL オプションの `FIPS.SSLFIPS_140` を `TRUE` に設定することでオンにします。SSL に FIPS 140-2 を設定した場合、暗号化ライブラリはクライアントと RDS for Oracle DB インスタンスの間のデータを暗号化します。
クライアントは、FIPS 準拠の暗号スイートを使用する必要があります。接続を確立する際、クライアントと RDS for Oracle DB インスタンスはメッセージの送受信に使用する暗号スイートをネゴシエートします。[Oracle SSL オプションの暗号スイート](#Appendix.Oracle.Options.SSL.CipherSuites) の表に、各 TLS バージョンについて FIPS 準拠の SSL 暗号スイートを示します。詳細については、Oracle データベースドキュメントの「[Oracle データベース FIPS 140-2 設定](https://docs.oracle.com/en/database/oracle/oracle-database/12.2/dbseg/oracle-database-fips-140-settings.html#GUID-DDBEB3F9-B216-44BB-8C18-43B5E468CBBB)」を参照してください。
## 暗号スイートと証明書の互換性
RDS for Oracle は、RSA 証明書と楕円曲線デジタル署名アルゴリズム (ECDSA) 証明書の両方をサポートしています。DB インスタンスの SSL を設定するときは、`SQLNET.CIPHER_SUITE` オプション設定で指定した暗号スイートが DB インスタンスで使用される証明書タイプと互換性があることを確認する必要があります。
次の表は、証明書タイプと暗号スイート間の互換性を示しています。
| [証明書タイプ] | 互換性のある暗号スイート | 互換性のない暗号スイート |
| --- | --- | --- |
| RSA 証明書 (rds-ca-2019、rds-ca-rsa2048-g1、rds-ca-rsa4096-g1) | SSL\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA SSL\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA256 SSL\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384 |
| ECDSA 証明書 (rds-ca-ecc384-g1) | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384 | SSL\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA SSL\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA256 SSL\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA |
`SQLNET.CIPHER_SUITE` オプション設定で複数の暗号スイートを指定する場合は、DB インスタンスで使用される証明書タイプと互換性のある暗号スイートを少なくとも 1 つ含めてください。証明書タイプが異なる複数の DB インスタンスでオプショングループを使用している場合は、証明書タイプごとに少なくとも 1 つの暗号スイートを含めます。
DB インスタンスの証明書タイプと互換性のない暗号スイートのみを含む SSL オプションにオプショングループを関連付けようとすると、オペレーションは失敗し、非互換性を示すエラーメッセージが表示されます。
# SSL オプションの追加
SSL を使用するには、RDS for Oracle DB インスタンスが、`SSL` オプションを含むオプショングループに関連付けられている必要があります。
## コンソール
**SSL オプションをオプショングループに追加するには**
1. 新しいオプショングループを作成するか、`SSL` オプションを追加する既存のオプショングループを識別します。
オプショングループの作成の詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
1. オプショングループに [`SSL`] オプションを追加します。
SSL 接続に FIPS で検証された暗号スイートのみを使用する場合は、`FIPS.SSLFIPS_140` オプションを `TRUE` に設定します。FIPS スタンダードの詳細については、「[FIPS のサポート](Appendix.Oracle.Options.SSL.md#Appendix.Oracle.Options.SSL.FIPS)」を参照してください。
オプショングループへのオプションの追加の詳細については、「[オプショングループにオプションを追加する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption)」を参照してください。
1. 新しい RDS for Oracle DB インスタンスを作成し、オプショングループをそのインスタンスに関連付けるか、オプショングループを関連付けるように RDS for Oracle DB インスタンスを変更します。
DB インスタンスの作成については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
DB インスタンスの変更については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
## AWS CLI
**SSL オプションをオプショングループに追加するには**
1. 新しいオプショングループを作成するか、`SSL` オプションを追加する既存のオプショングループを識別します。
オプショングループの作成の詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
1. オプショングループに [`SSL`] オプションを追加します。
以下のオプション設定を指定します。
+ `Port` - SSL ポート番号
+ `VpcSecurityGroupMemberships` - オプションが有効な VPC セキュリティグループ
+ `SQLNET.SSL_VERSION` - クライアントから DB インスタンスへの接続に使用できる TLS バージョン
例えば、以下の AWS CLI コマンドでは、`SSL` オプションを、`ora-option-group` という名前のオプショングループに追加します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds add-option-to-option-group --option-group-name ora-option-group \
--options 'OptionName=SSL,Port=2484,VpcSecurityGroupMemberships="sg-68184619",OptionSettings=[{Name=SQLNET.SSL_VERSION,Value=1.0}]'
```
Windows の場合:
```
aws rds add-option-to-option-group --option-group-name ora-option-group ^
--options 'OptionName=SSL,Port=2484,VpcSecurityGroupMemberships="sg-68184619",OptionSettings=[{Name=SQLNET.SSL_VERSION,Value=1.0}]'
```
1. 新しい RDS for Oracle DB インスタンスを作成し、オプショングループをそのインスタンスに関連付けるか、オプショングループを関連付けるように RDS for Oracle DB インスタンスを変更します。
DB インスタンスの作成については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
DB インスタンスの変更については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
# RDS for Oracle DB インスタンスで SSL を使用するように SQL\$1Plus を設定する
Oracle SSL オプションを使用する RDS for Oracle DB インスタンスに接続する前に、SQL\$1Plus を設定する必要があります。
**注記**
適切なクライアントからの DB インスタンスへのアクセスを許可するには、セキュリティグループが適切に設定されていることを確認します。詳細については、「[セキュリティグループによるアクセス制御](Overview.RDSSecurityGroups.md)」を参照してください。さらに、この手順は、SQL\$1Plus および Oracle ホームを直接使用するその他のクライアント向けです。JDBC 接続については、「[JDBC を介した SSL 接続のセットアップ](Appendix.Oracle.Options.SSL.JDBC.md)」を参照してください。
**SSL を使用して RDS for Oracle DB インスタンスに接続するように SQL\$1Plus を設定するには**
1. `ORACLE_HOME` 環境可変を Oracle ホームディレクトリの場所に設定します。
Oracle ホームディレクトリへのパスは、インストールによって異なります。次の例では、`ORACLE_HOME` 環境可変を設定します。
```
prompt>export ORACLE_HOME=/home/user/app/user/product/19.0.0/dbhome_1
```
Oracle 環境可変の設定については、Oracle ドキュメントの「[SQL\$1Plus 環境可変](http://docs.oracle.com/database/121/SQPUG/ch_two.htm#SQPUG331)」を参照してください。オペレーティングシステムについては、Oracle インストールガイドを参照してください。
1. `$ORACLE_HOME/lib` を `LD_LIBRARY_PATH` 環境可変に追加します。
LD\$1LIBRARY\$1PATH 環境可変を設定する例を以下に示します。
```
prompt>export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib
```
1. `$ORACLE_HOME/ssl_wallet` に Oracle Wallet のディレクトリを作成します。
以下は、Oracle Wallet のディレクトリを作成する例です。
```
prompt>mkdir $ORACLE_HOME/ssl_wallet
```
1. すべての AWS リージョン で動作する証明書バンドルをダウンロードし、そのファイルを ssl\$1wallet ディレクトリに置きます。詳細については、「[SSL/TLS を使用した DB インスタンスまたはクラスターへの接続の暗号化](UsingWithRDS.SSL.md)」を参照してください。
1. `$ORACLE_HOME/network/admin` ディレクトリで、`tnsnames.ora` ファイルを変更または作成して以下のエントリを含めます。
```
net_service_name =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = TCPS)
(HOST = endpoint)
(PORT = ssl_port_number)
)
)
(CONNECT_DATA =
(SID = database_name)
)
(SECURITY =
(SSL_SERVER_CERT_DN = "C=US,ST=Washington,L=Seattle,O=Amazon.com,OU=RDS,CN=endpoint")
)
)
```
1. 同じディレクトリで、sqlnet.ora ファイルを変更または作成して以下のパラメータを含めます。
**注記**
TLS でセキュリティ保護された接続を介してエンティティと通信するために、Oracle は認証用の必要な証明書を持つウォレットを必要とします。ステップ 7 に示すように、Oracle の ORAPKI ユーティリティを使用して Oracle ウォレットを作成して管理できます。詳細については、Oracle ドキュメントで「[ORAPKI を使用した Oracle ウォレットの設定](https://docs.oracle.com/cd/E92519_02/pt856pbr3/eng/pt/tsvt/task_SettingUpOracleWalletUsingORAPKI.html)」を参照してください。
```
WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = $ORACLE_HOME/ssl_wallet)))
SSL_CLIENT_AUTHENTICATION = FALSE
SSL_VERSION = 1.0
SSL_CIPHER_SUITES = (SSL_RSA_WITH_AES_256_CBC_SHA)
SSL_SERVER_DN_MATCH = ON
```
**注記**
`SSL_VERSION` はより高い値に設定できます (DB インスタンスでサポートされている場合)。
1. 以下のコマンドを実行して Oracle Wallet を作成します。
```
prompt>orapki wallet create -wallet $ORACLE_HOME/ssl_wallet -auto_login_only
```
1. OS ユーティリティを使用して、.pem バンドルファイル内の各証明書を個別の .pem ファイルに抽出します。
1. 個別の `orapki` コマンドを使用して各証明書をウォレットに追加し、`certificate-pem-file` を.pem ファイルの絶対ファイル名に置き換えます。
```
prompt>orapki wallet add -wallet $ORACLE_HOME/ssl_wallet -trusted_cert -cert
certificate-pem-file -auto_login_only
```
詳細については、「[SSL/TLS 証明書のローテーション](UsingWithRDS.SSL-certificate-rotation.md)」を参照してください。
# SSL を使用した RDS for Oracle DB インスタンスへの接続
前述のように SQL\$1Plus で SSL を使用するように設定すると、SSL オプションを使用して RDS for Oracle DB インスタンスに接続できるようになります。オプションとして、初期に、tnsnames.ora ファイルと sqlnet.ora ファイルが含まれているディレクトリを指す `TNS_ADMIN` 値をエクスポートできます。これにより、これらのファイルを SQL\$1Plus は確実に見つけることができます。次の例では、`TNS_ADMIN` の値をエクスポートしています。
```
export TNS_ADMIN = ${ORACLE_HOME}/network/admin
```
DB インスタンスに接続します。例えば、SQL \$1Plus と、tnsnames.ora ファイルの ** を使用して接続できます。
```
sqlplus mydbuser@net_service_name
```
以下のコマンドを使用すると、tnsnames.ora ファイルを使用せずに SQL \$1Plus のみを使用して、DB インスタンスに接続することもできます。
```
sqlplus 'mydbuser@(DESCRIPTION = (ADDRESS = (PROTOCOL = TCPS)(HOST = endpoint) (PORT = ssl_port_number))(CONNECT_DATA = (SID = database_name)))'
```
SSL を使用せずに RDS for Oracle DB インスタンスに接続することもできます。例えば、以下のコマンドは SSL 暗号化を使用せずにクリアテキストポートを使用して DB インスタンスに接続します。
```
sqlplus 'mydbuser@(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = endpoint) (PORT = port_number))(CONNECT_DATA = (SID = database_name)))'
```
Transmission Control Protocol (TCP) ポートアクセスを閉じる場合は、IP アドレスの進入を許可しないセキュリティグループを作成して、インスタンスに追加します。これを追加することで、TCP ポートを使用した接続を閉じながら、SSL オプションのセキュリティグループで許可された範囲内の IP アドレスから指定された SSL ポートを使用して接続できます。
# JDBC を介した SSL 接続のセットアップ
JDBC を介した SSL 接続を使用するには、キーストアを作成して、Amazon RDS のルート CA 証明書を信頼し、以下で指定されるコードスニペットを使用する必要があります。
JKS 形式でキーストアを作成するには、次のコマンドを使用できます。キーストアの作成の詳細については、Oracle のドキュメントの「[キーストアの作成](https://docs.oracle.com/cd/E35822_01/server.740/es_admin/src/tadm_ssl_jetty_keystore.html)」を参照してください。リファレンス情報については、「*Java プラットフォーム、標準エディションツールリファレンス*」の「[keytool](https://docs.oracle.com/javase/8/docs/technotes/tools/windows/keytool.html)」を参照してください。
```
keytool -genkey -alias client -validity 365 -keyalg RSA -keystore clientkeystore
```
Amazon RDS のルート CA 証明書を信頼するよう、以下のステップを実行します。
**Amazon RDS ルート CA 証明書を信頼するには**
1. すべての AWS リージョン で動作する証明書バンドルをダウンロードし、そのファイルを ssl\$1wallet ディレクトリに置きます。
証明書のダウンロードについては、[SSL/TLS を使用した DB インスタンスまたはクラスターへの接続の暗号化](UsingWithRDS.SSL.md) を参照してください。
1. OS ユーティリティを使用して、.pem ファイル内の各証明書を個別のファイルに抽出します。
1. *certificate-pem-file* を証明書 .pem ファイルの名前 (.pem 拡張子なし) に置き換えて、個別の `openssl` コマンドを使用して各証明書を .der 形式に変換します。
```
openssl x509 -outform der -in certificate-pem-file.pem -out certificate-pem-file.der
```
1. 次のコマンドを使用して、各証明書をキーストアにインポートします。
```
keytool -import -alias rds-root -keystore clientkeystore.jks -file certificate-pem-file.der
```
詳細については、「[SSL/TLS 証明書のローテーション](UsingWithRDS.SSL-certificate-rotation.md)」を参照してください。
1. キーストアが正常に作成されたことを確認します。
```
keytool -list -v -keystore clientkeystore.jks
```
キーストアのパスワードを求められたら、これを入力します。
次のコード例は、JDBC を使用する SSL 接続のセットアップ方法を示します。
```
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.util.Properties;
public class OracleSslConnectionTest {
private static final String DB_SERVER_NAME = "dns-name-provided-by-amazon-rds";
private static final Integer SSL_PORT = "ssl-option-port-configured-in-option-group";
private static final String DB_SID = "oracle-sid";
private static final String DB_USER = "user-name";
private static final String DB_PASSWORD = "password";
// This key store has only the prod root ca.
private static final String KEY_STORE_FILE_PATH = "file-path-to-keystore";
private static final String KEY_STORE_PASS = "keystore-password";
public static void main(String[] args) throws SQLException {
final Properties properties = new Properties();
final String connectionString = String.format(
"jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCPS)(HOST=%s)(PORT=%d))(CONNECT_DATA=(SID=%s)))",
DB_SERVER_NAME, SSL_PORT, DB_SID);
properties.put("user", DB_USER);
properties.put("password", DB_PASSWORD);
properties.put("oracle.jdbc.J2EE13Compliant", "true");
properties.put("javax.net.ssl.trustStore", KEY_STORE_FILE_PATH);
properties.put("javax.net.ssl.trustStoreType", "JKS");
properties.put("javax.net.ssl.trustStorePassword", KEY_STORE_PASS);
final Connection connection = DriverManager.getConnection(connectionString, properties);
// If no exception, that means handshake has passed, and an SSL connection can be opened
}
}
```
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
# SSL 接続で DN を一致させる
データベースサーバーの識別子名 (DN) をそのサービス名と一致させるには、Oracle パラメータ `SSL_SERVER_DN_MATCH` を使用できます。マッチングの検証を実施する場合は、SSL により、証明書がサーバーから取得されたものであることが確認されます。マッチングの検証を実施しない場合、SSL によって確認が行われますが、一致しているかどうかにかかわらず接続が許可されます。マッチングを実施しない場合、サーバーで識別をモデリング偽造することを許可できます。
DN マッチングを実施するには、DN マッチングのプロパティを追加し、以下に示されている接続文字列を使用します。
DN マッチングを実施するには、このプロパティをクライアント接続に追加します。
```
properties.put("oracle.net.ssl_server_dn_match", "TRUE");
```
SSL の使用時は、以下の接続文字列を使用して DN マッチングを実施します。
```
final String connectionString = String.format(
"jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCPS)(HOST=%s)(PORT=%d))" +
"(CONNECT_DATA=(SID=%s))" +
"(SECURITY = (SSL_SERVER_CERT_DN =
\"C=US,ST=Washington,L=Seattle,O=Amazon.com,OU=RDS,CN=%s\")))",
DB_SERVER_NAME, SSL_PORT, DB_SID, DB_SERVER_NAME);
```
# SSL 接続のトラブルシューティング
データベースにクエリを実行すると、`ORA-28860` エラーが表示されることがあります。
```
ORA-28860: Fatal SSL error
28860. 00000 - "Fatal SSL error"
*Cause: An error occurred during the SSL connection to the peer. It is likely that this side sent data which the peer rejected.
*Action: Enable tracing to determine the exact cause of this error.
```
このエラーは、サーバーがサポートしていないバージョンの TLS を使用してクライアントが接続しようとしたときに発生します。このエラーを回避するには、sqlnet.ora を編集して、`SSL_VERSION` を正しい TLS バージョンに設定します。詳細については、My Oracle Support の「[Oracle Support ドキュメント 2748438.1](https://support.oracle.com/epmos/faces/DocumentDisplay?id=2748438.1)」を参照してください。
# Oracle Spatial
Amazon RDS は、`SPATIAL` オプションを使用することで Oracle Spatial をサポートします。Oracle Spatial は、Oracle データベースのストレージ、取得、更新、および spatial データコレクションのクエリを可能にする SQL スキーマと機能を提供します。詳細については、Oracle ドキュメントの [Spatial Concepts](http://docs.oracle.com/database/121/SPATL/spatial-concepts.htm#SPATL010) を参照してください。Amazon RDS は、サポートされているすべてのリリースのすべてのエディションで Oracle Spatial をサポートしています。
## Spatial パッチバンドル (SPB) の仕組み
RDS for Oracle は、四半期ごとに、サポートされているすべてのメジャーエンジンに対して新しいマイナーエンジンバージョンをリリースします。リリースアップデート (RU) エンジンバージョンには、指定された四半期の RU パッチを含めることで Oracle からのバグ修正が組み込まれています。Spatial パッチバンドル (SPB) エンジンバージョンには、RU パッチと Oracle Spatial に固有のパッチが含まれています。例えば、19.0.0.0.ru-2025-01.spb-1.r1 は、エンジンバージョン 19.0.0.0.ru-2025-01.rur-2025-01.r1 の RU パッチと Spatial パッチを含むマイナーエンジンバージョンです。SPB は Oracle Database 19c でのみサポートされています。
SPB は名前が異なりますが、RU と同じように機能します。RU は、19.0.0.0.ru-2025-01.rur-2025-01.r1 という命名形式を使用します。SPB 名には、19.0.0.0.ru-2025-01.spb-1.r1 のように「spb」というテキストが含まれます。通常、SPB は対応する四半期 RU の 2～3 週間後にリリースされます。例えば、19.0.0.0.ru-2025-01.spb-1.r1 は 19.0.0.0.ru-2025-01.rur-2025-01.r1 以降にリリースされています。
RDS for Oracle には、RU と SPB の自動マイナーバージョンアップグレード用の個別のパスがあります。DB インスタンスが RU を使用している場合、RDS は自動的にインスタンスを RU にアップグレードします。DB インスタンスが SPB を使用している場合、RDS はインスタンスを SPB にアップグレードします。
RU および SPB の詳細については、「[Oracle のマイナーバージョンのアップグレード](USER_UpgradeDBInstance.Oracle.Minor.md)」を参照してください。Oracle Database 19c でサポートされている RU と SPB のリストについては、「*Amazon RDS for Oracle リリースノート*」の「[Amazon RDS for Oracle Database 19c (19.0.0.0)](https://docs.aws.amazon.com/AmazonRDS/latest/OracleReleaseNotes/oracle-version-19-0.html)」を参照してください。
## Oracle Spatial の前提条件
Oracle Spatial を使用するための前提条件は次のとおりです。
+ DB インスタンスが十分なインスタンスクラスであることを確認します。Oracle Spatial は、db.t3.small DB インスタンスクラスではサポートされていません。詳細については、「[RDS for Oracle DB インスタンスクラス](Oracle.Concepts.InstanceClasses.md)」を参照してください。
+ DB インスタンスで [**自動マイナーバージョンアップグレード**] が有効になっていることを確認します。このオプションにより、DB インスタンスは、(それが利用可能になった時点で) DB エンジンのマイナーバージョンアップグレードを自動的に受信できるようになります。これは、Oracle の Java 仮想マシン (JVM) をインストールする、すべてのオプションに必須です。Amazon RDS では、このオプションを使用して、DB インスタンスに対し最新の Oracle パッチセット更新 (PSU)、またはリリース更新 (RU) を行います。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
## Oracle Spatial のベストプラクティス
Oracle Spatial を使用するためのベストプラクティスは次のとおりです。
+ セキュリティを最大にするためには、`SPATIAL` オプションを Secure Sockets Layer (SSL) で使用します。詳細については、「[Oracle Secure Sockets Layer](Appendix.Oracle.Options.SSL.md)」を参照してください。
+ DB インスタンスへのアクセスを制限するように、DB インスタンスを設定します。詳細については、「[VPC の DB インスタンスにアクセスするシナリオ](USER_VPC.Scenarios.md)」および「[VPC 内の DB インスタンスの使用](USER_VPC.WorkingWithRDSInstanceinaVPC.md)」を参照してください。
## Oracle Spatial オプションの追加
DB インスタンスに `SPATIAL` オプションを追加する一般的な手順は以下のとおりです。
1. 新しいオプショングループを作成するか、既存のオプショングループをコピーまたは変更します。
1. オプショングループに [] オプションを追加します。
1. オプショングループを DB インスタンスに関連付けます。
DB インスタンスに Oracle Java Virtual Machine (JVM) がインストールされて*いない*場合、`SPATIAL` オプションが追加されている間は短時間停止します。Oracle Java Virtual Machine (JVM) がすでに DB インスタンスにインストールされている場合、停止は発生しません。オプションを追加した後に DB インスタンスを再起動する必要はありません。オプショングループがアクティブになると、すぐに Oracle Spatial が使用可能となります。
**注記**
この停止中、パスワード検証機能は一時的に無効になります。また、停止中にパスワード検証機能に関連するイベントを確認することもできます。Oracle DB インスタンスが使用可能になる前に、パスワード検証機能が再び有効になります。
**`SPATIAL` オプションを DB インスタンスに追加するには**
1. 使用するオプショングループを決定します。新しいオプショングループを作成することも、既存のオプショングループを使用することもできます。既存のオプショングループを使用する場合は、次のステップは飛ばしてください。または、次の設定でカスタム DB オプショングループを作成します。
1. [**エンジン**] で DB インスタンスの Oracle エディションを選択します。
1. [**メジャーエンジンのバージョン**] で、DB インスタンスのバージョンを選択します。
詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
1. オプショングループに [**SPATIAL**] オプションを追加します。オプションの追加方法の詳細については、「[オプショングループにオプションを追加する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption)」を参照してください。
1. 新規または既存の DB インスタンスに、DB オプショングループを適用します。
+ 新規 DB インスタンスの場合は、インスタンスを起動するときにオプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の DB インスタンスの場合は、インスタンスを修正し、新しいオプショングループを添付することで、オプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
## Oracle Spatial オプションの削除
`SPATIAL` オプションで提供されるデータ型を使用するすべてのオブジェクトを削除したら、DB インスタンスからそのオプションを削除できます。DB インスタンスに Oracle Java Virtual Machine (JVM) がインストールされて*いない*場合、`SPATIAL` オプションの削除中にサービスが短時間停止します。Oracle Java Virtual Machine (JVM) がすでに DB インスタンスにインストールされている場合、停止は発生しません。`SPATIAL` オプションを削除した後に DB インスタンスを再起動する必要はありません。
**`SPATIAL` オプションを削除するには**
1. データをバックアップします。
**警告**
オプションの一部として有効化されたデータ型がインスタンスで使用されている場合、`SPATIAL` オプションを削除すると、データが失われる可能性があります。詳細については、「[データのバックアップ、復元、エクスポート](CHAP_CommonTasks.BackupRestore.md)」を参照してください。
1. 既存のオブジェクトが、`SPATIAL` オプションのデータ型や機能を参照しているかどうかを確認します。
`SPATIAL` オプションが存在する場合、`SPATIAL` オプションを持たない新しいオプショングループを適用すると、インスタンスが停止することがあります。次のクエリを使用して、オブジェクトを識別できます。
```
SELECT OWNER, SEGMENT_NAME, TABLESPACE_NAME, BYTES/1024/1024 mbytes
FROM DBA_SEGMENTS
WHERE SEGMENT_TYPE LIKE '%TABLE%'
AND (OWNER, SEGMENT_NAME) IN
(SELECT DISTINCT OWNER, TABLE_NAME
FROM DBA_TAB_COLUMNS
WHERE DATA_TYPE='SDO_GEOMETRY'
AND OWNER <> 'MDSYS')
ORDER BY 1,2,3,4;
SELECT OWNER, TABLE_NAME, COLUMN_NAME
FROM DBA_TAB_COLUMNS
WHERE DATA_TYPE = 'SDO_GEOMETRY'
AND OWNER <> 'MDSYS'
ORDER BY 1,2,3;
```
1. `SPATIAL` オプションのデータ型や機能を参照するすべてのオブジェクトを削除します。
1. 次のいずれかを行ってください。
+ `SPATIAL` オプションを所属するオプショングループから削除します。この変更はそのオプショングループを使用するすべての DB インスタンスに影響します。詳細については、「[オプショングループからオプションを削除する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.RemoveOption)」を参照してください。
+ DB インスタンスを修正して、`SPATIAL` オプションが含まれない別オプショングループを指定します。この変更は、単一の DB インスタンスに影響します。デフォルト (空) のオプショングループや別のカスタムオプショングループを指定できます。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
# Oracle SQLT
Amazon RDS は、SQLT オプションの使用を通じて SQLTPLAIN (SQLT) をサポートします。SQLT は Oracle Database 19c 以降の任意のエディションで使用できます。
Oracle `EXPLAIN PLAN` ステートメントでは、SQL ステートメントの実行計画を決定できます。Oracle オプティマイザが、ネステッドループされたループ結合などの特定の実行計画を選択しているかどうかを検証できます。また、ハッシュ結合を介してネステッドループ結合を選択した理由など、オプティマイザの決定を理解するのに役立ちます。そのため、`EXPLAIN PLAN` はステートメントのパフォーマンスの理解に役立ちます。
SQLT は、レポートを作成する Oracle ユーティリティです。このレポートには、オブジェクト統計、オブジェクトメタデータ、オプティマイザ関連の初期化パラメータ、およびデータベース管理者が最適なパフォーマンスを得るために SQL ステートメントを調節するために使用できるその他の情報が含まれています。SQLT は、レポート内のすべてのセクションへのハイパーリンクを含む HTML レポートを生成します。
SQLT は、自動ワークロードリポジトリまたは Statspack レポートとは異なり、個々の SQL ステートメントに対して機能します。SQLT は、パフォーマンスデータを収集、保存、表示する SQL、PL/SQL、および SQL\$1Plus ファイルのコレクションです。
各 SQLT バージョンでは次の Oracle バージョンがサポートされています。
****
| SQLT バージョン | Oracle Database 21c | Oracle Database 19c |
| --- | --- | --- |
| 2018-07-25.v1 | サポート | サポート |
| 2018-03-31.v1 | サポートされません | サポートされません |
| 2016-04-29.v1 | サポートされません | サポートされません |
SQLT および使用のためのアクセス手順をダウンロードします。
+ My Oracle Support アカウントにログインして、以下のドキュメントを開きます。
+ SQLT のダウンロード: [ドキュメント 215187.1](https://support.oracle.com/epmos/faces/DocumentDisplay?id=215187.1)
+ SQLT のご利用方法: [ドキュメント 1614107.1](https://support.oracle.com/epmos/faces/DocumentDisplay?id=1614107.1)
+ SQLT についてのよくある質問: [ドキュメント 1454160.1](https://support.oracle.com/epmos/faces/DocumentDisplay?id=1454160.1)
+ 出力された SQLT 読み取りについて: [ドキュメント 1456176.1](https://support.oracle.com/epmos/main/downloadattachmentprocessor?parent=DOCUMENT&sourceId=1456176.1&attachid=1456176.1:58&clickstream=yes)
+ メインレポートの解釈について: [ドキュメント 1922234.1](https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=215187.1&id=1922234.1)
Amazon RDS は、以下の SQLT メソッドをサポートしていません。
+ `XPLORE`
+ `XHUME`
## &SQLT の前提条件
SQLT を使用するための前提条件は次のとおりです。
+ 存在する場合は、SQLT で必要とされるロールとユーザーを削除する必要があります。
SQLT オプションは、DB インスタンスの次のユーザーおよびロールを作成します。
+ `SQLTXPLAIN` ユーザー
+ `SQLTXADMIN` ユーザー
+ `SQLT_USER_ROLE` ロール
DB インスタンスにこれらのユーザーまたはロールがある場合は、SQL クライアントを使用して DB インスタンスにログインし、次のステートメントを使用して削除します。
```
DROP USER SQLTXPLAIN CASCADE;
DROP USER SQLTXADMIN CASCADE;
DROP ROLE SQLT_USER_ROLE CASCADE;
```
+ 存在する場合は、SQLT で必要とされるテーブルスペースを削除する必要があります。
SQLT オプションは、DB インスタンスの次のテーブルスペースを作成します。
+ `RDS_SQLT_TS`
+ `RDS_TEMP_SQLT_TS`
DB インスタンスにこれらのテーブルスペースがある場合は、SQL クライアントを使用して DB インスタンスにログインし、削除します。
## SQLT オプション設定
SQLT は、Oracle Tuning Pack および Oracle Diagnostics Pack によって提供されるライセンス機能を使用して動作します。Oracle Tuning Pack には SQL チューニングアドバイザが、Oracle Diagnostics Pack には自動ワークロードリポジトリが含まれています。SQLT 設定は、SQLT からこれらの機能へのアクセスを有効または無効にします。
Amazon RDS は、SQLT オプションの次の設定をサポートします。
****
| オプション設定 | 有効な値 | デフォルト値 | 説明 |
| --- | --- | --- | --- |
| `LICENSE_PACK` | `T`, `D`, `N` | `N` | SQLT を使用してアクセスする Oracle Management Pack。以下のいずれかの値にエラーがあります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Oracle.Options.SQLT.html) Amazon RDS はこれらの Oracle Management Pack のライセンスを提供しません。DB インスタンスに含まれていないパックを使用することを指定した場合は、DB インスタンスで SQLT を使用できます。ただし、SQLT はパックにアクセスできず、SQLT レポートにはパックのデータは含まれません。例えば、`T` を指定したが、DB インスタンスに Oracle Tuning Pack が含まれていない場合、SQLT は DB インスタンス上で動作しますが、作成するレポートに Oracle Tuning Pack に関係するデータは含まれません。 |
| `VERSION` | `2016-04-29.v1` `2018-03-31.v1` `2018-07-25.v1` | `2016-04-29.v1` | インストールする SQLT のバージョン。 Oracle Database 19c と 21c では、サポートされているバージョンは `2018-07-25.v1` のみです。このバージョンは、これらのリリースのデフォルトです。 |
## SQLT オプションの追加
DB インスタンスに SQLT オプションを追加する一般的なプロセスを次に示します。
1. 新しいオプショングループを作成するか、既存のオプショングループをコピーまたは変更します。
1. オプショングループに SQLT オプションを追加します。
1. オプショングループを DB インスタンスに関連付けます。
SQLT オプションの追加後、オプショングループがアクティブになるとすぐに、SQLT がアクティブになります。
**SQLT オプションを DB インスタンスに追加するには**
1. 使用するオプショングループを決定します。新しいオプショングループを作成することも、既存のオプショングループを使用することもできます。既存のオプショングループを使用する場合は、次のステップは飛ばしてください。または、次の設定でカスタム DB オプショングループを作成します。
1. [**Engine**] で、使用する Oracle のエディションを選択します。SQLT オプションは、すべてのエディションでサポートされます。
1. [**メジャーエンジンのバージョン**] で、DB インスタンスのバージョンを選択します。
詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
1. オプショングループに [**SQLT**] オプションを追加します。オプションの追加方法の詳細については、「[オプショングループにオプションを追加する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption)」を参照してください。
1. 新規または既存の DB インスタンスに、DB オプショングループを適用します。
+ 新規 DB インスタンスの場合は、インスタンスを起動するときにオプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の DB インスタンスの場合は、インスタンスを修正し、新しいオプショングループを添付することで、オプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
1. (オプション) SQLT オプションを伴う各 DB インスタンスの SQLT のインストールを検証します。
1. マスターユーザーとして DB インスタンスに接続している SQL クライアントを使用します。
Oracle DB インスタンスで SQL クライアントに接続する詳細については、「[Oracle DB インスタンスへの接続](USER_ConnectToOracleInstance.md)」を参照してください。
1. 次のクエリを実行します。
```
SELECT sqltxplain.sqlt$a.get_param('tool_version') sqlt_version FROM DUAL;
```
クエリは Amazon RDS の SQLT オプションの最新バージョンを返します。`12.1.160429` は Amazon RDS で使用可能である SQLT のバージョンの例です。
1. SQLT オプションで作成されたユーザーのパスワードを変更します。
1. マスターユーザーとして DB インスタンスに接続している SQL クライアントを使用します。
1. `SQLTXADMIN` ユーザーのパスワードを変更するには、以下の SQL ステートメントを実行します。
```
ALTER USER SQLTXADMIN IDENTIFIED BY new_password ACCOUNT UNLOCK;
```
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
1. `SQLTXPLAIN` ユーザーのパスワードを変更するには、以下の SQL ステートメントを実行します。
```
ALTER USER SQLTXPLAIN IDENTIFIED BY new_password ACCOUNT UNLOCK;
```
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
**注記**
SQLT をアップグレードするには、SQLT の旧バージョンをアンインストールしてから、新しいバージョンをインストールする必要があります。そのため、すべての SQLT メタデータが SQLT をアップグレードすると失われる可能性があります。データベースのメジャーバージョンのアップグレードでも、SQLT がアンインストールされ、再インストールされます。メジャーバージョンのアップグレードの例は、Oracle Database 18c から Oracle Database 19c へのアップグレードです。
## SQLT の使用
SQLT は Oracle SQL\$1Plus ユーティリティで動作します。
**使用する SQLT**
1. My Oracle Support サイトの [ドキュメント 215187.1](https://support.oracle.com/epmos/faces/DocumentDisplay?id=215187.1) から SQLT .zip ファイルをダウンロードします。
**注記**
My Oracle Support サイトから SQLT 12.1.160429 をダウンロードすることはできません。Oracle はこの古いバージョンを廃止しました。
1. SQLT .zip ファイルを解凍します。
1. コマンドプロンプトから、ファイルシステムの `sqlt/run` をディレクトリに変更します。
1. コマンドプロンプトで、SQL\$1Plus を開き、マスターユーザーとして DB インスタンスに接続します。
SQL\$1Plus を使用する DB インスタンスへの接続の詳細については、「[Oracle DB インスタンスへの接続](USER_ConnectToOracleInstance.md)」を参照してください。
1. SQL ステートメントの SQL ID を取得します。
```
SELECT SQL_ID FROM V$SQL WHERE SQL_TEXT='sql_statement';
```
以下のような出力が生成されます。
```
SQL_ID
-------------
chvsmttqjzjkn
```
1. SQLT を含む SQL ステートメントの分析:
```
START sqltxtract.sql sql_id sqltxplain_user_password
```
例えば、SQL ID`chvsmttqjzjkn` に対して、以下を入力してください。
```
START sqltxtract.sql chvsmttqjzjkn sqltxplain_user_password
```
SQLT は、HTML レポートと関連リソースを SQLT コマンドが実行されたディレクトリに .zip ファイルとして生成します。
1. (オプション) アプリケーションユーザーが SQLT を使用して SQL ステートメントを診断できるようにするには、次のステートメントを使用して `SQLT_USER_ROLE` を各アプリケーションユーザーに付与します。
```
GRANT SQLT_USER_ROLE TO application_user_name;
```
**注記**
Oracle は、`SYS` ユーザー、または `DBA` ロールを持つユーザーで SQLT を実行することを推奨していません。`SQLT_USER_ROLE` をアプリケーションユーザーに付与することにより、アプリケーションユーザーのアカウントを使用して SQLT 診断を実行することをお勧めします。
## SQLT オプションのアップグレード
Amazon RDS for Oracle では、SQLT オプションをバージョンを既存のバージョンから上位のバージョンにアップグレードできます。SQLT オプションをアップグレードするには、SQLT の新しいバージョンの [SQLT の使用](#Oracle.Options.SQLT.Using) のステップ 1-3 を完了します。また、そのセクションのステップ 7 で以前のバージョンの SQLT の特権を付与した場合は、新しい SQLT バージョンの特権を再度付与してください。
SQLT オプションをアップグレードすると、古い SQLT バージョンのメタデータが失われます。古い SQLT バージョンのスキーマおよび関連オブジェクトは削除され、新しいバージョンの SQLT がインストールされます。最新の SQLT バージョン における変更の詳細については、My Oracle Support サイトの「[ドキュメント 1614201.1](https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=215187.1&id=1614201.1)」を参照してください。
**注記**
バージョンのダウングレードはサポートされていません。
## SQLT 設定の変更
SQLT を有効にした後、オプションで `LICENSE_PACK` および `VERSION` 設定を変更できます。
オプション設定の変更方法の詳細については、「[オプションの設定を変更する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.ModifyOption)」を参照してください。各設定の詳細については、「[SQLT オプション設定](#Oracle.Options.SQLT.Options)」を参照してください。
## SQLT オプションの削除
DB インスタンスから SQLT を削除できます。
DB インスタンスから SQLT を削除するには、次のいずれかを実行します。
+ 複数の DB インスタンスから SQLT を削除するには、DB インスタンスが属しているオプショングループから SQLT オプションを削除します。この変更はそのオプショングループを使用するすべての DB インスタンスに影響します。詳細については、「[オプショングループからオプションを削除する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.RemoveOption)」を参照してください。
+ 単一の DB インスタンスから SQLT を削除するには、DB インスタンスを変更し、NNE オプションが含まれていない別のオプショングループを指定します。デフォルト (空) のオプショングループや別のカスタムオプショングループを指定できます。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
# Oracle Statspack
Oracle Statspack オプションは、Oracle Statspack パフォーマンス統計機能をインストールして有効にします。Oracle Statspack は、パフォーマンスデータを収集、保存、表示する SQL、PL/SQL、および SQL\$1Plus スクリプトのコレクションです。Oracle Statspack 使用の詳細には、Oracle ドキュメントの「[Oracle Statspack](http://docs.oracle.com/cd/E13160_01/wli/docs10gr3/dbtuning/statsApdx.html)」を参照してください。
**注記**
Oracle Statspack は、Oracle によるサポートが停止されたため、より高度な自動ワークロードリポジトリ (AWR) に置き換えられました。AWR は、Diagnostics Pack を購入した Oracle Enterprise Edition のお客様だけが使用できます。Oracle Statspack は、Amazon RDS 上の任意の Oracle DB エンジンで使用できます。Amazon RDS リードレプリカでは Oracle Statspack を実行できません。
## Oracle Statspack のセットアップ
Statspack スクリプトを実行するには、Statspack オプションを追加する必要があります。
**Oracle Statspack をセットアップするには**
1. SQL クライアントで、管理アカウントを使用して Oracle DB にログインします。
1. Statspack がインストールされているかどうかに応じて、次のいずれかの操作を行います。
+ Statspack がインストールされていて、`PERFSTAT` アカウントが Statspack に関連付けられている場合は、ステップ 4 に進みます。
+ Statspack がインストールされておらず、`PERFSTAT` アカウントが存在する場合は、次のようにアカウントを削除します。
```
DROP USER PERFSTAT CASCADE;
```
それ以外の場合は、Statspack オプションを追加しようとすると、エラーと `RDS-Event-0058` が生成されます。
1. オプショングループに Statspack オプションを追加します。「[オプショングループにオプションを追加する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption)」を参照してください。
Amazon RDS は、DB インスタンスに Statspack スクリプトを自動的にインストールしてから、 `PERFSTAT` アカウントを設定します。
1. 次の SQL 文を使用してパスワードをリセットし、*pwd* を新しいパスワードに置き換えます。
```
ALTER USER PERFSTAT IDENTIFIED BY pwd ACCOUNT UNLOCK;
```
`PERFSTAT` ユーザーアカウントを使用してログインし、Statspack スクリプトを実行できます。
1. 次のステートメントを使用して、`PERFSTAT` アカウントに `CREATE JOB` 権限を付与します。
```
GRANT CREATE JOB TO PERFSTAT;
```
1. `PERFSTAT.STATS$IDLE_EVENT` テーブル内のアイドル待機イベントが設定されていることを確認します。
Oracle バグ 28523746 のため、`PERFSTAT.STATS$IDLE_EVENT` のアイドル待機イベントが設定されていないことがあります。すべてのアイドルイベントが利用可能であることを確認するには、次のステートメントを実行します。
```
INSERT INTO PERFSTAT.STATS$IDLE_EVENT (EVENT)
SELECT NAME FROM V$EVENT_NAME WHERE WAIT_CLASS='Idle'
MINUS
SELECT EVENT FROM PERFSTAT.STATS$IDLE_EVENT;
COMMIT;
```
## Statspack レポートの生成
Statspack レポートでは、2 つのスナップショットを比較します。
**Statspack レポートを生成するには**
1. SQL クライアントで、`PERFSTAT` アカウントを使用して Oracle DB にログインします。
1. 次のいずれかの方法を使用して、スナップショットを作成します。
+ Statspack スナップショットを手動で作成します。
+ 特定の時間間隔の後に Statspack スナップショットを取得するジョブを作成します。例えば、次のジョブは Statspack スナップショットを 1 時間おきに作成します。
```
VARIABLE jn NUMBER;
exec dbms_job.submit(:jn, 'statspack.snap;',SYSDATE,'TRUNC(SYSDATE+1/24,''HH24'')');
COMMIT;
```
1. 次のクエリを使用してスナップショットを表示します。
```
SELECT SNAP_ID, SNAP_TIME FROM STATS$SNAPSHOT ORDER BY 1;
```
1. Amazon RDS プロシージャ `rdsadmin.rds_run_spreport` を実行し、*begin\$1snap* と *end\$1snap* をスナップショット ID に置き換えます。
```
exec rdsadmin.rds_run_spreport(begin_snap,end_snap);
```
例えば、次のコマンドでは、Statspack スナップショット 1 と 2 の間の間隔に基づいてレポートが作成されます。
```
exec rdsadmin.rds_run_spreport(1,2);
```
Statspack レポートのファイル名には、2 つのスナップショットの番号が含まれます。例えば、Statspack スナップショット 1 および 2 を使用して作成されたレポートファイルの名前は `ORCL_spreport_1_2.lst` になります。
1. 出力にエラーがないかモニタリングします。
Oracle Statspack は、レポートを実行する前にチェックを実行します。したがって、コマンド出力にエラーメッセージが表示される可能性もあります。例えば、スタートの Statspack スナップショット値が終了値よりも大きい、無効な範囲に基づいてレポートを生成しようとするとします。この場合、出力にはエラーメッセージが表示されますが、DB エンジンはエラーファイルを生成しません。
```
exec rdsadmin.rds_run_spreport(2,1);
*
ERROR at line 1:
ORA-20000: Invalid snapshot IDs. Find valid ones in perfstat.stats$snapshot.
```
無効な番号の Statspack スナップショットを使用すると、出力にエラーが表示されます。例えば、スナップショット 1 と 50 のレポートを生成しようとして、スナップショット 50 が存在しない場合、出力にはエラーが表示されます。
```
exec rdsadmin.rds_run_spreport(1,50);
*
ERROR at line 1:
ORA-20000: Could not find both snapshot IDs
```
1. (オプション)
レポートを取得するには、[Oracle トレースファイルを使用する](USER_LogAccess.Concepts.Oracle.md#USER_LogAccess.Concepts.Oracle.WorkingWithTracefiles) で説明されているように、トレースファイルプロシージャを呼び出します。
または、RDS コンソールから Statspack レポートをダウンロードします。DB インスタンスの詳細の **[ログ]** セクションに移動し、**[ダウンロード]** を選択します。次の例は、`trace/ORCL_spreport_1_2.lst` を示します。
![\[RDS コンソールに Oracle ログファイルのリストを表示します。次のトレースファイルは丸で囲まれています。trace/ORCL_spreport_1_2.lst。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/statspack1.png)
レポートの生成中にエラーが発生した場合、DB エンジンはレポートと同じ命名規則を使用しますが、拡張子は `.err` です。例えば、Statspack スナップショット 1 および 7 を使用してレポートを作成するときにエラーが発生した場合、レポートファイルの名前は `ORCL_spreport_1_7.err` になります。エラーレポートは、スタンダードのスナップショットレポートと同じ方法でダウンロードできます。
## Statspack スナップショットの削除
一定の範囲の Oracle Statspack スナップショットを削除するには、次のコマンドを使用します。
```
exec statspack.purge(begin snap, end snap);
```
# Oracle のタイムゾーン
タイムゾーンオプションを使用して、Oracle DB インスタンスで使用するシステムのタイムゾーンを変更することができます。例えば、オンプレミス環境またはレガシーアプリケーションとの互換性があるように、DB インスタンスのタイムゾーンで変更が必要になることがあります。タイムゾーンオプションでは、ホストレベルでタイムゾーンが変更されます。タイムゾーンを変更すると、`SYSDATE` や `SYSTIMESTAMP` など、すべての日付列および値に影響を与えます。
タイムゾーンオプションは、`rdsadmin_util.alter_db_time_zone` コマンドと異なります。`alter_db_time_zone` コマンドによって変更されるタイムゾーンは、一定のデータタイプのみ対象です。タイムゾーンオプションでは、すべての日付列および値のタイムゾーンが変更されます。`alter_db_time_zone` の詳細については、「[データベースタイムゾーンの設定](Appendix.Oracle.CommonDBATasks.TimeZoneSupport.md)」を参照してください。アップグレードに関する考慮事項の詳細については、「[タイムゾーンに関する考慮事項](USER_UpgradeDBInstance.Oracle.OGPG.md#USER_UpgradeDBInstance.Oracle.OGPG.DST)」を参照してください。
## タイムゾーンの設定に関する制限
タイムゾーンオプションは、固定かつ永続オプションです。したがって、以下の操作を行うことはできません。
+ タイムゾーンオプションを追加した後、オプショングループからオプションを削除します。
+ DB インスタンスに追加したオプショングループを削除する。
+ オプションのタイムゾーン設定を別のタイムゾーンに変更する。
## タイムゾーンの設定に関する推奨事項
タイムゾーンオプションを運用データベースに追加する前に、次の操作をお勧めします。
+ インスタンスの DB スナップショットを取得します。誤ってタイムゾーンを設定した場合、DB インスタンスを以前のタイムゾーン設定に戻す必要があります。詳細については、「[Amazon RDS のシングル AZ DB インスタンスの DB スナップショットの作成](USER_CreateSnapshot.md)」を参照してください。
+ タイムゾーンオプションを DB インスタンスに追加します。タイムゾーンオプションを追加すると、システムの日付を使用して日付または時刻を追加するテーブルに問題が発生することがあります。テストインスタンスでデータとアプリケーションを分析することをお勧めします。これにより、本番稼働用インスタンスのタイムゾーンを変更した場合の影響を評価できます。
DB インスタンスでデフォルトのオプショングループを使用している場合は、以下のステップに従います。
1. インスタンスの DB スナップショットを取得します。
1. タイムゾーンオプションを DB インスタンスに追加します。
DB インスタンスでデフォルト以外のオプショングループを使用している場合は、以下のステップに従います。
1. インスタンスの DB スナップショットを取得します。
1. 新しいオプショングループを作成します。
1. タイムゾーンオプションを、既存のオプショングループに現在関連付けられている他のすべてのオプションとともに追加します。
これにより、タイムゾーンオプションを有効にしている間に既存のオプションがアンインストールされるのを防ぐことができます。
1. DB インスタンスにオプショングループを追加します。
## タイムゾーンオプション設定
Amazon RDS は、タイムゾーンオプションの次の設定をサポートします。
****
| オプション設定 | 有効な値 | 説明 |
| --- | --- | --- |
| `TIME_ZONE` | 利用可能なタイムゾーンの例 利用できるタイムゾーンの一覧については、「[利用可能なタイムゾーン](#Appendix.Oracle.Options.Timezone.Zones)」を参照してください。 | DB インスタンスの新しいタイムゾーン。 |
## タイムゾーンオプションの追加
タイムゾーンオプションを DB インスタンスに追加するには、次のステップを完了します。
1. (推奨) DB インスタンスのスナップショットを取ります。
1. 次のいずれかのタスクを行います。
+ 新しいオプショングループを初めから作成します。詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
+ AWS CLI または API を使用して既存のオプショングループをコピーします。詳細については、「[オプショングループをコピーする](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Copy)」を参照してください。
+ デフォルト以外の既存のオプショングループを再利用します。ベストプラクティスは、DB インスタンスまたはスナップショットに現在関連付けられていないオプショングループを使用することです。
1. 前のステップからオプショングループに新しいオプションを追加します。
1. 現在 DB インスタンスに関連付けられているオプショングループでオプションが有効になっている場合は、これらのオプションを新しいオプショングループに追加します。この戦略は、新しいオプションを有効にしている間に既存のオプションがアンインストールされるのを防ぐことができます。
1. DB インスタンスに新しいオプショングループを追加します。
タイムゾーンオプションを追加すると、DB インスタンスが自動的に再起動する際に短い停止が発生します。
### コンソール
**タイムゾーンオプションをオプショングループに追加して、DB インスタンスに関連付けるには**
1. RDS コンソールで、[**オプショングループ**] を選択します。
1. オプションを追加するオプショングループの名前を選択します。
1. **[オプションを追加]** を選択します。
1. [**オプション名**] として [**タイムゾーン**] を選択し、オプション設定を行います。
1. オプショングループを新規または既存の DB インスタンスに関連付けます。
+ 新しい DB インスタンスの場合は、インスタンスを起動するときにオプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の DB インスタンスの場合は、インスタンスを修正し、新しいオプショングループを添付することで、オプショングループを適用します。既存の DB インスタンスに新しいオプションを追加すると、DB インスタンスが自動的に再起動している間に短い停止が発生します。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
### AWS CLI
以下の例では、AWS CLI の [add-option-to-option-group](https://docs.aws.amazon.com/cli/latest/reference/rds/add-option-to-option-group.html) コマンドを使用して、`Timezone` オプションと `TIME_ZONE` オプションの設定をオプショングループ `myoptiongroup` に追加しています。タイムゾーンは `Africa/Cairo` に設定されています。
Linux、macOS、Unix の場合:
```
aws rds add-option-to-option-group \
--option-group-name "myoptiongroup" \
--options "OptionName=Timezone,OptionSettings=[{Name=TIME_ZONE,Value=Africa/Cairo}]" \
--apply-immediately
```
Windows の場合:
```
aws rds add-option-to-option-group ^
--option-group-name "myoptiongroup" ^
--options "OptionName=Timezone,OptionSettings=[{Name=TIME_ZONE,Value=Africa/Cairo}]" ^
--apply-immediately
```
## タイムゾーン設定の変更
タイムゾーンオプションは、固定かつ永続オプションです。オプショングループに追加したオプションを削除することはできません。DB インスタンスに追加したオプショングループを削除することはできません。オプションのタイムゾーン設定を別のタイムゾーンへと変更することはできません。タイムゾーンオプションが正しく設定されていない場合は、タイムゾーンオプション追加前の DB インスタンスのスナップショットを復元します。
## タイムゾーンオプションの削除
タイムゾーンオプションは、固定かつ永続オプションです。オプショングループに追加したオプションを削除することはできません。DB インスタンスに追加したオプショングループを削除することはできません。タイムゾーンオプションを削除するには、タイムゾーンオプション追加前の DB インスタンスのスナップショットを復元します。
## 利用可能なタイムゾーン
タイムゾーンオプションには、以下の値を使用できます。
****
| ゾーン | タイムゾーン |
| --- | --- |
| アフリカ | Africa/Cairo、Africa/Casablanca、Africa/Harare、Africa/Lagos、Africa/Luanda、Africa/Monrovia、Africa/Nairobi、Africa/Tripoli、Africa/Windhoek |
| 南北アメリカ大陸 | America/Araguaina、America/Argentina/Buenos\$1Aires、America/Asuncion、America/Bogota、America/Caracas、America/Chicago、America/Chihuahua、America/Cuiaba、America/Denver、America/Detroit、America/Fortaleza、America/Godthab、America/Guatemala、America/Halifax、America/Lima、America/Los\$1Angeles、America/Manaus、America/Matamoros、America/Mexico\$1City、America/Monterrey、America/Montevideo、America/New\$1York、America/Phoenix、America/Santiago、America/Sao\$1Paulo、America/Tijuana、America/Toronto |
| アジア | Asia/Amman、Asia/Ashgabat、Asia/Baghdad、Asia/Baku、Asia/Bangkok、Asia/Beirut、Asia/Calcutta、Asia/Damascus、Asia/Dhaka、Asia/Hong\$1Kong、Asia/Irkutsk、Asia/Jakarta、Asia/Jerusalem、Asia/Kabul、Asia/Karachi、Asia/Kathmandu、Asia/Kolkata、Asia/Krasnoyarsk、Asia/Magadan、Asia/Manila、Asia/Muscat、Asia/Novosibirsk、Asia/Rangoon、Asia/Riyadh、Asia/Seoul、Asia/Shanghai、Asia/Singapore、Asia/Taipei、Asia/Tehran、Asia/Tokyo、Asia/Ulaanbaatar、Asia/Vladivostok、Asia/Yakutsk、Asia/Yerevan |
| 大西洋 | Atlantic/Azores、Atlantic/Cape\$1Verde |
| オーストラリア | Australia/Adelaide、Australia/Brisbane、Australia/Darwin、Australia/Eucla、Australia/Hobart、Australia/Lord\$1Howe、Australia/Perth、Australia/Sydney |
| ブラジル | Brazil/DeNoronha、Brazil/East |
| カナダ | Canada/Newfoundland、Canada/Saskatchewan |
| ETC | Etc/GMT-3 |
| 欧州 | Europe/Amsterdam、Europe/Athens、Europe/Berlin、Europe/Dublin、Europe/Helsinki、Europe/Kaliningrad、Europe/London、Europe/Madrid、Europe/Moscow、Europe/Paris、Europe/Prague、Europe/Rome、Europe/Sarajevo |
| 太平洋 | Pacific/Apia、Pacific/Auckland、Pacific/Chatham、Pacific/Fiji、Pacific/Guam、Pacific/Honolulu、Pacific/Kiritimati、Pacific/Marquesas、Pacific/Samoa、Pacific/Tongatapu、Pacific/Wake |
| 米国 | US/Alaska、US/Central、US/East-Indiana、US/Eastern、US/Pacific |
| UTC | UTC |
# Oracle のタイムゾーンファイルの自動アップグレード
`TIMEZONE_FILE_AUTOUPGRADE` オプションを使用すると、現在のタイムゾーンファイルを RDS for Oracle DB インスタンスの最新バージョンにアップグレードできます。
**Topics**
+ [Oracle のタイムゾーンファイルの概要](Appendix.Oracle.Options.Timezone-file-autoupgrade.tz-overview.md)
+ [タイムゾーンファイルを更新する戦略](Appendix.Oracle.Options.Timezone-file-autoupgrade.strategies.md)
+ [タイムゾーンファイル更新時のダウンタイム](Appendix.Oracle.Options.Timezone-file-autoupgrade.considerations.md)
+ [タイムゾーンファイル更新の準備](Appendix.Oracle.Options.Timezone-file-autoupgrade.preparing.md)
+ [タイムゾーンファイル自動アップグレードオプションの追加](Appendix.Oracle.Options.Timezone-file-autoupgrade.adding.md)
+ [タイムゾーンファイル更新後のデータのチェック](Appendix.Oracle.Options.Timezone-file-autoupgrade.checking.md)
# Oracle のタイムゾーンファイルの概要
Oracle Database の*タイムゾーンファイル*には、次の情報が格納されます。
+ 協定世界時 (UTC) との時差
+ サマータイム (DST) の移行時期
+ 標準時と DST の略語
Oracle Database には、複数のバージョンのタイムゾーンファイルが用意されています。オンプレミス環境で Oracle Database を作成するときには、タイムゾーンファイルのバージョンを選択します。詳細については、*「Oracle Database グローバリゼーションサポートガイド*」の「[タイムゾーンファイルの選択](https://docs.oracle.com/en/database/oracle/oracle-database/19/nlspg/datetime-data-types-and-time-zone-support.html#GUID-805AB986-DE12-4FEA-AF56-5AABCD2132DF)」を参照してください。
DST のルールが変更された場合、Oracle は新しいタイムゾーンファイルを公開します。Oracle は、四半期ごとの Release Updates (RU) および Release Update Revisions (RUR) のスケジュールとは関係なく、これらの新しいタイムゾーンファイルをリリースします。タイムゾーンファイルは、データベースホストのディレクトリ `$ORACLE_HOME/oracore/zoneinfo/` にあります。タイムゾーンファイル名は、DSTv35 のような形式 DSTv *バージョン*を使用します。
## タイムゾーンファイルがデータ転送に与える影響
Oracle Database では、`TIMESTAMP WITH TIME ZONE` データ型は、タイムスタンプとタイムゾーンのデータを保存します。`TIMESTAMP WITH TIME ZONE` データ型のデータは、関連付けられたタイムゾーンファイルバージョンのルールを使用します。そのため、タイムゾーンファイルを更新すると、既存の `TIMESTAMP WITH TIME ZONE` データが影響を受けます。
異なるバージョンのタイムゾーンファイルを使用するデータベース間でデータを転送すると、問題が発生する可能性があります。例えば、ターゲットデータベースよりも高いバージョンのタイムゾーンファイルを持つソースデータベースからデータをインポートすると、データベースは `ORA-39405` エラーを発行します。以前は、次のいずれかのテクニックを使用して、このエラーを回避する必要がありました。
+ 必要なタイムゾーンファイルを使用して RDS for Oracle DB インスタンスを作成し、ソースデータベースからデータをエクスポートしてから、新しいデータベースにインポートします。
+ AWS DMS または論理的なレプリケーションを使用して、データを移行します。
## TIMEZONE\$1FILE\$1AUTOUPGRADE オプションを使用した自動アップデート
RDS for Oracle DB インスタンスにアタッチされたオプショングループに `TIMEZONE_FILE_AUTOUPGRADE`オプションが含まれている場合、RDS はタイムゾーンファイルを自動的に更新します。Oracle データベースが同じバージョンのタイムゾーンファイルを使用するようにすることで、異なる環境間でデータを移動する際に時間のかかる手動操作を回避できます。`TIMEZONE_FILE_AUTOUPGRADE` オプションは、コンテナデータベース (CDB) と非 CDB の両方に対してサポートされています。
`TIMEZONE_FILE_AUTOUPGRADE` オプションをオプショングループに追加するときには、オプションをすぐに追加するか、メンテナンスウィンドウで追加するかを選択できます。DB インスタンスが新しいオプションを適用すると、RDS は新しい DSTv *バージョン*ファイルをインストールできるかどうか確認します。対象の DST *バージョン*は以下の内容によって異なります。
+ DB インスタンスが現在実行中のマイナーエンジンバージョン
+ DB インスタンスのアップグレード先のマイナーエンジンバージョン
例えば、現在のタイムゾーンファイルのバージョンは DSTv33 である可能性があります。RDS がオプショングループに更新を適用すると、DSTv34 が DB インスタンスファイルシステムで現在利用可能であると判断される場合があります。その後、RDS はタイムゾーンファイルを自動的に DSTv34 に更新します。
サポートされる RDS リリース更新で利用可能な DST バージョンを確認するには、「[Release notes for Amazon Relational Database Service (Amazon RDS) for Oracle](https://docs.aws.amazon.com/AmazonRDS/latest/OracleReleaseNotes/Welcome.html)」(Amazon Relational Database Service (Amazon RDS) for Oracle リリースノート) のパッチを参照してください。例えば、[version 19.0.0.0.ru-2022-10.rur-2022-10.r1](https://docs.aws.amazon.com/AmazonRDS/latest/OracleReleaseNotes/oracle-version-19-0.html#oracle-version-RU-RUR.19.0.0.0.ru-2022-10.rur-2022-10.r1) には、パッチ 34533061: RDBMS - DSTV39 UPDATE - TZDATA2022C がリストされています。
# タイムゾーンファイルを更新する戦略
DB エンジンをアップグレードし、オプショングループに `TIMEZONE_FILE_AUTOUPGRADE` オプションを追加するオペレーションは個別に行います。`TIMEZONE_FILE_AUTOUPGRADE` オプションを追加すると、最新のタイムゾーンファイルがある場合は、タイムゾーンファイルの更新が開始されます。すぐに、または次のメンテナンスウィンドウで、次のコマンドを実行します (関連するオプションのみが表示されます)。
+ 次の RDS CLI コマンドを使用してのみ DB エンジンをアップグレードします。
```
modify-db-instance --engine-version name ...
```
+ 次の CLI コマンドを使用してのみ `TIMEZONE_FILE_AUTOUPGRADE` オプションを追加します。
```
add-option-to-option-group --option-group-name name --options OptionName=TIMEZONE_FILE_AUTOUPGRADE ...
```
+ 次の CLI コマンドを使用して、DB エンジンをアップグレードし、インスタンスに新しいオプショングループを追加します。
```
modify-db-instance --engine-version name --option-group-name name ...
```
更新戦略は、データベースとタイムゾーンファイルを一緒にアップグレードするか、これらのオペレーションのいずれかのみを実行するかによって異なります。オプショングループを更新し、別の API オペレーションで DB エンジンをアップグレードすると、DB エンジンをアップグレードするときにタイムゾーンファイルの更新が現在進行中になる可能性があることに注意してください。
このセクションの例では、以下を前提とします。
+ DB インスタンスに現在関連付けられているオプショングループに、まだ `TIMEZONE_FILE_AUTOUPGRADE` が追加されていません。
+ ご使用の DB インスタンスはデータベースバージョン 19.0.0.0.ru-2019-07.rur-2019-07.r1 およびタイムゾーンファイル DSTv33 を使用しています。
+ DB インスタンスファイルシステムには、ファイル DSTv34 が含まれています。
+ リリース更新プログラム 19.0.0.0.ru-2022-10.rur-2022-10.r1 には DSTv35 が含まれています。
タイムゾーンファイルを更新するには、以下の戦略を使用できます。
**Topics**
+ [エンジンをアップグレードせずにタイムゾーンファイルを更新する](#Appendix.Oracle.Options.Timezone-file-autoupgrade.strategies.no-upgrade)
+ [タイムゾーンファイルと DB エンジンバージョンをアップグレードする](#Appendix.Oracle.Options.Timezone-file-autoupgrade.strategies.upgrade)
+ [タイムゾーンファイルを更新せずに、DB エンジンのバージョンをアップグレードする](#Appendix.Oracle.Options.Timezone-file-autoupgrade.strategies.upgrade-only)
## エンジンをアップグレードせずにタイムゾーンファイルを更新する
このシナリオでは、データベースに DSTv33 を使用していますが、ご使用の DB インスタンスファイルシステムでは DSTv34 が使用できます。DB インスタンスで使用されるタイムゾーンファイルを DSTv33 から DSTv34 に更新しても、エンジンは DSTv35 を含む新しいマイナーバージョンにアップグレードしたくありません。
`add-option-to-option-group` コマンドで、DB インスタンスで使用されるオプショングループに `TIMEZONE_FILE_AUTOUPGRADE` を追加します。オプションをすぐに追加するか、メンテナンスウィンドウまで遅延するかを指定します。`TIMEZONE_FILE_AUTOUPGRADE` オプションを適用すると、RDS は次の処理を行います。
1. 新しい DST バージョンをチェックする。
1. DSTv34 がファイルシステムで使用可能であることを決定する。
1. タイムゾーンファイルをすぐに更新する。
## タイムゾーンファイルと DB エンジンバージョンをアップグレードする
このシナリオでは、データベースに DSTv33 を使用していますが、ご使用の DB インスタンスファイルシステムでは DSTv34 が使用できます。DB エンジンを DSTv35 を含むマイナーバージョン 19.0.0.0.ru-2022-10.rur-2022-10.r1 にアップグレードし、エンジンのアップグレード中にタイムゾーンファイルを DSTv35 に更新します。したがって、目標は DSTv34 をスキップして、タイムゾーンファイルを DSTv35 に直接更新することです。
エンジンとタイムゾーンファイルを一緒にアップグレードするには、`--option-group-name` および `--engine-version` オプションを使用して `modify-db-instance` を実行します。コマンドはすぐに実行することも、メンテナンスウィンドウ に延期することもできます。`In --option-group-name` は、`TIMEZONE_FILE_AUTOUPGRADE` オプションを含むオプショングループを指定します。例えば、次のようになります。
```
aws rds modify-db-instance
--db-instance-identifier my-instance \
--engine-version new-version \
----option-group-name og-with-timezone-file-autoupgrade \
--apply-immediately
```
RDS は、エンジンの 19.0.0.0.ru-2022-10.rur-2022-10.r1 へのアップグレードを開始します。`TIMEZONE_FILE_AUTOUPGRADE` オプションが適用されると、RDS は新しい DST バージョンを確認して、DSTv35 が 19.0.0.0.ru-2022-10.rur-2022-10.r1 で使用可能であることがわかると、すぐに DSTv35 に更新を開始します。
エンジンをすぐにアップグレードし、タイムゾーンファイルをアップグレードするには、オペレーションを順番に実行します。
1. 次の CLI コマンドを使用してのみ DB エンジンをアップグレードします。
```
aws rds modify-db-instance \
--db-instance-identifier my-instance \
--engine-version new-version \
--apply-immediately
```
1. 次の CLI コマンドを使用して、インスタンスにアタッチされたオプショングループに `TIMEZONE_FILE_AUTOUPGRADE` オプションを追加します。
```
aws rds add-option-to-option-group \
--option-group-name og-in-use-by-your-instance \
--options OptionName=TIMEZONE_FILE_AUTOUPGRADE \
--apply-immediately
```
## タイムゾーンファイルを更新せずに、DB エンジンのバージョンをアップグレードする
このシナリオでは、データベースに DSTv33 を使用していますが、ご使用の DB インスタンスファイルシステムでは DSTv34 が使用できます。DB エンジンを DSTv35 を含むバージョン 19.0.0.0.ru-2022-10.rur-2022-10.r1 にアップグレードしても、タイムゾーンファイル DSTv33 を保持します。次の理由から、この戦略が必要になる場合があります。
+ データが `TIMESTAMP WITH TIME ZONE` データ型を使用しない。
+ データは `TIMESTAMP WITH TIME ZONE` データ型を使用できますが、データがタイムゾーン変更の影響を受けません。
+ 追加のダウンタイムを許容できないため、タイムゾーンファイルの更新を延期する必要があります。
戦略は、次のいずれが該当するによって異なります。
+ DB インスタンスは `TIMEZONE_FILE_AUTOUPGRADE` を含むオプショングループに関連付けられていません。`modify-db-instance` コマンドでは、RDS がタイムゾーンファイルを更新しないように、新しいオプショングループを指定しないでください。
+ DB インスタンスは現在、`TIMEZONE_FILE_AUTOUPGRADE` を含むオプショングループに関連付けられています。単一の `modify-db-instance` コマンド内で、`TIMEZONE_FILE_AUTOUPGRADE` を含まないオプショングループに DB インスタンスを関連付けてから、DB エンジンを 19.0.0.0.ru-2022-10.rur-2022-10.r1 にアップグレードします。
# タイムゾーンファイル更新時のダウンタイム
RDS がタイムゾーンファイルを更新すると、`TIMESTAMP WITH TIME ZONE` を使用する既存のデータが変更される可能性があります。この場合、主な考慮事項は、ダウンタイムです。
**警告**
`TIMEZONE_FILE_AUTOUPGRADE` オプションを追加すると、エンジンのアップグレードのためにダウンタイムが長くなる可能性があります。ラージデータベースのタイムゾーンデータの更新には、数時間または数日かかることがあります。
タイムゾーンファイルの更新の長さは、次のような要因によって異なります。
+ データベース内の `TIMESTAMP WITH TIME ZONE` データの量
+ DB インスタンスの設定
+ DB インスタンスクラス
+ ストレージ設定
+ データベース設定
+ データベースパラメータ設定
次の操作を行うと、追加のダウンタイムが発生する可能性があります。
+ DB インスタンスが古いタイムゾーンファイルを使用しているときには、オプションをオプショングループに追加します。
+ 新しいエンジンバージョンにタイムゾーンファイルの新しいバージョンが含まれている場合は、Oracle データベースエンジンをアップグレードします。
**注記**
タイムゾーンファイルの更新中に、RDS for Oracle は `PURGE DBA_RECYCLEBIN` を呼び出します。
# タイムゾーンファイル更新の準備
タイムゾーンファイルのアップグレードには、準備とアップグレードの 2 つの段階があります。必須ではありませんが、準備ステップを実行することを強く推奨します。このステップでは、PL/SQL ステップ `DBMS_DST.FIND_AFFECTED_TABLES` を実行することによって影響を受けるデータを調べます。準備ウィンドウの詳細については、Oracle Database ドキュメントの [Upgrading the Time Zone File and Timestamp with Time Zone Data](https://docs.oracle.com/en/database/oracle/oracle-database/19/nlspg/datetime-data-types-and-time-zone-support.html#GUID-B0ACDB2E-4B49-4EB4-B4CC-9260DAE1567A) を参照してください。
**タイムゾーンファイル更新の準備を行うには**
1. SQL クライアントを使用して、Oracle Database に接続します。
1. 現在使用されているタイムゾーンファイルのバージョンを確認します。
```
SELECT * FROM V$TIMEZONE_FILE;
```
1. DB インスタンスで使用可能な最新のタイムゾーンファイルのバージョンを決定します。
```
SELECT DBMS_DST.GET_LATEST_TIMEZONE_VERSION FROM DUAL;
```
1. `TIMESTAMP WITH LOCAL TIME ZONE` または `TIMESTAMP WITH TIME ZONE` 型の列を持つテーブルの合計サイズを決定します。
```
SELECT SUM(BYTES)/1024/1024/1024 "Total_size_w_TSTZ_columns_GB"
FROM DBA_SEGMENTS
WHERE SEGMENT_TYPE LIKE 'TABLE%'
AND (OWNER, SEGMENT_NAME) IN
(SELECT OWNER, TABLE_NAME
FROM DBA_TAB_COLUMNS
WHERE DATA_TYPE LIKE 'TIMESTAMP%TIME ZONE');
```
1. `TIMESTAMP WITH LOCAL TIME ZONE` または `TIMESTAMP WITH TIME ZONE` 型の列を持つセグメントの名前とサイズを決定します。
```
SELECT OWNER, SEGMENT_NAME, SUM(BYTES)/1024/1024/1024 "SEGMENT_SIZE_W_TSTZ_COLUMNS_GB"
FROM DBA_SEGMENTS
WHERE SEGMENT_TYPE LIKE 'TABLE%'
AND (OWNER, SEGMENT_NAME) IN
(SELECT OWNER, TABLE_NAME
FROM DBA_TAB_COLUMNS
WHERE DATA_TYPE LIKE 'TIMESTAMP%TIME ZONE')
GROUP BY OWNER, SEGMENT_NAME;
```
1. 準備ステップを実行します。
+ 手順 `DBMS_DST.CREATE_AFFECTED_TABLE` で、影響を受けるデータを保存するためのテーブルを作成します。このテーブル名を `DBMS_DST.FIND_AFFECTED_TABLES` 手順に渡します。詳細については、Oracle Database ドキュメントの [CREATE\$1AFFECTED\$1TABLE Procedure](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_DST.html#GUID-C53BAABA-914A-404C-9CD5-823257BE0B00) を参照してください。
+ このプロシージャ `CREATE_ERROR_TABLE` は、エラーを記録するテーブルを作成します。詳細については、Oracle Database ドキュメントの [CREATE\$1ERROR\$1TABLE Procedure](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_DST.html#GUID-6A7EA024-B02D-4486-B1D6-EF6ABF5DE507) を参照してください。
次の例では、影響を受けるデータとエラーテーブルを作成し、影響を受けるすべてのテーブルを検索します。
```
EXEC DBMS_DST.CREATE_ERROR_TABLE('my_error_table')
EXEC DBMS_DST.CREATE_AFFECTED_TABLE('my_affected_table')
EXEC DBMS_DST.BEGIN_PREPARE(new_version);
EXEC DBMS_DST.FIND_AFFECTED_TABLES('my_affected_table', TRUE, 'my_error_table');
EXEC DBMS_DST.END_PREPARE;
SELECT * FROM my_affected_table;
SELECT * FROM my_error_table;
```
1. 影響を受けるテーブルとエラーテーブルをクエリします。
```
SELECT * FROM my_affected_table;
SELECT * FROM my_error_table;
```
# タイムゾーンファイル自動アップグレードオプションの追加
オプションをオプショングループに追加すると、オプショングループは次のいずれかの状態になります。
+ 既存のオプショングループは、現在、少なくとも 1 つの DB インスタンスにアタッチされています。オプションを追加すると、このオプショングループを使用するすべての DB インスタンスが自動的に再起動します。これにより、短時間の停止が発生します。
+ 既存のオプショングループは、DB インスタンスにアタッチされていません。オプションを追加してから、既存のオプショングループを既存の DB インスタンスまたは新しい DB インスタンスに関連付ける予定です。
+ 新しいオプショングループを作成し、オプションを追加します。新しいオプショングループを既存の DB インスタンスまたは新しい DB インスタンスに関連付ける予定です。
## コンソール
**タイムゾーンファイル自動アップグレードオプションを DB インスタンスに追加するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**オプショングループ**] を選択します。
1. 使用するオプショングループを決定します。新しいオプショングループを作成することも、既存のオプショングループを使用することもできます。既存のオプショングループを使用する場合は、次のステップは飛ばしてください。または、次の設定でカスタム DB オプショングループを作成します。
1. **[Engine]** (エンジン) として、DB インスタンスの Oracle Database エディションを選択します。
1. [**メジャーエンジンのバージョン**] で、DB インスタンスのバージョンを選択します。
詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
1. 変更するオプショングループを選択し、[**オプションの追加**] を選択します。
1. [**Add option**(オプションの追加)] ウィンドウで、以下の操作を行います。
1. **[TIMEZONE\$1FILE\$1AUTOUPGRADE]** を選択します。
1. オプションを追加後すぐに、関連付けられているすべての DB インスタンスに対して有効にするには、[**Apply Immediately**] で [**Yes**] を選択します。[**No**] を選択した場合 (デフォルト)、オプションは次のメンテナンス時間中に、関連付けられている各 DB インスタンスに対して有効になります。
1. 設定が希望どおりになったら、[**オプションの追加**] を選択します。
## AWS CLI
次の例では、AWS CLI の [add-option-to-option-group](https://docs.aws.amazon.com/cli/latest/reference/rds/add-option-to-option-group.html) コマンドを使用して、`TIMEZONE_FILE_AUTOUPGRADE` オプションを `myoptiongroup` オプショングループに追加しています。
Linux、macOS、Unix の場合:
```
aws rds add-option-to-option-group \
--option-group-name "myoptiongroup" \
--options "OptionName=TIMEZONE_FILE_AUTOUPGRADE" \
--apply-immediately
```
Windows の場合:
```
aws rds add-option-to-option-group ^
--option-group-name "myoptiongroup" ^
--options "OptionName=TIMEZONE_FILE_AUTOUPGRADE" ^
--apply-immediately
```
# タイムゾーンファイル更新後のデータのチェック
タイムゾーンファイルの更新後に、データをチェックすることをお勧めします。準備ステップでは、RDS for Oracle によって次のテーブルが自動的に作成されます。
+ `rdsadmin.rds_dst_affected_tables` - 更新の影響を受けるデータを含むテーブルを一覧表示します
+ `rdsadmin.rds_dst_error_table` - 更新中に生成されたエラーを一覧表示します
これらのテーブルは、準備ウィンドウで作成するテーブルから独立しています。更新の結果を表示するには、次のようにテーブルをクエリします。
```
SELECT * FROM rdsadmin.rds_dst_affected_tables;
SELECT * FROM rdsadmin.rds_dst_error_table;
```
影響を受けるデータおよびエラーテーブルのスキーマの詳細については、Oracle ドキュメントの [FIND\$1AFFECTED\$1TABLES Procedure](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_DST.html#GUID-1F977505-671C-4D5B-8570-86956F136199) を参照してください。
# Oracle Transparent Data Encryption
Amazon RDS は、Oracle Enterprise Edition で使用可能な Oracle Advanced Security オプションの機能である Oracle Transparent Data Encryption (TDE) をサポートしています。この機能は、ストレージへの書き込み前に自動的にデータを暗号化し、ストレージからのデータの読み取り時に自動的にデータを復号します。このオプションは、Bring Your Own License (BYOL) モデルでのみサポートされています。
TDE は、データファイルやバックアップが第三者によって取得された場合に機密データを暗号化する必要があるシナリオで便利です。TDE は、セキュリティ関連の規制に準拠する必要がある場合にも役立ちます。
Oracle Database TDE に関する詳細な説明は、このガイドでは取り上げません。詳細については、次の Oracle Database リソースを参照してください。
+ Oracle Database ドキュメントの「[透過的データ暗号化の概要](https://docs.oracle.com/en/database/oracle/oracle-database/19/asoag/introduction-to-transparent-data-encryption.html#GUID-62AA9447-FDCD-4A4C-B563-32DE04D55952)」
+ Oracle Database ドキュメントの「[Oracle アドバンストセキュリティ](https://www.oracle.com/security/database-security/)」
+ Oracle ホワイトペーパーの「[Oracle アドバンストセキュリティの透過的データ暗号化のベストプラクティス](https://www.oracle.com/br/a/tech/docs/technical-resources/twp-transparent-data-encryption-bestpractices.pdf)」
RDS for Oracle で TDE を使用する方法の詳細については、次のブログを参照してください。
+ [Amazon RDS の Oracle Database 暗号化オプション](https://aws.amazon.com/blogs/apn/oracle-database-encryption-options-on-amazon-rds/)
+ [ を使用して、ダウンタイムを短縮してクロスアカウント TDE 対応 Amazon RDS for Oracle DB インスタンスを移行するAWS DMS](https://aws.amazon.com/blogs/database/migrate-a-cross-account-tde-enabled-amazon-rds-for-oracle-db-instance-with-reduced-downtime-using-aws-dms/)
## TDE 暗号化モード
Oracle Transparent Data Encryption では、TDE テーブルスペース暗号化と TDE 列暗号化の 2 つの暗号化モードがサポートされます。TDE テーブルスペース暗号化は、アプリケーションテーブル全体の暗号化に使用されます。TDE 列暗号化は、機密データを含む個々のデータ要素を暗号化するために使用されます。TDE のテーブルスペース暗号化と列暗号化の両方を使用するハイブリッド暗号化ソリューションを適用することもできます。
**注記**
DB インスタンス用の Oracle Wallet と TDE マスターキーは Amazon RDS によって管理されます。コマンド `ALTER SYSTEM set encryption key` を使用して暗号化キーを設定する必要はありません。
`TDE` オプションを有効にすると、次のコマンドを使用して Oracle Wallet のステータスを確認できます。
```
SELECT * FROM v$encryption_wallet;
```
暗号化されたテーブルスペースを作成するには、次のコマンドを使用します。
```
CREATE TABLESPACE encrypt_ts ENCRYPTION DEFAULT STORAGE (ENCRYPT);
```
暗号アルゴリズムを指定するには、以下のコマンドを実行します。
```
CREATE TABLESPACE encrypt_ts ENCRYPTION USING 'AES256' DEFAULT STORAGE (ENCRYPT);
```
テーブルスペースを暗号化するための前述のステートメントは、オンプレミスの Oracle データベースで使用するステートメントと同じです。
## TDE オプションの制限事項
オプションは永続的かつ固定的です。DB インスタンスを TDE オプションが有効になっているオプショングループに関連付けると、次のアクションを実行することはできません。
+ 現在関連付けられているオプショングループの `TDE` オプションを無効にします。
+ `TDE` オプションを含まない異なるオプショングループに DB インスタンスを関連付けます。
+ `TDE` オプションを使用している DB スナップショットを共有します。DB スナップショットの共有の詳細については、「[Amazon RDS の DB スナップショットを共有する](USER_ShareSnapshot.md)」を参照してください。
永続的および固定的オプションの詳細については、「[永続オプションと固定オプション](USER_WorkingWithOptionGroups.md#Overview.OptionGroups.Permanent)」を参照してください。
## DB インスタンスが TDE を使用しているかどうかの確認
`TDE` オプションを含むオプショングループに DB インスタンスが関連付けられているかどうかを調べるたい場合があります。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) を使用します。
## TDE オプションの追加
`TDE` オプションを DB インスタンスに追加するには、次のステップを完了します。
1. (推奨) DB インスタンスのスナップショットを取ります。
1. 次のいずれかのタスクを行います。
+ 新しいオプショングループを初めから作成します。詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
+ AWS CLI または API を使用して既存のオプショングループをコピーします。詳細については、「[オプショングループをコピーする](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Copy)」を参照してください。
+ デフォルト以外の既存のオプショングループを再利用します。ベストプラクティスは、DB インスタンスまたはスナップショットに現在関連付けられていないオプショングループを使用することです。
1. 前のステップからオプショングループに新しいオプションを追加します。
1. 現在 DB インスタンスに関連付けられているオプショングループでオプションが有効になっている場合は、これらのオプションを新しいオプショングループに追加します。この戦略は、新しいオプションを有効にしている間に既存のオプションがアンインストールされるのを防ぐことができます。
1. DB インスタンスに新しいオプショングループを追加します。
### コンソール
**TDE オプションをオプショングループに追加して、DB インスタンスに関連付けるには**
1. RDS コンソールで、[**オプショングループ**] を選択します。
1. オプションを追加するオプショングループの名前を選択します。
1. **[オプションを追加]** を選択します。
1. [**オプション名**] として [**TDE**] を選択し、オプション設定を行います。
1. **[オプションを追加]** を選択します。
**重要**
1 つ以上の DB インスタンスにアタッチされているオプショングループに **TDE** オプションを追加すると、すべての DB インスタンスが自動的に再起動する間に短い停止が発生します。
オプションの追加方法の詳細については、「[オプショングループにオプションを追加する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption)」を参照してください。
1. オプショングループを新規または既存の DB インスタンスに関連付けます。
+ 新しい DB インスタンスの場合は、インスタンスを起動するときにオプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の DB インスタンスの場合は、インスタンスを修正し、新しいオプショングループを添付することで、オプショングループを適用します。DB インスタンスは、この操作の一部として再起動されません。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
### AWS CLI
次の例では、AWS CLI [add-option-to-option-group](https://docs.aws.amazon.com/cli/latest/reference/rds/add-option-to-option-group.html) コマンドを使用して、`TDE` オプションを `myoptiongroup` という名前のオプショングループに追加します。詳細については、「[開始方法: Flink 1.13.2](https://docs.aws.amazon.com/managed-flink/latest/java/earlier.html#getting-started-1-13)」を参照してください。
Linux、macOS、Unix の場合:
```
aws rds add-option-to-option-group \
--option-group-name "myoptiongroup" \
--options "OptionName=TDE" \
--apply-immediately
```
Windows の場合:
```
aws rds add-option-to-option-group ^
--option-group-name "myoptiongroup" ^
--options "OptionName=TDE" ^
--apply-immediately
```
## TDE オプションを含まない DB インスタンスへのデータのコピー
DB インスタンスから TDE オプションを削除したり、TDE オプションを含まないオプショングループに関連付けることはできません。TDE オプションを含まないインスタンスにデータを移行するには、次の手順を実行します。
1. DB インスタンス上のデータを復号します。
1. `TDE` が有効になっているオプショングループに関連付けられていない新しい DB インスタンスにデータをコピーします。
1. 元の DB インスタンスを削除します。
新しいインスタンスには、前の DB インスタンスと同じ名前を付けることができます。
## Oracle Data Pump で TDE を使用する場合の考慮事項
暗号化されたダンプファイルをインポートまたはエクスポートするには、Oracle Data Pump を使用します。Amazon RDS は、Oracle Data Pump 用のパスワード暗号化モード `(ENCRYPTION_MODE=PASSWORD)` をサポートしています。Oracle Data Pump 用の透過的暗号化モード `(ENCRYPTION_MODE=TRANSPARENT)` は、Amazon RDS でサポートされていません。詳細については、「[Oracle Data Pump を使用したインポート](Oracle.Procedural.Importing.DataPump.md)」を参照してください。
# Oracle UTL\$1MAIL
Amazon RDS では、UTL\$1MAIL オプションおよび SMTP サーバーを使用して Oracle UTL\$1MAIL をサポートしています。UTL\$1MAIL パッケージを使用して、データベースから直接電子メールを送信できます。Amazon RDS では、Oracle の次のバージョンで UTL\$1MAIL をサポートしています。
+ Oracle Database 21c (21.0.0.0)、すべてのバージョン
+ Oracle Database 19c (19.0.0.0)、すべてのバージョン
UTL\$1MAIL を使用する場合の制約をいくつか次に示します。
+ UTL\$1MAIL は Transport Layer Security (TLS) をサポートしていないため、E メールは暗号化されません。
カスタムの Oracle ウォレットを作成およびアップロードして、リモート SSL/TLS リソースに安全に接続するには、「[証明書と Oracle ウォレットを使用した、UTL\$1HTTP アクセスの設定](Oracle.Concepts.ONA.md)」の手順を行います。
Wallet に必要な固有の証明書は、サービスによって異なります。AWS のサービスの場合は、通常、[Amazon Trust Services リポジトリ](https://www.amazontrust.com/repository/)にあります。
+ UTL\$1MAIL は、SMTP サーバーでの認証をサポートしていません。
+ E メールでは 1 つの添付ファイルのみ送信できます。
+ 32 K より大きい添付ファイルを送信することはできません。
+ ASCII および Extended Binary Coded Decimal Interchange Code (EBCDIC) 文字エンコードのみ使用できます。
+ SMTP ポート (25) は、Elastic Network Interface 所有者のポリシーに基づいてスロットリングされます。
UTL\$1MAIL を有効にすると、DB インスタンスのマスターユーザーのみに実行権限が付与されます。必要に応じて、UTL\$1MAIL を使用できるよう、マスターユーザーは他のユーザーに実行権限を付与することができます。
**重要**
UTL\$1MAIL プロシージャの使用を追跡するため、Oracle の組み込み監査機能を有効にすることをお勧めします。
## Oracle UTL\$1MAIL の前提条件
Oracle UTL\$1MAIL を使用するための前提条件は次のとおりです。
+ 1 つ以上の SMTP サーバーと、対応する IP アドレスまたはパブリック/プライベートドメインネームサーバー (DNS) 名。カスタム DNS サーバーを通じて解決されるプライベート DNS 名については、「[カスタム DNS サーバーのセットアップ](Appendix.Oracle.CommonDBATasks.System.md#Appendix.Oracle.CommonDBATasks.CustomDNS)」を参照してください。
## Oracle UTL\$1MAIL オプションの追加
DB インスタンスに Oracle UTL\$1MAIL オプションを追加する一般的な手順は以下のとおりです。
1. 新しいオプショングループを作成するか、既存のオプショングループをコピーまたは変更します。
1. オプショングループに [] オプションを追加します。
1. オプショングループを DB インスタンスに関連付けます。
UTL\$1MAIL オプションの追加後、オプショングループがアクティブになるとすぐに、UTL\$1MAIL がアクティブになります。
**UTL\$1MAIL オプションを DB インスタンスに追加するには**
1. 使用するオプショングループを決定します。新しいオプショングループを作成することも、既存のオプショングループを使用することもできます。既存のオプショングループを使用する場合は、次のステップは飛ばしてください。または、次の設定でカスタム DB オプショングループを作成します。
1. [**Engine**] で、使用する Oracle のエディションを選択します。
1. [**メジャーエンジンのバージョン**] で、DB インスタンスのバージョンを選択します。
詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」を参照してください。
1. オプショングループに [**UTL\$1MAIL**] オプションを追加します。オプションの追加方法の詳細については、「[オプショングループにオプションを追加する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption)」を参照してください。
1. 新規または既存の DB インスタンスに、DB オプショングループを適用します。
+ 新規 DB インスタンスの場合は、インスタンスを起動するときにオプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ 既存の DB インスタンスの場合は、インスタンスを修正し、新しいオプショングループを添付することで、オプショングループを適用します。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
## Oracle UTL\$1MAIL の使用
UTL\$1MAIL オプションを有効にした後、それを使用する前に、SMTP サーバーを設定する必要があります。
SMTP\$1OUT\$1SERVER パラメータを有効な IP アドレスまたはパブリック DNS 名に設定することで、SMTP サーバーを設定します。SMTP\$1OUT\$1SERVER パラメータでは、複数のサーバーのアドレスのカンマ区切りリストを指定できます。初期のサーバーが利用できない場合、UTL\$1MAIL は次のサーバーを順に試します。
[DB パラメータグループ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html)を使用して、DB インスタンスのデフォルトの SMTP\$1OUT\$1SERVER を設定できます。DB インスタンスで、データベースで以下のコードを実行して、セッションの SMTP\$1OUT\$1SERVER パラメータを設定できます。
```
1. ALTER SESSION SET smtp_out_server = mailserver.domain.com:25;
```
UTL\$1MAIL オプションが有効になり、SMTP\$1OUT\$1SERVER が設定されたら、`SEND` プロシージャを使用して E メールを送信できます。詳細については、Oracle ドキュメントの [UTL\$1MAIL](http://docs.oracle.com/cd/B19306_01/appdev.102/b14258/u_mail.htm#BABFJJBD) を参照してください。
## Oracle UTL\$1MAIL オプションの削除
DB インスタンスから Oracle UTL\$1MAIL を削除できます。
DB インスタンスから UTL\$1MAIL を削除するには、次のいずれかを実行します。
+ 複数の DB インスタンスから UTL\$1MAIL を削除するには、属しているオプショングループから UTL\$1MAIL オプションを削除します。この変更はそのオプショングループを使用するすべての DB インスタンスに影響します。詳細については、「[オプショングループからオプションを削除する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.RemoveOption)」を参照してください。
+ 単一の DB インスタンスから UTL\$1MAIL を削除するには、DB インスタンスを変更し、UTL\$1MAIL オプションが含まれていない別のオプショングループを指定します。デフォルト (空) のオプショングループや別のカスタムオプショングループを指定できます。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
## トラブルシューティング
Amazon RDS で UTL\$1MAIL を使用する際に生じる可能性がある問題は以下のとおりです。
+ Throttling。SMTP ポート (25) は、Elastic Network Interface 所有者のポリシーに基づいてスロットリングされます。UTL\$1MAIL を使用して正常に E メールを送信できたにもかかわらず、`ORA-29278: SMTP transient error: 421 Service not available` エラーが表示された場合は、スロットリングされている可能性があります。E メール配信がスロットリングされた場合は、バックオフアルゴリズムを実装することをお勧めします。バックオフアルゴリズムの詳細については、「[AWS でのエラーの再試行とエクスポネンシャルバックオフ](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)」および「["throttling Maximum sending rate exceeded" エラーの対処法](https://aws.amazon.com/blogs/ses/how-to-handle-a-throttling-maximum-sending-rate-exceeded-error/)」を参照してください。
この調整の削除をリクエストできます。詳細については、「[EC2 インスタンスからポート 25 のスロットルを削除する方法を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-port-25-throttle/)」を参照してください。
# Oracle XML DB
Oracle XML DB は、DB インスタンスにネイティブ XML サポートを追加します。XML DB を使用すると、構造化 XML または非構造化 XML とリレーショナルデータを保存および取得できます。XML DB プロトコルサーバーは、RDS for Oracle ではサポートされていません。
XML DB は、Oracle Database 12c 以降にプレインストールされています。したがって、オプショングループを使用して XML DB を追加機能として明示的にインストールする必要はありません。
XML DB を設定して使用する方法については、Oracle Database ドキュメントの「[Oracle XML DB 開発者ガイド](https://docs.oracle.com/en/database/oracle/oracle-database/19/adxdb/)」を参照してください。
# RDS for Oracle DB エンジンのアップグレード
Amazon RDS が新バージョンの Oracle Database をサポートするときには、DB インスタンスを新バージョンにアップグレードできます。Amazon RDS で使用できる Oracle のバージョンの詳細については、[https://docs.aws.amazon.com/AmazonRDS/latest/OracleReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/OracleReleaseNotes/Welcome.html)を参照してください。
**重要**
RDS for Oracle Database の 11g、12c、および 18c はサポートされなくなりました。Oracle Database の 11g、12c、または 18c スナップショットを維持する場合は、それ以降のリリースにアップグレードできます。詳細については、「[Oracle DB スナップショットのアップグレード](USER_UpgradeDBSnapshot.Oracle.md)」を参照してください。
**Topics**
+ [RDS for Oracle エンジンのアップグレードの概要](USER_UpgradeDBInstance.Oracle.Overview.md)
+ [Oracle のメジャーバージョンのアップグレード](USER_UpgradeDBInstance.Oracle.Major.md)
+ [Oracle のマイナーバージョンのアップグレード](USER_UpgradeDBInstance.Oracle.Minor.md)
+ [Oracle のデータベースアップグレードに関する考慮事項](USER_UpgradeDBInstance.Oracle.OGPG.md)
+ [Oracle DB アップグレードのテスト](USER_UpgradeDBInstance.Oracle.UpgradeTesting.md)
+ [RDS for Oracle DB インスタンスバージョンのアップグレード](USER_UpgradeDBInstance.Oracle.Upgrading.md)
+ [Oracle DB スナップショットのアップグレード](USER_UpgradeDBSnapshot.Oracle.md)
# RDS for Oracle エンジンのアップグレードの概要
RDS for Oracle DB インスタンスをアップグレードする前に、次の概念を理解しましょう。
**Topics**
+ [メジャーバージョンとマイナーバージョンのアップグレード](#USER_UpgradeDBInstance.Oracle.Overview.versions)
+ [RDS for Oracle のサポート日と必須のアップグレード](#Aurora.VersionPolicy.MajorVersionLifetime)
+ [Oracle エンジンのバージョン管理](#Oracle.Concepts.Patching)
+ [エンジンのアップグレード中の自動スナップショット](#USER_UpgradeDBInstance.Oracle.Overview.snapshots)
+ [マルチ AZ 配置での Oracle のアップグレード](#USER_UpgradeDBInstance.Oracle.Overview.multi-az)
+ [リードレプリカでの Oracle のアップグレード](#USER_UpgradeDBInstance.Oracle.Overview.read-replicas)
## メジャーバージョンとマイナーバージョンのアップグレード
メジャーバージョンは、1～2 年ごとにリリースされる Oracle Database のメジャーリリースです。Oracle Database 19c と Oracle Database 21c は、メジャーリリースです。
RDS for Oracle は、四半期ごとに、サポートされているすべてのメジャーエンジンに対して新しいマイナーエンジンバージョンをリリースします。リリースアップデート (RU) エンジンバージョンには、指定された四半期の RU パッチを含めることで Oracle からのバグ修正が組み込まれています。例えば、21.0.0.0.ru-2024-10.rur-2024-10.r1 は、2024 年 10 月の RU を組み込んだ Oracle Database 21c のマイナーバージョンです。
Spatial パッチバンドル (SPB) エンジンのバージョンには、Oracle Spatial に固有の RU パッチとパッチが含まれています。例えば、19.0.0.0.ru-2025-01.spb-1.r1 は、エンジンバージョン 19.0.0.0.ru-2025-01.rur-2025-01.r1 の RU パッチと Spatial パッチを含むマイナーエンジンバージョンです。通常、RDS for Oracle は、対応する RU の 2～3 週間後に SPB をリリースします。RU と SPB の違いの説明については、「[リリースアップデート (RU) と Spatial パッチバンドル (SPB)](USER_UpgradeDBInstance.Oracle.Minor.md#RUs-and-SPBs)」を参照してください。サポートされている RU と SPB については、「[Release notes for Amazon Relational Database Service (Amazon RDS) for Oracle](https://docs.aws.amazon.com/AmazonRDS/latest/OracleReleaseNotes)」を参照してください。
RDS for Oracle は、DB インスタンスへの次のアップグレードをサポートします。
| アップグレードタイプ | アプリケーションの互換性 | アップグレード方法 | サンプルのアップグレードパス |
| --- | --- | --- | --- |
| メジャーバージョン | メジャーバージョンのアップグレードによって、既存のアプリケーションと互換性のない変更が導入されることがあります。 | 手動のみ | Oracle Database 19c から Oracle Database 21c へ |
| マイナーバージョン | マイナーバージョンのアップグレードには、既存のアプリケーションとの下位互換性がある変更のみが含まれます。 | 自動または手動 | 21.0.0.0.ru-2023-07.rur-2022-07.r1 から 21.0.0.0.ru-2023-10.rur-2022-10.r1 へ |
**重要**
DB エンジンをアップグレードすると、停止が発生します。停止時間の長さは、エンジンのバージョンと DB インスタンスのサイズによって異なります。
本稼働データベースにアップグレードを適用する前に、アップグレードを徹底的にテストしてアプリケーションが正常に動作することを確認してください。詳細については、「[Oracle DB アップグレードのテスト](USER_UpgradeDBInstance.Oracle.UpgradeTesting.md)」を参照してください。
## RDS for Oracle のサポート日と必須のアップグレード
RDS for Oracle のデータベースバージョンには、サポート予定日があります。RDS for Oracle DB エンジンのメジャーバージョンまたはマイナーバージョンのサポート終了日が近づくと、RDS は*強制アップグレード*とも呼ばれる必須アップグレードを開始します。RDS は、次の情報を公開します。
+ 非推奨バージョンからサポートされているバージョンへの手動アップグレードを開始することを推奨する通知
+ サポートされていないバージョンでインスタンスを作成できなくなる日付
+ メンテナンス期間中に RDS がインスタンスをサポートされているバージョンに自動的にアップグレードする日付
+ メンテナンス期間外に RDS がインスタンスをサポートされているバージョンに自動的にアップグレードする日付
**重要**
強制アップグレードは、CloudFormation スタックに予期しない結果をもたらすことがあります。RDS を使用して DB インスタンスを自動的にアップグレードすると、CloudFormation で問題が発生する場合があります。
このセクションは、以下のトピックで構成されます。
**Topics**
+ [RDS for Oracle メジャーリリースのサポート日](#oracle-major-support-dates)
+ [RDS for Oracle のマイナーバージョンのサポート日](#oracle-minor-support-dates)
### RDS for Oracle メジャーリリースのサポート日
RDS for Oracle メジャーバージョンは、少なくとも対応する Oracle Database リリースバージョンのサポート終了日までは利用可能です。次の日付を参考にすると、テストおよびアップグレードのサイクルを計画することができます。これらの日付は、新しいバージョンへのアップグレードが必要になる可能性がある最も早い日付を表します。Amazon は、RDS for Oracle バージョンのサポートを当初発表よりも長く延長した場合、新しい日付を反映してこの表を更新するようにします。
**注記**
[describe-db-major-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-major-engine-versions.html) AWS CLI コマンドを実行するか、[DescribeDBMajorEngineVersions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBMajorEngineVersions.html) RDS API オペレーションを使用して、Oracle データベースのメジャーバージョンを表示できます。
| Oracle Database メジャーリリースバージョン | 新しいバージョンへのアップグレード予定日 |
| --- | --- |
| Oracle Database 19c | 2029 年 12 月 31 日 BYOL プレミアサポート (延長サポートの手数料が免除） 2032 年 12 月 31 日 BYOL 延長サポート (追加料金) または無制限ライセンス契約 2029 年 12 月 31 日、ライセンス込み (LI) |
| Oracle Database 21c | 2027 年 7 月 31 日 (延長サポートでは使用できません） |
RDS は、新しいメジャーバージョンにアップグレードする必要がある少なくとも 12 か月前に通知します。通知には、重要なマイルストーンのタイミング、DB インスタンスへの影響、推奨されるアクションなど、アップグレードプロセスについての説明が記載されています。データベースをメジャーバージョンにアップグレードする前に、新しい RDS for Oracle バージョンに関するアプリケーションのテストを、完全に完了することをお勧めします。
この事前通知期間後は、それ以降のメジャーバージョンへの自動アップグレードが、古いバージョンを実行しているR DS for Oracle DB インスタンスに適用されることを想定してください。その場合は、スケジュールされたメンテナンスウィンドウ中にアップグレードがスタートされます。
詳細については、「My Oracle Support」の「[現在のデータベースリリースのリリーススケジュール](https://support.oracle.com/knowledge/Oracle%20Database%20Products/742060_1.html)」を参照してください。
### RDS for Oracle のマイナーバージョンのサポート日
場合によっては、RDS for Oracle のメジャーリリースのマイナーバージョンのサポートを終了します。RDS は、新しいマイナーバージョンにアップグレードする必要がある少なくとも 6 か月前に通知します。通知には、重要なマイルストーンのタイミング、廃止されたマイナーバージョンを実行している DB インスタンスへの影響、推奨されるアクションなど、アップグレードプロセスについての説明が記載されています。データベースを新しいマイナーバージョンにアップグレードする前に、新しい RDS for Oracle バージョンに関するアプリケーションのテストを、完全に完了することをお勧めします。
廃止およびサポートが終了したマイナーバージョンの詳細については、「[Release notes for Amazon Relational Database Service (Amazon RDS) for Oracle](https://docs.aws.amazon.com/AmazonRDS/latest/OracleReleaseNotes/Welcome.html)」を参照してください。
## Oracle エンジンのバージョン管理
DB エンジンのバージョン管理により、データベースエンジンにパッチを適用してアップグレードするタイミングと方法を制御できます。データベースエンジンのパッチバージョンとの互換性を維持する柔軟性が得られます。また、RDS for Oracle の新しいパッチバージョンを本稼働環境でデプロイする前にテストして、アプリケーションで動作することを確認できます。さらに、独自の条件やタイムラインでバージョンをアップグレードします。
**注記**
Amazon RDS では、Amazon RDS 固有の DB エンジンのバージョンを使用して、Oracle データベースの公式パッチを定期的に収集します。Amazon RDS Oracle 固有のエンジンのバージョンに含まれている Oracle のパッチに関するリストについては、「[https://docs.aws.amazon.com/AmazonRDS/latest/OracleReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/OracleReleaseNotes/Welcome.html)」を参照してください。
## エンジンのアップグレード中の自動スナップショット
Oracle DB インスタンスをアップグレードする際、スナップショットはアップグレードの問題に対する保護を提供します。DB インスタンスのバックアップ保持期間を 0 より大きく設定した場合、Amazon RDS はアップグレード中に以下の DB スナップショットを作成します。
1. アップグレードの変更が行われる前の DB インスタンスのスナップショット。アップグレードが失敗した場合、このスナップショットを復元して、古いバージョンを実行する DB インスタンスを作成できます。
1. アップグレード完了後の DB インスタンスのスナップショット。
**注記**
バックアップ保持期間を変更するには、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
アップグレード後は、以前のエンジンバージョンに戻すことはできません。ただし、アップグレード前のスナップショットを復元することで、新しい Oracle DB インスタンスを作成できます。
## マルチ AZ 配置での Oracle のアップグレード
DB インスタンスがマルチ AZ 配置にある場合、Amazon RDS はプライマリとスタンバイの両方のレプリカをアップグレードします。オペレーティングシステムの更新が不要な場合は、プライマリとスタンバイのアップグレードが同時に実行されます。インスタンスは、アップグレードが完了するまで使用できません。
マルチ AZ 配置でオペレーティングシステムの更新が必要な場合は、データベースのアップグレードをリクエストした時点で、Amazon RDS によって更新が適用されます。Amazon RDS は以下の手順を実行します。
1. 現在のスタンバイ DB インスタンスのオペレーティングシステムを更新します。
1. プライマリ DB インスタンスをスタンバイ DB インスタンスにフェイルオーバーします。
1. 新しいプライマリ DB インスタンス (元のスタンバイインスタンス) のデータベースバージョンをアップグレードします。プライマリデータベースは、アップグレード中は利用できません。
1. 新しいスタンバイ DB インスタンス (元のプライマリインスタンス) のオペレーティングシステムをアップグレードします。
1. 新しいスタンバイ DB インスタンスのデータベースバージョンをアップグレードします。
1. 新しいプライマリ DB インスタンスを元のプライマリ DB インスタンスにフェイルオーバーし、新しいスタンバイ DB インスタンスを元のスタンバイ DB インスタンスにフェイルオーバーします。したがって、Amazon RDS はレプリケーション設定を元の状態に戻します。
## リードレプリカでの Oracle のアップグレード
ソース DB インスタンスとそのすべてのリードレプリカの Oracle DB エンジンバージョンは同じである必要があります。Amazon RDS は、以下の段階を踏んでアップグレードを実行します。
1. ソース DB インスタンスをアップグレードします。リードレプリカはこの段階で使用できます。
1. レプリカのメンテナンスウィンドウに関係なく、リードレプリカを並行してアップグレードします。ソース DB はこの段階で使用できます。
クロスリージョンリードレプリカのメジャーバージョンアップグレードの場合、Amazon RDS によって追加のアクションが実行されます。
+ ターゲットバージョンのオプショングループを自動的に生成します。
+ 元のオプショングループから新しいオプショングループにすべてのオプションとオプション設定をコピーします。
+ アップグレードされたクロスリージョンリードレプリカを新しいオプショングループに関連付けます。
# Oracle のメジャーバージョンのアップグレード
メジャーバージョンアップグレードを実行するためには、DB インスタンスを手動で変更します。メジャーバージョンのアップグレードは自動的に実行されません。
**重要**
本稼働データベースにアップグレードを適用する前に、アップグレードを徹底的にテストしてアプリケーションが正常に動作することを確認してください。詳細については、「[Oracle DB アップグレードのテスト](USER_UpgradeDBInstance.Oracle.UpgradeTesting.md)」を参照してください。
**Topics**
+ [メジャーアップグレードでサポートされているバージョン](#USER_UpgradeDBInstance.Oracle.Major.supported-versions)
+ [メジャーアップグレードでサポートされているインスタンスクラス](#USER_UpgradeDBInstance.Oracle.Major.instance-classes)
+ [メジャーアップグレード前の統計の収集](#USER_UpgradeDBInstance.Oracle.Major.gathering-stats)
+ [メジャーアップグレードの許可](#USER_UpgradeDBInstance.Oracle.Major.allowing-upgrades)
## メジャーアップグレードでサポートされているバージョン
Amazon RDS では、以下のメジャーバージョンへのアップグレードがサポートされています。
****
| 現在のバージョン | サポートされているアップグレード |
| --- | --- |
| CDB アーキテクチャを使用する 19.0.0.0 | 21.0.0.0 |
Oracle Database のメジャーバージョンアップグレードは、同じ月以降にリリースされた Release Update (RU) にアップグレードする必要があります。メジャーバージョンダウングレードは Oracle Database のいずれのバージョンでもサポートされていません。
## メジャーアップグレードでサポートされているインスタンスクラス
現在の Oracle DB インスタンスは、アップグレードするバージョンではサポートされていない DB インスタンスクラスで実行される可能性があります。この場合、アップグレードする前に、サポートされている DB インスタンスクラスに DB インスタンスを移行します。Amazon RDS for Oracle の各バージョンおよびエディションでサポートされている DB インスタンスクラスの詳細については、「[ DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。
## メジャーアップグレード前の統計の収集
メジャーバージョンアップグレードを実行する前に、アップグレードする DB インスタンスのオプティマイザ統計を収集することをお勧めします。これにより、アップグレード中の DB インスタンスのダウンタイムを短縮できます。
オプティマイザ統計を収集するには、DB インスタンスにマスターユーザーとして接続し、次の例のように `DBMS_STATS.GATHER_DICTIONARY_STATS` の手順を実行します。
```
EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;
```
詳細については、Oracle ドキュメントの「[GATHER\$1DICTIONARY\$1STATS プロシージャ](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_STATS.html?source=%3Aso%3Atw%3Aor%3Aawr%3Aodv%3A%3A#GUID-867989C7-ADFC-4464-8981-437CEA7F331E)」を参照してください。
## メジャーアップグレードの許可
エンジンのメジャーバージョンアップグレードは、アプリケーションと互換性がない場合があります。アップグレードは元に戻せません。EngineVersion パラメータに現在のメジャーバージョンとは異なるメジャーバージョンを指定する場合は、メジャーバージョンアップグレードを許可する必要があります。
CLI コマンド [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) を使用して、メジャーバージョンをアップグレードする場合、`--allow-major-version-upgrade` を指定します。この設定は永続的ではないため、メジャーアップグレードを実行するたびに `--allow-major-version-upgrade` を指定する必要があります。このパラメータは、エンジンのマイナーバージョンアップグレードには影響しません。詳細については、「[DB インスタンスのエンジンバージョンのアップグレード](USER_UpgradeDBInstance.Upgrading.md)」を参照してください。
コンソールを使用してメジャーバージョンをアップグレードする場合は、アップグレードを許可するオプションを選択する必要はありません。代わりに、メジャーアップグレードは元に戻せないという警告がコンソールに表示されます。
# Oracle のマイナーバージョンのアップグレード
RDS for Oracle では、マイナーバージョンアップグレードは、メジャー DB エンジンバージョンの更新です。RDS では、マイナーエンジンバージョンは、リリースアップデート (RU) または Spatial パッチバンドル (SPB) のいずれかです。例えば、DB インスタンスでメジャーバージョン Oracle Database 19c とマイナーバージョン 19.0.0.0.ru-2025-10.rur-2025-10.r1 を実行している場合、DB エンジンはマイナーバージョン 19.0.0.0.ru-2026-01.rur-2026-01.r1 にアップグレードできます。RDS for Oracle は、マイナーバージョンのダウングレードをサポートしません。
DB エンジンは、手動または自動でマイナーバージョンにアップグレードできます。手動でアップグレードする方法については、「[エンジンバージョンの手動アップグレード](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual)」を参照してください。自動アップグレードの設定方法については、「[マイナーエンジンバージョンの自動アップグレード](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.AutoMinorVersionUpgrades)」を参照してください。手動でアップグレードするか自動アップグレードするかにかかわらず、マイナーバージョンのアップグレードにはダウンタイムが伴います。アップグレードを計画するときは、このダウンタイムを考慮してください。
Amazon RDS は、複数のデータベースリソースと AWS アカウントにわたるマイナーバージョンの自動アップグレードを管理するためのアップグレードロールアウトポリシーもサポートしています。詳細については、「[自動マイナーバージョンアップグレードの AWS Organizations アップグレードロールアウトポリシーの使用](RDS.Maintenance.AMVU.UpgradeRollout.md)」を参照してください。
**重要**
本稼働データベースにアップグレードを適用する前に、アップグレードを徹底的にテストしてアプリケーションが正常に動作することを確認してください。詳細については、「[Oracle DB アップグレードのテスト](USER_UpgradeDBInstance.Oracle.UpgradeTesting.md)」を参照してください。
**Topics**
+ [リリースアップデート (RU) と Spatial パッチバンドル (SPB)](#RUs-and-SPBs)
+ [Oracle 用自動マイナーバージョンアップグレードの実行](#oracle-minor-version-upgrade-tuning-on)
+ [自動マイナーバージョンアップグレードの AWS Organizations アップグレードロールアウトポリシーの使用](#oracle-minor-version-upgrade-rollout)
+ [Amazon RDS for Oracle でのマイナーバージョン自動アップグレードの通知](#oracle-minor-version-upgrade-advance)
+ [Amazon RDS がマイナーバージョンの自動アップグレードをスケジュールする方法](#oracle-minor-version-upgrade-scheduled)
+ [RDS for Oracle でのマイナーバージョン自動アップグレードの管理](#oracle-minor-version-upgrade-managing)
## リリースアップデート (RU) と Spatial パッチバンドル (SPB)
RDS では、リリースアップデート (RU) は、Oracle Database のセキュリティ修正、バグ修正、新機能を含む四半期ごとのマイナーエンジンバージョンです。Spatial パッチバンドル (SPB) は、Oracle Spatial オプション用に設計されたパッチを含む RU エンジンバージョンです。例えば、19.0.0.0.ru-2025-01.spb-1.r1 という名前の SPB には、対応する RU のすべてのパッチ 19.0.0.0.ru-2025-01.rur-2025-01.r1 と Spatial に固有のパッチが含まれています。SPB は Oracle Database 19c でのみサポートされています。
インスタンスが自動マイナーバージョンアップグレード用に設定されている場合、RU と SPB は別々のアップグレードパスにあります。通常、SPB は対応する RU の 2～3 週間後にリリースされます。次の表は、Oracle Database 19c のマイナーバージョンの例を示しています。
| 標準 RU アップグレードパス | SPB アップグレードパス |
| --- | --- |
| 19.0.0.0.ru-2025-01.rur-2025-01.r1 | 19.0.0.0.ru-2025-01.spb-1.r1 |
| 19.0.0.0.ru-2025-04.rur-2025-04.r1 | 19.0.0.0.ru-2025-04.spb-1.r1 |
| 19.0.0.0.ru-2025-07.rur-2025-07.r1 | 19.0.0.0.ru-2025-07.spb-1.r1 |
| 19.0.0.0.ru-2025-10.rur-2025-10.r1 | 19.0.0.0.ru-2025-10.spb-1.r1 |
DB インスタンスが自動アップグレード用に設定されている場合、インスタンスは現在のバージョンに対応するアップグレードパスにあります。例えば、DB インスタンスがバージョン 19.0.0.0.ru-2025-01.rur-2025-01.r1 を実行している場合、19.0.0.0.ru-2025-04.rur-2025-04.r1 がリリースされると、インスタンスは自動的にこの RU にアップグレードされます。同様に、DB インスタンスが 19.0.0.0.ru-2025-01.spb-1.r1 を実行している場合、19.0.0.0.ru-2025-04.spb-1.r1 がリリースされると、インスタンスは自動的にこの SPB にアップグレードされます。RU である 19.0.0.0.ru-2025-01.rur-2025-01.r1 を実行しているインスタンスは、別のアップグレードパスの SPB である 19.0.0.0.ru-2025-04.spb-1.r1 に自動的にアップグレードされません。
インスタンスが Spatial を使用していない場合でも、DB インスタンスを SPB にアップグレードできますが、Spatial パッチは Oracle Spatial にのみ適用されます。RU から同じエンジンバージョン以上の SPB に手動でアップグレードできます。例えば、インスタンスを 19.0.0.0.ru-2025-01.rur-2025-01.r1 から次のいずれかのエンジンバージョンにアップグレードできます。
+ 19.0.0.0.ru-2025-01.spb-1.r1
+ 19.0.0.0.ru-2025-04.spb-1.r1
RU が上位のエンジンバージョンである場合にのみ、インスタンスを SPB から RU にアップグレードできます。例えば、SPB バージョン 19.0.0.0.ru-2025-04.spb-1.r1 から上位の RU バージョン 19.0.0.0.ru-2025-07.rur-2025-07.r1 にアップグレードできますが、同じ RU バージョン 19.0.0.0.ru-2025-04.rur-2025-04.r1 にアップグレードすることはできません。
DB インスタンスが自動マイナーバージョンアップグレード用に設定されていて、RU から SPB または SPB から RU に手動でアップグレードすると、自動アップグレードパスが変更されます。RU バージョン 19.0.0.0.ru-2025-01.rur-2025-01.r1 から SPB バージョン 19.0.0.0.ru-2025-01.spb-1.r1 に手動でアップグレードするとします。次回の自動マイナーバージョンアップグレードは SPB バージョン 19.0.0.0.ru-2025-04.spb-1.r1 になります。
SPB は RU として機能するため、インスタンスを RU と SPB にアップグレードするための RDS API は同じです。次のコマンドは、RU と SPB へのアップグレードを示しています。
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--engine-version 19.0.0.0.ru-2025-01.rur-2025-01.r1
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--engine-version 19.0.0.0.ru-2025-01.spb-1.r1
```
Oracle Spatial オプションの詳細については、「[Spatial パッチバンドル (SPB) の仕組み](Oracle.Options.Spatial.md#Oracle.Options.Spatial.SPBs)」を参照してください。Oracle Database 19c でサポートされている RU と SPB については、「[Amazon RDS for Oracle Database 19c (19.0.0.0)](https://docs.aws.amazon.com/AmazonRDS/latest/OracleReleaseNotes/oracle-version-19-0.html)」を参照してください。
## Oracle 用自動マイナーバージョンアップグレードの実行
マイナーバージョンの自動アップグレードでは、RDS は手動操作なしで、使用可能な最新のマイナーバージョンを Oracle データベースに適用します。Amazon RDS for Oracle DB インスタンスは、次の状況で、次のメンテナンス期間にアップグレードをスケジュールします。
+ DB クラスターの **[自動マイナーバージョンアップグレード]** オプションが有効になっています。
+ DB インスタンスで最新のマイナー DB エンジンバージョンが実行されていません。
自動アップグレードを有効にする方法については、「[マイナーエンジンバージョンの自動アップグレード](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.AutoMinorVersionUpgrades)」を参照してください。
## 自動マイナーバージョンアップグレードの AWS Organizations アップグレードロールアウトポリシーの使用
Amazon RDS for Oracle は、複数のデータベースリソースと AWS アカウントにわたってマイナーバージョンの自動アップグレードを管理するための AWS Organizations アップグレードロールアウトポリシーをサポートしています。このポリシーにより、手動またはカスタムツールを使用してマイナーバージョンの自動アップグレードを調整する運用上のオーバーヘッドがなくなり、アップグレードは運用環境にロールアウトされる前に本番環境以外の環境で最初に適用されるようになります。新しいマイナーエンジンバージョンが利用可能になると、Amazon RDS は、設定されたアップグレードのロールアウト順序に基づいて DB インスタンスをアップグレードします。
| ロールアウト順序のアップグレード | 一般的なユースケース | アップグレードを開始するタイミング |
| --- | --- | --- |
| First | 開発環境とテスト環境 | 最も早い時間 - 新しいバージョンの検証に最適 |
| 秒 | ステージング環境と重要度の低い運用環境 | 「最初」のフェーズが完了した後 |
| Last | 重要な運用環境 | 「2 番目」のフェーズが完了した後 |
**重要**
DB インスタンスのアップグレードロールアウト順序を設定しない場合、デフォルトで 2 番目に設定されます。
フェーズのタイミングと期間の詳細については、「[Amazon RDS がマイナーバージョンの自動アップグレードをスケジュールする方法](#oracle-minor-version-upgrade-scheduled)」を参照してください。AWS Organizations でのアップグレードロールアウトポリシーの設定については、「[自動マイナーバージョンアップグレードの AWS Organizations アップグレードロールアウトポリシーの使用](RDS.Maintenance.AMVU.UpgradeRollout.md)」を参照してください。
## Amazon RDS for Oracle でのマイナーバージョン自動アップグレードの通知
DB インスタンスでマイナーバージョンの自動アップグレードが有効になっている場合、RDS for Oracle はアップグレードを適用する前に通知する保留中のメンテナンスアクションを作成します。これらの保留中のメンテナンスアクションは、Amazon RDS コンソールのデータベースの詳細ページの **[メンテナンスとバックアップ]** タブで表示できます。
新しいマイナーバージョンが利用可能になると、RDS for Oracle は早期通知 (メンテナンスアクションの保留) を発行します。この早期通知の形式は次のとおりです。
```
An automatic minor version upgrade to engine-version will be applied during your maintenance window on apply-date based on the upgrade rollout order rollout-order. You can change the upgrade rollout order or apply this upgrade manually at any time before the scheduled date through the AWS console or AWS CLI.
```
早期通知の `apply-date` は、Amazon RDS が DB インスタンスをアップグレードする日付です。`rollout-order` はアップグレードのロールアウト順序 (1 番目、2 番目、または最後) です。アップグレードロールアウトポリシーを設定していない場合、この値はデフォルトで 2 番目です。詳細については、「[自動マイナーバージョンアップグレードの AWS Organizations アップグレードロールアウトポリシーの使用](RDS.Maintenance.AMVU.UpgradeRollout.md)」を参照してください。
アップグレードのロールアウトフェーズが開始されると、保留中のメンテナンスアクションメッセージは次の形式に変わります。
```
Automatic minor version upgrade to engine-version
```
このメッセージは、アップグレードがスケジュールされており、スケジュールされた適用日のメンテナンス期間中に適用されることを示します。スケジュールされた適用日は、Amazon RDS コンソールのデータベースの詳細ページの **[メンテナンスとバックアップ]** タブ、または `describe-pending-maintenance-actions` API レスポンスの `CurrentApplyDate` フィールドで確認できます。
次の例は、AWS CLI の `describe-pending-maintenance-actions` コマンドを使用して、保留中のメンテナンスアクションの詳細を取得できることを示しています。
```
aws rds describe-pending-maintenance-actions
"PendingMaintenanceActions": [
{
"ResourceIdentifier": "arn:aws:rds:us-east-1:123456789012:db:orclinst1",
"PendingMaintenanceActionDetails": [
{
"Action": "db-upgrade",
"Description": "Automatic minor version upgrade to 21.0.0.0.ru-2024-07.rur-2024-07.r1",
"CurrentApplyDate": "2024-12-02T08:10:00Z"
}
]
}, ...
```
[describe-pending-maintenance-actions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-pending-maintenance-actions.html) の詳細については、「*AWS CLI コマンドリファレンス*」を参照してください。
## Amazon RDS がマイナーバージョンの自動アップグレードをスケジュールする方法
AWS Organizations のアップグレードロールアウトポリシーを使用する場合、Amazon RDS は設定されたロールアウト順序に基づいたフェーズで DB インスタンスをアップグレードします。このセクションでは、各フェーズのタイミングと期間について説明します。
**フェーズ 0: 早期通知**
RDS for Oracle が新しいマイナーバージョンをリリースすると (通常は Oracle の四半期 RU リリースから 3～4 週間後)、自動マイナーバージョンアップグレードが有効になっているすべての DB インスタンスは早期通知を受信します。この通知は、Amazon RDS コンソールのデータベースの詳細ページの **[メンテナンスとバックアップ]** タブと `describe-pending-maintenance-actions` API レスポンスに表示されます。早期通知フェーズは 2 週間続きます。このフェーズの期間中、自動アップグレードは行われません。
**フェーズ 1: 最初のアップグレードロールアウト順序**
早期通知フェーズの終了時に、RDS for Oracle はアップグレードロールアウト順序が最初の DB インスタンスのアップグレードを開始します。このフェーズは、1 月、4 月、7 月の四半期のマイナーバージョンでは 2～3 週間、10 月の四半期のマイナーバージョンでは 7～8 週間続きます。10 月のマイナーバージョンの延長期間は、年末の祝祭日シーズン中に新しいマイナーバージョンをテストするのに十分な時間を提供します。このフェーズ中に最初のアップグレードのロールアウト順序で作成された新しい DB インスタンスは、自動的にアップグレードされます。
**フェーズ 2: 2 番目のアップグレードロールアウト順序**
フェーズ 1 の終了時に、RDS for Oracle はアップグレードロールアウト順序が 2 番目の DB インスタンスのアップグレードを開始します。このフェーズは、すべての四半期のマイナーバージョンで 2 週間続きます。このフェーズ中に最初のまたは 2 番目のアップグレードロールアウト順序で作成された新しい DB インスタンスは、自動的にアップグレードされます。
**フェーズ 3: 最後のアップグレードロールアウト順序**
フェーズ 2 の終了時に、RDS for Oracle はアップグレードロールアウト順序が最後の DB インスタンスのアップグレードを開始します。このフェーズは、次の四半期のマイナーバージョンリリースまで続きます。このフェーズ中に最初、2 番目、または最後のアップグレードロールアウト順序で作成された新しい DB インスタンスは、自動的にアップグレードされます。
| [Phase] | 開始するタイミング | 時間 | 保留中のメンテナンスアクションメッセージ |
| --- | --- | --- | --- |
| フェーズ 0: 早期通知 | RDS for Oracle が新しいマイナーバージョンをリリースしたとき | 2 週間 | エンジンバージョンへのマイナーバージョンの自動アップグレードは、アップグレードのロールアウト順序の rollout-order に基づき、apply-date にメンテナンスウィンドウ中に適用されます。AWS コンソールまたは AWS CLI を使用して、アップグレードのロールアウト順序を変更したり、スケジュールされた日より前にいつでもこのアップグレードを手動で適用したりできます。 |
| フェーズ 1: 最初のアップグレードロールアウト順序 | 早期通知フェーズの終了 | 1 月/4 月/7 月のマイナーバージョンでは 2～4 週間、10 月のマイナーバージョンでは 7～9 週間 | engine-version への自動マイナーバージョンアップグレード |
| フェーズ 2: 2 番目のアップグレードロールアウト順序 | フェーズ 1 の終了 | 2 週間 | engine-version への自動マイナーバージョンアップグレード |
| フェーズ 3: 最後のアップグレードロールアウト順序 | フェーズ 2 の終了 | 次の四半期ごとのマイナーバージョンリリースまで | engine-version への自動マイナーバージョンアップグレード |
## RDS for Oracle でのマイナーバージョン自動アップグレードの管理
DB インスタンスでマイナーバージョンの自動アップグレードが有効になっている場合、Amazon RDS はメンテナンスウィンドウ中に DB インスタンスを最新のマイナーバージョンに自動的にアップグレードします。ただし、AWS CLI を使用するか、データベースの詳細ページの **[メンテナンスとバックアップ]** タブから、スケジュール日より前に手動でアップグレードを適用できます。
スケジュールされたメンテナンスウィンドウを待たずに DB インスタンスをすぐにアップグレードするには
```
aws rds apply-pending-maintenance-action \
--resource-identifier arn:aws:rds:us-east-1:123456789012:db:orclinst1 \
--apply-action db-upgrade \
--opt-in-type immediate
```
スケジュールされた適用日ではなく、次のメンテナンスウィンドウ中にアップグレードを適用するには
```
aws rds apply-pending-maintenance-action \
--resource-identifier arn:aws:rds:us-east-1:123456789012:db:orclinst1 \
--apply-action db-upgrade \
--opt-in-type next-maintenance
```
自動マイナーバージョンアップグレードをオプトアウトするには、DB インスタンスを変更し、自動マイナーバージョンアップグレードオプションをオフにします。これにより、保留中の自動アップグレードのスケジュールが解除されます。
マイナーバージョンの自動アップグレードをオフにする方法の詳細については、「[マイナーエンジンバージョンの自動アップグレード](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.AutoMinorVersionUpgrades)」を参照してください。マイナーバージョンの自動アップグレードの無効化についてサポートが必要な場合は、AWS サポートにお問い合わせください。
RDS が以前のマイナーバージョンを適用する前に、新しいマイナーバージョンが利用可能になる場合があります。例えば、`both 21.0.0.0.ru-2025-10.rur-2025-10.r1` および `21.0.0.0.ru-2026-01.rur-2026-01.r1` がアップグレードターゲットとして利用可能な場合、インスタンスは `21.0.0.0.ru-2025-07.rur-2025-07.r1` で実行されています。この場合、DB インスタンスの不要なダウンタイムを回避するために、RDS はマイナーバージョンの自動アップグレードを最新バージョンにスケジュールし、以前のバージョンへのアップグレードをスキップします。この例では、RDS はインスタンスを `21.0.0.0.ru-2025-07.rur-2025-07.r1` から `21.0.0.0.ru-2026-01.rur-2026-01.r1` に直接アップグレードします。
# Oracle のデータベースアップグレードに関する考慮事項
Oracle インスタンスをアップグレードする前に、次の情報を確認してください。
**Topics**
+ [Oracle マルチテナントに関する考慮事項](#USER_UpgradeDBInstance.Oracle.multi)
+ [オプショングループに関する考慮事項](#USER_UpgradeDBInstance.Oracle.OGPG.OG)
+ [パラメータグループに関する考慮事項](#USER_UpgradeDBInstance.Oracle.OGPG.PG)
+ [タイムゾーンに関する考慮事項](#USER_UpgradeDBInstance.Oracle.OGPG.DST)
+ [Spatial パッチバンドル (SPB) に関する考慮事項](#USER_UpgradeDBInstance.Oracle.SPB)
## Oracle マルチテナントに関する考慮事項
次の表では、さまざまなリリースでサポートされる Oracle Database アーキテクチャについて説明します。
| Oracle Database のリリース | RDS のサポートステータス | アーキテクチャ |
| --- | --- | --- |
| Oracle Database 21c | サポート対象 | CDB のみ |
| Oracle Database 19c | サポート対象 | CDB または非 CDB |
次の表に、サポートされているアップグレードパスとサポートされていないアップグレードパスを示します。
| アップグレードパス | サポート対象? |
| --- | --- |
| CDB から CDB | はい |
| 非 CDB から CDB | いいえ。ただし、非 CDB を CDB に変換してからアップグレードできます。 |
| CDB から非 CDB | いいえ |
Oracle で RDS を使用するOracle のマルチテナントに関する詳細は、「[CDB アーキテクチャのシングルテナント設定](Oracle.Concepts.CDBs.md#Oracle.Concepts.single-tenant)」を参照してください。
## オプショングループに関する考慮事項
DB インスタンスがカスタムオプショングループを使用している場合、Amazon RDS が新しいオプショングループを自動的に割り当てられないことがあります。例えば、この状況は、新しいメジャーバージョンにアップグレードするときに発生します。このような場合、アップグレード時に新しいオプショングループを指定します。新しいオプショングループを作成し、このオプショングループに既存のカスタムオプショングループと同じオプションを追加することをお勧めします。
詳細については、「[オプショングループを作成する](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create)」または「[オプショングループをコピーする](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Copy)」を参照してください。
DB インスタンスで使用するカスタムオプショングループに `APEX` オプションと `APEX-DEV` オプションが含まれている場合、アップグレード時間を短縮できる可能性があります。そのためには、使用しているバージョンの APEX を DB インスタンスと同時にアップグレードします。詳細については、「[Oracle APEX バージョンのアップグレード](Appendix.Oracle.Options.APEX.UpgradeandRemove.md#Appendix.Oracle.Options.APEX.Upgrade)」を参照してください。
## パラメータグループに関する考慮事項
DB インスタンスでカスタムパラメータグループを使用している場合、Amazon RDS で DB インスタンスに新しいパラメータグループを自動的に割り当てられないことがあります。例えば、この状況は、新しいメジャーバージョンにアップグレードするときに発生します。このような場合、アップグレード時に必ず新しいパラメータグループを指定する必要があります。新しいパラメータグループを作成し、そのパラメータの設定を既存のカスタムパラメータグループと同じにすることをお勧めします。
詳細については、「[Amazon RDS での DB パラメータグループの作成](USER_WorkingWithParamGroups.Creating.md)」または「[Amazon RDS での DB パラメータグループのコピー](USER_WorkingWithParamGroups.Copying.md)」を参照してください。
## タイムゾーンに関する考慮事項
タイムゾーンオプションを使用して、Oracle DB インスタンスで使用する*システムのタイムゾーン*を変更することができます。例えば、オンプレミス環境またはレガシーアプリケーションとの互換性があるように、DB インスタンスのタイムゾーンで変更が必要になることがあります。タイムゾーンオプションでは、ホストレベルでタイムゾーンが変更されます。Amazon RDS for Oracle では、システムタイムゾーンは年間を通して自動的に更新されます。システムのタイムゾーンの詳細については、「[Oracle のタイムゾーン](Appendix.Oracle.Options.Timezone.md)」を参照してください。
Oracle DB インスタンスを作成すると、データベースによって *データベースのタイムゾーン*が自動的に設定されます。データベースのタイムゾーンは、夏時間 (DST) タイムゾーンとも呼ばれます。データベースのタイムゾーンは、システムのタイムゾーンとは異なります。
Oracle Database の各リリース間には、パッチセットまたは個々のパッチに、新しい DST バージョンが含まれる場合があります。これらのパッチは、さまざまなタイムゾーンリージョンの移行ルールの変更を反映しています。例えば、DST が有効になると、政府機関が変わる場合があります。DST ルールを変更すると、`TIMESTAMP WITH TIME ZONE` データ型の既存のデータに影響する場合があります。
RDS for Oracle DB インスタンスをアップグレードする場合、Amazon RDS はデータベースのタイムゾーンファイルを自動的にアップグレードしません。タイムゾーンファイルを自動的にアップグレードするには、エンジンバージョンのアップグレード中またはアップグレード後に、DB インスタンスに関連付けられたオプショングループに `TIMEZONE_FILE_AUTOUPGRADE` オプションを追加します。詳しくは、「[Oracle のタイムゾーンファイルの自動アップグレード](Appendix.Oracle.Options.Timezone-file-autoupgrade.md)」を参照してください。
データベースのタイムゾーンファイルを手動でアップグレードするには、必要な DST パッチを持つ新しい Oracle DB インスタンスを作成します。ただし、`TIMEZONE_FILE_AUTOUPGRADE` オプションを使用して、データベースのタイムゾーンファイルをアップグレードすることをお勧めします。
タイムゾーンファイルのアップグレード後、現在のインスタンスから新しいインスタンスにデータを移行します。データを移行するには、以下を含む複数の手法を使用できます。
+ AWS Database Migration Service
+ Oracle GoldenGate
+ Oracle Data Pump
+ 元のエクスポート/インポート (一般的な使用に対してはサポート終了)
**注記**
Oracle Data Pump を使用してデータを移行すると、ターゲットのタイムゾーンバージョンがソースのタイムゾーンバージョンよりも古い場合、エラー ORA-39405 が発生します。
詳細については、Oracle ドキュメントの「[TIMESTAMP WITH TIMEZONE Restrictions](https://docs.oracle.com/en/database/oracle/oracle-database/19/sutil/oracle-data-pump-overview.html#GUID-9B6C92EE-860E-43DD-9728-735B17B9DA89)」を参照してください。
## Spatial パッチバンドル (SPB) に関する考慮事項
RDS for Oracle では、リリースアップデート (RU) は、Oracle Database のセキュリティ修正、バグ修正、新機能を含むマイナーエンジンバージョンです。Spatial パッチバンドル (SPB) は、Oracle Spatial オプション用に設計されたパッチも含むマイナーエンジンバージョンです。例えば、19.0.0.0.ru-2025-01.spb-1.r1 は、エンジンバージョン 19.0.0.0.ru-2025-01.rur-2025-01.r1 の RU パッチと Spatial パッチを含むマイナーエンジンバージョンです。
データベースを SPB にアップグレードする場合は、以下を考慮してください。
+ SPB は Oracle Database 19c でのみサポートされています。
+ 通常、SPB は対応する四半期 RU の 2～3 週間後にリリースされます。
+ インスタンスが Oracle Spatial オプションを使用していない場合でも、DB インスタンスを SPB にアップグレードできますが、エンジンバージョンの Spatial パッチは Oracle Spatial にのみ適用されます。SPB に新しいインスタンスを作成し、後で Oracle Spatial オプションをインストールできます。
+ DB インスタンスの自動マイナーバージョンアップグレードを有効にする場合、アップグレードパスは、インスタンスが現在 SPB または RU のどちらを使用しているかによって異なります。インスタンスが SPB を使用している場合、RDS はインスタンスを最新の SPB に自動的にアップグレードします。インスタンスが RU を使用している場合、RDS はインスタンスを最新の RU に自動的にアップグレードします。
+ SPB が現在の RU と同じエンジンバージョン以上である場合にのみ、DB インスタンスを RU から SPB に手動でアップグレードできます。
+ RU が上位バージョンである場合にのみ、DB インスタンスを SPB から RU に手動でアップグレードできます。
# Oracle DB アップグレードのテスト
DB インスタンスをメジャーバージョンにアップグレードする前に、データベースとデータベースにアクセスするすべてのアプリケーションについて、新しいバージョンとの互換性を綿密にテストする必要があります。以下の手順を実行することをお勧めします。
**メジャーバージョンのアップグレードをテストするには**
1. データベースエンジンの新しいバージョンについて Oracle アップグレードドキュメントを参照して、データベースやアプリケーションに影響を与える可能性のある互換性の問題があるかどうかを確認します。詳細については、Oracle ドキュメントの「Database Upgrade Guide[」を参照してください](https://docs.oracle.com/database/121/UPGRD/toc.htm)。
1. DB インスタンスでカスタムオプショングループを使用している場合は、アップグレード先の新しいバージョンと互換性がある新しいオプショングループを作成します。詳細については、「[オプショングループに関する考慮事項](USER_UpgradeDBInstance.Oracle.OGPG.md#USER_UpgradeDBInstance.Oracle.OGPG.OG)」を参照してください。
1. DB インスタンスでカスタムパラメータグループを使用している場合は、アップグレード先の新しいバージョンと互換性がある新しいパラメータグループを作成します。詳細については、「[パラメータグループに関する考慮事項](USER_UpgradeDBInstance.Oracle.OGPG.md#USER_UpgradeDBInstance.Oracle.OGPG.PG)」を参照してください。
1. アップグレードする DB インスタンスの DB スナップショットを作成します。詳細については、「[Amazon RDS のシングル AZ DB インスタンスの DB スナップショットの作成](USER_CreateSnapshot.md)」を参照してください。
1. DB スナップショットを復元して、新しいテスト DB インスタンスを作成します。詳細については、「[DB インスタンスへの復元](USER_RestoreFromSnapshot.md)」を参照してください。
1. この新しいテスト DB インスタンスを変更して新しいバージョンにアップグレードするには、次に説明するいずれかの方法を使用します。
+ [コンソール](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual.Console)
+ [AWS CLI](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual.CLI)
+ [RDS API](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual.API)
1. テストを実行します。
+ データベースとアプリケーションが新しいバージョンで正常に動作することが確認されるまで、アップグレードした DB インスタンスに対する品質保証テストを必要な回数だけ実行します。
+ 手順 1 で特定した互換性の問題の影響を評価するための新しいテストを実行します。
+ すべてのストアドプロシージャ、関数、トリガーをテストします。
+ アプリケーションのテストバージョンを、アップグレードした DB インスタンスに割り振ります。アプリケーションが新しいバージョンで正しく動作することを確認します。
+ アップグレードしたインスタンスによって使用されるストレージを評価して、アップグレードに追加のストレージが必要かどうかを判断します。本稼働で新しいバージョンをサポートするために、より大きなインスタンスのクラスを選択する必要がある場合もあります。詳細については、「[ DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。
1. すべてのテストに合格したら、本番稼働用 DB インスタンスをアップグレードします。DB インスタンスへの書き込みオペレーションを許可する前に、DB インスタンスが正しく機能していることを確認することをお勧めします。
# RDS for Oracle DB インスタンスバージョンのアップグレード
RDS for Oracle DB インスタンスの DB エンジンバージョンを手動でアップグレードするには、AWS マネジメントコンソール、AWS CLI または RDS API を使用します。データベースのアップグレードに関する一般的な情報については、「[RDS for Oracle DB インスタンスバージョンのアップグレード](#USER_UpgradeDBInstance.Oracle.Upgrading)」を参照してください。有効なアップグレードターゲットを取得するには、AWS CLI[describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) コマンドを使用します。
## コンソール
**コンソールを使用して RDS for Oracle DB インスタンスのエンジンバージョンをアップグレードするには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**データベース**] を選択し、アップグレードする DB インスタンスを選択します。
1. **[変更]** を選択します。
1. **[DB エンジンバージョン]** で、上位のデータベースバージョンを選択します。
1. [**続行**] を選択して、変更の概要を確認します。データベースバージョンアップグレードの影響を理解していることを確認します。アップグレードした DB インスタンスを以前のバージョンに戻すことはできません。続行する前に、データベースとアプリケーションの両方を新しいバージョンでテストしていることを確認します。
1. DB インスタンスのアップグレードをスケジュールするタイミングを決定します。変更をすぐに反映させるには、[**Apply immediately**] を選択します。このオプションを選択すると、停止状態になる場合があります。詳細については、「[スケジュール変更設定の使用](USER_ModifyInstance.ApplyImmediately.md)」を参照してください。
1. 確認ページで、変更内容を確認します。正しい場合は、[**Modify DB Instance (DB インスタンスを変更)**] を選択して変更を保存します。
または、[**Back**] を選択して変更を編集するか、[**Cancel**] を選択して変更をキャンセルします。
## AWS CLI
RDS for Oracle DB インスタンスのエンジンバージョンをアップグレードするには、CLI の [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) コマンドを使用します。以下のパラメータを指定します。
+ `--db-instance-identifier` – RDS for Oracle DB インスタンスの名前。
+ `--engine-version` - アップグレード先のデータベースエンジンのバージョン番号です。
有効なエンジンバージョンの詳細については、AWS CLI の [describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) コマンドを参照してください。
+ `--allow-major-version-upgrade` – DB エンジンバージョンのアップグレード
+ `--no-apply-immediately` – 次のメンテナンス時間中に変更を適用します。今すぐ変更を適用するには、`--apply-immediately` を使用します。
**Example**
次の例は、`myorainst` という名前の CDB インスタンスを現在のバージョン `19.0.0.0.ru-2024-01.rur-2024-01.r1` からバージョン `21.0.0.0.ru-2024-04.rur-2024-04.r1` にアップグレードします。
Linux、macOS、Unix の場合:
```
1. aws rds modify-db-instance \
2. --db-instance-identifier myorainst \
3. --engine-version 21.0.0.0.ru-2024-04.rur-2024-04.r1 \
4. --allow-major-version-upgrade \
5. --no-apply-immediately
```
Windows の場合:
```
1. aws rds modify-db-instance ^
2. --db-instance-identifier myorainst ^
3. --engine-version 21.0.0.0.ru-2024-04.rur-2024-04.r1 ^
4. --allow-major-version-upgrade ^
5. --no-apply-immediately
```
## RDS API
RDS for Oracle DB インスタンスをアップグレードするには、[ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) アクションを使用します。以下のパラメータを指定します。
+ `DBInstanceIdentifier` – DB インスタンスの名前、例えば *`myorainst`* です。
+ `EngineVersion` – アップグレード先のデータベースエンジンのバージョン番号です。有効なエンジンバージョンについては、[DescribeDBEngineVersions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBEngineVersions.html) オペレーションを使用します。
+ `AllowMajorVersionUpgrade` – メジャーバージョンのアップグレードを許可するかどうか。そのためには、値を `true` に設定します。
+ `ApplyImmediately` – 変更をすぐに適用するか、次のメンテナンスウィンドウ中に適用するかを指定します。今すぐ変更を適用するには、値を `true` に設定します。次のメンテナンスウィンドウ中に変更を適用するには、値を `false` に設定します。
# Oracle DB スナップショットのアップグレード
Amazon RDS で Oracle DB スナップショットをアップグレードすると、データベースの安全性、互換性、および完全なサポートが確保されます。古い Oracle バージョンのパッチサポートが終了した場合、これらのバージョンに関連付けられた手動 DB スナップショットをアップグレードして、潜在的な脆弱性やサービスの制限を回避できます。詳細については、「[Oracle エンジンのバージョン管理](USER_UpgradeDBInstance.Oracle.Overview.md#Oracle.Concepts.Patching)」を参照してください。
Amazon RDS はすべての AWS リージョン のスナップショットのアップグレードに対応しています。
## コンソール
**Oracle DB スナップショットのアップグレード方法**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**スナップショット**] を選択し、アップグレードする DB スナップショットを選択します。
1. [**アクション**] は、[**スナップショットのアップグレード**] を選択します。[**スナップショットのアップグレード**] ページが表示されます。
1. [**New engine version (新しいエンジンバージョン)**] で、スナップショットをアップグレードするバージョンを選択します。
1. (オプション) [**Option group**] には、アップグレードした DB スナップショットのオプショングループを選択します。DB インスタンスをアップグレードするときと同じように DB スナップショットをアップグレードする場合も、同じオプショングループの考慮事項が適用されます。詳細については、「[オプショングループに関する考慮事項](USER_UpgradeDBInstance.Oracle.OGPG.md#USER_UpgradeDBInstance.Oracle.OGPG.OG)」を参照してください。
1. [**Save changes (変更の保存)**] を選択して、変更を保存します。
アップグレード中は、この DB スナップショットに関するスナップショット操作が、すべて無効になります。また、DB スナップショットのステータスは**利用可能**から**アップグレード中**に変わり、プロセスが完了すると**有効**になります。スナップショットの破損問題で DB スナップショットをアップグレードできない場合、ステータスは**使用不可**になります。この状態からスナップショットを復元することはできません。
**注記**
DB スナップショットアップグレードが失敗した場合、スナップショットは元の状態にロールバックします。
## AWS CLI
AWS CLI を使用して Oracle DB スナップショットをアップグレードするには、以下のパラメータを指定して [modify-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-snapshot.html) コマンドを呼び出します。
+ `--db-snapshot-identifier` – DB スナップショットの名前です。
+ `--engine-version` – スナップショットをアップグレードするバージョンです。
必要に応じて、以下のパラメータを含める場合もあります。DB インスタンスをアップグレードするときと同じように DB スナップショットをアップグレードする場合も、同じオプショングループの考慮事項が適用されます。詳細については、「[オプショングループに関する考慮事項](USER_UpgradeDBInstance.Oracle.OGPG.md#USER_UpgradeDBInstance.Oracle.OGPG.OG)」を参照してください。
+ `--option-group-name` – アップグレードした DB スナップショットのオプショングループ。
**Example**
以下の例では、DB スナップショットをアップグレードします。
Linux、macOS、Unix の場合:
```
aws rds modify-db-snapshot \
--db-snapshot-identifier mydbsnapshot \
--engine-version 19.0.0.0.ru-2020-10.rur-2020-10.r1 \
--option-group-name default:oracle-se2-19
```
Windows の場合:
```
aws rds modify-db-snapshot ^
--db-snapshot-identifier mydbsnapshot ^
--engine-version 19.0.0.0.ru-2020-10.rur-2020-10.r1 ^
--option-group-name default:oracle-se2-19
```
## RDS API
Amazon RDS API を使用して Oracle DB スナップショットをアップグレードするには、以下のパラメータを指定して [ModifyDBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBSnapshot.html) オペレーションを呼び出します。
+ `DBSnapshotIdentifier` – DB スナップショットの名前です。
+ `EngineVersion` – スナップショットをアップグレードするバージョンです。
また、`OptionGroupName` パラメータを含めなければならない場合もあります。DB インスタンスをアップグレードするときと同じように DB スナップショットをアップグレードする場合も、同じオプショングループの考慮事項が適用されます。詳細については、「[オプショングループに関する考慮事項](USER_UpgradeDBInstance.Oracle.OGPG.md#USER_UpgradeDBInstance.Oracle.OGPG.OG)」を参照してください。
# RDS for Oracle DB インスタンスでのサードパーティーソフトウェアの使用
ツールとサードパーティーソフトウェアをサポートする RDS for Oracle DB インスタンスをホストできます。
**Topics**
+ [Oracle GoldenGate と Amazon RDS for Oracle の使用](Appendix.OracleGoldenGate.md)
+ [Amazon RDS for Oracle での Oracle リポジトリ作成ユーティリティの使用](Oracle.Resources.RCU.md)
+ [Amazon EC2 インスタンスでの Oracle Connection Manager の設定](oracle-cman.md)
+ [Amazon RDS での Oracle への Siebel Database のインストール](Oracle.Resources.Siebel.md)
# Oracle GoldenGate と Amazon RDS for Oracle の使用
Oracle GoldenGate は、データベース間でトランザクションデータを収集、レプリケート、管理します。このツールは、ログベースの変更データキャプチャ (CDC) であり、オンライントランザクション処理 (OLTP) システムのデータベースで使用されるレプリケーションソフトウェアパッケージです。Oracle GoldenGate によって、ソースデータベースで最近変更されたデータを含んでいるトレイルファイルが作成されます。次に、これらのファイルをサーバーにプッシュします。サーバーでは、プロセスがトレイルファイルを標準 SQL に変換してターゲットデータベースに適用します。
Oracle GoldenGate と RDS for Oracle では、次の機能をサポートしています。
+ アクティブ-アクティブデータベースレプリケーション
+ 災害対策
+ データ保護
+ リージョン内およびクロスリージョンレプリケーション
+ ダウンタイムのない移行とアップグレード
+ RDS for Oracle DB インスタンスと Oracle 以外のデータベース間のデータレプリケーション
**注記**
サポートされているデータベースの一覧については、Oracle ドキュメントの「[Oracle Fusion Middleware Supported System Configurations](https://www.oracle.com/middleware/technologies/fusion-certification.html)」(Oracle Fusion ミドルウェアでサポートされているシステム設定) を参照してください。
RDS for Oracle で Oracle GoldenGate を使用して、Oracle Database のメジャーバージョンにアップグレードすることができます。例えば、Amazon RDS DB インスタンスで Oracle GoldenGate を使用して、Oracle Database 11g オンプレミスデータベースから Oracle Database 19c にアップグレードすることができます。
**Topics**
+ [Oracle GoldenGate でサポートされているバージョンとライセンスオプション](#Appendix.OracleGoldenGate.licensing)
+ [Oracle GoldenGate の要件と制限](#Appendix.OracleGoldenGate.requirements)
+ [Oracle GoldenGate アーキテクチャ](Appendix.OracleGoldenGate.Overview.md)
+ [Oracle GoldenGate のセットアップ](Appendix.OracleGoldenGate.setting-up.md)
+ [Oracle GoldenGate の EXTRACT ユーティリティと REPLICAT ユーティリティを使用する](Appendix.OracleGoldenGate.ExtractReplicat.md)
+ [Oracle GoldenGate のモニタリング](Appendix.OracleGoldenGate.Monitoring.md)
+ [Oracle GoldenGate のトラブルシューティング](Appendix.OracleGoldenGate.Troubleshooting.md)
## Oracle GoldenGate でサポートされているバージョンとライセンスオプション
RDS for Oracle の Standard Edition 2 (SE2) または Enterprise Edition (EE) を Oracle GoldenGate バージョン 12c 以降と使用できます。Oracle GoldenGate の次の機能を使用できます。
+ Oracle GoldenGate Remote キャプチャ (抽出) がサポートされています。
+ キャプチャ (抽出) は、従来の非 CDB データベースアーキテクチャを使用する RDS for Oracle DB インスタンスでサポートされています。Oracle GoldenGate リモート PDB キャプチャは、Oracle Database 21c または Oracle Database 19c バージョン 19.0.0.0.ru-2024-04.rur-2024-04.r1 以降を実行している CDB でサポートされています。
+ Oracle GoldenGate Remote Delivery (replicat) は、非 CDB または CDB アーキテクチャを使用する RDS for Oracle DB インスタンスでサポートされています。Remote Delivery は、Integrated Replicat、Parallel Replicat、Coordinated Replicat、およびクラシック Replicat をサポートします。
+ RDS for Oracle は、Oracle GoldenGate のクラシックアーキテクチャとマイクロサービスアーキテクチャをサポートしています。
+ 統合キャプチャモードを使用する場合、Oracle GoldenGate DDL およびシーケンス値のレプリケーションがサポートされます。
お客様には、すべての AWS リージョン で Amazon RDS で使用するために、Oracle GoldenGate ライセンス (BYOL) を管理する責任があります。詳細については、「[RDS for Oracle のライセンスオプション](Oracle.Concepts.Licensing.md)」を参照してください。
## Oracle GoldenGate の要件と制限
Oracle GoldenGate および RDS for Oracle を使用する場合、次の要件と制限を考慮してください。
+ ユーザーには、RDS for Oracle で使用するために Oracle GoldenGate を設定および管理する責任があります。
+ ユーザーには、ソースデータベースとターゲットデータベースで認定された Oracle GoldenGate バージョンを設定する責任があります。詳細については、Oracle ドキュメントの「[Oracle Fusion Middleware Supported System Configurations](https://www.oracle.com/middleware/technologies/fusion-certification.html)」を参照してください。
+ Oracle GoldenGate は、さまざまな AWS 環境でさまざまなユースケースに使用できます。Oracle GoldenGate に関するサポート関連の問題がある場合は、Oracle サポートサービスにお問い合わせください。
+ Oracle Transparent Data Encryption (TDE) を使用する RDS for Oracle DB インスタンスで、Oracle GoldenGate を使用できます。レプリケートされたデータの整合性を維持するには、 Amazon EBS 暗号化ボリュームまたはトレイルファイル暗号化を使用して Oracle GoldenGate ハブの暗号化を設定します。また、Oracle GoldenGate ハブと、ソースおよびターゲットのデータベースインスタンスの間で送信されるデータの暗号化も設定します。RDS for Oracle DB インスタンスは、[Oracle Secure Sockets Layer](Appendix.Oracle.Options.SSL.md) または [Oracle ネイティブネットワーク暗号化](Appendix.Oracle.Options.NetworkEncryption.md) を使用する暗号化をサポートしています。
# Oracle GoldenGate アーキテクチャ
Amazon RDS で使用される Oracle GoldenGate アーキテクチャは、次の独立したモジュールで構成されています。
ソースデータベース
ソースデータベースは、オンプレミスの Oracle データベース、Amazon EC2 インスタンス上の Oracle データベース、Amazon RDS DB インスタンス上の Oracle データベースのいずれかです。
Oracle GoldenGate ハブ
GoldenGate ハブは、トランザクション情報をソースデータベースからターゲットデータベースに移動します。ハブは次のいずれかになります。
+ Oracle Database と Oracle GoldenGate がインストールされた Amazon EC2 インスタンス
+ オンプレミスの Oracle インストール
複数の Amazon EC2 ハブを使用できます。クロスリージョンレプリケーションで Oracle GoldenGate を使用する場合は、2 つのハブを使用することをお勧めします。
ターゲットデータベース
ターゲットデータベースは、 Amazon RDS DB インスタンス、 Amazon EC2 インスタンス、オンプレミスの場所のいずれかに配置できます。
次のセクションでは、Amazon RDS での Oracle GoldenGate の一般的なシナリオについて説明します。
**Topics**
+ [オンプレミスのソースデータベースと Oracle GoldenGate ハブ](#Appendix.OracleGoldenGate.on-prem-source-gg-hub)
+ [オンプレミスのソースデータベースおよび Amazon EC2 ハブ](#Appendix.OracleGoldenGate.on-prem-source-ec2-hub)
+ [Amazon RDS ソースデータベースおよび Amazon EC2 ハブ](#Appendix.OracleGoldenGate.rds-source-ec2-hub)
+ [Amazon EC2 ソースデータベースと Amazon EC2 ハブ](#Appendix.OracleGoldenGate.ec2-source-ec2-hub)
+ [異なる AWS リージョンの Amazon EC2 ハブ](#Appendix.OracleGoldenGate.cross-region-hubs)
## オンプレミスのソースデータベースと Oracle GoldenGate ハブ
このシナリオでは、オンプレミスの Oracle ソースデータベースとオンプレミスの Oracle GoldenGate ハブから、ターゲットとなる Amazon RDS DB インスタンスにデータが提供されます。
![\[Amazon RDS を使用する Oracle GoldenGate の設定 0\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/oracle-gg0.png)
## オンプレミスのソースデータベースおよび Amazon EC2 ハブ
このシナリオでは、オンプレミス Oracle データベースがソースデータベースとして機能します。Amazon EC2 インスタンスハブに接続されています。このハブから、ターゲットの RDS for Oracle DB インスタンスにデータが提供されます。
![\[Amazon RDS を使用する Oracle GoldenGate の設定 1\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/oracle-gg1.png)
## Amazon RDS ソースデータベースおよび Amazon EC2 ハブ
このシナリオでは、RDS for Oracle DB インスタンスがソースデータベースとして機能します。Amazon EC2 インスタンスハブに接続されています。このハブから、ターゲットの RDS for Oracle DB インスタンスにデータが提供されます。
![\[Amazon RDS を使用する Oracle GoldenGate の設定 2\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/oracle-gg2.png)
## Amazon EC2 ソースデータベースと Amazon EC2 ハブ
このシナリオでは、Amazon EC2 インスタンス上の Oracle データベースがソースデータベースとして機能します。Amazon EC2 インスタンスハブに接続されています。このハブから、ターゲットの RDS for Oracle DB インスタンスにデータが提供されます。
![\[Amazon RDS を使用する Oracle GoldenGate の設定 3\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/oracle-gg3.png)
## 異なる AWS リージョンの Amazon EC2 ハブ
このシナリオでは、Amazon RDS DB インスタンス上の Oracle データベースが、同じ AWS リージョンの Amazon EC2 インスタンスハブに接続されています。ハブは別の AWS リージョンの Amazon EC2 インスタンスハブに接続されています。この 2 番目のハブは、2 番目の Amazon EC2 インスタンスハブとして、同じ AWS リージョン内のターゲット RDS for Oracle DB インスタンスにデータを提供します。
![\[Amazon RDS を使用する Oracle GoldenGate の設定 4\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/oracle-gg4.png)
**注記**
オンプレミス環境で実行中の Oracle GoldenGate に影響する問題は、AWS で実行中の Oracle GoldenGate にも影響します。Oracle GoldenGate ハブをモニタリングし、フェイルオーバーが発生した場合に `EXTRACT` や `REPLICAT` が再起動されていることを確認することを強くお勧めします。Oracle GoldenGate ハブは Amazon EC2 インスタンスで実行されるため、Amazon RDS では Oracle GoldenGate ハブが管理されず、実行中であるかどうかを確認できません。
# Oracle GoldenGate のセットアップ
Amazon RDS を使用して Oracle GoldenGate をセットアップするには、Amazon EC2 インスタンス上にハブを設定し、ソースデータベースとターゲットデータベースを設定します。以下のセクションは、Amazon RDS for Oracle で使用するために Oracle GoldenGate を設定する方法を示しています。
**Topics**
+ [Amazon EC2 での Oracle GoldenGate ハブのセットアップ](#Appendix.OracleGoldenGate.Hub)
+ [Amazon RDS の Oracle GoldenGate 用の出典データベースのセットアップ](#Appendix.OracleGoldenGate.Source)
+ [Amazon RDS で Oracle GoldenGate 用のターゲットデータベースをセットアップする](#Appendix.OracleGoldenGate.Target)
## Amazon EC2 での Oracle GoldenGate ハブのセットアップ
Amazon EC2 インスタンスに Oracle GoldenGate ハブを作成するには、まず Oracle RDBMS の完全なクライアントインストールで Amazon EC2 インスタンスを作成します。Amazon EC2 インスタンスには、Oracle GoldenGate ソフトウェアもインストールしている必要があります。Oracle GoldenGate ソフトウェアのバージョンは、ソースおよびターゲットのデータベースのバージョンにより決定されます。Oracle GoldenGate のインストールの詳細については、[Oracle GoldenGate のドキュメント](https://docs.oracle.com/en/middleware/goldengate/core/index.html)を参照してください。
Oracle GoldenGate ハブとして機能する Amazon EC2 インスタンスは、ソースデータベースのトランザクション情報をトレイルファイルに保存し、処理します。このプロセスをサポートするには、次の要件を満たしていることを確認してください。
+ トレイルファイル用に十分なストレージを割り当てています。
+ Amazon EC2 インスタンスには、データ量を管理するのに十分な処理能力がある。
+ トレイルファイルに書き込む前に、EC2 インスタンスにトランザクション情報を保存するのに十分なメモリがある。
**Amazon EC2 インスタンスに Oracle GoldenGate クラシックアーキテクチャハブを設定するには**
1. Oracle GoldenGate ディレクトリにサブディレクトリを作成します。
Amazon EC2 コマンドラインシェルで、Oracle GoldenGate コマンドインタープリタ `ggsci` を起動します。`CREATE SUBDIRS` コマンドは、パラメータ、レポート、チェックポイントの各ファイル用の `/gg` ディレクトリの下にサブディレクトリを作成します。
```
prompt$ cd /gg
prompt$ ./ggsci
GGSCI> CREATE SUBDIRS
```
1. `mgr.prm` ファイルを設定します。
次の例では、`$GGHOME/dirprm/mgr.prm` ファイルに行を追加します。
```
PORT 8199
PurgeOldExtracts ./dirdat/*, UseCheckpoints, MINKEEPDAYS 5
```
1. マネージャーを起動します。
次の例では、`ggsci` を起動し、`start mgr` コマンドを実行します。
```
GGSCI> start mgr
```
これで、Oracle GoldenGate ハブを使用する準備ができました。
## Amazon RDS の Oracle GoldenGate 用の出典データベースのセットアップ
Oracle GoldenGate で使用するソースデータベースを設定するには、次のタスクを実行します。
**Topics**
+ [ステップ 1: ソースデータベースでの補足的なログ記録を有効にする](#Appendix.OracleGoldenGate.Source.Logging)
+ [ステップ 2: ENABLE\$1GOLDENGATE\$1REPLICATION 初期化パラメータを true に設定する](#Appendix.OracleGoldenGate.Source.enable-gg-rep)
+ [ステップ 3: ソースデータベースでのログの保持期間を設定する](#Appendix.OracleGoldenGate.Source.Retention)
+ [ステップ 4: ソースデータベースに Oracle GoldenGate ユーザーアカウントを作成する](#Appendix.OracleGoldenGate.Source.Account)
+ [ステップ 5: ソースデータベースでユーザーに特権を付与する](#Appendix.OracleGoldenGate.Source.Privileges)
+ [ステップ 6: ソースデータベースに TNS エイリアスを追加する](#Appendix.OracleGoldenGate.Source.TNS)
### ステップ 1: ソースデータベースでの補足的なログ記録を有効にする
最小限のデータベースレベルの補足的なログ記録を有効にするには、次の PL/SQL プロシージャを実行します。
```
EXEC rdsadmin.rdsadmin_util.alter_supplemental_logging(p_action => 'ADD')
```
### ステップ 2: ENABLE\$1GOLDENGATE\$1REPLICATION 初期化パラメータを true に設定する
`ENABLE_GOLDENGATE_REPLICATION` 初期化パラメータを `true` に設定すると、データベースサービスが論理レプリケーションをサポートできるようになります。ソースデータベースが Amazon RDS DB インスタンスにある場合、`ENABLE_GOLDENGATE_REPLICATION` インストールパラメータを `true` に設定して、DB インスタンスにパラメータグループを割り当てる必要があります。`ENABLE_GOLDENGATE_REPLICATION` の初期化パラメータの詳細については、[Oracle Database のドキュメント](https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/ENABLE_GOLDENGATE_REPLICATION.html)を参照してください。
### ステップ 3: ソースデータベースでのログの保持期間を設定する
アーカイブされた REDO ログを保持するようにソースデータベースを必ず設定してください。以下のガイドラインを検討します。
+ ログの保持期間を時間単位で指定します。最小値は 1 時間です。
+ この期間は、ソース DB インスタンスの潜在的なダウンタイム、潜在的な通信期間、ソースインスタンスのネットワーク問題の潜在的な期間を超えるように設定します。このような期間により、Oracle GoldenGate は必要に応じて出典インスタンスからログを復元できます。
+ ファイル用の十分なストレージがインスタンスにあることを確認します。
例えば、アーカイブ REDO ログの保持期間を 24 時間に設定します。
```
EXEC rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24)
```
ログの保持を有効にしていない場合や、保持の値が小さすぎる場合、次のようなエラーメッセージが表示されます。
```
2022-03-06 06:17:27 ERROR OGG-00446 error 2 (No such file or directory)
opening redo log /rdsdbdata/db/GGTEST3_A/onlinelog/o1_mf_2_9k4bp1n6_.log for sequence 1306
Not able to establish initial position for begin time 2022-03-06 06:16:55.
```
DB インスタンスにはアーカイブされた REDO ログが保持されるため、ファイル用の十分なスペースがあることを確認してください。過去 *num\$1hours* 時間で使用した領域の量を確認するには、*num\$1hours* を時間数に置き換えて、次のクエリを実行します。
```
SELECT SUM(BLOCKS * BLOCK_SIZE) BYTES FROM V$ARCHIVED_LOG
WHERE NEXT_TIME>=SYSDATE-num_hours/24 AND DEST_ID=1;
```
### ステップ 4: ソースデータベースに Oracle GoldenGate ユーザーアカウントを作成する
Oracle GoldenGate はデータベースユーザーとして実行され、出典データベースの REDO ログとアーカイブ REDO ログにアクセスするには、適切なデータベース権限が必要です。これらを指定するには、ソースデータベースにユーザーアカウントを作成します。Oracle GoldenGate のユーザーアカウントに関するアクセス許可の詳細については、[Oracle のドキュメント](https://docs.oracle.com/en/middleware/goldengate/core/19.1/oracle-db/establishing-oracle-goldengate-credentials.html#GUID-79122058-27B0-4FB6-B3DC-B7D1B67EB053)を参照してください。
次のステートメントでは、`oggadm1` という名前のユーザーアカウントが作成されます。
```
CREATE TABLESPACE administrator;
CREATE USER oggadm1 IDENTIFIED BY "password"
DEFAULT TABLESPACE ADMINISTRATOR TEMPORARY TABLESPACE TEMP;
ALTER USER oggadm1 QUOTA UNLIMITED ON administrator;
```
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
### ステップ 5: ソースデータベースでユーザーに特権を付与する
このタスクでは、ソースデータベースでデータベースユーザーに必要なアカウント権限を付与します。
**ソースデータベースでユーザーに特権を付与するには**
1. SQL コマンド `grant` と `rdsadmin.rdsadmin_util` プロシージャ `grant_sys_object` を使用して、Oracle GoldenGate ユーザーアカウントに必要な権限を付与します。次のステートメントでは、`oggadm1` という名前のユーザーに権限が付与されます。
```
GRANT CREATE SESSION, ALTER SESSION TO oggadm1;
GRANT RESOURCE TO oggadm1;
GRANT SELECT ANY DICTIONARY TO oggadm1;
GRANT FLASHBACK ANY TABLE TO oggadm1;
GRANT SELECT ANY TABLE TO oggadm1;
GRANT SELECT_CATALOG_ROLE TO rds_master_user_name WITH ADMIN OPTION;
EXEC rdsadmin.rdsadmin_util.grant_sys_object ('DBA_CLUSTERS', 'OGGADM1');
GRANT EXECUTE ON DBMS_FLASHBACK TO oggadm1;
GRANT SELECT ON SYS.V_$DATABASE TO oggadm1;
GRANT ALTER ANY TABLE TO oggadm1;
```
1. Oracle GoldenGate 管理者になるためにユーザーアカウントに必要な権限を付与します。以下の PL/SQL プログラムを実行します。
```
EXEC rdsadmin.rdsadmin_dbms_goldengate_auth.grant_admin_privilege (
grantee => 'OGGADM1',
privilege_type => 'capture',
grant_select_privileges => true,
do_grants => TRUE);
```
権限を取り消すには、同じパッケージのプロシージャ `revoke_admin_privilege` を使用します。
### ステップ 6: ソースデータベースに TNS エイリアスを追加する
`$ORACLE_HOME/network/admin/tnsnames.ora` プロセスで使用する Oracle Home で、次のエントリを `EXTRACT` に追加します。`tnsnames.ora` ファイルの詳細については、[Oracle のドキュメント](https://docs.oracle.com/en/database/oracle/oracle-database/19/netrf/local-naming-parameters-in-tns-ora-file.html#GUID-7F967CE5-5498-427C-9390-4A5C6767ADAA)を参照してください。
```
OGGSOURCE=
(DESCRIPTION=
(ENABLE=BROKEN)
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCP)(HOST=goldengate-source.abcdef12345.us-west-2.rds.amazonaws.com)(PORT=8200)))
(CONNECT_DATA=(SERVICE_NAME=ORCL))
)
```
## Amazon RDS で Oracle GoldenGate 用のターゲットデータベースをセットアップする
このタスクでは、Oracle GoldenGate で使用するターゲット DB インスタンスを設定します。
**Topics**
+ [ステップ 1: ENABLE\$1GOLDENGATE\$1REPLICATION 初期化パラメータを true に設定する](#Appendix.OracleGoldenGate.Target.enable-gg-rep)
+ [ステップ 2: ターゲットデータベースで GoldenGate のユーザーアカウントを作成する](#Appendix.OracleGoldenGate.Target.User)
+ [ステップ 3: ターゲットデータベースでアカウント権限を付与する](#Appendix.OracleGoldenGate.Target.Privileges)
+ [ステップ 4: ターゲットデータベースに TNS エイリアスを追加する](#Appendix.OracleGoldenGate.Target.TNS)
### ステップ 1: ENABLE\$1GOLDENGATE\$1REPLICATION 初期化パラメータを true に設定する
`ENABLE_GOLDENGATE_REPLICATION` 初期化パラメータを `true` に設定すると、データベースサービスが論理レプリケーションをサポートできるようになります。ソースデータベースが Amazon RDS DB インスタンスにある場合、`ENABLE_GOLDENGATE_REPLICATION` インストールパラメータを `true` に設定して、DB インスタンスにパラメータグループを割り当てる必要があります。`ENABLE_GOLDENGATE_REPLICATION` の初期化パラメータの詳細については、[Oracle Database のドキュメント](https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/ENABLE_GOLDENGATE_REPLICATION.html)を参照してください。
### ステップ 2: ターゲットデータベースで GoldenGate のユーザーアカウントを作成する
Oracle GoldenGate はデータベースユーザーとして動作し、適切なデータベース権限が必要です。これらの権限があることを確認するには、ターゲットデータベースにユーザーアカウントを作成します。
次のステートメントでは、`oggadm1` という名前のユーザーを作成します。
```
CREATE TABLESPSACE administrator;
CREATE USER oggadm1 IDENTIFIED BY "password"
DEFAULT TABLESPACE administrator
TEMPORARY TABLESPACE temp;
ALTER USER oggadm1 QUOTA UNLIMITED ON administrator;
```
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
### ステップ 3: ターゲットデータベースでアカウント権限を付与する
このタスクでは、ターゲットデータベースでデータベースユーザーに必要なアカウント権限を付与します。
**ターゲットデータベースでユーザーに特権を付与するには**
1. ターゲットデータベースの Oracle GoldenGate ユーザーアカウントに必要な権限を付与します。次の例では、`oggadm1` に権限を付与します。
```
GRANT CREATE SESSION TO oggadm1;
GRANT ALTER SESSION TO oggadm1;
GRANT CREATE CLUSTER TO oggadm1;
GRANT CREATE INDEXTYPE TO oggadm1;
GRANT CREATE OPERATOR TO oggadm1;
GRANT CREATE PROCEDURE TO oggadm1;
GRANT CREATE SEQUENCE TO oggadm1;
GRANT CREATE TABLE TO oggadm1;
GRANT CREATE TRIGGER TO oggadm1;
GRANT CREATE TYPE TO oggadm1;
GRANT SELECT ANY DICTIONARY TO oggadm1;
GRANT CREATE ANY TABLE TO oggadm1;
GRANT ALTER ANY TABLE TO oggadm1;
GRANT LOCK ANY TABLE TO oggadm1;
GRANT SELECT ANY TABLE TO oggadm1;
GRANT INSERT ANY TABLE TO oggadm1;
GRANT UPDATE ANY TABLE TO oggadm1;
GRANT DELETE ANY TABLE TO oggadm1;
```
1. Oracle GoldenGate 管理者になるためにユーザーアカウントに必要な権限を付与します。以下の PL/SQL プログラムを実行します。
```
EXEC rdsadmin.rdsadmin_dbms_goldengate_auth.grant_admin_privilege (
grantee => 'OGGADM1',
privilege_type => 'apply',
grant_select_privileges => true,
do_grants => TRUE);
```
権限を取り消すには、同じパッケージのプロシージャ `revoke_admin_privilege` を使用します。
### ステップ 4: ターゲットデータベースに TNS エイリアスを追加する
`$ORACLE_HOME/network/admin/tnsnames.ora` プロセスで使用する Oracle Home で、次のエントリを `REPLICAT` に追加します。Oracle マルチテナントデータベースの場合、TNS エイリアスが PDB のサービス名を指していることを確認してください。`tnsnames.ora` ファイルの詳細については、[Oracle のドキュメント](https://docs.oracle.com/en/database/oracle/oracle-database/19/netrf/local-naming-parameters-in-tns-ora-file.html#GUID-7F967CE5-5498-427C-9390-4A5C6767ADAA)を参照してください。
```
OGGTARGET=
(DESCRIPTION=
(ENABLE=BROKEN)
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCP)(HOST=goldengate-target.abcdef12345.us-west-2.rds.amazonaws.com)(PORT=8200)))
(CONNECT_DATA=(SERVICE_NAME=ORCL))
)
```
# Oracle GoldenGate の EXTRACT ユーティリティと REPLICAT ユーティリティを使用する
Oracle GoldenGate のユーティリティである `EXTRACT` と `REPLICAT` は連携して動作し、トレイルファイルを使った増分トランザクションのレプリケーションを利用して、出典データベースとターゲットデータベースの同期を維持します。ソースデータベースで行われたすべての変更は `EXTRACT` によって自動的に検出され、その後整形されて、オンプレミスの Oracle GoldenGate または Amazon EC2 インスタンスハブ上のトレイルファイルに転送されます。トレイルファイルの初回の読み取りが完了すると、`REPLICAT` ユーティリティによってデータがこれらのファイルから読み取られ、ターゲットデータベースにレプリケートされます。
## Oracle GoldenGate の EXTRACT ユーティリティの実行
`EXTRACT` ユーティリティは、ソースデータベースのデータを取得し、変換して、トレイルファイルに出力します。基本的なプロセスは、次のとおりです。
1. `EXTRACT` は、トランザクションの詳細をメモリまたは一時ディスクストレージ上のキューに入れます。
1. ソースデータベースがトランザクションをコミットします。
1. `EXTRACT` は、トランザクションの詳細をトレイルファイルに書き込みます。
1. トレイルファイルは、これらの詳細を Oracle GoldenGate オンプレミスまたは Amazon EC2 インスタンスハブにルーティングしてから、ターゲットデータベースにルーティングします。
次の手順では、`EXTRACT` ユーティリティを起動し、ソースデータベース `OGGSOURCE` で `EXAMPLE.TABLE` からデータをキャプチャして、トレイルファイルを作成します。
**EXTRACT ユーティリティを実行するには**
1. Oracle GoldenGate ハブ (オンプレミスまたは Amazon EC2 インスタンス) にある `EXTRACT` パラメータファイルを設定します。`$GGHOME/dirprm/eabc.prm` という名前のサンプルの `EXTRACT` パラメータファイルを次に示します。
```
EXTRACT EABC
USERID oggadm1@OGGSOURCE, PASSWORD "my-password"
EXTTRAIL /path/to/goldengate/dirdat/ab
IGNOREREPLICATES
GETAPPLOPS
TRANLOGOPTIONS EXCLUDEUSER OGGADM1
TABLE EXAMPLE.TABLE;
```
1. Oracle GoldenGate ハブで、ソースデータベースにログインし、Oracle GoldenGate コマンドラインインターフェイス `ggsci` を起動します。次の例は、ログインの形式を示しています。
```
dblogin oggadm1@OGGSOURCE
```
1. トランザクションデータを追加して、データベーステーブルの補足的なログ記録を有効にします。
```
add trandata EXAMPLE.TABLE
```
1. `ggsci` コマンドラインを使用する場合、次のコマンドを使用して、`EXTRACT` ユーティリティを有効にします。
```
add extract EABC tranlog, INTEGRATED tranlog, begin now
add exttrail /path/to/goldengate/dirdat/ab
extract EABC,
MEGABYTES 100
```
1. アーカイブログが削除されないように、データベースに `EXTRACT` ユーティリティを登録します。このタスクにより、以前のコミットされていないトランザクションを必要に応じて復旧できます。データベースに `EXTRACT` ユーティリティを登録するには、次のコマンドを使用します。
```
register EXTRACT EABC, DATABASE
```
1. 次のコマンドを使用して `EXTRACT` ユーティリティを起動します。
```
start EABC
```
## Oracle GoldenGate の REPLICAT ユーティリティの実行
`REPLICAT` ユーティリティは、トレイルファイルのトランザクション情報をターゲットデータベースに「プッシュ」します。
次のステップでは、`REPLICAT` ユーティリティを有効にして起動し、キャプチャしたデータをターゲットデータベース `OGGTARGET` のテーブル `EXAMPLE.TABLE` にレプリケートできるようにします。
**REPLICATE ユーティリティを実行するには**
1. Oracle GoldenGate ハブ (オンプレミスまたは EC2 インスタンス) にある `REPLICAT` パラメータファイルを設定します。`$GGHOME/dirprm/rabc.prm` という名前のサンプルの `REPLICAT` パラメータファイルを次に示します。
```
REPLICAT RABC
USERID oggadm1@OGGTARGET, password "my-password"
ASSUMETARGETDEFS
MAP EXAMPLE.TABLE, TARGET EXAMPLE.TABLE;
```
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
1. ターゲットデータベースにログインし、Oracle GoldenGate コマンドラインインターフェイス (`ggsci`) を起動します。次の例は、ログインの形式を示しています。
```
dblogin userid oggadm1@OGGTARGET
```
1. `ggsci` コマンドラインを使用して、チェックポイントテーブルを追加します。ここで指定するユーザーは、ターゲットテーブルスキーマの所有者ではなく、Oracle GoldenGate のユーザーアカウントであることが必要です。次の例では、`gg_checkpoint` という名前のチェックポイントテーブルを作成します。
```
add checkpointtable oggadm1.oggchkpt
```
1. `REPLICAT` ユーティリティを有効にするには、次のコマンドを使用します。
```
add replicat RABC EXTTRAIL /path/to/goldengate/dirdat/ab CHECKPOINTTABLE oggadm1.oggchkpt
```
1. 次のコマンドを使用して、`REPLICAT` ユーティリティを起動します。
```
start RABC
```
# Oracle GoldenGate のモニタリング
Oracle GoldenGate をレプリケーションに使用する場合は、Oracle GoldenGate プロセスが稼働していて、ソースデータベースとターゲットデータベースが同期していることを確認してください。次のモニタリングツールを使用できます。
+ [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、このようなパターンで GoldenGate エラーログをモニタリングするために使用されるモニタリングサービスです。
+ [Amazon SNS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html) は、このようなパターンでメール通知を送信するために使用されるメッセージ通知サービスです。
詳細な説明については、「[Monitor Oracle GoldenGate logs by using Amazon CloudWatch](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/monitor-oracle-goldengate-logs-by-using-amazon-cloudwatch.html)」(Amazon CloudWatch を使用して Oracle GoldenGate ログをモニタリングする) を参照してください。
# Oracle GoldenGate のトラブルシューティング
このセクションでは、Amazon RDS for Oracle で Oracle GoldenGate を使用する場合に発生する最も一般的な問題について説明します。
**Topics**
+ [オンライン REDO ログを開くときにエラーが発生しました](#Appendix.OracleGoldenGate.Troubleshooting.Logs)
+ [Oracle GoldenGate は適切に設定されているようだが、レプリケーションが機能していない](#Appendix.OracleGoldenGate.Troubleshooting.Replication)
+ [SYS."\$1DBA\$1APPLY\$1CDR\$1INFO" に対するクエリが原因で、統合 REPLICAT が遅い](#Appendix.OracleGoldenGate.IR)
## オンライン REDO ログを開くときにエラーが発生しました
アーカイブされた REDO ログを保持するようにデータベースを設定していることを確認してください。以下のガイドラインを検討します。
+ ログの保持期間を時間単位で指定します。最小値は 1 時間です。
+ この期間は、ソースインスタンスの潜在的なダウンタイム、潜在的な通信期間、ソースインスタンスのネットワーク問題の潜在的な期間を超えるように設定します。このような期間により、Oracle GoldenGate は必要に応じてソース DB インスタンスからログを復元できます。
+ ファイル用の十分なストレージがインスタンスにあることを確認します。
ログの保持を有効にしていない場合や、保持の値が小さすぎる場合、次のようなエラーメッセージが表示されます。
```
2022-03-06 06:17:27 ERROR OGG-00446 error 2 (No such file or directory)
opening redo log /rdsdbdata/db/GGTEST3_A/onlinelog/o1_mf_2_9k4bp1n6_.log for sequence 1306
Not able to establish initial position for begin time 2022-03-06 06:16:55.
```
## Oracle GoldenGate は適切に設定されているようだが、レプリケーションが機能していない
既存のテーブルについては、Oracle GoldenGate の動作元の SCN を指定する必要があります。
**この問題を修正するには**
1. ソースデータベースにログインし、Oracle GoldenGate コマンドラインインターフェイス (`ggsci`) を起動します。次の例は、ログインの形式を示しています。
```
dblogin userid oggadm1@OGGSOURCE
```
1. `ggsci` コマンドラインを使用して、`EXTRACT` プロセスのスタート SCN を設定します。次の例では、`EXTRACT` の SCN を 223274 に設定しています。
```
ALTER EXTRACT EABC SCN 223274
start EABC
```
1. ターゲットデータベースにログインします。次の例は、ログインの形式を示しています。
```
dblogin userid oggadm1@OGGTARGET
```
1. `ggsci` コマンドラインを使用して、`REPLICAT` プロセスのスタート SCN を設定します。次の例では、`REPLICAT` の SCN を 223274 に設定しています。
```
start RABC atcsn 223274
```
## SYS."\$1DBA\$1APPLY\$1CDR\$1INFO" に対するクエリが原因で、統合 REPLICAT が遅い
Oracle GoldenGate 競合の検出および解決 (CDR) には、ベーシックな競合の解決ルーチンが用意されています。例えば、CDR は、`INSERT` ステートメントの一意の競合を解決できます。
CDR が衝突を解決すると、一時的に例外テーブル `_DBA_APPLY_CDR_INFO` にレコードを挿入できます。Integrated `REPLICAT` はこれらのレコードを後で削除します。まれなシナリオでは、統合 `REPLICAT` は多数の衝突を処理できますが、新しい統合 `REPLICAT` では置き換えられません。`_DBA_APPLY_CDR_INFO` の既存の行は、削除されるのではなく、孤立します。任意の新しい統合 `REPLICAT` プロセスは、`_DBA_APPLY_CDR_INFO` で孤立した行をクエリするため、処理速度が低下します。
`_DBA_APPLY_CDR_INFO` からすべての行を削除するには、Amazon RDS の手順 `rdsadmin.rdsadmin_util.truncate_apply$_cdr_info` を使用します。この手順は、2020 年 10 月のリリースおよびパッチアップデートの一部としてリリースされます。この手順は、次のデータベースバージョンで使用できます。
+ [ バージョン 21.0.0.0.ru-2022-01.rur-2022-01.r1](https://docs.aws.amazon.com/AmazonRDS/latest/OracleReleaseNotes/oracle-version-21-0.html#oracle-version-RU-RUR.21.0.0.0.ru-2022-01.rur-2022-01.r1) 以上
+ [ バージョン 19.0.0.0.ru-2020-10.rur-2020-10.r1](https://docs.aws.amazon.com/AmazonRDS/latest/OracleReleaseNotes/oracle-version-19-0.html#oracle-version-RU-RUR.19.0.0.0.ru-2020-10.rur-2020-10.r1) 以降
次の例では、テーブル `_DBA_APPLY_CDR_INFO` を切り捨てます。
```
SET SERVEROUTPUT ON SIZE 2000
EXEC rdsadmin.rdsadmin_util.truncate_apply$_cdr_info;
```
# Amazon RDS for Oracle での Oracle リポジトリ作成ユーティリティの使用
Amazon RDS を使用すると、Oracle Fusion Middleware コンポーネントをサポートするスキーマを保持する RDS for Oracle DB インスタンスをホストできます。Fusion Middleware コンポーネントを使用する前に、データベースでそれらのコンポーネント用のスキーマを作成してデータを入力します。スキーマの作成とデータ入力は、Oracle Repository Creation Utility (RCU) を使用して行います。
## RCU でサポートされているバージョンとライセンスオプション
Amazon RDS では、Oracle Repository Creation Utility (RCU) バージョン 12c のみサポートされています。RCU は以下の構成で使用できます。
+ Oracle データベース 21c を使用する RCU 12c
+ Oracle データベース 19c を使用する RCU 12c
RCU を使用する前に、以下を実行します。
+ Oracle Fusion Midleware のライセンスを取得する。
+ リポジトリをホストする Oracle データベースの Oracle ライセンスガイドラインに従う。詳細については、Oracle ドキュメントの「[Oracle Fusion Middleware Licensing Information User Manual](https://docs.oracle.com/en/middleware/fusion-middleware/fmwlc/)」を参照してください。
Fusion MiddleWare は、Oracle Database Enterprise Edition および Standard Edition 2 上のリポジトリをサポートしています。Oracle では、オンラインインデックスの再構築を必要とするパーティション化とインストールが必要な本稼働インストールには、Enterprise Edition を推奨しています。
RDS for Oracle DB インスタンスを作成する前に、デプロイするコンポーネントをサポートするために必要な Oracle データベースバージョンを確認します。デプロイする Fusion Middleware コンポーネントおよびバージョンの要件を確認するには、認定マトリックスを使用します。詳細については、Oracle ドキュメントの「[Oracle Fusion Middleware Supported System Configurations](http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html)」を参照してください。
Amazon RDS では、必要に応じて Oracle データベースバージョンのアップグレードがサポートされます。詳細については、「[DB インスタンスのエンジンバージョンのアップグレード](USER_UpgradeDBInstance.Upgrading.md)」を参照してください。
## RCU の要件と制限
RCU を使用するには、Amazon VPC が必要です。Amazon RDS DB インスタンスは、パブリックインターネットではなく、Fusion Middleware コンポーネントでのみ使用できるようにします。そのため、Amazon RDS DB インスタンスをプライベートサブネットでホストして、セキュリティを強化します。RDS for Oracle DB インスタンスも必要です。詳細については、「[Oracle DB インスタンスを作成して接続する](CHAP_GettingStarted.CreatingConnecting.Oracle.md)」を参照してください。
どの Fusion Middleware コンポーネントのスキーマでも Amazon RDS DB インスタンスに保存できます。次のスキーマは、正しくインストールされることが検証されています。
+ Analytics (ACTIVITIES)
+ Audit Services (IAU)
+ Audit Services Append (IAU\$1APPEND)
+ Audit Services Viewer (IAU\$1VIEWER)
+ Discussions (DISCUSSIONS)
+ Metadata Services (MDS)
+ Oracle Business Intelligence (BIPLATFORM)
+ Oracle Platform Security Services (OPSS)
+ Portal and Services (WEBCENTER)
+ Portlet Producers (PORTLET)
+ Service Table (STB)
+ SOA Infrastructure (SOAINFRA)
+ User Messaging Service (UCSUMS)
+ WebLogic Services (WLS)
## RCU を使用するガイドライン
このシナリオで DB インスタンスを使用する場合の推奨事項を以下に示します。
+ マルチ AZ は、本稼働ワークロードに使用することをお勧めします。複数のアベイラビリティーゾーンの使用の詳細については、「[リージョン、アベイラビリティーゾーン、および Local Zones](Concepts.RegionsAndAvailabilityZones.md)」を参照してください。
+ セキュリティを高めるため、Oracle では、Transparent Data Encryption (TDE) を使用して保管時のデータを暗号化することを推奨しています。高度なセキュリティオプションを含む Enterprise Edition のライセンスをお持ちの場合、TDE オプションを使用して保管時の暗号化を有効にできます。詳細については、「[Oracle Transparent Data Encryption](Appendix.Oracle.Options.AdvSecurity.md)」を参照してください。
Amazon RDS では、すべてのデータベースエディション用の保管時の暗号化オプションも用意しています。詳細については、「[Amazon RDS リソースの暗号化](Overview.Encryption.md)」を参照してください。
+ アプリケーションサーバーと Amazon RDS DB インスタンスの間の通信が許可されるように、VPC セキュリティグループを設定します。Fusion Middleware コンポーネントをホストするアプリケーションサーバーは、Amazon EC2 またはオンプレミスにすることができます。
## RCU の実行
Fusion Middleware コンポーネントをサポートするためのスキーマを作成し、データを入力するには、Oracle Repository Creation Utility (RCU) を使用します。RCU は、さまざまな方法で実行できます。
**Topics**
+ [コマンドラインを使用した 1 ステップでの RCU の実行](#Oracle.Resources.RCU.SilentSingle)
+ [コマンドラインを使用した複数ステップでの RCU の実行](#Oracle.Resources.RCU.SilentMulti)
+ [インタラクティブモードでの RCU の実行](#Oracle.Resources.RCU.Interactive)
### コマンドラインを使用した 1 ステップでの RCU の実行
データを入力する前にスキーマを編集する必要がない場合は、単一ステップで RCU を実行できます。それ以外の場合、複数ステップでの RCU の実行について次のセクションを参照してください。
コマンドラインパラメータ `-silent` を使用して、RCU をサイレントモードで実行できます。サイレントモードで RCU を実行すると、パスワードを含むテキストファイルを作成することで、コマンドラインにパスワードを入力する必要がなくなります。1 行目に `dbUser` のパスワードを含み、それ以降の行に各コンポーネントのパスワードを含むテキストファイルを作成します。RCU コマンドの最後のパラメータとして、パスワードファイルの名前を指定します。
**Example**
次の例では、SOA Infrastructure コンポーネント (およびその依存関係) のスキーマを単一ステップで作成し、データを入力します。
Linux、macOS、Unix の場合:
```
export ORACLE_HOME=/u01/app/oracle/product/12.2.1.0/fmw
export JAVA_HOME=/usr/java/jdk1.8.0_65
${ORACLE_HOME}/oracle_common/bin/rcu \
-silent \
-createRepository \
-connectString ${dbhost}:${dbport}:${dbname} \
-dbUser ${dbuser} \
-dbRole Normal \
-honorOMF \
-schemaPrefix ${SCHEMA_PREFIX} \
-component MDS \
-component STB \
-component OPSS \
-component IAU \
-component IAU_APPEND \
-component IAU_VIEWER \
-component UCSUMS \
-component WLS \
-component SOAINFRA \
-f < /tmp/passwordfile.txt
```
詳細については、Oracle ドキュメントの「[Running Repository Creation Utility from the Command Line](https://docs.oracle.com/middleware/1221/core/RCUUG/GUID-0D3A2959-7CC8-4001-997E-718ADF04C5F2.htm#RCUUG248)」を参照してください。
### コマンドラインを使用した複数ステップでの RCU の実行
スキーマスクリプトを手動で編集するには、次の複数のステップで RCU を実行します。
1. `-generateScript` コマンドラインパラメータを使用して [**Prepare Scripts for System Load**] モードで RCU を実行し、スキーマのスクリプトを作成します。
1. 手動で編集し、生成したスクリプト `script_systemLoad.sql` を実行します。
1. `-dataLoad` コマンドラインパラメータを使用して [**Perform Product Load**] モードでもう一度 RCU を実行し、スキーマにデータを入力します。
1. 生成したクリーンアップのスクリプト `script_postDataLoad.sql` を実行します。
RCU をサイレントモードで実行するには、コマンドラインパラメータ `-silent` を指定します。サイレントモードで RCU を実行すると、パスワードを含むテキストファイルを作成することで、コマンドラインにパスワードを入力する必要がなくなります。1 行目に `dbUser` のパスワードを含み、それ以降の行に各コンポーネントのパスワードを含むテキストファイルを作成します。RCU コマンドの最後のパラメータとして、パスワードファイルの名前を指定します。
**Example**
次の例では、SOA Infrastructure コンポーネントおよびその依存関係のスキーマスクリプトを作成します。
Linux、macOS、Unix の場合:
```
export ORACLE_HOME=/u01/app/oracle/product/12.2.1.0/fmw
export JAVA_HOME=/usr/java/jdk1.8.0_65
${ORACLE_HOME}/oracle_common/bin/rcu \
-silent \
-generateScript \
-connectString ${dbhost}:${dbport}:${dbname} \
-dbUser ${dbuser} \
-dbRole Normal \
-honorOMF \
[-encryptTablespace true] \
-schemaPrefix ${SCHEMA_PREFIX} \
-component MDS \
-component STB \
-component OPSS \
-component IAU \
-component IAU_APPEND \
-component IAU_VIEWER \
-component UCSUMS \
-component WLS \
-component SOAINFRA \
-scriptLocation /tmp/rcuscripts \
-f < /tmp/passwordfile.txt
```
ここでは、生成されたスクリプトを編集し、Oracle DB インスタンスに接続してスクリプトを実行できます。生成したスクリプトの名前は、`script_systemLoad.sql` です。Oracle DB インスタンスへの接続の詳細については、「[ステップ 3: SQL クライアントを Oracle DB インスタンスに接続する](CHAP_GettingStarted.CreatingConnecting.Oracle.md#CHAP_GettingStarted.Connecting.Oracle)」を参照してください。
次の例では、SOA Infrastructure コンポーネント (およびその依存関係) のスキーマにデータを入力します。
Linux、macOS、Unix の場合:
```
export JAVA_HOME=/usr/java/jdk1.8.0_65
${ORACLE_HOME}/oracle_common/bin/rcu \
-silent \
-dataLoad \
-connectString ${dbhost}:${dbport}:${dbname} \
-dbUser ${dbuser} \
-dbRole Normal \
-honorOMF \
-schemaPrefix ${SCHEMA_PREFIX} \
-component MDS \
-component STB \
-component OPSS \
-component IAU \
-component IAU_APPEND \
-component IAU_VIEWER \
-component UCSUMS \
-component WLS \
-component SOAINFRA \
-f < /tmp/passwordfile.txt
```
終了するには、Oracle DB インスタンスに接続し、クリーンアップスクリプトを実行します。生成したスクリプトの名前は、`script_postDataLoad.sql` です。
詳細については、Oracle ドキュメントの「[Running Repository Creation Utility from the Command Line](https://docs.oracle.com/middleware/1221/core/RCUUG/GUID-0D3A2959-7CC8-4001-997E-718ADF04C5F2.htm#RCUUG248)」を参照してください。
### インタラクティブモードでの RCU の実行
RCU グラフィカルユーザーインターフェイスを使用するには、インタラクティブモードで RCU を実行します。`-interactive` パラメータを指定し、`-silent` パラメータは指定しません。詳細については、Oracle ドキュメントの「[Understanding Repository Creation Utility Screens](https://docs.oracle.com/middleware/1213/core/RCUUG/rcu_screens.htm#RCUUG143)」を参照してください。
**Example**
次の例では、RCU をインタラクティブモードで起動し、接続情報を事前入力します。
Linux、macOS、Unix の場合:
```
export ORACLE_HOME=/u01/app/oracle/product/12.2.1.0/fmw
export JAVA_HOME=/usr/java/jdk1.8.0_65
${ORACLE_HOME}/oracle_common/bin/rcu \
-interactive \
-createRepository \
-connectString ${dbhost}:${dbport}:${dbname} \
-dbUser ${dbuser} \
-dbRole Normal
```
## RCU のトラブルシューティング
次の点に注意してください。
**Topics**
+ [Oracle Managed Files (OMF)](#Oracle.Resources.RCU.KnownIssues.OMF)
+ [オブジェクト権限](#Oracle.Resources.RCU.KnownIssues.object-privs)
+ [Enterprise Scheduler Service](#Oracle.Resources.RCU.KnownIssues.Scheduler)
### Oracle Managed Files (OMF)
Amazon RDS は、OMF データファイルを使用してストレージ管理を簡素化します。サイズや拡張管理などのテーブルスペース属性をカスタマイズできます。ただし、RCU の実行時にデータファイル名を指定すると、テーブルスペースコードが `ORA-20900` で失敗します。RCU は、以下の方法で OMF と使用できます。
+ RCU 12.2.1.0 以降で、`-honorOMF` コマンドラインパラメータを使用します。
+ RCU 12.1.0.3 以降で、複数のステップを使用して生成されたスクリプトを編集します。詳細については、「[コマンドラインを使用した複数ステップでの RCU の実行](#Oracle.Resources.RCU.SilentMulti)」を参照してください。
### オブジェクト権限
Amazon RDS はマネージ型サービスであるため、RDS for Oracle DB インスタンスへのフル `SYSDBA` アクセス権はありません。ただし、RCU 12c では低い権限のユーザーがサポートされます。ほとんどの場合、リポジトリを作成するにはマスターユーザー権限で十分です。
マスターアカウントは、`WITH GRANT OPTION` がすでに付与されている権限を直接付与できます。場合によっては、`SYS` オブジェクト権限を付与しようとすると RCU が `ORA-01031` で失敗することがあります。次の例に示すように、`rdsadmin_util.grant_sys_object` ストアドプロシージャを再試行して実行することができます。
```
BEGIN
rdsadmin.rdsadmin_util.grant_sys_object('GV_$SESSION','MY_DBA','SELECT');
END;
/
```
オブジェクト `SCHEMA_VERSION_REGISTRY` に対する `SYS` 権限を付与しようとすると、このオペレーションが `ORA-20199: Error in rdsadmin_util.grant_sys_object` で失敗することがあります。テーブル `SCHEMA_VERSION_REGISTRY$` とビュー `SCHEMA_VERSION_REGISTRY` をスキーマ所有者の名前 (`SYSTEM`) で修飾して、オペレーションを再試行できます。または、シノニムを作成することもできます。マスターユーザーとしてログインし、次のステートメントを実行します。
```
CREATE OR REPLACE VIEW SYSTEM.SCHEMA_VERSION_REGISTRY
AS SELECT * FROM SYSTEM.SCHEMA_VERSION_REGISTRY$;
CREATE OR REPLACE PUBLIC SYNONYM SCHEMA_VERSION_REGISTRY FOR SYSTEM.SCHEMA_VERSION_REGISTRY;
CREATE OR REPLACE PUBLIC SYNONYM SCHEMA_VERSION_REGISTRY$ FOR SCHEMA_VERSION_REGISTRY;
```
### Enterprise Scheduler Service
RCU を使用して Enterprise Scheduler Service リポジトリを中断すると、RCU が `Error: Component drop check failed` で失敗することがあります。
# Amazon EC2 インスタンスでの Oracle Connection Manager の設定
Oracle Connection Manager (CMAN) は、データベースサーバーまたは他のプロキシサーバーに接続リクエストを転送するプロキシサーバーです。CMAN 使用して、次を設定できます。
アクセスコントロール
ユーザーが指定したクライアントリクエストを除外し、他のクライアントリクエストを受け入れるルールを作成できます。
セッションの多重化
共有サーバーの宛先へのネットワーク接続を介して、複数のクライアントセッションをファネルできます。
通常、CMAN は、データベースサーバーおよびクライアントホストとは別のホストに存在します。詳細については、「Oracle Database ドキュメント」の「[Configuring Oracle Connection Manager](https://docs.oracle.com/en/database/oracle/oracle-database/19/netag/configuring-oracle-connection-manager.html#GUID-AF8A511E-9AE6-4F4D-8E58-F28BC53F64E4)」(Oracle Connection Manager の構成) を参照してください。
**Topics**
+ [CMAN でサポートされているバージョンとライセンスオプション](#oracle-cman.Versions)
+ [CMAN における要件と制限](#oracle-cman.requirements)
+ [CMAN の設定](#oracle-cman.configuring-cman)
## CMAN でサポートされているバージョンとライセンスオプション
CMAN は、Amazon RDS がサポートする Oracle Database のすべてのバージョンのエンタープライズエディションをサポートしています。詳細については、「[RDS for Oracle のリリース](Oracle.Concepts.database-versions.md)」を参照してください。
Oracle Database がインストールされているホストとは別のホストに Oracle Connection Manager をインストールできます。CMAN を実行するホスト用に別のライセンスは必要ありません。
## CMAN における要件と制限
Amazon RDS では、フルマネージドエクスペリエンスを提供するため、オペレーティングシステムへのアクセスを制限しています。オペレーティングシステムのアクセスを必要とするデータベースパラメータは変更できません。そのため Amazon RDS では、オペレーティングシステムへのログインを必要とする CMAN の機能をサポートしていません。
## CMAN の設定
CMAN を設定する際は、RDS for Oracle データベースの外部でほとんどの作業を実行します。
**Topics**
+ [ステップ 1: RDS for Oracle インスタンスと同じ VPC の Amazon EC2 インスタンスに CMAN を設定する](#oracle-cman.configuring-cman.vpc)
+ [ステップ 2: CMAN のデータベースパラメータを設定する](#oracle-cman.configuring-cman.parameters)
+ [ステップ 3: DB インスタンスを DB パラメータグループに関連付ける](#oracle-cman.configuring-cman.parameter-group)
### ステップ 1: RDS for Oracle インスタンスと同じ VPC の Amazon EC2 インスタンスに CMAN を設定する
CMAN の設定方法については、ブログ記事「[Configuring and using Oracle Connection Manager on Amazon EC2 for Amazon RDS for Oracle](https://aws.amazon.com/blogs/database/configuring-and-using-oracle-connection-manager-on-amazon-ec2-for-amazon-rds-for-oracle/)」(Amazon RDS for Oracle 用に Amazon EC2 で Oracle Connection Manager を設定および使用する) の詳細な手順に従ってください。
### ステップ 2: CMAN のデータベースパラメータを設定する
Traffic Director Mode やセッションの多重化などの CMAN の機能については、`REMOTE_LISTENER` パラメータをDB パラメータグループ内の CMAN のインスタンスのアドレスに設定します。次のシナリオを考えてみます。
+ CMAN のインスタンスが、IP アドレス `10.0.159.100` を持つホストに存在しており、ポート `1521` を使用しているとします。
+ データベース `orcla`、`orclb`、および `orclc` は、Oracle DB インスタンスの別の RDS に存在しているとします。
次の表は、`REMOTE_LISTENER` 値の設定方法を示しています。`LOCAL_LISTENER` 値は、Amazon RDS によって自動的に設定されます。
| DB インスタンス名 | DB インスタンス IP | ローカルリスナーの値 (自動的に設定) | リモートリスナーの値 (ユーザーが設定) |
| --- | --- | --- | --- |
| orcla | 10.0.159.200 | ( address=
(protocol=tcp)
(host=10.0.159.200)
(port=1521)
)
| 10.0.159.100:1521 |
| orclb | 10.0.159.300 | ( address=
(protocol=tcp)
(host=10.0.159.300)
(port=1521)
)
| 10.0.159.100:1521 |
| orclc | 10.0.159.400 | ( address=
(protocol=tcp)
(host=10.0.159.400)
(port=1521)
)
| 10.0.159.100:1521 |
### ステップ 3: DB インスタンスを DB パラメータグループに関連付ける
[ステップ 2: CMAN のデータベースパラメータを設定する](#oracle-cman.configuring-cman.parameters) で設定したパラメータグループを使用するように DB インスタンスを作成または変更します。詳細については、「[Amazon RDS で DB パラメータグループを DB インスタンスに関連付ける](USER_WorkingWithParamGroups.Associating.md)」を参照してください。
# Amazon RDS での Oracle への Siebel Database のインストール
Amazon RDS を使用して Oracle DB インスタンスで Siebel Database をホストできます。Siebel Database は Siebel Customer Relationship Management (CRM) アプリケーションアーキテクチャの一部です。図については、「[ Generic Architecture of Siebel Business Application](https://docs.oracle.com/cd/E63029_01/books/PerformTun/performtun_archinfra.htm#i1043361)」を参照してください。
次のトピックでは、Amazon RDS の Oracle DB インスタンスで Siebel Database をセットアップする方法について説明します。また、Amazon Web Services を使用して Siebel CRM アプリケーションアーキテクチャに必要なそのほかのコンポーネントをサポートする方法も説明します。
**注記**
Amazon RDS 上の Oracle に Siebel Database をインストールするには、マスターユーザーアカウントを使用する必要があります。`SYSDBA` 権限は必要ありません。マスターユーザー権限で十分です。詳細については、「[マスターユーザーアカウント権限](UsingWithRDS.MasterAccounts.md)」を参照してください。
## ライセンスとバージョン
Siebel Database を Amazon RDS にインストールするには、お客様ご自身の Oracle Database ライセンスと Siebel ライセンスを使用する必要があります。DB インスタンスクラスと Oracle Database のエディション用の適切な Oracle Database ライセンス (ソフトウェア更新ライセンスおよびサポート) を所持している必要があります。詳細については、「[RDS for Oracle のライセンスオプション](Oracle.Concepts.Licensing.md)」を参照してください。
Oracle Database Enterprise Edition は、このシナリオで唯一の Siebel 認定エディションです。Amazon RDS では、Siebel CRM バージョン 15.0 または 16.0 がサポートされています。
Amazon RDS では、データベースのバージョンのアップグレードがサポートされています。詳細については、「[DB インスタンスのエンジンバージョンのアップグレード](USER_UpgradeDBInstance.Upgrading.md)」を参照してください。
## スタートする前に
スタートする前に、Amazon VPC が必要です。Amazon RDS DB インスタンスは Siebel Enterprise Server でのみ使用できればよく、パブリックインターネットは必要ないため、Amazon RDS DB インスタンスはより優れたセキュリティを提供するプライベートサブネットでホストされます。Siebel CRM で使用する Amazon VPC を作成する方法については、「[Oracle DB インスタンスを作成して接続する](CHAP_GettingStarted.CreatingConnecting.Oracle.md)」を参照してください。
スタートする前に、Oracle DB インスタンスも必要です。Siebel CRM で使用する Oracle DB インスタンスを作成する方法については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
## Siebel Database のインストールと設定
Oracle DB インスタンスを作成した後、Siebel Database をインストールできます。テーブル所有者および管理者アカウントを作成し、保存手順と機能をインストールして、その後 Siebel Database Configuration Wizard を実行することで、データベースをインストールします。詳細については、「[Installing the Siebel Database on the RDBMS](https://docs.oracle.com/cd/E63029_01/books/SiebInstWIN/SiebInstCOM_ConfigDB.html)」を参照してください。
Siebel Database Configuration Wizard を実行するには、マスターユーザーアカウントを使用する必要があります。`SYSDBA` 権限は必要ありません。マスターユーザー権限で十分です。詳細については、「[マスターユーザーアカウント権限](UsingWithRDS.MasterAccounts.md)」を参照してください。
## Siebel Database によるその他の Amazon RDS 機能の使用
Oracle DB インスタンスを作成すると、Siebel Database のカスタマイズに役立つ追加の Amazon RDS 機能を使用できます。
### Oracle Statspack オプションでの統計情報の収集
DB オプショングループのオプションを使用して DB インスタンスに機能を追加できます。Oracle DB インスタンスを作成するときには、デフォルトの DB オプショングループを使用しました。データベースに機能を追加する場合は、DB インスタンスに対して新しいオプショングループを作成できます。
Siebel Database のパフォーマンス統計情報を収集する場合は、Oracle Statspack 機能を追加できます。詳細については、「[Oracle Statspack](Appendix.Oracle.Options.Statspack.md)」を参照してください。
オプションの変更は、直ちに適用されるものと、DB インスタンスの次のメンテナンス時間中に適用されるものがあります。詳細については、「[オプショングループを使用する](USER_WorkingWithOptionGroups.md)」を参照してください。カスタマイズされたオプショングループを作成後、DB インスタンスを修正してアタッチします。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
### パラメータによるパフォーマンスのチューニング
DB パラメータグループのパラメータを使用して DB エンジンの設定を管理します。Oracle DB インスタンスを作成するときには、デフォルトの DB パラメータグループを使用しました。データベースの設定をカスタマイズする場合は、DB インスタンスに対して新しいパラメータグループを作成できます。
パラメータの種類によって、パラメータの変更はすぐに適用されるものと、DB インスタンスを手動で再起動した後に適用されるものがあります。詳細については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。カスタマイズされたパラメータグループを作成後、DB インスタンスを修正してアタッチします。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
Oracle DB インスタンスを Siebel CRM 用に最適化するために、特定のパラメータをカスタマイズできます。次の表は、推奨されるパラメータ設定の一部です。Siebel CRM のパフォーマンスチューニングの詳細については、「[Siebel CRM Performance Tuning Guide](https://docs.oracle.com/cd/E63029_01/books/PerformTun/toc.htm)」を参照してください。
****
| パラメータ名 | デフォルト値 | Siebel CRM の最適なパフォーマンスのガイダンス |
| --- | --- | --- |
| \$1always\$1semi\$1join | `CHOOSE` | `OFF` |
| \$1b\$1tree\$1bitmap\$1plans | `TRUE` | `FALSE` |
| \$1like\$1with\$1bind\$1as\$1equality | `FALSE` | `TRUE` |
| \$1no\$1or\$1expansion | `FALSE` | `FALSE` |
| \$1optimizer\$1join\$1sel\$1sanity\$1check | `TRUE` | `TRUE` |
| \$1optimizer\$1max\$1permutations | 2000 | 100 |
| \$1optimizer\$1sortmerge\$1join\$1enabled | `TRUE` | `FALSE` |
| \$1partition\$1view\$1enabled | `TRUE` | `FALSE` |
| open\$1cursors | `300` | 少なくとも **2000**。 |
### スナップショットの作成
Siebel Database を作成した後、Amazon RDS のスナップショット機能を使用してデータベースをコピーできます。詳細については、「[Amazon RDS のシングル AZ DB インスタンスの DB スナップショットの作成](USER_CreateSnapshot.md)」および「[DB インスタンスへの復元](USER_RestoreFromSnapshot.md)」を参照してください。
## その他の Siebel CRM コンポーネントのサポート
Siebel Database に加えて、Amazon Web Services を使用して Siebel CRM アプリケーションアーキテクチャの他のコンポーネントをサポートすることもできます。追加の Siebel CRM コンポーネントに対して Amazon AWS により提供されるサポートに関する詳細を次の表に示します。
****
| Siebel CRM コンポーネント | Amazon AWS サポート |
| --- | --- |
| Siebel Enterprise(Siebel Server 1 つ以上含む) | Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで Siebel Server をホストできます。Amazon EC2 を使用して必要な分だけ仮想サーバーを起動できます。Amazon EC2 を使用すると、需要の変化に対応して簡単にスケールアップやスケールダウンができます。詳細については、「[Amazon EC2 とは](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html)」を参照してください。 サーバーを DB インスタンスと同じ VPC に配置し、データベースへのアクセスに VPC のセキュリティグループを使用できます。詳細については、「[VPC 内の DB インスタンスの使用](USER_VPC.WorkingWithRDSInstanceinaVPC.md)」を参照してください。 |
| ウェブサーバー(Siebel Web Server Extension を含む) | 複数の EC2 インスタンスに複数のウェブサーバーをインストールできます。その後、Elastic Load Balancing を使用して着信トラフィックをインスタンスに分散できます。詳細については、「[Elastic Load Balancing とは](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/elastic-load-balancing.html)」を参照してください。 |
| Siebel Gateway Name Server | EC2 インスタンスで Siebel Gateway Name Server をホストできます。その後、サーバーを DB インスタンスと同じ VPC に配置し、データベースへのアクセスに VPC のセキュリティグループを使用できます。詳細については、「[VPC 内の DB インスタンスの使用](USER_VPC.WorkingWithRDSInstanceinaVPC.md)」を参照してください。 |
# Oracle データベースエンジンのリリースノート
Amazon RDS for Oracle DB インスタンスは、更新によって常に最新の状態に保たれます。更新を適用することで、Oracle と Amazon の両方でテスト済みのバージョンのデータベースソフトウェアが、DB インスタンスで確実に実行されます。個々の RDS for Oracle DB インスタンスへのワンオフパッチの適用はサポートされていません。
新しい DB インスタンスを作成するときは、現在サポートされているいずれかの Oracle Database バージョンを指定できます。メジャーバージョン (Oracle Database 19c など) と、指定したメジャーバージョンでサポートされている任意のマイナーバージョンを指定できます。バージョンを指定しない場合、Amazon RDS では、サポートされているいずれかのバージョン (通常最新のバージョン) がデフォルトで設定されます。マイナーバージョンではなく、メジャーバージョンを指定した場合、Amazon RDS では、指定されたメジャーバージョンの最新リリースにデフォルトで設定されます。サポートされているバージョンのリストと、新しく作成された DB インスタンスのデフォルトを表示するには、[https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI コマンドを使用します。
Amazon RDS でサポートされている Oracle Database のバージョンの詳細については、「[https://docs.aws.amazon.com/AmazonRDS/latest/OracleReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/OracleReleaseNotes/Welcome.html)」を参照してください。