Informix DBA Survival Guide

Read an Excerpt

PREFACE: FOREWORD to the Second Edition

It's really interesting the way a book comes together. I started this project as a completely new book, to be called The INFORMIX Debugger's Survival Guide. After about six months of work, I had only about 150 pages completed and was at a total loss for more material. I could have thrown in a lot of technical mumbo-jumbo, code listings, and the like, but it would have just been filler and would have been incredibly boring to write and probably even more boring to read. That's when I decided to incorporate the debugging manuscript into the second edition of the DBA Survival Guide.

The first edition was written for Version 5. At the time I didn't feel comfortable enough with Version 7 to write about it, and it took me a couple of years to convince myself that I finally understood the new products enough to write about them. In the meantime, Carlton Doe came out with his excellent Informix Press book, INFORMIX-OnLine Dynamic Server Handbook. I recommend Carlton's book highly and intend to "borrow" from it liberally. Some of you may be asking, "What happened to Version 6?" Like the rest of the Informix community, I think that we'd all be better off forgetting that V6 ever existed. It was the first attempt at multithreading and was quickly replaced by V7. Rest in peace.

When I wrote the first edition, I agonized over the inclusion of what I call "soft" material. This includes such things as the political elements of being a database administrator (DBA), how to deal with things other than computer code, and tricks and tips for maintaining some level of sanity while being a DBA. I wondered whether these itemsbelonged in a technical book. My readers answered that question for me. By far, the most satisfying reviews I received touted the "soft" material. Maybe we're not such computer geeks after all and actually have such things as a sense of humor. My absolute favorite review praised the book's "breezy, blue-collar writing style." For months afterward I signed my Internet postings Joe "Bubba" Lumbley.

After making the decision to abandon the debugging book, the proper way to write a book on debugging was dropped into my lap from a most unexpected source. I had been having trouble with the fuel injection system of my Isuzu Trooper and went to my local auto supply store to buy a motor manual to try to trace down the problem. I've been buying such motor manuals since I was 14 and working on my first Mini Cooper. You know what motor manuals are like. Mine are always covered with grease and grime. You can tell the history of the car problems I've had just by finding the pages with the most grease. With my old Mini, you could just barely see the print in the electrical troubleshooting sections because of all the grease. The carburetion section of my Alfa Romeo manuals are even worse because of the addition of dog-eared pages, margin notes, and lots of big question marks.

Motor manuals are great tools for their intended jobs. They have numbered instruction steps, troubleshooting flowcharts, and plenty of pictures, diagrams, and wiring charts. They're the perfect thing to have when your whole body is crammed into the engine compartment and you have to have that sucker fixed by the end of the day. You're not looking for somebody's master's thesis; what you want is a simple outline that leads you through the process of solving your problem.

Like a lot of other DBAs I've been somewhat resistant to this type of approach. I think I developed a case of "white lab coat syndrome," the same malady that isolated early mainframes into glass houses tended by a cadre of white-coated acolytes who spoke their own language and had special knowledge restricted to their priesthood. While I never went so far as to create a DBA secret handshake, I have been known to assert that "this is DBA stuff and I can't explain it to you in words of fewer than three syllables." Gotta justify that salary, right? I've come to realize that what we really need is a motor manual for the Informix engine, and I'm trying to restructure this book to meet that need. I'll give you the bare minimum of theory and as much greasy, hands-on techniques as I can. Since I'm having to write this thing, I'll also try to make it fun for me to write, so I'll throw in enough snide comments, semi-off-color humor, and lousy puns to keep it interesting, provided I can slip them by my editors and technical proofreaders.

Being essentially a lazy writer, I've had to struggle to figure out how to gracefully marry the first book's material with the new material without having to totally rewrite the original. While the Version 7 engine is much more complicated and complex than the Version 5 engine, it is very much a superset of the earlier Version 5. That is, most of the material that specifically addressed Version 5 is also applicable to Version 7. As I go through the original material, I'll point out those few instances where Version 5 techniques do not apply to Version 7, and I'll include separate sections for the Version 7 specific material. I had actually considered putting the new material into a distinctive font or printing it in red, but it seemed a little bit too biblical for my style. However, I will try to identify any of the items that apply to Version 7 but not to Version 5.

I'd like to thank several people who have been instrumental in the development of this book. A book is never a solo project, and I have received help from numerous people. First of all, my original acquisitions editor at Prentice Hall, Mark Taub, was instrumental in convincing me to get started on a revision project. I wouldn't have even started on this revision without his enthusiastic support. Mark left for another position at Prentice Hall after this book went into production and I wish him all the best. Many thanks to my new editor, Miles Williams, who has helped me work through the details of producing this book. Thanks to Kerry Reardon, whose thoughtful proofreading has caused me to reopen my freshman English books more than once. Thanks to Anne Trowbridge at Prentice Hall for her efforts in coordinating the production of this book.

Special thanks go to Lester Knutsen, who graciously allowed me to use a paper of his as my chapter on the System Monitoring Tables. He also provided many of the SMI scripts that are included on the CD-ROM. I want to thank Art Kagel for his assistance in proofreading this document and correcting my many fact and conceptual errors. Thanks to David Williams, who gave me permission to use the Frequently Asked Questions (FAQ) file for the USENET newsgroup, comp.databases.informix.

While on the topic of comp.databases.informix, I'd like to thank all of the inhabitants of newsgroup for their patience with some of my technical questions and for the many good ideas that they gave me in their postings. This newsgroup is truly one of the great Informix resources available to Informix users.

Thanks to another Informix Press author, Carleton Doe, for his modifications to some of the first edition's scripts and for the many good ideas that his book has given me.

The final set of thanks has to go to my wife Jayne and my daughter Katherine, who put up with this project for almost a year. I want to give them special thanks for not having me institutionalized when I started talking about doing a third book just a few weeks ago.

Read More