Incomplete recovery after open resetlogs

hi gurus
Every sunday,consistent backups are performed on your database.Because of a user error,you performed an incomplete recovery on Tuesday and opened the database with RESETLOGS option.
A user error occurs again on Thursday,whick necessitates an incomplete recovery.Sunday's bakcup is the most recent backup avaliable.
what would you do in this scenario？
A. recovery cannot be performed because backup was not performed after the last incomplete recovery.
B. restore all backups from Sunday's backup,and then perform an incomplete recovery up to the point in time when the user error occured Thursday.
C. restore all the files from Sunday's backup,and then recover up to the point in time when the RESETLOGS operation was performed on Tuesday.
D. restore all the file from Sunday's backup, and open the database to reset the database to the point in time when the backup was performed on Sunday.
I choose C but answer gives B. what do u think?
thank u in advance.

As of oracle 10g, it is possible to restore and recover across RESETLOGS operations: see http://download.oracle.com/docs/cd/B19306_01/backup.102/b14192/flashptr006.htm#sthref667. So B is correct for 10g or 11g.

Similar Messages

Simplify recovery after opening the database with the RESETLOGS option

Hi All,
I just have doubt ,regarding the topic which is given in Oracle 11g Exam Syllabus for upgrading from 9i to 11g OCP.The opic is
*"Simplify recovery after opening the database with the RESETLOGS option"* in this topic what one need to study.
As i am little bit confuse related to "Recovery through RESETLOGS and reset of the incarnation of the database".
Kindly correct me if i am wrong
Thanks in advance

vk82 wrote:
Hi All,
I just have doubt ,regarding the topic which is given in Oracle 11g Exam Syllabus for upgrading from 9i to 11g OCP.The opic is
*"Simplify recovery after opening the database with the RESETLOGS option"* in this topic what one need to study.
As i am little bit confuse related to "Recovery through RESETLOGS and reset of the incarnation of the database".
Kindly correct me if i am wrong
Thanks in advanceyou are correct so you can mark this thread as answered
Handle:     vk82
Status Level:     Newbie (35)
Registered:     Nov 21, 2010
Total Posts:     733
Total Questions:     180 (115 unresolved)

Error during restore/recovery and 'open resetlogs'

Hello forum. I'm attempting to restore a database to a new host and have run into an error during the opening of the database (with resetlogs). The renaming of the datafiles, restore, switching of datafiles, and recovery are all done by an rman script, the contents of which are below:
# Restore production database to DR site using file system
# instead of ASM
run {
set newname for datafile 1 to '/opt/oracle/product/10gR2/oradata/DB01/system.dbf';
set newname for datafile 2 to '/opt/oracle/product/10gR2/oradata/DB01/undotbs1.dbf';
set newname for datafile 3 to '/opt/oracle/product/10gR2/oradata/DB01/sysaux.dbf';
set newname for datafile 4 to '/opt/oracle/product/10gR2/oradata/DB01/users.dbf';
set newname for datafile 5 to '/opt/oracle/product/10gR2/oradata/DB01/undotbs2.dbf';
set newname for datafile 6 to '/opt/oracle/product/10gR2/oradata/DB01/file1.dbf';
set newname for datafile 7 to '/opt/oracle/product/10gR2/oradata/DB01/file2.dbf';
restore database;
switch datafile all;
recover database;
I get the following output:
RMAN> @/home/oracle/scripts/rman_dr.rman
RMAN> # Restore production database to DR site using file system
2> # instead of ASM
3> #
4> run {
5> set newname for datafile 1 to '/opt/oracle/product/10gR2/oradata/DB01/system.dbf';
6> set newname for datafile 2 to '/opt/oracle/product/10gR2/oradata/DB01/undotbs1.dbf';
7> set newname for datafile 3 to '/opt/oracle/product/10gR2/oradata/DB01/sysaux.dbf';
8> set newname for datafile 4 to '/opt/oracle/product/10gR2/oradata/DB01/users.dbf';
9> set newname for datafile 5 to '/opt/oracle/product/10gR2/oradata/DB01/undotbs2.dbf';
10> set newname for datafile 6 to '/opt/oracle/product/10gR2/oradata/DB01/file1.dbf';
11> set newname for datafile 7 to '/opt/oracle/product/10gR2/oradata/DB01/file2.dbf';
12>
13> restore database;
14> switch datafile all;
15> recover database;
16> }
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
Starting restore at 03-JAN-08
Starting implicit crosscheck backup at 03-JAN-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK
Crosschecked 651 objects
Finished implicit crosscheck backup at 03-JAN-08
Starting implicit crosscheck copy at 03-JAN-08
using channel ORA_DISK_1
Crosschecked 1 objects
Finished implicit crosscheck copy at 03-JAN-08
searching for all files in the recovery area
cataloging files...
no files cataloged
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 /opt/oracle/product/10gR2/oradata/DB01/system.dbf
restoring datafile 00002 to /opt/oracle/product/10gR2/oradata/DB01/undotbs1.dbf
restoring datafile 00003 to /opt/oracle/product/10gR2/oradata/DB01/sysaux.dbf
restoring datafile 00004 to /opt/oracle/product/10gR2/oradata/DB01/users.dbf
restoring datafile 00005 to /opt/oracle/product/10gR2/oradata/DB01/undotbs2.dbf
restoring datafile 00006 to /opt/oracle/product/10gR2/oradata/DB01/file1.dbf
restoring datafile 00007 to /opt/oracle/product/10gR2/oradata/DB01/file2.dbfchannel ORA_DISK_1: reading from backup piece /ocfs2/remitpro/oracleBackups/tmp/rman_LV0_DB01.642899284.1.1.bus
channel ORA_DISK_1: restored backup piece 1
piece handle=/ocfs2/remitpro/oracleBackups/tmp/rman_LV0_DB01.642899284.1.1.bus tag=20080101_LV0_DB
channel ORA_DISK_1: restore complete, elapsed time: 01:22:28
Finished restore at 03-JAN-08
datafile 1 switched to datafile copy
input datafile copy recid=14 stamp=643049225 filename=/opt/oracle/product/10gR2/oradata/DB01/system.dbf
datafile 2 switched to datafile copy
input datafile copy recid=15 stamp=643049225 filename=/opt/oracle/product/10gR2/oradata/DB01/undotbs1.dbf
datafile 3 switched to datafile copy
input datafile copy recid=16 stamp=643049225 filename=/opt/oracle/product/10gR2/oradata/DB01/sysaux.dbf
datafile 4 switched to datafile copy
input datafile copy recid=17 stamp=643049225 filename=/opt/oracle/product/10gR2/oradata/DB01/users.dbf
datafile 5 switched to datafile copy
input datafile copy recid=18 stamp=643049225 filename=/opt/oracle/product/10gR2/oradata/DB01/undotbs2.dbf
datafile 6 switched to datafile copy
input datafile copy recid=19 stamp=643049225 filename=/opt/oracle/product/10gR2/oradata/DB01/file1.dbf
datafile 7 switched to datafile copy
input datafile copy recid=20 stamp=643049225 filename=/opt/oracle/product/10gR2/oradata/DB01/file2.dbf
Starting recover at 03-JAN-08
using channel ORA_DISK_1
starting media recovery
channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=2 sequence=1005
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=1365
channel ORA_DISK_1: reading from backup piece /ocfs2/remitpro/oracleBackups/tmp/rman_LV0_DB01.642900444.1.1.bus
channel ORA_DISK_1: restored backup piece 1
piece handle=/ocfs2/remitpro/oracleBackups/tmp/rman_LV0_DB01.642900444.1.1.bus tag=20080101_LV0_DB
channel ORA_DISK_1: restore complete, elapsed time: 00:00:05
archive log filename=/opt/oracle/product/10gR2/db/flash_recovery_area/DB01/archivelog/2008_01_03/o1_mf_1_1365_3qtshnfv_.arc thread=1 sequence=1365
archive log filename=/opt/oracle/product/10gR2/db/flash_recovery_area/DB01/archivelog/2008_01_03/o1_mf_2_1005_3qtshncz_.arc thread=2 sequence=1005
channel default: deleting archive log(s)
archive log filename=/opt/oracle/product/10gR2/db/flash_recovery_area/DB01/archivelog/2008_01_03/o1_mf_1_1365_3qtshnfv_.arc recid=2418 stamp=643049236
unable to find archive log
archive log thread=1 sequence=1366
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 01/03/2008 16:47:22
RMAN-06054: media recovery requesting unknown log: thread 1 seq 1366 lowscn 181804603
RMAN> **end-of-file**
I searched for a decription of the 06054 error, and found that if the archive logs weren't available, then to run "alter database open resetlogs;", which I did. Here's the output:
RMAN> alter database open resetlogs;
database opened
RMAN-06900: WARNING: unable to generate V$RMAN_STATUS or V$RMAN_OUTPUT row
RMAN-06901: WARNING: disabling update of the V$RMAN_STATUS and V$RMAN_OUTPUT rows
ORACLE error from target database:
ORA-06553: PLS-801: internal error [56319]
I've done all of this twice now, with the same result. I've googled PLS-801 and found more than a few instances of people getting this code, but not during a database open after a restore. Can anyone shed some light on what might have gone wrong? In the interest of brevity, I left out the rest of the restore process prior to running the database restore, but other than setting "compatible" and "db_recovery_file_dest_size", it was all by the book.
Thanks in advance.

Thanks for the reply Pierre.
I am not using RMAN Duplicate. Yes, the source of the backup is an RAC. The destination is a single server, with the DB on the filesystem. Here's an overview of of the commands I ran and the procedure.
Copied tar'd backup controlfile and datafiles to destination machine. Untar'd. Install 10.2.0.1.0 on destination machine, patch to 10.2.0.2.0.
OS> sqlplus /nologin
SQL> alter system set compatible = '10.2.0.2.0' scope=spfile;
SQL> alter system set db_recovery_dest_file_size = '8g'; scope spfile;
SQL> shutdown immediate;
SQL> startup; (to verify changes took...)
SQL> shutdown immediate;
OS> Copy control file from untar'd dir and place in $ORACLE_HOME/dbs/, truncate name to c-DBID-date-00.
OS> rman target /
RMAN> startup nomount;
RMAN> set dbid <dbid from control file>;
RMAN> restore controlfile from autobackup; (finds control file with no problem...)
RMAN> alter database mount;
RMAN> @/home/oracle/rman_dr.rman (script cited in first post, to rename datafiles from ASM to filesystem, restore, switch files, and recover...)
RMAN> alter database open resetlogs; (as cited before...)
If I'm not using Duplicate and not specifying dates, the UNTIL/SET UNTIL commands aren't necessary, correct?

Incomplete Recovery After Drop Tablespace.

Hi...some technical help required.
I was trying a hands-on for incomplete recovery. That is drop a tablespace and then retrieve back until 1 second before drop statement.
The Steps were like this...
1) Shutdown Immediate;
2) Copy all *.ctl, *.dbf, logfiles into a different folder <nis_back>
3) Startup;
4) Enter 3-4 Records and Commit. Table is in <USER> Tablespace.
5) 3 times "alter system switch logfile;"
5) drop tablespace users;
6) shutdown;
7) Check the Alter Log and find the time when tablespace dropped.
Suppose time when dropped is -> 21-Aug 10:30:45 AM. (HH:MM:SS)
7) copy back only *.dbf, *.ctl files from backup folder <nis_back>
8) startup mount;
9) alter database recover automatic until time '2002-08-21:10:30:40';
10) <<Statement Process>> Message Comes.
11) alter database open resetlogs;
When I open the table into which I inserted records just before dropping the tablespace I dont see the records (Inseretd in Step - 4) but the tablespace is back.
Now My Concern -> Why did the 3-4 record which I inserted in step 4 did not get restored from the archieve log ?
Hope to hear from you all soon.
Thanks in advance.
Regards
Nishit

After step 5, try ALTER SYSTEM ARCHIVELOG ALL
Naveen
Hi...some technical help required.
I was trying a hands-on for incomplete recovery. That is drop a tablespace and then retrieve back until 1 second before drop statement.
The Steps were like this...
1) Shutdown Immediate;
2) Copy all *.ctl, *.dbf, logfiles into a different folder <nis_back>
3) Startup;
4) Enter 3-4 Records and Commit. Table is in <USER> Tablespace.
5) 3 times "alter system switch logfile;"
5) drop tablespace users;
6) shutdown;
7) Check the Alter Log and find the time when tablespace dropped.
Suppose time when dropped is -> 21-Aug 10:30:45 AM. (HH:MM:SS)
7) copy back only *.dbf, *.ctl files from backup folder <nis_back>
8) startup mount;
9) alter database recover automatic until time '2002-08-21:10:30:40';
10) <<Statement Process>> Message Comes.
11) alter database open resetlogs;
When I open the table into which I inserted records just before dropping the tablespace I dont see the records (Inseretd in Step - 4) but the tablespace is back.
Now My Concern -> Why did the 3-4 record which I inserted in step 4 did not get restored from the archieve log ?
Hope to hear from you all soon.
Thanks in advance.
Regards
Nishit

Is it possible to restore a datafile after opening the db using resetlogs?

Hi Experts,
We have cloned the db and after opening the db with resetlog option we came to know that one of the user db file is not part of the db and is showing the below error while checking the status and attempting to online it. When checking the size and availability of the dbfile it shows everything without errors.
SQL> alter database datafile 50 online;
alter database datafile 50 online
ERROR at line 1:
ORA-01122: database file 50 failed verification check
ORA-01110: data file 50:
'+DATA/orcl/orcldata.291.730828357.dbf'
ORA-01251: Unknown File Header Version read for file number 50
Thanks,
Newbie

user7490278 wrote:
Hi Experts,
We have cloned the db and after opening the db with resetlog option we came to know that one of the user db file is not part of the db and is showing the below error while checking the status and attempting to online it. When checking the size and availability of the dbfile it shows everything without errors.
SQL> alter database datafile 50 online;
alter database datafile 50 online
ERROR at line 1:
ORA-01122: database file 50 failed verification check
ORA-01110: data file 50:
'+DATA/orcl/orcldata.291.730828357.dbf'
ORA-01251: Unknown File Header Version read for file number 50
Thanks,
NewbieI suggest you review what was done, determine where the mistake was made,
then clone the DB again; but this time don't make any mistakes.

Recover Database after opening in Resetlog

Hi All,
Is it possible to recover datbase after opening it in resetlog.
Scenoria:
Due to some serious update exceuted on a particular table , I want to extract one table from previous day morning backup and apply archive still 4PM .
But after recovering the datbase still 2PM ..I opened the database with resretlog .
Now how can I apply archive generated after 2 clock.
Do I need to restore the database again?
Thanks

Do I need to restore the database again?Yes. You have to restore the database and proceed until applying archive logs upto 4pm.
RESETLOGS - Updates all current datafiles and online redo logs and all subsequent archived redo logs with a new RESETLOGS SCN and time stamp.Archives the current online redo logs (or up to the last redo record before redo corruption if corruption is found), clears the contents of the online redo logs, and resets the online redo logs to log sequence 1.

Open resetlogs after RMAN duplicate fails

Hi,
I wonder if anybody else has come across this issue, or is able to shed any light on it.
I have done a duplicate database to a new host with RMAN.
At the point where the duplicate opens the new database with resetlogs
I get this error in the alert log:
alter database open resetlogs
Tue Apr 7 02:10:06 2009
Errors in file /oracle/admin/udump/db1_ora_13931.trc:
ORA-00367: checksum error in log file header
ORA-00305: log 1 of thread 1 inconsistent; belongs to another database
ORA-00312: online log 1 thread 1: '/oracle/oradata/redo/db1_REDO_01A.log'
additional info: Oracle 10.2.0.4, Linux o/s.
thanks.

i have used the logfile keyword in the duplicate script to tell the duplicate
location and size of redologs.
duplicate target database to db1
logfile
group 1 ('/oracle/oradata/redo/db1_REDO_01A.log'
,'/oracle/oradata/redo/db1_REDO_01B.log') SIZE 200M REUSE,
group 2 ('/oracle/oradata/redo/db1_REDO_02A.log'
,'/oracle/oradata/redo/db1_REDO_02B.log') SIZE 200M REUSE,
group 3 ('/oracle/oradata/redo/db1_REDO_03A.log'
,'/oracle/oradata/redo/db1_REDO_03B.log') SIZE 200M REUSE,
group 4 ('/oracle/oradata/redo/db1_REDO_04A.log
','/oracle/oradata/redo/db1_REDO_04B.log') SIZE 200M REUSE;
my thoughts are that the resetlogs will make automatically recreate the redo logs.
there were pre-existing ones in this location, but REUSE should overcome this issue?

A problem about incomplete recovery

All,
I'm a freshman for oracle knowledge and skill. I'm simulating the incomplete recovery for database. Here are my scenarios and steps:
1. In database "db1", there is a table named "tb1" has 2 records, the whole database running on archive log mode and has 3 redo log groups(each group contains one member) ---- status "A"
2. Make a cold backup for all datafiles, controlfiles and redo logs;
3. startup database again, and insert 3 records into "tb1", then switch log file at least 3 times. Get the frist change number form latest archived log. ---- status "B"
4. after the 3rd step over, drop a tablespace named "indx" and do a switching log file operation again.
5. shutdow database immediate and restore all the backuped datafile and controlfiles, not including the redo logs and startup database with mount option.
6. run recover command to execute the incomplete recovery to database.
whatever using "recover until time '<almost close the drop operating time>" or "recover until change number", I only got the status "A" after open the database, not status "B". But as my understanding and some reference from books, it should return to status "B" which includes the newer 3 records.
Now, I adhere some alert logs at below (the number 54878 is the latest change number in archived log files before dropping that tablespace)
alter database recover until change 54878
Tue Jul 03 17:30:34 2007
Media Recovery Start
Media Recovery Not Required
Completed: alter database recover until change 54878
Tue Jul 03 17:31:35 2007
alter database open resetlogs
Tue Jul 03 17:31:35 2007
RESETLOGS after complete recovery through change 54742
why the recovery use change number 54742 but not 54878 I expected. Did I go the correct steps for this incomplete recovery. Does anyone can give me some piece of advice to resolve this problem

Are you using 'recover using backup controlfile'...???????????
If not, it will take the restored controlfiles as the latest copy and will only recover up to the SCN in there.
Using the above, Oracle will simply ignore the SCN in the controlfile, since it knows its an old controlfile and should recover beyond the restored controfile..

'alter database open resetlogs' didn't reset one of the datafiles

I've spent the last three and a half weeks recovering an oracle database (11g 64-bit linux) because of a corrupt block in an online redo log (which I thought was being written to multiple locations). I restored the files, moving some of them around in the process; recovered to the latest possible point; moved files back to their proper location; ran 'alter database open resetlogs'; and one of the datafiles (from a bigfile tablespace) didn't get reset. I checked afterward, and it was marked offline. I do not remember placing the file offline, and cannot find such a statement in my last 300 sqlplus commands, which includes commands well before I renamed this file and the commands surrounding the rename.
Restoring/recovering the database again will take too long, and is a remarkably poor option. Even if the database had opened correctly, the affected tablespace would not have been touched in the two or three minutes the database was open. Is there any way to force oracle to reset the logs again or otherwise fix this one file to mark it with the same date? Only allowing the resetlogs option after an incomplete recovery seems a poor restriction, especially, if files can slip through like this. I'm suspecting there is someway to just fix the checkpoint values for the tablespace, but I don't know where to begin. This particular file is <5% of the database, so if I have to do some sort of backup/restore with just it, that is probably doable.

0: 11.1.0.6.0 on SUSE Linux Enterprise Server 10 SP2
1: rman
backup format '/opt/oracle/backup/mydatabase_%Y-%M-%D_%s_datafiles_%p' (database);
backup format '/opt/oracle/backup/mydatabase_%Y-%M-%D_%s_archivelogs_%p' archivelog all delete input;
backup format '/opt/oracle/backup/mydatabase_%Y-%M-%D_%s_control_%p' current controlfile spfile;
2:
restore database; --not sure what datafiles were restored with this
restore datafile X; --several files were restored individually
recover database until scn 1137554504; -- I verified that all datafiles were on the same checkpoint after this finished. Not having placed any files offline, I didn't bother checking that.
3:
SQL> alter database open resetlogs;
Database altered.
Elapsed: 00:04:20.34
SQL> quit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
4: Nothing in the tablespace has been touched since I ran 'alter database open resetlogs;'. It also appears that oracle placed the file offline (without me telling it to do so) and left it that way through the resetlogs, leaving the tablespace unusable during the time it was opened. The only things that would be out of date are the 'RESETLOGS_CHANGE#', the 'CHECKPOINT_CHANGE#', and associated values. It's still at the last scn before the resetlogs, and the system has been in archivelog mode the entire time. This is all information that Oracle could be tracking, and from a program logic standpoint there is no reason why Oracle cannot tie together the changes before the resetlogs, the resetlogs command and the changes after the resetlogs into a new, continuous string of changes. I assume there is some such feature in a high-caliber program because I'm actually a programmer (who would have included such advanced tracking features), and I've become a DBA out of necessity. I admit to not knowing all of the oracle DBA commands, hence me posting here before doing the work of submitting a request to metalink.
5: I consider it a poor restriction because it doesn't always reset the logs on all files, and as far as my knowledge goes it has rendered my 3.5 week recovery process WORTHLESS. I suppose it could cause numerous errors, especially if the database wasn't cleanly shut down, but having the ability to do something equivalent to datafiles that oracle skipped the process on seems quite useful in my situation. I guess the more fundamental problem to complain about is that it would apply such changes to only some of the files, while leaving others unusable, instead of just giving me an error that some files weren't going to be reset, but I think I'm done venting my Oracle frustrations for now.
Am I stuck with a tablespace that I cannot bring online with the database open, or is there some sort of 'alter database datafile' command (or anything else) that I know nothing of that will fix the straggling file?
Edited by: jbo5112 on Oct 5, 2009 3:33 PM -- obfuscated some file names to secure identity.

Incomplete recovery in Oracle 10g

hello,
I have been trying Incomplete recovery in oracle 10g. The steps i did were.
1. Set the database in archivelog mode.
2. shutdown immediate
3. Take physical copies of control files, datafiles and redo files
4. open the database.
5. Insert three rows in test table and commit. (and note the time )
6. shutdown abort
7. copy the restored datafiles to the desired location
8. startup mount
9 recover database until time (the time noted in step 5)
10. alter database open resetlogs
After doing this, i still do not get the three records inserted in step 5.
Can anyone suggest why this is so ? am i missing something. ?
Thanx.
Trupti

Hello,
Thank you for the prompt reply.
I did what you suggested. Here are the output.
16:17:52 SQL> select * from testing.test;
NO
1
2
3
4
17:09:26 SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
*** Here i took a backup of all files.
17:10:16 SQL> startup mount;
ORACLE instance started.
Total System Global Area 167772160 bytes
Fixed Size 788224 bytes
Variable Size 66058496 bytes
Database Buffers 100663296 bytes
Redo Buffers 262144 bytes
Database mounted.
17:13:45 SQL> alter database open;
Database altered.
17:14:07 SQL> alter system switch logfile;
System altered.
17:14:17 SQL> select * from testing.test;
NO
1
2
3
4
17:14:25 SQL> insert into testing.test values(5);
1 row created.
17:14:40 SQL> insert into testing.test values(6);
1 row created.
17:14:43 SQL> insert into testing.test values(7);
1 row created.
17:14:45 SQL> commit;
Commit complete.
17:14:47 SQL> alter system switch logfile;
System altered.
17:14:50 SQL> insert into testing.test values(8);
1 row created.
17:14:55 SQL> insert into testing.test values(9);
1 row created.
17:14:57 SQL> insert into testing.test values(10);
1 row created.
17:15:00 SQL> commit;
Commit complete.
17:15:02 SQL> alter system switch logfile;
System altered.
17:15:04 SQL> shutdown abort;
ORACLE instance shut down.
*** Here i restored the datafiles
17:15:15 SQL> startup mount;
ORACLE instance started.
Total System Global Area 167772160 bytes
Fixed Size 788224 bytes
Variable Size 66058496 bytes
Database Buffers 100663296 bytes
Redo Buffers 262144 bytes
Database mounted.
17:18:09 SQL> recover database until time '2004-12-05:17:14:45';
ORA-00279: change 402561 generated at 12/05/2004 17:10:03 needed for thread 1
ORA-00289: suggestion :
G:\ORACLE10G\ORADATA\NEWTEST\ARCHIVE\ARC00002_0544119450.001
ORA-00280: change 402561 for thread 1 is in sequence #2
17:18:43 Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
Log applied.
Media recovery complete.
17:19:20 SQL>
17:19:51 SQL> alter database open resetlogs;
Database altered.
17:20:33 SQL> select * from testing.test;
NO
1
2
3
4

Incomplete Recovery and Read Only

Ok, I seem to be missing something. I've performed an incoplete recovery to a specified SCN. Everything is great if I open the database with resetlogs. But, the documentation (see quote below) says I can open the database as read only to check the recovery before I do the "resetlogs". However, I get the error (RMAN-01009) when I try to open the database read only. Can anyone explain?
Oracle Database Concepts (B14220-02) - 15 Backup and Recovery:
Before using the OPEN RESETLOGS command to open the database in read/write mode after an incomplete recovery, it is a good idea to first open the database in read-only mode, and inspect the data to make sure that the database was recovered to the correct point. If the recovery was done to the wrong point, then it is easier to re-run the recovery if no OPEN RESETLOGS has been done. If you open the database read-only and discover that not enough recovery was done, then just run the recovery again to the desired time. If you discover that too much recovery was done, then you must restore the database again and re-run the recovery.
The script I ran:
run
set until restore point r1;
restore database;
recover database;
}

To generate the exception RMAN-01009 it appears you are trying to open the database using RMAN ... try it with SQL*Plus ... and if you have a problem post the full error message not just your impression of it along with the corresponding section of the alert log and full version number.

Incomplete Recovery Fails using Full hot backup & Archive logs !!

Hello DBA's !!
I am doing on Recovery scenario where I have taken One full hot backup of my Portal Database (EPR) and Restored it on New Test Server. Also I restored Archive logs from last full hot backup for next 6 days. Also I restored the latest Control file (binary) to their original locations. Now, I started the recovery scenario as follows....
1) Installed Oracle 10.2.0.2 compatible with restored version of oracle.
2) Configured tnsnames.ora, listener.ora, sqlnet.ora with hostname of Test server.
3) Restored all Hot backup files from Tape to Test Server.
4) Restored all archive logs from tape to Test server.
5) Restored Latest Binary Control file from Tape to Test Server.
6) Now, Started recovery using following command from SQL prompt.
SQL> recover database until cancel using backup controlfile;
7) Open database after Recovery Completion using RESETLOGS option.
Now in Above scenario I completed steps upto 5) successfully. But when I execute the step 6) the recovery completes with Warning : Recovery completed but OPEN RESETLOGS may throw error " system file needs more recovery to be consistent " . Please find the following snapshot ....
ORA-00279: change 7001816252 generated at 01/13/2008 12:53:05 needed for thread
1
ORA-00289: suggestion : /oracle/EPR/oraarch/1_9624_601570270.dbf
ORA-00280: change 7001816252 for thread 1 is in sequence #9624
ORA-00278: log file '/oracle/EPR/oraarch/1_9623_601570270.dbf' no longer needed
for this recovery
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00308: cannot open archived log '/oracle/EPR/oraarch/1_9624_601570270.dbf'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
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: '/oracle/EPR/sapdata1/system_1/system.data1'
SQL> SQL> SQL> SQL> SQL> SQL> SQL>
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: '/oracle/EPR/sapdata1/system_1/system.data1'
Let me know What should be the reason behind recovery failure !
Note : I tried to Open the database using Last Full Hot Backup only & not applying any archives. Then Database Opens successfully. It means my Database Installation & Configuration is OK !
Please Let me know why my Incomplete Recovery using Archive logs Goes Fail ?
Atul Patil.

oh you made up a new thread so here again:
there is nothing wrong.
You restored your backup, archives etc.
you started your recovery and oracle applyed all archives but the archive
'/oracle/EPR/oraarch/1_9624_601570270.dbf'
does not exist because it represents your current online redo log file and that is not present.
the recovery process cancels by itself.
the solution is:
restart your recovery process with:
recover database until cancel using backup controlfile
and when oracle suggests you '/oracle/EPR/oraarch/1_9624_601570270.dbf'
type cancel!
now you should be able to open your database with open resetlogs.

OPEN RESETLOGS and incarnation....

Hi ,
I try to understand the use/function of OPEN RESETLOGS but the extensive use of the word 'incarnation' sets obstacles....
The following lines are from :
Oracle® Database Backup and Recovery Advanced User's Guide
10g Release 2 (10.2)
Part Number B14191-02
Paragraph:
Resetting the Database Incarnation in the Recovery Catalog
When you run either the RMAN command or the SQL statement ALTER
DATABASE OPEN RESETLOGS, you create a new incarnation of the database.
You can access a record of the new incarnation in the
V$DATABASE_INCARNATION view of the target database.
If you run the RMAN command or the SQL statement ALTER DATABASE OPEN
RESETLOGS, then a new database incarnation record is automatically created in
the recovery catalog. The database also implicitly and automatically issues a
RESET DATABASE command, which specifies that this new incarnation of the
database is the current incarnation. All subsequent backups and log archiving
done by the target database is associated with the new database incarnation.Can anybody explain ....????
Thanks....a lot
Sim

Incarnation here has the same meaning here that you would find in dictionary.
What it means is that now after "incarnation" this database is as good as a new database since all the redolog sequence, archive log sequence etc will be reset to start which they were during the time of creation (or last incarnation) of the database.
Lets assume u create a database. Lets call this as Life1 of the database.
Now a year later because of some reason you have to do an incomplete recovery and you open you database using resetlogs. Lets say this is Life2 of the database
Now after some time you do that again. This is Life3 of the database.
But there are times when you might want to bring the database back to Life1 and Life2. It is possible but because Oracle maintains all the Lives i.e INCARNATION of the database.
The concept of incarnation is important due to many reasons but for you understanding you can take it as life cycle of a database.
Thanks,
Ankit.

Question on OPEN RESETLOGS

Db version: 11g
What will happen if we don't use
ALTER DATABASE OPEN RESETLOGS;after an incomplete recovery?

hi,
check this out from oracle doc
About Opening with the RESETLOGS Option
The RESETLOGS option is always required after incomplete
media recovery or recovery using a backup control file. Resetting
the redo log does the following:
Archives the current online redo logs (if they are accessible) and then
erases the contents of the online redo logs and resets the log sequence
number to 1. For example, if the current online redo logs are sequence
1000 and 1001 when you open RESETLOGS, then the database archives
logs 1000 and 1001 and then resets the online logs to sequence 1 and 2.
Creates the online redo log files if they do not currently exist.
Reinitializes the control file metadata about online redo logs and redo threads.
Updates all current datafiles and online redo logs and all subsequent archived
redo logs with a new RESETLOGS SCN and time stamp.
Because the database will not apply an archived log to a datafile unless the
RESETLOGS SCN and time stamps match, the RESETLOGS prevents you
from corrupting datafiles with archived logs that are not from direct
parent incarnations of the current incarnation.
In prior releases, it was recommended that you back up the database
immediately after the RESETLOGS. Because you can now easily recover
a pre-RESETLOGS backup like any other backup, making a new database
backup is optional. In order to perform recovery through resetlogs you
must have all archived logs generated since the last backup and at least
one control file (current, backup, or created).this might help
thanks and regards
VD

Incomplete recovery question

Hi guys
As a DBA, we must to know about all backup and recover strategies. Today i was trying to simulate a recover from a lost of current relog group.
In order to deal with this situation, we need to perform an incomplete recovery.
The following steps were used to simulate a lost of current redo log and recover from it
1) Shutdown abort
2) delete all redo log files
3) open database to show there was an error in relog file
4) replace the existng datafiles with backup datafiles
5) recover database using backup control file until cancel
6) alter database open resetlogs
After the above steps, the database was able to operate as normal.
After that, i tried to perform incremental level 0 (backup incremental level 0 database plus archivelog delete input) to backup the database and archive and i got an error message :
"error identifying file c:\ARC00002.001"
"unable to open file"
"<OS 2 > The system cannot find the file specified"
I am sure that the archived file does not exist at the first place_
Can anyone tell me why this kind of error occur even you have successful performed incomplete recovery and how to solve this kind of situation.

Unless you were sloppy enough to put all of your log groups into a single directory on a single disk and lucky enough to have something bad happen while the database was down what you did doesn't truly simulate reality.
Here's reality.
Scenario 1:
1. Database is open and transactions are taking place ... code a simple PL/SQL loop
2. Query the database and look at your log files status values in v$log
3. Drop an inactive log
4. Issue an ALTER SYSTEM SWITCH LOGFILE until something breaks.
Scenario 2:
1. Database is open and transactions are taking place ... code a simple PL/SQL loop
2. Query the database and look at your log files status values in v$log
3. Drop an active log
4. Issue an ALTER SYSTEM SWITCH LOGFILE until something breaks.
Scenario 1:
1. Database is open and transactions are taking place ... code a simple PL/SQL loop
2. Query the database and look at your log files status values in v$log
3. Drop the current log
4. Issue an ALTER SYSTEM SWITCH LOGFILE until something breaks.
Be prepared to deal with all three scenarios.

Incomplete recovery after open resetlogs

Similar Messages

Maybe you are looking for