General Archive Concepts
Archiving in OnLine is done with the tbtape program. This program performs both the data archiving when invoked as tbtape -s and the logfile archiving when invoked as tbtape -c or tbtape -a. The tbmonitor Archive menu options invoke the tbtape program.
IDS systems can use either ontape or the newer onbar program to backup and archive data. The ontape program is almost identical to tbtape because ontape is the natural progression of concepts found in tbtape. The extensions to tbtape that are embodied in ontape relate to restores for replicated systems and to restores of individual dbspaces.
This ability to archive and restore at the dbspace level gives the IDS administrator more flexibility in performing partial archives and restores. Indeed, it is conceivable that an IDS database administrator can achieve table-level archives and restores simply by placing each table in its own dbspace.
This book will not cover the onbar program in any depth. Informix includes a 300 page manual devoted to archiving and restoring the database, and most of it deals with the onbar program. Whereas the tb/ontape and onbar programs were written by Informix, the onarchive program was purchased from a third party and thus differs significantly from tb/ontape/onbar.
Like many other Informix database administrators, I have personally adopted the stance of being very slow to adopt the "latest and greatest" programs from any vendor, Informix included. I prefer to monitor the USENET newsgroups for six months to a year following introduction of a new product before using it for any mission-critical application. There is almost nothing more mission-critical in the database world than regular, reliable archives. If you are not certain of this yet, you will become certain the first time that you realize that your system has crashed and the only thing between you and the deep blue sea is a few hundred meters of flimsy magnetic tape.
Based on the feedback that I have been seeing on the Internet, avoiding onbar may have been a good decision, as the newsgroups are full of DBAs with problems or questions about onbar. I believe that the root cause of most of these problems is improper initial setup of the utility. This setup is complicated and error-prone, and many DBAs tend to approach it with a cavalier manner. I believe that onbar can be a workable and even necessary archive solution in certain cases because there are several things that onbar can do that tb/ontape cannot do, and if you fall into one of these categories, you may find yourself forced to use onbar. One of these areas is with extremely large databases in which the time to archive the system begins to cut into your window of time needed for other activities. One of the more important improvements to onbar is its capability to parallelize archives and restores and to use multiple tape drives simultaneously. If you decide to use onbar, I highly recommend attending the Informix class on the subject. Some day you will find yourself absolutely depending upon your archive and you need to be 100 percent confident in your archiving hardware, in your software, and in your operating procedures.
One of the more compelling features of the OnLine database is that archives can be run without shutting down the database. In an environment such as a large transaction processing system, this becomes a critical point. There is just no time available to take the database off-line for long enough to complete an archive.
When you consider exactly what is happening in backing up a database that is being accessed and modified at the same time, you will better understand some of the limitations of the archive process. At the same time the archive process is trying to take a snapshot of the database, users and batch jobs are trying their best to make that snapshot out of date. The archive process has to cooperate with checkpoints and logging processes to maintain the integrity and consistency of the data.
Do you Really Need to Archive?
There's a time that I would have considered such a question asinine, but there are applications that do not call for doing an Informix archive. One case may be with transient data working from batch loads that are frequently performed. The DBA and other system administration personnel need to evaluate the value, longevity, and time and cost needed to rebuild the data. In a system that is fed by batch jobs and is used for query processing, it may be that it will be faster and cheaper to rebuild the database and reload it from your source data in the event of a crash.
Note that I said "need to archive" and not "need to backup". If you are on an NT system or are only using cooked files in UNIX, you may have a non-Informix solution available that makes more sense than using the Informix archive and restore programs. There are three things that the Informix utilities give you that a non-Informix solution might not:
Ability to do a "hot" backup with the database up and running during the backup
Ability of the Informix utilities to allow you to recover from a disk crash by using the archives in conjunction with the logical logs to restore data up to the instant before the crash
Ability to do incremental backups or backups by dbspace
If you do not need any of these capabilities and if you are using cooked files on NT or UNIX, it will be much faster to use native operating system or third party backup and restore programs to backup your system. In a rare case like this, it is absolutely critical the database be shut down for the duration of the archive. Shutting the database down will ensure that the backup is totally consistent and that there are no data changes to parts of the database that have already been backed up during the course of the backup. Another reason that the database must be shut down is that many operating system backup programs will place a lock on files that are being backed up. If database activity were occurring during a backup, it is possible that Informix will try to read from a locked data file. If Informix cannot read a chunk, it assumes that the chunk is physically bad and internally marks the chunk as down and unavailable for use. This can range from a major inconvenience in later IDS engines to an emergency in earlier engine versions that requires Informix Support to call into your system and mark the chunks available. The IDS onspaces command supports a flag that will mark the chunk as online and available and in many cases the IDS DBA can avoid a support call-in by bringing the chunk online herself.
When considering your archive and restore options, do not limit yourself to consideration of the database alone. If your application generates any output files, critical logfiles, or temporary work files, an Informix archive may not be sufficient to restore your system to operation after an incident. The perfect example to this is a large data warehouse that does some of its summarization and aggregation work in operating system files not controlled by the database. If these files need to be kept in sync with the database data, restoring the database after a disk crash may not be enough to make the system operable. Unless the database and the aggregation files are consistent with each other, all of the data would be suspect.
Don't take this section as carte blanche to run without doing Informix archives. Indeed, in all probability you need to do regular Informix archives. Just be aware that there may be some situations that call for breaking the normal rules.