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
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.
Altering multiple tables in a replicate set
You can alter multiple replicated tables for replicates that belong to the same replicate set and then remaster those tables as a group.

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.
      - 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.
        Altering multiple tables in a replicate set
        You can alter multiple replicated tables for replicates that belong to the same replicate set and then remaster those tables as a group.
        Adding a Replicated Column
        Removing replicated columns
        You can alter replicated tables to remove columns from replication.
        Modifying the data type or size of a replicated column
        You can modify the size or type of a replicated column for all basic data types and for the BOOLEAN and LVARCHAR extended types. Modifying the data type or size of columns of other extended types is not supported. The replicate must be a master replicate.
        Changing the Name of a Replicated Column, Table, or Database
        Changing or re-creating primary key columns
        You can change or re-create the primary key columns definition of a replicated table while replication is active.
        Attaching a New Fragment to a Replicated Table
        You can attach a new fragment to a replication table while replication is active.
        Remastering a Replicate
        You must remaster a replicate if you add a replicated column, drop a replicated column, or change a classic replicate into a mastered replicate. If you modify a replicated column, you can remaster, but remastering is not mandatory.
      - 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

Altering multiple tables in a replicate set

You can alter multiple replicated tables for replicates that belong to the same replicate set and then remaster those tables as a group.

About this task

Instead of remastering the replicates individually for each table that you alter, you create a derived replicate set that contains only the replicates that must be remastered. You do not specify the names of the replicates. The server identifies which replicates have tables that must be remastered and adds them to the derived set for you. After you remaster and synchronize the derived replicate set, you delete it.

Procedure

To alter replicated tables in a replicate set:

Run the ALTER operation on the tables on all replication servers.
If the replicate set is included in a grid, you can alter the tables on one server and propagate the changes to all other servers.
Create a derived replicate set by running the cdr define replicateset command with the --needRemaster option.
Remaster the tables in the derived replicate set by running the cdr remaster replicateset command.
The replicate definitions are updated in the global catalogs of the replication servers.
Synchronize the derived replicate set by running the cdr check replicateset with the --repair option or by running the cdr sync replicateset command.
Drop the derived replicate set by running the cdr delete replicateset command.