When you configure the DBEnvironment, it runs with
nonarchive logging by default. This is appropriate for
data definition and table loading, since nonarchive logging results
in more efficient loading, and usually there is little or no risk
of data corruption.
After data definition and before doing the initial backup,
you should decide which kind of backup, recovery, and logging
you want to use for production. If you choose
nonarchive logging,
you should do a static backup using the SQLUtil STORE command.
For archive logging, you should do a concurrent backup using
the SQLUtil STOREONLINE command.
Choosing Archive Logging |
 |
If you choose archive logging, you
create a backup of the entire DBEnvironment at periodic
intervals (say, once a week) and back up the log files
at shorter intervals (say, every day).
In the event of a media failure, you restore the
DBEnvironment first, and then you can apply each of the
stored log files in chronological sequence to the restored copy
of the DBEnvironment until you have
rolled forward all completed transactions.
If you wish, you can roll forward to a particular time prior to
the crash by supplying a timestamp for recovery.
Archive logging affords the greatest security for the DBEnvironment.
If you choose archive logging, it is best to place the log
on a device that is different from any of the
devices that contain other DBEnvironment files. For
the greatest security, use dual logging with the
two logs on different devices.
Since nonarchive logging is the default, you must
explicitly turn archive logging on.
The
SQLUtil STOREONLINE command lets you perform the STORE without stopping
the DBEnvironment; and it sets archive logging mode on for all
subsequent activity until you decide to turn it off with
a START DBE NEWLOG statement (omitting the ARCHIVE option).
|
| |
|
 | NOTE: You should use the STOREONLINE command for DBEnvironment
backups if you want to use archive logging.
Although it is possible to recover a DBEnvironment in archive mode
from a backup made with the STORE command, this is not recommended. |
|
| |
|
