Ships from: santa cruz, CA
Usually ships in 1-2 business days
Ships from: fallbrook, CA
Usually ships in 1-2 business days
Ships from: acton, MA
Usually ships in 1-2 business days
Unix Backup & Recovery provides a complete overview of all facets of Unix backup and recovery, and offers practical, affordable backup and recovery solutions for environments of all sizes and budgets. The book begins with detailed explanations of the native backup utilities available to the Unix administrator, and ends with practical advice on choosing a commercial backup utility.This book:
This guide provides a complete overview of all facets of UNIX backup and recovery and offers practical, affordable backup and recovery solutions for environments of all sizes and budgets with explanations from freely available systems to large-scale commercial utilities.
Dedication;
Preface;
I Wish I Had This Book;
Only the Recovery Matters;
Products Change;
Backing Up Databases Is Not That Hard;
Bare-Metal Recovery Is Not That Hard;
The Scripts in This Book Actually Work;
How This Book is Organized;
Conventions;
How to Contact Us;
This Book Was a Team Effort;
Introduction;
Chapter 1: Preparing for the Worst;
1.1 My Dad Was Right;
1.2 Developing a Disaster Recovery Plan;
1.3 Step 1: Define (Un)acceptable Loss;
1.4 Step 2: Back Up Everything;
1.5 Step 3: Organize Everything;
1.6 Step 4: Protect Against Disasters;
1.7 Step 5: Document What You Have Done;
1.8 Step 6: Test, Test, Test;
1.9 Put It All Together;
Chapter 2: Backing It All Up;
2.1 Don’t Skip This Chapter!;
2.2 Why Should You Read This Book?;
2.3 How Serious Is Your Company About Backups?;
2.4 You Can Find a Balance;
2.5 Deciding What to Back Up;
2.6 Deciding When to Back Up;
2.7 Deciding How to Back Up;
2.8 Storing Your Backups;
2.9 Testing Your Backups;
2.10 Monitoring Your Backups;
2.11 Following Proper Development Procedures;
2.12 Unrelated Miscellanea;
2.13 Good Luck;
Freely Available Filesystem Backup & Recovery Utilities;
Chapter 3: Native Backup & Recovery Utilities;
3.1 An Overview;
3.2 Backing Up with the dump Utility;
3.3 Restoring with the restore Utility;
3.4 Limitations of dump and restore;
3.5 Features to Check For;
3.6 Backing Up and Restoring with the cpio Utility;
3.7 Backing Up and Restoring with the tar Utility;
3.8 Backing Up and Restoring with the dd Utility;
3.9 Comparing tar, cpio, and dump;
3.10 How Do I Read This Volume?;
Chapter 4: Free Backup Utilities;
4.1 The hostdump.sh Utility;
4.2 The infback.sh, oraback.sh, and syback.sh Utilities;
4.3 A Really Fast tar Utility: star;
4.4 Recording Configuration Data: The SysAudit Utility;
4.5 Displaying Host Information: The SysInfo Utility;
4.6 Performing Remote Detections: The queso Utility;
4.7 Mapping Your Network: The nmap Utility;
4.8 AMANDA;
Commercial Filesystem Backup & Recovery Utilities;
Chapter 5: Commercial Backup Utilities;
5.1 What to Look For;
5.2 Full Support of Your Platforms;
5.3 Backup of Raw Partitions;
5.4 Backup of Very Large Filesystems and Files;
5.5 Simultaneous Backup of Many Clients to One Drive;
5.6 Simultaneous Backup of One Client to Many Drives;
5.7 Data Requiring Special Treatment;
5.8 Storage Management Features;
5.9 Reduction in Network Traffic;
5.10 Support of a Standard or Custom Backup Format;
5.11 Ease of Administration;
5.12 Security;
5.13 Ease of Recovery;
5.14 Protection of the Backup Index;
5.15 Robustness;
5.16 Automation;
5.17 Volume Verification;
5.18 Cost;
5.19 Vendor;
5.20 Conclusions;
Chapter 6: High Availability;
6.1 What Is High Availability?;
6.2 HA Building Blocks;
6.3 Commercial HA Solutions;
6.4 The Impact of an HA Solution;
Bare-Metal Backup & Recovery Methods;
Chapter 7: SunOS/Solaris;
7.1 What About Fire?;
7.2 Homegrown Bare-Metal Recovery;
7.3 Recovering a SunOS/Solaris System;
Chapter 8: Linux;
8.1 How It Works;
8.2 A Sample Bare-Metal Recovery;
Chapter 9: Compaq Tru64 Unix;
9.1 Compaq’s btcreate Utility;
9.2 Homegrown Bare-Metal Recovery;
Chapter 10: HP-UX;
10.1 HP’s make_recovery Utility;
10.2 The copyutil Utility;
10.3 Using dump and restore;
Chapter 11: IRIX;
11.1 SGI’s Backup and Restore Utilities;
11.2 System Recovery with Backup Tape;
11.3 Homegrown Bare-Metal Recovery;
Chapter 12: AIX;
12.1 IBM’s mksysb Utility;
12.2 IBM’s Sysback/6000 Utility;
12.3 System Cloning;
Database Backup & Recovery;
Chapter 13: Backing Up Databases;
13.1 Can It Be Done?;
13.2 Confusion: The Mysteries of Database Architecture;
13.3 The Muck Stops Here: Databases in Plain English;
13.4 What’s the Big Deal?;
13.5 Database Structure;
13.6 An Overview of a Page Change;
13.7 What Can Happen to an RDBMS?;
13.8 Backing Up an RDBMS;
13.9 Restoring an RDBMS;
13.10 Documentation and Testing;
13.11 Unique Database Requirements;
Chapter 14: Informix Backup & Recovery;
14.1 Informix Architecture;
14.2 Automating Informix Startup: The dbstart.informix.sh Script;
14.3 Protect the Physical Log, Logical Log, and sysmaster;
14.4 Which Backup Utility Should I Use?;
14.5 Physical Backups Without a Storage Manager: ontape;
14.6 Physical Backups with a Storage Manager: onbar;
14.7 Recovering Informix;
14.8 Logical Backups;
Chapter 15: Oracle Backup & Recovery;
15.1 Oracle Architecture;
15.2 Physical Backups Without a Storage Manager;
15.3 Physical Backups with a Storage Manager;
15.4 Managing the Archived Redologs;
15.5 Recovering Oracle;
15.6 Logical Backups;
15.7 A Broken Record;
Chapter 16: Sybase Backup & Recovery;
16.1 Sybase Architecture;
16.2 Physical Backups Without a Storage Manager;
16.3 Physical Backups with a Storage Manager;
16.4 Recovering Sybase;
16.5 Logical Backups;
16.6 An Ounce of Prevention . . .;
Backup & Recovery Potpourri;
Chapter 17: ClearCase Backup & Recovery;
17.1 ClearCase Architecture;
17.2 VOB Backup and Recovery Procedures;
17.3 View Backup and Recovery Procedures;
17.4 Summary;
Chapter 18: Backup Hardware;
18.1 Choosing on a Backup Drive;
18.2 Using Backup Hardware;
18.3 Tape Drives;
18.4 Optical Drives;
18.5 Automated Backup Hardware;
18.6 Vendors;
18.7 Hardware Comparison;
Chapter 19: Miscellanea;
19.1 Volatile Filesystems;
19.2 Demystifying dump;
19.3 Gigabit Ethernet;
19.4 Disk Recovery Companies;
19.5 Yesterday;
19.6 Trust Me About the Backups;
Colophon;
Chapter 14: Informix Backup & Recovery
Informix is one of the easiest databases to back up and recover. Although it is a highly complex, very advanced relational database, it has the least complex recovery of all three database products covered in this book. Informix also was the first among the three products to come out with a live, multilevel backup and restore program. tbtape, as it was called in the early days, was simple enough to understand and use, yet smart enough to handle the job. (The complete documentation set for tbtape was only 14 pages.)
The large number of utilities available to back up Informix databases can be quite confusing, but each is actually made for a separate application. ontape (as tbtape is now called) is Informix's oldest physical backup utility and is used primarily in environments without a storage manager. onbar is Informix's newest physical backup utility and is designed only for environments with a storage manager. onunload is a logical backup utility, and onarchive is deprecated and should not be used for new backup systems.
This chapter covers the three basic ways to back up and recover an Informix database:
- Physical backups without a storage manager, using ontape
- Physical backups with a storage manager, using onbar
- Logical backups, using onunload
This chapter also makes recommendations on how to increase the data integrity of your Informix instance, as well as how to recover the instance when necessary.
Informix Architecture
Let's begin with a discussion of Informix's architecture. This chapter uses only Informix-specific terms. To see how a particular term relates to one used in Oracle or Sybase, consult Chapter 13, Backing Up Databases.
Power User's View
Power users typically understand these elements of Informix architecture. They may use them when conversing with database administrators and system administrators.
Instance
Similar to the other database products, an Informix instance is a single connection to shared memory. It is represented by one or more oninit processes. When Informix is started or stopped, these processes appear and disappear. Informix used to use the term "server" when referring to an instance, hence the environment variable DBSERVERNAME. This created a problem, though. System administrators would think that they were speaking about a Unix server, and database administrators would think they were talking about an Informix server. Although some of these variables are still around, Informix documentation now typically uses the term "server" when referring to the database installation and software and "instance" when referring to the connection to shared memory. To keep from confusing any DBAs who may be reading this chapter, I use the term "host" or "machine" when referring to the machine on which the Informix instance resides.
TIP: Some Informix backup utilities back up on the instance level, although they are able to restore at the dbspace level. (dbspaces are covered later.) That is, they back up one instance at a time. The utilities also back up the entire instance, although they will allow you to recover a single dbspace from such a backup. (onbar can back up a single space.)
Database
An Informix database's architecture is not that much different from any other product's database, except that multiple databases may be found inside a single instance. Informix cannot recover a single database inside an instance. However, a DBA who isolated a database by putting it into a separate dbspace then could recover that database by recovering that dbspace. This is a very common practice.
Table or index
An Informix table or index is functionally the same as any RDBMS table or index. (They work differently internally, but that is not important to understand for backup and recovery purposes.) Informix cannot back up or recover on the table or index level, except via the export/import facilities. (Again, a DBA who isolated a table in a separate dbspace could recover that table by itself by recovering that dbspace.)
DBA's View
Typically, only a DBA needs to understand the terms covered in this section. An SA who also understands them will be better equipped to communicate with the DBA about backup issues.
BLOB space
All Informix Binary Large Object (BLOB) data is kept inside the database, but there is a special dbspace for BLOB data.
Chunk
A chunk is a physical portion of disk on which Informix stores its data. A chunk can be either a raw partition or a filesystem file. Informix suggests that a chunk's name be a symbolic link to the actual chunk. For example, if you are using /dev/rdsk/c6t0d0s1 as a chunk, you could create a symbolic link named /dev/informix/chunk1 that points to /dev/rdsk/c6t0d0s1. That way, if there are ever any problems with that disk, you could replace the disk with another one and just change the symbolic link.
Page
An Informix page is a physically contiguous portion of a chunk. A page can be either 2 KB or 4 KB, depending on the operating system.
Extent
An extent is a logical grouping of at least four physically contiguous pages. When you create a table in Informix, you specify the amount of space in kilobytes. Informix then will allocate as many contiguous pages as possible to satisfy this request. If it cannot allocate enough space in one contiguous section, other extents will be created as necessary. As a table grows, the existing extents that a table is using are used up, and Informix will allocate additional pages for that table. It will try to allocate physically contiguous pages if it can. If not, it again will allocate another extent.
Other database products' extents may not be physically contiguous, depending on when and how they were created.
tblspace
An Informix tblspace is a logical grouping of all extents allocated to a table--possibly spanning multiple chunks. It is what most Informix DBAs are referring to when they say something that sounds like "tablespace," but the proper Informix spelling is "tblspace."
Tablespace
Informix documentation also uses the spelling "tablespace," and it is defined as the space that a table occupies within a chunk. That is, it is a logical grouping of the extents within a chunk that are allocated to a table. They may or may not be physically contiguous. A tablespace does not span a chunk. This term "tablespace" (as opposed to "tblspace") is rarely used in Informix and is defined here only because you may encounter it in Informix documentation. An Informix chunk can contain several tablespaces for many tables.
TIP: To Oracle DBAs: Do not confuse either of these with what Oracle calls a "tablespace," since an Oracle tablespace is simply a logical collection of datafiles. The closest Informix equivalent to an Oracle tablespace would be a dbspace, which is defined below.
dbspace
A dbspace is a storage element that consists of one or more chunks. A dbspace contains one or more tblspaces, as defined earlier. Although Informix backups usually are done on the instance level, restores can be done on the dbspace level. That is, you can restore a single dbspace.
Fragment
When a table is partitioned across multiple dbspaces, the portion of the table that resides in a single dbspace is called a fragment. It does not present any unique backup requirements.
sysmaster database
The sysmaster database is the database of databases. That is, it is the master database within an Informix instance that keeps track of all databases within that instance. Remember, though, there may be multiple Informix instances on a single host, and there is no master database of all master databases.
Transaction
Informix transactions are the same as those in any other RDBMS. A transaction is a single atomic event that must complete successfully. Any partially completed (committed) transactions are rolled back if the instance crashes.
LRU queue
The least recently used (LRU) queues and their associated buffers are the part of shared memory that stores data that is about to be used (and may be changed) by transactions. Before a page is modified, it is read into one of the LRU queues, which are filled up in a random fashion. Informix then monitors these queues based on the
LRU_MAX_DIRTYandLRU_MIN_DIRTYparameters that are set to a percentage from 0 to 100 in the onconfig file. TheLRU_MAX_DIRTYparameter specifies what percentage of buffers in a single LRU queue must be dirty before the page cleaners start flushing and freeing queues, and theLRU_MIN_DIRTYparameter specifies the percentage of dirty buffers at which the page cleaners can stop.The cleaning works as follows: Once Informix determines that the LRU queues are dirty enough (as specified by the
LRU_MAX_DIRTYparameter), it starts flushing buffers starting with the least recently used buffers first. Once a buffer's dirty pages are flushed to disk, they are available for reuse. The page cleaners continue flushing queues to disk until they reach the value specified byLRU_MIN_DIRTY. Informix then continues to monitor the queues again until they reach the value specified byLRU_MAX_DIRTY, and the cleaning process starts again. As explained in "I'm Confused by All the Logging!" later in this section, higherLRU_MIN_DIRTYandLRU_MAX_DIRTYvalues result in higher data integrity. However, having a higherLRU_MAX_DIRTYvalue will result in more dirty pages being flushed during checkpoints. This means that your checkpoints will take longer.Physical log
Informix's physical log stores the before-images of any pages that have changed since the last checkpoint. That is, prior to modifying a page, Informix saves its before-image in the physical log. It does this only once per page; if the page is modified many times since the last checkpoint, it needs only to store the before-image once. It is simply a record of what the page looked like at the time the last checkpoint was taken. When a checkpoint occurs, all buffers are flushed to disk, and the physical log is cleared of all pages. Since a checkpoint occurs as part of a normal Informix shutdown, the physical log should be empty when an instance is started.
The physical log is then read during fast recovery, a special mode that an Informix instance goes into during initialization. During fast recovery, Informix looks in the physical log to see if it contains any before-images. If it does, it knows that the instance was not shut down properly, since a proper shutdown would have performed a checkpoint and emptied the physical log. By writing these before-images back to their original location, Informix returns the instance to what it looked like at the time the last checkpoint was taken. This is referred to as a known point of physical consistency. The logical logs then can be used to return the database to a point of logical consistency.
TIP: To the Oracle DBA: At first, this may sound exactly like Oracle's rollback segments, but it's slightly different. The first difference is that Oracle keeps the before-images associated with a particular transaction in its rollback segment until that transaction is committed. Informix clears the entire physical log after a checkpoint. Oracle also uses the rollback log during recovery to roll back, or "undo," a partially committed transaction. Informix uses the logical log (defined next) for this purpose.
Architecturally, the physical log is composed of two physical log buffers (in shared memory) and one actual physical log (on disk). For performance reasons, before-images actually are written to the physical log buffer during normal activity. Informix then flushes the physical log buffer to disk under any of three circumstances:
- During a checkpoint
- When a physical log buffer is full
- When an LRU queue must be flushed
The first circumstance under which the physical log buffer is flushed to disk is during any checkpoint. Once the checkpoint is complete, the physical log is cleared.
The second circumstance under which Informix flushes the physical log buffer to disk is when one of the two physical log buffers is full. In that case, Informix begins writing to the second buffer and flushes the first buffer to disk.
The final circumstance under which the physical log buffer is flushed to disk is when a page cleaner needs to flush an LRU queue. Recall that flushing an LRU queue involves writing to disk some or all of the modified pages managed by that queue. If there are before-images in the physical log buffer that have not yet been flushed to disk, the flushing of the LRU queue will wait until the before-images are flushed to disk. Since forcing the page cleaners to wait can significantly decrease your performance, you should take steps to ensure that this doesn't happen very often. See "I'm Confused by All the Logging!" later in this section for more information.
Logical log
Informix's logical log is similar to the transaction logs of other RDBMSs. The logical log is used to redo, or roll forward, transactions in case of recovery, or an explicit ROLLBACK WORK statement. It also stores the before-images of the records that each transaction will change, so it can be used to roll back any transactions that have not committed. It is called a logical log because it contains a log of how the database was changed logically. That is, it contains a record of which rows were changed and how, rather than which physical pages contained those rows.
If you needed to recover the database from an older backup, the logical log would be used to roll forward any transactions that have occurred since your last backup. It also is used when a database instance goes into fast recovery mode. During either operation, it eventually reaches the end of the log. Once it has done so, it looks to see if it has attempted to roll forward any transactions that have not been committed. If so, it then rolls those transactions back using the row-level before-image information that also is stored in the logical log.
Logical logs are actually tables within Informix. By default, there are six logical logs in the root dbspace. It also is quite common to create a separate dbspace that contains only logical logs. Similar to the physical log, the logical log is composed of three logical log buffers (in shared memory) and several logical logs (on disk). Transaction logs are always written to the logical log buffer first and then flushed to disk at different times. How often the log buffers are flushed to disk depends on the type of logging mode that is used. There are three logging modes:
- No logging
- Very little information is written to the logical log. Some of the things it does log include the creation of dbspaces, tables, and indexes. Normal transaction-redo information is not recorded. Nonlogging databases are useful only in databases that are modified using batch loads. Transactions cannot be redone in case of recovery from backup or an instance that crashes and goes into fast recovery mode.
- Buffered logging
- A database operating in buffered-logging mode flushes a logical log buffer to disk only when that logical log buffer is full. This results in efficient use of disk and memory, as well as higher performance. The trade-off is that if the instance crashes, all transactions that have not been flushed to disk are lost.
- Unbuffered logging
- When a database operates in unbuffered-logging mode, the logical log buffer is flushed to disk every time a transaction is committed. Remember that during buffered logging, Informix writes one large block of data to disk when the logical log buffer is full. In contrast, unbuffered logging writes small blocks of data more or less constantly. Since it always is more efficient to write larger blocks of data less often, an unbuffered database is always a little slower than a buffered database. Another downside to unbuffered logging is that flushing is done in page increments. A page that is partially filled by a transaction must be completely flushed to disk. Therefore, unbuffered logging also causes more information to be written to the logical logs.
- Despite its slight performance cost, unbuffered logging offers the greatest level of data integrity. All transactions are flushed to the logical log on disk as soon as they are committed. Therefore, whenever an instance crashes, Informix is able to redo all committed transactions. Only uncommitted transactions would be lost in a host crash. This is why almost all DBAs running a transaction-based database run their Informix databases in unbuffered-logging mode.
WARNING: Informix requires that the instance be in quiescent mode in order to change logging modes. It also requires you to perform a backup when moving from nonlogging mode to either of the logging modes, because the only reason for switching to logging mode is for better data integrity. What kind of data integrity do you have if you haven't made a backup? Informix support or documentation sometimes suggests that you simply perform a quick backup to /dev/null. I've never understood this practice; there is a reason that you're being forced to make a backup--logging is worthless without it. Sending the backup to /dev/null makes Informix think that you have made a backup, when you really haven't. Think twice before using this common procedure.
Since the logical logs reside on disk, they must be backed up. If they are not backed up, they will not be available for use during a recovery from backup. Informix provides two methods of backing up the logical logs: automatic and continuous. The "automatic" method is not automatic at all, and I've never understood why Informix calls it that. It consists of a command that does a one-time backup of the current logical logs to the storage media. Continuous backups, as their name implies, run continuously while the instance is online. When continuous backups are running, and a logical log fills up, it is backed up automatically to the storage device specified. Each logical log is appended to the storage device until it is full. The actual command to perform either automatic or continuous backups depends on whether you are using onbar or ontape. (Both commands are discussed later.) The storage media for logical log backups has historically been tape. This chapter also discusses backing up logical logs to disk.
Whether you choose to use automatic or continuous backups is entirely up to you. Many sites are now performing automatic backups using the
ALARMPROGRAMparameter in the onconfig file that runs a shell script for you when a log becomes full or is manually closed (ontape -l ). A sample shell script, log_ full.sh, which backs up the logical logs using onbar, is included with Informix. The shell script included with this book uses continuous backups.Checkpoint
A checkpoint flushes all pages in shared memory to disk. This means that physical log buffers are flushed to the physical log, and logical log buffers are flushed to the logical log. It provides a point in time during which all data is on disk. This is a point in time to which Informix can be rolled back, if necessary. Once the checkpoint has completed, all pages in the physical log can be removed.
TIP: During a checkpoint, the three different buffer areas are flushed in a particular order. The physical log is flushed first, followed by the logical log. Once the logs have been flushed, all pages that have been changed by committed transactions can be flushed.
Fast recovery
Fast recovery is a process through which the different elements of the architecture cooperate to bring the database into a consistent state after a crash. When an instance is brought online, it goes into fast recovery mode and in this state checks the physical log to see if it contains any before-images. The presence of any before-images in the physical log indicates that the system crashed, so any before-images that are in the physical log are written back to their original location. Informix then uses the logical log to redo any transactions that began after the last checkpoint. Eventually it will reach the end of the log. Once it does that, it rolls back any transactions that were not committed. (It works through the log in a serial fashion, so it begins a transaction as soon it sees a begin transaction statement. If it reaches the end of all transaction logs and does not see a corresponding end transaction statement, it rolls that transaction back. This is how the checkpoint, physical log, and logical log are used to bring the database to a consistent point in time after an instance crash.
I'm Confused by All the Logging!
Let's review. The LRU queues contain all disk pages that have been read into memory, including pages that were changed by a transaction. These queues are flushed periodically to disk by page cleaners at a rate determined by the number and size of the queues, as well as the values that you specify for
LRU_MIN_DIRTYandLRU_MAX_DIRTY. This flushing writes to disk some or all of the modified pages in a particular queue, changing the status of these dirty pages to "clean."The physical log contains the before-images of the physical pages that have been changed since the last checkpoint. This log really consists of two physical log buffers that are flushed to disk when one is full and cleared when a checkpoint occurs--and a checkpoint always occurs during a normal shutdown. These before-images are read only during fast recovery. If there are pages in the physical log when an Informix instance starts up, it means the instance did not shut down properly.
The logical log contains a record of which rows have been changed and how they were changed. The logical log actually consists of logical log buffers that are occasionally flushed to disk; how often they are flushed depends on your logging mode. If you are running in buffered-logging mode, a logical log buffer is flushed to disk only when it becomes full. If you are running in unbuffered-logging mode, the portion of the logical log buffer that pertains to a given transaction is flushed to disk as soon as that transaction is completed.
How bad (and good) things happen
Suppose for a moment that you were operating in buffered-logging mode. Now suppose that the current physical and logical log buffers are not full, the LRU queues are beginning to approach the value specified by
LRU_MAX_DIRTY, and Art has just committed a large transaction while Greg begins another large transaction. Informix sees that the LRU queues have too many dirty pages and begins flushing the LRU queues to disk to make room for Greg's transaction.We are operating in buffered-logging mode, which means that the logical log buffer will flush to disk only when it is full. This means that all roll-forward and rollback information pertaining to Art's and Greg's transactions are only in memory. However, the page cleaners need to flush the LRU queues that contain Art's transaction to disk. Before they are allowed to do so, however, the physical log will need to be flushed to disk. This ensures that the before-images are available to return the instance to a known point of physical consistency. One of two bad things could now happen.
The first thing that could happen is that the system crashes before the physical log buffer finishes flushing to disk, and all the information in both the physical and logical log buffers is lost. Since the physical log buffer was partially flushed to disk, Informix will realize that something went wrong when it restarts the instance and goes into fast recovery mode. It then rewrites the before-images back to their original locations, although the pages that it is overwriting have not actually been changed, since the LRU queues were never flushed because they were waiting for the physical log to continue flushing to disk.
The second thing that could happen is that the physical log buffer finishes flushing to disk, the LRU queues begin flushing to disk, and then the system crashes. The result is essentially the same. When Informix restarts the instance, it will see that there are pages in the physical log, which means it did not do a proper shutdown. It then rewrites the before-images to the original locations, overwriting any pages that were changed by the LRU queue being flushed.
Regardless of when the system crashes, the before-images of any pages to be changed will always be available. Once Informix has rewritten these images to their original locations, it can use the logical log to roll forward any committed transactions and roll back any uncommitted transactions.
Could this be better?
There are two problems with the preceding scenario described. The first problem is that the log of Art's transaction should have been flushed to disk as soon as the transaction was committed. Changing the instance to unbuffered logging fixes this problem. With the previous buffered logging example, Art's transaction would be lost. However, if it were flushed as soon as it was committed, the chances of the transaction being lost would be greatly reduced.
To be honest, I can't find a good reason to run an instance in buffered-logging mode anymore. Buffered logging used to provide a performance gain, but in Informix 7.x, the performance difference between unbuffered and buffered logging is minimal. (In fact, many DBAs tell me the gain was never that great.) This performance gain was the only reason for using unbuffered logging, and I believe the risk of database corruption is just too great.
Some have suggested that you could run a data warehouse in buffered-logging mode. Why would you? Buffered-logging mode is meant to make transactions that modify pages faster, and such a database should have very few transactions of this type. Therefore the performance increase would not even be noticeable.
The second problem was that there weren't enough buffers. The idea behind flushing least recently used transactions is to allow the logical log to flush to disk before transactions that are in that log are flushed to disk. If your buffers are numerous enough, the logical log containing a given transaction should flush to disk well before the LRU queues reach the value specified by
LRU_MAX_DIRTY, resulting in the queue that contains that transaction's pages being flushed to disk. Another potential problem could be that the value forLRU_MAX_DIRTYwas set too low. Informix DBAs set this value low to cause pages to be flushed more often, resulting in faster checkpoints, since the checkpoint does not have to flush very many dirty pages to disk. However, it increases the chance of data loss.In summary, Informix will do the right thing and ensure that your database will not get corrupted if the system crashes. However, operating in unbuffered-logging mode and having enough buffers significantly decreases the chance of data loss.
Automating Informix Startup:
The dbstart.informix.sh ScriptNot having a global configuration file makes a lot of things more difficult, one of them being backups. When writing a shell script to back up all Informix instances on a given machine, how do you know what instances to back up? You can't ask Informix, which definitely does not know about the other instances. I would like to suggest a different method of starting Informix that also would make backups easier. Let's start with the basics.
In order for an Informix database to be started up after a system reboot, a startup script must be placed somewhere in /etc. Startup scripts are run by root and, therefore, should be owned by root and placed in a directory that root controls. A startup script in /etc should not be calling a startup script in Informix's home directory. However, this creates an extra task for both the SAs and DBAs. The DBA must find an SA every time he wants to add a new instance to the startup script. The SAs would rather not have to do this, but they don't want root running shell scripts found in Informix's home directory. The SAs also are normally in charge of backups, and this is one way to find out that there is a new instance to back up.
How does Oracle accomplish this task? It's as simple as the oratab file. The start-up scripts are in a directory owned by root, and the oratab file is in a directory owned by the oracle ID. The startup script starts up any instances in the oratab file that have a
Yin the third field. All a DBA needs to do to have a new instance started is add the instance to the oratab file. This also gives backup scripts a great place to start. For example, the oraback.sh utility automatically backs up any instances that it finds in the oratab file.Sure, it's possible for a DBA to create and start up a new instance that does not get put into the oratab file. However, if the oratab file is being used to both start up and back up Oracle, DBAs will get into the habit of putting new instances there. Otherwise, they will continually have to start the instances manually, and the instances also will never get backed up.
With a little practice, Informix DBAs can be shown to do the same thing that Oracle DBAs do with the oratab file . . . I present the inftab file, an Informix version of Oracle's oratab file.
The inftab File
This inftab file in Example 14-1 has several comments but only one actual configuration line. This line tells the startup scripts that there is an Informix instance called crash, that its $INFORMIXDIR is /informix, and that it should be restarted after a reboot. Its logical logs should go to /informix/logical. (The logical backup destination variable will be used for the backup scripts that are covered later in this chapter.)
Example 14-1: A Sample inftab File # This file is used by the startup, shutdown, and backup scripts. # Provided in "Unix Backup & Recovery," O'Reilly & Assoc., Inc. # Author: W. Curtis Preston # Use a colon, ':', as the field terminator. # Lines that begin with an octothorpe, or pound sign (#), are comments. # Entries should follow this form: # $ONCONFIG:$INFORMIXDIR:<N|Y>: # The first field is the Informix server name. # The second field is the INFORMIXDIR variable that the Informix server uses. # A Y in the third field indicates if this instance should be started # automatically after a system reboot. # The fourth field is where logical logs will go. If you want to go # to disk, put a directory name. If you want to go to tape, put the # device file of the tape drive here. # Multiple lines with the same $ONCONFIG variable are not allowed. crash:/informix:Y:/informix/logicalThe dbstart.informix.sh script in Example 14-2 acts very much like Oracle's dbstart script (see Chapter 15, Oracle Backup & Recovery). It starts by reading the inftab file to determine the names of all instances. Then it either starts or stops each of the instances that have a Y specified in the third field. It also calls rclogs.sh for each of those instances. rclogs.sh, discussed later, automatically starts continuous backups in the background.
Example 14-2: The dbstart.informix.sh Script #!/bin/sh INFTAB=/informix/etc/inftab Usage() echo "Usage: [dbshut|dbstart] [start|stop]" echo "\n(Either this script must be called with the name of dbshut or dbstart," echo "or it must be called with a start or stop argument.)" echo "\nIf called by the name dbstart, or with the argment of 'start,'" echo "it will start all Informix instances listed in $INFTAB" echo "\nIf called by the name dbshut, or with the argument of 'stop,'" echo "it will STOP all Informix instances listed in $INFTAB." #This script starts up all instance on this box specified in $INFTAB. #It is of the form: #$ONCONFIG:$INFORMIXDIR:<Y|N> SCRIPT=`basename $0` if [ $SCRIPT != dbstart -a "$1" != start ] ; then if [ $SCRIPT != dbshut -a "$1" != stop ] ; then Usage exit fi fi WHO=`id | awk -F'(' '{print $2}' | awk -F')' '{print $1}' ` if [ "$WHO" = root ] ; then su informix -c $0 $* exit $? fi grep -v '^#' $INFTAB \ |while read LINE do STARTUP=`echo $LINE|cut -d: -f3` TBCONFIG=`echo $LINE|cut -d: -f1` ONCONFIG=`echo $LINE|cut -d: -f1` INFORMIXDIR=`echo $LINE|cut -d: -f2` #INFORMIXSERVER and ONCONFIG can be different, so get it from the onconfig file. INFORMIXSERVER=`grep DBSERVERNAME $INFORMIXDIR/etc/$ONCONFIG|awk '{print $2}'` BINDIR=$INFORMIXDIR/local/bin PATH=$INFORMIXDIR/bin:$BINDIR:$PATH export TBCONFIG ONCONFIG INFORMIXSERVER INFORMIXDIR PATH BINDIR if [ `basename $0` = dbstart -o "$1" = start ] ; then if [ "$STARTUP" = "Y" ] ; then else fi else echo "Stopping Informix Instance $ONCONFIG" [ -f $BINDIR/rclogs.sh ] && rclogs.sh stop onmode -ky fi doneAn inftab file provides a single point for all global Informix activities. The difficult part is getting in the habit of using one. However, if all startup, backup, and monitoring scripts base their actions on the inftab file, it will get used soon enough. The DBAs will be happy because they can change a single file that they own, and Informix will automatically start up, back up, and monitor a new instance. The SAs will be happy because they won't have to worry about changing a root-owned shell script every time a new instance is created.
Installing the dbstart.informix.sh Script
If you'd like to begin using dbstart.informix.sh to start up your Informix instances automatically, follow the upcoming steps to install and customize it for your environment.
Install the files
Copy the dbstart.informix.sh, dbstart, and dbstop programs into the same directory (e.g., $INFORMIXDIR/local/bin) and make sure that they are executable. If you have only dbstart.informix.sh, dbstart and dbstop are merely hard links to that file. You can make those links yourself by entering:
$ ln dbstart.informix.sh dbstart$ ln dbstart.informix.sh dbstopCopy inftab into a directory that the
informixuser ID can write to (e.g., $INFORMIXDIR/etc). (They can be placed in the same directory as the other files but do not need to be.)If you plan to use rclogs.sh with dbstart.informix.sh, you need to read about it later in this chapter and to configure it as well.
Edit the inftab file
If you have not already done so, edit the file $INFORMIXDIR/etc/inftab. This works basically like Oracle's oratab file. Each Informix instance should be listed in this file, in the following format:
onconfig_file:$INFORMIXDIR:Y|N:log_destinationonconfig_file
- The first field should be the relative name of the onconfig file for that instance (e.g., prod, not $INFORMIXDIR /etc/prod ).
- $INFORMIXDIR
- The second field should contain the value for the $INFORMIXDIR variable for that instance.
- Y|N
- If you also are using dbstart.informix.sh, placing a Y in the third field causes dbstart to automatically start this instance after a reboot. (Please note that the Y is case-sensitive.)
- Some DBAs prefer to start their Informix instances manually. If you wish to use dbstart.informix.sh but do not want the instances to start automatically, simply set this field to N.
- log_destination
- If you are using rclogs.sh, the fourth field should contain the value that you want to use for the archive log destination. This can be a directory or device name. (If it is a directory, make sure that it is writable by
informix.)Edit the dbstart.informix.sh script
The main thing that you need to do is to make sure that the location specified for the inftab file is correct. This is done by changing the $INFTAB variable at the top of the script. If you are not going to use rclogs.sh, you also want to delete the lines that refer to it.
Change the startup files
Check your system documentation for the proper location of startup and shutdown scripts and place dbstart.informix.sh there. On a SVr4-style Unix, you are looking for a file in one of the rc directories. For example, on Solaris, there is probably a file in /etc/init.d, with links to it in other directories. If the file is called informix, simply copy dbstart to informix. This will cause the links to it to run it with the appropriate stop and start arguments. On a BSD-style Unix, you are looking for a command somewhere in /etc/rc or /etc/rc.local.
Make a Fake oninit Command
There is one other change in the area of Informix startup that can help increase your data integrity. One of the most frequent causes of data corruption is an accidental oninit -i command. This causes Informix to completely reinitialize the instance, overwriting the rootdbs. (I don't know how many times I've seen this in comp.databases.informix.) Once begun, the only way out is a cold restore of the critical dbspaces.
The best way to protect yourself from this mistake is to replace oninit with a script that calls the real oninit. For example, move oninit to oninit.cmd. Then replace oninit with the following script:
#!/bin/shCMD=${0}.cmdif [ "$1" = "-i" ] ; thenecho "WARNING! oninit -i will completely erase this instance!"If that's what you REALLY want to do, then re-run this commandusing a capital '-I' instead. (e.g. $0 -I )."fi[ "$1" = "-I" ] && $CMD -i || $CMD $*Don't forget to make the script executable!
$ chmod 555 oninitProtect the Physical Log, Logical
Log, and sysmasterThese 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 dbspaceMoving 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 curtis$ onspaces -c -d plogdbs -p /informix/physlog.dbf -o 0 -s 10000 -m /informix/physlog_mirror.dbf 0 Verifying physical disk space, please wait ... Verifying physical disk space, please wait ... DBspace/BLOBspace successfully added.As shown in Example 14-4, we then must take the instance into quiescent mode, tell it to use the new dbspace for the physical log, and then bring it online again.
Example 14-4: Adding a New Physical Log curtis$ onmode -sy curtis$ onstat -l|grep Version INFORMIX-OnLine Version 7.23.UC4 -- Quiescent -- Up 00:15:40 -- 8976 Kbytes curtis$ onparams -p -s 5000 -d plogdbs -y Shutting down, please wait ... Initializing, please wait ... Recovering, please wait ... curtis$ onmode -m curtis$ onstat -l|grep Version INFORMIX-OnLine Version 7.23.UC4 -- On-Line -- Up 00:02:00 -- 8976 KbytesThe physical log is now in its own dbspace. You now can proceed to put the logical log in its own dbspace. Again, this is for performance reasons, not data integrity reasons.
Recommendation: Put the Logical
Log in Its Own dbspacePutting the logical log into its own dbspace is a bit more complicated. The first step, shown in Example 14-5, is obviously the same: we create a separate, mirrored dbspace that will eventually contain the logical logs.
Example 14-5: Creating a New dbspace curtis$ onspaces -c -d llogdbs -p /informix/logiclog.dbf -o 0 -s 10000 -m /informix/logiclog_mirror.dbf 0 Verifying physical disk space, please wait ... Verifying physical disk space, please wait ... DBspace/BLOBspace successfully added.Next, we perform a log switch and checkpoint, then use onstat -l to verify that all but the current log have been backed up (flag
B). (See Example 14-6 for examples of these commands.) Otherwise, we will not be able to drop the logs in the next step. If the output shows that the logs were not backed up, we would need to use ontape or onbar to get them backed up before continuing with this procedure. (See "Physical Backups Without a Storage Manager: ontape," later in this chapter, for more information about ontape.)
Example 14-6: Performing a Log Switch curtis$ onmode -l; onmode -c curtis$ onstat -l #(output abbreviated) address number flags uniqid begin size used %used a04b424 1 U-B---- 25 100233 250 5 2.00 a04b440 2 U-B---- 26 10032d 250 5 2.00 a04b45c 3 U-B---- 27 100427 250 5 2.00 a04b478 4 U-B---- 28 100521 250 5 2.00 a04b494 5 U---C-L 29 10061b 250 13 5.20 a04b4b0 6 U-B---- 24 100715 250 20 8.00The next step is to take the database to quiescent mode and drop all but three of the logs, as shown in Example 14-7. (Three is the minimum number of logs that Informix recommends.)
Example 14-7: Dropping All but Three of the Logical Logs curtis$ onmode -sy curtis$ onstat -l #(output abbreviated) address number flags uniqid begin size used %used a04b424 1 U-B---- 46 300611 250 3 1.20 a04b440 2 U-B---- 47 30070b 250 3 1.20 a04b45c 3 U-B---- 48 300805 250 3 1.20 a04b478 4 U---C-L 49 300035 250 3 1.20 a04b494 5 U-B---- 44 30012f 250 3 1.20 a04b4b0 6 U-B---- 45 300229 250 3 1.20 curtis$ onparams -d -l 6 WARNING: Dropping a logical log file. Do you really want to continue? (y/n)y Logical log 6 successfully dropped. curtis$ onparams -d -l 4 WARNING: Dropping a logical log file. Do you really want to continue? (y/n)y Logical log 4 successfully dropped. curtis$ onparams -d -l 5 WARNING: Dropping a logical log file. Do you really want to continue? (y/n)y Logical log 5 successfully dropped. curtis$ onstat -l #(output abbreviated) address number flags uniqid begin size used %used a04b424 1 U-B---- 34 100233 250 1 0.40 a04b440 2 U---C-L 35 10032d 250 4 1.60 a04b45c 3 F------ 0 100427 250 0 0.00The maximum number of logs must now be modified to be the original maximum plus 3. (That is because we are going to add the same number of logs to the new llogdbs dbspace while the original three logs still exist.) This change is made by running onmonitor and entering P (for Parameters) and S (for Shared-Memory). You then should get a screen that looks like the one in Example 14-8.
Example 14-8: The onmonitor Utility SHARED MEMORY: Make desired changes and press ESC to record changes. Press Interrupt to abort changes. Press F2 or CTRL-F for field-level help. Server Number [ 0] Server Name [crash ] Server Aliases [ ] Dbspace Temp [ ] Deadlock Timeout [ 60] Secs Number of Page Cleaners [ 1] Forced Residency [N] Stack Size (K) [ 32] Non Res. SegSize (K) [ 8000] Optical Cache Size (K) [ 0] Heterogeneous Commit [N] Transaction Timeout [ 300] Physical Log Buffer Size [ 32] K Long TX HWM [ 50] Logical Log Buffer Size [ 32] K Long TX HWM Exclusive [ 60] Max # of Logical Logs [ 6] Index Page Fill Factor [ 90] Max # of Locks [ 2000] Add SegSize (K) [ 8192] Max # of Buffers [ 200] Total Memory (K) [ 0] Resident Shared Memory size [ 880] Kbytes Page Size [ 2] Kbytes Enter the maximum # of logical logs that INFORMIX-OnLine can useBy looking at the Max # of Logical Logs field in Example 14-8, we can see that the current maximum number of logical logs for this instance is set to 6. Since we are going to add six logs to the new dbspace, we would need to change this maximum to 9. To make the change, use your arrow keys to move the cursor to the appropriate field and change its value. Once you make the change, enter Esc, Y (Yes to save changes), Y (Yes to shutdown), then Enter. Once that is done, the instance should be offline. You then need to return it to a quiescent state with oninit -s, and add the logical logs to the new dbspace, as shown in Example 14-9.
Example 14-9: Adding the New Logical Logs curtis$ oninit -s curtis$ for I in 1 2 3 4 5 6 ; do > onparams -a -d llogdbs > done Logical log successfully added. Logical log successfully added. Logical log successfully added. Logical log successfully added. Logical log successfully added. Logical log successfully added.You now must perform a level-0 archive to make these logs available for use. (An example level-0 archive is shown in Example 14-10.)
Example 14-10: A Level-0 Archive curtis$ ontape -s Please enter the level of archive to be performed (0, 1, or 2) 0 Please mount tape 1 on /informix/logical/crash/crash.level.0 and press Return to continue ... 100 percent done. Please label this tape as number 1 in the arc tape sequence. This tape contains the following logical logs: 35 Program over.As shown in Example 14-11, we now switch logs three times, which will cause the current log to be one of the new logs on the separate dbspace. Then we will force a checkpoint and perform a logical log backup. This will free the logs that are on the old dbspace, so that we may drop them.
Example 14-11: Performing a Log Switch and Starting Continuous Backups curtis$ onmode -l ; onmode -l ; onmode -l curtis$ onmode -c curtis$ ontape -c Performing continuous backup of logical logs. Please mount tape 1 on /informix/logical/crash.log and press Return to continue ...In another window, we run an onstat -l that shows us that the logical log backup is done. We now can stop the ontape -c with a Ctrl-C. We also can drop the original three logical logs. See Example 14-12 for an example of these steps.
Example 14-12: Example onstat Output and onparams Command curtis$ onstat -l #(output abbreviated) address number flags uniqid begin size used %used a04b424 1 U-B---- 34 100233 250 1 0.40 a04b440 2 U-B---- 35 10032d 250 15 6.00 a04b45c 3 U-B---- 36 100427 250 0 0.00 a04b478 4 U---C-L 0 300035 250 0 0.00 a04b494 5 F------ 0 30012f 250 0 0.00 a04b4b0 6 F------ 0 300229 250 0 0.00 a04b4cc 7 F------ 0 300323 250 0 0.00 a04b4e8 8 F------ 0 30041d 250 0 0.00 a04b504 9 F------ 0 300517 250 0 0.00 curtis$ onparams -d -l 1 WARNING: Dropping a logical log file. Do you really want to continue? (y/n)y Logical log 1 successfully dropped. curtis$ onparams -d -l 2 WARNING: Dropping a logical log file. Do you really want to continue? (y/n)y Logical log 2 successfully dropped. curtis$ onparams -d -l 3 WARNING: Dropping a logical log file. Do you really want to continue? (y/n)y Logical log 3 successfully dropped. curtis$ onstat -l #(output abbreviated) address number flags uniqid begin size used %used a04b478 4 U---C-L 37 300035 250 7 2.80 a04b494 5 F------ 0 30012f 250 0 0.00 a04b4b0 6 F------ 0 300229 250 0 0.00 a04b4cc 7 F------ 0 300323 250 0 0.00 a04b4e8 8 F------ 0 30041d 250 0 0.00 a04b504 9 F------ 0 300517 250 0 0.00At this point, we have successfully moved all logical logs into the new dbspace. The following steps are purely a matter of personal preference. I like my logs to be numbered starting with one. In order to do that, I have to add three more and drop the last three, as demonstrated in Example 14-13. The new logs will be given log numbers 1-3. Then we drop logs 7-9 in reverse order. (It's less confusing to delete them in reverse order.)
Example 14-13: Dropping and Adding Logical Logs curtis$ onparams -a -d llogdbs Logical log successfully added. curtis$ onparams -a -d llogdbs Logical log successfully added. curtis$ onparams -a -d llogdbs Logical log successfully added. curtis$ onparams -d -l 9 WARNING: Dropping a logical log file. Do you really want to continue? (y/n)y Logical log 9 successfully dropped. curtis$ onparams -d -l 8 WARNING: Dropping a logical log file. Do you really want to continue? (y/n)y Logical log 8 successfully dropped. curtis$ onparams -d -l 7 WARNING: Dropping a logical log file. Do you really want to continue? (y/n)y Logical log 7 successfully dropped. curtis$ onstat -l #(output abbreviated) address number flags uniqid begin size used %used a04b424 1 A------ 0 300611 250 0 0.00 a04b440 2 A------ 0 30070b 250 0 0.00 a04b45c 3 A------ 0 300805 250 0 0.00 a04b478 4 U---C-L 37 300035 250 16 6.40 a04b494 5 F------ 0 30012f 250 0 0.00 a04b4b0 6 F------ 0 300229 250 0 0.00Recommendation: Mirror Essential dbspaces
If you have the space, it is best to mirror the entire database. However, many places do not have that luxury. It doesn't take up much disk space to mirror the essential dbspaces, though. The essential dbspaces are those that contain the sysmaster database and the physical and logical logs. Of these, the most essential dbspace would be the one that contains the logical logs. That is because all other dbspaces can be recovered up to the point of failure--if the logical logs are intact.
When creating dbspaces, they can be set up as mirrored dbspaces. (This is demonstrated in the previous example about moving your logs to dedicated dbspaces.) However, it also can be done after the dbspace is created. Since we've already covered creating a mirrored dbspace, this section covers turning on mirroring for an existing dbspace. Assume for this example that we have a dbspace called plogdbs, and that we wish to mirror it to /informix /physlog_mirror.dbf. We would run the commands shown in Example 14-14.
Example 14-14: Adding Mirroring to an Existing dbspace $ onspaces -m plogdbs -f /informix/physlog_mirror.dbf -y $ onstat -d # (output abbreviated) a12a728 3 2 3 1 M informix plogdbs (The M flag above says that the plogdbs is mirrored.) address chk/dbs offset size free bpages flags pathname (It lists two chunks below. One is primary and the other secondary.) a12a358 2 2 0 5000 2447 PO- /informix/physlog.dbf a12a508 2 2 0 5000 0 MO- /informix/physlog_mirror.dbfRecommendation: Leave Room for the Logs
Remember that the logical logs are absolutely essential for maintaining the integrity of your database. A common problem with many installations is that the logs become full. This is caused by either not backing up the logs or a long transaction that keeps too many logs open.
Back up your logical logs
Informix instances must have their logical logs backed up. If you do not back them up, all logical logs eventually become full. Once this happens, all activity on the instance stops, and you are forced to do a logical log backup. The problem is that backing up the logical logs requires creating more logical log entries. If all logs are full, you can't back up the logs.
The only option that remains is a special tool that can be run only by Informix support. They have to be able to dial or telnet into your system. They then transfer the file to your system, run it, and remove it. They do not allow you to keep the tool, and there is no way for you to get it without Informix accessing your system. In short, this is not a situation you want to be in.
Informix recently introduced a new parameter that prevents logical log entries from becoming full. Unfortunately, it is turned off by default.[2] The
LBU_PRESERVEparameter (found in the onconfig file) needs to be set to 1 to reserve the last logical log for administrative activity, such as logical log backups.Long transactions
Another "log full" problem is caused by a long transaction. A long transaction occurs when a user or application starts a transaction and does not commit it within a reasonable time. The problem with this is that a log cannot be freed if it contains an uncommitted transaction. Suppose there are 10 logical logs, and a long transaction is started in the first log. Once the first log is full, Informix moves on to the next log, but it cannot free the first log for reuse until the long transaction is completed and that log file has been backed up. If the transaction were allowed to remain open until the 10th log was full, there would be no more free logs. One transaction has managed to span the entire set of logical logs. This is why it is called a long transaction. One might think that the transaction could be rolled back. However, rolling back a transaction requires creating more logical log entries. No more logical log entries can be created because there are no more free logical logs. Does that sound familiar?
The long-transaction problem is why they introduced the high-water-mark parameters that are found in the onconfig file. The first is the long-transaction high-water mark (
LTXHWM), and its default value is 50. Once the percentage of full logical logs reaches this value, the transaction is automatically aborted and rolled back. However, since other transactions are allowed to continue, the logical logs are still in danger of filling up. The second parameter, the long-transaction exclusive-access high-water mark (LTXEHWM), is designed to protect the instance from this; its default value is 60. If the percentage of full logs reaches this value, most database activity is suspended and the transaction is given "exclusive access" to the remaining logical logs so that it can complete its rollback. The values of 50 and 60 are the new default values for these parameters, and oninit complains if you attempt to initialize an instance with values higher than these.In summary, leave the
LTXHWMandLTXEHWMvalues where they are and turn onLBU_PRESERVEby changing its value to 1 in the onconfig file. For more details about these values, consult the IDS Administration Guide.Which Backup Utility Should I Use?
Before examining how to perform Informix backups, we need to understand the various backup options that are available to an Informix DBA. There are three backup utilities available with Informix: onbar, onarchive, and ontape.
A Quick History of onarchive, onbar, and ontape
Around 1993 and 1994, very large Informix databases started to appear. (Back then, "large" meant anything greater than 100 GB.) The only utility that Informix customers had was ontape. ontape's one big flaw is that it is single-threaded. How do you back up 100 GB to a single device, especially when the devices available could back up only at rates ranging from 500 KB/s to 3 MB/s? Informix customers started screaming for a multithreaded backup system. (I was one of them.)
Informix, in an attempt to meet these demands, purchased the rights to a third-party program that became known as onarchive. Its syntax was arcane, complex, and completely unlike any other command on Unix. (It wasn't as complex as sendmail, but it was close!) The forward-slash method of passing options to a command seemed bizarre to most Unix system administrators, and it came with a manual that is almost the size of this book.
I was there
By the time in my career that I met onarchive, I had learned dozens of products just by browsing the manuals. I read the onarchive manual cover to cover four times and attended the Informix onarchive class. I was still confused. The most disconcerting part of the class was how the instructor kept talking about this thing called onbar that would soon replace onarchive.
I remember having 15 open bug reports for onarchive at one time. I remember calling support and getting the feeling that they didn't want to support the product any more than I wanted to use it. I remember spending months configuring and testing our onarchive setup. Informix came and saw what we did and thought it was one of the most impressive onarchive installations they had ever seen.
Then we tested the restore. It didn't work. No matter what we did, we couldn't restore the instance that we had backed up with onarchive. It just wouldn't work. Suddenly we received approval to buy a much faster tape drive and go back to ontape.
As a result of the input that they received from the field, Informix began work on a replacement for onarchive almost immediately. onbar was released with Version 7.21. Unfortunately, this created a problem. Users who need the multithreaded capabilities of onbar were required to purchase an interface to their storage manager--at a cost of more than $5000 per system. To avoid that cost, people who needed a multithreaded backup product were still being driven toward onarchive ; this product, despite its incredible complexity and horrible reputation, remained the only choice available for some customers.
Informix wanted to fix this problem, so they negotiated an arrangement with Legato Systems that allowed them to bundle a scaled-down version of Legato NetWorker with IDS 7.3. This product is known as Informix Storage Manager, or ISM. It allows you to send up to four data streams simultaneously to four storage devices (i.e., one data stream per drive). This is enough parallelism to back up a relatively large instance. Assuming that each data stream can "stream" each of four DLT 7000s, that is a total potential throughput of 40 MB/s, 144 GB/hr, or 1.1 TB in an eight-hour period. (Unfortunately, on many systems, you'll need more than one thread to stream a device; this reduces the overall effective throughput of an ISM/onbar combination, but it is still going to be faster than ontape.)
Don't use onarchive
If you downloaded both the Archive and Backup Guide and the Backup and Restore Guide from >http://www.informix.com/answers, you might get the impression that there are three viable options for backing up Informix databases: ontape, onbar, and onarchive. The manuals do explain that onbar is designed to work with storage managers, and ontape and onarchive are not. What the documentation does not explain is why two products (ontape and onarchive) that appear to perform the same function exist. Further, you might get the impression after reading the manual that onarchive is the way to go. It's not.
The release of ISM means that there remains no valid reason for configuring a new backup system using onarchive. If you can live without multithreaded backup and recovery, use ontape and infback.sh (or something similar). If you need multi-threaded capability or want some other advanced feature, use onbar and ISM. If you can afford an Informix server that needs more than four backup threads, you can afford a full-featured storage manager and its interface to onbar. If you're having trouble convincing your management to spend that money, show them this chapter.
Informix plans to phase out onarchive over time. You can already see references that say things like "onbar is the preferred solution for 7.3," and "ontape and onarchive are supported for now." The only reason that they don't drop onarchive today is there are still people using it. I wouldn't be surprised if a future release of Informix configures onarchive in such a way that you would no longer be able to make backups with it. The restore functionality will be left for those who still have onarchive backup tapes. (I doubt that Informix will drop ontape, though, because it's so easy to use and support. They aren't adding any new features to it, but that could be considered a feature in itself.)
Some people reading this section may disagree with my assessment of onarchive 's value. They like the flexibility that such a complex product offers them. They don't care that they need to read almost 500 pages of documentation just to figure out how to back up their Informix database. They've figured it out now--and they don't want to have to figure out another product. If that is how you feel, please know that you are in the minority. The whole reason that onbar exists is that the Informix user community was in an uproar about onarchive. Remember also that a product that is difficult to use is difficult to support. Informix is probably doing everything it can to put this utility behind them. If you're using onarchive today, you should seriously consider looking at onbar as soon as possible or going back to ontape if you can. Trust me: onbar is as easy as it gets.
Pick a Utility, but Not Any Utility
Here is a quick summary of the three utilities available for Informix backups:
- onbar
- onbar is the latest in Informix backup technology and is used only for interfacing with storage managers like the Informix Storage Manager (ISM). (onbar is covered in "Physical Backups with a Storage Manager: onbar.") If you are running Informix 7.3 or greater, onbar offers enhanced functionality and flexibility.
- onarchive
- onarchive was Informix's first attempt at an enhanced product, but its incredible complexity caused it to be just a stopgap measure until onbar was available. onarchive will not be supported in the future and therefore should not be used as the basis for any new backup system. (See "Don't use onarchive," earlier in this chapter, for more information.)
- ontape
- ontape is Informix's oldest backup utility, but it's still going strong. It does not interface with storage managers, therefore it is the easiest and best way to perform physical backups without a storage manager.
In summary, if you do not have a storage manager, you really should be using ontape if you can. If your database is really large, and you need the multithreaded capabilities of onbar, you should either purchase a third-party storage manager or upgrade to a recent version of Informix that includes a free (albeit scaled-down) storage manager. Once you have done that, you can use the advanced functionality of onbar. I would not advise designing any new backup systems around onarchive. It is too difficult to learn, and it is being phased out.
Physical Backups Without a Storage Manager: ontape
If you do not have access to a storage manager, ontape might be the perfect tool for you. This section covers ontape 's basic usage, then shows you how to automate it using shell scripts. Many environments without storage managers use ontape to automate their backups.
Despite its age, many people continue to use ontape for several reasons:
- Informix version
- ontape does not require a storage manager. If you are not running Informix 7.3 or greater, you do not have ISM. That means that you will need to purchase a storage manager and its interface to onbar. If you are running a version older than Informix 7.21, you don't even have access to onbar.
- Cost
- ontape is free. Although onbar itself is free, it will cost as much as $7000 per host [3] to purchase the interface to onbar, even if you already have one of the commercial storage management applications (e.g., those discussed in Chapter 5, Commercial Backup Utilities).
- Ease of use
- ontape is a breeze to learn. It has four required options, -s for archive,[4] -c for continuous backups, -a for automatic backups, and -r for restore. That's it. In contrast, onarchive is a nightmare of complexity. Its manual spans 436 pages, compared to ontape 's 49 pages or onbar 's 125 pages. onbar is much simpler to use than onarchive, but adding a storage manager into the picture still makes it more complicated than ontape. (The slight increase in complexity does come with greatly increased functionality, though.)
ontape is easy to use. Even more importantly, ontape recoveries work! ontape was developed many years ago, before the advent of backup automation in the Unix world. It was ahead of its time with multilevel backups, but it does have one design flaw: it was designed to be run by an operator on a console. It prompts the operator for information even during normal operations. It was not designed for automated backups, but that doesn't mean you can't use it that way. Many scripts have been written that answer its prompts, providing a level of functionality never envisioned by the original programmers. Before looking at how to automate the use of ontape, though, we cover its basic usage.
Configuring ontape
Prior to running ontape, you must configure some parameters using the onmonitor utility. This utility changes these parameters in the file $INFORMIXDIR/etc/$ONCONFIG, where $INFORMIXDIR is a required environment variable specifying the Informix directory, and $ONCONFIG is a required environment variable specifying the name of the Informix configuration file. It is an editable text file, but not all changes will go into effect until you restart the instance if you edit it manually. Specifically, the
The values in Figure 14-1 should be changed to ones appropriate for your environment. The appropriate values are also listed in Table 14-1.LTAPEparameters must be changed using onmonitor if you want them to go into effect immediately. To configure ontape, run the onmonitor utility, choosing menu option A (for Archive) and T (for Tape Parameters). (An ontape backup of an instance is referred to as an archive.) This takes you into a screen that looks like Figure 14-1.
Table 14-1: Tape Configuration Values Variable in the $ONCONFIG file
Value in onmonitor Screen
Purpose
TAPEDEV
Tape Device
Device to which archives (backups) are sent
TAPEBLK
Block Size
Block size of tape device in kilobytes
TAPESIZE
Tape Size
Size of tape in kilobytes
LTAPEDEV
Log Tape Device
Device to which logical log backups are sent
LTAPEBLK
Block Size
Block size of log device in kilobytes
LTAPESIZE
Tape Size
Specifies the tape device for logical log backups.
These values usually are set once and should be changed only if your configuration changes. One of the best ways to do this is to make the device name to which you are backing up a symbolic link to the real device. For example, you can specify that the tape device is /informix/tapedev and make that a symbolic link to /dev/rmt/0cn. That would allow you to change the actual tape device without accessing onmonitor. Although optimum block size settings are determined by your tape drive manufacturer, a value of 64 or 128 is quite common. You should experiment with different values to see how they affect backup performance.[5]
I like to set the
TAPESIZEparameter to something slightly larger than the instance size but less than the actual tape size. For example, suppose you have a 16-GB tape but a 4-GB instance. One option would be to set the tape size to 15 GB and not worry about changing it again for a long time. You also could set it at 5 GB, and then watch the logs to make sure that backups complete. Once backups start failing because the tape is filling up, change theTAPESIZEparameter to 8 GB. This method lets you to see how big the instance is growing over time, allowing you to document when the instance is going to exceed the size of your 16-GB tape drive so you can purchase a bigger tape drive long before it ever becomes a problem. Setting theTAPESIZEto 15 GB would result in successful archives for a long time, followed by a failure once the database got bigger than 15 GB. Unfortunately, though, you would have no idea when it is going to reach 16 GB and have very little time to purchase a bigger tape drive.Some DBAs prefer to set the
TAPESIZEparameter to the size of the tape and then chart the growth of the instance with sysdbspaces. You should do whatever works best for you!TIP: It should be noted that Informix backups can span tapes. It will prompt the operator for a second tape if the first one fills up. However, if you are automating your backups with shell scripts, the prompt probably will not get answered, and the backup will fail.
Tape or Disk?
Informix assumes that the devices that you specify for
TAPEDEVandLTAPEDEVare tape drives, as evidenced by the variable names. It is common, however, to use files on disk instead. To back up to disk, Informix needs an empty disk file to which it can write. This usually is done with the touch command. For example, the previous example window shows the Log Tape Device set to /informix/logical/crash.log. This is a disk file created by issuing the following command:$ touch /informix/logical/crash.logWhat's wrong with tape?
One of the most difficult things about ontape 's continuous backups is that they are designed to back up the logical logs to a single tape. Once the tape fills up, the logical log backups stop, and the logical logs begin to fill up. If all logical logs fill up during this time, all activity on the instance is suspended. This means that the DBA must constantly watch several tape drives, swapping tapes throughout the day. Nor can he tell how full a tape is getting. (A DBA could write a separate script to monitor how many logs have been written to a device and use that to estimate how full the tape is getting. However, different compression ratios may cause this estimate to be way off.) It doesn't help that Informix requires a separate tape device for each instance. What does a DBA do with a machine that has several Informix instances on it?
WARNING: If you are archiving to tape, make sure that your scripts rewind the tape before starting an archive. Failure to do so may result in unexpected results!
Backing up to disk can help
The alternative is to back up the logical logs to disk. All of the logical log backups on a single host can share a single /logical filesystem. For each Informix instance, you'll need a script that:
- Stops continuous backups for a moment
- Moves the current logical log backup file to a date/timestamped file
- Creates another logical log backup file
- Starts continuous backups again
Once this has been done, the only management required is monitoring the available space in the filesystems where you're sending your logical logs and deleting old logical log files that have been backed up.
Is it OK to back up to disk?
Some DBAs feel that the logical logs are extremely important and that backing them up to disk places them at risk. Disks can fail. If the disk drive that contains your logical logs fails at the same time as the disk drive that contains your database, you are out of luck. They feel it is safer to get the backups out to tape.
There are strong arguments for backing up to disk. Proponents say the value added by backing up to disk far outweighs the added risk. They also say that backing up to tape has risks as well. Their reasoning is as follows:
- Backing up to disk allows complete automation. No one has to remember to swap tapes, no one needs to be available to swap tapes, continuous backups just happen. It's always a good thing to automate backups. Why have operators swapping tapes when a simple shell script will do the job--day in and day out?
- The slowest part of an Informix database restore is the reading of the logical logs. Placing the logical logs on disk significantly increases the speed of this critical path of a restore.
- The all-your-eggs-in-one-basket problem is solved by using remote devices. For example, elvis logical logs can back up to a filesystem on apollo--all you need to do is specify apollo:/logical/servername/logfile as the logical tape device. This significantly reduces the chance that both the logical tape device and the database instance will be damaged at the same time.
- The proponents of logical log backups to tape also would contend that backing up to disk would not protect the data from a fire that destroys both systems. Don't forget that a fire also would destroy any tapes that are in the drives.
- Tape is safer than disk, right? The quicker the logical logs get to tape, the safer they are. Performing logical log backups to disk actually makes this easier. Why is that? If the logical logs are being backed up to disk, logging can be stopped and started throughout the day, creating multiple log files. These log files can be immediately backed up using a homegrown or commercial backup system. They can even be backed up or copied multiple times. This is something that is impossible with tape backups. As long as the tape device is open by Informix, it can't be accessed. Talk about putting all your eggs in one basket! Instead, you could easily have multiple copies of the disk backup, as well as tape copies that can be sent off-site without disturbing Informix.
Doesn't Informix try to rewind the tape?
A common misconception is that Informix rewinds the tape before and/or after a backup or restore. This is what is commonly used as an argument against disk backups. It also is commonly used to explain why you are not supposed to put more than one archive on a tape device.
Informix does not rewind the tape at any time. It expects the tape to be rewound already. This allows you to back up to disk or to put multiple archives on a single tape by using the no-rewind device. Recent changes to the Informix FAQ and discussions in the comp.databases.informix newsgroup have confirmed this.
If you do back up to disk, all "tape" management is up to you. ontape will not know that the backup really went to disk. It is up to you to track that information and to manipulate disk devices during a restore so that the "tape" is always where ontape expects it to be.
WARNING: However, if you do put multiple archives or log backups on a tape by using the no-rewind device, a restore from those backups will not work. This is because Informix opens and closes the tape several times during a restore, expecting it to rewind. If you have multiple backups on a tape, you must copy each backup to a separate tape in order to do a restore.
The two-gigabyte file size limit
There is one downside to backing up to disk. Informix still has a 2-GB file-size limit, so you will not be able to create a disk archive of a database that results in a file larger than 2 GB. There are two options that you can explore to get around the 2-GB file-size limitation:
- Use expect (or the expect module of perl ) to respond to the prompts from ontape.
- Don't use ontape ; use onbar.
Use expect to swap tapes
The first option is to use expect or perl to respond to the multiple prompts from ontape. You then could set the
TAPESIZEparameter to something just short of 2 GB. Once ontape reaches this size, it will prompt you for a second tape. You then could use expect to move the first file from its original location, create another file, and respond to ontape 's prompt for a second tape. This method will allow you to make an archive as large as the available space on the filesystem.Use a storage manager and onbar
The second option, and one you should seriously consider, is to use Informix Storage Manager (or some other storage manager) and onbar. This combination would work around the 2-GB limit, still allow you to back up to disk if you wish, while providing you with the features that are available only in onbar.
I'll Use Disk for Continuous Backups . . .
Backing Up the Instance
The Informix term for a backup of an instance is an archive. First, you must configure
TAPEDEVas explained in "Configuring ontape," earlier in this chapter. Then to perform an archive, run one of the following commands:$ ontape -s # on a 5.x instance$ ontape -s <-Llevel> # on a 6.x and higher instanceYou may specify a 0, 1, or 2 for level. Specifying a 0 performs a full archive. Specifying a 1 causes Informix to back up anything that has changed since the last level 0. Specifying a 2 causes Informix to back up anything that has changed since the last level 1 or 0. If you do not specify the level using the -L option, ontape prompts for it. ontape also prompts you to hit Enter once you have mounted the tape.
If ontape detects that it has reached the end of a volume, it prompts for another tape. ontape supports three levels and multivolume archives but cannot use more than one device at a time; you must use the same device throughout the archive. Once the volume on that device is full, you must swap that volume and answer ontape 's prompts for the next tape. If you are backing up to disk, this means that you have to move the original backup file to another location.
Backing Up the Logical Logs
Recovering an Informix instance from an archive recovers the database to the point in time that the archive was taken. In order to redo any transactions that have occurred since then, you also must restore the logical logs. In order for the logs to be available during a restore, you must back them up. You can:
- Back up the logs continuously
- ontape offers a particular type of logical log backup, referred to as "continuous backups," by using the -c option of ontape. ontape runs continuously in the foreground, appending logical logs to the storage media as it becomes full.
- Back up the logs manually
- A "manual backup" is a one-time backup performed by the -a option of ontape. It overwrites the storage media with all full logical logs and the current logical log.
- Back up the logs with a script and the ALARMPROGRAM parameter
- As of 7.xx, there is a new way to back up your logs. You can use the
ALARMPROGRAMparameter to automatically run a shell script for you when a log is full or is manually closed.- Elect not to back up the logs
- You could decide not to back up the logical logs. This is done by setting the backup device to /dev/null.
Backing up logical logs continuously
The historically preferred way to back up your logical logs is to use the continuous backup option of ontape. When continuous backups are running, logical logs are automatically backed up to the specified device as soon as they are full. The logs are appended to the backup device, which is held open by Informix as long as continuous backups are running.
To perform a continuous backup of the logical logs, run the following command:
$ ontape -cThis command prompts you to hit Enter once you have mounted the tape; from then on, it performs a continuous backup of the logical logs to the storage media until you enter Ctrl-C or kill the process. It continues to append logical log backups to a particular piece of media until the media is full. A tape is "full" when ontape can longer write to it, or the amount of data that has been written to it exceeds the value specifid by the
TAPESIZEparameter in the onconfig file.Backing up logical logs manually
Another method of backing up logical logs is to perform a manual backup only when required. This method differs from continuous backups in two ways. First, it is a onetime backup that backs up full logs, along with the current logical log. It opens the device once, writes these logs to it, and closes the device. Second, and perhaps more important, a manual backup overwrites any backups found on the storage media. To perform a manual backup of the logical logs, run the following command:
$ ontape -aThere are some environments that have written automation scripts around this command. They monitor the logs to see how many are full. Once a certain percentage of them are full, they run the ontape -a command to back up the logs. A script that operates in this way is simulating the continuous backup operation of ontape -c. It requires more tape or disk space than the continuous backup method, because it backs up the current log whether it is full or not, whereas continuous backups back up logs only when they are full.
There is nothing wrong with simulating continuous backups using scripts and ontape -a, and it is slightly easier to automate than ontape -c. This is exactly what the
ALARMPROGRAMis for. You specify the script that Informix should run whenever a log is full.Electing no backup of logical logs
The least preferred method of backing up the logical logs is to not back them up at all. You do this by setting the
LTAPEDEVvalue to /dev/null, which causes Informix to mark the logs as backed up as soon as they become full. (See the earlier explanation under "Configuring ontape" for details on how to do this.) Since no actual backup occurs, this is not an option to use if you will need point-in-time recovery. Using this option allows you to recover only from your latest archive. You will not be able to redo any transactions since the time of that archive. This option typically is used only for development instances or instances in which data is loaded only via batch loads. If you are considering using this option for a batch-load instance, you should experiment with this option and with the continuous backup option. Find out the impact of both on your environment, including performance during loads and recovery speed.TIP: To Oracle DBAs: This is the Informix equivalent to running an Oracle database in NOARCHIVELOG mode.
Automating Archives with ontape:
the infback.sh Utilityinfback.sh is a shell script that automates performing archives with ontape. Before examining how infback.sh works, we explain why automating ontape backups is difficult.
Why automating ontape is difficult
The ontape utility is simple and flexible, but automating it has always been somewhat difficult, because it is a little picky about how it receives the answers to its questions. For example, some versions of ontape do not accept a typical "here document,"[6] as shown in Example 14-15.
Example 14-15: Calling ontape with a Here Document LEVEL=0 ontape -s <<EOF >/tmp/logfile $LEVEL EOFontape now accepts the use of a -L level argument, but it still requires you to respond to a prompt after executing the command. ontape can still give you difficulties if you use the syntax in Example 14-15.
The method shown in Example 14-15 is often mentioned in FAQs and other books, but it does not work on every version of Informix. The method that does always seem to work is shown in Example 14-16.
Example 14-16: A More Reliable Way to Call ontape LEVEL=0 echo "$LEVEL "| ontape -s | head -100 > /tmp/logfileThere are two differences between the methods shown in Example 14-15 and Example 14-16. The first difference is the way in which the answers are passed to ontape ; the second method seems to be a little more robust. The second difference between the two methods is the addition of the head command in the second one. The head command is not required but is a good precaution in case the backup device becomes full. Here's why: once ontape detects that the backup device is full, it prompts for a second tape. It is not very easy to provide a second tape and answer this prompt without using a program such as expect.[7] (There is a way to answer prompts like this by redirecting
stdinandstdoutto named pipes, but that can be really tricky with ontape. ontape prompts repeatedly for the second tape and things get pretty ugly very quickly.) The head command keeps this repeated prompting from happening, since it truncates the output to 100 lines, but once the 100 lines have been reached, ontape aborts.How infback.sh works
infback.sh is a shell script that automates performing archives with ontape. (As discussed earlier, its one limitation is that it cannot handle multivolume archives.)
infback.sh consists of several files:
- infback.sh
- This is the main backup program that looks at the configuration files to decide how and what to back up.
- rclogs.sh
- This program is another main program that automates continuous backups of the logical logs using ontape -c.
- infback.conf
- This file is used by infback.sh to specify how, when, and what to back up.
- inftab
- This file lists all Informix instances on a machine. It is used by dbstart.informix.sh, rclogs.sh, and infback.sh to determine what instances are on the machine.
- localpath.sh, rempath.sh, config.guess
- These files accompany these other programs and assist them in determining what commands to run on various Unix platforms.
infback.sh is based on the same logic as Oracle's oraback.sh and Sybase's syback.sh. infback.sh:
- Uses a global tabulation file (inftab) to list all Informix instances
- Uses a global configuration file (infback.conf5 ) to configure backups
- Automatically performs full or incremental backups of all instances found in inftab
- Optionally performs full or incremental backups of any instances listed on the command line
- Can write archives to disk or tape
- Sends email, notifying of the success or failure of the backup
- Backs up databases that reside on raw partitions or filesystems
infback.sh can be called in one of three ways:
- With no arguments
- If you call infback.sh with no arguments, it decides what to back up and what device to use by looking at infback.conf.
- With arguments specifying backup parameters
- You can tell infback.sh which device and level to use by giving them as arguments. If you do this without giving it a list of instances to back up, it will back up any instances it finds in inftab. If you specify instances to back up, it will back up only the instances that you specify.
- With at as the first argument, with or without backup parameter arguments
- Specifying at as the first argument causes infback.sh to look at infback.conf to determine what time to back up. It then schedules an at job using the same arguments given after the at argument. (That means that the scheduled backup will figure out what and how to back up via either infback.conf or the arguments that were given.)
When infback.sh runs
One of the first things that infback.sh does is to check if the word "skip" is in field 2 of infback.conf. If so, it skips the backup once and removes the word "skip" from infback.conf. (This allows a DBA to manually skip tonight's backup, but does not allow the DBA to accidentally disable backups forever.)
If infback.sh determines that it is not supposed to skip the backup, it then needs to determine what instances to back up ($INSTANCE_LIST ), what level backup to run ($LEVEL ), and what device to use ($DEVICE ). How infback.sh does this depends on which arguments (if any) it receives.
If infback.sh is called with no arguments
If called with no arguments, like this:
$ infback.shinfback.sh looks at the third field in infback.conf to determine what level of backup to run. That field specifies the full backup day. If today is the full backup day, then it performs a level-0 archive. If it is not today, it performs a level-1 archive. infback.sh then looks at fields 6 and 7 of infback.conf to get the name of the device server and device to which it should back up. Finally, it looks at inftab for a list of instances to back up.
If infback.sh is called with arguments specifying backup parameters
If infback.sh is called with arguments as follows:
$ infback.sh level [device|host:device] [instancea instanceb ...]it will determine its level and device from the arguments. If it also receives a list of instances to back up, it will use that as the list of instances. If not, it determines the list of instances to back up by listing each instance list in inftab. The arguments and their possible values are as follows:
- level
- This should be a valid level for an Informix archive (0, 1, or 2).
- device | host:device
- This should be a valid device name or directory name. It also can be hostname : device (e.g., apollo:/dev/rmt/0cbn).
[instancea instanceb...]- These arguments are optional. You may specify one or more Informix instances to back up. Specifying no instances causes infback.sh to back up all instances listed in inftab.
If infback.sh is called with at as the first argument
If infback.sh is called with at as the first argument (as it would be called in cron or at):
$ infback.sh atinfback.sh sets the $TIME variable so that the backups take place at a specified time. If it is a level-0 backup, infback.sh sets the $TIME variable to the value in field 4. If it is a level-1 backup, it sets the $TIME variable to the value in field 5. infback.sh then schedules an at job that will perform the backup at the time specified by $TIME. If there were other arguments given after the at argument, those arguments are passed to the scheduled run of infback.sh. When the at job runs infback.sh, it will then determine what and how to back up based on the arguments (if any) that it was given.
The backup begins
Once the actual backup is supposed to run, infback.sh checks to see if the database is up. If it is not, infback.sh complains and exits. If it is up, infback.sh checks to see if there is enough space to make a change to the onconfig file.[8] What it does next depends on whether you specified that compression should be used.
If there is a value specified in infback.conf for $COMPRESS, infback.sh creates a named pipe called $INFORMIXDIR/$INSTANCE.level.$LEVEL.fifo, and changes
TAPEDEVto that filename. It does this using onmonitor, so the change will be effective immediately. After creating the named pipe and telling ontape to use it, it calls compress and tells it to read from the named pipe, compress the data, and write it to the location specified as the original device. infback.sh then calls either ontape or tbtape, depending on the version of Informix you are running, [9] passing it the appropriate level. It checks the status of the backup command and, if backing up to disk, compresses the backup file.If there is no value specified for $COMPRESS, infback.sh sets
TAPEDEVto $DEVICE_SERVER:$DEVICE_FILE using onmonitor. It then calls ontape to perform the archive to the specified device.Installing infback.sh and its configuration files
If you'd like to use infback.sh, you'll need to install the files in the appropriate directory, configure inftab and infback.conf, and customize infback.sh to your environment.
Copy infback.sh, localpath.sh, rempath.sh, and config.guess into the same directory (e.g., $INFORMIXDIR /local/bin) and make sure that they are executable. Copy inftab and infback.conf into a directory to which Informix can write (e.g., $INFORMIXDIR/etc). infback.sh needs to be able to write to this directory for the "skip" feature to work. inftab and infback.conf can be placed in the same directory as the other files, but they do not need to be.
Editing the infback.sh configuration files
If you have not already done so, you should configure inftab for use on this system. For details on how to do that, see "Edit the inftab file" earlier in this chapter.
Editing infback.conf
infback.conf is the configuration file for infback.sh and rclogs.sh. It should contain one line for each machine in the following format:
hostname.master::full_day:full_time:inc_time:device_server:archive_dest:allow_ids:compress:mail_idshostname.master
- Replace hostname with the base hostname. For example, if the hostname is apollo.domain.com, this field should contain
apollo.master.- full_day
- This is the day of the week that full backups should run. (All other days of the week will receive level-1 backups.)
- full_time
- If using the at argument, this is the time that the program should schedule level-0 backups. Suppose that it says
1900, and the full backup day is Mon. At 1500 on Monday, there is a cron job that runs infback.sh at. That will see that Monday is a full backup day and schedule an at job to run at 1900.- inc_time
- If using the at argument, this is the time that the program should schedule level-1 backups.
- device_server
- Set this to the hostname of the server that contains the backup device. If it is the same as this host, enter the base hostname only (just like in the first field). For all other hosts, use the Fully Qualified Domain Name (FQDN) if it is appropriate.
- archive_dest
- This should be set to a device or directory that will contain all archives. If it is a directory, make sure that it is writable by Informix. Also, if it is a directory, infback.sh will create a subdirectory for each instance inside this directory.
- allow_ids
- This is a |-separated list of user IDs that are allowed to run infback.sh. This is usually only Informix.
- mail_ids
- This is a comma-separated list of user IDs that should receive mail about the success of infback.sh.
Editing infback.sh
There are a few minor changes that you need to make to the infback.sh file itself. Locate the following variable and function declarations in the top of the script, and set them to the appropriate value for your environment:
DEBUG=- Set this to Y if you want to see debug information for all functions (i.e., turns on set -x).
BINDIR=- Set this to the directory where you copied the backup programs (e.g., $INFORMIXDIR/local/bin).
LOGDIR=- Set this to the directory where you want infback.sh to log its information (e.g., $INFORMIXDIR/log).
LOG=- Set this to the full path of the name of the log file you want it to use (e.g., $LOGDIR/infback.log).
INFCONF=- Set this to the full path of infback.conf (e.g., $INFORMIXDIR
/etc/infback.conf).INFORMIX=- Set this to the user that owns the Informix instance (usually informix).
INFTAB=- Set this to the full path of inftab (e.g., $INFORMIXDIR/etc/inftab).
TMP=- Set this to the directory you want infback.sh to use for temporary files.
- Preback
- Anything that is put inside this function will be executed prior to running the backup.
- Postback
- Anything that is put inside this function will be executed when the backups are finished.
Centralized configuration
Just like oraback.sh, the configuration file infback.conf can be shared via NFS. If multiple servers share the same configuration file, and you are using the at argument, you could make changes to all Informix backups by changing one file. Suppose that Informix backups currently are set up to run a full backup on Sunday at 1900. However, you know that the network will be down this Sunday. With most homegrown backup scripts, you would need to log into several servers and change multiple cron entries. With a centralized infback.conf file, you need only to change field 3 for each server from "Sun" to "Mon." If you know that there will be some intensive processing this evening, you also could skip all infback.sh backups by putting the word "skip" in field 2.
Scheduling backups
To use all scheduling features of infback.sh, create a cron entry that calls infback.sh at a time earlier than the earliest time specified in fields 4 and 5 in infback.conf. Since most backups are run after 6:00 P.M., a common entry would be like the following:
0 17 * * * /informix/local/bin/infback.sh atThis says to run the script with the at argument at 5:00 P.M. This causes infback.sh to look at the infback.conf file to determine what level of backup to run and what time to run it. It then will schedule an at job for the appropriate time.
The reason for keeping the entry as late as possible is to allow the DBAs to make changes to infback.conf. Since infback.sh does not look at the file until 5:00 P.M., they can change tonight's backup time or skip tonight's backups by changing the file any time before then.
Why Automating Continuous Backups Is Difficult
The original design of ontape -c continuous backups was that they would be run from an operator's console. They also would be monitored by that operator; when the system prompted for another tape, the operator would respond by changing tapes.
Automating a program that was designed to run and be monitored by a human around the clock is a challenge. It's even more difficult than automating an archive. ontape is designed to continue logging to a tape until the tape is full. Although you can write a program that will monitor the tape and let you know when it is full, how does the program notify you so you can replace the tape? The program can send you an email, but if you're not reading your email or the email gets lost in transit, the tape does not get swapped. Then, processing is eventually halted on that instance once all the logical logs become full and are not backed up. The secret to complete automation is to back up to disk instead. Backing up to disk does remove the need to swap tapes, but it's slightly more involved than simply changing the
LTAPEDEVfield to a disk.Any automated system designed to automate continuous backups needs to manage many things. The program must emulate the human that ontape was originally designed to interact with. Here are the tasks that must be handled:
- Put a tape in drive
- ontape expects a device it can write to. Historically this has been a tape drive with a tape in it. The way to emulate that on disk is to use the touch command to create a file that Informix can write to. The file needs to be owned by the Informix user ID and writable to both the Informix user and Informix group.
- Watch for a full tape
- Historically this was done by watching the terminal for a prompt. When backing up to tape, there are a couple of ways to do this. One way is to write a program that watches how many logs are backed up and checks that number against the number of logs you have determined will fit on a tape. This is somewhat complicated but is preferred over the second method. The second method would be to use the onstat -l command to watch for logs that get filled but are not backed up. This means that the tape device is already full, since no more logs are being backed up. (The problem with this method is that you may need to swap tapes very quickly, and you do not get notified right away.) When backing up to disk, the "tape" becomes full when the filesystem is full. Therefore, you simply need to monitor the filesystem where you are sending the logical logs. You then need to compress or remove files to make room for more continuous backups. You can start doing this once a filesystem reaches a certain threshold, such as 75 percent.
- Remember that Informix depends on the
TAPESIZEparameter to tell it how much data will fit on a "tape." It considers the tape full once it has put that much data on a tape, and it will request another tape. If it encounters a filesystem or tape that is actually full (as evidenced by a failed attempt to write more data) prior to reaching this value, the archive will actually abort.- Swap tapes
- When backing up to tape, you must swap tapes manually. A program that is running continuous backups for you will need to notify you in some way that this needs to happen. If backing up to disk, this is done by moving the "tape" file to another location and re-creating a file in the same location using the touch and chown commands.
- Tell ontape there is another tape
- When using continuous backups, this is the difficult part to automate. As mentioned previously, ontape has a tendency to immediately send hundreds of prompts to a program trying to talk to it, so it's somewhat impractical to actually try to answer these prompts. It works just as well to stop continuous backups, then restart them once you've swapped the "tape." A good way to stop them is to use the onmode -z command. If you can keep track of the session ID that is associated with your ontape process, you simply pass this value to the onmode -z command, and it will close the session gracefully. If that doesn't work, you can always kill the process ID.
WARNING: If you are using Informix 5.x, never kill an ontape process of any kind with the -9 option. The instance will need to be restarted to recover from this. (Informix 7.x recovers from this condition gracefully.)
- Move the backup tape or disk to another location
- It doesn't do any good to back up your logical logs to a tape or disk and then leave that backup sitting right on the server. You need to move the backup to another location. When backing up to tape, this must be done manually of course. When backing up to disk, this can be automated by copying the file to an NFS-mounted filesystem or running another backup program to back it up to a tape somewhere else. Do something other than just leave the one file or tape all by itself on the server, especially if you are backing up to disk. Copying it to another location on disk is so simple. Not copying it leaves you open to an electrical surge that takes out both the backup disk and the disk(s) that contained the instance.
The rclogs.sh program was written to automate all of the preceding tasks.
Automating Continuous Backups:
the rclogs.sh UtilityThe rclogs.sh program can back up to either tape or disk, but it works best if backing up to disk because it can automate the "swap tapes" step by automatically moving and creating files as needed. The first step that rclogs.sh performs is to check that the Informix instance is online. It performs a while loop until the instance reports "On-line" or "Read-only." If it stays in this loop for 60 seconds, it exits with an error. Without this feature, a malfunctioning instance would prevent other instances from starting when this program is called from dbstart.
The next thing that rclogs.sh does is check to see if there are any ontape -c backups running for this instance. If so, it stops them. If rclogs.sh was called with the stop argument, it then exits. If it was called with the start argument, it then needs to "swap tapes." If backing up to disk, rclogs.sh moves the continuous backup file to a date/timestamped file and creates an empty file for the next ontape -c session. If backing up to tape, this program cannot be run from cron; it must be run manually from a terminal because once it stops the ontape -c session, it can only notify the operator running the program to swap the tape and wait for notification that this has been done. Once rclogs.sh knows that the tape has been swapped, it will start a new ontape -c session in the background. It then queries Informix to verify that continuous backups are running and sends notification of success or failure.
Installing rclogs.sh and its configuration files
Install the files rclogs.sh, localpath.sh, rempath.sh, and config.guess in the same directory (e.g., $INFORMIXDIR /local/bin) and make sure that they are all executable. Install inftab and infback.conf in a directory writable by
informix(e.g., $INFORMXDIR /etc). (These two files do not have to be in the same directory as the executables, but they can be.)Editing rclogs.sh and its configuration files
Make sure you have already configured the inftab and infback.conf files for use on this system; details on how to do this can be found in the previous section, "Editing the infback.sh configuration files." (The only field that rclogs.sh uses from infback.conf file is the mail IDs field.)
Check the site-specific section at the top of rclogs.sh and make sure that all the values are appropriate for your environment. The following values are found there:
DEBUG=- Set this to
Yif you wish to see debug information (set -x).INFTAB=- Set this to the full path of your inftab file.
COMPRESS=- Set this to the compression command that you wish to use (e.g., gzip).
COMPSUFF=- If you change the compression command from the default value of "compress," then you need to change this value. It is the suffix that your compression command uses (e.g., use gz for gzip).
BINDIR=- Set this to the location of infback.sh and the other programs (e.g., $INFORMIXDIR
/local/bin).THRESHHOLD=- This should be set to a percentage between 50 and 100 if you are backing up to disk. Once the filesystem specified by $ARCHIVEDEST is this full, it does some extra cleanup and notifies you.
TMP=- Set this to the directory that you wish to use for temporary files.
INFORMIXDIR=- This normally can be left alone, since it is determined from inftab.
ONCONFIGFILE=- This also can normally be left alone, but if you have a unique location for your onconfig files, specify it here.
ARCHIVE_DEST=- This also is determined by looking at inftab.
INFORMIXSERVER=- This is automatically determined by looking at the onconfig file.
LOGDIR=- Set this to a directory that you want to use for logs (e.g., $INFORMIXDIR
/logs).LOG_FILE=- Set this to the name of the log file that you wish to use.
PATH=- You normally should not need to change this.
DBAS=- If you've already specified the use of infback.conf, the value of this field is determined from there. If not, you can specify a list of mail IDs to mail to. (Enclose them within quotes if there are more than one.)
Testing the rclogs.sh program
Before adding the rclogs.sh script to cron, you might want to run it a few times to make sure that it works in your environment. Run rclogs.sh:
- With the stop argument to make sure that it stops the appropriate logs
- With the start argument to make sure it creates the file and starts the ontape -c process
- Multiple times with the start argument to make sure that it stops and starts the appropriate logs
Scheduling backups
Once you are sure the program works for you, you have a few options for how it is used. If you have installed dbstart.informix.sh, it automatically calls rclogs.sh when the system shuts down or starts up. This means that continuous backups are started automatically when the instance is started using dbstart.informix.sh.
If you are backing up to disk, you can greatly increase your recoverability options by running rclogs.sh every hour or half hour. This is especially true if you have added some commands to the Backup_the_backup function. Instead of having one large log for each day, you will have many small logs that get backed up throughout the day. Doing this ensures you'll never lose more than 30 minutes worth of data. The following cron entry runs rclogs.sh every half hour:
00,30 * * * * /informix/local/bin/rclogs.sh startUsing the Scripts Together
The scripts discussed in the previous sections all work together. dbstart, rclogs.sh, and infback.sh all use the inftab file. rclogs.sh and infback.sh both use the infback.conf file. dbstart automatically calls rclogs.sh. Running rclogs.sh on an hourly or half-hourly basis will provide you with multiple logical log backups that you can use at recovery time. Running a weekly full and daily incremental backup using infback.sh will reduce the amount of time spent doing backups and still requires only three tapes for a restore (the third tape is the logical log backup).
Physical Backups with a
Storage Manager: onbarontape is a program that has been around for years, and its greatest single feature is simplicity. It does have limitations, though, that were addressed with the release of onbar. onbar has the following features that ontape does not have:
- XBSA interface
- The XBSA interface is what separates onbar from ontape or onarchive. This interface is designed specifically for use with third-party storage management (TPSM) applications, such as those discussed in Chapter 5. XBSA allows you to use onbar to back up Informix data directly to the TPSM's tapes. Whereas ontape requires you to keep track of all the archive tapes, onbar and the TPSM will do that for you. When you need to restore a database, you simply tell onbar to do so; onbar and the TPSM figure out which tapes they need. If you have a jukebox, they even automatically put the necessary tapes in the drives.
- Restartable restore
- This is a new feature in Informix 7.3. With earlier versions, if you are restoring a large database and the restore fails at 90 percent complete, you have to redo the entire restore. The restartable restore feature allows the restore to pick up where it left off.
- Restore of online storage spaces
- "Storage space" is a new term in Informix documentation that refers to any storage element, such as a dbspace, a blobspace, or a chunk. (It used to be necessary to take a storage space offline prior to restoring it.)
- External backup and restore
- External backup and restore is an interesting feature, also new in 7.3, which allows you to copy disks containing storage spaces to another location and restore them with onbar.
- Storage-space-level backup and recovery
- ontape allowed you to recover a single dbspace, but you still needed to back up the entire instance at one time. With onbar, you can back up or restore any storage space within an Informix instance.
- Multiple backup streams
- This is a feature that ontape never had and what most people went to onarchive to get. This feature allows the TPSM to accept or request multiple backup streams (or threads) at the same time. This means that the TPSM may back up 50 or more dbspaces at a time! (In case you are wondering, it can also read multiple streams simultaneously during a restore.)
- Simplicity of ontape with the flexibility of onarchive
- This is how onbar was always billed, and it really is true. It really does give you the flexibility that Informix users have always needed, without the incredible complexity of onarchive.
Since onbar and ISM are well documented and easy to use, there is not much sense in covering onbar in detail in this chapter. It is especially difficult to discuss the configuration of onbar without discussing a particular storage manager. This section of this chapter, then, serves only as an overview of what lies before you if you choose to use onbar.
Configuring onbar
The first thing that you need to do is make sure that you have recent releases and patches of both onbar and your storage manager. Then, look for the following values in your onconfig file:
# Backup/Restore variablesBAR_ACT_LOG /tmp/bar_act.logBAR_MAX_BACKUP 0BAR_RETRY 1BAR_NB_XPORT_COUNT 10BAR_XFER_BUF_SIZE 31
BAR_ACT_LOG
- This should be set to the full path of a filename that onbar can use for its own logs.
BAR_MAX_BACKUP- This is the maximum number of threads (as defined previously) that onbar is allowed to start simultaneously.
BAR_RETRY- If there is an error when onbar tries to back up a storage space, you can specify what it should do next. If
BAR_RETRYis set to a number (e.g., 10), it retries that storage space in 10 seconds. Setting it toBAR_CONTmeans that onbar should continue to the next storage space. A value ofBAR_ABORTmeans that onbar should abort the entire operation if it encounters any errors. Typically, this value is set toBAR_CONT.BAR_NB_XPORT_COUNT- This is the number of buffers that onbar is allowed to use when passing data to the TPSM.
BAR_XFER_BUF_SIZE- This specifies how large the onbar buffers should be. The default value depends on the OS page size. Exercise extreme caution when modifying either
BAR_XFER_BUF_SIZEorBAR_NB_XPORT_COUNT, as bad values can adversely affect the performance of both onbar and the Informix instance.You also should know that onbar will create a file called $INFORMIXDIR/etc/ixbar.servernum. This is called the "emergency boot file" and contains the information that onbar needs to perform a cold restore of an instance.
Configuring the Storage Manager
Most of the work in getting onbar to do its job is on the storage manager side. It is here that you have to define tape pools, backup definitions, and schedules. If your storage manager is worth its salt, all these steps should be properly documented. It also may include a shell script that automates basic configuration.
Once properly configured, you should be able to back up your Informix database from either side of the system. That is, you should be able to run a backup from your storage manager and have it automatically activate onbar, causing it to begin sending an Informix backup to the storage manager. You also should be able to execute onbar commands from the Informix command line and have it automatically activate the storage manager, causing it to load tapes and begin accepting data from onbar. (The same is true for restores.)
Performing Backups
There are three types of backups available in onbar. You may back up:
- The whole instance
- Part of the instance
- The logical logs
When backing up all or part of the instance, you also may specify three backup levels. When backing up the logical logs, you may back up the current log or all full logs or salvage any logs that are not backed up. There isn't actually a continuous backup feature, but there is a shell script that emulates it.
Backing up the whole instance
To back up the whole instance, run the following command. Specifying the level is optional and can be 0, 1, or 2. If you do not specify a level, it defaults to a level 0. This is the onbar equivalent of the ontape -s command.
$ onbar -b [ -L level ]You also can add a -w option to the command, which causes it to do a "whole system" backup, which backs up all storage spaces serially.
$ onbar -b -w [ -L level ]Backing up part of the instance
To back up part of the instance, drop the -w and list one or more dbspaces after the onbar command:
$ onbar -b [ -L level ] dbspace1 dbspace2 [...]TIP: This functionality is not available with ontape.
Backing up the logical logs
The following command is somewhat equivalent to the ontape -a command, since it backs up all full logs. However, unlike the ontape -a command, it is the preferred command to back up the logical logs with onbar. In fact, the following log_full.sh script uses this option to do continuous backups. One main difference is that it does not also back up the current log; it backs up only logs that are marked as full.
$ onbar -lThe following command backs up the current log and switches the instance to the next log:
$ onbar -l -cAn onbar recovery automatically performs a log salvage prior to overwriting the logical log, but this command is for the paranoid administrator who would rather do that before beginning a restore:
$ onbar -l -sAs mentioned previously, onbar doesn't have continuous backups in the same sense that ontape did. That is, it does not have an option that keeps a backup device open continuously. The reason for this is that there is no need to dedicate a single device to a process that may happen only a few times a day. However, since you probably do want to back up logical logs as soon as they are full, Informix has provided a program called log_full.sh that you will find in the $INFORMIXDIR/etc directory. To use this program, change the following line in your onconfig file:
ALARMPROGRAM $INFORMIXDIR/etc/log_full.sh # Alarm program pathRecovering Informix
Recovering Informix is much easier than recovering other databases. One reason is that the commands to actually perform the recovery are simple--there is only one argument for ontape and only two arguments for onbar. This section covers just about any recovery scenario that you might find yourself in, yet it has fewer than 20 main steps.
Another reason that Informix recoveries are simple is that the sysmaster database, physical log, and logical log are considered critical. In order to recover one of them, you have to recover all of them. In Oracle, for instance, there are four or five different recovery tactics that you can use, depending on which one of these objects is damaged. With Informix, there is only one recovery tactic.
The Informix recovery procedure does not assume that you know why your database went down. It does assume that you have been making backups via ontape or onbar. It also assumes that if you are using ontape, you know which tapes or files contain the latest level-0 and/or level-1 backups, as well as the location of all logical log backups since your last physical backup. If you are using onbar, this procedure assumes you know how to use your storage manager well enough that you know how to respond to its prompts for any media that may not be in an autochanger. In short, all media management is up to you.
The following examples use ontape. The example hostname is curtis, and the instance name is
crash. The archives are being sent to disk files named /informix/logical/crash/crash.level.level.Z, and continuous backups are being sent to a disk file named /informix/logical/crash.log.The flowchart shown in Figure 14-2 is meant to be used in conjunction with the following procedure. Each element in the flowchart corresponds to a step in the procedure. You should start with Step 1.
Step 1: Does oninit Work?
The obvious first step in determining if an instance is in need of recovery is to try and start the instance. Do this by issuing the oninit command with no options. If it works, it just returns the prompt to you. You also could see one of two errors.
curtis $ oninitWARNING: Cannot access configuration file $INFORMIXDIR/etc/$ONCONFIG.This error is pretty obvious. If you see it, you are missing your configuration file and should proceed to Step 2.
If any of your critical dbspaces has damaged or missing chunks, you may see an error like this one.
oninit: Cannot open chunk '/informix/rootdbs.dbf'. errno = 2oninit: Cannot open chunk '/informix/rootdbs_mirror.dbf'. errno = 2oninit: Fatal error in shared memory initializationIf all critical dbspaces are mirrored, and only one-half of the mirror is damaged, you do not see this error. It also does not appear if a noncritical dbspace is damaged. This error appears only if all chunks in a critical dbspace are damaged.
TIP: If you see an error like the previous one, proceed to Step 2. If you don't see either error, proceed to Step 7.
Step 2: Is the onconfig File Missing?
The oninit utility uses the onconfig file to determine the basic information needed to start the instance. This includes, but is not limited to, the following instance-specific information:
- The location of the root dbspace
- The location of the physical log
- The
SERVERNUMvalue- The base address of shared memory
- Sqlhosts information
TIP: If the onconfig file is missing or corrupted, proceed to Step 3. If this is not the reason the instance would not start, proceed to Step 4.
Step 3: Restore or Re-create the onconfig File
If you are running onbar, it can automatically re-create the onconfig file. However, if this file is the only one damaged, there's no need to do a full restore just to restore this file. Restoring or re-creating it is easy enough.
If you are running infback.sh, it makes a backup copy of the onconfig file before it changes it. DBAs and other scripts often do the same. Look first to see if you have such a backup copy. If not, try to restore the file from the nightly filesystem backups. If you cannot find a backup copy and cannot restore one from backup, you will need to re-create it. If any of the following objects is available, it will be easy:
- The chunk (or its mirror) that contains the root dbspace
- A level-0 or -1 archive created by ontape on disk
- A level-0 or -1 archive created by ontape on tape
To re-create the onconfig file from the root dbspace chunk or an ontape archive on disk, run the following command, where filename is the name of the chunk or archive on disk:
$ strings filename |grep '^[A-Z][A-Z_]*' >$INFORMIX/etc/$ONCONFIGIf you have only an archive available on tape, the command is similar:
$ dd if=$TAPEDEV bs=$TAPEBLK | strings |grep '^[A-Z][A-Z_]*' \> $INFORMIX/etc/$ONCONFIGThis creates an editable text file that contains all the parameters and their current values. The grep command does not completely remove extraneous lines, so you should edit it and remove any lines that do not look like the following:
PARAMETER valueIf you do not have one of these objects available, you need to manually re-create the file. Copy the onconfig.std file in $INFORMIXDIR/etc to the name of the onconfig file. The values that you must change are
ROOTNAME,ROOTPATH,DBSERVERNAME,SERVERNUM, andSHMBASE. These values will allow you to restore the instance.
"Jagged Little Pill"a
Step 4: Is There an Inaccessible or Critical Chunk?
If an Informix instance will not start, the most common cause is a missing or corrupt critical chunk. (If a noncritical chunk is damaged, the instance starts and records the problem to the online log file.) The error that you receive may look something like the following:
oninit: Cannot open chunk '/informix/rootdbs.dbf'. errno = 2According to errno.h, an Error 2 means "No such file or directory." This means that the chunk or the symbolic link that Informix uses to refer to that chunk is missing. Another common error is 13, which means "Permission denied." This means that someone other than Informix owns the device. Any error other than those usually means that the physical file is all right, but the data within it is corrupted.
TIP: If the file is missing or its permissions are wrong, proceed to Step 5. If not, proceed to Step 6.
Step 5: Repair or Replace the Missing Chunk
This step is necessary only if the physical file is somehow damaged. If it were a filesystem file, it might be deleted or its permissions changed. If it were a raw device, the disk drive could be damaged or missing or its permissions could be wrong. Another problem could be that you are using a symbolic link to the real chunk, and the symbolic link was deleted accidentally.
If the missing file is a symbolic link, you simply need to restore or re-create the file in its original location. The only difficult part is that Informix doesn't tell you which file it was symbolically linked to. Restoring the symbolic link from your regular filesystem backups is probably the easiest answer. Another method would be to consult any documentation that you may have about how you put the instance together. (Restoring from backup obviously is much easier.)
If it is not a symbolic link, the damaged file may be a filesystem file or raw device. If it is a filesystem file and the filesystem itself is intact, simply re-create a new file with the touch command. After doing so, make sure that the file is read/write for the
informixuser andinformixgroup. If the filesystem is not intact, you need to relocate the file. Hopefully, you followed the common practice of using symbolic links to point to the actual chunks. If you did, you can re-create the chunk file anywhere on the system and just change the symbolic link to point to the new location. If you did not, you need to make a symbolic link in the original location to point to the new file.For example, assume that the filesystem /data1 is destroyed, and it contained chunk /data1/rootdbs.dbf. However, you set up the Informix instance to point directly to /data1/rootdbs.dbf, instead of to a symbolic link to that chunk. You create a new file called rootdbs.dbf in /data2, but you have to tell oninit to use the new file. You need to unmount /data1 (although it probably is already) and create a symbolic link in the old location with the following command:
$ ln -s /data2/rootdbs.dbf /data1/rootdbs.dbfThis is, of course, a very bad solution since repairing and remounting /data1 will overwrite the symbolic link. If you have to do this, consult your IDS Administration Manual about permanently relocating the file. (Use a symbolic link this time.)
Before continuing, you may wish to verify that all chunks are all right. If you don't have a complete list of filenames, you can obtain them by running the strings command on a root dbspace chunk or an ontape archive:
$ zcat /informix/logical/crash/crash.level.1.Z | strings | grep '^/'Make sure that you have checked both of the following conditions:
- Permissions
- Ensure that someone didn't accidentally change the ownership or permissions of any chunks. If you are using symbolic links to point to the actual chunks, the only permissions that matter are those for the final file to which the symbolic link is pointing. For example, suppose that you have a symbolic link called /informix/chunk1 that points to /dev/dsk/c0t0d0s5. If you are running Solaris, and if you run an ls -l on /dev/dsk/c0t0d0s5, you will find this:
lrwxrwxrwx 1 root other 84 Nov 5 02:29 /dev/dsk/c0t0d0s5 -> ../../devices/iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/esp@f,800000/sd@0,0:f- It is the permissions of sd@0,0:f that matter, not the symbolic link /dev/dsk/c0t0d0s5. To verify its permissions, run the following command:
$ Ls -lL /dev/dsk/c0t0d0s5- Adding the -L option causes it to display the ownership and permissions of the source file, not of the link. Make sure that both the owner and the group are
informix, and that the file is read/write for both the owner and the group.- Symbolic link
- This problem usually happens when the DBA is trying to "clean house." If you're using symbolic links to point to the actual chunks, and someone deletes the symbolic link, you obviously have a problem. If you are using symbolic links, make sure that you remake the symbolic link instead of creating a chunk in its place.
TIP: If the instance is currently down because a critical dbspace could not be opened, return to Step 1 and run oninit again. If the instance is already up and you were sent here by Step 8, proceed to Step 9. If you have repaired or replaced any missing chunks and the instance still won't start, proceed to Step 6.
Step 6: Performing a Cold Restore
TIP: You should perform this step only if directed to do so by Step 5.
Make sure you need this step
This is not a step to be taken lightly. Depending on the size of your instance, a cold restore may take a considerable amount of time. Please take a moment to verify that you really do need to perform a restore; if you do, follow the appropriate section below.
TIP: Both ontape and onbar allow you to specify a list of dbspaces to restore. This even works with critical dbspaces. However, if you restore just the critical dbspaces, the restore leaves all other chunks in an "inconsistent" state, as specified by the I flag that they display after the restore is done. Informix support does have a tool that will change this flag to consistent, but your mileage will vary on this one. If you are restoring a critical dbspace, you really should restore the whole thing.
Restoring with ontape
After removing the current logical log tape or file from its current location, place the latest level-0 archive in the device specified by
$TAPEDEV. If you are backing up to disk, this may require uncompressing and moving a file to the appropriate location. If you're backing up to tape, it involves placing the latest level-0 archive in the tape drive. After doing so, execute the following command:$ ontape -rontape prompts you for everything that it needs. You need to know if you have a level-1 or -2 backup, since it will ask you that. You'll also need to know the location of all logical log backups since the latest archive was taken.
WARNING: Make sure to remove the current logical log "tape" prior to beginning a physical restore. If you're backing up to disk, this means moving the file to a different location. If you're backing up to tape, this means physically removing the current logical log tape. When performing a physical restore with ontape, it asks you if you want to back up the current log, and you should always say yes. However, this performs an ontape -a backup, not an ontape -c backup. Remember that the primary difference between these two options is that ontape -a overwrites the "tape" currently in the drive. If it contains any logs other than the current log, they will disappear forever.
The following example was done with an instance that is archiving to disk using infback.sh. infback.sh now uses named pipes, so the value for
TAPEDEVwill be a named pipe (e.g., /informix/logical/crash.level.1.fifo) that reflects the last level that was performed. Since infback.sh will re-create the named pipe when it needs to, we will overwrite it with symbolic links. The instance also used rclogs.sh to continuously back up the logical logs to disk. The value forLTAPEDEVis /informix/logical/crash.log, and when it switches logs, it copies them to /informix/logical/$ONCONFIG.year.month.day.hour.minute.second.WARNING: Informix asks you if you want to back up the logs. Always say yes, but make sure that you are giving it a fresh tape or file to back up to, since it will overwrite it --not append to it.
Putting All the Logs on One Tape
An ontape restore with archives on disk always requires more than one window, and this section needs to show both of the windows described later to fully demonstrate the example. To reduce confusion, it uses a regular paragraph like this one when switching windows. Since it still needs to explain the reasoning behind certain commands or answers within a window, it uses this font to do that. There is also a heading on each body of computer output specifying either Restore Window or Alternate Window. The Restore Window is the window in which the ontape -r command is being run, and the Alternate Window will be the window in which we perform other commands. We will start with Example 14-17, the Restore Window.
Example 14-17: Starting an ontape Restore [Restore Window] #The first thing that we need to do is #uncompress the archive files. curtis$ uncompress /informix/logical/crash/crash.level.*.Z curtis$ ls /informix/logical/crash crash.level.0 crash.level.1 # Now we need to remove the named pipe and replace it with a # symbolic link to the actual backup file. curtis$ rm /informix/crash.level.0.fifo curtis$ ln -s /informix/logical/crash/crash.level.0 /informix/crash.level.0.fifo #Now we can begin the restore. curtis$ ontape -r Please mount tape 1 on /informix/logical/crash/crash.level.0 and press Return to continue ... Archive Tape Information Tape type: Archive Backup Tape Online version: INFORMIX-OnLine Version 7.23.UC4 Archive date: Thu Jan 21 00:57:14 1999 User id: informix Terminal id: ? Archive level: 0 Tape device: /informix/crash.level.0.fifo Tape blocksize (in k): 16 Tape size (in k): 1024000 Tape number in series: 1 Spaces to restore: 1 [rootdbs ] 2 [plogdbs ] 3 [llogdbs ] 4 [testdbs ] Archive Information INFORMIX-OnLine Copyright(C) 1986-1995 Informix Software, Inc. Initialization Time 03/04/98 20:08:25 System Page Size 2048 Version 4 Archive CheckPoint Time 01/21/99 00:57:17 Dbspaces number flags fchunk nchunks flags owner name 1 2 1 1 M informix rootdbs 2 2 2 1 M informix plogdbs 3 2 3 1 M informix llogdbs 4 1 4 1 N informix testdbs Chunks chk/dbs offset size free bpages flags pathname 1 1 0 10000 9051 PO- /informix/rootdbs.dbf 1 1 0 10000 0 MO- /informix/rootdbs_mirror.dbf 2 2 0 5000 2447 PO- /informix/physlog.dbf 2 2 0 5000 0 MO- /informix/physlog_mirror.dbf 3 3 0 5000 3447 PO- /informix/logiclog.dbf 3 3 0 5000 0 MO- /informix/logiclog_mirror.dbf 4 4 0 500 191 PO- /informix/testdbs.dbf # Ontape displays all this information to you so that you know # that this is the right tape to restore the right instance. # It doesn't actually do anything until you respond "y" to the next question. Continue restore? (y/n)y # Always say "YES" to this next question. Do you want to back up the logs? (y/n)y Please mount tape 1 on /informix/logical/crash.log and press Return to continue ... Would you like to back up any of logs 65 - 67? (y/n) yThis next section is from another window. We need to move the old logical log "tape" out of the way so that the salvaging of the current log does not overwrite it. In Example 14-18, we will use the same naming convention as the other files.
Example 14-18: Preparing Disk-Based Logical Log Backups [Alternate Window] curtis$ cp crash.log crash.log.1999.01.21.17.04.00 curtis$ compress crash.log.1999.01.21.15.05.16 curtis$ ls -l crash.log.1999.01.21* total 2424 -rw-rw---- 1 informix informix 73961 Jan 21 01:12 crash.log.1999.01.21.01.13.02.Z -rw-rw---- 1 informix informix 1949 Jan 21 01:13 crash.log.1999.01.21.01.14.08.Z -rw-rw---- 1 informix informix 557056 Jan 22 17:04 crash.log.1999.01.22.17:04:00.ZOnce we've copied the "tape" to another location, it is safe to tell Informix to salvage the current logical log. Note in Example 14-19 that when asked for the oldest log that we would like to back up, we reply with the oldest number available. (It never hurts to have too many logical log backups. If we were to answer "66," what would happen if the restore needed log 65 and it had not been backed up, or its backup had been damaged? We would be out of luck, that's what.
Example 14-19: Backing Up the Current Logical Logs [Restore Window] Logical logs 65 - 67 may be backed up. Enter the id of the oldest log that you would like to backup? 65 Please label this tape as number 1 in the log tape sequence. This tape contains the following logical logs: Log salvage is complete, continuing restore of archive. # We do have a level-1 archive, so when it asks if we have one, # we will answer "yes." Restore a level 1 archive (y/n) y Ready for level 1 tapeYou may recall that prior to beginning the restore, we created a symbolic link from the level-0 archive on disk to the location that Informix expects the archive to be. Now that we are "swapping tapes," we need to remove that link and create another one that points to the level-1 backup. (The commands in Example 14-20are obviously being done in another window.)
Example 14-20: Simulating a Tape Swap [Alternate Window] curtis$ rm /informix/crash.level.0.fifo curtis$ ln -s /informix/logical/crash/crash.level.1 /informix/crash.level.0.fifoNow that we have swapped tapes, we can respond to the prompt shown in Example 14-21.
Example 14-21: Responding to ontape's Prompts [Restore Window] Please mount tape 1 on /informix/logical/crash/crash.level.0 and press Return to continue ... Archive Tape Information Tape type: Archive Backup Tape Online version: INFORMIX-OnLine Version 7.23.UC4 Archive date: Thu Jan 21 01:10:13 1999 User id: informix Terminal id: ? Archive level: 1 Tape device: /informix/crash.level.1.fifo Tape blocksize (in k): 16 Tape size (in k): 1024000 Tape number in series: 1 # We do not have a level-2 archive, so we will answer no to # following prompt. Restore a level 2 archive (y/n) n # We do want to restore log tapes, though... Do you want to restore log tapes? (y/n)y Roll forward should start with log number 65Again, we must move over to the other window and prepare the logical log "tape." First, we move the salvage logs to an appropriately named file and compress it. Then we use the log concatenation method discussed in the previous sidebar. Since the logs are compressed, in Example 14-22 we create a single concatenated log using zcat.
Example 14-22: Creating One Large Logical Log Backup [Alternate Window] curtis$ mv crash.log crash.log.1999.01.21.18.00.00 curtis$ compress crash.log.1999.01.21.18.00.00 curtis$ ls -l crash.log.1999.01.2* total 2424 -rw-rw---- 1 informix informix 73961 Jan 21 01:12 crash.log.1999.01.21.01.13.02.Z -rw-rw---- 1 informix informix 1949 Jan 21 01:13 crash.log.1999.01.21.01.14.08.Z -rw-rw---- 1 informix informix 557056 Jan 22 17:04 crash.log.1999.01.22.17:04:00.Z -rw-rw---- 1 informix informix 557056 Jan 22 18:00 crash.log.1999.01.22.18.00.00.Z curtis$ zcat *1999* >crash.log curtis$ chmod 664 * crash.logNow that we have created the single log, we can respond to the prompt in Example 14-23.
Example 14-23: Completing the Restore and Starting the Instance [Restore Window] Please mount tape 1 on /informix/logical/crash.log and press Return to continue ... # Since we put all logs into this single log, there are no # more logs to restore. Do you want to restore another log tape? (y/n)n Program over. # The next step is very important. You must bring the # instance online when you are done, or you will # need to do the restore all over again. curtis$ onmode -mWARNING: Make sure that you use onmode -m to bring the instance online after doing a cold restore. If you do not, you will need to completely redo the restore if you stop and start the instance before doing so.
The first and simplest recovery with onbar is to enter onbar -r. This specifies to do a complete restore of any offline dbspaces. It automatically performs the following three steps for you:
Salvages the logical log
Completes physical restore, which reads the archive only
Completes logical restore, which reads all available logical logs
You also may add an optional -w flag (onbar -r -w) that specifies using the latest whole backup when performing the restore. If you have not been performing -w backups, then you cannot use -w on the restore. If you have been using -w on your backups, then you can use the same option on the restore. You also have the option of not using the -w option on the restore, even if you did use it to back up.
Unlike with ontape, you do not even need to move files around or swap tapes if you have an autochanger. onbar automatically retrieves the appropriate volumes that it needs to write to or read from. Even if you do not have an autochanger, it prompts you for the appropriate tapes by name.
You also have the option of performing the three steps by yourself. This allows you to use a number of flags to do different kinds of restores based on your needs of the moment. The first thing you need to do, though, is issue the onbar -l -s command to salvage any logical logs that have not been backed up.
After doing that, you have a number of options when performing the physical and logical restores. As started earlier, a physical restore is one that just reads the archive tape. It does not apply any logical logs. Applying the logical logs is called the logical restore. The following onbar command represents your options when beginning the physical restore. Please note the grouping of the options. The -p, -n, and -t options are mutually exclusive, and so are the -w, dbspace_list and noflags options.
$ onbar -r \[ -p | -n xxx | -t time ] [ -w | dbspace_list | noflags ]
Here is a listing of the various options and how they affect the restore:
If you specified just a physical restore, you may now perform the logical restore. When doing so, you have three options:
WARNING: Make sure that you use onmode -m to bring the instance online after doing a cold restore. If you do not bring the instance online with onmode -m before the next time you stop and start the instance, you will need to completely redo the restore.
In summary, an onbar restore offers you the same simplicity as an ontape restore, since both have the all-encompassing -r option that means to do a complete physical and logical restore. However, if you need extra options like point-in-time or point-in-log restores, they are available. It also has the added benefit of working with your storage manager so that you no longer have to worry about what tape has what backup. If you have not begun to look at onbar, perhaps now is the time to start.
TIP: Nine out of every 10 restores will end right here. To make sure that everything is okay, return to Step 1 and restart the instance after first bringing it online with onmode -m.
Perhaps the instance started on your first try. Perhaps you needed to do a cold restore in order to get it started. The next thing to do would be to check the online log for any errors. Examples of the types of errors you may see are shown in Example 14-24.
|
If you see any errors like this, you should run an onstat -d to see which chunk is having a problem:
Chunksaddress chk/dbs offset size free bpages flags pathname# Output abbreviated...a12a508 4 4 0 500 191 PD- /informix/testdbs.dbf
The preceding flags show you that the /informix/testdbs.dbf chunk is down. What you need to find out now is why it is down.
TIP: If you start the instance and there are no errors in the online log, then proceed to Step 16. If there are errors in the log, proceed to Step 8.
If oninit is able to access all critical chunks, it brings the instance online. If any noncritical chunks are inaccessible, it just logs the problem in the online log. If, after checking the online log and running an onstat -d, you have verified that a noncritical chunk is inaccessible to Informix, you need to repair or replace it.
TIP: If a noncritical chunk is inaccessible, return to Step 5. If you have verified that the problem chunk is now accessible and has the correct permissions, proceed to Step 9.
TIP: You should be performing this step only if directed to do so by Step 5 or 8.
The best way to find out if your noncritical chunks are corrupted is to try to bring them online. In order to be able to do that, the following conditions must be true:
If all these conditions are true, you probably can save yourself a restore by bringing the dbspaces online using onspaces. Run the following command for each chunk that was marked down:
$ onspaces -s dbspacename -p chunkname -o offset -OWarning: Bringing chunk back online.Do you really want to continue? (y/n)yVerifying physical disk space, please wait ...Chunk status successfully changed.
If you see successful messages like this one, you won't even need to do a restore. If it complains that the chunk is inconsistent, you have to do a restore to bring it to a consistent state.
TIP: If you were able to bring all down dbspaces online, proceed to Step 11. If not, proceed to Step 10 to restore them.
There isn't much that can be said in this step that wasn't already covered in Step 6. However, there are a few differences between the restore discussed in Step 6 and this one:
Read Step 6 in detail, then run one of the following commands:
$ ontape -r -D dbspace dbspace # Will recover any dbspaces$ onbar -r # Will recover all down dbspaces$ onbar -r dbspace # Will recover any dbspaces listed
Both onbar and ontape prompt you with the same standard questions. The main differences are that you may be warned that the affected dbspaces will be taken offline, and you will not be asked the "Do you want to back up the logs?" question. A sample output from an ontape restore can be found in Example 14-25.
|
TIP: Once the restore of all down dbspaces is complete, they will be brought online. Proceed to Step 11.
If you were forced to use an old onconfig file backup or to create one from scratch, you may have some wrong values. Depending on which values are wrong, they may prevent the instance from operating properly. If so, oninit logs them in the online log.
02:13:58 Onconfig parameter LTAPEBLK modified from 32 to 16.02:14:46 Onconfig parameter MIRROROFFSET modified from 1 to 0
TIP: If you see any errors like this, proceed to Step 12. If not, then proceed to Step 13.
This one is about as easy as they come. Change any bad values in the onconfig file back to their original values. For example, if you saw the errors displayed in Step 11, you need to change LTAPEBLK to 32 and MIRROROFFSET to 1. Unfortunately, most of these values are read only at startup.
TIP: Once you have changed any incorrect values, proceed to Step 13.
If you changed any values in Step 12, you need to restart the instance to have oninit read the new values. Also, if you had to follow a lot of steps to get to this step, you may want to make sure that everything will start correctly the next time. The only way to be sure of that is to restart the instance now.
TIP: If you wish to restart the instance, proceed to Step 14. If not, proceed to Step 15.
If you had to do any restores to get to this step, make sure that you bring the instance online before you take it offline again. To make sure that it is online, run the following command:
$ oninit -INFORMIX-OnLine Version 7.23.UC4 -- On-Line -- Up 00:00:29 -- 8976 Kbytes
If you see the preceding output, then the instance was brought online. If you see the following output, you need to bring the instance online by running the command onmode -m.
INFORMIX-OnLine Version 7.23.UC4 -- Quiescent -- Up 00:01:17 -- 8976 KbytesOnce you are sure that the instance is online, you can take it offline:
$ onmode -kyTIP: Once you have done so, return to Step 1.
If you don't restart the database, you should make doubly sure that all dbspaces and chunks are online. To do so, run the command onstat -d, as shown in Example 14-26.
|
Check the flags column in the Dbspaces section for flags P, L, or R. Also check the flags column of the Chunks section for flags D or I. The meanings of these flags are:
TIP: Once you know if there are any of these flags, proceed to Step 18.
Perhaps the instance started OK, but there is a different problem. If a DBA accidentally deleted a dbspace, or a user accidentally deleted an important table, there is really only one way to recovery that--a point-in-time restore.[11]
TIP: If you need a point-in-time restore, proceed to Step 17. If not, proceed to Step 18.
In order to do a point-in-time restore, you need to do a cold restore of the entire database. (Details on how to do that are in Step 6.)
If you are using ontape, you will need to apply all logical logs until you reach the one during which the user/DBA error occurred. Do not apply that logical log.
If you are using onbar, you can use the -n xxx or -t time features of onbar -r to recover up to a point in time just prior to the user/DBA error.
TIP: Once you have done this, proceed to Step 19.
TIP: If you saw any of the flags mentioned in Step 15, return to Step 8. If not, proceed to Step 19.
Every restore should be followed immediately by a full backup. Of course, Informix allows you do so online. Don't consider the restore finished until you have completed this backup.
Informix has two logical backup commands: onunload and dbexport. onunload is much faster than dbexport, but it has many more constraints placed on it than dbexport has. There are advantages and disadvantages to each utility.
onunload exports, or unloads, a database or table into a binary output file, consisting of a logical backup of a database or table. The resulting file can be used to import data into another database using the onload utility. onunload is faster because it copies the data in page mode, instead of having to convert the data to ASCII format as dbexport does. However, since the files are binary, only the same version of onload can read an onunload backup. This utility typically is used for moving data between computers but cannot be used for moving data between databases that are not the same version. onunload locks the database in shared mode while it is running. An error is returned if it cannot obtain a shared lock.
dbexport unloads a database into text files and creates a schema file. The resulting files can be used to import data into another database using the dbimport utility. Since the files are ASCII format, they can be moved between databases running different versions of Informix. The dbexport command is not part of OnLine XPS and Informix Dynamic Server with Advanced Decision Support and Extended Parallel Options, but onunload is. It is much slower than onunload since it has to convert the data to ASCII format. It also can back up only a database, whereas onunload can back up a database or table. dbexport locks the database in exclusive mode while it is running. An error is returned if it cannot obtain an exclusive lock.
TIP: I cover only onunload and onload in this chapter for three reasons: One is that these programs require only a shared lock, where dbexport requires an exclusive lock. Another is that onunload feels more like a backup and recovery tool, whereas dbexport 's emphasis seems to be moving data between different databases. The final reason is that I can't cover everything in a book of this size. onunload and dbexport use the same method of determining what device to use, as well as its block size and tape size, so that portion of this section may be useful to you if you plan on using dbexport.
Since the export created by onunload is actually a binary file, there are constraints on how that file may be used:
informix to unload a table. The onunload utility can write the exported data to a file on a hard drive or to a tape device. It can unload an entire database or just a table within that database. The syntax of the command is as follows:
$ onunload [-l | -b blocksize -s tapesize -t device ] database[[:owner].table]There are two methods of specifying the device parameters for onunload. The first is to use the -l option, which specifies that onunload should read the device, tapesize, and blocksize values from the onconfig file. It will use LTAPEDEV, LTAPESIZE, and LTAPEBLK values, respectively.
WARNING: Please note that
LTAPEDEVis the same device that you are using for your logical log backups. That means that if you do not specify a tape device, you could accidentally overwrite your logical backup tape! It is therefore safer to specify another device if you can. If you cannot, make sure you take your logical backup tape out of the drive before running this command.
The second method for specifying device parameters is to specify each of them individually using the -b blocksize, -s tapesize, and -t device options.
At a minimum, you must specify the name of the database to unload. To do this, simply name the database as the last argument of the onunload command. Optionally, you can specify a name of a table and the owner of that table. To do this, add the name of the table and its owner after the name of the database using this format:
database:owner.tableonload is onunload 's counterpart and will read the logical backup created by onunload. It will create a database or table in the specified dbspace and load the data from the logical backup into that database or table. If you do not specify a dbspace to load the database or table into, it will be loaded into the root dbspace.
As with onunload, you can specify the device parameters for onload by using the -b blocksize, -s tapesize, and -t device options. You also can use the -l option, which tells onload to read the device parameter information from the onconfig file.
You specify the name of the database or table to load the same way you do with the onunload utility. Specify the database by listing it as the last option. To specify the owner and table to load, list them after the database name in the following format:
database:owner.tableNow that you have specified the device to use and the database or table to load, there are options that determine how the database or table is created:
1. Informix would, of course, dispute this! I am merely saying that the term database refers to the same general structure in Informix that it does in other databases.
2. I really don't understand this one. This is such a bad situation to get into, I can't imagine anyone who wouldn't want to turn on this new feature.
3. Every commercial backup application charges per host for its interface to the database backup applications. In a large Informix environment, this can therefore reach $100,000 very quickly. It does provide significantly better functionality, but it is difficult to justify such an expense for a little 1-GB instance.
4. I finally figured out why archive is -s ! It stands for "save"!
5. It is usually true that the bigger the block size, the better the backup performance. However, in recent tests I found that a block size of 64 KB was actually faster than a block size of 128 KB. Your mileage may vary.
6. A here document is a Unix trick that allows a script to answer prompts from a command. It starts with <<STRING and ends with STRING.
7. expect is a public domain utility designed to answer a program's prompts for information. It is sophisticated enough to be able to give different answers for different conditions, such as a full tape. A typical shell script and here document can provide only one set of answers to a program. While using expect would probably increase the functionality of the script, I have tried very hard not to require the installation of other packages to make mine work.
8. This part is to get around an old problem that may have been fixed in newer versions of Informix. If you attempted to change the config file, and the filesystem was full, you would end up with an empty config file!
9. Believe it or not, this script works just fine with Informix 5! It might even work with Informix 4, but I haven't seen one of those in ages.
10. I found the available documentation on these different flags confusing. I hope that documenting the flags in this way will help reduce the confusion and not add to it!
11. Yes, I realize you cannot restore just a table from backup, unless you use the famous arcunload utility. (See Informix support for details.) However, you could restore the whole instance and stop the restore before the point in time when the table was deleted.
Anonymous
Posted Wed Nov 26 00:00:00 EST 2008
No text was provided for this review.
Overview
Unix Backup & Recovery provides a complete overview of all facets of Unix backup and recovery, and offers practical, affordable backup and recovery solutions for environments of all sizes and budgets. The book begins with detailed explanations of the native backup utilities available to the Unix administrator, and ends with practical advice on choosing a commercial backup utility.This book: