Re: An unusual case of recovery asking for an archived log from long time a go.
Date: Wed, 15 Feb 2012 23:38:57 -0500
Message-ID: <CAPXEL0K0Pv0C2eCuvdMMWUTDVgEMW15y4eT=RYyeJ3e1sTZO-w_at_mail.gmail.com>
Hi David, Dundi,
Thanks for your suggestion.
_at_David
I promise and take an oath that no I didn't do any of that ;) or at least I am not aware of an action that I took, that did something similar in the background i.e. like a recursive action (I am sure nothing like that has happened but I am trying to be as open minded as possible and ignoring my knowledge in case I haven't read any updated material) . Only thing I did was to put the database in archive log mode as was already mentioned.
_at_Dundi,
Suspecting that to be the case (during restore-recovery attempt from Feb 11 backup), I copied only the control file mentioned in the rman auto backup log to the target machine where I am doing the recovery so your case has been covered. I did a "drop database" first so old controlfiles were dropped ("......When you issue this statement, Oracle Database drops the database and deletes all control files and datafiles listed in the control file. If the database used a server parameter file (spfile), it is also deleted.").
[oracle_at_xxxxxxx autobackup]$ pwd /data/rman_backups_from_prototype_machine/autobackup [oracle_at_xxxxxxx autobackup]$ ll
total 166888
-rw-r----- 1 oracle oinstall 170721280* Feb 13 11:47* * c-425519899-20120213-00*
Starting Control File and SPFILE Autobackup at 13-FEB-12
piece handle=/u03/flash_recovery_area/AIS/autobackup/*
c-425519899-20120213-00* comment=NONE
Finished Control File and SPFILE Autobackup at 13-FEB-12
I am going to try what Ian has suggested (got stuck in some other work).
Okay let us assume something is stopping me from recovering from current state of inceremental level 0 backups (a setup issue, a bug etc.). I am thinking of the alternative options. What options I have now to get to a state where I can make the backups work (other than cold backup)?
Please bear in mind that this is a 700 GB db (not too big but read on) with 31000+ files (and tablespaces) on an extremely slow IO test machine and each restore cycle takes about 16 hours, (please don't ask me why the situation is so dire...). So it my take me a while to post my findings, thank you for your patience. I have an inkling that the issue is a bug and has something to do with switch to archivelog mode and/or large number of data files.
If Ian's suggestion doesn't work (I think it should work as a crosscheck will tell Oracle to forget about those beloved archive logs it is looking for that doesn't exists),
- I am thinking of trying a full backup and see what happens
- If that doesn't work try to shutdown and restart the source db, take a incremental level 0 and/or full backup and try again.
Thanks everyone again for your suggestions. Paresh
On Wed, Feb 15, 2012 at 7:30 PM, Dundi Gurram <dundi_gurram_at_yahoo.com>wrote:
> Can you please try this at rman prompt
>
> Restore controlfile from 'full path of controlfile autobackup/controlfile
> name you saw in the rman backup Log';
>
> Don't use the latest file or let rman pick the controlfile name
> automatically
>
> Regards,
> Dundi Gurram
> Global Group Inc.
>
> e-mail: Dundi.Gurram_at_1GlobalGroupInc.com
>
>
>
> On Feb 15, 2012, at 10:45 AM, Paresh Yadav <yparesh_at_gmail.com> wrote:
>
> > Hi Howard,
> > Thanks for your suggestion. Backup optimization is off. BTW - What was
> the
> > solution in your case? Just turning off backup optimization or you
> figured
> > out a workaround, solution?
> >
> > RMAN> show all;
> >
> > using target database control file instead of recovery catalog
> > RMAN configuration parameters are:
> > CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 14 DAYS;
> > CONFIGURE BACKUP OPTIMIZATION OFF;
> > CONFIGURE DEFAULT DEVICE TYPE TO DISK;
> > CONFIGURE CONTROLFILE AUTOBACKUP ON;
> > CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
> > '/u03/flash_recovery_area/AIS/autobackup/%F';
> > CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET
> PARALLELISM
> > 1;
> > CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
> > CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
> > CONFIGURE MAXSETSIZE TO 50 G;
> > CONFIGURE ENCRYPTION FOR DATABASE OFF;
> > CONFIGURE ENCRYPTION ALGORITHM 'AES128';
> > CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;
> > CONFIGURE SNAPSHOT CONTROLFILE NAME TO
> > '/u01/app/oracle/product/10.2.0/db_1/dbs/snapcf_AIS.f';
> >
> > RMAN>
> >
> > Thanks,
> > Paresh
> >
> > On Wed, Feb 15, 2012 at 8:52 AM, Howard Latham <howard.latham_at_gmail.com
> >wrote:
> >
> >> I had this when I tried to duplicate a db. Is backup optimisation
> >> turned on may be the problem.
> >>
> >> Sent from my Nascom I
> >> From: Paresh Yadav
> >> Sent: 15/02/2012 05:07
> >> To: oracle-l_at_freelists.org
> >> Subject: An unusual case of recovery asking for an archived log from
> >> long time a go.
> >> Hi,
> >> I am trying to recover rman backups from one host to other (recover
> Oracle
> >> 10.2.0.1 backups on RHEL-4, x86_64 to Oracle 11.2.0.3.0 RHEL-5, x86_64).
> >> This is a test environment.
> >>
> >>
> >>
> >> - The database was changed to archivelog mode and (re)started on
> >> - 09-FEB-2012 21:29:40
> >> - I copied incremental level 0 backups taken on 2012-Feb-13 to the new
> >> host along with latest control file autobackup and archive logs till
> >> "now"
> >> - Recovered spfile from autobackup, converted to pfile, edited
> necessary
> >> parameters, converted back to spfile and started the instance in
> NOMOUNT
> >> mode
> >> - Recovered controlfile from autobackup
> >> - Cataloged backup pieces and archivelogs because they are in different
> >> location on the new host
> >> - Renamed redo log file members because they are in different location
> >> on the new host
> >> - Ran set new name (because the datafiles are in different location on
> >> the new host), restore database and switch all file commands in rman,
> *so
> >> far so good*
> >> - When I try to recover, the recovery is asking for an archived log
> >> sequence that was created from a time even before the database was
> >> started.
> >>
> >>
> >> SQL> recover database using backup controlfile until cancel; --
> >> FYI Sequence 57023 is from Feb 13 19:27 (o1_mf_1_57023_7mmbmq84_.arc)
> >> ORA-00279: change 371904991 generated at *02/08/2012 23:51:56* needed
> for
> >> thread 1
> >> ORA-00289: suggestion :
> >>
> >>
> /data/u03/flash_recovery_area/AIS/archivelog/2012_02_14/o1_mf_1_56645_%u_.arc
> >> -- I don't have this archive log
> >> ORA-00280: change 371904991 for thread 1 is in sequence #56645
> >>
> >>
> >> Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
> >>
> >> *Of course cancelling will give me "file 1 was not restored from a
> >> sufficiently old backup"*
> >>
> >> cancel
> >> ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error
> >> below
> >> ORA-01152: file 1 was not restored from a sufficiently old backup
> >> ORA-01110: data file 1: '/data/u01/oradata/AIS/system01.dbf'
> >>
> >>
> >> ORA-01112: media recovery not started
> >>
> >> I have tried this using one other incremental backup from Feb 11 too
> with
> >> same results.
> >>
> >> Why is the recovery asking for that archive log from Feb 08 when the
> >> incremental level 0 backup is from Feb 13? Incremental 0 backups are
> >> suppose to be equivalent to full backups and as far as I read only
> >> difference between the two is that full backups can't be part of
> >> incremental backup cycles.
> >>
> >> Thanks in advance.
> >> --
> >> Thanks
> >> Paresh
> >> 416-688-1003
> >>
> >>
> >> --
> >> http://www.freelists.org/webpage/oracle-l
> >>
> >
> >
> >
> > --
> > Thanks
> > Paresh
> > 416-688-1003
> >
> >
> > --
> > http://www.freelists.org/webpage/oracle-l
> >
> >
>
-- Thanks Paresh 416-688-1003 -- http://www.freelists.org/webpage/oracle-lReceived on Wed Feb 15 2012 - 22:38:57 CST