How to recover a data file that was deleted by RM without using the Rman tool

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