Database and data requirements for clusters

For a high-availability cluster to function, your database and data must meet certain requirements.

Your database and data must meet the following requirements:
  • All data must be logged.

    All databases that you want to replicate must have transaction logging turned on.

    This requirement is important because the secondary database server uses logical-log records from the primary database server to update the data that it manages. If databases managed by the primary database server do not use logging, updates to those databases do not generate log records, so the secondary database server has no means of updating the replicated data. Logging can be buffered or unbuffered.

    If you must turn on transaction logging before you start HDR, see Turn on transaction logging with ontape.

  • The data must be located in dbspaces or sbspaces.

    If your primary database server has simple large objects stored in blobspaces, modifications to the data within those blobspaces is not replicated as part of normal HDR processing. However, simple-large-object data within dbspaces is replicated.

    Smart large objects, which are stored in sbspaces, are replicated. The sbspaces must be logged. User-defined types (UDTs) are replicated, unless they have out-of-row data stored in operating system files. Data types with out-of-row data are replicated if the data is stored in an sbspace or in a different table on the same database server.

    You can encrypt storage spaces on high-availability servers. The encryption state of corresponding storage spaces on HDR and RS primary and secondary servers can be different. The encryption state of corresponding storage spaces on SD primary and secondary servers must be the same.

  • The secondary servers must not use disk compression.

    If you use the HCL OneDB™ disk compression feature, data that is compressed in the source table is compressed in the target table. You cannot perform compression operations on an HDR secondary, RS secondary, or SD secondary server, because the HDR target server must have the same data and physical layout as the source server.