Amazon Web Services ブログ
Amazon EBS マルチボリュームのクラッシュ整合性のあるスナップショットを使用した Oracle のバックアップおよびリカバリのパフォーマンスの改善
Amazon Elastic Block Store (EBS) スナップショットは、ポイントインタイムスナップショットを取得することにより、EBS ボリューム上のデータを Amazon S3 にバックアップする機能を提供します。Amazon EC2 で Oracle Database を実行し、EBS ボリュームを使用する場合、バックアップ要件を満たすために EBS スナップショットを使用している可能性があります。2019 年 5 月より前は、データベースをバックアップモードにして、データベースファイルを含む各 EBS ボリュームのスナップショットを個別に作成する必要がありました。このアプローチには、主に 3 つの欠点がありました。
- データベースと対話する必要があった
- 複数の API を呼び出して、ボリュームの個別のスナップショットを作成する必要があった
- バックアップモードでは、データベースブロックは最初に変更されたときにログバッファに完全にコピーされ、これにより、特定のワークロードでより多くの REDO が生成され、データベースのパフォーマンスに影響が出る可能性がある
AWS は、1 回の API 呼び出しと最小限の I/O の一時停止で、EC2 インスタンスにアタッチされたすべての EBS ボリュームにわたってクラッシュ整合性のあるスナップショットを作成できる新しい機能を 2019 年 5 月にリリースしました。詳細については、「Amazon EC2 インスタンス上の複数の Amazon EBS ボリュームにわたってクラッシュ整合性のあるスナップショットを取得する」を参照してください。
この機能と Oracle Database 12c で導入された Storage Snapshot Optimization 機能を組み合わせることにより、データベースをバックアップモードにする必要がなくなります。この投稿では、このプロセスを順を追って説明し、(パフォーマンスの観点から) この新しい機能の利点について議論し、いくつかのユースケースについても説明します。
Oracle Database 12c Storage Snapshot Optimization 機能を活用するには、データベースが 12c 以上である必要があります。これにより、サードパーティーのテクノロジーを使用して、データベースをバックアップモードにせずにデータベースのストレージスナップショットを取得できます。そのスナップショットを使用して、データベースの全部または一部をリカバリできます。詳細については、Oracle ウェブサイトの「Storage Snapshot Optimization」を参照してください。
エンタープライズグレードのオンプレミスストレージアレイと Storage Snapshot Optimization 機能を備えた Oracle Database 12c を使用する Oracle のお客様は、ポイントインタイムリカバリやクローン作成など、大幅に改善されたバックアップおよびリストア操作の恩恵を受けています。新しい EBS マルチボリュームのクラッシュ整合性のあるスナップショット機能により、オンプレミスで長年使用してきた同様のスキルを使用して、AWS の全体的なエクスペリエンスを向上させることができます。
データベース (またはテーブルスペース) をバックアップモードにしないことの主な利点は、生成される REDO が少なくなることです。REDO の生成を少なくすると、チェックポイントの頻度と REDO サイズが減少します。これにより、バックアップ中のログ書き込みとデータベースライター I/O の両方が減少し、リカバリ中にログを適用する必要がある場合のデータベースリカバリ時間も短縮されます。
テスト環境
テスト環境には次の要素が含まれていました。
- EC2 インスタンスで作成された Oracle Database バージョン 19c インスタンス (ルートボリュームは 50 GB)
- 2 つのディスクグループ (
DATA
およびRECO
) を持つ ASM インスタンス- ディスクグループ
DATA
は、ASM ディスク (各 5 GB) として表示される 9 つの EBS ボリュームで構成され、データファイルが含まれます - ディスクグループ
RECO
は、ASM ディスク (それぞれ 30 GB) として提示される 4 つの EBS ボリュームで構成され、REDO ログファイル、アーカイブログファイル、および制御ファイルが含まれます
- ディスクグループ
- 各ブロックに 2 行のみが含まれる 19 GB のテーブル。次のコードを使用してテーブルを作成し、入力します。
- 次のコードを使用して作成できる、最初のクラッシュ整合性のあるマルチボリュームスナップショット:
この投稿のテスト中に、テーブルで更新アクティビティを生成し、更新アクティビティ後にデータベースをリカバリする必要性をシミュレートします。
クラッシュ整合性のあるスナップショットと Oracle Storage Snapshot Optimization の使用
最初のテストでは、クラッシュ整合性のあるスナップショット機能と Oracle Storage Snapshot Optimization を使用します。次の手順を実行します。
- 次のコードを使用して、19 GB のテーブルの列を更新します。
生成される REDO の量は約 42 GB です。次のコードを参照してください。
- 次のコードを使用して、別のクラッシュ整合性のあるマルチボリュームスナップショットを作成します。
ユースケースのシミュレーション
データベースをリカバリする必要性をシミュレートするには、次の手順を実行します。
- 次のコードを使用して、EC2 インスタンスを停止し、すべての EBS ボリューム (ルートボリュームを除く) をデタッチします。
- 初期のクラッシュ整合性のあるマルチボリュームスナップショットからボリュームを作成し (DATA ディスクグループのみ)、次のコードを使用して EC2 インスタンスにアタッチします。
- 更新後に取得したクラッシュ整合性のあるマルチボリュームスナップショットからボリュームを作成し (
RECO
ディスクグループのみ)、次のコードを使用して EC2 インスタンスにアタッチします。RECO
ディスクグループには、REDO ログファイル、制御ファイル、およびアーカイブ REDO ログファイルが含まれます。データベースをリカバリするために必要なすべての情報が含まれています。
データベースのリカバリ
データベースをリカバリするには、次の手順を実行します。
- EC2 インスタンスタイプを起動します。
- データベースを起動します。次のコードを参照してください。
- 初期スナップショットの時間を取得します (スナップショット全体で一意であることがわかります)。次のコードを参照してください。
- Storage Snapshot Optimization を使用してデータベースをリカバリします (以前の出力に基づいてスナップショット時間を適宜更新し、数秒追加します)。次のコードを参照してください。
リカバリにかかる時間は約 6 分です。
データベースのリストア
データベースをテスト前の状態にリストアするには、次の手順を実行します。
- EC2 インスタンスを停止し、ルートのものを除くすべての EBS ボリュームをデタッチします。以前に使用したのと同じスクリプトを使用できます。
- 最初のクラッシュ整合性のあるマルチボリュームスナップショット (
DATA
およびRECO
ディスクグループ用) からボリュームを作成し、EC2 インスタンスにアタッチします。次のコードを参照してください。 - EC2 インスタンスタイプを起動します。
- データベースを起動します。
ホストが単にクラッシュしたかのように、データベースインスタンスが起動し、インスタンスのリカバリのみを行います。これは、クラッシュ整合性のあるスナップショットの優れた使用例です。スナップショットの時点でのすべてのボリュームを単純にリストアおよびリカバリします。
バックアップの開始/終了手順を使用する
2 番目のテストでは、バックアップの開始/終了手順を使用します。次の手順を実行します。
- データベースをバックアップモードにします。次のコードを参照してください。
- 次のコードを使用して、
DATA
ディスクグループに属するすべての EBS ボリュームでループするスナップショットを作成します。 - 次のコードを使用して、19 GB テーブルの列を更新します (最初のテストと同じスクリプトを使用)。
生成される REDO の量は約 42 GB です。次のコードを参照してください。
- データベースのバックアップモードを解除します。次のコードを参照してください。
- 次のコードを使用して、
RECO
ディスクグループに属するすべての EBS ボリュームでループするスナップショットを作成します。
ユースケースのシミュレーション
データベースをリカバリする必要性をシミュレートするには、次の手順を実行します。
- EC2 インスタンスを停止し、ルートのものを除くすべての EBS ボリュームをデタッチします。以前に使用したのと同じコードを使用します。
DATA
ディスクグループに属する EBS ボリュームのスナップショットからボリュームを作成し (データベースがバックアップモードになっている間)、それらを EC2 インスタンスにアタッチします。次のコードを参照してください。RECO
ディスクグループに属する EBS ボリュームのスナップショットからボリュームを作成し (データベースのバックアップモードが解除されている間)、それらを EC2 インスタンスにアタッチします。次のコードを参照してください。
データベースのリカバリ
データベースをリカバリするには、次の手順を実行します。
- EC2 インスタンスタイプを起動します。
- データベースを起動します。次のコードを参照してください。
- データベースのリカバリを行います。次のコードを参照してください。
リカバリにかかる時間は約 15 分です。
追加のユースケース
次のユースケースでは、クラッシュ整合性のあるスナップショットを使用できます。
- ポイントインタイムリカバリ
- テスト環境の更新と作成の自動化 (ソースデータベースとの対話は一切なし)
- セキュリティのレイヤーの追加 (rman の使用や S3 へのバックアップなど、別のバックアップ戦略を使用する場合)
まとめ
この投稿では、データベースがバックアップモードでより多くの REDO ログを生成できることを示しました (同じ更新の場合)。クラッシュ整合性のあるスナップショットからのリカバリにかかる時間は、標準のバックアップ開始/バックアップ終了戦略からのリカバリに必要な時間よりもはるかに短いものでした。さらに、クラッシュ整合性のあるスナップショットを使用して、最初のテストの前と同じように (2 つのテスト間で) データベースを再構築できます (インスタンスリカバリのみを実行)。
以上のことから、Oracle Database インスタンスを Amazon EC2 で実行し、Amazon EBS ボリュームを使用する場合、上記の利点のためにクラッシュ整合性のあるスナップショット機能の使用を検討することをお勧めします。
著者について
Bertrand Drouvot 氏は、アマゾン ウェブ サービスのシニアデータベースエンジニアです。