Each of these parameters can be manually adjusted to reflect specific conditions that exist at specific sites. This customization is achieved by changing the Output Range Values and the polling times. For example, a transaction-oriented system could be customized to stop polling in the evenings when batch reporting occurs.

It is important to note that Patrol measures system-wide statistics, and not just the behaviors of each database on the host. Patrol currently supports Unix-level measurement on Bull, DC-OSX, DG, HP, SCO, Sequent, SGI, Solaris, Sun4, and SVR4. With the Unix knowledge module, a system administrator would be able to use Patrol to measure “swap” memory usage, paging within the Unix buffer cache, and just about every possible kernel component. Unfortunately, Patrol does not offer a “recovery” section for the Unix component. It may assume that system administrators would be offended by a tool that suggests possible remedies for the problems.

Customized events can also be incorporated into Patrol’s knowledge modules. A customized event might be a backup process that is run every Tuesday morning at 1:00 AM. Patrol can be customized to check for the successful completion of the backup, and trigger an alert if a problem is encountered.

Patrol Reports

Patrol comes with a set of menu options that allows the manager to view salient information about the system. One interesting menu option is Patrol’s “CPU Hog Percentage” and “all Problem users,” which can be programmed to detect and alert for runaway processes on the host. For example, any process that consumes more than 30 percent of the overall CPU may be a runaway process, and Patrol can be programmed to detect these conditions (see Figure 11.7).

Figure 11.7  A Patrol Oracle report.

Overall, the report facility of Patrol is very robust and comprehensive, replacing the need to have additional database reports for all but the most specific queries.

Patrol Exception Handling

Patrol also provides preset automated recovery actions. For example, the Oracle component allows Patrol to automatically resize a table’s NEXT EXTENT SIZE, thereby averting a possible downtime. To illustrate this feature, assume a customer table that has been defined to grow in chunks of five megabytes (for example, NEXT=5MB). If the tablespace that contained the table only had 3MB available, Patrol would automatically downsize the table to NEXT=3M, allowing the table to extend one more time and buying time for the DBA to be notified. In this way, the DBA can add a data file to the tablespace without disruption of the system (see Figure 11.8).

Figure 11.8  A Patrol recovery action.

Patrol offers extensions into its base system using a proprietary language called Patrol Script Language (PSL). PSL is used to extend upon the base functionality of the software and automatically handle sophisticated recovery, where numerous conditions must be checked. Internally, PSL is a large library of more than 100 prewritten functions. These functions, in turn, are called from within a small framework of 10 commands. The functions also include calls to SNMP modules for interfacing with other SNMP-compliant tools.

In short, Patrol offers a very robust and comprehensive system and database monitoring tool. Like any powerful monitor, Patrol is not plug-and-play—it requires a significant investment in up-front customization. However, once the framework is in place, Patrol delivers its promise to continually monitor, alert, and correct problems. The result? The elimination of many tedious and time-consuming chores for the systems and DBA staffs.

Summary

Now that we have investigated database performance monitoring techniques, we can wrap up the text with a look at the future of relational database tuning, with a focus on object orientation, and a discussion about how objects will change the way that databases are implemented and tuned.