NetBase SQL Shadowing Handbook

NetBase SQL Troubleshooting
____________________________________________________________
ver A0195 QUEST Software, Inc. 4-13
Resync’ing
As an example, let's start with the simplest case. A shadow copy of a DBE is out of sync with the
master. There is only one shadow copy and one master copy. To get back into sync the following
steps should be taken:
1. Connect to the DBE on the master system.
2. Unload the DBE. This should be done while the DBE is completely quiesced. Do not
proceed until all activity with the DBE has ceased.
3. Get the checkpoint record from the log file. It is important that no other activity takes
place on the DBE between the start of step 2 and this step. Otherwise the DBEs will be
out of sync at the completion of this process.
To get the checkpoint record, you may use the NBSQLSYN utility.
: RUN NBSQLSYN.NB.NETBASE;INFO="GET,dbename,partition"
Specify the partition from which the data is being resync'ed (the home partition number
of the master). The results are placed in a file named SYNCSCR in the same location
as the DBE. So if the DBE is in DATA.PROD, the file will be SYNCSCR.DATA.PROD.
4. Connect to the DBE on the shadow system.
5. Again, make sure that the DBE is completely quiesced. Then delete the old data from
the DBE and load the tables with the data from the master DBE.
6. Update the checkpoint in the local log file from the checkpoint record retrieved from the
log file on the master machine.
To update the SCR using the SYNCSCR file, transfer it to the shadow machine. With
that accomplished, you may use the NBSQLSYN utility again.
: RUN NBSQLSYN.NB.NETBASE;INFO="UPDATE,dbename"
The whole DBE need not necessarily be replaced. Consider an installation that has three master
machines and one slave. In this case we may assume that each master only updates a particular
set of tables. For instance, the master on SYSA updates tables 1-3, the master on SYSB
updates tables 4-7, and the master on SYSC updates tables 8-9. In effect, the shadow machine
acts as the shadow copy for three different DBEs. If the shadow machine goes out of sync with
the database on SYSC, then the above steps are followed but only for tables 8-9.
If userexits are used to filter the data from the master copy, a simple unload and reload will not
suffice. In this case the best plan would be to restore the shadow copy to the last backup and
then restart SQL shadowing. The backups should always include the logfiles so that when SQL
shadowing is started, the checkpoint record on the shadow machine is a correct reflection of the
updates on that machine.