ポイント・イン・タイム・リカバリ
30305 ワード
データベースをポイント・イン・タイム・リカバリによってリカバリします.リカバリするターゲット時間より前のバックアップからデータベースを返すことができます.その後、インクリメンタル・バックアップとREDOログを使用してデータベースをターゲット・タイム・ポイントにロールアップします.ポイント・イン・タイム・リカバリは、あるログを使用しないか、データベースに対するすべての変更を完全にリカバリしないため、不完全リカバリと呼ばれます.
データベースが時点でリカバリする条件1.データベースはarchivelogモードで実行する必要があります.リカバリ・ターゲットの時点までのすべてのデータ・ファイルのバックアップと、バックアップSCNとターゲットSCNの間のすべてのアーカイブREDOログが必要です.
resetlogsオプションでデータベースを開くたびに、新しいデータベースincarnationが作成されます.Open resetlogs操作を実行すると、現在のオンラインREDOログファイルがアーカイブされます.incarnitionは、REDOログのシリアル番号を1に設定し、オンラインREDOログの新しいタイムスタンプを指します.また、incarnationのシーケンス番号も追加され、別のREDOログ・ストリームを一意にマークし、認識するために使用されます.
incarnationに存在する可能性のあるいくつかの関係1.Current incarnationはそのincarnationがopen resetlog操作を実行することによって生成され、そのincarnationはcurrent incarnationのparent incarnationである
2.parent incarnationとそのparent incarnationのincarnationをcurrent incarnationというancestor incarnations
3.2つのincarnationが同じancestorを共有している場合、それらはsibling incarnationsです.
ポイント・イン・タイム・リカバリを実行するには、次の2つの条件を用意する必要があります.1.リカバリするターゲット時間、SCN、リストアポイント、またはログ・シーケンス番号を決定します.フラッシュバック・クエリー、フラッシュバック・バージョン・クエリー、フラッシュバック・トランザクション・クエリーは、論理エラーを識別するのに役立ちます.alert.をチェックすることもできます.logの情報は、リカバリのターゲットポイントを判断するのに役立ちます.また,ターゲットSCNを含むログシーケンス番号を判断してログにより復元することも可能である.たとえば、v$log_のクエリhistoryは、アーカイブされたログ情報を表示します.
たとえば、午前10時1分にユーザーが誤って表領域を削除した場合、データベースを午前10時に復元できます.つまり、表領域を削除する前の時点です.回復後の午前10時以降のすべての変更は失われます.
2.ターゲットSCNの代わりにターゲット時間式を使用する場合は、RMANを使用する前に、時間フォーマットの環境変数の設定が適切であることを確認します.NLS_LANG=AMERICAN_AMERICA.ZHS16GBK NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS'
current incarnationを使用して、時点別リカバリを実行current incarnationを使用して時点別リカバリを実行する場合に使用される現在のバージョンの制御ファイルです.時点別リカバリを実行する場合は、restotreコマンドとrecoverコマンドでuntil句を個別に設定せずに、set untilコマンドを使用してリカバリのターゲット時間を設定し、エラーを回避できます.これにより、バックアップから復元されたデータファイルのタイムスタンプが、後続のrecover操作よりも早いことが保証されます.
ポイント・イン・タイム・リカバリの手順は、scottユーザーの下のテーブルempのすべてのレコードを削除し、削除する前に現在のシステムのSCNを記録し、ポイント・イン・タイム・リカバリを実行してテーブルのレコードをリカバリします.
1.ターゲット・データベースまたはリカバリ・ディレクトリに接続し、ある場合はmountステータスにデータベースを起動します.
2.RUNブロックを実行して、ポイント・イン・タイム・リカバリを実行します.RUNブロックでset untilを使用して、リカバリのターゲット時間、リストアポイント、SCNまたはログシーケンス番号を指定します.ターゲット時間を指定した場合は、NLS_を使用します.LANGとNLS_DATE_FORMAT環境変数で指定されたフォーマット.自動チャネルが構成されていない場合は、アクセスするディスクまたはテープにチャネルを割り当てます.
alertログファイルから次の情報が表示されます.
上記のリカバリ・プロセスから、まずバックアップからデータ・ファイルをリストアします.各データ・ファイルのcheckpoint scnは3142189で、リカバリ・ターゲットSCNよりも小さく、REDOログ・ファイルを適用してデータベースをターゲットSCNに対応する時点にリカバリします.
set untilはまた、リカバリターゲットの時点set until time'2015-02-04 11:22:29'として、リストアポイントまたはログシーケンスを使用することもできます.set until sequence 4; set until restore point before_delete;
ポイント・イン・タイムでリカバリに成功した場合.データベースを読み取り専用で開き、テーブルempのデータが復元されたかどうかを確認できます.テーブルempのレコードがリカバリされていない場合は、リカバリターゲットSCNを間違って選択した可能性があります.この場合、新しいリカバリターゲットSCNを使用して、ポイント・イン・タイム・リカバリを再実行できます.
以上の結果から,表empの記録は時点回復により取り戻したことが分かる.
時点別のリカバリが検証された後にリカバリ目標に達した場合、次の選択肢があります.1.Oracleエクスポートツールを使用して、リカバリしたテーブルempを論理的にエクスポートします.次に、データベースを現在の時点に復元してから、エクスポートされたデータをインポートします.これにより、データベースの他の変更が失われず、テーブルempのデータが復元されます.
2.データベースを読み書きで開きます.これにより、ターゲットSCNをリカバリした後の変更はすべて失われます.現在のオンラインREDOログ・ファイルはアーカイブされ、ログ・シーケンス番号は1に設定され、すべてのオンラインREDOログに新しいタイムスタンプとSCNが指定されます.
ancestor incarnationによるポイント・イン・タイム・リカバリancestor incarnationによるポイント・イン・タイム・リカバリとcurrent incarnationによるリカバリの違いは、データベースのincarnationを設定する必要がある点である.また、リカバリ対象SCNを含むincarnationから制御ファイルを復元する必要があります.
recover catalogを使用しない場合、たとえばscottユーザーのempテーブルが削除された時点にデータベースをリカバリし、older incarnationに対して時点別リカバリを実行する手順は、次のとおりです.
1.使用するincarnationを判断します.list incarnationコマンドを使用して、リカバリターゲット時間に対応するincarnationを見つけることができます.
現在のincarnationのInc Keyは14である.次のクエリでは、その前のincarnationのInc Keyが13であることがわかります.
2.データベースをmount状態に起動する
3.データベースtestのincarnationをincarnation番号13、すなわちcurrent incarnationのparent incarnationに設定します.
4.関連チャネル設定チャネルが構成されていない場合は、リストアとリカバリを実行し、リカバリターゲット時間を設定します.データベースをテーブルemp削除後の時点に復元します(2015-02-04 13:30:01):
recover catalogを使用する場合、たとえばscottユーザーのempテーブルが削除された時点にデータベースをリカバリし、older incarnationに対して時点別リカバリを実行する手順は、次のとおりです.
1.使用するincarnationを判断します.list incarnationコマンドを使用して、リカバリターゲット時間に対応するincarnationを見つけることができます.
現在のincarnationのInc Keyは188である.次のクエリでは、以前のincarnationのInc Keyは102であったことがわかります.データベースを2015-02-04 18:22:30、つまりSCN:415176とSCN:415481の間に復元します.
上記の制御ファイルバックアップ情報から、2015-02-04 18:22:30にリカバリする時点で制御ファイルバックアップを使用するべきであることがわかりますo 1_mf_s_870805363_bf3wqnyv_.bkp
2.データベースをnomount状態に強制的に起動する
3.データベースtestのincarnationをincarnation番号102、すなわちcurrent incarnationのparent incarnationに設定します.
4.関連チャネル設定チャネルが構成されていない場合は、リストアとリカバリを実行し、リカバリターゲット時間を設定します.制御ファイルを復元し、テーブルemp削除後の時点にデータベースを復元します(2015-02-04 18:22:30):
データファイルを2015-02-04 18:22:30に復元し、次にリカバリを実行します.リカバリ操作を実行する前にreset database to incarnation 102を実行する必要があります.そうしないと、エラーが発生することに注意してください.
reset database to incarnation 102を再実行する.
リカバリが完了した後の現在のincarnation対応reset scn号は415176と415481の間で、期待される結果に達していることがわかります.
「ITPUBブログ」からのリンク:http://blog.itpub.net/26015009/viewspace-1426636/転載する必要がある場合は、出典を明記してください.そうしないと、法律責任を追及します.
転載先:http://blog.itpub.net/26015009/viewspace-1426636/
データベースが時点でリカバリする条件1.データベースはarchivelogモードで実行する必要があります.リカバリ・ターゲットの時点までのすべてのデータ・ファイルのバックアップと、バックアップSCNとターゲットSCNの間のすべてのアーカイブREDOログが必要です.
resetlogsオプションでデータベースを開くたびに、新しいデータベースincarnationが作成されます.Open resetlogs操作を実行すると、現在のオンラインREDOログファイルがアーカイブされます.incarnitionは、REDOログのシリアル番号を1に設定し、オンラインREDOログの新しいタイムスタンプを指します.また、incarnationのシーケンス番号も追加され、別のREDOログ・ストリームを一意にマークし、認識するために使用されます.
incarnationに存在する可能性のあるいくつかの関係1.Current incarnationはそのincarnationがopen resetlog操作を実行することによって生成され、そのincarnationはcurrent incarnationのparent incarnationである
2.parent incarnationとそのparent incarnationのincarnationをcurrent incarnationというancestor incarnations
3.2つのincarnationが同じancestorを共有している場合、それらはsibling incarnationsです.
SQL> select * from v$database_incarnation;
INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TI PRIOR_RESETLOGS_CHANGE# PRIOR_RESETL STATUS RESETLOGS_ID PRIOR_INCARNATION# FLASHBACK_DATABASE_ALLOWED
------------ ----------------- ------------ ----------------------- ------------ ------- ------------ ------------------ --------------------------
1 1 30-JUN-05 0 PARENT 562360180 0 NO
2 446075 05-SEP-14 1 30-JUN-05 PARENT 857466832 1 NO
3 2849317 27-JAN-15 446075 05-SEP-14 PARENT 870102602 2 NO
4 2880152 27-JAN-15 2849317 27-JAN-15 PARENT 870133266 3 NO
5 3017109 01-FEB-15 2880152 27-JAN-15 PARENT 870550288 4 NO
6 3041066 01-FEB-15 3017109 01-FEB-15 PARENT 870563157 5 NO
7 3041350 01-FEB-15 3041066 01-FEB-15 PARENT 870564201 6 YES
8 3111834 03-FEB-15 3041350 01-FEB-15 ORPHAN 870724654 7 YES
9 3111834 03-FEB-15 3041350 01-FEB-15 ORPHAN 870726369 7 YES
10 3114665 03-FEB-15 3041350 01-FEB-15 ORPHAN 870726883 7 YES
11 3114664 03-FEB-15 3041350 01-FEB-15 CURRENT 870729934 7 YES
11 rows selected.
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 TEST 2155613261 PARENT 1 30-JUN-05
2 2 TEST 2155613261 PARENT 446075 05-SEP-14
3 3 TEST 2155613261 PARENT 2849317 27-JAN-15
4 4 TEST 2155613261 PARENT 2880152 27-JAN-15
5 5 TEST 2155613261 PARENT 3017109 01-FEB-15
6 6 TEST 2155613261 PARENT 3041066 01-FEB-15
7 7 TEST 2155613261 PARENT 3041350 01-FEB-15
8 8 TEST 2155613261 ORPHAN 3111834 03-FEB-15
9 9 TEST 2155613261 ORPHAN 3111834 03-FEB-15
11 11 TEST 2155613261 CURRENT 3114664 03-FEB-15
10 10 TEST 2155613261 ORPHAN 3114665 03-FEB-15
ポイント・イン・タイム・リカバリを実行するには、次の2つの条件を用意する必要があります.1.リカバリするターゲット時間、SCN、リストアポイント、またはログ・シーケンス番号を決定します.フラッシュバック・クエリー、フラッシュバック・バージョン・クエリー、フラッシュバック・トランザクション・クエリーは、論理エラーを識別するのに役立ちます.alert.をチェックすることもできます.logの情報は、リカバリのターゲットポイントを判断するのに役立ちます.また,ターゲットSCNを含むログシーケンス番号を判断してログにより復元することも可能である.たとえば、v$log_のクエリhistoryは、アーカイブされたログ情報を表示します.
SQL> select * from v$log_history;
RECID STAMP THREAD# SEQUENCE# FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# RESETLOGS_CHANGE# RESETLOGS_TI
---------- ---------- ---------- ---------- ------------- ------------ ------------ ----------------- ------------
231 870563592 1 2 3041294 01-FEB-15 3041343 3041066 01-FEB-15
232 870564201 1 3 3041343 01-FEB-15 3041349 3041066 01-FEB-15
233 870597597 1 1 3041350 01-FEB-15 3063719 3041350 01-FEB-15
234 870684680 1 2 3063719 02-FEB-15 3097923 3041350 01-FEB-15
235 870724659 1 3 3097923 03-FEB-15 3114664 3041350 01-FEB-15
236 870726371 1 1 3111834 03-FEB-15 3112739 3111834 03-FEB-15
237 870726883 1 1 3111834 03-FEB-15 3114664 3111834 03-FEB-15
238 870729935 1 1 3114665 03-FEB-15 3116367 3114665 03-FEB-15
239 870769788 1 1 3114664 03-FEB-15 3135728 3114664 03-FEB-15
たとえば、午前10時1分にユーザーが誤って表領域を削除した場合、データベースを午前10時に復元できます.つまり、表領域を削除する前の時点です.回復後の午前10時以降のすべての変更は失われます.
2.ターゲットSCNの代わりにターゲット時間式を使用する場合は、RMANを使用する前に、時間フォーマットの環境変数の設定が適切であることを確認します.NLS_LANG=AMERICAN_AMERICA.ZHS16GBK NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS'
current incarnationを使用して、時点別リカバリを実行current incarnationを使用して時点別リカバリを実行する場合に使用される現在のバージョンの制御ファイルです.時点別リカバリを実行する場合は、restotreコマンドとrecoverコマンドでuntil句を個別に設定せずに、set untilコマンドを使用してリカバリのターゲット時間を設定し、エラーを回避できます.これにより、バックアップから復元されたデータファイルのタイムスタンプが、後続のrecover操作よりも早いことが保証されます.
ポイント・イン・タイム・リカバリの手順は、scottユーザーの下のテーブルempのすべてのレコードを削除し、削除する前に現在のシステムのSCNを記録し、ポイント・イン・タイム・リカバリを実行してテーブルのレコードをリカバリします.
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
3142264
SQL> select to_char(scn_to_timestamp(3142264),'yyyy-mm-dd hh24:mi:ss') from dual;
TO_CHAR(SCN_TO_TIME
-------------------
2015-02-04 11:22:29
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------
1 1 4 52428800 1 NO CURRENT 3142228 04-FEB-15
3 1 3 52428800 1 YES INACTIVE 3142176 04-FEB-15
2 1 2 52428800 1 YES INACTIVE 3135728 04-FEB-15
SQL> select * from emp;
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
---------- ---------- --------- ---------- ------------ ---------- ---------- ----------
7369 SMITH CLERK 7902 17-DEC-80 800 20
7499 ALLEN SALESMAN 7698 20-FEB-81 1600 300 30
7521 WARD SALESMAN 7698 22-FEB-81 1250 500 30
7566 JONES MANAGER 7839 02-APR-81 2975 20
7654 MARTIN SALESMAN 7698 28-SEP-81 1250 1400 30
7698 BLAKE MANAGER 7839 01-MAY-81 2850 30
7782 CLARK MANAGER 7839 09-JUN-81 2450 10
7788 SCOTT ANALYST 7566 19-APR-87 3000 20
7839 KING PRESIDENT 17-NOV-81 5000 10
7844 TURNER SALESMAN 7698 08-SEP-81 1500 0 30
7876 ADAMS CLERK 7788 23-MAY-87 1100 20
7900 JAMES CLERK 7698 03-DEC-81 950 30
7902 FORD ANALYST 7566 03-DEC-81 3000 20
7934 MILLER CLERK 7782 23-JAN-82 1300 10
14 rows selected.
SQL> delete from emp;
14 rows deleted.
SQL> commit;
Commit complete.
SQL> select * from emp;
no rows selected
1.ターゲット・データベースまたはリカバリ・ディレクトリに接続し、ある場合はmountステータスにデータベースを起動します.
[oracle@oracle11g ~]$ rman target/
Recovery Manager: Release 10.2.0.5.0 - Production on Wed Feb 4 10:25:34 2015
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database (not started)
RMAN> startup mount
Oracle instance started
database mounted
Total System Global Area 327155712 bytes
Fixed Size 1273516 bytes
Variable Size 138412372 bytes
Database Buffers 184549376 bytes
Redo Buffers 2920448 bytes
2.RUNブロックを実行して、ポイント・イン・タイム・リカバリを実行します.RUNブロックでset untilを使用して、リカバリのターゲット時間、リストアポイント、SCNまたはログシーケンス番号を指定します.ターゲット時間を指定した場合は、NLS_を使用します.LANGとNLS_DATE_FORMAT環境変数で指定されたフォーマット.自動チャネルが構成されていない場合は、アクセスするディスクまたはテープにチャネルを割り当てます.
RMAN> run
2> {
3> set until scn 3142264;
4> restore database;
5> recover database;
6> }
executing command: SET until clause
Starting restore at 04-FEB-15
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=157 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /u01/app/oracle/oradata/test/system01.dbf
restoring datafile 00002 to /u01/app/oracle/oradata/test/undotbs01.dbf
restoring datafile 00003 to /u01/app/oracle/oradata/test/sysaux01.dbf
restoring datafile 00004 to /u01/app/oracle/oradata/test/users01.dbf
restoring datafile 00005 to /u01/app/oracle/oradata/test/example01.dbf
restoring datafile 00006 to /u01/app/oracle/oradata/test/test01.dbf
restoring datafile 00007 to /u01/app/oracle/oradata/test/testbak.dbf
channel ORA_DISK_1: reading from backup piece /u02/test_df870779983_s135_s1
channel ORA_DISK_1: restored backup piece 1
piece handle=/u02/test_df870779983_s135_s1 tag=TAG20150204T111943
channel ORA_DISK_1: restore complete, elapsed time: 00:02:29
Finished restore at 04-FEB-15
Starting recover at 04-FEB-15
using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:02
Finished recover at 04-FEB-15
alertログファイルから次の情報が表示されます.
The input backup piece /u02/test_df870779983_s135_s1 is in compressed format.
Full restore complete of datafile 6 /u01/app/oracle/oradata/test/test01.dbf. Elapsed time: 0:00:01
checkpoint is 3142189
Full restore complete of datafile 7 /u01/app/oracle/oradata/test/testbak.dbf. Elapsed time: 0:00:06
checkpoint is 3142189
Full restore complete of datafile 4 /u01/app/oracle/oradata/test/users01.dbf. Elapsed time: 0:00:09
checkpoint is 3142189
last deallocation scn is 3111848
Wed Feb 04 11:25:47 CST 2015
Full restore complete of datafile 2 /u01/app/oracle/oradata/test/undotbs01.dbf. Elapsed time: 0:00:37
checkpoint is 3142189
last deallocation scn is 3106509
Wed Feb 04 11:25:58 CST 2015
Full restore complete of datafile 5 /u01/app/oracle/oradata/test/example01.dbf. Elapsed time: 0:00:46
checkpoint is 3142189
last deallocation scn is 2526488
Wed Feb 04 11:26:57 CST 2015
Full restore complete of datafile 3 /u01/app/oracle/oradata/test/sysaux01.dbf. Elapsed time: 0:01:47
checkpoint is 3142189
last deallocation scn is 3099893
Wed Feb 04 11:27:32 CST 2015
Full restore complete of datafile 1 /u01/app/oracle/oradata/test/system01.dbf. Elapsed time: 0:02:20
checkpoint is 3142189
last deallocation scn is 3101877
Wed Feb 04 11:27:39 CST 2015
alter database recover datafile list clear
Wed Feb 04 11:27:39 CST 2015
Completed: alter database recover datafile list clear
Wed Feb 04 11:27:39 CST 2015
alter database recover datafile list
1 , 2 , 3 , 4 , 5 , 6 , 7
Completed: alter database recover datafile list
1 , 2 , 3 , 4 , 5 , 6 , 7
Wed Feb 04 11:27:39 CST 2015
alter database recover if needed
start until change 3142264
Media Recovery Start
Wed Feb 04 11:27:40 CST 2015
Recovery of Online Redo Log: Thread 1 Group 3 Seq 3 Reading mem 0
Mem# 0: /u01/app/oracle/oradata/test/redo03.log
Wed Feb 04 11:27:40 CST 2015
Recovery of Online Redo Log: Thread 1 Group 1 Seq 4 Reading mem 0
Mem# 0: /u01/app/oracle/oradata/test/redo01.log
Wed Feb 04 11:27:40 CST 2015
Incomplete Recovery applied until change 3142277
Wed Feb 04 11:27:40 CST 2015
Media Recovery Complete (test)
Completed: alter database recover if needed
start until change 3142264
上記のリカバリ・プロセスから、まずバックアップからデータ・ファイルをリストアします.各データ・ファイルのcheckpoint scnは3142189で、リカバリ・ターゲットSCNよりも小さく、REDOログ・ファイルを適用してデータベースをターゲットSCNに対応する時点にリカバリします.
set untilはまた、リカバリターゲットの時点set until time'2015-02-04 11:22:29'として、リストアポイントまたはログシーケンスを使用することもできます.set until sequence 4; set until restore point before_delete;
ポイント・イン・タイムでリカバリに成功した場合.データベースを読み取り専用で開き、テーブルempのデータが復元されたかどうかを確認できます.テーブルempのレコードがリカバリされていない場合は、リカバリターゲットSCNを間違って選択した可能性があります.この場合、新しいリカバリターゲットSCNを使用して、ポイント・イン・タイム・リカバリを再実行できます.
RMAN> sql 'alter database open read only';
sql statement: alter database open read only
SQL> select * from emp;
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
---------- ---------- --------- ---------- ------------ ---------- ---------- ----------
7369 SMITH CLERK 7902 17-DEC-80 800 20
7499 ALLEN SALESMAN 7698 20-FEB-81 1600 300 30
7521 WARD SALESMAN 7698 22-FEB-81 1250 500 30
7566 JONES MANAGER 7839 02-APR-81 2975 20
7654 MARTIN SALESMAN 7698 28-SEP-81 1250 1400 30
7698 BLAKE MANAGER 7839 01-MAY-81 2850 30
7782 CLARK MANAGER 7839 09-JUN-81 2450 10
7788 SCOTT ANALYST 7566 19-APR-87 3000 20
7839 KING PRESIDENT 17-NOV-81 5000 10
7844 TURNER SALESMAN 7698 08-SEP-81 1500 0 30
7876 ADAMS CLERK 7788 23-MAY-87 1100 20
7900 JAMES CLERK 7698 03-DEC-81 950 30
7902 FORD ANALYST 7566 03-DEC-81 3000 20
7934 MILLER CLERK 7782 23-JAN-82 1300 10
14 rows selected.
以上の結果から,表empの記録は時点回復により取り戻したことが分かる.
時点別のリカバリが検証された後にリカバリ目標に達した場合、次の選択肢があります.1.Oracleエクスポートツールを使用して、リカバリしたテーブルempを論理的にエクスポートします.次に、データベースを現在の時点に復元してから、エクスポートされたデータをインポートします.これにより、データベースの他の変更が失われず、テーブルempのデータが復元されます.
2.データベースを読み書きで開きます.これにより、ターゲットSCNをリカバリした後の変更はすべて失われます.現在のオンラインREDOログ・ファイルはアーカイブされ、ログ・シーケンス番号は1に設定され、すべてのオンラインREDOログに新しいタイムスタンプとSCNが指定されます.
RMAN> alter database open resetlogs;
database opened
ancestor incarnationによるポイント・イン・タイム・リカバリancestor incarnationによるポイント・イン・タイム・リカバリとcurrent incarnationによるリカバリの違いは、データベースのincarnationを設定する必要がある点である.また、リカバリ対象SCNを含むincarnationから制御ファイルを復元する必要があります.
recover catalogを使用しない場合、たとえばscottユーザーのempテーブルが削除された時点にデータベースをリカバリし、older incarnationに対して時点別リカバリを実行する手順は、次のとおりです.
1.使用するincarnationを判断します.list incarnationコマンドを使用して、リカバリターゲット時間に対応するincarnationを見つけることができます.
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 TEST 2155613261 PARENT 1 2005-06-30 19:09:40
2 2 TEST 2155613261 PARENT 446075 2014-09-05 09:13:52
3 3 TEST 2155613261 PARENT 2849317 2015-01-27 15:10:02
4 4 TEST 2155613261 PARENT 2880152 2015-01-27 23:41:06
5 5 TEST 2155613261 PARENT 3017109 2015-02-01 19:31:28
6 6 TEST 2155613261 PARENT 3041066 2015-02-01 23:05:57
7 7 TEST 2155613261 PARENT 3041350 2015-02-01 23:23:21
8 8 TEST 2155613261 ORPHAN 3111834 2015-02-03 19:57:34
9 9 TEST 2155613261 ORPHAN 3111834 2015-02-03 20:26:09
11 11 TEST 2155613261 PARENT 3114664 2015-02-03 21:25:34
10 10 TEST 2155613261 ORPHAN 3114665 2015-02-03 20:34:43
12 12 TEST 2155613261 PARENT 3142278 2015-02-04 11:40:02
13 13 TEST 2155613261 PARENT 3144077 2015-02-04 13:09:03
14 14 TEST 2155613261 CURRENT 3144537 2015-02-04 13:32:41
現在のincarnationのInc Keyは14である.次のクエリでは、その前のincarnationのInc Keyが13であることがわかります.
SQL> select prior_incarnation# from v$database_incarnation where status ='CURRENT';
PRIOR_INCARNATION#
------------------
13
2.データベースをmount状態に起動する
RMAN> startup mount
Oracle instance started
database mounted
Total System Global Area 327155712 bytes
Fixed Size 1273516 bytes
Variable Size 138412372 bytes
Database Buffers 184549376 bytes
Redo Buffers 2920448 bytes
3.データベースtestのincarnationをincarnation番号13、すなわちcurrent incarnationのparent incarnationに設定します.
RMAN> reset database to incarnation 13;
database reset to incarnation 13
4.関連チャネル設定チャネルが構成されていない場合は、リストアとリカバリを実行し、リカバリターゲット時間を設定します.データベースをテーブルemp削除後の時点に復元します(2015-02-04 13:30:01):
RMAN> run
2> {
3> set until time '2015-02-04 13:30:01';
4> restore database;
5> recover database;
6> }
executing command: SET until clause
Starting restore at 2015-02-04 13:54:37
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /u01/app/oracle/oradata/test/system01.dbf
restoring datafile 00002 to /u01/app/oracle/oradata/test/undotbs01.dbf
restoring datafile 00003 to /u01/app/oracle/oradata/test/sysaux01.dbf
restoring datafile 00004 to /u01/app/oracle/oradata/test/users01.dbf
restoring datafile 00005 to /u01/app/oracle/oradata/test/example01.dbf
restoring datafile 00006 to /u01/app/oracle/oradata/test/test01.dbf
restoring datafile 00007 to /u01/app/oracle/oradata/test/testbak.dbf
channel ORA_DISK_1: reading from backup piece /u02/test_df870779983_s135_s1
channel ORA_DISK_1: restored backup piece 1
piece handle=/u02/test_df870779983_s135_s1 tag=TAG20150204T111943
channel ORA_DISK_1: restore complete, elapsed time: 00:02:37
Finished restore at 2015-02-04 13:57:14
Starting recover at 2015-02-04 13:57:14
using channel ORA_DISK_1
starting media recovery
archive log thread 1 sequence 3 is already on disk as file /u02/1_3_870729934.dbf
archive log thread 1 sequence 4 is already on disk as file /u02/1_4_870729934.dbf
archive log thread 1 sequence 1 is already on disk as file /u02/1_1_870781202.dbf
archive log filename=/u02/1_3_870729934.dbf thread=1 sequence=3
archive log filename=/u02/1_4_870729934.dbf thread=1 sequence=4
archive log filename=/u02/1_1_870781202.dbf thread=1 sequence=1
archive log filename=/u02/1_1_870786543.dbf thread=1 sequence=1
media recovery complete, elapsed time: 00:00:03
Finished recover at 2015-02-04 13:57:18
RMAN> alter database open resetlogs;
database opened
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 TEST 2155613261 PARENT 1 2005-06-30 19:09:40
2 2 TEST 2155613261 PARENT 446075 2014-09-05 09:13:52
3 3 TEST 2155613261 PARENT 2849317 2015-01-27 15:10:02
4 4 TEST 2155613261 PARENT 2880152 2015-01-27 23:41:06
5 5 TEST 2155613261 PARENT 3017109 2015-02-01 19:31:28
6 6 TEST 2155613261 PARENT 3041066 2015-02-01 23:05:57
7 7 TEST 2155613261 PARENT 3041350 2015-02-01 23:23:21
8 8 TEST 2155613261 ORPHAN 3111834 2015-02-03 19:57:34
9 9 TEST 2155613261 ORPHAN 3111834 2015-02-03 20:26:09
11 11 TEST 2155613261 PARENT 3114664 2015-02-03 21:25:34
10 10 TEST 2155613261 ORPHAN 3114665 2015-02-03 20:34:43
12 12 TEST 2155613261 PARENT 3142278 2015-02-04 11:40:02
13 13 TEST 2155613261 PARENT 3144077 2015-02-04 13:09:03
14 14 TEST 2155613261 ORPHAN 3144537 2015-02-04 13:32:41
15 15 TEST 2155613261 CURRENT 3144674 2015-02-04 13:58:43
recover catalogを使用する場合、たとえばscottユーザーのempテーブルが削除された時点にデータベースをリカバリし、older incarnationに対して時点別リカバリを実行する手順は、次のとおりです.
1.使用するincarnationを判断します.list incarnationコマンドを使用して、リカバリターゲット時間に対応するincarnationを見つけることができます.
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 8 TEST 2168949517 PARENT 1 2010-04-19 10:22:46
1 2 TEST 2168949517 PARENT 383537 2015-02-04 17:44:49
1 102 TEST 2168949517 PARENT 415176 2015-02-04 18:22:16
1 188 TEST 2168949517 CURRENT 415481 2015-02-04 18:33:17
現在のincarnationのInc Keyは188である.次のクエリでは、以前のincarnationのInc Keyは102であったことがわかります.データベースを2015-02-04 18:22:30、つまりSCN:415176とSCN:415481の間に復元します.
RMAN> list backup of controlfile;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
75 Full 6.80M DISK 00:00:01 2015-02-04 18:11:38
BP Key: 77 Status: AVAILABLE Compressed: NO Tag: TAG20150204T181137
Piece Name: /u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_04/o1_mf_s_870804697_bf3w2t62_.bkp
Control File Included: Ckp SCN: 415111 Ckp time: 2015-02-04 18:11:37
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
139 Full 6.80M DISK 00:00:02 2015-02-04 18:22:45
BP Key: 144 Status: AVAILABLE Compressed: NO Tag: TAG20150204T182243
Piece Name: /u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_04/o1_mf_s_870805363_bf3wqnyv_.bkp
Control File Included: Ckp SCN: 415288 Ckp time: 2015-02-04 18:22:43
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
236 Full 6.80M DISK 00:00:03 2015-02-04 18:33:39
BP Key: 242 Status: AVAILABLE Compressed: NO Tag: TAG20150204T183336
Piece Name: /u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_04/o1_mf_s_870806016_bf3xd2wl_.bkp
Control File Included: Ckp SCN: 415765 Ckp time: 2015-02-04 18:33:36
上記の制御ファイルバックアップ情報から、2015-02-04 18:22:30にリカバリする時点で制御ファイルバックアップを使用するべきであることがわかりますo 1_mf_s_870805363_bf3wqnyv_.bkp
2.データベースをnomount状態に強制的に起動する
RMAN> startup force nomount
Oracle instance started
Total System Global Area 327155712 bytes
Fixed Size 1273516 bytes
Variable Size 138412372 bytes
Database Buffers 184549376 bytes
Redo Buffers 2920448 bytes
3.データベースtestのincarnationをincarnation番号102、すなわちcurrent incarnationのparent incarnationに設定します.
RMAN> reset database to incarnation 102;
database reset to incarnation 102
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 8 TEST 2168949517 PARENT 1 2010-04-19 10:22:46
1 2 TEST 2168949517 PARENT 383537 2015-02-04 17:44:49
1 102 TEST 2168949517 CURRENT 415176 2015-02-04 18:22:16
1 188 TEST 2168949517 ORPHAN 415481 2015-02-04 18:33:17
4.関連チャネル設定チャネルが構成されていない場合は、リストアとリカバリを実行し、リカバリターゲット時間を設定します.制御ファイルを復元し、テーブルemp削除後の時点にデータベースを復元します(2015-02-04 18:22:30):
RMAN> restore controlfile;
Starting restore at 2015-02-04 18:44:23
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_04/o1_mf_s_870805363_bf3wqnyv_.bkp
channel ORA_DISK_1: restored backup piece 1
piece handle=/u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_04/o1_mf_s_870805363_bf3wqnyv_.bkp tag=TAG20150204T182243
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
output filename=/u01/app/oracle/oradata/test/control01.ctl
output filename=/u01/app/oracle/oradata/test/control02.ctl
output filename=/u01/app/oracle/oradata/test/control03.ctl
Finished restore at 2015-02-04 18:44:29
RMAN> alter database mount;
database mounted
released channel: ORA_DISK_1
RMAN> restore database until time '2015-02-04 18:22:30';
Starting restore at 2015-02-04 18:47:15
Starting implicit crosscheck backup at 2015-02-04 18:47:15
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK
Crosschecked 4 objects
Finished implicit crosscheck backup at 2015-02-04 18:47:17
Starting implicit crosscheck copy at 2015-02-04 18:47:17
using channel ORA_DISK_1
Finished implicit crosscheck copy at 2015-02-04 18:47:17
searching for all files in the recovery area
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name: /u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_04/o1_mf_s_870805363_bf3wqnyv_.bkp
File Name: /u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_04/o1_mf_s_870806016_bf3xd2wl_.bkp
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /u01/app/oracle/oradata/test/system01.dbf
restoring datafile 00002 to /u01/app/oracle/oradata/test/undotbs01.dbf
restoring datafile 00003 to /u01/app/oracle/oradata/test/sysaux01.dbf
restoring datafile 00004 to /u01/app/oracle/oradata/test/users01.dbf
restoring datafile 00005 to /u01/app/oracle/oradata/test/example01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/flash_recovery_area/TEST/backupset/2015_02_04/o1_mf_nnndf_TAG20150204T181037_bf3w0y1f_.bkp
channel ORA_DISK_1: restored backup piece 1
piece handle=/u01/app/oracle/flash_recovery_area/TEST/backupset/2015_02_04/o1_mf_nnndf_TAG20150204T181037_bf3w0y1f_.bkp tag=TAG20150204T181037
channel ORA_DISK_1: restore complete, elapsed time: 00:01:15
Finished restore at 2015-02-04 18:48:32
データファイルを2015-02-04 18:22:30に復元し、次にリカバリを実行します.リカバリ操作を実行する前にreset database to incarnation 102を実行する必要があります.そうしないと、エラーが発生することに注意してください.
RMAN> recover database until time '2015-02-04 18:22:30';
Starting recover at 2015-02-04 18:49:05
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 02/04/2015 18:49:05
RMAN-06004: ORACLE error from recovery catalog database: RMAN-20011: target database incarnation is not current in recovery catalog
reset database to incarnation 102を再実行する.
RMAN> reset database to incarnation 102;
database reset to incarnation 102
RMAN> recover database until time '2015-02-04 18:22:30';
Starting recover at 2015-02-04 18:49:21
using channel ORA_DISK_1
starting media recovery
archive log thread 1 sequence 3 is already on disk as file /u02/1_3_870803089.dbf
archive log thread 1 sequence 4 is already on disk as file /u02/1_4_870803089.dbf
archive log thread 1 sequence 1 is already on disk as file /u02/1_1_870805336.dbf
archive log filename=/u02/1_3_870803089.dbf thread=1 sequence=3
archive log filename=/u02/1_4_870803089.dbf thread=1 sequence=4
archive log filename=/u02/1_1_870805336.dbf thread=1 sequence=1
media recovery complete, elapsed time: 00:00:01
Finished recover at 2015-02-04 18:49:24
RMAN> alter database open resetlogs;
database opened
new incarnation of database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 8 TEST 2168949517 PARENT 1 2010-04-19 10:22:46
1 2 TEST 2168949517 PARENT 383537 2015-02-04 17:44:49
1 102 TEST 2168949517 PARENT 415176 2015-02-04 18:22:16
1 308 TEST 2168949517 CURRENT 415183 2015-02-04 18:49:41
1 188 TEST 2168949517 ORPHAN 415481 2015-02-04 18:33:17
リカバリが完了した後の現在のincarnation対応reset scn号は415176と415481の間で、期待される結果に達していることがわかります.
「ITPUBブログ」からのリンク:http://blog.itpub.net/26015009/viewspace-1426636/転載する必要がある場合は、出典を明記してください.そうしないと、法律責任を追及します.
転載先:http://blog.itpub.net/26015009/viewspace-1426636/