Re: Care and feeding of OnLine

Okay, I was hoping that by being vague, I would get a wider range of responses. I see now, though, that I was too vague. I'll try again to get the ball rolling. What my client-oriented customer is looking for is some simple steps they can perform to keep their OnLine databases happy. They do have some access to DBAs (myself included...). But, in the past, we've only been called in after things have gone to hell. For example, once upon a time, they had problems creating backups. This didn't bother them enough to ask anyone until they lost their database. That's when they called me and expected me to pull a backup out of my... well, out of thin air. Off the top of my head, here are some of the steps I'm thinking of giving them. Daily 1. Check to make sure the archive was successful. 2. Use "onstat -g ses" to look for orphan/zombie clients. Use "onmode -z <id>" to clean them up. (Yes, I know this can be automated. I'm just giving examples, remember?) 3. Keep an eye on the "ontape -c" console. If the log tape fills, be sure to change tapes. (BTW, has everyone noticed the new ALARMPROGRAM feature which can be used to broadcast messages when this happens?) Weekly 1. Examine the contents of the $INFORMIXDIR/online.log file. Look for long transaction errors, bad page messages, etc. Call a DBA if anything looks odd. 2. Use "onstat -d" to check disk space usage. Contact a DBA if space is beginning to run low. Monthly 1. Run a report to check for tables which have a high number of extents. Use "alter index to cluster..." or contact a DBA to look at the situation. As for those of you who have offered training, products, etc., thank you. However, they are not asking for this guide out of a lack of support. The customer is, in fact, a good sized government agency that has access to plenty of free training. They just don't want to bother. They even have DBAs-in-training on-site, but they work for a competing group. All this customer wants is a checklist/guide which will help them keep OnLine humming and warn them when they may need a DBA. (Actually, warn them before they need a DBA; I'm tired of arriving too late!) I've gotten notes from several people interested in the outcome of this discussion, so let's go! What kinda tricks do you use to keep things going? --Craig (craig@chemistry.utah.edu)