Home
Administering
In addition to administering the database server, you can tune performance, replicate data, and archive data.
Enterprise Replication
The HCL® Informix® Enterprise Replication Guide describes the concepts of data replication using Informix Enterprise Replication, including how to design your replication system, as well as administer and manage data replication throughout your enterprise.
Setting up and managing Enterprise Replication
After you design your replication system, you define it and start replication.
Managing Replication Servers and Replicates
Resynchronizing Data among Replication Servers
If replication has failed for some reason and data is not synchronized, there are different ways to correct data mismatches between replicated tables.
Checking Consistency and Repairing Inconsistent Rows
A consistency check compares the data between a reference server and one or more target servers and then generates a report that describes any inconsistencies. You can choose to repair inconsistent rows during a consistency check.
Implementing a custom checksum function
You can implement a custom checksum function for consistency checking if you do not want to use the checksum function that is included with the database server.

Administering
In addition to administering the database server, you can tune performance, replicate data, and archive data.
- System administration
  These topics contain concepts, procedures, and reference information for database and database server administrators to use for managing and tuning HCL Informix® database servers.
- Backup and Restore Guide
  The Informix® Backup and Restore Guide describes how to use the Informix ON-Bar and ontape utilities to back up and restore database server data. These utilities enable you to recover your databases after data is lost or becomes corrupted due to hardware or software failure or accident.
- Enterprise Replication
  The HCL® Informix® Enterprise Replication Guide describes the concepts of data replication using Informix Enterprise Replication, including how to design your replication system, as well as administer and manage data replication throughout your enterprise.
  - About Enterprise Replication
    Informix® Enterprise Replication generates and manages multiple copies of data at one or more sites, which allows an enterprise to share corporate data throughout its organization.
  - Planning and designing for Enterprise Replication
    Before you set up your replication system, plan how to include Enterprise Replication into your database server environment, design your database schema by following Enterprise Replication requirements, and then design your replication system between database servers.
  - Setting up and managing Enterprise Replication
    After you design your replication system, you define it and start replication.
    - Preparing the Replication Environment
      The following topics explain the steps that are required for setting up Enterprise Replication.
    - Using High-Availability Clusters with Enterprise Replication
    - Defining Replication Servers, Replicates, Participants, and Replicate Sets
      These topics describe the steps defining and starting Enterprise Replication.
    - Grid setup and management
      A grid is a set of replication servers that are configured to simplify administration. When you run SQL data definition statements from within a grid context on a grid server, the statements propagate to all servers in the grid. You can run SQL data manipulation statements and routines through grid routines. You can choose to set up replication automatically when you create a table through a grid. You can propagate external files to other servers in the grid.
    - Shard cluster setup
      Sharding is a way to horizontally partition a single table across multiple database servers in a shard cluster. Enterprise Replication moves the data from the source server to the appropriate target server as specified by the sharding method. You query a sharded table as if the entire table is on the local server. You do not need to know where the data is. Queries that are performed on one shard server retrieve the relevant data from other servers in a shard cluster. Sharding reduces the index size on each shard server and distributes performance across hardware. You can add shard servers to the shard cluster as your data grows.
    - Managing Replication Servers and Replicates
      - Managing Replication Servers
      - Managing Replicates
      - Managing Replicate Sets
      - Managing Templates
      - Managing Replication Server Network Connections
      - Resynchronizing Data among Replication Servers
        If replication has failed for some reason and data is not synchronized, there are different ways to correct data mismatches between replicated tables.
        Performing Direct Synchronization
        Direct synchronization replicates every row in the specified replicate or replicate set from the reference server to all the specified target servers. You can use direct synchronization to populate a new target server, or an existing target server that has become severely inconsistent.
        Checking Consistency and Repairing Inconsistent Rows
        A consistency check compares the data between a reference server and one or more target servers and then generates a report that describes any inconsistencies. You can choose to repair inconsistent rows during a consistency check.
        Interpreting the Consistency Report
        The consistency report displays information about differences in replicated data within the replicate or replicate set.
        Increase the speed of consistency checking
        You can increase the speed of checking the consistency of replicates or replicate sets with the cdr check replicate or cdr check replicateset commands in several ways.
        Repair inconsistencies by time stamp
        You can repair inconsistencies based on the latest time stamps among the participants instead of specifying a master server.
        Repairing inconsistencies while enabling a replication server
        If a replication server is in disabled mode, you can enable it and repair inconsistencies with the cdr check replicateset command.
        Implementing a custom checksum function
        You can implement a custom checksum function for consistency checking if you do not want to use the checksum function that is included with the database server.
        Rules for custom checksum functions
        The idschecksum.c file in the $INFORMIXDIR/demo/checksum directory contains code that you can use for your checksum functions. You can replace the checksum generation portion of the code with your custom code.
        Repairing Failed Transactions with ATS and RIS Files
        You can repair failed or inconsistent transactions using an ATS or RIS file if you defined the replicate or replication server with the -ats or -ris option and the ATS or RIS files are being generated in text format.
        Resynchronize data manually
        Manual resynchronization involves replacing the inconsistent table in the target database with a copy of the correct table from the reference database.
      - Alter, rename, or truncate operations during replication
        When Enterprise Replication is active and data replication is in progress, you can perform many types of alter, rename, or truncate operations on replicated tables and databases.
      - Recapture replicated transactions
        If you want a transaction to continue to be replicated after it reaches the target replication servers, you can use the ifx_set_erstate() procedure.
    - Monitor and troubleshooting Enterprise Replication
      You can monitor and diagnose problems with the Enterprise Replication system by using several different methods, depending on your needs.
  - Push data feature
  - Loopback replication
  - Appendixes

Implementing a custom checksum function

You can implement a custom checksum function for consistency checking if you do not want to use the checksum function that is included with the database server.

About this task

The $INFORMIXDIR/extend/checksum directory contains sample checksum function code and registration statements.

Procedure

To implement a custom checksum function:

Using the idschecksum.c file in the $INFORMIXDIR/demo/checksum directory as a template, write a C language function that creates a checksum.
Overload the function for each of the supported data types.
Compile the function code into a shared object file.
Save a copy of the shared object file in the $INFORMIXDIR/extend/checksum directory on all replication servers.
To register the function:
1. Modify the idschecksum.sql file in the $INFORMIXDIR/demo/checksum directory to include the name of your function.
2. Run the SQL statements on each replication server.

What to do next

Specify your checksum function name with the --checksum option when you run the cdr check replicate or cdr check replicateset command.

If the cdr check replicate or cdr check replicateset command fails with return code 172, your checksum function is not installed and registered on all replication servers.