User's Manual

Chapter 9. Deploying and Synchronizing Databases
Test before deployment
Thorough testing of your SQL Remote system should be carried out before
deployment, especially if you have a large number of remote sites.
When you are in the design and setup phase, you can alter many facets of the
SQL Remote setup. Altering publications, message types, writing triggers to
resolve update conflicts are all easy to do.
Once you have deployed a SQL Remote application, the situation is
different. A SQL Remote setup can be seen as a single dispersed database,
spread out over many sites, maintaining a loose form of consistency. The
data may never be in exactly the same state in all databases in the setup at
once, but all data changes are replicated as complete transactions around the
system over time. Consistency is built in to a SQL Remote setup through
careful publication design, and through the reconciliation of UPDATE
conflicts as they occur.
Upgrading and
resynchronization
Once a SQL Remote setup is deployed and is running, it is not easy to tinker
with. An upgrade to a SQL Remote installation needs to be carried out with
the same care as an initial deployment. This applies also to upgrading
maintenance releases of the Adaptive Server Enterprise or Adaptive Server
Anywhere database software. Any such software upgrade needs to be tested
for compatibility before deployment.
Making changes to a database schema at one database within the system can
cause failures because of incompatible database objects. The passthrough
mode does allow schema changes to be sent to some or all databases in a
SQL Remote setup, but must still be used with care and planning.
The loose consistency in the dispersed database means that updates are
always in progress: you cannot generally stop changes being made to all
databases, make some changes to the database schema, and restart.
Without careful planning, changes to a database schema will produce errors
throughout the installation, and will require all subscriptions to be stopped
and resynchronized. Resynchronization involves loading new copies of the
data in each remote database, and for more than a few subscribers is a
time-consuming process involving work interruptions and possible loss of
data.
Changes to avoid on a running system
The following are examples of changes that should not be made to a
deployed and running SQL Remote setup. From the list, you will see that
there is a class of changes that are permissive, and these are generally
187