【恢復】Redo日誌文件丟失的恢復
第一章 Redo文件丟失的恢復
1.1 online redolog file 丟失
聯機Redo日誌是Oracle數據庫中比較核心的文件，當Redo日誌文件異常以後，數據庫就沒法正常啓動，並且有丟失據的風險，強烈建議在條件容許的狀況下，對Redo日誌進行多路鏡像。須要注意的是，RMAN不能備份聯機Redo日誌文件。因此，聯機Redo日誌一旦出現故障，則只能進行清除日誌了。清除日誌文件即代表能夠重用該文件。 node
1.1.1 數據庫歸檔/非歸檔模式下inactive redo異常ORA-00316 ORA-00327
1.1.1.1 例一
SQL> startup mount linux
ORACLE instance started. 面試
Total System Global Area 260046848 bytes sql
Fixed Size 1266896 bytes 數據庫
Variable Size 83888944 bytes bootstrap
Database Buffers 167772160 bytes 微信
Redo Buffers 7118848 bytes 網絡
Database mounted. oracle
SQL> alter database open; app
alter database open
*
ERROR at line 1:
ORA-00316: log 2 of thread 1, type in header is not log file
ORA-00312: online log 2 thread 1: '/u01/oracle/oradata/XFF/redo02.log'
SQL> col member for a40
SQL> set lines 120
SQL> SELECT thread#,
2 a.sequence#,
3 a.group#,
4 TO_CHAR (first_change#, '9999999999999999') "SCN",
5 a.status,
6 MEMBER
7 FROM v$log a, v$logfile b
8 WHERE a.group# = B.GROUP#
9 ORDER BY a.sequence# DESC;
THREAD# SEQUENCE# GROUP# SCN STATUS MEMBER
---------- ---------- ---------- ----------------- ---------------- -----------------------------------
1 15 3 665697 CURRENT /u01/oracle/oradata/XFF/redo03.log
1 14 2 645619 INACTIVE /u01/oracle/oradata/XFF/redo02.log
1 13 1 625540 INACTIVE /u01/oracle/oradata/XFF/redo01.log
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 2;
Database altered.
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-00327: log 2 of thread 1, physical size less than needed
ORA-00312: online log 2 thread 1: '/u01/oracle/oradata/XFF/redo02.log'
SQL> alter database drop logfile group 2;
Database altered.
SQL> alter database open;
Database altered.
SQL> alter database add logfile group 2 ('/u01/oracle/oradata/XFF/redo02.log') size 50M reuse;
Database altered.
1.1.1.2 例二
[oracle@orcltest ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Wed May 6 13:46:16 2015
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> col member for a50
SQL> set lines 120
SQL> SELECT thread#,
2 a.sequence#,
3 a.group#,
4 TO_CHAR (first_change#, '9999999999999999') "SCN",
5 a.status,
6 MEMBER
7 FROM v$log a, v$logfile b
8 WHERE a.group# = B.GROUP#
9 ORDER BY a.sequence# DESC;
THREAD# SEQUENCE# GROUP# SCN STATUS MEMBER
---------- ---------- ---------- ----------------- ---------------- --------------------------------------------------
1 16 3 1209020 CURRENT /u02/app/oracle/oradata/oratest/redo03.log
1 15 1 1209017 INACTIVE /u02/app/oracle/oradata/oratest/redo01.log
1 14 2 1209012 INACTIVE /u02/app/oracle/oradata/oratest/redo02.log
SQL> ! rm -rf /u02/app/oracle/oradata/oratest/redo01.log
SQL>
SQL> startup force;
ORACLE instance started.
Total System Global Area 409194496 bytes
Fixed Size 2228864 bytes
Variable Size 297799040 bytes
Database Buffers 100663296 bytes
Redo Buffers 8503296 bytes
Database mounted.
ORA-03113: end-of-file on communication channel
Process ID: 15390
Session ID: 125 Serial number: 5
SQL>
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
告警日誌：
Errors in file /u02/app/oracle/diag/rdbms/oratest/oratest/trace/oratest_lgwr_15484.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/u02/app/oracle/oradata/oratest/redo01.log'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
[oracle@orcltest ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Wed May 6 13:48:39 2015
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 409194496 bytes
Fixed Size 2228864 bytes
Variable Size 297799040 bytes
Database Buffers 100663296 bytes
Redo Buffers 8503296 bytes
Database mounted.
SQL> alter database clear logfile group 1;
Database altered.
SQL> alter database open;
Database altered.
SQL> col member for a50
SQL> set lines 120
SQL> SELECT thread#,
2 a.sequence#,
3 a.group#,
4 TO_CHAR (first_change#, '9999999999999999') "SCN",
5 a.status,
6 MEMBER
7 FROM v$log a, v$logfile b
8 WHERE a.group# = B.GROUP#
9 ORDER BY a.sequence# DESC;
THREAD# SEQUENCE# GROUP# SCN STATUS MEMBER
---------- ---------- ---------- ----------------- ---------------- --------------------------------------------------
1 17 1 1229024 CURRENT /u02/app/oracle/oradata/oratest/redo01.log
1 16 3 1209020 INACTIVE /u02/app/oracle/oradata/oratest/redo03.log
1 14 2 1209012 INACTIVE /u02/app/oracle/oradata/oratest/redo02.log
SQL>
1.1.2 正常關閉數據庫current redo異常ORA-00316 ORA-01623
1.1.2.1 例一
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-00316: log 1 of thread 1, type in header is not log file
ORA-00312: online log 1 thread 1: '/u01/oracle/oradata/XFF/redo01.log'
SQL> SELECT thread#,
2 a.sequence#,
3 a.group#,
4 TO_CHAR (first_change#, '9999999999999999') "SCN",
5 a.status,
6 MEMBER
7 FROM v$log a, v$logfile b
8 WHERE a.group# = B.GROUP#
9 ORDER BY a.sequence# DESC;
THREAD# SEQUENCE# GROUP# SCN STATUS MEMBER
---------- ---------- ---------- ----------------- ---------------- ----------------------------------
1 16 1 685918 CURRENT /u01/oracle/oradata/XFF/redo01.log
1 15 3 665697 INACTIVE /u01/oracle/oradata/XFF/redo03.log
1 0 2 0 UNUSED /u01/oracle/oradata/XFF/redo02.log
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1;
ALTER DATABASE CLEAR LOGFILE GROUP 1
*
ERROR at line 1:
ORA-00316: log 1 of thread 1, type 0 in header is not log file
ORA-00312: online log 1 thread 1: '/u01/oracle/oradata/XFF/redo01.log'
SQL> ALTER DATABASE drop logfile group 1;
ALTER DATABASE drop logfile group 1
*
ERROR at line 1:
ORA-01623: log 1 is current log for instance XFF (thread 1) - cannot drop
ORA-00312: online log 1 thread 1: '/u01/oracle/oradata/XFF/redo01.log'
SQL> recover database until cancel;
Media recovery complete.
SQL> alter database open resetlogs;
Database altered.
1.1.2.2 例二
[oracle@orcltest ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Wed May 6 13:52:49 2015
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> col member for a50
SQL> set lines 120
SQL> SELECT thread#,
2 a.sequence#,
3 a.group#,
4 TO_CHAR (first_change#, '9999999999999999') "SCN",
5 a.status,
6 MEMBER
7 FROM v$log a, v$logfile b
8 WHERE a.group# = B.GROUP#
9 ORDER BY a.sequence# DESC;
THREAD# SEQUENCE# GROUP# SCN STATUS MEMBER
---------- ---------- ---------- ----------------- ---------------- --------------------------------------------------
1 20 1 1229346 CURRENT /u02/app/oracle/oradata/oratest/redo01.log
1 19 3 1229343 INACTIVE /u02/app/oracle/oradata/oratest/redo03.log
1 18 2 1229340 INACTIVE /u02/app/oracle/oradata/oratest/redo02.log
SQL> ! rm -rf /u02/app/oracle/oradata/oratest/redo01.log
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 409194496 bytes
Fixed Size 2228864 bytes
Variable Size 297799040 bytes
Database Buffers 100663296 bytes
Redo Buffers 8503296 bytes
Database mounted.
ORA-03113: end-of-file on communication channel
Process ID: 15837
Session ID: 125 Serial number: 5
SQL>
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
告警日誌：
Errors in file /u02/app/oracle/diag/rdbms/oratest/oratest/trace/oratest_ora_15949.trc:
ORA-00313: open failed for members of log group 1 of thread
ORA-00312: online log 1 thread 1: '/u02/app/oracle/oradata/oratest/redo01.log'
Wed May 06 13:53:47 2015
ARC1 started with pid=21, OS id=15976
USER (ospid: 15949): terminating the instance due to error 313
System state dump requested by (instance=1, osid=15949), summary=[abnormal instance termination].
System State dumped to trace file /u02/app/oracle/diag/rdbms/oratest/oratest/trace/oratest_diag_15919.trc
Dumping diagnostic data in directory=[cdmp_20150506135347], requested by (instance=1, osid=15949), summary=[abnormal instance termination].
Instance terminated by USER, pid = 15949
[oracle@orcltest ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Wed May 6 13:54:28 2015
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 409194496 bytes
Fixed Size 2228864 bytes
Variable Size 297799040 bytes
Database Buffers 100663296 bytes
Redo Buffers 8503296 bytes
Database mounted.
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1;
ALTER DATABASE CLEAR LOGFILE GROUP 1
*
ERROR at line 1:
ORA-00350: log 1 of instance oratest (thread 1) needs to be archived
ORA-00312: online log 1 thread 1: '/u02/app/oracle/oradata/oratest/redo01.log'
SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 1;
Database altered.
SQL> ALTER DATABASE OPEN;
Database altered.
SQL> col member for a50
SQL> set lines 120
SQL> SELECT thread#,
2 a.sequence#,
3 a.group#,
4 TO_CHAR (first_change#, '9999999999999999') "SCN",
5 a.status,
6 MEMBER
7 FROM v$log a, v$logfile b
8 WHERE a.group# = B.GROUP#
9 ORDER BY a.sequence# DESC;
THREAD# SEQUENCE# GROUP# SCN STATUS MEMBER
---------- ---------- ---------- ----------------- ---------------- --------------------------------------------------
1 21 2 1229347 CURRENT /u02/app/oracle/oradata/oratest/redo02.log
1 19 3 1229343 INACTIVE /u02/app/oracle/oradata/oratest/redo03.log
1 0 1 1229346 UNUSED /u02/app/oracle/oradata/oratest/redo01.log
SQL>
1.1.3 數據庫異常關閉current/active redo異常ORA-00316 ORA-01624 ORA-01194
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-00316: log 1 of thread 1, type 0 in header is not log file
ORA-00312: online log 1 thread 1: '/u01/oracle/oradata/XFF/redo01.log'
SQL> SELECT thread#,
2 a.sequence#,
3 a.group#,
4 TO_CHAR (first_change#, '9999999999999999') "SCN",
5 a.status,
6 MEMBER
7 FROM v$log a, v$logfile b
8 WHERE a.group# = B.GROUP#
9 ORDER BY a.sequence# DESC;
THREAD# SEQUENCE# GROUP# SCN STATUS MEMBER
---------- ---------- ---------- ----------------- ---------------- -----------------------------------
1 8 2 686310 CURRENT /u01/oracle/oradata/XFF/redo02.log
1 7 1 686294 ACTIVE /u01/oracle/oradata/XFF/redo01.log
1 6 3 686289 INACTIVE /u01/oracle/oradata/XFF/redo03.log
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1;
ALTER DATABASE CLEAR LOGFILE GROUP 1
*
ERROR at line 1:
ORA-01624: log 1 needed for crash recovery of instance XFF (thread 1)
ORA-00312: online log 1 thread 1: '/u01/oracle/oradata/XFF/redo01.log'
SQL> ALTER DATABASE drop logfile group 1;
ALTER DATABASE drop logfile group 1
*
ERROR at line 1:
ORA-01624: log 1 needed for crash recovery of instance XFF (thread 1)
ORA-00312: online log 1 thread 1: '/u01/oracle/oradata/XFF/redo01.log'
SQL> recover database until cancel;
ORA-00279: change 686294 generated at 04/20/2013 01:37:16 needed for thread 1
ORA-00289: suggestion : /u01/oracle/oracle/product/10.2.0/db_1/dbs/arch1_7_813202529.dbf
ORA-00280: change 686294 for thread 1 is in sequence #7
Specify log: {=suggested | filename | AUTO | CANCEL}
/u01/oracle/oradata/XFF/redo01.log
ORA-00308: cannot open archived log '/u01/oracle/oradata/XFF/redo01.log'
ORA-27047: unable to read the header block of file
Additional information: 2
Specify log: {=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/u01/oracle/oradata/XFF/system01.dbf'
ORA-01112: media recovery not started
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/u01/oracle/oradata/XFF/system01.dbf'
SQL> alter system set "_allow_resetlogs_corruption"=true scope=spfile;
System altered.
SQL> shutdown immediate;
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 260046848 bytes
Fixed Size 1266896 bytes
Variable Size 83888944 bytes
Database Buffers 167772160 bytes
Redo Buffers 7118848 bytes
Database mounted.
SQL> recover database until cancel;
ORA-00279: change 686294 generated at 04/20/2013 01:37:16 needed for thread 1
ORA-00289: suggestion : /u01/oracle/oracle/product/10.2.0/db_1/dbs/arch1_7_813202529.dbf
ORA-00280: change 686294 for thread 1 is in sequence #7
Specify log: {=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/u01/oracle/oradata/XFF/system01.dbf'
ORA-01112: media recovery not started
SQL> alter database open resetlogs;
Database altered.
在這樣的狀況下,數據庫異常關閉,current/active redo異常,經過使用隱含參數可能能夠僥倖的恢復數據庫,可是也可能致使數據丟失.這裏由於是模擬狀況,無業務因此在不少較爲繁忙的業務系統中,使用隱含參數resetlogs過程當中可能還會遇到以下不少常見的錯誤,進一步增長了恢復難度。
current/active redo異常後附帶其餘錯誤
ORA-600[2662]
Wed Dec 07 13:02:49 2011
SMON: enabling cache recovery
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_ora_3388.trc (incident=216664):
ORA-00600: 內部錯誤代碼, 參數: [2662], [2], [1153862134], [2], [1153864845], [12582921], [], []
Incident details in: d:\app\administrator\diag\rdbms\hzyl\hzyl\incident\incdir_216664\hzyl_ora_3388_i216664.trc
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_ora_3388.trc:
ORA-00600: 內部錯誤代碼, 參數: [2662], [2], [1153862134], [2], [1153864845], [12582921], [], []
Error 600 happened during db open, shutting down database
USER (ospid: 3388): terminating the instance due to error 600
ORA-00600[4000]
Thu Feb 28 19:29:10 2013
SMON: enabling cache recovery
Thu Feb 28 19:29:11 2013
Errors in file /u1/PROD/prodora/db/tech_st/10.2.0/admin/PROD_oracle/udump/prod_ora_20989.trc:
ORA-00600: internal error code, arguments: [4000], [50], [], [], [], [], [], []
Thu Feb 28 19:29:13 2013
Incremental checkpoint up to RBA [0x1.3.0], current log tail at RBA [0x1.3.0]
Thu Feb 28 19:29:13 2013
Errors in file /u1/PROD/prodora/db/tech_st/10.2.0/admin/PROD_oracle/udump/prod_ora_20989.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [4000], [50], [], [], [], [], [], []
ORA-00704 ORA-00604 ORA-01555
Fri May 4 21:04:21 2012
select ctime, mtime, stime from obj$ where obj# = :1
Fri May 4 21:04:21 2012
Errors in file /oracle/admin/standdb/udump/perfdb_ora_1286288.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 40 with name "_SYSSMU40$" too small
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704
Instance terminated by USER, pid = 1286288
ORA-1092 signalled during: alter database open resetlogs...
current/active redo異常還可能報以下錯誤
redo文件損壞報錯
Started redo scan
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_ora_2960.trc (incident=214262):
ORA-00353: 日誌損壞接近塊 12014 更改 9743799889 時間 12/05/2011 09:21:11
ORA-00312: 聯機日誌 3 線程 1: 'R:\ORADATA\HZYL\REDO03.LOG'
Incident details in: d:\app\administrator\diag\rdbms\hzyl\hzyl\incident\incdir_214262\hzyl_ora_2960_i214262.trc
Aborting crash recovery due to error 368
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_ora_2960.trc:
ORA-00368: 重作日誌塊中的校驗和錯誤
ORA-00353: 日誌損壞接近塊 12014 更改 9743799889 時間 12/05/2011 09:21:11
ORA-00312: 聯機日誌 3 線程 1: 'R:\ORADATA\HZYL\REDO03.LOG'
ORA-368 signalled during: ALTER DATABASE OPEN...
redo文件被其餘實例佔用報錯
Wed May 16 17:03:11 2012
Started redo scan
Wed May 16 17:03:11 2012
Errors in file /oracle/admin/odsdb/udump/odsdb1_ora_2040024.trc:
ORA-00305: log 14 of thread 1 inconsistent; belongs to another database
ORA-00312: online log 14 thread 1: '/dev/rods_redo1_2_2'
ORA-00305: log 14 of thread 1 inconsistent; belongs to another database
ORA-00312: online log 14 thread 1: '/dev/rods_redo1_2_1'
ORA-305 signalled during: ALTER DATABASE OPEN...
存儲總體異常
Mon Oct 17 09:35:09 2011
Errors in file /oracle/app/admin/orcl/bdump/orcl2_lgwr_348814.trc:
ORA-00340: IO error processing online log 4 of thread 2
ORA-00345: redo log write error block 6732 count 2
ORA-00312: online log 4 thread 2: '/dev/rredo21'
ORA-27063: number of bytes read/written is incorrect
IBM AIX RISC System/6000 Error: 6: No such device or address
Additional information: -1
Additional information: 1024
Mon Oct 17 09:35:09 2011
LGWR: terminating instance due to error 340
存儲IO異常
Fri Feb 21 08:44:42 2014
Thread 1 advanced to log sequence 591 (LGWR switch)
Current log# 1 seq# 591 mem# 0: J:\ORADATA\ORCL\REDO01.LOG
Fri Feb 21 15:31:20 2014
Errors in file c:\oracle\product\10.2.0\admin\orcl\bdump\orcl_lgwr_10312.trc:
ORA-00316: log 1 of thread 1, type 286 in header is not log file
ORA-00312: online log 1 thread 1: 'J:\ORADATA\ORCL\REDO01.LOG'
使用_disable_logging參數
Sat May 14 23:16:49 2005
Errors in file d:\oracle\admin\rman\bdump\rman_arc0_736.trc:
ORA-16038: log 3 sequence# 72 cannot be archived
ORA-00354: corrupt redo log block header
ORA-00312: online log 3 thread 1: 'D:\ORACLE\ORADATA\RMAN\REDO03.LOG'
1.1.3.1 current狀態日誌丟失
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 5
Next log sequence to archive 7
Current log sequence 7
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
1 1 7 52428800 1 NO CURRENT 661005 11-MAR-15
2 1 5 52428800 1 YES INACTIVE 660997 11-MAR-15
3 1 6 52428800 1 YES INACTIVE 660999 11-MAR-15
SQL> ho ls /u03/app/oracle/oradata/ora1024g/redo01.log
ls: cannot access /u03/app/oracle/oradata/ora1024g/redo01.log: No such file or directory
SQL> shutdown abort;
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 448790528 bytes
Fixed Size 2084616 bytes
Variable Size 130023672 bytes
Database Buffers 310378496 bytes
Redo Buffers 6303744 bytes
Database mounted.
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/u03/app/oracle/oradata/ora1024g/redo01.log'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1;
ALTER DATABASE CLEAR LOGFILE GROUP 1
*
ERROR at line 1:
ORA-01624: log 1 needed for crash recovery of instance ora1024g (thread 1)
ORA-00312: online log 1 thread 1: '/u03/app/oracle/oradata/ora1024g/redo01.log'
SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 1;
ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 1
*
ERROR at line 1:
ORA-01624: log 1 needed for crash recovery of instance ora1024g (thread 1)
ORA-00312: online log 1 thread 1: '/u03/app/oracle/oradata/ora1024g/redo01.log'
SQL> alter system set "_allow_resetlogs_corruption"=true scope=spfile;
System altered.
SQL> recover database using backup controlfile;
ORA-00279: change 662207 generated at 03/12/2015 10:08:02 needed for thread 1
ORA-00289: suggestion :
/u03/app/oracle/flash_recovery_area/ORA1024G/archivelog/2015_03_12/o1_mf_1_7_%u_.arc
ORA-00280: change 662207 for thread 1 is in sequence #7
Specify log: {=suggested | filename | AUTO | CANCEL}
ORA-00308: cannot open archived log
'/u03/app/oracle/flash_recovery_area/ORA1024G/archivelog/2015_03_12/o1_mf_1_7_%u_.arc'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
SQL> startup mount force;
ORACLE instance started.
Total System Global Area 409194496 bytes
Fixed Size 2228864 bytes
Variable Size 297799040 bytes
Database Buffers 100663296 bytes
Redo Buffers 8503296 bytes
Database mounted.
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/u03/app/oracle/oradata/ora1024g/system01.dbf'
SQL> shutdown immediate;
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 448790528 bytes
Fixed Size 2084616 bytes
Variable Size 130023672 bytes
Database Buffers 310378496 bytes
Redo Buffers 6303744 bytes
Database mounted.
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
SQL> startup force;
ORA-24324: service handle not initialized
ORA-01041: internal error. hostdef extension doesn't exist
SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@rhel6_lhr ~]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.4.0 - Production on Thu Mar 12 10:20:50 2015
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Connected to an idle instance.
SQL> startup
ORACLE instance started.
Total System Global Area 448790528 bytes
Fixed Size 2084616 bytes
Variable Size 130023672 bytes
Database Buffers 310378496 bytes
Redo Buffers 6303744 bytes
Database mounted.
Database opened.
SQL> alter system reset "_allow_resetlogs_corruption" scope=spfile sid='*';
System altered.
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 1
Next log sequence to archive 2
Current log sequence 2
SQL>
重作日誌文件在數據庫中是要求最高的組件，首先其對磁盤的IO要求極高，其次一旦CURRENT組發生故障，數據庫會當即崩潰，而且100%會發生數據丟失，因此ORACLE建議至少每一個組須要兩個成員，而且在數據庫運行過程當中日誌文件會一直被鎖定，以防不測。
Redo log的恢復分爲兩種：CURRENT 和 非CURRENT
3.1 CURRENT 狀況
形成redo 損壞，不少狀況是與忽然斷電有關。這種狀況下是比較麻煩的。
（1）若是有歸檔和備份，能夠用不徹底恢復。
SQL>startup mount;
SQL>recover database until cancel; 先選擇auto，儘可能恢復能夠利用的歸檔日誌，而後從新執行：
SQL>recover database until cancel; 此次輸入cancel，完成不徹底恢復,
用resetlogs打開數據：
SQL>alter database open resetlogs； 打開數據庫
（2）強制恢復， 這種方法可能會致使數據不一致
sql>startup mount;
sql>alter system set "_allow_resetlogs_corruption"=true scope=spfile;
sql>recover database until cancel;
sql>alter database open resetlogs;
運氣好的話，數據庫能正常打開，可是因爲使用_allow_resetlogs_corruption方式打開，會形成數據的丟失，且數據庫的狀態不一致。所以，這種狀況下Oracle建議經過EXP方式導出數據庫。重建新數據庫後，再導入。
redo 的損壞，通常還容易伴隨如下2種錯誤：ORA-600[2662]（SCN有關）和 ORA-600[4000]（回滾段有關）。
metalink上的兩篇文章介紹了兩種狀況的處理方法：
TECH: Summary For Forcing The Database Open With `_ALLOW_RESETLOGS_CORRUPTION` with Automatic Undo Management [ID 283945.1]
http://blog.csdn.net/tianlesoftware/archive/2010/12/29/6106083.aspx
ORA-600 [2662] Block SCN is ahead of Current SCN [ID 28929.1]
http://blog.csdn.net/tianlesoftware/archive/2010/12/29/6106130.aspx
這兩種狀況下的恢復有點複雜，回頭單獨作個測試，在補充進來。
3.2 非CURRENT 狀況
這種狀況下的恢復比較簡單，由於redo log 是已經完成歸檔或者正在歸檔。 沒有正在使用。能夠經過v$log 查看redo log 的狀態。
（1）若是STATUS是INACTIVE,則表示已經完成了歸檔，直接清除掉這個redo log便可。
SQL>startup mount;
SQL> alter database clear logfile group 3 ;
SQL>alter database open;
（2）若是STATUS 是ACTIVE ，表示正在歸檔， 此時須要使用以下語句：
SQL>startup mount;
SQL> alter database clear unarchived logfile group 3 ;
SQL>alter database open;
current online log 損壞有兩種恢復方法：
（1）若是有歸檔和備份，能夠用不徹底恢復。
SQL>startup mount;
SQL>recover database until cancel; 先選擇auto，儘可能恢復能夠利用的歸檔日誌，而後從新執行：
SQL>recover database until cancel; 此次輸入cancel，完成不徹底恢復,
用resetlogs打開數據：
SQL>alter database open resetlogs； 打開數據庫
（2）強制恢復， 這種方法可能會致使數據不一致
sql>startup mount;
sql>alter system set "_allow_resetlogs_corruption"=true scope=spfile;
sql>recover database until cancel;
sql>alter database open resetlogs;
這裏主要看2點：
（1）使用了_allow_resetlogs_corruption 參數
（2）這種狀況下，可能會報ORA-600[2662]（SCN有關）和 ORA-600[4000]（回滾段有關）的錯誤。
使用_allow_resetlogs_corruption參數，強制的打開數據庫，可能會致使邏輯的壞塊，從而影響數據字典。 因此，即便使用該參數正常打開後，也須要作的一個操做：邏輯導出數據。 重建實例，導入實例。 消除邏輯壞塊的可能性。
若是使用_allow_resetlogs_corruption參數啓動報了undo segment的錯誤而沒法啓動，處理方法參考第二節中undo 的處理狀況。 只要DB 能正常open，就導出數據，重建實例，在導入。
1.1.4 其餘
如下命令須要在sqlplus中執行：
Which of the following does the recover command not do? 下列哪項是恢復命令不能作？
A. Restore archived redo logs.還原歸檔重作日誌。
B. Apply archived redo logs.
C. Restore incremental backups.
D. Apply incremental backups.
E. Restore datafile images.
The recover command does not restore datafile images. It does restore and apply archived redo logs and incremental backup images during the recovery process.
Answer: A
Which statement about recovering from the loss of a redo log group is true? 有關重作日誌組的損失中恢復，哪一種說法是真的？
A. If the lost redo log group is ACTIVE, you should first attempt to clear the log file. B.
If the lost redo log group is CURRENT, you must clear the log file.
C. If the lost redo log group is ACTIVE, you must restore, perform cancel-based incomplete recovery, and
open the database using the RESETLOGS option.
D. If the lost redo log group is CURRENT, you must restore, perform cancel-based incomplete recovery, and
open the database using the RESETLOGS option. 若是丟失的重作日誌組是最新的，你必須恢復，執行基於
取消的不徹底恢復，並使用重置日誌選項打開數據庫。
Answer: D
1.1.4.1 聯機重作日誌文件的恢復(online redo log )
當數據庫置爲mount狀態，且將要轉換爲open狀態時，數據文件，聯機日誌文件被打開，所以聯機日誌的丟失能夠在mount狀態完成
恢復步驟
a. 啓動到mount狀態(startup mount force)
b. 還原數據庫(restore database)
c. 恢復數據庫(recover database)
下面對刪除日誌並進行恢復
lion@ORCL> select * from tb2;
ID NAME
---------- ---------------
2 Jackson
lion@ORCL> select current_scn from v$database; --查看數據庫當前的SCN
CURRENT_SCN
-----------
1020638
lion@ORCL> insert into tb2 select 1,'Johnson' from dual; --爲表tb2新增一條記錄
lion@ORCL> commit;
lion@ORCL> select current_scn from v$database; --數據庫當前的SCN發生了變化爲
CURRENT_SCN
-----------
1020685
lion@ORCL> select file#, checkpoint_change# from v$datafile_header; --數據文件頭部的checkpoint_change
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 1020368
2 1020368
3 1020368
4 1020368
5 1020368
6 1020368
lion@ORCL> ho rm -f $ORACLE_BASE/oradata/orcl/*.log --刪除全部的日誌文件 */
lion@ORCL> insert into tb2 select 2,'wilson' from dual; --爲表插入新記錄
lion@ORCL> commit;
lion@ORCL> select current_scn from v$database; --數據庫當前的SCN發生了變化爲
CURRENT_SCN
-----------
1020708
lion@ORCL> alter system archive log current; --對日誌進行歸檔時提示錯誤發生
alter system archive log current
*
ERROR at line 1:
ORA-16038: log 1 sequence# 1 cannot be archived
ORA-00312: online log 1 thread 1: '/u01/oracle/oradata/orcl/redo01.log'
lion@ORCL> conn / as sysdba
sys@ORCL> startup mount force;
[oracle@oradb ~]$ uniread rman target / catalog rman/rman@asmdb --退出RMAN後並從新鏈接
RMAN> run {
2> allocate channel ch1 device type disk;
3> restore database;
4> recover database;
5> release channel ch1;}
RMAN-06054: media recovery requesting unknown log: thread 1 seq 1 lowscn 1020365
sys@ORCL> recover database until cancel; --回到SQLPlus直接使用until cancel來進行恢復
sys@ORCL> alter database open resetlogs; --執行opensetlogs打開數據庫
sys@ORCL> select * from lion.tb2; --在日誌未完成自動歸檔前，刪除日誌的後數據所有丟失
ID NAME
---------- ---------------
2 Jackson
Which are the correct steps, in order , to deal with the loss of an online redo log if the database has not yet
crashed? 若是數據庫還沒有崩潰，哪些是按順序的正確步驟，以處理聯機重作日誌的丟失？
a. Issue a checkpoint.
b. Shut down the database.
c. Issue an alter database open command to open the database.
d. Startup mount the database.
e. Issue an alter database clear logfile command.
f. Recover all database datafiles.
a.發出一個檢查點。
b.關閉數據庫。
d.啓動掛載數據庫。
e.發出改變數據庫清除日誌文件命令。
c.發出改變數據庫打開命令來打開數據庫。
A. a, b, c, d
B. b, d, e, c
C. a, b, d, e, c 阿扁得逞
D. b, f, d, f, c
E. b, d, a, c
Answer: C
The database is running in the ARCHIVELOG mode. It has three redo log groups with one member each. One of the redo log groups has become corrupted. You have issued the following command during the recovery of a damaged redo log file: 數據庫運行在歸檔記錄模式。它每個成員都有三個重作日誌組。重作日
志組之一已損壞。損壞的重作日誌文件的恢復過程當中，您已發出如下命令：
ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 3; 改變數據庫清除未歸檔日誌文件組3;
Which action should you perform immediately after using this command?
你在使用此命令後應當即執行哪個活動？
A. You should perform a log switch
B. You should make a backup of the database你應該作一個數據庫備份
C. You should switch the database to the NONARCHIVELOG mode
D. You should shut down the database instance and perform a complete database recovery
Answer: B
As soon as you discover that you have lost an online redo log, if the database is still functioning, what
should be your first action?
A. Shut down the database
B. Clear the online redo log
C. Back up the database
D. Checkpoint the database
E. Call Oracle support
Answer: D
1.1.4.2 Loss of a Redo Log File
If a member of a redo log file group is lost and if the group still has at least one member, note the following results:
1. Normal operation of the instance is not affected.
2. You receive a message in the alert log notifying you that a member cannot be found.
3. You can restore the missing log file by dropping the lost redo log member and adding a new member.
4. If the group with the missing log file has been archived you can clear the log group to re-create the missing file.
1、 第一種辦法
Recovering from the loss of a single redo log group member should not affect the running instance.
To perform this recovery:
1.Determine whether there is a missing log file by examining the alert log.
2.Restore the missing file by first dropping the lost redo log member:
SQL> ALTER DATABASE DROP LOGFILE MEMBER'+DATA/orcl/onlinelog/group_1.261.691672257';
Then add a new member to replace the lost red log member:
SQL> ALTER DATABASE ADD LOGFILE MEMBER '+DATA' TO GROUP 2;
Enterprise Manager can also be used to drop and re-create the log file member.
Note: If using OMF for your redo log files and you use the above syntax to add a new redo log member to an existing group, that new redo log member file will not be an OMF file. If you want to ensure that the new redo log member is an OMF file, then the easiest recovery option would be to create a new redo log group and then drop the redo log group that had the missing redo log member.
3.If the media failure is due to the loss of a disk drive or controller, rename the missing file.
4.If the group has already been archived, or if you are in NOARCHIVELOG mode, you may choose to solve the problem by clearing the log group to re-create the missing file or files. Select the appropriate group and then select the Clear Logfile action. You can also clear the affected group manually with the following command:
SQL> ALTER DATABASE CLEAR LOGFILE GROUP #;
2、 第二種辦法
執行：alter database clear logfile group 1;
ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 1;
3.Your database is in ARCHIVELOG mode.You have two online redo log groups,each of which contains one redo member.When you attempt to start the database,you receive the following errors:
ORA-00313:open failed for members of log group 1 of thread 1
ORA-00312:online log 1 thread 1:'D:\REDO01.LOG'
You discover that the online redo log file of the current redo group is corrupted.
Which statement should you use to resolve this issue?
A.ALTER DATABASE DROP LOGFILE GROUP 1;
B.ALTER DATABASE CLEAR LOGFILE GROUP 1;
C.ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 1;
D.ALTER DATABASE DROP LOGFILE MEMBER'D:\REDO01.LOG';
Answer:C
(答案解析：
參考：http://docs.oracle.com/cd/E11882_01/backup.112/e10642/osadvsce.htm#BRADV90052
[oracle@rtest~]$oerr ora 313
00313,00000,"open failed for members of log group%s of thread%s"
//*Cause:The online log cannot be opened.May not be able to find file.
//*Action:See accompanying errors and make log available.
[oracle@rtest~]$oerr ora 312
00312,00000,"online log%s thread%s:'%s'"
//*Cause:This message reports the filename for details of another message.
//*Action:Other messages will accompany this message.See the
//associated messages for the appropriate action to take.
你的數據庫在歸檔記錄模式。你有兩個在線重作日誌組，其中每一個都包含一個重作成員。當您嘗試啓動數據庫時，您會收到如下錯誤：
ORA-00313：線程1日誌組1成員打開失敗
ORA-00312：聯機日誌1線程1：'D：\REDO01.LOG
你發現當前的重作組聯機重作日誌文件被損壞。你應該使用哪一種說法來解決這個問題？
Clearing Inactive,Unarchived Redo
Clearing a not-yet-archived redo log allows it to be reused without archiving it.This action makes backups unusable if they were started before the last change in the log,unless the file was taken offline before the first change in the log.Hence,if you need the cleared log file for recovery of a backup,then you cannot recover that backup.Clearing a not-yet-archived-redo-log,prevents complete recovery from backups due to the missing log.
To clear an inactive,online redo log group that has not been archived:
If the database is shut down,then start a new instance and mount the database:
SQL>STARTUP MOUNT
Clear the log using the UNARCHIVED keyword.
For example,to clear log group 2,issue the following SQL statement:
SQL>ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 2;)
A database has three online redo log groups with one member each. A redo log member with the
status ACTICE is damages while the database is running.
What is the first step you should take to solve this problem?
A.Attempt to Issue a checkpoint.
B.Restart the database using the RESETLOGS option.
C.Drop the redo log number and create it in a different location.
D.Perform and incomplete recovery up to the most recent available redo log.
Answer:A
題目解答 注意在runing 且first
1.1.4.3 Loss of a Redo Log Group
Recovering from the Loss of a Redo Log Group
If you have lost an entire redo log group, then all copies of the log files for that group are unusable or gone.
The simplest case is where the redo log group is in the INACTIVE state. That means it is not currently being written to, and it is no longer needed for instance recovery. If the problem is temporary, or you are able to fix the media, then the database continues to run normally, and the group is reused when enough log switch events occur. Otherwise, if the media cannot be fixed, you can clear the log file. When you clear a log file, you are indicating that it can be reused.
If the redo log group in question is ACTIVE, then, even though it is not currently being written to, it is still needed for instance recovery. If you are able to perform a checkpoint, then the log file group is no longer needed for instance recovery, and you can proceed as if the group were in the inactive state.
If the log group is in the CURRENT state, then it is, or was, being actively written to at the time of the loss. You may even see the LGWR process fail in this case. If this happens, the instance crashes. Your only option at this point is to restore from backup, perform cancel-based point-in-time recovery, and then open the database with the RESETLOGS option.
Clearing a Log File
Clear a log file using this command:
ALTER DATABASE CLEAR [UNARCHIVED] LOGFILE GROUP
[UNRECOVERABLE DATAFILE]
When you clear a log file, you are indicating that it can be reused. If the log file has already been archived, the simplest form of the command can be used. Use the following query to determine which log groups have been archived:
SQL> SELECT GROUP#, STATUS, ARCHIVED FROM V$LOG;
For example, the following command clears redo log group 3, which has already been archived:
SQL> ALTER DATABASE CLEAR LOFGILE GROUP 3;
If the redo log group has not been archived, then you must specify the UNARCHIVED keyword. This forces you to acknowledge that it is possible that there are backups that rely on that redo log for recovery, and you have decided to forgo that recovery opportunity. This may be satisfactory for you, especially if you take another backup right after you correct the redo log group problem; you then no longer need that redo log file.
It is possible that the redo log is required to recover a data file that is currently offline.
ocp
A database is running In ARCHIVBXXMS mode. It has two online redo log groups and each group has one member.A LGWR Input/output (I/O) fells due to permanent media failure that has resulted In the loss of redo log file and the LWGR terminates causing the instance to crash. The steps to recover from the loss of a current redo log group member in the random order are as follow.
1) Restore the corrupted redo log group.
2) Restore from a whole database backup.
3) Perform incomplete recovery.
4) Relocate by renaming the member of the damaged online redo log group to a new location.
5) Open the database with the RESETLOGS option.
6) Restart the database instance.
7) Issue a checkpoint and clear the log.
Identify the option with the correct sequential steps to accomplish the task efficiently.
A. 1, 3, 4, and 5
B. 7, 3, 4. and 5
C. 2, 3, 4, and 5
D. 7, 4, 3. and 5
E. Only 6 is required
Answer: C
解答：
To recover from loss of an active online redo log group in ARCHIVELOG mode:
1. Begin incomplete media recovery, recovering up through the log before the damaged log.
2. Ensure that the current name of the lost redo log can be used for a newly created file.
If not, then rename the members of the damaged online redo log group to a new location. For example, enter:
3. ALTER DATABASE RENAME FILE "/disk1/oradata/trgt/redo01.log" TO "/tmp/redo01.log";
4. ALTER DATABASE RENAME FILE "/disk1/oradata/trgt/redo02.log" TO "/tmp/redo02.log";
5. Open the database using the RESETLOGS option:
6. ALTER DATABASE OPEN RESETLOGS;
先不徹底恢復在更改日誌路徑後打開數據庫 因此 後面爲3,4,5究竟是還原備份仍是清空日誌呢？
Losing an Active Online Redo Log Group
If the database is still running and the lost active redo log is not the current log, then issue the ALTER SYSTEM CHECKPOINT statement. If the operation is successful, then the active redo log becomes inactive, and you can follow the procedure in "Losing an Inactive Online Redo Log Group". If the operation is unsuccessful, or if your database has halted, then perform one of procedures in this section, depending on the archiving mode.
The current log is the one LGWR is currently writing to. If a LGWR I/O operation fails, then LGWR terminates and the instance fails. In this case, you must restore a backup, perform incomplete recovery, and open the database with the RESETLOGS option.
因此先還原備份但若是數據庫沒有關閉狀況下，能夠執行switch logfile後觸發ckpt 而後在clear的。 很明顯7 不須要
SQL> ALTER DATABASE CLEAR logfile group 1;
ALTER DATABASE CLEAR logfile group 1
*
ERROR at line 1:
ORA-00350: log 1 of instance oratest (thread 1) needs to be archived
ORA-00312: online log 1 thread 1: '/u02/app/oracle/oradata/oratest/redo01.log'
SQL> ALTER DATABASE CLEAR unarchived logfile group 1;
Database altered.
SQL> ALTER DATABASE CLEAR unarchived logfile group 2;
Database altered.
SQL> ALTER DATABASE CLEAR unarchived logfile group 3;
Database altered.
SQL>
1.1.4.4 loss all online redo logs
You have lost all your online redo logs. As a result, your database has crashed. You have tried to restart the database and clear the online redo log files, but when you try to open the database you get the following error.
SQL> startup
ORACLE instance started.
Total System Global Area 167395328 bytes
Fixed Size 1298612 bytes
Variable Size 142610252 bytes
Database Buffers 20971520 bytes
Redo Buffers 2514944 bytes
Database mounted.
ORA-00313: open failed for members of log group 2 of thread 1
ORA-00312: online log 2 thread 1: ,,/oracle01/oradata/orcl/redo02a.log
ORA-27037: unable to obtain file status Linux Error: 2: No such file or directory
Additional information: 3
ORA-00312: online log 2 thread 1: ,,/oracle01/oradata/orcl/redo02.log
ORA-27037: unable to obtain file
status Linux Error: 2: No such file or directory Additional information: 3
SQL> alter database clear logfile group 2;
alter database clear logfile group 2
* ERROR at line 1:
ORA-01624: log 2 needed for crash recovery of instance orcl (thread 1) ORA-00312: online log 2 thread
1: ,,/oracle01/oradata/orcl/redo02.log ORA-00312: online log 2 thread
1: ,,/oracle01/oradata/orcl/redo02a.log
What steps must you take to resolve the error?
A. Issue the recover database redo logs command.
B. Issue the Startup Mount command to mount the database.
C. Restore the last full database backup.
D. Perform a point-in-time recovery, applying all archived redo logs that are available.
E. Restore all archived redo logs generated during and after the last full database backup.
F. Open the database using the alter database open resetlogs command.
G. Issue the alter database open command.
A. b, a, f
B. e, b, a, f
C.e, b, a, g
D.b, a, g
E. c, e, b, d, f
Answer: E
You are trying to recover your database. During the recovery process, you receive the following error:
ORA-00279: change 5033391 generated at 08/17/2008 06:37:40 needed for thread 1ORA-00289:
suggestion:
/oracle01/flash_recovery_area/ORCL/archivelog/2008_08_17
/o1_mf_1_11_%u_.arc
ORA-00280: change 5033391 for thread 1 is in sequence #11
ORA-00278: log
file ,,/oracle01/flash_recovery_area/ORCL/archivelog/2008_08_17
/o1_mf_1_10_4bj6wnqm_.arc no longer needed for this recovery Specify log:
{=suggested | filename | AUTO | CANCEL}
ORA-00308: cannot open archived log
,,/oracle01/flash_recovery_area/ORCL/archivelog/2008_08_17
/o1_mf_1_11_%u_.arc
ORA-27037: unable to obtain file status Linux Error: 2: No such file or directory Additional information: 3
How do you respond to this error? (Choose two.)
A. Restore the archived redo log that is missing and attempt recovery again.
B. Recovery is complete and you can open the database.
C. Recovery needs redo that is not available in any archived redo log. Attempt to apply an online redo log if available.
D. Recover the entire database and apply all archived redo logs again.
E. Recovery is not possible because an archived redo log has been lost.
Answer: AC
1.1.4.5 數據庫未掛掉的狀況下的恢復
參考：【RMAN】rm -rf 誤操做的恢復過程----數據庫在無備份且open狀況下的恢復
1.2 恢復archivelog介紹
Given the following RMAN commands, choose the option that reflects the order required to restore your currently operational ARCHIVELOG-mode database.
A. restore database;
B. recover database;
C. shutdown immediate
D. startup
E. restore archivelog all;
F. alter database open
A. a, b, c, d, e, f
B. c, b, a, d, e, f
C. c, b, a, d, f
D. c, a, b, d
E. c, a, e, b, d, f
Answer: E
還原歸檔日誌一般狀況下是Oracle在recover時自動完成的。當數據庫出現問題,但不須要restore只需recover時,發現要用到的archivelog已經備份並刪除了,由於咱們備份archivelog通常是採用delete input的,這時先須要restore archivelog,而後才能作recover,下面介紹一下restore archivelog的用法:
restore archivelog後面能夠跟的參數有"all, from, high, like, logseq, low, scn, sequence, time, until"
1.2.1 恢復歸檔
備份全部歸檔日誌文件
RMAN> backup archivelog all delete input;
1.2.1.1 restore archivelog 的各類選項
1.恢復所有歸檔日誌文件
RMAN> restore archivelog all;
2.只恢復5到8這四個歸檔日誌文件
RMAN> restore archivelog from logseq 5 until logseq 8;
3.恢復從第5個歸檔日誌起
RMAN> restore archivelog from logseq 5;
4.恢復7天內的歸檔日誌
RMAN> restore archivelog from time 'sysdate-7';
5. sequence between 寫法
RMAN> restore archivelog sequence between 1 and 3;
6.恢復到哪一個日誌文件爲止
RMAN> restore archivelog until logseq 3;
7.從第五個日誌開始恢復
RMAN> restore archivelog low logseq 5;
8.到第5個日誌爲止
RMAN> restore archivelog high logseq 5;
恢復指定的archivelog：restore archivelog sequence 18;
--若歸檔日誌不在本地，則須要恢復相應的歸檔日誌到本地目錄。
run {allocate channel ci type disk;
set archivelog destination to '/tmp';
restore archvielog from logseq xxx until logseq xxx;
release channel ci;
};
1.列出已經備份的archivelog
list backup of archivelog all;
2.預覽恢復出程,但不真正恢復,能夠在你執行恢復前先看看恢復過程,也能夠驗證一下你的語法是否寫對
restore archivelog all preview; 即在你要執行的restore archivelog命令後加preview
restore archivelog sequence 18 preview;
3.恢復指定時間範圍的archivelog
3.1 顯示2008-08-13 10:00:00到2008-08-13 11:00:00之間的archivelog
list backup of archivelog time between "to_date('2008-08-13 10:00:00','yyyy-mm-dd hh24:mi:ss')" and "to_date('2008-08-13 11:00:00','yyyy-mm-dd hh24:mi:ss')";
3.2 預覽恢復2008-08-13 10:00:00到2008-08-13 11:00:00之間的archivelog
restore archivelog time between "to_date('2008-08-13 10:00:00','yyyy-mm-dd hh24:mi:ss')" and "to_date('2008-08-13 11::00','yyyy-mm-dd hh24:mi:ss')" preview;
3.3 真正恢復2008-08-13 10:00:00到2008-08-13 11:00:00之間的archivelog
restore archivelog time between "to_date('2008-08-13 10:00:00','yyyy-mm-dd hh24:mi:ss')" and "to_date('2008-08-13 11::00','yyyy-mm-dd hh24:mi:ss')"
4.恢復指定的archivelog
restore archivelog sequence 18;
恢復sequence爲18的archivelog
5.restore archivelog like恢復模糊查詢出來的archivelog,這個只能用於經過catalog的備份,用nocatalog的會報錯
restore archivelog like '%18%';
6.恢復指定sequence範圍的archivelog
restore archivelog from sequence 18 until sequence 20;
或restore archivelog low sequence 18 high sequence 20;
或restore archivelog low logseq 18 high logseq 20;
restore archivelog from logseq 5;
7.指定archivelog的恢復目的地,如你想把archivelog恢復到一個臨時目錄時有用,但這個必須包含在run{}裏面才能用
set archivelog destination to 'e:\temp';
以上基本上能夠解決你恢復archivelog的需求,我是在10.2.0.4版本中測試經過的---------------------------------------------
如下部分是在本人正式環境中遇到的實際狀況，非轉載:
備份日誌中有如下內容:
通道 t1: 正在指定備份集中的存檔日誌
輸入存檔日誌線程 =1 序列 =18070 記錄 ID=35794 時間戳=671966051
輸入存檔日誌線程 =1 序列 =18071 記錄 ID=35796 時間戳=671966351
輸入存檔日誌線程 =1 序列 =18072 記錄 ID=35798 時間戳=671966652
輸入存檔日誌線程 =1 序列 =18073 記錄 ID=35800 時間戳=671966952
輸入存檔日誌線程 =1 序列 =18074 記錄 ID=35802 時間戳=671967249
輸入存檔日誌線程 =1 序列 =18075 記錄 ID=35804 時間戳=671967550
輸入存檔日誌線程 =1 序列 =18076 記錄 ID=35806 時間戳=671967850
輸入存檔日誌線程 =1 序列 =18077 記錄 ID=35808 時間戳=671968151
輸入存檔日誌線程 =1 序列 =18078 記錄 ID=35810 時間戳=671968451
單獨恢復18071 到18076
rman> run
{ allocate channel t1 type 'sbt_tape' parms 'ENV=(tdpo_optfile=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt)';
restore archivelog from logseq 18071 until logseq 18076 ;
release channel t1;
}
1.備份全部歸檔日誌文件
RMAN> backup archivelog all delete input;
Starting backup at 02-JUN-08
current log archived
using channel ORA_DISK_1
skipping archive log file D:\ARCHPAUL\ARC00001.001; already backed up 1 time(s)
skipping archive log file D:\ARCHPAUL\PUBTEST_1_2.DBF; already backed up 1 time(
s)
skipping archive log file D:\ARCHPAUL\PUBTEST_1_3.DBF; already backed up 1 time(
s)
skipping archive log file D:\ARCHPAUL\PUBTEST_1_4.DBF; already backed up 1 time(
s)
skipping archive log file D:\ARCHPAUL\PUBTEST_1_5.DBF; already backed up 1 time(
s)
skipping archive log file D:\ARCHPAUL\PUBTEST_1_6.DBF; already backed up 1 time(
s)
skipping archive log file D:\ARCHPAUL\PUBTEST_1_7.DBF; already backed up 1 time(
s)
skipping archive log file D:\ARCHPAUL\PUBTEST_1_8.DBF; already backed up 1 time(
s)
skipping archive log file D:\ARCHPAUL\PUBTEST_1_9.DBF; already backed up 1 time(
s)
skipping archive log file D:\ARCHPAUL\PUBTEST_1_10.DBF; already backed up 1 time
(s)
skipping archive log file D:\ARCHPAUL\PUBTEST_1_11.DBF; already backed up 1 time
(s)
skipping archive log file D:\ARCHPAUL\PUBTEST_1_12.DBF; already backed up 1 time
(s)
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=13 recid=128 stamp=656353510
channel ORA_DISK_1: starting piece 1 at 02-JUN-08
channel ORA_DISK_1: finished piece 1 at 02-JUN-08
piece handle=D:\BACKUP\2QJHUA76_1_1 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
channel ORA_DISK_1: deleting archive log(s)
archive log filename=D:\ARCHPAUL\PUBTEST_1_13.DBF recid=128 stamp=656353510
channel ORA_DISK_1: deleting archive log(s)
archive log filename=D:\ARCHPAUL\ARC00001.001 recid=116 stamp=656352824
archive log filename=D:\ARCHPAUL\PUBTEST_1_2.DBF recid=117 stamp=656353339
archive log filename=D:\ARCHPAUL\PUBTEST_1_3.DBF recid=118 stamp=656353340
archive log filename=D:\ARCHPAUL\PUBTEST_1_4.DBF recid=119 stamp=656353340
archive log filename=D:\ARCHPAUL\PUBTEST_1_5.DBF recid=120 stamp=656353369
archive log filename=D:\ARCHPAUL\PUBTEST_1_6.DBF recid=121 stamp=656353370
archive log filename=D:\ARCHPAUL\PUBTEST_1_7.DBF recid=122 stamp=656353375
archive log filename=D:\ARCHPAUL\PUBTEST_1_8.DBF recid=123 stamp=656353376
archive log filename=D:\ARCHPAUL\PUBTEST_1_9.DBF recid=124 stamp=656353382
archive log filename=D:\ARCHPAUL\PUBTEST_1_10.DBF recid=125 stamp=656353384
archive log filename=D:\ARCHPAUL\PUBTEST_1_11.DBF recid=126 stamp=656353386
archive log filename=D:\ARCHPAUL\PUBTEST_1_12.DBF recid=127 stamp=656353465
Finished backup at 02-JUN-08
Starting Control File and SPFILE Autobackup at 02-JUN-08
piece handle=D:\BACKUP\C-799229701-20080602-0C comment=NONE
Finished Control File and SPFILE Autobackup at 02-JUN-08
第二: restore archivelog 的各類選項
1.restore archivelog all 恢復所有歸檔日誌文件
RMAN> restore archivelog all;
Starting restore at 02-JUN-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=1
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=2
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=3
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=4
channel ORA_DISK_1: restoring archive log
- 1. RMAN備份與恢復系列之redo日誌文件恢復
- 2. 達夢-REDO日誌丟失或損壞-恢復測試
- 3. oracle12.2 dataguard 丟失歸檔日誌恢復
- 4. Oracle DG日誌丟失恢復
- 5. 數據庫日誌文件丟失時的恢復步驟
- 6. Oracle在線 redo log文件丟失後的恢復
- 7. undo數據文件丟失的恢復
- 8. Typora如何恢復丟失的文件?
- 9. Oracle日誌文件丟失後恢復操做流程
- 10. oracle數據丟失恢復
- 更多相關文章...
- • MySQL數據庫恢復（LOAD DATA） - MySQL教程
- • ionic 複選框 - ionic 教程
- • Docker容器實戰(七) - 容器眼光下的文件系統
- • SpringBoot中properties文件不能自動提示解決方法
-
每一个你不满意的现在，都有一个你没有努力的曾经。