Filter
Top Products
Adaptive Server Enterprise transaction log and
backup management
You must protect against losing transactions that have been replicated to
remote databases. If transactions are lost that have already been replicated to
remote databases, the remote databases will be inconsistent with the
consolidated database. In this situation, you may have to re-extract all
remote databases.
Protecting against media failure on the transaction log
Media failure on the transaction log can cause committed transactions to be
lost. If the transaction log has been scanned and these transactions have
already been sent to subscriber databases, then the subscribing databases
contain transactions that are lost from the publishing database, and the
databases are in an inconsistent state.
Why the transaction log
is needed
The transaction log is needed, even after the entries have been scanned into
the stable queue, to guard against media failure on the database file. If the
database is lost, it must be recovered to a point that includes every
transaction that may have been sent to remote databases.
This recovery is done by restoring a database dump and loading transaction
dumps to bring the database up to date. The last transaction dump restored is
the dump of the active transaction log at the time of the failure.
Protecting against
transaction log loss
There are two ways of protecting against inconsistency arising from media
failure on the transaction log:
♦ Mirror the transaction log When a device is mirrored, all writes to the
device are copied to a separate physical device.
♦ Only replicate backed-up transactions There is a command-line
option for the Message Agent that prevents it from sending transactions
until they are backed up.
Mirroring the transaction
log
The only way to protect against media failure on the transaction log is by
mirroring the transaction log.
Disk mirroring can provide nonstop recovery in the event of media failure.
The disk mirror command causes an Adaptive Server Enterprise database
device to be duplicated—that is, all writes to the device are copied to a
separate physical device. If one of the devices fails, the other contains an
up-to-date copy of all transactions.
☞ For information on disk mirroring in Adaptive Server Enterprise, see the
chapter “Mirroring Database Devices”, in the Adaptive Server Enterprise
272