-
Trouble With RMAN Backup
First off, this is a test environment that I am having trouble on. My dail full backups were running find up until a few days ago. This database also had a standby that was taken down around the same time the problem occurred. Now, when doing full backups, it backs up the datafiles but errors out when it reaches the archive logs. The archive log folder then began to fill up since the scripts didn't delete the logs. The error I get is that it can resync because RMAN-20033: controlfile sequence# too low. After the script errors out, I go into RMAN and any command I issue give me the same error. I run resync catalog and all command work fine, but then when running backup, it messes up again. First question: Is this cause by the standby no longer being up? Did the standby clean out the archive log folder before? Question 2: What happens if RMAN backs up archive logs and deletes them before the standby applies them? Does this ever happen? Thanks!!
-
Try:
PHP Code:
CHANGE ARCHIVELOG ALL CROSSCHECK;
;)
-
Re:
I tried what you suggested at the RMAN prompt and it validated 2 archived logs that are indeed in the correct folder. But, if I run the backup, and it errors out. Then come and type Change Archivelog All Crosscheck, it comes up with the same error again until I manually resync (resync catalog). Is there any reason it keeps going out of sync? Thanks.
-
I found out that by placing 'resync catalog' in the first line of my run { ... } block and also placing it right before I release the channels everything works fine. But am I just camoflauging the real problem and is it ok to resync catalog so often? I do not totally understand what resync catalog does. Thanks.
-
Shuld not be necesary to re-sync catalog.
Here is an example of a script I use:
PHP Code:
rman target / << EOF
CONNECT CATALOG RCVCAT/PassWord@RMANDB
SQL "ALTER SYSTEM CHECKPOINT";
ALLOCATE CHANNEL FOR MAINTENANCE TYPE DISK;
CHANGE ARCHIVELOG ALL CROSSCHECK;
RUN {
ALLOCATE CHANNEL ch00 TYPE DISK;
ALLOCATE CHANNEL ch01 TYPE DISK;
SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';
BACKUP
ARCHIVELOG ALL
DELETE INPUT;
RELEASE CHANNEL ch01;
BACKUP
CURRENT CONTROLFILE;
RELEASE CHANNEL ch00;
}
exit
EOF
:D
-
As far as I understand, you have been runing a physical stand-by. That means that both databases have same DBID and they are physically identical, what means they have same dbid and the RMAN cannot differentiate the stand-by database from the primary one. I have the feeling that you have registered into the recovery catalog your stand-by database but not the original one. Now when your stand-by is down, the RMAN still keeps up resync from the stand-by control file, which however is not advanced forward anymore, since the stand-by is down and that causes the error.
I can't really imagine how that could happen but seems that is the case. Maybe it worths to try changing the snapshot controlfile name and try again
set snapshot controlfile name to 'something'
-
What do I put for 'something'? Just the new name for the new snapshot? And if this doesn't work, can I switch back to the snapshot controlfile I am using now. I just want to make sure this isn't a one way street. Thanks.
-
OK, I hadn't fixed the previous problem and now I have a new one. Somehow, someone recovered the archivelog and archivelog backup folder from a backup. The last archivelog before this happened was at #327. The logs someone restored ended at #276. Now the DB is archiving the logs at #277 and so on. So now I get an error RMAN-20032 checkpoint change# too low. If I do 'change archivelog all validate', it looks for log #'s 326 and 327 and can't find them. Is this because RMAN is looking at an older control file? Is there anyway to reset RMAN to the new sequence scheme, do a full backup, and go on from there? I just don't understand why someone would restore the archive folder from a backup. Thanks for all the help.
-
OK, I found out what happened. The archivelog directory and the control files from a backup were restored. The sequence in the restored control file is at #277. Is there any way I can get RMAN to look at the restored control file and get the new sequence? Or would I be better off bring the database up with resetlogs option? If I do this, will RMAN start back at one? I'm not totally convinced that RMAN is taking a snapshot of the correct controlfile. Is there anyway I can check? I did set snapshot .... and it was the same as the other snapshot. Thanks.
