Typical DBA Job Functions

No matter where the lines are drawn, there are certain functions that need to be part of the overall management of any database system. This list is not comprehensive. Every organization will have its own quirks and peculiarities, but these are the basic items.

Keeping the Database Running

This is the primary function of the database administrator in production environments. Especially in mission-critical applications that run 24 hours a day, 7 days a week (24x7), the database administrator is judged first on system downtime. In some situations, the cost of minutes of downtime can be more than the annual salary of the DBA.

This has become more prevalent as Informix-based systems have been developed for transaction processing systems for banks and retailers. These systems are now appearing more and more in such telecom, credit card processing, and Web-based systems. These systems have to be up all of the time or have failover capability that can transfer their duties over to other machines should they fail. There are application requirements in some cases that permit less than an hour of downtime a year. Companies such as Stratus are producing fault-tolerant systems that are capable of less than 15 minutes downtime a year. Obviously, applications that need such hardware dependability will demand a similar dependability from their database operations, which are often the heart of the application.

In most applications, whether mission critical or not, database downtime impacts just about everyone associated with the database. Order entry personnel, service and help line personnel, data-entry staff, and software developers need to have the database up and running to get any work done.

Downtime is not only when the database is completely down. It is perceived downtime that hurts. If the database is running slowly, no matter what the cause, the effect is just about as bad as if it is not running at all. In fact, when the database is running slowly, it is often even worse than when it is not running at all.

Have you ever waited for an elevator that is running slowly? Chances are, you've pushed the button several times, hoping that repeatedly pushing the button will somehow make the elevator get to you faster. Computer users exhibit the same type of superstitious behavior. They will put jobs in the background, use the UNIX nice command, open additional terminal windows and database jobs, fill their keyboard buffers with useless keystrokes, or hit a series of breaks, all in the hope that something will make the database go faster. Usually this just makes things worse. What started as a slowdown winds up as a crash. Crashes that occur because of this type of load-related problem are often quite difficult to diagnose, especially when they are at the operating system level. Here, the operating system dies and doesn't give Informix the time to log whatever errors or problem it has.

What this means to the DBA is that you must communicate with your users. If the database is slow, let the users know. Believe me, they already know. What you're doing is telling them that you know there's a problem and you're working on it. If it's possible, plan your downtime in advance. Give everyone lots of notice. If you can negotiate scheduled downtime, do so. The users will get used to it and your life will be easier.

Often, the DBA will be the cause of the slowdowns. This you can almost certainly control. If you're using any of the Informix utilities, be aware of their effects on the database. Certain options in tb/oncheck can cause tables to lock. Using tb/onlog on an active logfile can freeze up the database. Know your tools.

If the database does inexplicably freeze up, look first for problems with the checkpoints. This is a common cause of database hangs. Often, a checkpoint may hang while it is blocked by some other system activity. The checkpoint hang may very well be a symptom of some other problem. As an example, a checkpoint that is requested while the tbape archive is waiting for a new tape in an OnLine system will freeze up until the new tape is inserted. Beware of such interactions between programs. Luckily, this type of tape-change freeze-up is no longer a problem in IDS systems, since the system uses internal temporary tables to help avoid the problem.

Training the Users

The user community can make or break the DBA. If the users are knowledgeable about the database, they'll make fewer demands on the DBA and do more for themselves. The DBA will spend less time fighting fires and more time in more constructive activities if he devotes the necessary time to helping the users get up to speed.

Of course, different users have different needs. If most of your users are using "canned" software, meaning that all of their dealings with the database are through well-tested and well-debugged programs, they'll need a lot less training. As long as they don't engage in impatient or superstitious behavior, they will need little database training. Users of such "canned" programs quite often just view it as a "black box" anyway. They don't realize they're dealing with a database. They just deal with screens and keystrokes.

More sophisticated users need more training. When you begin to give users unstructured access through various access tools, there's more that can go wrong. If they use SQL, they need to be schooled in how to compose their queries, especially in how to compose the WHERE clauses. A disjoint query is a query using multiple tables that do not join properly. Rather than restricting the number of rows that the query returns, this type of query often returns a number of rows equal to the product of the number of rows in each table. Thus, a disjoint query on two tables, each with 10 rows, could return 100 rows, which is the Cartesian product of the two tables. Disjoint queries on large tables can quickly overwhelm the database with millions of rows of output. Likewise, queries that join on unindexed tables or that generate unreasonable query plans can take forever to complete. On systems more recent than Version 7, decision support queries can be run that could take a system down to its knees.. The user will often wait for 30 minutes or so, realize that it's taking too long, and then try to kill the job. This often results in long transactions, database rollback, or database crashes if the job is killed incorrectly. This can also leave back-end and front-end processes running, which can eventually overwhelm an operating system If you have these somewhat sophisticated users, get them some training. If you have software developers, try to get them to train the ad hoc users. It'll help both of them.

Software developers are often the most challenging training problem for DBAs. Most often, developers are building highly specialized applications. They'll know much more about the applications than you do. They'll probably know a lot more about the logical database structure than you do. These sophisticated developers can be a valuable resource when it comes to going very deep into the database. Quite often, though, developers will be weak on either extreme of the database. They often know the structure of the data, but many times they know a lot less about the contents of the data than the data-entry people do. On the other end of the spectrum, the developers will know a lot about how individual parts of the database behave, but they'll be weak on how it all fits together.

Development environments such as Visual Basic, PowerBuilder, and Forte further isolate the developer from the database itself. With the emergence of ODBC as a database communication standard, such development environments can work with most or all of the databases in the market. Often, the system being developed will try to work with multiple brands of databases for competitive reasons, and the developer may not even know which database his application runs against.

Often, developers are not aware of the effects of long transactions, logfile use, resource contention, and latch contention. They will code their software until it gives them the results they want. They're usually under such time pressures that they don't spend a lot of time trying to optimize the code. Produce, produce, produce! Of course, these are generalizations. No two users are the same. If you're lucky, you'll have developers who can view the overall picture and create finely crafted code that fits in well with the overall system. If you don't have these kinds of developers, it's the DBA's job to try to create them. If you can, get them to develop some code for you. Teach them about the things you need to monitor and let them work on it for a while. You'll get some good tools as well as a better-trained developer community.

There's nothing better for developers than teaching them how to run and interpret the SET EXPLAIN output. If they know how the optimizer is interpreting their queries, they'll write better queries.

As more and more emphasis is placed on individual development projects that access a single database, it becomes more important to balance the requirements of various classes of user against other users' requirements. The best way to do this is to involve the DBA in the development project from day one.

One successful method of guaranteeing the quality of a development project is to require that the DBA approve all SQL that is coded to run against the database. Developers write and test the code and run SET EXPLAIN and submit the EXPLAIN outputs to the DBA for approval. Bad queries can be caught immediately, and the DBA may see an immediate need for changes in the indexes or fragmentation.. This is a little more complicated when the SQL statements are dynamic, as in coding search screens that allow users to search for an item based on multiple search parameters. Here, the DBA can be of great help to the developer in laying out the search screen. For example, a developer will think twice about allowing someone to search a million-member names database for everyone whose state is "TX" after going over the resultant query plan with the DBA.

What I've found that is so neat about this method is that if you make it part of the development process, it becomes a rule and a habit. Especially with contract developers, it's just another requirement that needs to be met, just another milestone. Of course, I've also heard it called a millstone. Actually, even old-time developers can see the value of this approach if you use it to help them, not to dictate how they write code.

A DBA who is really on the ball would then take this approved SQL and put it in a database for later use in maintenance and troubleshooting. A super DBA would use such a database and a set of benchmark tables to track performance. A super DBA with added points for political style would get the developers to write a frontend that managed the benchmark system as a "training exercise."

Although said partly in jest, this last bit is often possible, especially in larger organizations. If you can't get the services of developers working directly with you, see if anyone offers training in a development environment that can talk to your database. Talk to that trainer and see if you can help develop a course that will eventually develop an in-house system that you need. Everybody benefits, and you get a system that you can use and can't buy anywhere. Then go to the graduates of that course and let them further their skills, on your project, of course.

Another area that developers and system analysts often can use help with is developing a concept of a data life cycle. Often, much attention is paid to getting data into a database, with little or none paid to getting rid of the data when it's out of date. If the developers don't develop plans for archiving and removal of obsolete data, guess who finally gets the job? When you suddenly get to 95 percent capacity, you'll start frantically trying to clean out the junk, and you'll be fighting a hopeless battle. If the software specification calls for creating new data or inserting data into tables, the specification should include a plan for the archival or deletion of old data.

Providing Services to Users

The DBA needs to be seen as a resource person for the users. She needs to be aware of the overall structure of the database system and needs to know how the parts fit together. Often, the DBA tends to inherit the job of documenting the database, especially if the organization has been somewhat lax in documentation in the past. Users need to know the structure of the tables and indexes, where source code is located, which utilities are available, and which scripts have been written to make their jobs easier.

If your organization uses a 3GL language such as INFORMIX®-ESQL/C, the DBA will often be the resource person who helps the developers when their programs don't compile. Hint: Look first at their makefiles.

It's usually good procedure to prohibit all but a few of the more sophisticated users from ever killing an SQL job or backend on earlier Version 5 systems. As this is a major cause of system crashes, it's usually better to let the DBA be the "executioner" of runaway jobs. On Versions 7 and up, the fan-in/fan-out architecture means that various virtual processors (VPs) may be performing tasks for a query, and nobody kills the oninits. The only way to kill the process is to use an onmode command. This should restricted as much as possible to DBAs and other qualified users.

The DBA should also be available to help developers interpret sqlexplain.out files to help them tune their queries. Here, the DBA needs to understand in detail the operations of the optimizer.

Often, the DBA needs to be the person who grants access and privileges in the database. Along with this comes the job of providing the correct environmental variables to access the database and to compile ESQL/C code. The DBA often needs to be able to provide synonyms and aliases for the user. It's better if the DBA and system administrator cooperate in this area and that they have scripts or other programs designed for the task. This task is made more complex if the system utilizes a distributed database across a network. Here, the DBA and system administrator need to ensure that all of the above items occur, not only on one computer system, but on many.

Another DBA service consists of setting up database connections from various client machines into the network. This is always in great demand in larger organizations, especially those that tend to use their databases a lot. This is pretty much "cookie cutter" stuff, in that establishing connectivity to Informix is usually just a matter of properly setting up the Informix client-side applications. Since these are usually operating system specific, you need to know only the connectivity quirks of each of the operating systems on your network. Setting up one Windows NT workstation is usually exactly like setting up another NT workstation. It gets more complicated with systems using Open Database Connectivity (ODBC) to communicate between clients and server. Again, once you've done it once, the rest is "cookie cutter". Usually, it's a bit complicated for users, but it's a perfect task for a trainee DBA.

Disaster Recovery

System crashes are an unfortunate fact of life for all those who deal with computer systems. No matter how fault tolerant the system is, no matter how good the database is, no matter how good the DBA plans, the system will crash. Take that as a given. If you're lucky it will be recoverable. If you're unlucky, your entire computer center will disappear into a hole in the earth some night. Even worse, you may want your entire computer center to disappear.

We're all subject to the "it can't happen here" syndrome, which says that all bad things happen to someone else. Next time you see a disaster scene on the news, look around and you'll probably find someone's computer system at the bottom of one of the piles of rubble. What would you do if it were yours?

That's the worst of the disaster recovery scenarios. Your more common occurrences will usually be of a less catastrophic nature, simple things like disk errors, hardware failures, and user errors. If you plan for the end-of-the-world scenarios, you'll always be able to handle the simple problems.

Your disaster recovery plan needs to begin with the simple recovery of the database. Usually this means setting up and following a plan for periodic archives of the database. Regular archives, combined with database logging, can be an almost foolproof means of recovering from just about all kinds of errors. The only drawback is the time needed for performing the archives and the time necessary to recover the system from the archives. Crashes are usually chaotic times, and a well-practiced plan is a necessity. This is not the right time to begin reading up on database recovery in the manual!

Although archives and logs will suffice most of the time, you need to keep the catastrophic situation in the back of your mind. Disaster recovery entails recovering from a partial or complete destruction of everything in your computer room. Look at your backup tapes right now. Where are they? If they're sitting on top of the computer in the computer room, the airliner that crashes into your computer center will probably take them out, too. What about communications? What'11 you do if the phones are down? Or the power? Where are the telephone numbers of your critical staff members? In the computer?

Disaster recovery is often not just a matter of recovery of the database. Many systems create supporting or work files that need to be kept in sync with the database. Any disaster recovery plan has to be sure that these files are also recoverable.

Devising a good disaster recovery plan is an exercise in paranoia. You need to think about these things. Imagine your computer center in the middle of that hole in the ground that used to be an airliner. It may not be practical to devise contingencies that will cover the end of life on earth as we know it, but you'll be surprised how some simple precautions can let you sleep better at night.

Planning for the Future

The DBA is often the person in the organization who has the broadest view of the data management function. Individual developers and project leaders usually view a piece of the overall application, but the DBA's viewpoint must be more global and wide ranging. The DBA must maintain this global view and must participate in planning how to best meet the organization's data management needs.

This planning function is often pretty far down the DBA's list of priorities. The DBA can get into a firefighting mode in which it seems that 90 percent of her time is spent handling emergencies. This is probably due to someone's failure to plan adequately. While fire-fighting is usually the most visible and often the most exciting part of the DBA's functions, the ideal situation is to avoid the fires.

The DBA needs to participate in planning for such items as hardware and software upgrades, maintenance schedules, facilities management, communications capabilities, and project plans. If the enterprise is of any size at all, most of this planning will be the responsibility of someone else. Even so, the DBA must represent the realities of the database to those who are doing the planning. Failure to do so will result in unworkable plans, unreasonable expectations, and much frustration down the line.

The DBA should also take the lead in planning for the integration of new products and tools. As more third-party tools become available that work with the Informix family of products, the DBA has a wider range of options. It also means that the DBA must be able to support various development environments and tools.

Many of these are graphical tools that allow users to compose their own queries, build their own forms, and write their own reports. These tools can provide a mixed blessing to the DBA. On the one hand, they allow the DBA to shift some of the development out of the MIS department and into the hands of the users. Balancing this benefit is the risk of allowing inexperienced users access to the database.

The DBA needs to assist in plotting a course that will allow these new classes of tools to fit into the existing IS structure. The DBA's perspective is crucial in ensuring that such areas as database security, resource monitoring and controls, and data validity are considered in the integration of new tools.

Tuning the Database

Monitoring and improvement of database system performance are a constant part of the DBA job function. Although we are classifying this as "tuning the database," the function really encompasses:

• Tuning the hardware

• Tuning the operating system

• Tuning the database engine

• Designing the database schema

• Tuning the application, and

• Monitoring daily operations

Of these, tuning of the hardware and operating system is usually considered to be the system administrator's bailiwick. These two functions, though, are absolutely critical if we are to wring the best performance out of the entire system. The DBA should endeavor to become familiar with tuning the UNIX operating system and with the parameters that can affect the speed of the operating system. Of particular interest from the hardware and operating system viewpoints are:

• Disk layout

• Disk striping

• Single versus multiple processors

• Shared memory parameters

• Other resource limitations in the kernel

The same types of issues will arise between the DBA and the NT system administrators for NT-based systems. Often, they will be complicated to some degree by differences between UNIX security and NT security.

Tuning the database engine is usually the sole responsibility of the DBA. If not, it should be. The DBA should be the one point of contact for any parameter changes to the OnLine system. The DBA is constantly monitoring system performance and tweaking the parameters until the system is matched well to the types of tasks it is asked to perform.

The DBA should also be responsible for maintaining the structure and layout of the tables. Although system analysts and developers most often specify the tables and structure, the DBA needs to be the person who actually creates the tables and indexes. If the DBA is attempting to create and maintain an enterprise-wide data dictionary, this is even more important, as the data dictionary needs to know about new tables and indexes.

Maintenance of indexes is a large part of the overall performance of the database system. You will find that most of the time, performance problems can be traced back to improper indexing.

Running a close second to poor indexing as a performance bugaboo is inefficient application design. Often, the queries can be made much more efficient by analyzing them with SET EXPLAIN. It is sometimes advisable to restructure the application to access its data in a completely different way, especially if the old way requires unindexed scans of large tables. There are some types of queries, such as correlated subqueries, that are inherently inefficient. Sometimes it is possible to significantly speed up SQL statements by using temporary tables to force the optimizer to evaluate the SQL statement in a preferred manner.

A final part of the speed enhancement function calls for the DBA to monitor and correct resource hogging and other disruptive activities of the users. The DBA should be alert for instances in which users create disjoint queries or engage in excessive locking or long transactions. Most often, the user is not even aware that his activities are a problem to others. Usually all that the DBA has to do is point out the problem and make the user understand why his activities are causing a problem. Users who continue to create problems usually need a little more prodding.

Maintaining Security

The data in a firm's computer system is often one of the most valuable of the company's assets. Among other things, the database often contains:

• Customer information

• Marketing information

• Vendor information

• Accounting and credit information

• Mailing lists

• Planning data

• Product information

• Source code

• Personnel and salary information

A good way to visualize the value of your database data is to imagine it placed in the hands of your company's biggest competitor. If this thought scares you, your data is probably worth protecting.

Security administration consists of protecting the data from loss and misuse. Your logging and archive plans probably handle the loss contingency, but how well are you protected from theft or misuse? Most databases are being backed up onto DAT, DLT, or other high-capacity tapes. One of these tapes can hold up to 50 gigabytes of data. This means thatsomeone could walk out of your computer room with all of your company's critical data in a shirt pocket.

If your system has connections to the outside world, either through modems, LANs, WANs, or Internet, you have potential security problems. The primary defense against security breaches is your operating system. This is analogous to locking your front door. Once this security is in place, the database itself must be made secure. By granting and limiting access using the GRANT command in SQL, you can further limit data that can be accessed by someone who gets into the operating system.

The primary purpose of the Informix security is provide secure access within an organization. The standard example is salary information. This information is sensitive and is usually available only to a few users. Since Informix SQL allows a table's owner to grant privileges on a table by column, it is possible to restrict access to certain columns for certain users. You can also use views to allow certain users to access only part of the data. Views, which are essentially "canned" queries, can be created by either DBAs or users and look just like tables to the users. In most instances, the user never realizes that he is dealing with data from multiple tables. By creating a view, the DBA has made details of the table layout irrelevant to the user.

An example of using a view to restrict access to certain information often arises when it is necessary for someone to only be able to view a subset of a table:

   create table salary (name char(30), dept char(5),
   salary int);
   create view dp_salary as select * from salary where
   dept="DP" ;

The manager of the data processing department could be granted select privileges on the view dp_salary and be able to view his own employees' salaries, but no others. (Of course, the DP people probably have total access to the system anyway, so you really can't keep anything secret from them!)

Interfacing with your Peers

In any organization in which the DBA is not in total control of the entire computer system (all but the absolutely smallest applications), the DBA will have to work with and become interdependent with other professionals. As the organization becomes larger and more complex, the job functions often become narrower and more specific.

In a small operation, the DBA is often the UNIX system administrator, the development staff, the technician, and the troubleshooter. As the organization gets larger and more complicated, the DBA is forced to wear fewer hats. In the largest organizations, the DBA may be part of a team of DBAs. These DBAs may have their duties divided by function or divided by systems. In these larger organizations, it becomes more important that the DBA communicate and cooperate with many other professionals. The following list is not exclusive, but it includes the major players in the DBA's professional life.

The System Administrator

Both the UNIX and NT system administrator can be a tremendously valuable resources to the DBA. He can be a source of information about the inner workings of the computer system and can help guide the DBA around potential problems and pitfalls. Especially in areas of initial database setup and subsequent performance tuning, the system administrator can be a lifesaver. Often, the only person who really understands the file system and the raw devices is the system administrator. As you begin to design the disk layouts and to make decisions about striping and mirroring of the Informix database chunks and devices, you'll begin to appreciate the value of a good system administrator. If your initial installation requires UNIX kernel modifications, you'll probably have to have the system administrator do it. System administrators are usually quite protective of such things as kernel configuration.

The system administrator is usually conversant with the performance monitoring and tuning tools available with your flavor of the operating system. As you begin to tune for maximum performance, you'll need to be able to differentiate between performance problems at the operating system level and at the Informix level.

The system administrator will often be your best reference for items regarding communications and network protocols. These items can severely harm system performance if they are set up badly, and they're difficult to debug.

Get on and stay on good terms with your system administrator. One good way to work is to cross train with him or her. Let the system administrator learn enough about the database to serve as a backup DBA. Likewise, learn enough about the operating system to be able to serve as a backup system administrator. Together you'll be able to solve problems that neither of you could tackle alone.

Computer Operators

If your organization is large enough to need and afford operators for your computer systems, these people can make your job much easier. Set up well-documented written procedures for such day-to-day activities as doing database archives and handling logging tapes. Give them simple, user-oriented menus for the operational tasks that they can do. You'll appreciate having an operator available when you have a logfile or an archive problem at 3:00 in the morning. It's much easier on the DBA if she can call into an operations center and walk someone through a fix instead of driving into the office.

Operators should know how to start and stop the database, how to start and stop applications, how to handle the archives and logs, and how to detect problems with the system. One of the most important things they need to know is when to call the DBA. It is important to set some guidelines and to make sure everyone knows when the problems need to be escalated to the DBA's attention.

Informix Support

Informix support policies change, so anything you read here may or may not still be in effect, but the general features remain the same.

If you can get access to the Internet or to the USENET UNIX newsgroups, look into becoming a regular on the comp.databases.informix newsgroup. If you don't have access, there are several options for getting Internet access. Check with your system administrator or local UNIX gurus. Someone will probably know the best deal in your area. Questions or problems posted to comp.databases.informix often get multiple responses with detailed solutions, frequently containing programs or code fragments.

Your primary source of "real person" Informix support will probably be the support 800 number. As support hotlines go, this one is pretty decent. You'll get a voice mail application that will walk you through to a real live person. You'll need your software serial number. It's probably a good idea for the DBA to have the Informix serial numbers tattooed on his arm. They'll get a lot of use. One thing about the hotline that is not immediately obvious is that there's a 911 feature. On dialing in, immediately punch 911 and you'll get to a support person quickly. Informix wants you to use this in emergencies only. They define an emergency as a production system down or seriously impaired. Use some discretion in taking this option. Don't cry "wolf" unless you really have an emergency.

Assuming that you're not taking the 911 option, you'll probably get a support person whose job is to log your call and put you in a queue to talk to another support person. When they give you a problem number, be sure and write it down. It'll make it much easier to follow up later. If you're lucky, you'll get to a technical support person on this call. If not, the technical support person will call you back. At some point in the process, you will probably be requested to rate the severity of your problem. If your system is down or seriously impaired, let the support person know it. The more serious problems are placed at the top of the queue. Don't be shy about requesting faster response or special services. Just about everyone in the support system has the ability to escalate your problem to a higher level. It doesn't hurt to ask, but be nice about it. You will be dealing with these people again. If worse comes to worst, ask to speak to a manager. You'll always have the option to do this.

Your first technical contact may or may not be tremendously helpful. Their usual response is to read sections of the manual to you. These people usually don't have access to the source code and pretty much have to follow the "company line." They do, however, have access to the complete Informix bugs database. If your problem has shown up before, they may have a quick solution for you. It's a good idea to prepare before talking to these first-line technical folks. Think about how you think Informix would classify your problem. The support staff will be looking up keywords in the database. Give them several options. You'll have a better chance of getting an answer. In any questionable situation, they'll often recommend that you either reinstall or restore from your archive tape. If you're not pleased with this, don't be afraid to ask to speak to a manager or to escalate the problem to a higher level.

Your Informix Account Representative

The salespeople who handle your Informix account can be valuable resources as well. They will have access to local technical personnel who can help you solve problems with your systems. Salespeople have a much greater vested interested in keeping you happy as a user, and thus will often knock themselves out to help you out of a problem. If your account is of any significant size, they'll be able to provide evaluation copies of new software in the hope that you'll buy a ton of them. If you have temporary needs for software, such as special tools for conversion, they can often provide "loaner" software to help you out of a bind. Just remember how helpful they were when it comes time to write up purchase orders.

Hardware and Operating System Vendors

These are an often-neglected source of help for Informix-related solutions. Many vendors have close relationships with database vendors such as Informix. If your hardware or operating system vendor has such a relationship, and if you know how to get to the proper people, they can often be the best source of solutions to problems. Inquire about their other installations running Informix. Even if you're a small operation, your vendor may have other, larger accounts running Informix on the same hardware. Piggyback on top of the big guys. It doesn't hurt to check.

Users' Groups

If you have a local Informix users' group, by all means get involved with it. You can usually find out about users' groups through your Informix account reps. If they don't know, check out the users' group sections at http://www.iiug.com. If you can't find a local users group, consider starting one. If you live in an area with many Informix users, this can become a most valuable resource. A users' group is a great tool for networking and providing mutual support and assistance with problems. It's a good source of information on new techniques and new products. It's also a good way to keep your eyes on the Informix job market, whether you're looking for another position for yourself or whether you're looking to hire someone. Don't be too blatant about soliciting employees or employers at users' groups. It's not considered good form to come in and try to hire everyone in sight!

Internet and the General User Community

One of the major untapped resources out there is the collective knowledge of the 60 million or so Internet users. For those of you who are not familiar with the Internet, it is a network of thousands of computer systems tied together with communication lines. The Internet originated as a resource connecting academic and research institutions. As it expanded, it included military, government, and commercial interests. Up until the late 1980's, access to Internet was more or less restricted to those who had access through one of these member sites.

The Internet has now expanded into a more business and commercial role. This vast infrastructure is being opened to businesses and to private individuals as part of the "Information Superhighway" concept. Many of the online services such as America Online®, and NetCom® are offering inexpensive connections to the Internet without your having to go through the time, effort, and expense of actually connecting your computer systems to the network. For most of the reference tasks you'll be needing, this dial-up Internet access will be enough.

One of the best informal sources of Informix information is the World Wide Web. Informix's corporate site at http://www..informix.com is a tremendous resource for the Informix junkie, as is the Web site of the International Informix Users Group. This user group site is http://www.iiug.org. The users group Website includes an archive of public domain software plus links to various Informix resources across the net. This is also the home of the Informix FAQ, or "frequently asked questions," which is a hypertext version of the most asked questions in the newsgroup, comp.databases.informix.

One of the big draws of the Internet is access to more than 20,000 newsgroups that are part of the USENET news facility. These newsgroups are essentially bulletin board systems that cater to specific interests. Many of the newsgroups are exercises in anarchy or attempts to see how far the users can push the bounds of bad taste. Ignore them. If you look hard enough, you'll find plenty of hard, useful data.

Most browsers such as Netscape® and Microsoft Internet Explorer® have the capability of accessing newsgroups. If you don't have a news feed into your internet service provider (ISP), you can access newsgroups by using Web-based news servers such as http://www.dejanews.com.

Among the most valuable newsgroups to the Informix DBA is the comp.databases.informix newsgroup. You'll find discussions of new and old products, bug reports, workarounds, theoretical discussions, and much peer-to-peer interaction in this newsgroup. No matter what kind of problem or question you have, you can post it to this newsgroup and probably have three or four answers to it within the next day or two. You'll find many Informix employees active in the group, and they are almost all helpful. For the DBA, access to this newsgroup is reason enough to invest the time and energy needed in setting up an Internet connection.

Whenever you connect to the comp.databases.informix newsgroup, one of the first documents you need to locate is informix.faq. This file is the frequently asked questions file. This is a common service that is found in newsgroups on USENET. Reading the FAQ file in a newsgroup will give you a feeling for the types of information that is available in the newsgroup and will help you become familiar with the customs and proce-dures of the group. The Informix.faq file contains many helpful hints for setting up, maintaining, and troubleshooting your OnLine system.