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.
Defining Replication Servers, Replicates, Participants, and Replicate Sets
These topics describe the steps defining and starting Enterprise Replication.
Define a replicate
To define a replicate, use the cdr define replicate command.
Replicate types
You can choose a replicate type depending on whether you want the schema definitions on all participants to be the same. A master replicate enforces consistency between the schema definitions of the participants and the schema definition on a designated server. A classic replicate does not check the schema definitions of the participants.

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.
      - Starting Database Servers
        The database server must be online before you can define it as a replication server.
      - Defining Replication Servers
        You must define a replication server to create a replication domain or to add a server to an existing domain.
      - Define a replicate
        To define a replicate, use the cdr define replicate command.
        Participant definitions
        You must define a participant for each server that is involved in the replicate definition by running the cdr define replicate command. Each participant in a replicate must specify a different database server.
        Replicate types
        You can choose a replicate type depending on whether you want the schema definitions on all participants to be the same. A master replicate enforces consistency between the schema definitions of the participants and the schema definition on a designated server. A classic replicate does not check the schema definitions of the participants.
        Master Replicate Verification
        Creating Strict Master Replicates
        Creating Empty Master Replicates
        Defining Shadow Replicates
        Specifying Conflict Resolution Rules and Scope
        You specify the conflict resolution rule in the replicate definition.
        Specifying Replication Frequency
        Setting Up Failed Transaction Logging
        The Aborted Transaction Spooling (ATS) files and Row Information Spooling (RIS) files contain information about failed transactions and aborted rows. You can use this information to help you diagnose problems that arise during replication.
        Replicate only changed columns
        You can choose to replicate only those columns that have changes instead of entire rows.
        Using the IEEE Floating Point or Canonical Format
        You can specify how the FLOAT and SMALLFLOAT data types are handled, depending on your platform.
        Enabling Triggers
        By default, when a replicate causes an insert, update, or delete on a target table, triggers associated with the table are not executed. However, you can specify that triggers are executed when the replicate data is applied by enabling triggers in the replicate definition.
        Enabling code set conversion between replicates
        You can enable code set conversion to allow replication of data between servers that use different code sets.
        Replication to SPL routine
      - Define replicate sets
        When you define a replicate set, you specify the type of replicate set, the replicates that belong to the replicate set, and the frequency of replication for the member replicates.
      - Initially Synchronizing Data Among Database Servers
      - Set up replication through templates
        Enterprise Replication provides templates to allow easy setup and deployment of replication for clients with large numbers of tables to replicate. A template uses schema information about a database, a group of tables, columns, and replication keys to define a group of master replicates and a replicate set.
    - 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
    - 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

Replicate types

You can choose a replicate type depending on whether you want the schema definitions on all participants to be the same. A master replicate enforces consistency between the schema definitions of the participants and the schema definition on a designated server. A classic replicate does not check the schema definitions of the participants.

By default, replicates are master replicates. If you do not specify a master server, the master replicate is based on the first participant. Dictionary information is then stored about replicated column attributes for the participant you specify. Enterprise Replication checks for consistency between the master definition and local participant definitions. Checks are run when the replicate is defined and each time a new participant is added to the replicate, thus avoiding runtime errors. Verification also occurs each time that the master replicate is started on a server.

If you do not want to verify the schema, create a classic replicate. For example, if you want to create a data consolidation system in which one server only receives data from other servers that only send data, create a classic replicate.

Defining a replicate as a master replicate provides several advantages:

Ensures data integrity by verifying that all participants in the replicate have table and replicated column attributes that match the master replicate definition.
Provides automatic table generation on participants that do not already contain the table that is specified in the master replicate. However, Enterprise Replication cannot create tables with user-defined data types.
Allows alter operations on the replicated tables.

When you define a master replicate, you can specify a participant that is on the server for which you are running the command. By default, the first participant that you list in the cdr define replicate command is the used to create the dictionary information for the master replicate. The additional participants in the cdr define replicate command are verified against the master definition and added to the replicate if they pass validation. If any participant fails validation, the cdr define replicate command fails and that participant is disabled.