Home
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.
Administrator's Guide
The Informix® Administrator's Guide provides the information required to administer HCL Informix.
High availability and scalability
A successful production environment requires database systems that are always available, with minimal if any planned outages, and that can be scaled quickly and easily as business requirements change.
Cluster failover, redirection, and restoration
To maintain availability, you must plan for the failover of primary servers, redirecting client connections from unavailable servers, and restoring the cluster to its original configuration after a failure.
Recover HDR and RS clusters after failure
When you restore the HDR or RS cluster back to the original configuration, you might need to restore critical media, as well as restart and configure servers in the cluster.
Recovering an HDR cluster after the secondary server became the primary server
If a secondary server in an HDR cluster became the primary server after the original primary server failed, you can use a script to reestablish the original primary and convert the current primary server back to a secondary 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.
  - List of utilities
    HCL Informix® includes utilities and applications that you can use to perform administrative tasks and capture information about configuration and performance.
  - Administrator's Guide
    The Informix® Administrator's Guide provides the information required to administer HCL Informix.
    - The database server
    - Disk, memory, and process management
    - Logging and log administration
    - Fault tolerance
    - High availability and scalability
      A successful production environment requires database systems that are always available, with minimal if any planned outages, and that can be scaled quickly and easily as business requirements change.
      - Strategies for high availability and scalability
        HCL Informix® database software can be customized to create the appropriate high availability and scalability solution to match your business goals and environment.
      - High-availability cluster configuration
      - Connection management through the Connection Manager
        Connection Managers can control automatic failover for high-availability clusters, monitor client connections and direct requests to appropriate database servers, act as proxy servers and handle client/server communication, and prioritize connections between application servers and the primary server of a high-availability cluster. Connection Managers support high-availability clusters, replicate sets, server sets, and grids.
      - Cluster failover, redirection, and restoration
        To maintain availability, you must plan for the failover of primary servers, redirecting client connections from unavailable servers, and restoring the cluster to its original configuration after a failure.
        Failover configuration for high-availability clusters
        A failure in a high-availability cluster means that one of the servers is no longer available. If a primary server fails, you must promote a secondary server to the role of primary server. Connection Managers can be configured to perform automatic failover.
        Redirection and connectivity for data-replication clients
        When any server in a high-availability cluster becomes unavailable, any client connections to it should be redirected to an available server. The best way to handle connection redirection is to use Connection Manager to automatically reconnect client connections to the servers that you specify in service level agreements. Alternatively, you can control connection redirection with environment variables or connection information.
        Recover HDR and RS clusters after failure
        When you restore the HDR or RS cluster back to the original configuration, you might need to restore critical media, as well as restart and configure servers in the cluster.
        Recovering a cluster after critical data is damaged
        If one of the database servers in a high-availability cluster experiences a failure that damages the root dbspace, the dbspace that contains logical-log files, or the dbspace that contains the physical log, you must treat the failed database server as if it has no data on the disks as is being started for the first time. Use the functioning database server with the intact disks as the database server with the data.
        Restarting HDR or RS clusters after a network failure
        After a network failure, the HDR or RS cluster might need to be restarted. After a network failure, the primary database server is in online mode, and the secondary database server is in read-only mode. Replication is turned off on both database servers (state = off).
        Restarting HDR or RS clusters if the secondary server fails
        If you must restart HDR or an RS cluster after a failure of a secondary server, in addition to starting the secondary server, you might need to perform a logical log restore on the secondary server.
        Recovering an HDR cluster after the secondary server became the primary server
        If a secondary server in an HDR cluster became the primary server after the original primary server failed, you can use a script to reestablish the original primary and convert the current primary server back to a secondary server.
        Restart if the primary server fails
        The process for restarting an HDR or RS cluster after the primary server fails depends on whether a secondary server became the primary server, and the method by which the secondary server became the primary server.
        Recovering a shared-disk cluster after data is damaged
        If a shared-disk cluster fails, you must perform a restore of affected dbspaces. The type of restore that you need to perform depends on whether critical data is damaged.
        Recovering an SD cluster after the secondary server became the primary server
        If a secondary server in an SD cluster became the primary server after the original primary server failed, you can use a script to reestablish the original primary and convert the current primary server back to a secondary server.
    - Distributed data
    - Overview of automatic monitoring and corrective actions
      You can use the SQL administration API, the Scheduler, and drill-down queries to manage automatic maintenance, monitoring, and administrative tasks.
  - Administrator's Reference
    The Informix® Administrator's Reference includes comprehensive descriptions of HCL Informix configuration parameters, the system-monitoring interface (SMI) tables in the sysmaster database, the syntax of database server utilities such as onmode and onstat, logical-log records, disk structures, event alarms, and unnumbered error messages.
  - DB-Access User's Guide
    The Informix® DB-Access User's Guide describes how to use the DB-Access utility to access, modify, and retrieve information from Informix database servers.
  - High-Performance Loader User's Guide
    The describes how to use the HCL Informix® to load and unload large quantities of data efficiently to or from Informix databases.
  - Performance Guide
    The Informix® Performance Guide describes how to configure and operate your HCL Informix database server to improve overall system throughput and to improve the performance of SQL queries.
  - SNMP Subagent Guide
    The describes the Simple Network Management Protocol (SNMP) and the software that you need to use SNMP to monitor and manage HCL Informix® database servers and databases.
  - InformixHQ Guide
    InformixHQ is a modern web console for visualizing, monitoring, and managing your Informix server instances. It is purpose built for ease-of-use, scaling out, and optimizing DevOps needs. It provides critical performance management capabilities, monitoring how key performance metrics are changing over time and tracking how efficiently Informix is running your workload even when you’ve stepped away from your screen. Its monitoring system feeds directly into a customizable alerting system so you can be immediately alerted via email, Twilio, or PagerDuty whenever an issue occurs on one of your Informix database server instances. InformixHQ is designed to be scalable to efficiently manage and monitor as many Informix database server instances as you need. Moreover, it's a tool that can be shared by the DBAs, the app developers, the ops engineers, and management and accessed from any desktop, laptop, or mobile device. InformixHQ is the centralized hub for graphical monitoring, alerting, and administration of your 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.

Recovering an HDR cluster after the secondary server became the primary server

If a secondary server in an HDR cluster became the primary server after the original primary server failed, you can use a script to reestablish the original primary and convert the current primary server back to a secondary server.

About this task

Suppose the primary server, named srv_pri, has encountered an error that has caused it to fail over to an HDR secondary server named srv_hdr_sec. At this point, the primary server is srv_hdr_sec, and any other secondary servers in the cluster are now pointing to srv_hdr_sec.

To restore the cluster to the way it was before srv_pri failed over, follow these steps:

Procedure

Initialize srv_pri as the HDR secondary server by running the appropriate command:
UNIX™ systems:
```
$INFORMIXDIR/bin/hdrmksec.sh srv_hdr_sec
```
Windows™ systems:
```
hdrmksec.bat srv_hdr_sec
```
Change srv_pri to the primary server by running:
```
onmode -d make primary srv_pri
```
This command makes srv_pri the primary server, and redirects any other secondary servers in the cluster to point to the new primary server. The command also shuts down the old HDR primary (srv_hdr_sec) because only a single primary server can exist in a high-availability environment.
Initialize srv_hdr_sec as the HDR secondary server by running the following command:
On UNIX™ systems:
```
$INFORMIXDIR/bin/hdrmksec.sh srv_pri
```
On Windows™ systems:
```
hdrmksec.bat srv_pri
```