Understanding the importance of an appropriately configured disk subsystem

There are many types of disk subsystems in use to meet either business or performance needs. Not all of these disk subsystems are suitable for use by databases or CDC Replication out of the box. Some may need to be tuned to ensure that appropriate input/output semantics are in place for reliable continuous operation.

Symptoms of an unreliable disk subsystem

Without appropriate disk subsystem configuration, both the database itself or CDC Replication may exhibit any of a wide variety of input/output related errors, usually random in nature. Any one of them can stop replication. If the database transaction logs themselves become corrupted due to this kind of misconfiguration, then the database itself may become unrecoverable, putting the entire business at risk. Having an appropriately configured disk subsystem is therefore essential to the operation of both database and CDC Replication.

What makes a disk subsystem unreliable?

Typically, disk mounting options that interfere with or modify the read visibility of write operations are the ones which will cause data to be read inaccurately, thereby causing applications such as databases and CDC Replication to report errors and fail. The expectations of these semantics between the database and CDC Replication must be compatible with those provided by the options used to mount the disk subsystem in order to avoid corruption issues. Some databases exhibit specific behaviors only with certain disk subsystem types, so proper care and attention is needed to properly configure the disk subsystem.

Special notes regarding specific configurations

Direct I/O on Linux—Due to the nature of the implementation of direct I/O (directio) on Linux, applications that read from files being written using direct I/O must employ exactly the same direct I/O options as the writing application. If this is not done, the reading application may not ever see the data written by the writing application and the reading application can therefore exhibit a stall. Linux versions of CDC Replication prior to version 6.5.1 Interim Fix 17 for Oracle, version 6.5.2 Interim Fix 20 for Oracle, and IBM® Data Replication - CDC Replication versions prior to 10.2 for Oracle and Sybase can exhibit this behaviour under certain conditions. The best resolution is to upgrade to the latest Interim Fix level for CDC Replication or to version 10.2 or later for IBM Data Replication - CDC Replication.