General

The nice thing with a complex product they are just so many ways to make it not quite work properly.

Be wary of sysadmins when they are looking for space and you are using raw devices. It is very easy for them to run 'mkfs' on one of your dbspaces.

Don't remove the 't' permission on /tmp, the correct permissions for /tmp are rwxrwxrwt root:sys

Don't bring up IDS with the PDQPRIORITY environment variable set on an OLTP system. Imagine 3000 users all trying to run queries at PDQPRIORITY of 1

Don't comment out PC_POOLSIZE and PC_HASHSIZE config params (ie. bringing 'em down to defaults) if you're using a lot of stored procedures, for example for implementing business logic in database (Java architects, please don't comment on this)

Installation

The nice thing about dumb mistakes when installing the product is that they are normally identified early.

Dont run chown informix:informix * in any Informix subdirectory. Some programs must have root ownership, unless it is a non-root installation

On older releases but make sure you're not in root when you install Informix.

If you are running multiple instances then make sure you don't allocate the same disk twice. If in doubt 'dd' the disk and see what is there.

If you are running multiple instances on the same server the SERVERNUM must be unique. You will see strange startup problems if you don't.

Beware of the -y option on commands, running oninit -ivy is probably not what you meant

If you are using hard disks directly, i.e. no LVM software or hardware in place, then, for some Unixs, you must not use the first cylinder of the drive. Either use an offset via the format command [preferred] or use a chunk offset when creating the dbspace. The first cylinder is re-written when the server is re-started.

Onconfig

The problem with ONCONFIG variables is many of them are so easy to get nearly right, or close enough to wrong for the engine to start but run poorly.

LRUMIN 0 this can dramatically increase the checkpoint times, try 0.0001 instead. If you are using an engine where LRUMIN has to be an integer then use 1 NOT 0.

ALARMPROGRAM: don't set it to /dev/null or a script that you, as the DBA, can't alter. To change the value you will probably will need to bounce the engine, to alter the script you just need permission. If you don't want script to do anything then just 'exit 0' out on the first line.

ALRM_ALL_EVENTS 1 on AIX uses all the available processes fast if you drop to single user mode and have a lot of users, and others

Backup and Restore

Backup errors are always fun because you only discover them when it is way too too late.

Periodically test your backup, it could be a simple archecker, but make sure you are actually writing something to the tape.

If you are doing a restore then write-protect your tapes before you start - how often do you actually type ontape -r, it's easy to autopilot an ontape -s -L0

Most people set the tape devices to /dev/null for installation phase, remember to set it back when the system goes live `

ER and HDR and Failover

Dumb mistakes and ER/HDR are always fun, how often do you get to destroy multiple systems with only one command.

Do not add additional space on the primary without the same space being available on the secondary.

Never run onmode -c block on a primary HDR pair when HDR is not working, onmode -c unblock will not work until it is able to communicate with the secondary!

If you are going to use some sort of failover software then make sure your all your critical files are on dual-attach drives. If you don't then someone at some time will fail to update a critical file on the two systems.