asked on
Oracle rman archivelog backups failing after dataguard switchover
We did a dataguard switchover this past weekend for several of our databases. We then began running the rman backups from the new primary server. The archive log backups are failing on some of the switched databases. The problem seems to involve the archive logs created on the original primary between the time of the last archivelog backup on that server and the swtichover. Here's what happens:
If anyone has had the patience to read through this rambling tale, I could sure use some help. Thanks.
The first archive log backup reported success, and included the interim-period archive logs described above
.
The next couple of backups failed with a message saying it can't find the first of the interim-period archive logs:
RMAN-03002: failure of backup command at 11/14/2010 08:36:18
RMAN-06059: expected archived log not found, lost of archived log compromises recoverability
ORA-19625: error identifying file /opt/app/oracle/admin/webp
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
RMAN-06059: expected archived log not found, lost of archived log compromises recoverability
ORA-19625: error identifying file /opt/app/oracle/admin/webp
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
So I copied them over from the original server. The next backup was happy, and included the interiim-period archive logs.
The next one failed with the same message above. So I copied them over again. Went through this cycle a couple of times before I realized the log files it was missing were the same ones over and over. (It was a hectic morning).
So I copied them over one more time and ran the RMAN CATALOG command: catalog archivelog 'blah1','blah2'...
Same results: the first archive log backup was happy, the next failed with the same problem. I'm running a crosscheck now, but I don't see how that's going to fix it.
Here, finally, is my question: How can I make future archive log backups succeed?If anyone has had the patience to read through this rambling tale, I could sure use some help. Thanks.
Oracle Database
Last Comment
cholman
ASKER
Anybody?
ASKER
I just needed to folllow the 'catalog' with:
crosscheck copy of archivelog all;
Everything is OK now.
crosscheck copy of archivelog all;
Everything is OK now.
ASKER
Thanks.
The above solution fixed the archive log backup problems with our two 10.2.0.3 databases, but we're still having the problem with tthe two 10.2.0.4 db's. I don't know if the version makes a difference or not, just thought I'd toss it out there.
The above solution fixed the archive log backup problems with our two 10.2.0.3 databases, but we're still having the problem with tthe two 10.2.0.4 db's. I don't know if the version makes a difference or not, just thought I'd toss it out there.
I think this means that you have to check the Oracle parameters pointing to the archivelog destinations.
They are in LOG_ARCHIVE_DEST parameters. Check also the name convention, name convention and all other parameters in regard to archive log process.
Check also the names of the files, directories, read writes.
They are in LOG_ARCHIVE_DEST parameters. Check also the name convention, name convention and all other parameters in regard to archive log process.
Check also the names of the files, directories, read writes.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
It worked! We've had two successive successful archivelog backups without manual intervention.
The key was to "crosscheck copy of archivelog all;" with the interim-period logs NOT present on the server hosting the now-primary databases.
ASKER
After a lot of fumbling around, I finally solved my own problem. I gave the solution a 'c' because it documents a lot of that fumbling. It's not straightforward. But by reading the entire thread, the answer is there.