Oracle Flashbackのベスト・プラクティス

10 Oracle Flashbackのベスト・プラクティス

Oracle Databaseフラッシュバック・テクノロジは、誤った操作による影響を選択的かつ効率的に取り消すことで、データベースが人的エラーを無効にできるようにする、独自の充実した一連のデータ・リカバリ・ソリューションです。

Oracle Databaseにフラッシュバックが導入される以前は、データベースの破損にかかる時間が数分でも、そのリカバリには数時間かかる場合がありました。フラッシュバックでは、エラーの修正にかかる時間は、エラーの発生にかかる時間とほぼ同じです。また、このエラーからのリカバリに必要な時間は、Oracle Database固有の機能であるデータベース・サイズに依存しません。

フラッシュバックでは、行、トランザクション、表およびデータベース全体を含むすべてのレベルでのデータベース・リカバリがサポートされています。フラッシュバックは、データを表示したり、任意の時点にデータを戻したり、進めるための増え続ける機能セットを提供し、高可用性と障害時リカバリのいくつかの重要なユースケースに対応します。機能およびユースケースのリストといくつかの主な例については、「Oracle Flashback Technology」を参照してください。

フラッシュバック機能を使用すると、データベースがオンラインである間に、履歴データを問い合せ、変更分析を実行し、セルフサービス修復を実行して、論理的な破損からリカバリできます。Oracle Flashback Technologyを使用すると、実際に、過去を元に戻すことができます。

Oracle Flashbackのパフォーマンス観測

構成および運用のベスト・プラクティスを採用し、推奨パッチを適用した後、プライマリ・データベースまたはスタンバイ・データベースでフラッシュバック・データベースが有効になっている状態で、Oracleでは次のパフォーマンス観測を確認しました。

データベースまたはPDBを前の時間にフラッシュバックするには、ワークロードが非常に高い場合でも、通常、数秒および数分かかります。特定の量のREDOを適用するのにかかる時間の何分の1かで終了します。次に、いくつかの観測を示します。
- 400 GBの変更で構成される大規模なバッチ・ワークロードのフラッシュバックが5分未満で完了しました。
- 8GBの変更を含む大容量のOLTPのフラッシュバックが2分未満で完了しました。
- 多くの変数があるため、フラッシュバックを完了するまでの時間を推定する経験則または計算はありません。これらの観測が確認されたテストは、記憶域I/O帯域幅などのシステム・ボトルネックを取り除くためにExadataで行われました。
プライマリ・データベースへのOLTPワークロードの影響は、通常5パーセント未満です。
大容量の挿入(バッチ挿入など)または直接ロード操作による影響は、フラッシュバック・ブロックの新しい最適化が有効な場合、通常は5パーセント未満です。それ以外の場合は、影響は大幅に変動するため(2-40%の影響)、テストが必要です。

「特定のアプリケーションのユースケースに対するOracle Flashbackのパフォーマンス・チューニング」で、ブロックの新しい最適化に関する説明と例外を取り上げたフラッシュバックのユースケースを参照してください。
スタンバイ・システムが高速リカバリ領域の追加のI/Oスループット要件に対応できない場合、フラッシュバック・データベースを有効にすると、フィジカル・スタンバイ・データベースのピークREDO適用パフォーマンス率が低下する可能性があります。ただし、スタンバイでフラッシュバック・データベースが有効になっていても、フラッシュバックが有効な状態で実現可能なREDO適用率は非常に高く、アプリケーションのREDO生成率を超える可能性があります。

次のリストに、様々なOracle Databaseソフトウェア・リリースでの重要なフラッシュバック・マイルストンおよび主要なパフォーマンスの改善を示します。

Oracle Database 12cリリース2 (12.2)

プラガブル・データベースのフラッシュバックを使用すると、他のPDBに影響を与えずに個々のPDBのフラッシュバックが可能になります。
PDBリストア・ポイントを使用すると、簡単に別名をSCNに設定できます。その後、この別名は、フラッシュバックPDBまたはポイント・イン・タイム・リカバリに使用できます。

Oracle Database 19c

プライマリ・データベースでリストア・ポイントを作成すると、自動的にスタンバイ・データベースに伝播され、対応するリストア・ポイントがスタンバイ・データベースに作成されます。
Oracle Data Guard構成のプライマリ・データベースとスタンバイ・データベースの両方でフラッシュバック・データベースが有効になっている場合、プライマリ・データベースをフラッシュバックすると、スタンバイ・データベースも自動的にフラッシュバックされます。

Oracle Database 21c

フラッシュバック・データ・アーカイブが有効な表の異なるデータベース・リリース間での移行
データ・ファイルのサイズ変更操作のフラッシュバック・データベース・サポート
PDBは、同じCDBインカネーションまたは祖先インカネーション内の孤立したPDBインカネーションにリカバリできます

Oracle Flashback構成のベスト・プラクティス

次に、Oracle Databaseでフラッシュバック・テクノロジを構成するためのOracle MAAのベスト・プラクティスを示します。

DB_FLASHBACK_RETENTION_TARGETの設定

DB_FLASHBACK_RETENTION_TARGET初期化パラメータを、次のいずれかの適用される条件で指定されている最大値に設定します。

Oracle Data Guardフェイルオーバー後にフラッシュバック・データベースを利用して障害が発生したプライマリ・データベースを復元するには、DB_FLASHBACK_RETENTION_TARGETを60 (分)以上に設定して、障害が発生したプライマリの復元を有効化します。フラッシュバック・データベースを有効にする場合、復元が可能になる前に、十分なフラッシュバック・データをフラッシュバック・ログに生成するために数時間かかります。V$FLASHBACK_DATABASE_LOGを問い合せて、最も古いフラッシュバック時間を見つけることができます。
複数の停止が発生したケースを想定してください(ネットワークの停止後にプライマリ・データベースの停止が発生するなど)。この場合、フェイルオーバー時にプライマリ・データベースとスタンバイ・データベース間に転送ラグが生じる可能性があります。このような場合は、DB_FLASHBACK_RETENTION_TARGETを、対応可能な最大転送ラグを60 (分)にプラスした合計と等しい値に設定します。これにより、障害が発生したプライマリ・データベースを、スタンバイがプライマリになったときのSCNよりも前のSCNに確実にフラッシュバックできます。これはプライマリ復元の要件です。
ユーザー・エラーまたは論理破損からの高速ポイント・イン・タイム・リカバリにフラッシュバック・データベースを使用中の場合、DB_FLASHBACK_RETENTION_TARGETを、リカバリ可能な過去の最も遠い時間と等しい値に設定します。
ほとんどの場合、DB_FLASHBACK_RETENTION_TARGETは、プライマリとスタンバイで同じ値に設定する必要があります。

高速リカバリ領域のサイズ設定

フラッシュバック・データベースでは、独自のロギング・メカニズムによってフラッシュバック・ログが作成され、高速リカバリ領域(FRA)に格納されます。FRAに、ターゲット保持サイズおよびピーク・バッチ率のフラッシュバック・ログを格納するための十分な領域が割り当てられていることを確認します。FRAのサイズ設定については、Oracleバックアップおよびリカバリのドキュメントで詳しく説明しますが、フラッシュバック・ログ生成のボリュームは、REDOログ生成の大きさとほぼ同じです。次の保守的な式とアプローチを使用します。

ターゲットFRA = 現在のFRA + DB_FLASHBACK_RETENTION_TARGET x 60 x ピークREDO率(MB/秒)

例:

現在のFRAまたはDB_RECOVERY_FILE_DEST_SIZE= 1000GB
ターゲットDB_FLASHBACK_RETENTION_TARGET=360 (360分)
AWRからの場合:
- OLTPワークロードのピークREDO率は、データベースに対して3 MB/秒です
- バッチ・ワークロードのピークREDO率は、データベースに対して30 MB/秒で、最長期間は4時間です
- 6時間ウィンドウの最悪のREDO生成サイズは、(240分 x 30 MB/秒 x 60秒/分) + (120分 x 3 MB/秒 x 60秒/分) = 453,600 MB、または約443 GBです
提案されたFRAまたはDB_RECOVERY_FILE_DEST_SIZE= 443 GB +1000 GB = 1443 GB

FRAのサイズ設定を決定するための他の方法は、フラッシュバック・データベースを有効にして、データベース・アプリケーションを短期間(2-3時間)実行できるようにし、V$FLASHBACK_DATABASE_STAT.ESTIMATED_FLASHBACK_SIZEを問い合せることです。

DB_FLASHBACK_RETENTION_TARGETは目標であり、データベースを同じくらいフラッシュバックできるという保証はありませんので注意してください。フラッシュバック・ログが格納されているFRAで領域が不十分な場合は、最も古いフラッシュバック・ログを削除できます。FRA削除ルールの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』の高速リカバリ領域のメンテナンスに関する項を参照してください。保証付きリストア・ポイント(GRP)を使用して、フラッシュバックのポイント・イン・タイムを保証する必要があります。GRPが削除されるまで、必要なフラッシュバック・ログはGRPでリサイクルまたはパージされません。GRPがあるが領域が不十分な場合にデータベースが応答を停止する可能性があるため、GRPの対象期間に応じて、FRAに追加領域を割り当てる必要があります。

高速リカバリ領域の十分なI/O帯域幅の構成

OLTPワークロードの自動ワークロード・リポジトリ(AWR)レポートでFLASHBACK BUF FREE BY RVWR待機イベントが頻繁に発生し、大容量の挿入操作でFLASHBACK LOG FILE WRITE待機時間が30ミリ秒を超える場合、一般的には、フラッシュバック・データベースが有効化されていてI/O帯域幅が不十分です。

通常、フラッシュバックI/Oのサイズは1 MBです。全体的な書込みスループットは、データベースの強制ロギングが有効になっている場合にはREDO生成率と同様となり、または直接ロード操作の場合にはロード率と同一となる場合があります。簡潔化のために、1つの大きな共有ストレージGRIDを構成し、ディスクまたはLUNの外側の部分にDATAを構成して、ディスクまたはLUNの内側の部分にRECO (FRA)を構成します。これは、Exadataシステムの場合には自動的に実行されます。

LOG_BUFFERの設定

フラッシュバック・データベースのメモリー内にバッファ領域を追加するには、オペレーティング・システムの制限に応じて、初期化パラメータLOG_BUFFER=256MB以上を設定します。

Oracle Flashbackの運用ベスト・プラクティス

次に、フラッシュバック・データベースに対するOracle MAAの推奨される運用ベスト・プラクティスを示します。

フラッシュバック・データベースを有効にする前後に、自動ワークロード・リポジトリ(AWR)またはOracle Enterprise Managerを使用してデータベース統計を収集し、フラッシュバック・データベースの有効化による影響を測定できます。
Oracle Enterprise Managerを使用して、Enterprise Manager監視メトリック「リカバリ領域空き領域(%)」を、高速リカバリ領域(FRA)における領域の問題の予防的アラートに設定します。
フラッシュバック・データベース操作の進捗状況は、V$SESSION_LONGOPSビューを問い合せることによって監視できます。たとえば、

select * from v$session_longops where opname like 'Flashback%';

フラッシュバック・データベース操作で詳細が必要な場合は、データベース・パラメータ_FLASHBACK_VERBOSE_INFO=TRUEを設定して、データベースのDIAGNOSTIC_DESTトレース・ディレクトリにフラッシュバック・データベース操作の詳細なトレースを生成します。
フラッシュバック・データベースを使用してテスト・データベースで繰返しテストを実行する場合は、明示的にフラッシュバック・データベースを有効にせずに、保証付きリストア・ポイント(GRP)のみを使用することをお薦めします。領域の使用率およびフラッシュバック・パフォーマンスのオーバーヘッドを最小限に抑えるには、次の推奨アプローチに従います。
```
Create Guaranteed Restore Point (GRP)
Execute test
loop
     Flashback database to GRP
     Open resetlogs
     Create new GRP
     Drop old GRP
     Execute
testEnd loop
```
「REDO適用のトラブルシューティングおよびチューニング」で説明されているOracle Data Guard REDO適用のベスト・プラクティスに従います。

特定のアプリケーションのユースケースに対するOracle Flashbackのパフォーマンス・チューニング

OLTPワークロードのパフォーマンス・チューニング

flashback buf free by RVWR待機イベントは、フラッシュバック・データベースが有効になっている場合にのみ発生します。バッファの満杯によりディスクのフラッシュバック・ログにフラッシュバック・データを書き込むため、セッションはリカバリ・ライター(RVWR)を待機します。セッションは、RVWRによりバッファを解放できるまで待機することが必要になる場合があります。

このイベントがデータベースの上位待機イベントの1つになるとします。その場合、これは通常、高速リカバリ領域(FRA)のファイル・システムまたはストレージ・システムに、フラッシュバック書込みからの追加のI/Oに対応できる十分なI/O帯域幅がないためです。チューニングの考慮事項および対応するI/Oとストレージの統計の評価については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』のフラッシュバック・データベースに関する項を参照してください。

表10-1 上位5位のフォアグラウンド時間イベント

イベント	待機	回数	平均待機(ミリ秒)	%データベース時間	待機クラス
write complete waits	1,842	23,938	12995	33.68	構成
flashback buf free by RVWR	53,916	20,350	377	28.63	構成
cell single block physical read(セルの単一ブロックの物理読込み)	3,029,626	16,348	5	23.00	ユーザーI/O
buffer busy waits	6,248	5,513	882	7.76	同時実行性
DB CPU		1,757		2.47

ダイレクト・パス操作のパフォーマンス・チューニング

AWRレポートまたはOracle Enterprise Managerで、v$sysstatにあるflashback log write bytesおよびphysical write bytesのシステム統計を確認します。

flashback log write bytes = RVWRによってフラッシュバック・データベース・ログに書き込まれたフラッシュバック・データベース・データの合計サイズ(バイト)
physical write bytes = データベース・アプリケーション・アクティビティ(他のインスタンス・アクティビティは含まれない)によるすべてのディスク書込みの合計サイズ(バイト)。

(flashback log write bytes) / (physical write bytes) < 5%の場合、フラッシュバックはパフォーマンスに影響しません。

それ以外の場合は、フラッシュバック・ブロックの新しい最適化機能を使用できる運用上の変更またはバグ修正を評価します(前述のパフォーマンス観測に関する項を参照)。さらに、上位の待機イベントの1つであっても、flashback log file sync待機イベントを無視します。

ブロックの新しい最適化が有効な例

この例の詳細は次のとおりです。

flashback log write bytes = 1,223,442,432
physical write bytes = 184,412,282,880

(flashback log write bytes) / (physical write bytes) = 0.0066 < 5%という結果は、直接ロード操作が行われるこの間隔内の物理書込みと比較して、フラッシュバック・データが何分の1かのわずかな量であることを意味します。この場合でも、flashback log file sync待機イベントは、次の表に示すように、データベース内の上位2番目の待機イベントでした。

表10-2 上位5位のフォアグラウンド時間イベント

イベント	待機	回数	平均待機(ミリ秒)	%データベース時間	待機クラス
direct path write	136,553	7,875	58	39.12	ユーザーI/O
flashback log file sync	91,566	5,887	64	29.25	ユーザーI/O
DB CPU		3,092		15.36
log buffer space	20,545	1,737	85	8.63	構成
gc buffer busy release	1,277	487	382	2.42	クラスタ

ブロックの新しい最適化が有効でない例

この例の詳細は次のとおりです。

flashback log write bytes= 184,438,194,176
physical write bytes =184,405,925,888

(flashback log write bytes) / (physical write bytes) = 100% > 5%という結果は、この場合、すべての直接書込みでもフラッシュバック・ログ書込みが行われることを意味します。ここで、この場合の上位待機イベントを示します。

表10-3 上位5位のフォアグラウンド時間イベント

イベント	待機	回数	平均待機(ミリ秒)	%データベース時間	待機クラス
flashback log file sync	170,088	22,385	132	52.04	ユーザーI/O
direct path write	278,185	8,284	30	19.26	ユーザーI/O
flashback buf free by RVWR	38,396	5,048	131	11.74	構成
direct path read	220,618	4,242	19	9.86	ユーザーI/O
DB CPU		2,788		6.48

従来型ロード操作のパフォーマンス・チューニング

次の例は、ブロックの新しい最適化を使用する場合と使用しない場合の、2つの従来型ロードを示しています。

ブロックの新しい最適化が有効でない例

次の例では、表をロードする直前に切り捨てるため、ブロックの新しい最適化を使用しません。ブロックの新しい最適化を使用しない従来型ロードの待機イベントでは、flashback log file syncにかかる合計待機時間が非常に長時間であることがわかります。これは、ブロックのイメージをバッファ・キャッシュに読み込み、ブロックをフラッシュバック・ログに書き込むために時間が必要であるためです。

表10-4 上位5位のフォアグラウンド時間イベント

イベント	待機	回数	平均待機(ミリ秒)	%データベース時間	待機クラス
flashback log file sync	235,187	13,728	58	30.82	ユーザーI/O
direct path write	558,037	10,818	19	24.29	ユーザーI/O
direct path read	459,076	8,419	18	18.90	ユーザーI/O
DB CPU		6,171		13.85
flashback buf free by RVWR	79,463	4,268	54	9.58	構成

次のインスタンス統計では、ブロックの新しい最適化を追跡する統計において増加はほとんど見られません。

統計	合計	1秒当たり	1トランザクション当たり
flashback cache read optimizations for block new	62	0.06	1.13
flashback direct read optimizations for block new	8	0.01	0.15
flashback log write bytes	177,533,280,256	177,245,433.67	3,227,877,822.84
flashback log writes	18,917	18.89	343.95

flashback cache read optimizations for block newがflashback log writesよりはるかに小さい場合、ブロックの新しい最適化は効果がありません。

前述のロード操作に最適なチューニングの推奨事項は、I/O帯域幅を増やすか、またはブロックの新しい最適化を活用できるようにロードの実行方法を変更することです。フラッシュバック保存目標の対象外となるまで待機するか、オブジェクトが削除された場合はごみ箱から削除することもできます。

ブロックの新しい最適化が影響しない例

ブロックの新しい最適化を使用する従来型ロードの待機イベントでは、次に示すように、他のデータベース待機と比較して、flashback log file syncにかかる合計時間が比較的少ないことがわかります。

表10-5 上位5位のフォアグラウンド時間イベント

イベント	待機	回数	平均待機(ミリ秒)	%データベース時間	待機クラス
direct path write	284,115	8,977	32	34.20	ユーザーI/O
DB CPU		6,284		23.94
log buffer space	128,879	5,081	39	19.36	構成
flashback log file sync	139,546	3,178	23	12.11	ユーザーI/O
ラッチ: REDO割当て	95,887	1,511	16	5.76	その他

インスタンス統計を見ると、ブロックの新しい操作を追跡する統計がロード中に大幅に増加したことがわかります。

統計	合計	1秒当たり	1トランザクション当たり
flashback cache read optimizations for block new	329	0.53	9.68
flashback direct read optimizations for block new	698,410	1,116.43	20,541.47
flashback log write bytes	1,197,514,752	1,914,271.66	35,221,022.12
flashback log writes	18,951	30.29	557.38