I see. Makes sense.
Many Thanks,
Simon
"Howard J. Rogers" <howardjr_at_www.com> wrote in message
news:3bd9dd40$0$8349$afc38c87_at_news.optusnet.com.au...
> Simply because you can't drop the current redo log. And you can't make
the
> current redo log NOT the current redo log with an 'alter system switch'
> command, because without the current redo log, you are stuck in MOUNT
stage,
> and are not able to issue 'alter system' commands.
>
> There's a lot of current redo logs in that sentence, but you get the right
> idea?
>
> Regards
> HJR
> --
>
> Oracle Resources : http://www.geocities.com/howardjr2000
> ========================================
>
>
> "Simon Gottesman" <sgotte_at_prodigy-nospamplease.net> wrote in message
> news:g%1C7.6747$bu3.1177940074_at_newssvr15.news.prodigy.com...
> > Question for the guru DBA's:
> > Why is the dropping of the bad logfile group out of the question here,
ie
> > "alter database drop logfile group..."? Wouldn't that get rid of the
> > problematic logfile?If there are only two logfile groups, then they
could
> > add a temporary third to drop the bad one, after which a cold backup
could
> > be done. So why exactly is this approach incorrect?
> >
> > "Howard J. Rogers" <howardjr_at_www.com> wrote in message
> > news:3bd871b7$0$8350$afc38c87_at_news.optusnet.com.au...
> > > If the thing is genuinely lost (and I have neither the time nor the
> > > inclination to check out error numbers for their precise text
message),
> > then
> > > you are in deep doo-doo.
> > >
> > > The first thing you should do is take a backup.
> > >
> > > The next thing you should do is restore all data files, but not the
> > > controlfile nor any online redo logs you might have floating around,
> from
> > > the last backup you've taken (you have taken backups, I hope?!).
> > >
> > > Then you get to the MOUNT state (startup mount [pfile=...]).
> > >
> > > Then you issue the command 'recover database until cancel', and when
it
> > > prompts to apply redo, type the word 'auto'. All archives and online
> logs
> > > will be applied, automatically, until it can't read the contents of
the
> > > offending log, at which point the recovery process will crash out with
> an
> > > error.
> > >
> > > Then you issue the 'recover database until cancel' command once more,
> and
> > > when it prompts to apply the last log (presumably your current one),
you
> > > type the word 'cancel'.
> > >
> > > Then, you issue the command alter database open resetlogs, and the
> > database
> > > should open. You'll have lost all transactions that were in the
missing
> > > redo log.
> > >
> > > Finally, you ask yourself why your online redo logs are not mirrored,
> and
> > > invest a little time and disk space in rectifying that problem pronto.
> > >
> > > And given the resetlogs, you now have no valid backups nor archives,
so
> > its
> > > time to shut the entire database down cleanly, and perform a full,
> closed
> > > database backup.
> > >
> > > Regards
> > > HJR
> > > --
> > >
> > > Oracle Resources : http://www.geocities.com/howardjr2000
> > > ========================================
> > >
> > >
> > > "À̱âÅÂ(Kitae Lee)" <kitaelee_at_itnc.co.kr> wrote in message
> > > news:0oQB7.111$cI6.156340_at_news.bora.net...
> > > > Hi,
> > > >
> > > > My DB lost current online redo log.
> > > >
> > > > If "startup" the DB, get message ORA-00333.
> > > >
> > > > My DB has three redo log groups.
> > > >
> > > > That redo log is not mirred.
> > > >
> > > > My system is running in Archive Mode.
> > > >
> > > > But, I have any cold backups.
> > > >
> > > > What can I do?
> > > >
> > > > Help me.
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Received on Sat Oct 27 2001 - 11:09:17 CDT
