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  |
|
|
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 #333601 is a reply to message #333586] |
Sun, 13 July 2008 08:30  |
|
|
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 |
|
|
|
Goto Forum:
Current Time: Mon Apr 29 07:25:10 CDT 2024
|
] 
Blog
Search
Help
Members
Register
Login
Home
