Solving Common Configuration Problems

If you experience problems setting up Enterprise Replication, check the following:

• Make sure that you created an sbspace for the row data and set the CDR_QDATA_SBSPACE in the ONCONFIG file.

  For more information, see Setting Up Send and Receive Queue Spool Areas and CDR_QDATA_SBSPACE Configuration Parameter.

• Verify that the trusted environment is set up correctly.

  For more information, see Setting Up the Trusted Environment.

• Verify that your SQLHOSTS file is set up properly on each server participating in replication. You must set up database server groups in the SQLHOSTS file.

  For more information, see Verifying SQLHOSTS.

• Verify the format of the SQLHOSTS file.

  The network connection (not the shared memory connection) entry should appear immediately after the database server group definition. If the network connection does not appear immediately after the database server group definition, you might see the following error when you run cdr define server:

  command failed -- unable to connect to server specified (5)

  You might also see a message like the following in the message log for the target server:

  Reason: ASF connect error (-25592)

• Make sure that the unique identifier for each database server (i= in the options field of the SQLHOSTS information) is consistent across all nodes in the enterprise.

  For more information, see Database Server Groups on UNIX and Appendix F. SQLHOSTS Registry Key (Windows).

• Verify that the operating system times of the database servers that participate in the replicate are synchronized.

  For more information, see Time Synchronization.

• Make sure that the database server has adequate logical log disk space. If the database server does not have enough logical log space at initialization, you will see the following error:

  command failed -- fatal server error (100)

• Check the $INFORMIXDIR/etc/buildsmi.xxx files to see if a problem occurred when the databases server built the SMI tables.
• Make sure that the databases on all database server instances involved in replication are set to logging (unbuffered logging is recommended).

  For more information, see Unbuffered Logging.

• For replicates that use any conflict-resolution rule except ignore, make sure that you define shadow columns (CRCOLS) for each table involved in replication.

  For more information, see Preparing Tables for Conflict Resolution.

• If you defined a participant using SELECT * from table_name, make sure that the tables are identical on all database servers defined for the replicate.

  For more information, see Defining Participants and Participant Type.

• Verify that each replicated column in a table on the source database server has the same data type as the corresponding column on the target server.

  Enterprise Replication does not support replicating a column with one data type to a column on another database server with a different data type.

  The exception to this rule is cross-replication between simple large objects and smart large objects.

  For more information, see Enterprise Replication Data Types.

• Verify that all tables defined in a replicate have one PRIMARY KEY.

  For more information, see Primary Key Constraint, the IBM Informix Database Design and Implementation Guide, and IBM Informix Guide to SQL: Syntax.

• If HDR is enabled in the replication system, then all row data sbspaces must be created with logging by using the -Df LOGGING=ON option of the onspaces command.

  For more information, see Row Data sbspaces and the IBM Informix Dynamic Server Administrator's Guide.