Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: database could not be started

Re: database could not be started

From: quarkman <quarkman_at_myrealbox.com>
Date: Sun, 10 Aug 2003 07:42:28 +1000
Message-ID: <oprtnqk2wfzkogxn@haydn>


On Sat, 9 Aug 2003 12:39:31 -0500, Burton Peltier <burttemp1REMOVE_THIS_at_bellsouth.net> wrote:

> "Anton Buijs" <remove_aammbuijs_at_xs4all.nl> wrote in message
> news:3f3510b5$0$49108$e4fe514c_at_news.xs4all.nl...

>
> This is the main reason where you would need the REDO logs. I thought
> that
> was what I said? After re-reading my post, it IS what I said.
>
> Just to be clear... I did not mean to imply and I know you do NOT recover
> REDO logs when recovering from a hot backup. The entire context of the
> OP
> was a problem with a cold backup. All of the comments in my post were
> about
> cold backups ONLY.
>
> Hot backups are different, of course.

The temperature of your backups makes no difference. You should never backup online redo logs, period. Archivelog or noarchivelog, hot or cold.

The subtler point is that's it's fine to do cold backups, even in archivelog mode. Indeed, cold backups with archivelog mode is quite possibily the nicest combination of options available to the dba. But herein lies the source of possible confusion: I'm in archivelog mode, I take cold backups... is it therefore OK for me to backup my online redo logs? No it isn't, because I risk data loss at the time of restore.

So some cold backups, it would be OK to back them up (noarchivelog ones) and some it wouldn't (archivelog ones). Not very consistent advice, is it? For newbies, I mean.

>
> Anyway, it sounded like a real possibility (needing the REDO logs or
> having
> to do a reset logs) for this person who is doing a cold/offline backup
> and
> does a shutdown abort every now and then because the immediate isn't
> coming
> back soon enough.
>
> I would add for the OP... if this is occuring often, I would look into
> what
> is running at the time you are attempting a cold backup. Someone probably
> has a job that is kicking off at the same time or right before and you
> could
> get them to change the start time.
>
> Note: I have had problems before trying to get a "clean shutdown" such
> as:
>
> (1) Some job or snapshot would kick off in the middle of my "clean
> startup/shutdown" even with the listener shutdown. So, then I would need
> a
> second init.ora with jobs = 0 and have to do the "clean startup/shutdown"
> using a different init.ora .
>
> (2) The "crash recovery" step would take a lot longer than you would like
> when doing the "clean startup/shutdown".
>
> So, can someone/quarkman? please explain to me what is the problem /
> disadvantage of recovering the REDO logs, IF recovering from COLD
> backup
> (even if a shutdown abort was not issued).
>
> Seems cleaner to me to recover the cold backup with REDO logs than to do
> a
> reset logs command or having a potential problem getting a "clean
> shutdown".
>

I don't know why suddenly 'resetlogs' is considered so evil! You would have to type 'recover database until cancel'...'cancel'...'alter database open resetlogs'. I make that a massive 9 words of typing!

Why backup something which you can never safely restore in archivelog mode?

And why make your noarchivelog cold backup backup something (possibly taking many extra minutes to do so, depending on their size) which you would then have to expend more minutes restoring... when the alternative re-creates them in a blink of an eye? I dispute the reasoning that a full restore would be quicker than an open resetlogs, particularly if you're restoring from tape.

But the real issue is as I mentioned earlier: backing up the redo logs is only feasible when you are in noarchivelog mode. The advice not to back them up, ever, works 100% of the time, regardless of the nature of your database.

~QM Received on Sat Aug 09 2003 - 16:42:28 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US