Planning for Disk Space Requirements

Enterprise Replication requires additional disk space for storing the logical logs and, depending on your conflict-resolution configuration, delete tables and shadow columns.

Logical Log Configuration Disk Space

The database server uses the logical log to store a record of changes to the data since the last archive. Enterprise Replication requires the logical log to contain entire row images for updated rows, including deleted rows.

The database server normally logs only columns that have changed. This behavior is called the logical-log record reduction option. Enterprise Replication deactivates this option for tables that participate in replication. (The logical-log record reduction option remains enabled for tables that do not participate in Enterprise Replication.) Enterprise Replication logs all columns, not only the columns that have changed, which increases the size of your logical log.

To determine the size of your logical log, examine your data activity for normal operations and for the replication system you defined. Keep in mind that defining replication on a table causes Enterprise Replication to deactivate log reduction for that table, and that your transactions might log more data.

Logical Log Configuration Guidelines

Use the following guidelines when configuring your logical log files:

• Make sure that all logical log files are approximately the same size.
• Make the size of the logical log files large enough so that the database server switches log files no more than once every 15 minutes during normal processing.
• Plan to have sufficient logical-log space to hold at least four times the maximum transaction size.
• Set LTXEHWM (long-transaction, exclusive-access, high-watermark) 30 percent larger than LTXHWM (long-transaction high-watermark).

For more information about logical logs and these configuration parameters, see IBM Informix Administrator's Reference and IBM Informix Dynamic Server Administrator's Guide.

The database server can add logs dynamically when Enterprise Replication enters blockout mode if the CDR_MAX_DYNAMIC_LOGS configuration parameter is set to a non-zero integer. For more information, see Preventing DDRBLOCK Mode.

Delete Table Disk Space

If you use the time stamp or time stamp and SPL routine conflict-resolution rules, Enterprise Replication creates delete tables to keep track of modified rows for conflict resolution. (Enterprise Replication creates delete tables only for tables that have replicates defined with a conflict-resolution rule other than ignore.) Delete tables handle conflicts such as when a DELETE or UPDATE finds no corresponding row on the target. The DTCleaner thread removes a row from the delete tables after all the servers have progressed beyond that row. For more information, see Conflict-Resolution Rule.

Delete tables are created on the database server where the data originates and on all the database servers to which data gets replicated. Delete tables are stored in the same dbspaces, using the same fragmentation strategy, as their base tables.

To determine the disk space requirements to accommodate delete tables, estimate how many rows will be deleted or modified. For example, if the base table has 100 megabytes of data, but only half the rows might be deleted or modified, then 50 megabytes is a reasonable estimate for the size of the delete table.

Shadow Column Disk Space

When you define a replicate that uses any conflict-resolution rule except ignore, you must define shadow columns (CRCOLS) with the WITH CRCOLS clause. The shadow columns, cdrserver and cdrtime, store server and time-stamp information that Enterprise Replication uses for conflict resolution. The two shadow columns are integers, which adds a total of 8 bytes to each row in the table involved in a replicate that uses conflict resolution.

For more information, see Conflict-Resolution Rule and Preparing Tables for Conflict Resolution.