Re: Best backup scenerio

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.
Received on Sun Feb 15 1998 - 00:00:00 CST