Oracle FlashBackの概要
9566 ワード
概要
Flashbackデータベースは、時点(PIT)データベースのリカバリ方法です.この不完全なリカバリポリシーは、人為的なエラーによって論理的に破損したデータベースをリカバリするために使用できます.10 gに導入した後、その設計目標は、リカバリ時間を短縮して最大の可用性を得ることである.この記事では、Flashbackデータベースを探求し、従来のリカバリ方法と比較し、再現リカバリの構成と実行方法を説明します.
従来のリカバリvs.データベースの再生
ダウンタイムの最初の原因は、人為的なエラーによる論理的な破損であることが広く認められている.論理的破損の例については,ユーザの不正なデータ更新や切り取りテーブルから,バッチタスクのエラー実行まで2回,あるいは順序を乱すことが多い.結果は同じです.データベースが破損し、範囲が広く認識しにくいです.Oracleでは、2つのポリシーを使用して、従来のリカバリとデータベースの再生のいずれかの時点にデータベースを戻します.
不完全なリカバリは、データベースが以前の状態にリカバリされたリカバリです.このプロセスには、データを再格納し、トランザクション・アクティビティを目的の時間までリカバリする2つのステップがあります.従来のリカバリと再生データベースの主な違いは、従来のリカバリがすべてのデータファイルを再格納してから所望のリカバリ時間にリカバリされ、再生データベースは破損した後に変更されたブロックを再格納することによって後方に操作されることです.この観点から考えると、10 TBのデータベースで1 MBのデータが破損していることを考えてみましょう.従来のリカバリは、10 TBのアプリケーションデータの再格納を開始することから始まり、再生データベースは、この1 MBのアプリケーションデータを取り戻し、破損前の点に達する.それぞれの戦略を見てみましょう
従来のリカバリ
Oracle 10 gの前に、人為的なエラーによって問題になったデータベースを以前の時点にリカバリする唯一のオプションは、従来のリカバリです.このポリシーには、バックアップからすべてのデータベース・データ・ファイルを取り出して再格納し、目的の時点に戻ることが含まれます.メディアリカバリは、サーバ(RMAN)に基づいてもよいし、ユーザ(オペレーティングシステムツール)に基づいてもよい.
次の図は、この複雑でコストが高く、効率が極めて低いマルチステップリカバリポリシーを示しています.
498)this.style.width=498;">
ユーザーがSQLを実行し、データベースを破損した場合を見てみましょう.ユーザーはコマンドセンターに通知し、エラーを報告しました.システムアナリストは、会社の異なる部門の他の人と協議して今回の事件を管理しています.リカバリは、バックアップからすべてのデータファイルを再格納し、redoログを所望の時点にロールバックすることによって完了します.リカバリ時間は、リカバリが必要な変更の数ではなく、データベースの規模に比例します.これは、リカバリ時間(MTTR)が実際にデータベースの規模とともに増加していることを意味します.
データベースの再生
Oracle 10 gでは、Flashback Database(データベースの再生)と呼ばれる新しい再生技術特性が、従来のリカバリの代替品として導入されています.データベースを再現すると、バックアップからデータベースを再保存することなく、データベース全体を以前の時点に迅速にリカバリできます.データベースでは、変更されたデータ・ブロックを希望するリカバリ時間までリカバリするだけで、逆転ボタンとしてよく記述されます.その後、Redo変更レコードを適用して、所望のリカバリポイントを達成します.この変更されたデータブロックを再生ログと呼びます.
データベースの再現は、従来のデータベースに比べて非常に顕著な利点を提供します.分析型データベースでは、このような明らかなメリットはありません.データ・ウェアハウスでは、ブロックの操作は通常、ログを記録しないモードで実行されます.再生データベースでは、データベースがドキュメント・ログ・モードで実行されている限り、変更されたブロックはリカバリによって実行された操作を取り消すことができるため、ブロック操作の前の状態に戻ることができます.
注:再現データベースはデータベースに統合されていますが、OracleのExpress Edition(XE)では使用できません.
498)this.style.width=498;">
ここでは、ユーザーがSQLを実行し、データベースを破損した場合を見てみましょう.ユーザーは、データベースの再生コマンドを実行し、破損する前のポイントに自動的にリカバリするアプリケーション・データベース管理者に通知します.変更されたデータのみに対して操作されるため、データベースの再生が速くなります.再現された時間は、データベースの規模に関係なく、エラーが発生した数に関係します.
再生データベースの構成
次の例では、コマンドライン構成を示します.これはエンタープライズマネージャで行うこともできます.
再現データベースを構成する前に、次の前提条件を考慮する必要があります.
Flash Recovery Area
まず、Flash Recovery Area(FRA)を構成する必要があります.10 gでは新しいもので、FRAは関連ファイルを復元するディスクの位置付けにすぎません.再生データベースの場合、Recovery Writer(RVWR)という新しいバックグラウンドプロセスがあり、SGAからのデータベースがキャッシュされたイメージを再生する前に、FRAの再生ログとしてディスクに段階的に書き込まれる.再現ログはFRAでOracleデータベースによって自動的に管理されます.
ログの再生コストは、スペースとパフォーマンスで測定されます.スペースは、データベースの書き込み密度の要因です.24時間稼働し、5%のデータ・ブロックで再生ログに書き込むことで、ディスク全体の5%の増加が必然的に発生します.ブロックはトランザクションの一部ではなく規則的な間隔で書き込まれるため、パフォーマンスへの影響は無視できます.
FRAを構成するには、次の初期化パラメータを設定する必要があります.
アーカイブ
次に、アーカイブを構成する必要があります.もう一度、ドキュメントログの宛先としてFRAを使用する必要があります.従来のリカバリと同様に、リカバリ・データベースは、コミットされたトランザクションを前にリカバリするためにアーカイブする必要があります.リカバリ・ログが所望の時間前に再保存された時点以降です.
構成アーカイブを最小化するには、次のコマンドを実行します.
データベースの再生
これらの前提条件を構成した後、再現データベースを構成する準備ができています.
まず、再生保持ターゲットを設定する必要があります.この初期化パラメータは、データベースをどのくらい前に戻すことができるかを表す分で計算されます.この値は、FRAで再生されるログの数と期間を決定します.以下の例では、24時間に設定します.この保持期間を理解することは保証ではないことが重要です.FRAにスペースが必要な場合は、ログを再生すると、ターゲット保持ポイントより前のレコードが自動的に削除されます.後で、ログを再現する方法をFRAで維持することを保証します.保存期間の設定により、データベースを再生してアクティブ化できます.
データベースの例の再生
次の例は、単一のテーブル以外の破損を説明するために使用されます.
10 gR 1では、データベースのPIT:タイムスタンプとシステム変更番号(SCN)をキャプチャする2つの選択肢があります.この情報は再生動作の一部として要求される.データ管理言語の操作ではなく、コミットされたSCNをキャプチャするか、後で重要です.Oracleは、userenv('commitscn')関数を使用してコミットされたSCNをキャプチャするための比較的不器用な方法を提供します.我々の例では、破損したデータ管理言語操作が発生する前に、この情報をキャプチャした.
select current_scn from v$database;
10 gR 2では、このプロセスは再ストレージポイントによって簡略化されています.再ストレージポイントは、タイムスタンプまたはSCNで使用できるデータベースPITに関連付けられたユーザー定義の名前です.再記憶ポイントはredo履歴の参照タグであると考えられる.再記憶ポイントは、再記憶ポイントが削除されるか、ログが削除されるまで制御ファイルに保持されます.2つ目の例は、リカバリに対して再生データベースが使用可能であることを保証します.
または再記憶ポイントmy_を作成するrestrore_ポイントはデータベースの再現を保証する.
注意:再セーブポイントは、すべてのトランザクションがその時点でコミットされることを保証しません.DB 2のリレーショナル・データベース管理システムのサイレント・ポイントと混同するべきではありません.
アナログデータベースの破損
注:デフォルトでは、Oracleはクロック・レベルでSCNを取得します.もちろん、時計の中のすべての行には同じSCNがあります.行レベルのSCN検索をアクティブにし、CREATE TABLEコマンドでROWDEPENDENCIESキーワードを使用できます.
データベースの再生が可能であることを確認します.あなたが再現できる最初の時間を判断します.
再ストレージポイントがあるかどうかを判断します.
ここは興味のあるビューです.
データベースの再生
SQL*PlusまたはRMANで再現データベースを実行できます.データベースの再生は、ポイントを変更して再保存する時間に基づいて行うことができます.RMANは、オプションベースの追加のログ順序を提供します.
以前に作成した再セーブポイントを使用して、データベースを再現します.
警告ログでのデータベース・メッセージの再表示の確認
データベースが所望の状態に復元されていることを確認します.満足していない場合は、再び再現し、完全なリカバリが実行されるまでデータベースを前に復元できます.recover database.注意:RESETLOGSでは、データベースの再生を実行できます.
一般的な用途のデータベースを開く
リカバリに満足したら、一般的な用途のためにデータベースを開きます.
結論
データベースの再現は、私の最も好きなOracle 10 gプロパティの1つになります.このプロパティは、ユーザーのエラーを修正したかどうかにかかわらず、以前のデータベースのステータスを確認するか、衰退したテストの後にテスト環境に戻るかにかかわらず、リカバリ時間を短縮する最善のポリシーです.私たちはこの技術が使いやすく、伝統的な回復よりも速く、最も良いのは無料であることを見ました.データベースの再現が可用性アーキテクチャの主要なコンポーネントであることも考えてほしい.
Flashbackデータベースは、時点(PIT)データベースのリカバリ方法です.この不完全なリカバリポリシーは、人為的なエラーによって論理的に破損したデータベースをリカバリするために使用できます.10 gに導入した後、その設計目標は、リカバリ時間を短縮して最大の可用性を得ることである.この記事では、Flashbackデータベースを探求し、従来のリカバリ方法と比較し、再現リカバリの構成と実行方法を説明します.
従来のリカバリvs.データベースの再生
ダウンタイムの最初の原因は、人為的なエラーによる論理的な破損であることが広く認められている.論理的破損の例については,ユーザの不正なデータ更新や切り取りテーブルから,バッチタスクのエラー実行まで2回,あるいは順序を乱すことが多い.結果は同じです.データベースが破損し、範囲が広く認識しにくいです.Oracleでは、2つのポリシーを使用して、従来のリカバリとデータベースの再生のいずれかの時点にデータベースを戻します.
不完全なリカバリは、データベースが以前の状態にリカバリされたリカバリです.このプロセスには、データを再格納し、トランザクション・アクティビティを目的の時間までリカバリする2つのステップがあります.従来のリカバリと再生データベースの主な違いは、従来のリカバリがすべてのデータファイルを再格納してから所望のリカバリ時間にリカバリされ、再生データベースは破損した後に変更されたブロックを再格納することによって後方に操作されることです.この観点から考えると、10 TBのデータベースで1 MBのデータが破損していることを考えてみましょう.従来のリカバリは、10 TBのアプリケーションデータの再格納を開始することから始まり、再生データベースは、この1 MBのアプリケーションデータを取り戻し、破損前の点に達する.それぞれの戦略を見てみましょう
従来のリカバリ
Oracle 10 gの前に、人為的なエラーによって問題になったデータベースを以前の時点にリカバリする唯一のオプションは、従来のリカバリです.このポリシーには、バックアップからすべてのデータベース・データ・ファイルを取り出して再格納し、目的の時点に戻ることが含まれます.メディアリカバリは、サーバ(RMAN)に基づいてもよいし、ユーザ(オペレーティングシステムツール)に基づいてもよい.
次の図は、この複雑でコストが高く、効率が極めて低いマルチステップリカバリポリシーを示しています.
498)this.style.width=498;">
ユーザーがSQLを実行し、データベースを破損した場合を見てみましょう.ユーザーはコマンドセンターに通知し、エラーを報告しました.システムアナリストは、会社の異なる部門の他の人と協議して今回の事件を管理しています.リカバリは、バックアップからすべてのデータファイルを再格納し、redoログを所望の時点にロールバックすることによって完了します.リカバリ時間は、リカバリが必要な変更の数ではなく、データベースの規模に比例します.これは、リカバリ時間(MTTR)が実際にデータベースの規模とともに増加していることを意味します.
データベースの再生
Oracle 10 gでは、Flashback Database(データベースの再生)と呼ばれる新しい再生技術特性が、従来のリカバリの代替品として導入されています.データベースを再現すると、バックアップからデータベースを再保存することなく、データベース全体を以前の時点に迅速にリカバリできます.データベースでは、変更されたデータ・ブロックを希望するリカバリ時間までリカバリするだけで、逆転ボタンとしてよく記述されます.その後、Redo変更レコードを適用して、所望のリカバリポイントを達成します.この変更されたデータブロックを再生ログと呼びます.
データベースの再現は、従来のデータベースに比べて非常に顕著な利点を提供します.分析型データベースでは、このような明らかなメリットはありません.データ・ウェアハウスでは、ブロックの操作は通常、ログを記録しないモードで実行されます.再生データベースでは、データベースがドキュメント・ログ・モードで実行されている限り、変更されたブロックはリカバリによって実行された操作を取り消すことができるため、ブロック操作の前の状態に戻ることができます.
注:再現データベースはデータベースに統合されていますが、OracleのExpress Edition(XE)では使用できません.
498)this.style.width=498;">
ここでは、ユーザーがSQLを実行し、データベースを破損した場合を見てみましょう.ユーザーは、データベースの再生コマンドを実行し、破損する前のポイントに自動的にリカバリするアプリケーション・データベース管理者に通知します.変更されたデータのみに対して操作されるため、データベースの再生が速くなります.再現された時間は、データベースの規模に関係なく、エラーが発生した数に関係します.
再生データベースの構成
次の例では、コマンドライン構成を示します.これはエンタープライズマネージャで行うこともできます.
再現データベースを構成する前に、次の前提条件を考慮する必要があります.
Flash Recovery Area
まず、Flash Recovery Area(FRA)を構成する必要があります.10 gでは新しいもので、FRAは関連ファイルを復元するディスクの位置付けにすぎません.再生データベースの場合、Recovery Writer(RVWR)という新しいバックグラウンドプロセスがあり、SGAからのデータベースがキャッシュされたイメージを再生する前に、FRAの再生ログとしてディスクに段階的に書き込まれる.再現ログはFRAでOracleデータベースによって自動的に管理されます.
ログの再生コストは、スペースとパフォーマンスで測定されます.スペースは、データベースの書き込み密度の要因です.24時間稼働し、5%のデータ・ブロックで再生ログに書き込むことで、ディスク全体の5%の増加が必然的に発生します.ブロックはトランザクションの一部ではなく規則的な間隔で書き込まれるため、パフォーマンスへの影響は無視できます.
FRAを構成するには、次の初期化パラメータを設定する必要があります.
alter system set db_recovery_file_dest=
'C:/oracle/product/10.2.0/flash_recovery_area' scope=both;
alter system set db_recovery_file_dest_size = 10G scope=both;アーカイブ
次に、アーカイブを構成する必要があります.もう一度、ドキュメントログの宛先としてFRAを使用する必要があります.従来のリカバリと同様に、リカバリ・データベースは、コミットされたトランザクションを前にリカバリするためにアーカイブする必要があります.リカバリ・ログが所望の時間前に再保存された時点以降です.
構成アーカイブを最小化するには、次のコマンドを実行します.
SQL> startup mount
ORACLE instance started.
.
.
.
Database mounted.
SQL> alter database archivelog;
Database altered.
SQL> alter database open;
Database altered.
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 2
Next log sequence to archive 4
Current log sequence 4データベースの再生
これらの前提条件を構成した後、再現データベースを構成する準備ができています.
まず、再生保持ターゲットを設定する必要があります.この初期化パラメータは、データベースをどのくらい前に戻すことができるかを表す分で計算されます.この値は、FRAで再生されるログの数と期間を決定します.以下の例では、24時間に設定します.この保持期間を理解することは保証ではないことが重要です.FRAにスペースが必要な場合は、ログを再生すると、ターゲット保持ポイントより前のレコードが自動的に削除されます.後で、ログを再現する方法をFRAで維持することを保証します.保存期間の設定により、データベースを再生してアクティブ化できます.
SQL> startup mount;
ORACLE instance started.
.
.
.
Database mounted.
SQL> alter system set db_flashback_retention_target = 1440 scope=both;
System altered.
SQL> alter database flashback on;
Database altered.
SQL> alter database open;
Database altered.
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------
YESデータベースの例の再生
次の例は、単一のテーブル以外の破損を説明するために使用されます.
45. FRA
46. select name,space_limit,space_used, space_reclaimable from v$recovery_file_dest;
47.
48. NAME SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE
49. --------------------------------------------
50. C:/oracle/product/10.2.0/flash_recovery_area 2147483648 166646272 0
51.
52.
53. select * from v$flash_recovery_area_usage;
54.
55. FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
56. ------------ ------------------ ------------------------- ---------------
57. CONTROLFILE 0 0 0
58. ONLINELOG 0 0 0
59. ARCHIVELOG 7.38 0 29
60. BACKUPPIECE 0 0 0
61. IMAGECOPY 0 0 0
62. FLASHBACKLOG .38 0 1
63.
64. select c1, ora_rowscn from my_table;
65.
66. C1 ORA_ROWSCN
67. ---------- ----------
68. 1 1320954
69. 10 gR 1では、データベースのPIT:タイムスタンプとシステム変更番号(SCN)をキャプチャする2つの選択肢があります.この情報は再生動作の一部として要求される.データ管理言語の操作ではなく、コミットされたSCNをキャプチャするか、後で重要です.Oracleは、userenv('commitscn')関数を使用してコミットされたSCNをキャプチャするための比較的不器用な方法を提供します.我々の例では、破損したデータ管理言語操作が発生する前に、この情報をキャプチャした.
select current_scn from v$database;
CURRENT_SCN
-----------
1321065
or
select to_char(sysdate,'YYYY-MM-DD:HH24:MI:SS')
"Recover Time" from v$database;
Recover Time
-------------------
2006-09-23:20:13:4810 gR 2では、このプロセスは再ストレージポイントによって簡略化されています.再ストレージポイントは、タイムスタンプまたはSCNで使用できるデータベースPITに関連付けられたユーザー定義の名前です.再記憶ポイントはredo履歴の参照タグであると考えられる.再記憶ポイントは、再記憶ポイントが削除されるか、ログが削除されるまで制御ファイルに保持されます.2つ目の例は、リカバリに対して再生データベースが使用可能であることを保証します.
create restore point my_restore_point;
Operation 206 succeeded.または再記憶ポイントmy_を作成するrestrore_ポイントはデータベースの再現を保証する.
注意:再セーブポイントは、すべてのトランザクションがその時点でコミットされることを保証しません.DB 2のリレーショナル・データベース管理システムのサイレント・ポイントと混同するべきではありません.
アナログデータベースの破損
70.
71. insert into my_table values (2);
72.
73. 1 row created.
74.
75. commit;
76.
77.
78. 。
79. select c1, ora_rowscn from my_table;
80.
81. C1 ORA_ROWSCN
82. ---------- ----------
83. 1 1320954
84. 2 1321231注:デフォルトでは、Oracleはクロック・レベルでSCNを取得します.もちろん、時計の中のすべての行には同じSCNがあります.行レベルのSCN検索をアクティブにし、CREATE TABLEコマンドでROWDEPENDENCIESキーワードを使用できます.
データベースの再生が可能であることを確認します.あなたが再現できる最初の時間を判断します.
SELECT OLDEST_FLASHBACK_SCN
,to_char(OLDEST_FLASHBACK_TIME,'YYYY-MM-DD:HH24:MI:SS')
"OLDEST_FLASHBACK_TIME"
FROM V$FLASHBACK_DATABASE_LOG;
OLDEST_FLASHBACK_SCN OLDEST_FLASHBACK_TI
-------------------- -------------------
1319629 2006-09-23:19:51:56再ストレージポイントがあるかどうかを判断します.
select name, scn, time from v$restore_point;
NAME SCN TIME
---------------- ---------- ----------------------------
MY_RESTORE_POINT 1321136 23-SEP-06 08.16.24.000000000 PMここは興味のあるビューです.
データベースの再生
SQL*PlusまたはRMANで再現データベースを実行できます.データベースの再生は、ポイントを変更して再保存する時間に基づいて行うことができます.RMANは、オプションベースの追加のログ順序を提供します.
以前に作成した再セーブポイントを使用して、データベースを再現します.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
.
.
.
Database mounted.
SQL> flashback database to restore point my_restore_point;
Flashback complete.警告ログでのデータベース・メッセージの再表示の確認
.
.
.
Sat Sep 23 20:38:11 2006
flashback database to restore point my_restore_point
Sat Sep 23 20:38:12 2006
Flashback Restore Start
Flashback Restore Complete
Flashback Media Recovery Start
parallel recovery started with 2 processes
Sat Sep 23 20:38:14 2006
Recovery of Online Redo Log: Thread 1 Group 2 Seq 33 Reading mem 0
Mem# 0 errs 0:
C:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO02.LOG
Sat Sep 23 20:38:16 2006
Incomplete Recovery applied until change 1321137
Flashback Media Recovery Complete
Completed: flashback database to restore point my_restore_pointデータベースが所望の状態に復元されていることを確認します.満足していない場合は、再び再現し、完全なリカバリが実行されるまでデータベースを前に復元できます.recover database.注意:RESETLOGSでは、データベースの再生を実行できます.
SQL> alter database open read only;
Database altered.
SQL> select c1, ora_rowscn from my_table;
C1 ORA_ROWSCN
---------- ----------
1 1321002一般的な用途のデータベースを開く
リカバリに満足したら、一般的な用途のためにデータベースを開きます.
SQL> shutdown;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
.
.
.
Database mounted.
SQL> alter database open resetlogs;
Database altered.結論
データベースの再現は、私の最も好きなOracle 10 gプロパティの1つになります.このプロパティは、ユーザーのエラーを修正したかどうかにかかわらず、以前のデータベースのステータスを確認するか、衰退したテストの後にテスト環境に戻るかにかかわらず、リカバリ時間を短縮する最善のポリシーです.私たちはこの技術が使いやすく、伝統的な回復よりも速く、最も良いのは無料であることを見ました.データベースの再現が可用性アーキテクチャの主要なコンポーネントであることも考えてほしい.