7 フラッシュバック・データベースおよびリストア・ポイントの使用
この章では、フラッシュバック・データベースおよびリストア・ポイントについて説明します。全体的なデータ保護計画の一環としてこれらの機能を構成、監視およびメンテナンスする方法を示します。
この章のトピックは、次のとおりです:
ノート:
フラッシュバック・データベースおよび通常のリストア・ポイントと保証付きリストア・ポイントを使用するリカバリ・シナリオの詳細は、「フラッシュバックおよびデータベースのPoint-in-Timeリカバリの実行」を参照してください。
7.1 フラッシュバック・データベース、リストア・ポイントおよび保証付きリストア・ポイントの概要
Oracle Flashback Databaseおよびリストア・ポイントは、関連するデータ保護機能です。これらの機能を使用すると、データを特定の時点まで巻き戻して、指定の期間中に論理的なデータ破損またはユーザー・エラーによって生じた問題を解決できます。
これらの機能は、Point-in-Timeリカバリの効率的な代替手段となり、リストア対象のデータベースの事前バックアップを必要としません。その効果は、データベースのPoint-in-Timeリカバリ(DBPITR)を使用した場合と同様です。フラッシュバック・データベースおよびリストア・ポイントは、従来のデータベース・リカバリ状況で効果的に使用できるだけでなく、データベースのアップグレード・シナリオ、アプリケーションのデプロイメント・シナリオ、およびテスト・データベースをすばやく作成したり、再作成する必要があるテスト・シナリオでも役立ちます。また、フラッシュバック・データベースは、Data Guardフェイルオーバーの後に、障害が発生したプライマリ・データベースを再構築するかわりとしても効率的に使用できます。
リストア・ポイントには、フラッシュバック・データベースおよびその他のメディア・リカバリ操作に関連する機能が備えられています。特に、任意のシステム変更番号(SCN)で作成された保証付きリストア・ポイントによって、フラッシュバック・データベースを使用してデータベースをこのSCNに確実に巻き戻せるようになります。リストア・ポイントおよびフラッシュバック・データベースは、別々に使用することも、一緒に使用することもできます。
フラッシュバック・データベースは、FLASHBACK DATABASE
としてRMANとSQLの両方からアクセス可能です。いずれかの言語を使用して、論理的なデータ破損またはユーザー・エラーからデータベースをすばやくリカバリできます。次の例では、データベースを指定したSCNまたはリストア・ポイントに戻します。
FLASHBACK DATABASE TO RESTORE POINT 'before_upgrade';
FLASHBACK DATABASE TO SCN 202381;
7.1.1 フラッシュバック・データベースについて
フラッシュバック・データベースは、従来のPoint-in-Timeリカバリと類似しています。フラッシュバック・データベースを使用すると、データベースを直前の状態に戻すことができます。フラッシュバック・データベースは、Point-in-Timeリカバリよりはるかに高速ですが、これは、フラッシュバック・データベースでは、バックアップからデータファイルをリストアする必要がなく、アーカイブREDOログから適用する変更が少ないためです。
データファイルが影響を受けていない場合、フラッシュバック・データベースを使用して、データベースに対する最も不要な変更を無効にすることができます。データベースを直前のインカネーションの状態に戻したり、ALTER DATABASE OPEN RESETLOGS
文の効果を元に戻すことができます。FLASHBACK
DATABASE
コマンドを使用してデータベースの変更を無効にする方法については、「フラッシュバック・データベースを使用したデータベースの巻戻し」を参照してください。
フラッシュバック・データベースでは、独自のロギング・メカニズムによってフラッシュバック・ログが作成され、高速リカバリ領域に格納されます。フラッシュバック・データベースは、フラッシュバック・ログが使用可能な場合にのみ使用できます。フラッシュバック・データベースを使用するには、フラッシュバック・ログが作成されるようにデータベースを事前に設定しておく必要があります。
フラッシュバック・データベースを有効にするには、高速リカバリ領域を構成し、フラッシュバック保存目標を設定します。この保存目標では、フラッシュバック・データベースを使用してデータベースをどの程度巻き戻すかを指定します。
その時点以降、一定間隔で、すべてのデータファイル内の変更されている各ブロックのイメージがフラッシュバック・ログにコピーされます。これらのブロック・イメージを後で再利用して、ログが取得された時点のデータファイルの内容を再構築できます。
フラッシュバック・データベースを使用してデータベースを過去の目標時点に巻き戻すと、コマンドによって、目標時点以降に変更されたブロックが判別され、フラッシュバック・ログからリストアされます。データベースでは、目標時点の直前の各ブロックのバージョンがリストアされます。次に、データベースでは、REDOログを使用して、これらのブロックがフラッシュバック・ログに書き込まれた後に行われた変更が再適用されます。
ディスクまたはテープ上のREDOログは、フラッシュバック・ログに記録されている期間中、使用可能である必要があります。たとえば、フラッシュバック保存目標が1週間の場合は、過去1週間のすべての変更が含まれているオンラインREDOログおよびアーカイブREDOログに、アクセスできるようにしておく必要があります。実際にPoint-in-Timeリカバリをサポートするには、通常、REDOログはフラッシュバック保存目標より長い期間必要とされます。
7.1.2 フラッシュバック・データベース・ウィンドウについて
FLASHBACK DATABASE
コマンドをサポートするための十分なフラッシュバック・ログ・データが現在存在するSCNの範囲をフラッシュバック・データベース・ウィンドウと呼びます。フラッシュバック・データベース・ウィンドウは、使用可能なフラッシュバック・ログの最も古いSCNより前に延長することはできません。
フラッシュバック・ログは、高速リカバリ領域外の場所にはバックアップできません。フラッシュバック・データベース・ウィンドウを満たすための十分なフラッシュバック・ログが保存される可能性を高くするために、高速リカバリ領域を増加することができます(「表5-3」を参照)。
高速リカバリ領域が、保存方針に必要なフラッシュバック・ログおよびアーカイブREDOログや他のバックアップなどのファイルを保持できるサイズでない場合、データベースでは、最も古いSCNからフラッシュバック・ログを削除して他のファイル用に領域を確保することができます。この結果、フラッシュバック・データベース・ウィンドウは、高速リカバリ領域のサイズ、保存する必要がある他のバックアップおよび必要なフラッシュバック・ロギング・データの量に応じてフラッシュバック保存目標より短くなる可能性があります。フラッシュバック保存目標は目標であり、フラッシュバック・データベースが使用可能であることを保証するものではありません。
フラッシュバック・データベース・ウィンドウの長さが十分でないためFLASHBACK DATABASE
を使用できないときは、通常、同様の目的でデータベースのPoint-in-Timeリカバリ(DBPITR)を使用できます。フラッシュバック・データベースを使用して特定の時点に戻すか、またはフラッシュバック・ウィンドウのサイズを確保できるようにする場合は、保証付きリストア・ポイントが唯一の方法となります。
ノート:
表領域の削除やデータファイルの縮小などの一部のデータベース操作は、フラッシュバック・データベースで無効にできません。詳細は、「フラッシュバック・データベースの制約」を参照してください。
関連項目:
-
フラッシュバック・データベースについて学習するには、フラッシュバック・データベースを使用したデータベースの巻戻しを参照してください。
-
DBPITRについて学習するには、データベースのPoint-in-Timeリカバリの実行を参照してください。
7.1.3 フラッシュバック・データベースの制約
フラッシュバック・データベースは、コマンドの実行時に存在するデータファイルへの変更を取り消すことで機能するため、特定の制約があります。
フラッシュバック・データベースの制約を次に示します。
-
フラッシュバック・データベースでは、Oracle Databaseで行われたデータファイルに対する変更のみを元に戻すことができます。メディア障害の修復またはデータファイルの誤った削除からのリカバリには使用できません。
-
フラッシュバック・データベースを使用して、データファイルの縮小操作を元に戻すことはできません。ただし、縮小されたファイルをオフラインにして、データベースの残りの部分をフラッシュバックし、その後、縮小されたデータファイルをリストアおよびリカバリすることはできます。
-
フラッシュバック・データベースのみを使用して、削除されたデータファイルを回復することはできません。削除されたデータファイルがデータベースに存在していた時点にデータベースをフラッシュバックした場合、データファイル・エントリが制御ファイルに追加されるだけです。削除されたデータファイルをリカバリできるのは、RMANを使用してデータファイルを完全にリストアおよびリカバリした場合のみです。
-
データベース制御ファイルがバックアップからリストアされるか、または再作成されると、すべての累積フラッシュバック・ログ情報が破棄されます。
FLASHBACK DATABASE
を使用して、制御ファイルのリストアまたは再作成が行われたときより前に戻すことはできません。 -
NOLOGGING
操作が行われていたターゲット時刻を指定してフラッシュバック・データベースを使用すると、NOLOGGING
操作の影響を受けたデータベース・オブジェクトとデータファイルのブロックが破損している可能性があります。たとえば、ダイレクト・パスINSERT
操作をNOLOGGING
モードで2005年4月3日9:00から9:15に実行し、その後、フラッシュバック・データベースを使用して同じ日の09:07の目標時点に戻す場合、ダイレクト・パスINSERT
によって更新されたオブジェクトおよびデータファイルは、フラッシュバック・データベース操作が完了した後も、ブロック破損状態のままになる可能性があります。可能な場合、
NOLOGGING
操作と同時の目標時点またはSCNでフラッシュバック・データベースを使用することを避けてください。また、NOLOGGING
操作の直後に、影響を受けたデータファイルの完全バックアップまたは増分バックアップを実行し、操作後の時点へのリカバリを可能にしてください。フラッシュバック・データベースを使用して、ダイレクト・パスINSERT
などの操作中の時点に戻す予定がある場合、操作をLOGGING
モードで実行することを検討してください。関連項目:
NOLOGGING
モードをサポートする操作の詳細は、Oracle Database SQL言語リファレンスを参照してください。
7.1.4 通常のリストア・ポイントについて
通常のリストア・ポイントを作成すると、リストア・ポイント名がSCNまたは特定の時点に割り当てられます。
これによって、リストア・ポイントはこのSCNのブックマークまたは別名として機能します。通常のリストア・ポイントは、無効にする必要がある操作を実行する前に作成できます。制御ファイルに、リストア・ポイント名およびSCNが格納されます。
フラッシュバック機能またはPoint-in-Timeリカバリを使用する場合は、時刻またはSCNのかわりに、リストア・ポイント名を使用します。次のコマンドでは、リストア・ポイントをこの方法で使用できます。
-
RMANの
RECOVER DATABASE
およびFLASHBACK DATABASE
コマンド -
SQLの
FLASHBACK TABLE
文
通常のリストア・ポイントを作成すると、事前に手動でSCNを記録する必要がありません。つまり、問題が発生した後でフラッシュバック問合せなどの機能を使用して適切なSCNを判別します。
通常のリストア・ポイントは軽量です。制御ファイルには、データベースのパフォーマンスに大きな影響を与えることなく、数千もの通常のリストア・ポイントの記録を保持できます。通常のリストア・ポイントは、手動で削除しない場合でも、最終的には制御ファイルからエージ・アウトされるため、継続的なメンテナンスは不要です。
関連項目:
フラッシュバック問合せの使用方法を学習するには、Oracle Database開発ガイドを参照してください。
7.1.5 保証付きリストア・ポイントについて
通常のリストア・ポイントと同様に、保証付きリストア・ポイントは、リカバリ操作でSCNの別名として機能します。保証付きリストア・ポイントは、制御ファイルからエージ・アウトされず、明示的に削除する必要がある点が主な違いとなります。
通常、保証付きリストア・ポイントは、通常のリストア・ポイントで動作するすべてのコマンドで、SCNの別名として使用できます。特に明記されていないかぎり、通常のリストア・ポイントの使用箇所および使用方法に関する情報は、保証付きリストア・ポイントにも適用されます。
保証付きリストア・ポイントによって、フラッシュバック・ログが無効になっている場合でも、フラッシュバック・データベースを使用してデータベースをリストア・ポイントSCNの状態に巻き戻すことができます。フラッシュバック・ロギングが有効になっている場合は、保証付きリストア・ポイントによって、最も古い保証付きリストア・ポイント以降の任意のSCNまで、フラッシュバック・データベースに必要なフラッシュバック・ログが保存されます。したがって、フラッシュバック・ロギングが有効になっている場合は、データベースを1つのSCNにのみ巻き戻すのではなく、連続したいずれかのSCNに巻き戻すことができます。
ノート:
フラッシュバック・ロギングが無効になっている場合は、FLASHBACK DATABASE
を使用して、保証付きリストア・ポイントと現時点の間にあるSCNに直接データベースをフラッシュバックすることはできません。ただし、最初に保証付きリストア・ポイントにフラッシュバックしてから、保証付きリストア・ポイントと現時点の間にあるSCNにリカバリすることはできます。
必要なログを格納できる十分なディスク領域がリカバリ領域にある場合は、保証付きリストア・ポイントを使用して、数日前または数週間前の良好な状態にデータベース全体を巻き戻すことができます。フラッシュバック・データベースの場合と同様に、ダイレクト・ロード・インサートなどのNOLOGGING
操作の影響も、保証付きリストア・ポイントを使用して無効にすることができます。
ノート:
フラッシュバック・データベースに適用される制限事項は、保証付きリストア・ポイントにも適用されます。たとえば、データファイルの縮小または表領域の削除を行うと、その影響を受けるデータファイルは、保証付きリストア・ポイントまでフラッシュバックされません。詳細は、「フラッシュバック・データベースの制約」を参照してください。また、データベースに保証付きリストア・ポイントが存在する場合は、データベース互換性パラメータを上位のデータベース・バージョンに設定できません。設定すると、エラーが発生します。このように制限されるのは、現在、フラッシュバック・データベースでは互換性初期化パラメータを使用してデータベース・バージョンの増加を無効にできないためです。
7.1.5.1 保証付きリストア・ポイントとストレージ・スナップショットの比較
実際、保証付きリストア・ポイントは、ストレージ・スナップショットにかわる有効な機能です。
多くの場合、ストレージ・スナップショットは、大規模なデータベースの更新、アプリケーションのパッチの適用やアップグレードなどの危険を伴う操作の前に、データベースを保護するために使用します。操作のテスト用にスナップショットまたは複製データベースを作成するかわりに、プライマリ・データベースまたはフィジカル・スタンバイ・データベースに保証付きリストア・ポイントを作成できます。これによって、必要なフラッシュバック・ログが確実に保存される状態で、危険を伴う操作を実行できます。
7.1.6 マルチテナント環境でのリストア・ポイントの概要
マルチテナント環境には、通常のリストア・ポイントと保証付きリストア・ポイントの両方を作成できます。
データベースのリストア・ポイントの基本的な概念は、マルチテナント環境のリストア・ポイントにも適用されます。マルチテナント環境に作成できるリストア・ポイントのタイプは次のとおりです。
-
CDBリストア・ポイント
-
PDBリストア・ポイント
-
クリーンPDBリストア・ポイント
7.1.6.1 CDBリストア・ポイントについて
CDBリストア・ポイントは、SCNの別名またはマルチテナント・コンテナ・データベース(CDB)の特定の時点として機能します。通常のリストア・ポイントまたは保証付きリストア・ポイントになります。
作成するためにSYSDBA
権限またはSYSBACKUP
権限を持つ共通ユーザーとしてrootに接続する必要がある点以外は、CDBリストア・ポイントは非CDBのリストア・ポイントと同様です。CDBリストア・ポイントは、Oracle Database 12cリリース1 (12.1)以上で作成できます。CDBリストア・ポイントは、CDB内のすべてのプラガブル・データベース(PDB)にアクセス可能です。ただし、CDBリストア・ポイントは、そのPDBのPDBサブインカネーションを反映しません。
CDBリストア・ポイントは、次のシナリオで便利です。
-
CDB全体を特定の時点にリカバリする必要がある場合
-
CDB内の複数のPDBを特定の時点にリカバリする必要がある場合
7.1.6.2 PDBでのリストア・ポイントについて
プラガブル・データベース(PDB)に、通常のリストア・ポイントと保証付きリストア・ポイントを作成できます。PDBリストア・ポイントは、それが定義されているPDBに対してのみアクセス可能です。
PDBリストア・ポイント
PDBリストア・ポイントは、特定の時点のブックマークまたは特定のプラガブル・データベース(PDB)のSCNです。作成対象のPDBにのみ属しており、そのPDBの操作に対してのみ使用できます。PDBリストア・ポイントは、作成された特定の時点でのPDBサブインカネーションを表します。
PDBリストア・ポイントは、通常のリストア・ポイントまたは保証付きリストア・ポイントにもできます。保証付きPDBリストア・ポイントは、PDBに対してこのリストア・ポイントへのフラッシュバック操作を実行できることを保証します。
PDBリストア・ポイントは、それが作成されたPDBに対してのみフラッシュバック・データベース操作またはPoint-in-Timeリカバリを実行するのに使用できます。
ノート:
保証付きPDBリストア・ポイントの作成は、十分に注意する必要があります。そのようなリストア・ポイントは、マルチテナント・コンテナ・データベース(CDB)で必要とされているフラッシュバック・ログが再利用されるのを妨げる可能性があるためです。これによって、高速リカバリ・エリアの領域が足りなくなる可能性があるため、潜在的にCDB機能に影響を及ぼす可能性があります。クリーンPDBリストア・ポイント
クリーンPDBリストア・ポイントは、PDBがクローズされていて、そのPDBに未処理のトランザクションが存在しないときに作成されるPDBリストア・ポイントです。クリーンPDBリストア・ポイントは、共有UNDOを使用するCDBにのみ適用されます。
クリーンPDBリストア・ポイントは、通常のリストア・ポイントまたは保証付きリストア・ポイントにもできます。CREATE CLEAN RESTORE POINT
コマンドを使用して、クリーンPDBリストア・ポイントを明示的に作成します。共有UNDOを使用するCDBでは、PDBがクローズで未処理のトランザクションがない場合、作成されるPDBリストア・ポイントはすべてクリーンPDBリストア・ポイントとしてマーク付けされます。
PDBを特定の時点(アプリケーション・アップグレードの直前の状態など)に巻き戻す必要が出てくると予測する場合には、クリーンPDB保証付きリストア・ポイントを作成することをお薦めします。
共有UNDOを使用するCDBでは、クリーンPDBリストア・ポイントに対するフラッシュバック・データベース操作の方が、SCNまたはクリーンPDBリストア・ポイントではない他のリストア・ポイントへのフラッシュバック・データベース操作より高速です。これは、クリーンPDBリストア・ポイントへのフラッシュバック操作の実行中にはRMANがバックアップをリストアする必要がないからです。
7.1.6.3 PDBリストア・ポイントのネームスペースについて
各プラガブル・データベース(PDB)には、リストア・ポイント用に専用のネームスペースがあります。そのため、複数のPDBで同じ名前のPDBリストア・ポイントを定義できます。
マルチテナント環境では、PDB内でまたはPDB操作でリストア・ポイント名を使用すると、最初に名前が当該PDBのPDBリストア・ポイントとして解釈されます。指定された名前のPDBリストア・ポイントが見つからない場合、CDBリストア・ポイントとして解釈されます。
関連項目:
7.2 フラッシュバック・データベースおよび保証付きリストア・ポイントのロギングについて
フラッシュバック・データベースおよび保証付きリストア・ポイントのロギングでは、変更が適用される前のデータファイル・ブロックのイメージを取得する必要があります。FLASHBACK DATABASE
コマンドでは、これらのイメージを使用して、データファイルを前の状態に戻すことができます。
通常のフラッシュバックのロギングと保証付きリストア・ポイントのロギングの主な違いは、ブロックをロギングするタイミング、および高速リカバリ領域で領域圧迫に応じてログを削除できるかどうかに関連しています。これらの違いは、ログに対する領域の使用状況およびデータベースのパフォーマンスに影響します。
リカバリ可能目標によって、フラッシュバック・データベースのロギングを有効にするかどうか、または保証付きリストア・ポイントを使用するかどうか、あるいはその両方を行うかどうかが部分的に決定されます。これらの機能を個別に使用した場合および同時に使用した場合のパフォーマンスおよび領域の使用状況への影響も、決定を行う場合の要因として考慮してください。
7.2.1 保証付きリストア・ポイントおよび高速リカバリ領域の領域使用状況
高速リカバリ領域内の領域の使用を制御する特定の規則があります。
保証付きリストア・ポイントを作成する場合は、フラッシュバック・データベースの完全なロギングを有効にしているかどうかに関係なく、高速リカバリ領域で使用可能な領域を監視する必要があります。高速リカバリ領域のディスク領域の使用状況を監視する方法については、「高速リカバリ領域でのフラッシュバック・ログの領域の管理」を参照してください。
次の規則によって、高速リカバリ領域でのフラッシュバック・ログの作成、保存、上書きおよび削除が制御されます。
-
フラッシュバック・ログは、高速リカバリ領域に十分な領域がある場合、フラッシュバック保存目標の達成に必要になると常に作成されます。
-
フラッシュバック・ログは、フラッシュバック保存目標の達成に不要になるほど古くなると、再利用されます。
-
データベースでフラッシュバック・ログを作成する必要がある場合に、高速リカバリ領域が一杯になるか、またはディスク領域がなくなると、かわりに最も古いフラッシュバック・ログが再利用されます。
ノート:
最も古いフラッシュバック・ログを再利用すると、フラッシュバック・データベース・ウィンドウは短くなります。ディスク領域の不足が原因で、多くのフラッシュバック・ログが再利用されると、フラッシュバック保存目標が達成されない場合があります。
-
高速リカバリ領域が一杯になると、他のファイル用の領域を確保するために、高速リカバリ領域規則に従って再利用可能なアーカイブREDOログが高速リカバリ領域によって自動的に削除される場合があります。この場合、
FLASHBACK DATABASE
を使用するために、そのREDOログ・ファイルを使用する必要があるフラッシュバック・ログも削除されます。ノート:
高速リカバリ領域規則では、次のいずれかの条件が満たされた場合にファイルが再利用可能となります。
-
ファイルは、不要およびフラッシュバック・データベースで必要なしとしてレポートされます。たとえば、ファイルは
DB_FLASHBACK_RETENTION_TARGET
パラメータの範囲外となります。 -
このファイルはテープにバックアップされます。
-
-
高速リカバリ領域内のファイルは、保証付きリストア・ポイントを満たすために必要な場合は削除対象になりません。保証付きリストア・ポイントを満たすために必要なアーカイブREDOログは、ディスクまたはテープにバックアップ後に削除できる場合があります。RMAN
FLASHBACK DATABASE
コマンドを使用する際に、指定した保証付きリストア・ポイントを満たすために必要なアーカイブREDOログが高速リカバリ領域で使用できない場合は、それらはバックアップからリストアされます。バックアップ保存方針を満たすために必要なファイルに加えて、保証付きリストア・ポイントを満たすために必要なフラッシュバック・ログおよびその他のファイルを保存すると、高速リカバリ領域が完全に一杯になる場合があります。高速リカバリ領域が一杯になった場合は、「高速リカバリ領域が一杯になった場合の対応」を参照してください。
注意:
保存方針の要件および保証付きリストア・ポイントのため、高速リカバリ領域からの削除対象となるファイルがない場合、データベースはディスクが一杯になった場合と同様に動作します。多くの場合、これによってデータベースは停止します。「高速リカバリ領域が一杯になった場合の対応」を参照してください。
7.2.2 フラッシュバック・ロギングが無効になっている状態での保証付きリストア・ポイントのロギングについて
フラッシュバック・データベースのロギングが無効になっているときに保証付きリストア・ポイントを作成するとします。この場合、保証付きリストア・ポイントの時点以降にデータファイル・ブロックが初めて変更されると、データベースによって、変更前のブロックのイメージがフラッシュバック・ログに格納されます。このため、フラッシュバック・ログには、保証付きリストア・ポイントが作成された時点で変更されているすべてのデータ・ブロックの内容が保持されます。同じブロックに対するこれ以降の変更では、そのブロックが最後に変更されてから別の保証付きリストア・ポイントが作成されない、または以降のフラッシュバック・データベース操作がブロックの元のコンテンツにリストアされないかぎり、その内容が再度ロギングされることはありません。フラッシュバック・データベースを使用してデータベースを同じリストア・ポイントに複数回リストアする場合、保証付きリストア・ポイントを毎回削除して再作成するのが一般的です。これにより古いフラッシュバック・ログは削除され、高速リカバリ領域の領域割当て制限を超えないことも保証されます。
このロギング方法には、次の重要な効果があります。
-
FLASHBACK DATABASE
を使用すると、ブロック・イメージを使用して、保証付きリストア・ポイントの時点でのデータファイルの内容を再作成できます。 -
同じデータを繰り返し変更するワークロードでは、ディスク領域の使用量が、通常のフラッシュバック・ロギングより少なくなる可能性があります。変更された各ブロックは1回のみロギングされるため、必要な領域が少なくなります。このディスク領域の節約は、小さいボリュームが挿入されたアプリケーションでは有効な場合があります。大きいボリュームまたは大きいバッチが挿入されたアプリケーションでは、このメリットはあまりありません。また、フラッシュバック・データベース・ロギングを行わずに保証付きリストア・ポイントをロギングした場合のパフォーマンスのオーバーヘッドも小さくなる可能性があります。
保証付きリストア・ポイントが作成された時点にデータベースを戻すことが第一の目標であるとします。この場合は、通常、フラッシュバック・ロギングを無効にして、保証付きリストア・ポイントのみを使用する方がより効率的です。たとえば、週末にデータベース・ホストに対してアプリケーション・アップグレードを実行するとします。アップグレードの開始時に、保証付きリストア・ポイントを作成します。アップグレードに失敗した場合は、FLASHBACK DATABASE
コマンドを使用して変更を無効にします。
7.2.3 保証付きリストア・ポイントが定義された状態でのフラッシュバック・データベースのロギングについて
フラッシュバック・データベースを有効にし、1つ以上の保証付きリストア・ポイントを定義すると、データベースで通常のフラッシュバック・ロギングが実行されます。
この場合、現時点と現在定義されている最も古い保証付きリストア・ポイントの間の任意の時点にフラッシュバックするために必要なフラッシュバック・ログが、リカバリ領域に保存されます。フラッシュバック・ログは、保証を実現するために必要な場合、領域圧迫に応じて削除されることはありません。
フラッシュバック・ロギングでは、パフォーマンスのオーバーヘッドが発生します。また、データベースでのアクティビティのパターンに応じて、高速リカバリ領域で著しい領域圧迫が発生する場合もあります。したがって、高速リカバリ領域で使用される領域を監視する必要があります。
7.3 フラッシュバック・データベースおよびリストア・ポイントの前提条件
フラッシュバック・データベースおよび保証付きリストア・ポイントの操作を正常に行うには、いくつかの重要なデータベース・オプションを最初に設定する必要があります。
フラッシュバック・データベース
フラッシュバック・データベースを有効にする前に、次のデータベース設定を構成します。
-
フラッシュバック・データベースの操作ではアーカイブ・ログが使用されるため、データベースを
ARCHIVELOG
モードで実行している必要があります。 -
フラッシュバック・ログは高速リカバリ領域にのみ格納可能なため、高速リカバリ領域を有効にする必要があります。
-
Oracle Real Application Clusters(Oracle RAC)データベースの場合、高速リカバリ領域はクラスタ・ファイル・システムまたはASM内にある必要があります。
-
CDBでリストア・ポイントを作成するには、
COMPATIBLE
初期化パラメータを12.1.0以上に設定する必要があります。
保証付きリストア・ポイント
保証付きリストア・ポイントを使用するには、データベースが追加の前提条件を満たす必要があります。つまり、COMPATIBLE
初期化パラメータが10.2.0以上に設定されている必要があります。
ノート:
通常のリストア・ポイントを使用する場合は、設定が必要な特別な前提条件はありません。
7.4 通常のリストア・ポイントと保証付きリストア・ポイントの使用
通常のリストア・ポイントと保証付きリストア・ポイントの両方を作成、監視および削除できます。
この項では、次の項目について説明します。
7.4.1 非CDBにおける通常のリストア・ポイントと保証付きリストア・ポイントの作成
通常のリストア・ポイントまたは保証付きリストア・ポイントを作成するには、SQL文CREATE RESTORE POINT
を使用します。このとき、リストア・ポイントの名前を入力し、それを保証付きリストア・ポイントにするか通常のリストア・ポイント(デフォルト)にするかを指定します。
リストア・ポイントを作成するには:
関連項目:
-
SQLの
CREATE RESTORE POINT
文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください -
リストア・ポイントのリスト方法を学習するには、「LISTコマンドを使用したリストア・ポイントの表示」を参照してください
-
リストア・ポイントを削除する方法を学習するには、「リストア・ポイントの削除」を参照してください。
7.4.2 CDBリストア・ポイントの作成
CREATE RESTORE POINT
SQLコマンドによって、マルチテナント・コンテナ・データベース(CDB)に、通常のリストア・ポイントおよび保証付きリストア・ポイントを作成することができます。
CDBリストア・ポイントを作成するには:
関連項目:
-
SQL*Plusをルートに接続するステップについては、Oracle Database管理者ガイドを参照してください。
7.4.3 PDBリストア・ポイントの作成
CREATE RESTORE POINT
SQL文を使用して、プラガブル・データベース(PDB)にリストア・ポイントを作成します。
PDBに接続しているときにPDBリストア・ポイントを作成するには:
-
「フラッシュバック・データベースおよびリストア・ポイントの前提条件」の説明に従って前提条件が満たされていることを確認します。
-
SQL*Plusを、
SYSDBA
またはSYSBACKUP
権限を持つ共通ユーザーまたはローカル・ユーザーとしてPDBに接続します。 -
共有UNDOを使用するCDBにクリーンPDBリストア・ポイントを作成している場合、PDBはクローズしておく必要があります。
次のコマンドでは、PDBの状態が表示されます。
SQL> SELECT name, open_mode FROM V$PDBs;
次のコマンドを使用して、PDBをクローズします。
SQL> ALTER PLUGGABLE DATABASE CLOSE;
-
マルチテナント・コンテナ・データベース(CDB)がマウント状態の場合、一貫性のある状態で停止する必要があります(フィジカル・スタンバイ・データベース以外の場合)。
-
現在のコンテナを、PDBに設定します。
次のコマンドは、現在のコンテナをPDB
my_pdb
に設定します。SQL> ALTER SESSION SET CONTAINER=my_pdb;
-
CREATE RESTORE POINT
コマンドを使用してPDBリストア・ポイントを作成します。次のコマンドは、通常のPDBリストア・ポイントを作成します。
SQL> CREATE RESTORE POINT before_patching;
次のコマンドは、保証付きPDBリストア・ポイントを作成します。
SQL> CREATE RESTORE POINT before_upgrade GUARENTEE FLASHBACK DATABASE;
次のコマンドは、明示的にクリーンPDBリストア・ポイントを作成します。クリーン・リストア・ポイントを作成できない場合、エラーが戻されます。
SQL> CREATE CLEAN RESTORE POINT before_patching;
CDBに接続しているときにPDBリストア・ポイントを作成するには:
関連項目:
-
SQL*Plusをルートに接続するステップについては、Oracle Database管理者ガイドを参照してください。
7.4.4 LISTコマンドを使用したリストア・ポイントの表示
LIST
コマンドを使用して、特定のリストア・ポイント、またはRMANリポジトリで認識されるすべてのリストア・ポイントを表示できます。このコマンドの例を次に示します。
LIST RESTORE POINT restore_point_name;
LIST RESTORE POINT ALL;
RMANは、リストア・ポイントのSCNおよび時刻、リストア・ポイントのタイプおよびリストア・ポイントの名前を表示します。出力例を次に示します。
RMAN> LIST RESTORE POINT ALL; using target database control file instead of recovery catalog SCN RSP Time Type Time Name ---------------- --------- ---------- --------- ---- 341859 28-APR-15 28-APR-15 NORMAL_RS 343690 28-APR-15 GUARANTEED 28-APR-15 GUARANTEED_RS
ノート:
LIST
コマンドは、PDBインカネーション番号やリストア・ポイントがPDBリストア・ポイントであるかなどの詳細は表示しません。マルチテナント環境におけるリストア・ポイントの追加詳細を表示するには、「V$RESTORE_POINTビューを使用したリストア・ポイントのリスト」を参照してください。
7.4.5 V$RESTORE_POINTビューを使用したリストア・ポイントの表示
V$RESTORE_POINT
コントロール・ファイル・ビューを使用して、CDBリストア・ポイントおよびPDBリストア・ポイントを含む、すべての現在定義されているリストア・ポイント(通常および保証付き)に関する情報を取得できます。
V$RESTORE_POINT
ビューには、LIST RESTORE POINT
コマンドでは表示されない、マルチテナント環境のリストア・ポイントに関する追加情報が含まれています。これには、PDBリストア・ポイントが作成されたプラガブル・データベース(PDB)のインカネーションやリストア・ポイントがPDBリストア・ポイントかクリーンPDBリストア・ポイントかなどの詳細が含まれます。
次のステップにより、CDB内のすべてのPDBに対するPDBリストア・ポイントに関する情報を表示します。
例7-1 マルチテナント環境でのリストア・ポイントの表示
次の問合せは、マルチテナント環境におけるすべてのリストア・ポイントに関する詳細を表示します(問合せ出力はページに収まるように形式が設定されています)。
SELECT name, guarantee_flashback_database, pdb_restore_point, clean_pdb_restore_point, pdb_incarnation#, storage_sizeFROM v$restore_point;
NAME GUARANTEE_ PDB_RESTORE_POINT CLEAN_PDB_RESTORE_POINT STORAGE_SIZE -------- ---------- ---------------- ----------------------- ------------ CDB_GRP_BEFORE_PATCH YES NO NO 84586 PDB_GRP_BEFORE_UPGRADE_TEMP YES YES NO 4562 CDB_RP1 NO NO NO 0 PDB1_BEFORE_PATCHING NO YES NO 0 MYPDB_CLEAN_GRP_BEFORE_UPGRADE NO YES YES 0
通常のリストア・ポイントの場合、STORAGE_SIZE
が0(ゼロ)になります。保証付きリストア・ポイントの場合、STORAGE_SIZE
は、高速リカバリ領域のディスク領域の大まかなバイト数を示します。この領域は、そのリストア・ポイントに対するFLASHBACK
DATABASE
を保証するために必要なログの保持用に確保されます。
関連項目:
-
V$RESTORE_POINT
の詳細は、Oracle Databaseリファレンスを参照してください。
7.4.6 リストア・ポイントの削除
既存のリストア・ポイントが不要であることを確認した場合、または既存のリストア・ポイントの名前を使用してリストア・ポイントを作成する必要がある場合は、SQL*Plus文DROP RESTORE POINT
を使用して、リストア・ポイントを削除できます。
次に例を示します。
SQL> DROP RESTORE POINT before_app_upgrade;
Restore point dropped.
通常のリストア・ポイントおよび保証付きリストア・ポイントの両方の削除に、同じ文を使用します。
ノート:
通常のリストア・ポイントは、明示的に削除しなくても、最終的には制御ファイルからエージ・アウトされます。制御ファイル内のリストア・ポイントは、次の規則に基づいて保存されます。
-
最新の2048個のリストア・ポイントは、その保存期間に関係なく、常に制御ファイルに保存されます。
-
CONTROL_FILE_RECORD_KEEP_TIME
の値よりも新しいリストア・ポイントは、定義されているリストア・ポイント数に関係なく、いずれも保持されます。
これらの条件のどちらも満たさない通常のリストア・ポイントは、制御ファイルからエージ・アウトされる可能性があります。
保証付きリストア・ポイントは制御ファイルからエージ・アウトされません。明示的に削除されるまで残ります。
関連項目:
SQLのDROP RESTORE POINT
文の詳細は、Oracle Database SQL言語リファレンスを参照してください。
7.5 フラッシュバック・データベースの使用
ターゲット・データベースでフラッシュバック・ロギングを使用するには、フラッシュバック・データベースを有効にする必要があります。特定のガイドラインに従って、フラッシュバック・データベースのパフォーマンスを最適化することができます。
この項では、次の項目について説明します。
7.5.1 フラッシュバック・データベースの有効化
ALTER DATABASE
コマンドを使用して、フラッシュバック・データベースを有効にします
フラッシュバック・ロギングを有効にするには:
データベースをオープンした状態でフラッシュバック・データベースを有効にする場合、まれに、コマンドが必要なメモリーを取得できないことがあります。この理由でコマンドが失敗した場合、しばらくしてからコマンドを再試行するか、インスタンスを停止し再起動してからコマンドを再試行します。
フィジカル・スタンバイ・データベースでフラッシュバック・データベースを有効にすると、スタンバイ・データベースをフラッシュバックできます。スタンバイ・データベースのフラッシュバック・データベースには、Data Guard環境で使用可能ないくつかのアプリケーションがあります。
関連項目:
スタンバイ・データベースの詳細は、Oracle Data Guard概要および管理を参照してください。
7.5.2 フラッシュバック・データベースのロギングの無効化
ALTER DATABASE
コマンドを使用して、フラッシュバック・データベースを無効にします。
マウントまたはオープンされた状態のいずれかのデータベース・インスタンスで、次のコマンドを発行します。
ALTER DATABASE FLASHBACK OFF;
7.5.3 最適なフラッシュバック・データベースのパフォーマンスのための環境の構成
フラッシュバック・ログをメンテナンスすると、データベース・インスタンスで発生するオーバーヘッドが比較的制限されます。変更されたブロックがメモリーからフラッシュバック・ログに比較的低い頻度で定期的に書き込まれ、プロセスおよびI/Oオーバーヘッドが制限されます。
フラッシュバック・データベースが有効になっている大規模な本番データベースのパフォーマンスを向上させるには、次のガイドラインに従うことをお薦めします。
-
高速リカバリ領域には、可能な場合、オペレーティング・システムのファイル・キャッシュを使用せずに高速なファイル・システムを使用します。
通常、データベースによって高速リカバリ領域に作成されるファイル(フラッシュバック・ログなど)は、サイズが大きくなります。オペレーティング・システムのファイル・キャッシュは、通常、これらのファイルに対しては有効ではなく、実際には、このファイル・キャッシュによって、これらのファイルに対する読取り/書込みを行った場合のCPUオーバーヘッドが増加する場合があります。したがって、オペレーティング・システムのファイル・キャッシュが行われないAutomatic Storage Management (ASM)などのファイル・システムを使用することをお薦めします。
-
高速リカバリ領域を保持するファイル・システムに、十分なディスク・スピンドルを構成します。
大規模な本番データベースでは、データベースでフラッシュバック・ログを効果的に書き込むために必要となるディスク・スループットをサポートするために、複数のディスク・スピンドルが必要な場合があります。
-
高速リカバリ領域の保持に使用されるストレージ・システムに非揮発性RAMがない場合は、ストライプ化されたストレージ・ボリュームにファイル・システムを構成します。
比較的小さなストライプ・サイズ(128KBなど)を使用します。この方法では、フラッシュバック・ログへのそれぞれの書込みを複数のスピンドルに分散することによって、パフォーマンスを向上できます。
-
大規模なデータベースでは、初期化パラメータ
LOG_BUFFER
を8MB以上に設定します。
フラッシュバック・データベースのロギングで発生するオーバーヘッドは、データベース・ワークロードでの読取りと書込みの組合せによって異なります。ワークロードが書込み集中型の場合、データベースのすべての変更を記録する必要があるため、フラッシュバック・データベースのロギングのオーバーヘッドが増加します。問合せによってデータは変更されないため、フラッシュバック・データベースのロギング・アクティビティには影響しません。
7.5.4 フラッシュバック・データベースのパフォーマンスに対する影響の監視
システム上のフラッシュバック・データベースのワークロードを監視するために、複数のデータ分析方法が提供されています。
-
AWRレポート
自動ワークロード・リポジトリ(AWR)では、データベースの問題検出および自己チューニングのためにパフォーマンス統計の収集、処理および保持を行うことによって、データベースの統計収集が自動化されています。フラッシュバック・データベースを有効にする前と後でAWRレポートを比較して、パフォーマンスの影響を監視できます。
-
AWRスナップショット
AWRスナップショットを参照して、フラッシュバック・ロギングによって発生するシステムの使用状況を明確にすることができます。たとえば、
flashback buf free by RVWR
が最上位の待機イベントとして表示されている場合は、Oracle Databaseではフラッシュバック・ログへの迅速な書込みを行うことができないことを示しています。したがって、「最適なフラッシュバック・データベースのパフォーマンスのための環境の構成」で説明したいずれかの方法で、高速リカバリ領域に使用されているファイル・システムおよび記憶域をチューニングすることをお薦めします。 -
V$FLASHBACK_DATABASE_STAT
ビューV$FLASHBACK_DATABASE_STAT
ビューには、データベースによって記録されたフラッシュバック・データのバイト数が表示されます。ビューの各行には、(通常は1時間にわたって)累積された統計が表示されます。FLASHBACK_DATA
およびREDO_DATA
列には、一定期間中に書き込まれたフラッシュバック・データおよびREDOデータのバイト数がそれぞれ示されます。DB_DATA
列には、読取りおよび書込みが行われたデータ・ブロックのバイト数が示されます。FLASHBACK_DATA
およびREDO_DATA
列は順次書込みに対応し、DB_DATA
列はランダム読取りおよび書込みに対応しています。 -
V$SYSSTAT
ビュー順次I/OとランダムI/Oの違いのため、I/Oオーバーヘッドは、フラッシュバック・ログに対して発行されたI/O操作の数によってより明確に示されます。表7-1に示す
V$SYSSTAT
統計は、様々な目的のためにインスタンスによって発行されたI/O操作の数を示しています。
表7-1 V$SYSSTAT統計
列名 | 列の意味 |
---|---|
physical write I/O request |
データ・ブロックの書込みのために発行された書込み操作の数 |
Physical read I/O request |
データ・ブロックの読取りのために発行された読取り操作の数 |
Redo writes |
REDOログへの書込みのために発行された書込み操作の数 |
Flashback log writes |
フラッシュバック・ログへの書込みのために発行された書込み操作の数 |
Flashback log write bytes |
このインスタンスから書き込まれたフラッシュバック・データベース・データの合計バイト・サイズ |
関連項目:
-
V$SYSSTAT
ビューの列の詳細は、Oracle Databaseリファレンスを参照してください。 -
AWRについて学習するには、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください
-
AWRレポートの詳細は、Oracle Database 2日でパフォーマンス・チューニング・ガイドを参照してください。
7.5.5 I/Oエラーが発生した場合のフラッシュバック・ライター(RVWR)の動作について
フラッシュバックが有効になっている場合、または保証付きリストア・ポイントが存在する場合は、バックグラウンド・プロセスRVWRによって、高速リカバリ領域内のフラッシュバック・データベース・ログにフラッシュバック・データが書き込まれます。
RVWRでI/Oエラーが発生した場合は、次の動作が予測されます。
-
保証付きリストア・ポイントが定義されている場合は、RVWRでI/Oエラーが発生すると、インスタンスで障害が発生します。
-
保証付きリストア・ポイントが定義されていない場合は、RVWRでI/Oエラーが発生しても、インスタンスは影響を受けません。ただし、次の場合に注意してください。
-
プライマリ・データベースでは、データベースをオープンしている間はフラッシュバック・データベースが自動的に無効になります。既存のすべてのトランザクションおよび問合せは、影響を受けずに続行されます。これは、シングル・インスタンス・データベースおよびOracle RACデータベースの両方で予測される動作です。
-
フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースでは、RVWRが応答を停止してI/Oを定期的に再試行しているように見えます。最終的に、これによってロジカル・スタンバイ・データベース、またはフィジカル・スタンバイ・データベースの管理リカバリが一時停止する場合があります。(Oracle Databaseでは、スタンバイ・インスタンスの障害は発生しません。最大保護モードでプライマリ・データベースの障害が発生しないようにするためです)。この問題を解決するには、
SHUTDOWN ABORT
またはALTER DATABASE FLASHBACK OFF
コマンドを発行します。
-