Re: RMAN Archive Log
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