Common configuration problems

If you experience problems setting up Enterprise Replication, check the configuration of your environment and database.

To solve configuration problems:
  • 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 Configuring secure ports for connections between replication servers.

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

    For more information, see Creating sqlhost group entries for replication servers.

  • Verify the format of the sqlhosts file.

    The network connection (not the shared memory connection) entry must be immediately after the database server group definition. If the network connection entry is not 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 domain.

    For more information, see Creating sqlhost group entries for replication servers.

  • 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 see the following error: 
    command failed -- fatal server error (100)
  • Check the files in the $INFORMIXDIR directory to see if a problem occurred when the database server built the SMI tables.
  • Make sure that the databases on all database server instances that are 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 and always-apply, make sure that you define shadow columns (CRCOLS) for each table that is involved in replication.

    For more information, see Preparing Tables for Conflict Resolution.

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

    For more information, see Participant definitions and Participant and participant modifier.

  • 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 Replication and data types.

  • Verify that all tables defined in a replicate have a replication key.

    For more information, see Unique key for replication.

  • If high-availability clusters are also in use in the domain, 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 HCL OneDB™ Administrator's Guide.