Friends on the rise of the use of rm**, delete the Oracle data file after I help, I am helping friends to restore the database, encountered when recover, error can not find the number No. 28739 archive log, so I can not sync SCN, but also can not open the database. This is a typical case of an archived log discontinuity, and I finally told him to be prepared for it. It's not over yet, this real case has caused me to think that if the friend did not do the Rman rescue measures, it is impossible not to use Rman can recover data files! Finally I found the answer:
Case
1. System Solaris SunOS tjlt-ydwg6 5.9 generic_122300-25 sun4u SPARC sunw,sun-fire-v890
DB oracledatabase 10g Enterprise Edition Release 10.2.0.1.0-64bi
2. Description of the case
The field engineer used the RM-RF *.dbf command to delete all the data files.
There's a May 4 backup now.
Restore database until Time "to_date (' 2012-05-04 12:00:00 ', ' yyyy-mm-dd hh24:mi:ss ')"; Perform restore show finish restore complete no problem, we've copied the files back.
To synchronize
rman> recover database until Time "to_date (' 2012-05-04 11:00:00 ', ' yyyy-mm-dd hh24:mi:ss ')";
Starting recover at 2012-07-26 14:02:42
Using channel Ora_disk_1
Starting Media recovery
Unable to find archive log
Archive log thread=1 sequence=28739 missing number No. 28739 archive log, resulting in undotbs01.dbf file inconsistencies
Oracle Error:
Ora-01547:warning:recover succeeded but OPEN Resetlogs would get error below
Ora-01194:file 2 needs more recovery to be consistent
Ora-01110:data file 2: '/OPT/ORADATA/KPIDB/UNDOTBS01.DBF '
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR message STACK follows ===============
RMAN-00571: ===========================================================
Rman-03002:failure of recover command at 07/26/2012 14:02:51
Rman-06054:media recovery requesting unknown Log:thread 1 seq 28739 lowscn 1513525474
Leonarding
2012.7.26
In our work, it's possible that this kind of unexpected situation often happens, in this case, the first thing to do is to calm down, the problem that occurred to me after that, I found that the database has become a mount state, in the use of file handles to recover the data file is too late, so I used the general recovery method , unexpectedly ah unexpectedly, archive log is not complete, immediately I whole person "spartan", finally tell a friend to do DBA need courage.
Below I use my own test library to demonstrate the operating system RM-level Delete data files, the database is still in the open state when the use of file handles to restore the RM deleted data files, and finally successfully open the database experiment! I am a more rigorous person, so I first made a "compressed whole library backup" to be prepared
Describe the scene:
Operating system: Enterprise Linux Enterprise Linux as Release 4 (October Update 8)
DB version: Oracle database 10g Enterprise Edition release 10.2.0.1.0-prod
Backup is more important than everything.
So let's do a backup before we do the demo.
Rman> Show All;
Rman configuration parameter area, as below are default values
RMAN configuration parameters are:
Redundant configuration Retention Policy: redundancy number is 1
CONFIGURE RETENTION POLICY to redundancy 1; # Default
Turn on incremental backup: Off
CONFIGURE BACKUP optimization off; # Default
The default backup device is disk
CONFIGURE DEFAULT DEVICE TYPE to DISK; # Default
Control file Automatic backup: Off
CONFIGURE Controlfile autobackup off; # Default
Control file Automatic backup directory and format:%F "Backup device: Disk"
CONFIGURE controlfile autobackup FORMAT for DEVICE TYPE DISK to '%F '; # Default
Degree of parallelism of Backup: 1, Backup type is backup set
CONFIGURE DEVICE type DISK PARALLELISM 1 BACKUP type to backupset; # Default
Data files are backed up by replication
CONFIGURE datafile BACKUP copies for DEVICE TYPE DISK to 1; # Default
Archive log backup by replication
CONFIGURE Archivelog BACKUP copies for DEVICE TYPE DISK to 1; # Default
Maximum: Unlimited
CONFIGURE maxsetsize to unlimited; # Default
Encrypted database: Off
CONFIGURE encryption for DATABASE off; # Default
Encryption algorithm using AES128
CONFIGURE encryption algorithm ' AES128 '; # Default
Archive Log deletion policy: null