Home » RDBMS Server » Backup & Recovery » ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS required....
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS required.... [message #333576] Sun, 13 July 2008 00:02 Go to next message
debrucer
Messages: 7
Registered: March 2008
Location: san diego california
Junior Member

We have backed up our Oracle10gR2 Enterprise Edition (64-bit) Windows database running on MS Windows Server 2003 using the following RMAN command:

	run {  
	allocate channel Disk1 type disk format '\\oraclebackup\WeeklyBackup\RMAN\AR5\backup_%U'; 
	backup ( database  filesperset 64  include current controlfile );
	RELEASE CHANNEL Disk1;

	allocate channel Disk1 type disk format '\\oraclebackup\DailyBackup\RMAN\AR5\arc_backup_%U'; 
	backup  ( archivelog all  delete input  filesperset 64 );
	RELEASE CHANNEL Disk1;

	delete noprompt obsolete;
}
	EOF


The files created by this backup are stored on network drive location. We are NOT using a Recovery Catalog.

There is no problem with using the network share (UNC location) as the account used by all Oracle Windows services is a domain administrator (the same on all hosts).

The files created are named as follows:

	BACKUP_1SJL5LQM_1_1
	BACKUP_1TJL63SH_1_1


We have installed Oracle10gR2 Enterprise Edition (32-bit) with all of the same "options" (OLAP, Spatial, Partitioning, etc., as used by SAP in production) on a test server and are attempting to use a tried and proven technique of duplicating our database (from production to test), using the following command in RMAN:

run {
set newname for datafile       1 to 'e:\oradata\AR5c\SAPDATA1\SYSTEM_1\SYSTEM.DATA1';    
<SNIP> files 2 through 61 <SNIP>    
set newname for tempfile	1  to 'e:\oradata\AR5c\SAPDATA2\TEMP_1\TEMP.DATA1';
sql 'alter system switch logfile';
duplicate target database to AR5c
LOGFILE
GROUP 1('e:\oradata\AR5c\origlogA\LOG_G11M1.DBF','e:\oradata\AR5c\origlogA\LOG_G13M1.DBF') size 50M,
GROUP 2('e:\oradata\AR5c\mirrlogA\LOG_G11M2.DBF','e:\oradata\AR5c\mirrlogA\LOG_G13M2.DBF') size 50M,
GROUP 3('e:\oradata\AR5c\origlogB\LOG_G12M1.DBF','e:\oradata\AR5c\origlogB\LOG_G14M1.DBF') size 50M,
GROUP 4('e:\oradata\AR5c\mirrlogB\LOG_G12M2.DBF','e:\oradata\AR5c\mirrlogB\LOG_G14M2.DBF') size 50M;
}
EOF


The above command is executed after all the necessary steps are completed for services, filesystem, tnsnames, listener, sqlnet, etc., and like I said, this technique has worked before... and has actually worked exactly once in seven or eight attempts over the past four days.

With slight deviation, based on little changes we have made, the failure in the RMAN command window follows:

contents of Memory Script:
{
   set until scn  25804867;
   recover
   clone database
    delete archivelog
   ;
}
executing Memory Script

executing command: SET until clause

Starting recover at 12-JUL-08
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: sid=387 devtype=DISK

starting media recovery

Oracle Error:
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: 'E:\ORADATA\AR5C\SAPDATA1\SYSTEM_1\SYSTEM.DATA1'

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 07/12/2008 20:10:17
RMAN-03015: error occurred in stored script Memory Script
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of log thread 1 seq 3188 lowscn 25797718 found to restore

RMAN> EOF


And the failure shows up in the alertlog, as follows:

Switch of datafile 61 complete to datafile copy 
  checkpoint is 25651194
Sat Jul 12 20:10:13 2008
alter database recover datafile list clear
Sat Jul 12 20:10:13 2008
Completed: alter database recover datafile list clear
Sat Jul 12 20:10:13 2008
alter database recover datafile list
 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10 , 11 , 12 , 13 , 14 , 15 , 16 , 17 , 18 , 19 , 20

Completed: alter database recover datafile list
 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10 , 11 , 12 , 13 , 14 , 15 , 16 , 17 , 18 , 19 , 20
Sat Jul 12 20:10:13 2008
alter database recover datafile list
 21 , 22 , 23 , 24 , 25 , 26 , 27 , 28 , 29 , 30 , 31 , 32 , 33 , 34 , 35 , 36 , 37 , 38 , 39 , 40

Completed: alter database recover datafile list
 21 , 22 , 23 , 24 , 25 , 26 , 27 , 28 , 29 , 30 , 31 , 32 , 33 , 34 , 35 , 36 , 37 , 38 , 39 , 40
Sat Jul 12 20:10:13 2008
alter database recover datafile list
 41 , 42 , 43 , 44 , 45 , 46 , 47 , 48 , 49 , 50 , 51 , 52 , 53 , 54 , 55 , 56 , 57 , 58 , 59 , 60

Completed: alter database recover datafile list
 41 , 42 , 43 , 44 , 45 , 46 , 47 , 48 , 49 , 50 , 51 , 52 , 53 , 54 , 55 , 56 , 57 , 58 , 59 , 60
Sat Jul 12 20:10:13 2008
alter database recover datafile list
 61

Completed: alter database recover datafile list
 61
Sat Jul 12 20:10:13 2008
alter database recover if needed
 start until change 25804867 using backup controlfile

Media Recovery Start
 parallel recovery started with 2 processes
ORA-279 signalled during: alter database recover if needed
 start until change 25804867 using backup controlfile
...
Sat Jul 12 20:10:17 2008
alter database recover cancel
Sat Jul 12 20:10:24 2008
ORA-1547 signalled during: alter database recover cancel...


It's late and I'm tired and I'm not sure that I can begin to tell you all the things that have been tried. Like I said, "seven or eight attempts over the past four days"... and with each one, we've googled and tried "intuitive" things... At the moment, the failure is "virgin", as we haven't done anything to corrupt the setup.

There is no online redo log to apply, which seems to be what it's looking for, an SCN after the most recent one that was available. But, you see that archivelog was "deleted"... not a command that we gave it, it was generated by RMAN (at least, I don't think we told it to do that).

The database cannot be recovered, because it can't be opened to get there... we've tried the "undocumented" config setting to allow corruption... waste of time... we've tried many different ways to get in the database, at one point it was telling us to "upgrade" and we got the database open with that option; but, it's no longer telling us, or letting us in that way.

An added thought... the one time it told us to "upgrade" was when I was using the Standard Edition libraries for Oracle, and duplicating from the EE "target" (production DB). The upgrade that the message suggested didn't help resolve the problem; but, at least we were able to get the DB open to run the scripts (catalog.sql, which runs catproc.sql and something else).

What are we missing here? Any ideas?

Thanks for any help you can provide.

David

[Updated on: Sun, 13 July 2008 00:14]

Report message to a moderator

Re: ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS required.... [message #333586 is a reply to message #333576] Sun, 13 July 2008 05:12 Go to previous messageGo to next message
Mahesh Rajendran
Messages: 10672
Registered: March 2002
Location: oracleDocoVille
Senior Member
Account Moderator
Did you try a TSPITR based restore (set until time OR scn)?
RMAN duplication will use only the backupsets (Datafiles + archived
logs that were backed up).
until time is much easier. Just use a time before your most recent backup.
set your NLS_DATE_FORMAT to MON DD YYYY HH24:MI:SS and try duplication again.
Also, make sure you issue this followed by DELETE EXPIRED and DELETE OBSOLETE.
RMAN> CROSSCHECK ARCHIVELOG ALL

Regards

Re: ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS required.... [message #333601 is a reply to message #333586] Sun, 13 July 2008 08:30 Go to previous message
debrucer
Messages: 7
Registered: March 2008
Location: san diego california
Junior Member

It's usually "operator error" when these things go so wrong... and it was this time, for sure.

The redo log groups were improperly set up, as follows:

LOGFILE
GROUP 1('e:\oradata\AR5c\origlogA\LOG_G11M1.DBF','e:\oradata\AR5c\origlogA\LOG_G13M1.DBF') size 50M,
GROUP 2('e:\oradata\AR5c\mirrlogA\LOG_G11M2.DBF','e:\oradata\AR5c\mirrlogA\LOG_G13M2.DBF') size 50M,
GROUP 3('e:\oradata\AR5c\origlogB\LOG_G12M1.DBF','e:\oradata\AR5c\origlogB\LOG_G14M1.DBF') size 50M,
GROUP 4('e:\oradata\AR5c\mirrlogB\LOG_G12M2.DBF','e:\oradata\AR5c\mirrlogB\LOG_G14M2.DBF') size 50M;


Here is how they should have been set, as follows:

LOGFILE
GROUP 1('e:\oradata\AR5c\origlogA\LOG_G11M1.DBF','e:\oradata\AR5c\mirrlogA\LOG_G11M2.DBF') size 50M,
GROUP 2('e:\oradata\AR5c\origlogB\LOG_G12M1.DBF','e:\oradata\AR5c\mirrlogB\LOG_G12M2.DBF') size 50M,
GROUP 3('e:\oradata\AR5c\origlogA\LOG_G13M1.DBF','e:\oradata\AR5c\mirrlogA\LOG_G13M2.DBF') size 50M,
GROUP 4('e:\oradata\AR5c\origlogB\LOG_G14M1.DBF','e:\oradata\AR5c\mirrlogB\LOG_G14M2.DBF') size 50M;


On the duplicate DB they looked a little funny because they were all on the same device which is clearly not how the "target" DB is configured.

I executed "alter database backup controlfile to trace;" on the target to get the right specification and put that in the RMAN script and everything works like a champ.

It's painful to make silly mistakes. Fortunately for me this was a test to assure we can recover... and we learned more with the error than we would have ever learned if it went smoothly.

Thanks to the one person who offered suggestions. I do appreciate your help.

David

[Updated on: Sun, 13 July 2008 21:12]

Report message to a moderator

Previous Topic: How do do you backup with 2 different retention periods?
Next Topic: RMAN backup failing.
Goto Forum:
  


Current Time: Wed Dec 07 16:31:45 CST 2016

Total time taken to generate the page: 0.05204 seconds