Protect the Physical Log, Logical Log, and sysmaster

These three elements of an Informix database are completely interrelated, and the loss of any one of them will require a physical restore of all of them. Depending on which of them is damaged, it also could mean a restore of the entire database. That is why you should seriously consider the following recommendations for any production Informix database. The first set of recommendations has to do with moving the physical and logical logs to their own dbspaces. Since all three objects are interrelated, this doesn’t actually decrease the chance that you’ll need to do a restore; what it does is make it easier on Informix by distributing the load among three separate dbspaces. Distributing the load in this way makes it easier on Informix once you follow the second set of recommendations and mirror these dbspaces.

Recommendation: Put the Physical Log in Its Own dbspace

Moving the physical log into its own dbspace does not increase your data integrity, since the physical log, logical log, and sysmaster database are interdependent. It simply moves the physical log’s I/O operations to a separate dbspace. The following paragraphs show an example of moving the physical log (for an instance called crash) to a separate dbspace called plogdbs.

The first thing we need to do is to create a separate, mirrored dbspace called plogdbs, as shown in Example 14-3. (How to mirror an existing dbspace is covered later.)

Example 14-3. Creating a New dbspace ...

Get Unix Backup and Recovery now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.