Re: Online backup: Backup online redologs?

"Charles Fisher" <Charles.Fisher_at_alcoa.com> wrote in message news:Pine.GSO.4.31.0105081630240.1019-100000_at_unknown...
> On Wed, 2 May 2001, Howard J. Rogers wrote:
>
> > > ...but assuming that I am willing to endure the lesser
> > > quality, how are the redologs recreated?
 

> > I may be wrong, and I don't have a database to hand on which to test
 this
> > out, but since the commands to create or drop redo logs are all
 variations
> > on a theme of 'alter database', I would have thought that they can be
 issued
> > in the mount stage -which means you can take your binary version of the
> > control file, created as you just described, get to the mount stage, add
 two
> > new redo log groups, drop all reference to the existing groups, and
 alter
> > database open resetlogs. The trace file method of course relies on the
> > (consistent) presence of the existing logs, because the controlfile has
 to
> > gets its SCN from somewhere. Using the binary file, you're just
 performing
> > boring old incomplete recovery because of a gap in your redo stream.
> > I wouldn't consider the resulting database a clone, though, because of
 that
> > resetlogs. But your view might differ.
> > Alter database add logfile group 3 "blah/blah.rdo' size 1m (repeat for
 group
> > 4)
> > Alter database drop logfile group 1 (repeat for group 2)
>
> Hey, this doesn't work.
>
> I have restored everything, but I have no redologs.
>
> I can mount the database, but here is what happens:
>
>
> $ svrmgrl
>
> Oracle Server Manager Release 3.0.5.0.0 - Production
>
> (c) Copyright 1997, Oracle Corporation. All Rights Reserved.
>
> Oracle8 Enterprise Edition Release 8.0.5.0.0 - Production
> With the Partitioning and Objects options
> PL/SQL Release 8.0.5.0.0 - Production
>
> SVRMGR> connect internal
> Connected.
> SVRMGR> startup mount
> ORACLE instance started.
> Total System Global Area 26148952 bytes
> Fixed Size 49240 bytes
> Variable Size 5349376 bytes
> Database Buffers 20480000 bytes
> Redo Buffers 270336 bytes
> Database mounted.
> SVRMGR> alter database drop logfile group 1;
> Statement processed.
> SVRMGR> alter database drop logfile group 2;
> Statement processed.
> SVRMGR> alter database drop logfile group 3;
> Statement processed.
> SVRMGR> alter database drop logfile group 4;
> Statement processed.
> SVRMGR> alter database drop logfile group 5;
> alter database drop logfile group 5
> *
> ORA-01567: dropping log 5 would leave less than 2 log files in thread 1
> ORA-00312: online log 5 thread 1:
> '/pkg/prdcrm/oradata/prdcrm/redoprdcrm05.log'
> SVRMGR> alter database add logfile group 1
> '/pkg/prdcrm/oradata/prdcrm/redoprdcrm01.log' size 10M;
> Statement processed.
> SVRMGR> alter database drop logfile group 5;
> Statement processed.
> SVRMGR> alter database add logfile group 2
> '/pkg/prdcrm/oradata/prdcrm/redoprdcrm02.log' size 10M;
> Statement processed.
> SVRMGR> alter database drop logfile group 6;
> alter database drop logfile group 6
> *
> ORA-01623: log 6 is current log for thread 1 - cannot drop
> ORA-00312: online log 6 thread 1:
> '/pkg/prdcrm/oradata/prdcrm/redoprdcrm06.log'
>
> Of course, I cannot force a log switch in this state.
>
> What do I do? Using the hotbackup online redologs seems to be the ONLY way
> to do a complete recovery. If I couldn't get the online redologs for
> whatever reason, I couldn't recover the database!

Well, it was worth a try. And yes, I'd forgotten that 'alter system switch logfile' will only work when fully open.

Your last statement is entirely true. Hence the maxim: if you lose all members of the current redo log, you must perform an incomplete recovery (ie, recover until cancel -and you type 'cancel' when prompted to supply the current log).

There is no alternative (save relying on a method which may or may not work, depending on which way the wind is blowing, and how busy the database was when you hot-backed it up). The current redo log has always been known as Oracle's Achilles' heel, and that's why multiplexing was introduced. But if *all* members of the group are lost, yes, you're right: your database cannot be recovered. The same point of weakness is exhibited by all other RDBMS's too.

Regards
HJR
>
> --------------------------------------------------------------------------