Ted, I don't think you're right about this.
Copying the DB2 archive log journal volumes doesn't prevent the problem
if the tables and journals are on separate volumes and the volume copies
are done by any process that is not exactly time-synchronized across all
volumes. If the copies are offset by even a few milliseconds you have
the potential for a later copy of the active log volume to indicate a
successful table update has occurred, while the volume copy of the
volume containing the actual table may have occurred prior to the
physical update and not contain the update. Similarly, if the journal
volume is copied earlier, it may not reflect updates that could need to
be backed out while the updated tables on a volume copied later may have
been updated by the time that volume copy is made.
DB2 journaling is designed to guarantee a known state of affairs on
system DASD in the event of catastrophic failure. DB2 does this by
using synchronous writes to guarantee that physical changes on DASD
occur in the order (1)write table row pre-image to archive log,
(2)update table row, (3)write updated image to archive log. Once you
introduce asynchronous volume copy operations into the picture and
different volumes are involved, depending on the order of the copies you
introduce the possibility that your volume copies may contain (1) and
(3) without containing the effect of (2)(loss of update); or perhaps the
effect of (2) without (1) and (3) (a problem if DB2 recovery during DR
needs to back the change out, or should forward recovery be needed after
initial DR). You may not necessarily get an error out of DB2 during DB2
recovery using a system built from the copied volumes: if DB2 doesn't
see archive log entries corresponding to (1), it has no way of knowing
that the update was in-flight; and if DB2 sees both (1) and (3), it will
assume update (2) must be present since it must have been successfully
written prior to (3).
Last time we checked, prior use of DB2 SUSPEND to freeze further table
updates is the technique advised in the IBM manuals (Redbook?) to avoid
DB2 data corruption in copies created through use of FlashCopy to copy
multiple volumes containing DB2 tables and logs.
Ted MacNEIL wrote:
suspend
DB2 updates and some other update activities during the establishment
process to be sure that you have consistent volume backups that will
actually be usable for a Disaster Recovery.
Not if you are also copying journals.
In-flights are handled by that.
-teD
...
--
Joel C. Ewing, Fort Smith, AR [EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
