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.
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.

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 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 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.

About this task

In this example, the primary server, named srv_pri, has failed over to an SD secondary server named srv_sds_sec. At this point, the primary server is srv_sds_sec, and any other secondary servers in the cluster are now pointing to srv_sds_sec. To restore the cluster to the way it was before srv_pri failed over, follow these steps:

Procedure

If necessary, set the following parameters in the onconfig file of srv_pri:
```
SDS_ENABLE 1
SDS_PAGING <path 1>,<path 2>
SDS_TEMPDBS <dbsname>,<dbspath>,<pagesize>,<offset>,<size> 
```
The dbsname value must be unique. In addition, the dbsname must be unique among all existing dbspaces, blobspaces, and sbspaces, including those (possibly disabled) temporary spaces that are inherited from a primary server. If you have multiple SD secondary servers, the dbsname value must be unique for each server and not shared with any other SD secondary server or the primary server. See Setting up a shared disk secondary server for more information about setting these parameters.
Initialize srv_pri as an SD secondary server by running the oninit command on srv_pri.
Perform a manual failover of srv_pri to make it the primary server:
```
onmode -d make primary srv_pri
```
The previous command removes srv_sds_sec from the cluster and makes srv_pri the primary server.
Restore srv_sds_sec as an SD secondary server by running the oninit command on srv_sds_sec.