Re: Restoring & recovering in NOARCHIVELOG

On Fri, 25 Jul 2003 19:30:46 +0300, Tanel Poder <tanel@@peldik.com> wrote:

> Hi!
>
> I wouldn't say that a production db should never be in noarchivelog. When
> we
> look at this from customer money point of view, then if one day of
> customer's data is less worth than additional disk storage and IO
> bandwidth
> for archivelogs - then production database can very well be in
> noarchivelog
> mode. I've had several such cases, especially when we are dealing with
> staging type of databases which can be recreated easily.
>
> Tanel.
>

Spot on. There are many circumstances under which archivelog is not appropriate.

> "Daniel Roy" <danielroy10junk_at_hotmail.com> wrote in message
> news:3722db.0307250655.5c526149_at_posting.google.com...
>> You will need to read a bit about database backups and recovery.
>> First, a Production database should never run in NOARCHIVELOG mode!
>> Just put it in ARCHIVELOG mode (with automatic archiving, of course).
>> Then, if you still want to make daily offline backups, go as you do
>> now, but include the archive logs also in your backup. That way,
>> you'll be 100% sure to be able to recover up to the second before any
>> HW failure.

This thread has brought out a lot of woolly thinking, hasn't it? Hardware failures are *totally* recoverable, not just to the 'second before' the failure. I think you are confusing this with user errors (drop table, or delete from table ... commit). Those sorts of errors need incomplete recoveries sure enough, and the hallmark of an incomplete recovery is that you indeed stop applying redo to a point just short of the error (though you can do better than 1 second if you use the SCN in v$logmnr_contents).

>> Relying on the changes still being in the redo logs is not
>> recommended, secure and supported, even if I might work sometimes.

*Using* the changes in the online logs is of course supported. It's only redo, after all. And Oracle doesn't care what sort of file (online log or archive) you can supply the redo from, so long as you can supply it.

But you are right to say that *relying* on the changes still being in the *online* logs is not a particularly sensible way to go, because the changes are vulnerable to being over-written following some log switches.

>> Please read the backup and recovery manuals at tahiti.oracle.com.
>>

Excellent advice nonetheless.

~QM

>> Daniel
>
>
>

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/