Re: RMAN Archive Log

From: <exec_at_chicagorsvp.com>
Date: Wed, 10 Sep 2008 12:26:53 -0700 (PDT)
Message-ID: <096dd61e-dd40-4d1b-92eb-ef06d92415f7@x35g2000hsb.googlegroups.com>


On Sep 10, 2:12 pm, sybra..._at_hccnet.nl wrote:
> On Wed, 10 Sep 2008 11:15:35 -0700 (PDT), e..._at_chicagorsvp.com wrote:
> >On Sep 10, 12:39 pm, sybra..._at_hccnet.nl wrote:
> >> On Wed, 10 Sep 2008 10:29:40 -0700 (PDT), e..._at_chicagorsvp.com wrote:
>
> >> >Hi,
>
> >> >We put our database into archive log mode.  It has been that way for a
> >> >day.  We also modified our init.ora file to set the destination and
> >> >file name format.
>
> >> >When we run RMAN, it looks in the oracle home and also for a totally
> >> >different file name with a totally different sequence number.  We set
> >> >the location in RMAN with no luck.......
>
> >> >We are on 10g R2 and using the control file rather than the recovery
> >> >catalog......
>
> >> >Any thoughts?  Do I need to shutdown and re-open with resetlogs???
>
> >> RMAN only looks in the catalog whether it is located in the
> >> controlfile or in the catalog database doesn't matter.
>
> >> In short: you only state 'It doesn't work' without any evidence.
> >> You can not expect accurate responses.
>
> >> --
> >> Sybrand Bakker
> >> Senior Oracle DBA- Hide quoted text -
>
> >> - Show quoted text -
>
> >Take a look at this:
>
> >SQL>  archive log list
> >Database log mode              Archive Mode
> >Automatic archival             Enabled
> >Archive destination            /u03/NI00/arch
> >Oldest online log sequence     68123
> >Next log sequence to archive   68132
> >Current log sequence           68132
>
> >SQL> select min(sequence#), max(sequence#), min(first_time),
> >max(first_time) from v$archived_log;
>
> >MIN(SEQUENCE#) MAX(SEQUENCE#) MIN(FIRST MAX(FIRST
> >-------------- -------------- --------- ---------
> >         37099          68131 27-MAR-08 10-SEP-08
>
> >This is VERY wrong.  We did have archiving turned on back in March.
> >We shut it off for several reasons and turned it back on last night.
> >So, RMAN is looking for 37099, which does not exist......
>
> >How do we fix that?
>
> This is NOT 'very' wrong. It is just a result of sloppy operational
> procedures. Apparently you are switching very infrequently and have 10
> online redologs. Why escapes me, as 4 is usually sufficient.
>
> It can be resolved by making your first backup using the
> skip inaccessible clause.
> After you have validated this backup, you could
> crosscheck archivelog all
> and
> deleted expired archivelog all
>
> and you are set.
> You could also perform an initial cold backup (all archivelogs before
> the backup are redundant)
> or the hack you described opening the database with resetlogs.
> But there is really no need for that.
>
> --
> Sybrand Bakker
> Senior Oracle DBA- Hide quoted text -
>
> - Show quoted text -

Thanks for your input. I've taken this database over from some junkie who was not even a DBA. This is what his backup script looks like:

RUN {
  ### Manually checkpoint the archive logs ###   sql 'ALTER SYSTEM ARCHIVE LOG CURRENT';

  ### Backup Database ###
  ALLOCATE CHANNEL weekly1 DEVICE TYPE DISK FORMAT '/backup/oracle/ niva/weekly/ora_%M%D%Y_%d_%s_%p';
  SET ARCHIVELOG DESTINATION TO '/u03/NI00/arch';   BACKUP CHECK LOGICAL
  INCREMENTAL LEVEL = 0
  AS COMPRESSED BACKUPSET DATABASE
  FILESPERSET 4
  PLUS ARCHIVELOG
  DELETE INPUT
  TAG = 'WEEKLY_DATABASE_BACKUP';
  RELEASE CHANNEL weekly1;
  DELETE NOPROMPT OBSOLETE;
} Received on Wed Sep 10 2008 - 14:26:53 CDT

Original text of this message