Limitations of the tb/ontape Program

In addition to the UNIX filesize limits noted in the previous section, there are several more items that can cause serious problems with the archiving process.

The Informix manuals recommend that a terminal be dedicated to the tb/ontape program and that someone watch that terminal for instructions to change the tape. If you do this, the terminal should actually be in the same room as the tape drive, so that the operator can visually check the status of the drive and change the tapes quickly. Although this looks good on paper, it is not always the best method from an operational standpoint. Sometimes, the DBA needs to have these processes working in the background or as a part of a management script. This can be done as in the following script:

   #!/bin/csh
   tbtape -s << EOF
   0
   ^M   (note, this is a control M
   EOF

This script runs the tb/ontape program and answers "0" to the Level? prompt and then enters a carriage return when prompted to hit enter when the tape is mounted. Please note that running tb/ontape from a script or in the background is definitely not recommended by Informix. You're doing it at your own risk, but the risk is manageable.

What's so risky about this? Problems arise if you exceed the capacity of your tape archive device. This capacity is set with the tb/onmonitor program. This tape size parameter, as well as the names of the archive and log devices, are changeable without having to restart the engine. When tb/ontape thinks you've reached the end of your tape, it will send a prompt to the standard output requesting you to change tapes and hit ENTER. If tb/ontape is running in the background or as part of a script, you cannot hit ENTER, and tb/ontape continues to wait for you to change tapes.

This creates a problem when your system needs to perform a checkpoint. Whether the checkpoint is needed because the checkpoint interval has elapsed or because the physical logs have reached 75 percent full, the checkpoint program will try to write out data to the archive tape. (Remember, the archives, logs, and checkpoints all work together and know of one other's status.) This write cannot occur when the archive is waiting for a tape change, so the checkpoint cannot occur. This causes the engine to freeze up and allows processes to perform nothing but data reads. The only way out is to kill the tb/ontape process. (Kill it with a UNIX kill -15 command, not with the very dangerous kill -9 command.) This problem has been corrected in the IDS engine. In the IDS engine the physical log before images are constantly copied to temp tables instead of to the archive.

You can feel relatively comfortable with running tb/ontape either in a script or in the background as long as you are absolutely sure that your entire archive will fit within a single archive tape.

Another thing to do if you're running tb/ontape in this way is to redirect the standard error and standard output to a file. Since tb/onmonitor and tb/ontape both use UNIX standard input and standard output, standard UNIX redirection methods work. If you redirect the output into a file, you can then access this file and check on the status of the archive without having to be at a dedicated terminal. You can also use the file output in other scripts. This is done in the status script included with this book. Note that tb/ontape uses the UNIX curses library and that it addresses the screen directly. The output file is difficult to read with the vi editor, as vi thinks it is all one line. Use the UNIX cat command and pipe it to more and you'll be able to see the output better. The status script runs a UNIX tail command on this output file to print the progress messages from tb/ontape.