Re: Best backup scenerio

On Sun, 15 Feb 1998 15:19:54 -0600, "John P. Higgins" <jh33378nospam_at_deere.com> wrote:
Hi,

take inot your considerations that the backup media could be destroyed since last backup or couldn't be read. So from my point of view it would be a good idea to keep at least a l l archived redo logs since the last three backups (including).

>Keep your eyes on the prize -- the only reason for backups is to enable
>recovery! If you can rebuild easily and quickly, you don't need any
>backups.
>
>If you are like most of us, rebuilding is not possible, much less quick
>and easy. So backups are a necessary fact of life.
>
>ARCHIVLOG mode enables you to recover the updates that were made since
>the last backup (hot or cold). If all updates are batch and if you can
>rerun the updates after restoring from a backup and if you can do
>consistent cold backups, you don't need ARCHIVLOG mode.
>
>ARCHIVLOG mode also enables hot backups. If you can't shutdown for
>consistent cold backups, hot backups are the answer. But hot backups are
>inconsistent, so you need the redo logs (possibly archived) to recover
>from a restored datafile. You also need to mark the begin and end of
>each tablespace's backup. You cannot alter a tablespace into backup mode
>unless you are in ARCHIVLOG mode.
>
>If you take a hot backup without altering the tablespace into backup
>mode, there is a good chance you will not be able to recover the
>tablespace from a restored backup. The async nature of DBWR and the LRU
>algorithm means the disk may not be consistent during the backup even if
>all updating is suspended. So a recovery using a hot backup needs the
>redo logs to roll forward to a consistent state.
>
>While the database is on-line, you can alter the archived log
>destination. You can use this for a hybrid solution:
>1) Use ARCHIVELOG mode
>2) Normally, direct archived logs to /dev/null
>3) While backing up, direct archived logs to a keep directory
>4) In a recovery situation:
> A) restore from the backup
> B) recover to the end of backup point-in-time
> C) rerun the updates since the backup
>
>Hope this helps.
>
>John
>
>PS I use ARCHIVLOG mode and hot backups on all my databases.
>
>Keith E. Moore wrote:
>>
>> This might sound like an odd question, but for the past year we
>> have been implementing a new Oracle database which has approx. 3
>> million rows in the primary table and averages around 8 GB with
>> indexes.
>>
>> The problem is that we can not seem to get a consensus on the
>> best way to back up the instance without taking it down. If
>> we enable ARCHIVE mode performance suffers, and any large batch
>> update sucks up alot of disk space, which we believe is partially
>> due to several Context Keys generateing huge redo logs.
>>
>> The primary requirement is that we should never have to shutdown
>> the database, however we CAN guarantee that it is not being
>> updated for a long enough period to back it up.
>>
>> Is there a way to do hot-backups without ARCHIVE? My thought was
>> that we can create a mirror of the database, stop all updates
>> to the Master, shutdown the mirror, backup the mirror, bring
>> the mirror back up, and start doing updates again.
>>
>> Is this possible? What would be the best implementation for this?
>> We are running on an Enterprise 4000 Solaris box. We need to maintain
>> a replicated instance for other purposes, which does not have to be
>> a 24/7 database, so I was hoping I could leverage off of it to
>> eliminate the need for ARCHIVE mode.
>>
>> I would like to hear stories about how most houses maintain
>> full time (24/7) databases.
>>
>> --
>> -- Keith Moore
>> President
>> KMA Computer Solutions, Inc.

--

Regards

Matthias Gresz    :-)

GreMa_at_T-online.de