Installing and Setting up OnLine

At some point, you will need to be able to install and set up an Informix OnLine or IDS system. This will occur during an initial installation, during an installation on or upgrade to a new computer system, or during an upgrade to your existing system. As installations go, the Informix install process is usually relatively painless, but of course there are exceptions.

There seems to be a rule that software companies spend 20 quadrillion man years developing their products and about 10 minutes writing the install programs. Be very wary of all install programs, not only for Informix, but for all computer software. The rule seems to be uniform. If you have a chance, look at scripts before you run them, just to be sure that they don't do something stupid. Do this especially for upgrades. Install programs are often unclear about the extents they go to to preserve your existing data and environments. The better ones will warn you and ask your permission before making any modifications to anything critical. The worst ones will merrily blow away your data, configuration files, user files, and the like and not even bother to let you know what they've done.

Informix has gotten much better with the install programs for its Windows-based products. These install programs are very well thought out and for the most part will almost allow you to do a hands-off install. These install programs understand the relationships between the various Informix modules and will usually identify potential conflicts and give you guidance as to how to handle any unusual situations.

Luckily, Informix has a fairly robust set of install routines. In most cases, an upgrade will try to preserve existing data and environments. If the documentation does not make it clear, call Informix Technical Support. They may not, and probably will not, immediately know the answer, but they will research it for you.

In all cases, make a complete backup of your system before trying any type of installation procedure or upgrade. Back up your UNIX file system, making sure that you get all of your critical files. Do a complete, level 0 archive of your database, and back up all logfiles to tape. Don't scrimp or try to save time by not doing the backups. There's no such thing as a "safe" upgrade.

Maintaining a Logbook

A basic need common to all computer administration is the need to document and track the system configuration. Installation of software, changes to tuning parameters, changes or upgrades of the operating system, system crashes, and calls to support all need to be written down somewhere for future reference. Too often, the DBA gets so involved in solving the immediate problems that the job of documenting the problem gets a very low priority. A common train of thought is "Of course I'll remember what changes I'm making."

For the same reason that software must be rigorously documented, all of the primary and side issues of administering the database should be documented. Software that you install today may need to be reinstalled next year. You'll need the serial numbers, installation manuals, and software protection codes later. When you've discovered that something unusual has happened to your data two months ago and you're just now finding out about it, you'll want to know what types of tuning or database changes you made then. Some day you'll want to take a couple of weeks of vacation and let your assistant handle the database while you're gone. This person won't remember all of the things that you did. For all these reasons, you need to keep a logbook.

Computer people seem to want to try to do everything on the computer. That's why software developers can sell thousands of copies of home budget, recipe tracking, and videotape tracking programs that get used once or twice at the most. It's tempting to want to keep track of your database management activities using (surprise, surprise) the database.

Avoid this. Take the simple, low-tech approach. Use a physical logbook that you write in with a pen. (Try it, I'm sure it'll come back to you. It's the way you did it in elementary school.)

Make a big thing out of the logbook. Get a nicely bound book. Make it look good. You want something that gives you an incentive to use it and to keep it up. If you use some plain, ordinary notebook, you'll find yourself tearing pages out of it when you need to write down the plumber's phone number. The logbook is something you want to keep. Besides, if you make a production out of it, it'll be more convincing if you need to pull it out to convince a manager or a vendor that you know what you're talking about. True, it's a little thing, but little things count.

What should you keep in the logbook? At the very minimum, you need to have:

Telephone numbers	hardware and software vendors, service vendors, important staff members, facilities people (A/C, electrical, etc.), modem numbers for your incoming lines
Serial numbers	hardware, software (with key codes, too), O/S versions and revision levels version numbers of all installed software
Configuration data	disk layout documentation, mirroring and striping information, sample .profile or .cshrc files, scripts that set environment variables
Written procedures	startup and shutdown procedures, archive plan, logging procedures, emergency procedures, shutdown and startup procedures for applications, support policies, documentation for local utilities, location of full Informix manual set
Site-specific data	contents of your tb/onconfig file, tb/onstat -a output, tb/oncheck -pe output, dbschema output

For the most part, most of the items listed above are one-shot items. Sure, there's a lot of information to put together, but after it's done you'll only have to change it occasionally.

Other items need a running log that is more or less a system diary. These sections need to be added to as events happen. They need to be logged with a date and time.

Tuning changes	What parameters did you change? What were you trying to do? What was the result of the change? Is this a permanent change?
User complaints	What was the problem? Was it fixed? How? Is it a training issue?
System crashes	When did the system go down? Was there any data lost? What was the problem? How was it fixed?
Downtime	Was this scheduled or unscheduled downtime? Who was affected? How long was the system down? Who started it back up? Was there preventative maintenance done?
Support calls	Date and time of call to Informix Technical Support. Whom did you talk to? What was the case number they gave you? What did they recommend? Did it work? Is this a continuing problem? What was their response time?
Software changes	Full information about any new software installed. Information on any upgrades made.

This list is just the beginning of an outline, but you should get the general idea. This may be a pain to do right now, but when you find yourself with Informix licenses for 20 computers trying to figure out which versions are where and how to upgrade everyone to the same version, you'll be glad you took the time.

The Installation Procedure

Before you attempt an install or an upgrade, look through the documentation included with the software. Informix usually includes a booklet that details install procedures for the entire release set. These booklets are done by overall version of the product. Thus, if you have a 5.01 install, you may be installing a 5.01 engine and earlier, possibly 4.11 tools. There should be separate install booklets for the 5.01 and the 4.11 software. They'll probably say the same thing, but read through them to see if anything's different. You'll also get lots of registration forms and license forms. Put them aside and handle the paperwork later. You will, however, receive an envelope with the software serial number and installation key codes with each set of disks or tapes that make up one product. Be sure to keep track of which codes go with which products. I always try to write the serial number and key codes on the installation media. If you do this, be sure to maintain tight physical control over the media.

The booklets and distribution media will contain commands for loading the media. Take these with a grain of salt. The actual commands are probably right, as are the flags to the commands, but you'll probably have to do some interpretation of the device names. Just know the device names for your tape drives and/or floppy devices, and you'll get through it with no trouble.

UNIX Installs

It is very important that you have created the informix user and group properly. Check the installation booklet carefully to see if there are any restrictions on proper user or group numbers for informix. The instructions will tell you to place certain environmental variables such as $INFORMIXDIR into your environment. It's best to create the informix login first, then re-login as informix. You can check that you have the proper variables in place by using the UNIX echo command, as in echo $INFORMIXDIR. If the outputs are correct, you have the variables set correctly for your login. The actual installs are done as user root.

The actual installations usually follow a similar sequence of events.

Running the install script usually consists of entering the software serial number and key code and then watching the install script move things into the proper places. Part of the process is branding the code, which is Informix's means of protecting its software from pirates. If for some reason the install doesn't go properly, it is usually better to reinstall from the installation medium. If something got branded improperly or didn't get done at all, you'll have problems in the future.

The order of installation is important in installing Informix products. Usually, the order is:

A good mnemonic for remembering the order is TEN, for Tools, Engine, and Network. If you have any questions about the proper installation order, contact Informix Support for the latest information. With varying product families and varying versions, the TEN order does not always hold true, but it is a good place to start.

Be sure to completely install one product before you copy the media from the next product. The process should be copy media, run install, copy media, run install, etc.

After all of the products are on the disk and have been installed properly, you need to initialize the database. Initializing the database needs be done only once. If you are upgrading from a prior version, do not initialize the database. It will destroy all of your data if you do. Refer to the installation booklets for the initialization process, but I'll give you a few suggestions covering items that may not be clear in the documentation.

First, plan your install. Know which devices you are going to use for disk chunks. The best procedure for handling disk chunks is to create symbolic links to them. Don't ever use the full UNIX name for the devices. If you do, you will not be able to swap out those devices when they break. If you use links, you can simply replace a broken device with an equivalent one no matter what it is called. You then link the new device to the old device name and continue merrily on your way.

Make sure that all of these devices are owned by the informix user and that they have the proper access permissions. Informix is very picky about permissions, and the error messages are not always clear that they're complaining about permissions. In fact, if anything doesn't work correctly in the installation process, look at your permissions. If one of the install scripts did not complete properly, it may not have changed the permissions of the software correctly. If you already have a running engine, run a directory of all of the Informix code for future reference. There may be a time that you'll want to come back and compare your permissions with a known good system.

Also, be prepared to relink your kernel several times to get Informix to run properly. One common problem is with shared memory and semaphore limits. Have your UNIX system administrator (or the system administration manual) handy. It is a good idea to check the release notes after all of the software is installed but before you try to initialize the engine. These release notes are in the $INFORMIXDIR/release directory. In later IDS systems supporting Global Language Support (GLS), these release notes will be found further down in this directory tree divided into subdirectories based upon locales and GLS options. If your machine's release requires any special kernel parameters, they will be found in a file called *ONLINE*. Go through everything in the release notes directory. It'll save you a lot of time down the line

Windows NT Installs

As mentioned earlier, Informix has gotten much more sophisticated with the install programs for the Windows-based products. Most of these programs now come on CD-ROM, and the install often consists mainly of sticking the CD-ROM into the drive and letting Windows run it automatically. If Windows does not automatically run the CD-ROM, change over to it and look for either an "install.exe" or a "setup.exe" program. Run that program, answer a few questions, enter your serial number and key code, and you're off and running.

Pay particular attention to the requirements for Windows service packs. These are occasional operating system patches released by Microsoft. If the engine requires a particular service pack, be sure that it is installed on your system.

If this is an upgrade, the install program will usually recognize that you have existing Informix products and will ask you whether you want to just reinstall the product, reinstall and reconfigure it, or reinstall and reinitialize it. Be sure that you are certain what you are doing. It's always pretty scary when you are doing an upgrade and you don't know whether the install program will blow away all of your existing data. The install is actually pretty forgiving of this, but be careful.

If you want to take a "belt and suspenders" approach to doing a reinstall on an existing IDS system on NT, copy the rootdbs file over to a file with another name. Even safer is to rename the subdirectory in which the rootdbs resides. That way, even if the install program mistakenly chooses to reinitialize the database, you can recover from it. To be totally safe, take a copy of your ONCONFIG file before starting the upgrade also.

Versions of IDS on NT prior to 7.30 do not give you the option of setting up your chunks on raw disks. I've actually seen very little cost in performance to using the NTFS filesystem for your dbspaces. One thing that using the NTFS disk files gives you is some very tricky disaster recovery options. All of the information about chunk names, disk locations, chunk sizes, and dbspace locations is kept in the rootdbs. The only thing that refers to the location of the rootdbs is the ONCONFIG file. This means that as long as your ONCONFIG file is intact and as long as the rootdbs and other database disk files are in the same locations on the same drives as before, you can recover from many kinds of disaster.

As an example, I was doing an upgrade from 7.23 IDS to 7.30 IDS on NT and ran into problems because of some services that would not disappear (ISM storage manager services, and I still haven't figured it out). Due to some ill-advised monkeying with the registry and the attempt to manually delete some program files, I was trapped in a Catch-22 situation. I couldn't use the commands to uninstall properly, because I had deleted needed files. I couldn't install properly, because the services wouldn't go away. But I did have a 7.23 engine running on another system on the network. I didn't want to try to reinstall the old version for fear of destroying my existing data.

I copied the ONCONFIG file into the $INFORMIXDIRin directory on the new server and created a parallel directory structure for the rootdbs alongside the directory holding the rootdbs of the working server, only in a subdirectory with the same name that the broken rootdbs came from. I then used NT drive mapping to map the drives on the old machine to the same drive names on the new machine. When I was finished, the working machine had the ONCONFIG file from the broken machine (the good ONCONFIG was appropriately saved) as well as the identical drive structure and file locations as the broken machine had had. The files were actually the same files as before on the broken machine, only mapped over to the new machine. When I restarted IDS on the nonbroken machine, everything came up properly and I was able to do a dbexport of the broken database. (I know, I should have done it before trying the upgrade, but I was getting complacent.) I was then able to completely rebuild the broken server and reimport the data. I had done something similar to this once before after changing the computer name of an NT machine running an IDS server. Don't ever rename the computer that holds an IDS server. If you do, you will have to reinstall all the software and reconfigure the system. The computer name is imbedded deep inside the Informix system, and changing the name is a major operation. Also, keep the name of the NT machine short and simple (fewer than 8 characters), and don't use a dash anywhere in the name. IDS has problems with this.

Since Informix uses the NT and Windows 95 registry extensively, don't attempt to deinstall Informix products on these platforms without running the uninstall programs that are included with the products. These uninstall programs will clear out the proper registry entries as well as remove icons and menu items from the Windows environment.