The term data queue refers to both the send queue and the receive queue. Enterprise Replication collects information from the logical logs and places the data to be transferred in the send queue. Then Enterprise Replication transfers the contents of the send queue to the receive queue on the target server. Enterprise Replication on the target reads the data from the receive queue and applies the changes to the tables on the target server.
The send and receive queues reside in memory and are managed by the Reliable Queue Manager (RQM). The CDR_QUEUEMEM configuration parameter (CDR_QUEUEMEM Configuration Parameter) specifies the amount of memory space that is available for the data queues.
When a queue in memory fills (for the receive queue, this only occurs with large transactions), the transaction buffers are written (spooled) to disk. Spooled transactions consist of transaction records (headers that contain internal information for Enterprise Replication), replicate information (summaries of the replication information for each transaction), and row data (the actual replicated data). Spooled transaction records and replication records are stored in transaction tables and replication tables in a single dbspace. Spooled row data is stored in one or more sbspaces.
By default, the transaction records and replication records are stored in the root dbspace. Because Enterprise Replication and other database servers become unavailable if the root dbspace fills, you should define a single, separate dbspace for the send and receive queue transaction records and replication records before you define the replication server.
To determine the size of your transaction record dbspace, you must determine the estimated number of transactions in a given period. You should allocate 110 bytes per transaction to the dbspace and allocate enough disk space to store 24 hours of transaction records. For example, if your network is down for 24 hours, and you estimate that you will log 1000 transactions each day, the size of the transaction record dbspace should be at least 108 kilobytes (110 bytes * 1000 transactions / 1024).
To create the transaction record dbspace, use onspaces -c. For example, to create a 110 kilobyte dbspace called er_dbspace using raw disk space on UNIX with an offset of 0, enter:
onspaces -c -d er_dbspace -p /dev/raw_dev1 -o 0 -s 110
The pathname for the dbspace cannot be longer than 256 bytes.
Set the CDR_QHDR_DBSPACE configuration parameter (CDR_QHDR_DBSPACE Configuration Parameter) in the ONCONFIG file to the location of the transaction record dbspace (er_dbspace, in this example).
For information on creating dbspaces, see the chapter on managing disk space in the IBM Informix Dynamic Server Administrator's Guide and the utilities chapter in the IBM Informix Administrator's Reference.
Replicated data might include UDT and CLOB or BLOB data types. Therefore, the spooled row data is stored as smart large objects in one or more sbspaces.
The CDR_QDATA_SBSPACE configuration parameter accepts multiple sbspaces, up to a maximum of 32 sbspaces. Enterprise Replication can support a combination of logging and non-logging sbspaces for storing spooled row data. If CDR_QDATA_SBSPACE is configured for multiple sbspaces, then Enterprise Replication uses all appropriate sbspaces in round-robin order. For more information, see CDR_QDATA_SBSPACE Configuration Parameter.
Follow these guidelines when creating sbspaces for spooled row data:
To determine the size of your spooled row data sbspaces, determine your log usage and then consider how much data you can collect if your network goes down. For example, assume that you usually log 40 megabytes of data each day, but only 10 percent of that is replicated data. If your network is down for 24 hours and you estimate that you will log 4 megabytes of replicated data each day, the size of the sbspaces you identify for the spooled row data must be a total of at least 4 megabytes.
On Windows, increase the resulting size of the sbspace by approximately a factor of two. (The default page size, the way that data maps onto a page, and the number of pages written to disk differs on Windows.)
To create row data sbspaces, use the onspaces -c utility. For example, to create a 4-megabyte sbspace, called er_sbspace, using raw disk space on UNIX with an offset of 0, enter:
onspaces -c -S er_sbspace -p /dev/rdsk/c0t1d0s4 -o 0 -s 4000\
-m /dev/rdsk2/c0t1d0s4 0 \
-Df "AVG_LO_SIZE=2,LOGGING=OFF"
The pathname for an sbspace cannot be longer than 256 bytes.
The -m option specifies the location and offset of the sbspace mirror. The -Df option specifies default behavior of the smart large objects stored in the sbspace:
Set this parameter to the expected average transaction size (in kilobytes). The database server uses this value to calculate the metadata size. The minimum value for AVG_LO_SIZE is 2 kilobytes, which is appropriate for Enterprise Replication in most cases. (The default value of AVG_LO_SIZE is 32 kilobytes.) If you set AVG_LO_SIZE to larger than the expected transaction size, you might run out of metadata space. If you set AVG_LO_SIZE too small, you might waste space on metadata.
Set this parameter to OFF to create an sbspace without logging. Set this parameter to ON to create an sbspace with logging. It is recommended that you use a combination of logging and non-logging sbspaces for Enterprise Replication. For more information, see Logging Mode for sbspaces.
Set the CDR_QDATA_SBSPACE configuration parameter in the ONCONFIG file to the location of the row data sbspace (er_sbspace, in this example). For more information, see CDR_QDATA_SBSPACE Configuration Parameter.
Enterprise Replication uses the default log mode that the sbspace was created with for spooling row data.
Create sbspaces with a default logging mode of ON or OFF according to the types of transactions Enterprise Replication replicates:
Create sbspaces with LOGGING set to ON to support these situations:
Enterprise Replication must use logging sbspaces for transactions involved in HDR.
Enterprise Replication uses logging sbspaces for transactions that are less than a page size (2K or 4K) of replicated data.
For logging sbspaces, performance might be enhanced because logging mode enables asynchronous IO. However, a logging sbspace consumes additional logical-log space.
Create sbspaces with LOGGING set to OFF to support replication of large transactions (greater than a page size of replicated data).
It is recommended that you mirror non-logging sbspaces. For more information, see the chapter on managing disk space in the IBM Informix Dynamic Server Administrator's Guide and the utilities chapter in the IBM Informix Administrator's Reference.
For non-logging sbspaces, performance is enhanced on the database server when Enterprise Replication spools to disk because Enterprise Replication writes less data to disk.
You can change the default logging mode of the row data sbspace if you have more than one sbspace specified by the CDR_QDATA_SBSPACE configuration parameter.
You can drop a row data sbspace if you have more than one sbspace specified by the CDR_QDATA_SBSPACE configuration parameter.