Chapter 6. Instantiating enterprise replication 69
Example 6-1 Adding CRCOLS to Typed Tables
alter table stock add CRCOLS;
DROP TABLE retail_customer;
DROP TABLE whlsale_customer;
DROP TABLE customer;
CREATE TABLE customer OF TYPE customer_t
PRIMARY KEY (customer_num),
FOREIGN KEY (customer_loc) REFERENCES location (location_id),
CHECK (customer_type IN ('R','W')),
CHECK (credit_status IN ('D','L','R','P','N'))
) with CRCOLS;
CREATE TABLE retail_customer OF TYPE retail_t UNDER customer with
CREATE TABLE whlsale_customer OF TYPE whlsale_t
(CHECK (terms_net >= 0 OR terms_net IS NULL))
UNDER customer with CRCOLS;
LOAD FROM 'retail_cust.unl' INSERT INTO retail_customer;
LOAD FROM 'whlsale_cust.unl' INSERT INTO whlsale_customer;
In the examples in this chapter, we chose not to cause any conflicts in the typed
tables. That means there will be no changes to the customer.customer_num or
either of the children of that table (retail_customer or whlsale_customer). In any
production system, this potential conflict would have to be avoided or dealt with.
One option is to use sequences instead of the serial type to generate the
numbers. The sequence definition provides appropriate controls for generating
unique numbers in multiple systems.
Our example systems are on two different hardware types, the IBM System p
and the IBM System x. One of the example replicates is stock.unit_price. It is a
floating point number, so it may have different representation on the different
systems. To avoid problems, floating point numbers can be replicated in IEEE
format. That is part of defining the replicates.
6.2.2 The IDS instances
The IDS instances that are replication servers must have certain resources
configured so the replication threads have room to perform their functions. The
70 Informix Dynamic Server V10: Superior Data Replication for High Availability and Distribution
configuration parameters in the onconfig file (and the values used in the example
systems) include those identified in Table 6-1.
Table 6-1 Configuration parameters
Each instance in the example has a unique set of values for CDR_SERIAL. That
allows the use of the SERIAL type in a way that avoids conflicts. If that change to
the sequence of generated numbers cannot be made for some reason, then the
conflict resolution scheme
must be able to handle the problem.
CDR_QDATA_SBSPACE parameters define the space for the queue headers
and data held or received by the replication threads. Each of these needs to be
defined using the onspaces command before replication can be started. See the
IBM Informix Enterprise Replication Guide, G251-1254, for advice on how to
determine a good size for this dbspace and smart blobspace.
The CDR_DBSPACE is the dbspace in which the syscdr database is created.
This may be an existing space or a space that is added for this purpose. In the
example, we chose to create a dbspace specifically for this database.
The CDR_EVALTHREADS defines how many additional threads will be used in
each CPU virtual processor (VP) to evaluate what data from each SQL statement
should be held for replications. The choice of number here depends on the
volume of work. For the example, we chose to use only a single thread because
the workload was very light.
Parameter Value Description
CDR_EVALTHREADS 2 # evaluator threads (per-cpu-vp,
CDR_DSLOCKWAIT 5 # DS lockwait timeout (seconds)
CDR_QUEUEMEM 4096 # Max amount of memory for any CDR
queue (Kbytes)
CDR_NIFCOMPRESS 0 # Link level compression (-1= never, 0=
none, 9= max)
CDR_SERIAL 1000,1 # Serial Column Sequence
CDR_DBSPACE cdrspc # dbspace for syscdr database
CDR_QHDR_DBSPACE cdrspc # CDR queue dbspace (default same as
CDR_QDATA_SBSPACE cdrqueues # List of CDR queue smart blob spaces

Get Informix Dynamic Server V10: Superior Data Replication for Availability and Distribution now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.