Informix Enterprise Command Center

Beginning with Informix OnLine 7.22, Informix has included the Command Center application with its Windows servers. This is a graphical user interface that allows the DBA to start and stop the database and monitor the status of multiple Informix databases, both NT and UNIX, located across a network. As the product marketing shifted a bit, the name was changed to Informix Enterprise Command Center, and that is the name by which it is currently known.

Command Center also contains an extensive mechanism for generating alerts and other types of notification that are triggered by predefined conditions within the database. When Command Center is first started, the user is given a graphical screen that shows the available servers.

Populating the Informix Neighborhood

The available servers in Command Center must be defined using the wrench (setup) icon of Command Center. These servers are not automatically located, and simply setting up the servers in setnet32 will not make them available in the Informix Neighborhood. Clicking on the wrench icon brings up the following screen.

The Shared Server Definition screen shows one of the more handy aspects of the Windows administration tools, the ability to designate a single system as the master system for containing sqlhosts information. This has always been one of the little arcane things that DBAs have had to do in order to ensure that Informix databases on different machines can talk to one another. With one or two servers, it's no great task, but with tens or hundreds of servers, it becomes a challenge to keep all of their sqlhosts files in sync, especially with systems that are constantly changing.

Since the NT port has effectively done away with the sqlhosts file and has stored this information in the Windows registry, this opens up the capability of sharing this information with other systems on the network. This screen allows the DBA to designate one NT machine as the master source of sqlhosts data. Other systems can use the same registry information simply by choosing the proper machine from the system tree. Now the DBA can make connectivity changes in one place and not have to worry about propagating those changes in other NT systems.

Since UNIX systems do not have the concept of a registry, any Informix databases running on UNIX will continue to need a local sqlhosts file and cannot use this feature.

The Server Administration tab is where the servers are actually defined. This definition must be done from this screen, even if the servers are already listed in the registry from a previous run of setnet32. Clicking the Modify or Add buttons will bring up a screen that allows the DBA to enter information about the server

The systems need to have an entry in the registry for each server and this entry is most often entered using the setnet32 utility. It can be done manually using the Windows program regedit or regedt32 (depending upon Windows version), but doing it manually is somewhat more hazardous than allowing setnet32 to do the work. As in setnet32, the database server name needs to be the name of the Informix server, not the name of the computer itself.

The Server Administration Service needs to be running on any system that is to be controlled by Command Center. Making these connections is somewhat easier with NT systems than with UNIX systems. In order to control a UNIX server with Command Center, the UNIX server needs to have a TCP service such as "srv_agent" running with a defined TCP port, much the same way as the Database Administration Service has always been needed for Informix-to-informix communication. The Database Administration Service is the same service that is listed in the sqlhosts file. The Server Administration Service is new to Informix, and needs to be defined on both UNIX and NT systems. If you need to control UNIX machines with Command Center, contact your Informix representative to obtain the necessary software to establish and run the Server Administration Service on the UNIX machine.

Going back to the initial screen of the Command Center application, drilling down on a particular server will open four folders in the right-hand panel, in which the user can get information about alerts, backup (bar) activity, reports about database status, and session information about the database.

Alerts

Alerts are a new feature with the NT port. UNIX IDS ports have long included the ALARMPROORAM feature which monitored the online.log and allowed the user to set up actions based upon what was happening in the database. The alerts feature is an extension of that concept, with a prettier interface and a more intuitive approach to the whole matter.

Clicking on an active alert reveals another ease-of-use feature of Command Center. Informix has created an alert resolution wizard that walks the DBA through the tasks of responding to an alert. Whereas this may not be terribly impressive to a jaded DBA who knows all of this stuff anyway, it can be a lifesaver to an inexperienced DBA or someone who is filling in while the real DBA is away on vacation.

Just the fact that an alert shows up on a graphical screen is an improvement for the neophyte DBA, who probably would not have identified and corrected the problem until after the fact without the use of Command Center.

Bar Activity

Contrary to what many DBAs may believe, the Bar Activity screen has nothing to do with libations or tall tales. This is the interface with the latest backup, recovery, and logfile archiving program, onbar.

Reports

This screen shows the reports that are available in the Command Center for each server defined. The alert log is a listing of any alerts that have been generated by Command Center. These alerts cover such items as disk full, logfiles full, out of operating system resources, and other system-level problems.

The Customer Information icon contains licensing information and a mechanism for faxing this information directly to Informix Support. The Database Schemas icon creates a schema for a database whose name you select from a window of available databases on the server. The Machine System Information icon shows basic information about the hardware and operating system of the database computer. It also shows memory information and gives a listing of the environmental variables for the computer. The Online System Information runs onstat -c and provides a listing of the $ONCONFIG file. The Online System Log icon shows the contents of the online.log. finally, the Online System Statistics runs an onstat -a against the database.

All seven of these report icons first generate a "save as" screen, with the default filename set to "report.txt." Be sure and change the name to something more meaningful to assure that the output is not overwritten the next time that one of the reports is generated.

All of the reports are pretty simplistic and cannot approach the quality of reports that you can generate by running the dbschema and onstat commands from the command line, with the myriad of options that are available. The most useful aspect of these reports is that it will allow Informix Support to gather decent information about a system even if the DBA is not available. Any of the users could just click on the appropriate icon and generate information that will be helpful in a support call.

Sessions

The Sessions folder gives a subset of the information that is available with the onstat utilities. It shows an icon for every database session, identified by the user name of the user running the session. Clicking on a session icon gives an output similar to the onstat -g sql command, showing the SQL statement that the session has most recently run.

The session information is information that the DBA always seems to need. Quite a bit of a DBA's time is spent trying to track down rogue SQL statements that are either doing sequential scans or taking up too many resources in the system. Often, these statements are embedded in programs written either in ESQL/C or in 4GL, and it is quite often difficult to actually find the statements that are running.

IDS made substantial improvements to the process of identifying these statements with the advent of the onstat -g sql command. While this Sessions screen does not provide the in-depth information that the onstat commands give, it does provide a quick and dirty way for a DBA to identify what is going on. She can then do further research to track down offending statements.

Much of the chapter on optimizing and tuning applications will concentrate on methods of using the SMI tables and the character-based utilities to further ferret out these rogue SQL statements.

Command Center Summary

The Command Center application, while no substitute for understanding the underlying, character-based utilities, does provide ease of use for smaller installations as well as a method of graphically monitoring more complex systems. As usual, there are tradeoffs to the concept of making a database easier to use and understand.

Informix is neither easy to use nor easy to understand. It is a large, complicated product that requires in-depth knowledge to use correctly and safely. Don't let the flashiness and apparent simplicity of the GUIs lull you or your management into believing that this is a simple desktop application. The GUI is a simple desktop application, but the IDS engine is not.

Command Center could potentially allow a naive user to set up and maintain an IDS database. As long as data volumes are small, the user count is low, and system loads are not excessive, an IDS database can be treated almost like a low-end desktop database, with all of the simplicity of operation that such a database entails. With low loads it is not necessary to extract the last bit of performance out of the engine. Tuning and setup errors probably won't be fatal and the system will run, although not at peak performance. A user can perform the basic database administration functions using the GUI without understanding the underlying complexity and without having to learn all of the commands, options, and switches necessary to use the character-based utilities.

The problems will occur when the load gets heavier and it becomes necessary to tune the database in order to extract more performance. Suddenly, the "DBA" who was competent doing the simple things with the GUI will be faced with more complicated decisions. Unless the DBA is trained well enough to appreciate the complexities and subtleties of the engine, the GUI may lull him and his management into believing that he understands something that he really understands only superficially.

This is one of the risks that we face as we move into a Windows-based environment. There is a basic difference between UNIX and NT applications. Windows applications tend to be more "shrink-wrapped" and more user friendly than UNIX applications. If the users and management see the shrink-wrapped GUI running on Windows, there is the risk that they will view the database as a typical PC application, rather than the complex engine that it really is. This expectation has ramifications in how the community views hardware requirements, training requirements, hardware and software costs, personnel costs, and support costs. It's up to the DBA to make sure that the expectations are set correctly and that management understands that this is really a very complex, capable product masquerading as desktop software.