Chapter 9. Deployingand Synchronizing Databases
Test before deployment
Thoroughtesting of your SQL Remote system should be carried out before
deployment,especially if you have a large number of remote sites.
Whenyou are in the design and setup phase, you can alter many facets of the
SQLRemote setup. Alteringpublications, message types, writing triggers to
resolveupdate conflicts are all easy to do.
Onceyou have deployed a SQL Remote application, the situation is
different. A SQL Remote setup can be seen as a single dispersed database,
spreadout over many sites, maintaining a loose form of consistency. The
datamay 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
systemover time. Consistencyis built in to a SQL Remote setup through
carefulpublication design, and through the reconciliation of UPDATE
conflictsas they occur.
Upgradingand
resynchronization Oncea 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
thesame care as an initial deployment. Thisapplies also to upgrading
maintenancereleases of the Adaptive Server Enterprise or Adaptive Server
Anywheredatabase software. Anysuch software upgrade needs to be tested
forcompatibility before deployment.
Makingchanges to a database schema at one database within the system can
causefailures because of incompatible database objects. Thepassthrough
modedoes allow schema changes to be sent to some or all databases in a
SQLRemote setup, but must still be used with care and planning.
Theloose consistency in the dispersed database means that updates are
alwaysin progress: youcannot generally stop changes being made to all
databases,make some changes to the database schema, and restart.
Withoutcareful planning, changes to a database schema will produce errors
throughoutthe installation, and will require all subscriptions to be stopped
andresynchronized. Resynchronizationinvolves loading new copies of the
datain each remote database, and for more than a few subscribers is a
time-consumingprocess involving work interruptions and possible loss of
data.

Changes to avoid on a running system

Thefollowing are examples of changes that should not be made to a
deployedand running SQL Remote setup. Fromthe list, you will see that
thereis a class of changes that are permissive, and these are generally
187