Sybase DC38133-01-0902-01 manual Test before deployment, Changes to avoid on a running system

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	Once a SQL Remote setup is deployed and is running, it is not easy to tinker
resynchronization	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