恢復資料庫出現ORA-38727

yangtingkun發表於2012-04-16

一個測試資料庫在恢復時出現ORA-38727錯誤。

 

 

錯誤資訊如下:

[orat1@hpserver2 ~]$ rman target /

Recovery Manager: Release 10.2.0.3.0 - Production on Sat Apr 14 09:56:01 2012

Copyright (c) 1982, 2005, Oracle. All rights reserved.

connected to target database: TEST10G (DBID=1030910857)

RMAN> recover tablespace tbs013;

Starting recover at 14-APR-12
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=138 devtype=DISK

starting media recovery
media recovery failed
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 04/14/2012 09:57:45
ORA-00283: recovery session canceled due to errors
RMAN-11003: failure during parse/execution of SQL statement: alter database recover if needed
tablespace TBS013
ORA-00283: recovery session canceled due to errors
ORA-38727: FLASHBACK DATABASE requires a current control file.

RMAN> exit

Recovery Manager complete.

顯然導致這個錯誤的原因和FLASHBACK特性有關,檢查資料庫,果然發現FLASHBACK屬性出於ON的狀態:

[orat1@hpserver2 ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.3.0 - Production on Sat Apr 14 09:57:57 2012

Copyright (c) 1982, 2006, Oracle. All Rights Reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

SQL> set pages 100 lines 140
SQL> select dbid, name, flashback_on from v$database;

DBID NAME      FLASHBACK_ON
---------- --------- ------------------
1030910857 TEST10G   YES

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area 314572800 bytes
Fixed Size 2072384 bytes
Variable Size 171966656 bytes
Database Buffers 134217728 bytes
Redo Buffers 6316032 bytes
Database mounted.
SQL> alter database flashback off;

Database altered.

SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

再次執行恢復操作:

[orat1@hpserver2 ~]$ rman target /

Recovery Manager: Release 10.2.0.3.0 - Production on Sat Apr 14 10:01:03 2012

Copyright (c) 1982, 2005, Oracle. All rights reserved.

connected to target database: TEST10G (DBID=1030910857, not open)

RMAN> recover tablespace tbs013;

Starting recover at 14-APR-12
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK

starting media recovery
media recovery failed
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 04/14/2012 10:02:06
ORA-00283: recovery session canceled due to errors
RMAN-11003: failure during parse/execution of SQL statement: alter database recover if needed
tablespace TBS013
ORA-00283: recovery session canceled due to errors
ORA-01110: data file 11: '/t1/orat1/oradata/test10g_s/tbs013.dbf'
ORA-01157: cannot identify/lock data file 11 - see DBWR trace file
ORA-01110: data file 11: '/t1/orat1/oradata/test10g_s/tbs013.dbf'

RMAN> restore tablespace tbs013;

Starting restore at 14-APR-12
using channel ORA_DISK_1

skipping datafile 11; already restored to file /t1/orat1/oradata/test10g_s/tbs013.dbf
restore not done; all files readonly, offline, or already restored
Finished restore at 14-APR-12

RMAN> recover tablespace tbs013;

Starting recover at 14-APR-12
using channel ORA_DISK_1

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 04/14/2012 10:03:05
RMAN-06067: RECOVER DATABASE required with a backup or created control file

RMAN> recover database;

Starting recover at 14-APR-12
using channel ORA_DISK_1

starting media recovery

archive log thread 1 sequence 356 is already on disk as file /t1/orat1/arch_s/1_356_779468996.dbf
archive log thread 1 sequence 357 is already on disk as file /t1/orat1/arch_s/1_357_779468996.dbf
archive log thread 1 sequence 358 is already on disk as file /t1/orat1/arch_s/1_358_779468996.dbf
archive log thread 1 sequence 359 is already on disk as file /t1/orat1/arch_s/1_359_779468996.dbf
archive log thread 1 sequence 360 is already on disk as file /t1/orat1/arch_s/1_360_779468996.dbf
archive log thread 1 sequence 361 is already on disk as file /t1/orat1/arch_s/1_361_779468996.dbf
archive log thread 1 sequence 362 is already on disk as file /t1/orat1/arch_s/1_362_779468996.dbf
archive log thread 1 sequence 363 is already on disk as file /t1/orat1/arch_s/1_363_779468996.dbf
archive log thread 1 sequence 364 is already on disk as file /t1/orat1/arch_s/1_364_779468996.dbf
archive log thread 1 sequence 365 is already on disk as file /t1/orat1/arch_s/1_365_779468996.dbf
archive log thread 1 sequence 366 is already on disk as file /t1/orat1/arch_s/1_366_779468996.dbf
archive log thread 1 sequence 367 is already on disk as file /t1/orat1/arch_s/1_367_779468996.dbf
archive log thread 1 sequence 368 is already on disk as file /t1/orat1/arch_s/1_368_779468996.dbf
archive log thread 1 sequence 369 is already on disk as file /t1/orat1/arch_s/1_369_779468996.dbf
archive log thread 1 sequence 370 is already on disk as file /t1/orat1/arch_s/1_370_779468996.dbf
archive log thread 1 sequence 371 is already on disk as file /t1/orat1/arch_s/1_371_779468996.dbf
archive log thread 1 sequence 372 is already on disk as file /t1/orat1/arch_s/1_372_779468996.dbf
archive log thread 1 sequence 373 is already on disk as file /t1/orat1/arch_s/1_373_779468996.dbf
archive log thread 1 sequence 374 is already on disk as file /t1/orat1/arch_s/1_374_779468996.dbf
archive log thread 1 sequence 375 is already on disk as file /t1/orat1/arch_s/1_375_779468996.dbf
archive log thread 1 sequence 376 is already on disk as file /t1/orat1/arch_s/1_376_779468996.dbf
archive log thread 1 sequence 377 is already on disk as file /t1/orat1/arch_s/1_377_779468996.dbf
archive log thread 1 sequence 378 is already on disk as file /t1/orat1/arch_s/1_378_779468996.dbf
archive log thread 1 sequence 379 is already on disk as file /t1/orat1/arch_s/1_379_779468996.dbf
archive log thread 1 sequence 380 is already on disk as file /t1/orat1/arch_s/1_380_779468996.dbf
archive log thread 1 sequence 381 is already on disk as file /t1/orat1/arch_s/1_381_779468996.dbf
archive log thread 1 sequence 382 is already on disk as file /t1/orat1/arch_s/1_382_779468996.dbf
archive log thread 1 sequence 383 is already on disk as file /t1/orat1/arch_s/1_383_779468996.dbf
archive log thread 1 sequence 384 is already on disk as file /t1/orat1/arch_s/1_384_779468996.dbf
archive log thread 1 sequence 385 is already on disk as file /t1/orat1/arch_s/1_385_779468996.dbf
archive log thread 1 sequence 386 is already on disk as file /t1/orat1/arch_s/1_386_779468996.dbf
archive log thread 1 sequence 387 is already on disk as file /t1/orat1/arch_s/1_387_779468996.dbf
archive log thread 1 sequence 388 is already on disk as file /t1/orat1/arch_s/1_388_779468996.dbf
archive log thread 1 sequence 389 is already on disk as file /t1/orat1/oradata/test10g_s/redo02.log
archive log thread 1 sequence 390 is already on disk as file /t1/orat1/oradata/test10g_s/redo03.log
archive log thread 1 sequence 391 is already on disk as file /t1/orat1/oradata/test10g_s/redo01.log
archive log filename=/t1/orat1/arch_s/1_356_779468996.dbf thread=1 sequence=356
archive log filename=/t1/orat1/arch_s/1_357_779468996.dbf thread=1 sequence=357
archive log filename=/t1/orat1/arch_s/1_358_779468996.dbf thread=1 sequence=358
archive log filename=/t1/orat1/arch_s/1_359_779468996.dbf thread=1 sequence=359
archive log filename=/t1/orat1/arch_s/1_360_779468996.dbf thread=1 sequence=360
archive log filename=/t1/orat1/arch_s/1_361_779468996.dbf thread=1 sequence=361
archive log filename=/t1/orat1/arch_s/1_362_779468996.dbf thread=1 sequence=362
archive log filename=/t1/orat1/arch_s/1_363_779468996.dbf thread=1 sequence=363
archive log filename=/t1/orat1/arch_s/1_364_779468996.dbf thread=1 sequence=364
archive log filename=/t1/orat1/arch_s/1_365_779468996.dbf thread=1 sequence=365
archive log filename=/t1/orat1/arch_s/1_366_779468996.dbf thread=1 sequence=366
archive log filename=/t1/orat1/arch_s/1_367_779468996.dbf thread=1 sequence=367
archive log filename=/t1/orat1/arch_s/1_368_779468996.dbf thread=1 sequence=368
archive log filename=/t1/orat1/arch_s/1_369_779468996.dbf thread=1 sequence=369
archive log filename=/t1/orat1/arch_s/1_370_779468996.dbf thread=1 sequence=370
archive log filename=/t1/orat1/arch_s/1_371_779468996.dbf thread=1 sequence=371
archive log filename=/t1/orat1/arch_s/1_372_779468996.dbf thread=1 sequence=372
archive log filename=/t1/orat1/arch_s/1_373_779468996.dbf thread=1 sequence=373
archive log filename=/t1/orat1/arch_s/1_374_779468996.dbf thread=1 sequence=374
archive log filename=/t1/orat1/arch_s/1_375_779468996.dbf thread=1 sequence=375
archive log filename=/t1/orat1/arch_s/1_376_779468996.dbf thread=1 sequence=376
archive log filename=/t1/orat1/arch_s/1_377_779468996.dbf thread=1 sequence=377
archive log filename=/t1/orat1/arch_s/1_378_779468996.dbf thread=1 sequence=378
archive log filename=/t1/orat1/arch_s/1_379_779468996.dbf thread=1 sequence=379
archive log filename=/t1/orat1/arch_s/1_380_779468996.dbf thread=1 sequence=380
archive log filename=/t1/orat1/arch_s/1_381_779468996.dbf thread=1 sequence=381
archive log filename=/t1/orat1/arch_s/1_382_779468996.dbf thread=1 sequence=382
archive log filename=/t1/orat1/arch_s/1_383_779468996.dbf thread=1 sequence=383
archive log filename=/t1/orat1/arch_s/1_384_779468996.dbf thread=1 sequence=384
archive log filename=/t1/orat1/arch_s/1_385_779468996.dbf thread=1 sequence=385
archive log filename=/t1/orat1/arch_s/1_386_779468996.dbf thread=1 sequence=386
archive log filename=/t1/orat1/arch_s/1_387_779468996.dbf thread=1 sequence=387
archive log filename=/t1/orat1/arch_s/1_388_779468996.dbf thread=1 sequence=388
archive log filename=/t1/orat1/oradata/test10g_s/redo02.log thread=1 sequence=389
archive log filename=/t1/orat1/oradata/test10g_s/redo03.log thread=1 sequence=390
archive log filename=/t1/orat1/oradata/test10g_s/redo01.log thread=1 sequence=391
media recovery complete, elapsed time: 00:00:15
Finished recover at 14-APR-12

RMAN> alter database open;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 04/14/2012 10:06:34
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

RMAN> alter database open resetlogs;

database opened

雖然恢復成功,但是可以看到恢復過程並不順利,最明顯的一點,本來一個簡單的TABLESPACE的恢復,變成了DATABASE的恢復,而且本來可以直接開啟,現在變成了RESETLOGS方式的開啟。這也說明由於啟用了FLASHBACK,導致Oracle在判斷控制檔案狀態出現了異常,導致最終以RESETLOGS方式開啟資料庫。

其實這個錯誤和不久前碰到的RMAN-600錯誤有直接的關聯:

RMAN-600(8201)錯誤:

RMAN-600(8201)錯誤的重現:

而且正如我們所料,當前資料庫再次RESETLOGS後,目前控制檔案中最大的RESETLOGS時間對應的正式當前控制檔案中記錄的RESETLOGS時間,這就使得CATALOG的同步得以實現:

[orat1@hpserver2 ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.3.0 - Production on Sun Apr 15 00:09:12 2012

Copyright (c) 1982, 2006, Oracle. All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options

SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
[orat1@hpserver2 ~]$ rman target / catalog rcat_user/rcat_password

Recovery Manager: Release 10.2.0.3.0 - Production on Sun Apr 15 00:09:31 2012

Copyright (c) 1982, 2005, Oracle. All rights reserved.

connected to target database: TEST10G (DBID=1030910857)
connected to recovery catalog database

RMAN> show all;

new incarnation of database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 5 BACKUP TYPE TO BACKUPSET;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/t1/orat1/product/10.2.0/db_1/dbs/snapcf_test10g_s.f'; # default

RMAN>

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/4227/viewspace-721635/,如需轉載,請註明出處,否則將追究法律責任。

相關文章