Cover V08, I07
Article

jul99.tar


syslog

When we were developing the 1999 editorial calendar last year, it was not without trepidation that we added database to our usual mix. There are, after all, plenty of database-related publications that handle the topic every month. Those publications, however, are usually looking at database issues from the perspective of the DBA or DBMS-centric application developer. Because we run the systems that run their databases, which, in turn, drive the applications, it is appropriate for us to look at this slice of the SA world from time to time. Although database-related systems administration issues can be divided into several categories, it may be most helpful to consider everything as a matter of tuning.

On one hand, you may be concerned with tweaking the system's hardware and OS to best support the nature of operation of a particular database. That might entail adjusting the tunable parameters within the OS to balance the available system resources, or adding actual hardware. For example, adding storage capacity so you can spread the disk I/O across multiple SCSI channels may improve the performance of the database. To make the best use of the additional disk resource, however, you need to understand the internal structure of the database application and how people actually use it.

Armed with actual usage statistics, you can allocate system resources appropriately, perhaps putting relatively small, but heavily used tables on their own partition and channel. Or, after doing your research, you may decide that reducing I/O latency to an absolute minimum for these heavily used files is the way to go, and add Solid State Disk (SSD) devices. Once the exclusive option of the best-funded of database operations, SSD is experiencing a rebirth. The erosion of memory prices may not make the chip manufacturers happy, but that economic reality has certainly made SSD far more affordable and opened the technology to new and interesting uses. You might apply an SSD to a non-database task, for example, as a means of freeing other resources to improve system response times for the database. SSD products are available from a variety of vendors, and units from Imperial Technologies, Quantum, and Solid Data are among the most interesting.

On the other hand, tuning interpersonal communication channels may be where you need to concentrate your efforts. If your organization is large enough to have one or more dedicated database administrators (DBAs), it is quite likely that they report into a different line of management than you. As a result, the level of communication and cross-departmental cooperation may not be as effective as it should be. By their very nature, SAs and DBAs know the importance of communication and cooperation, but the pressure of operational priorities may have dulled that awareness. Occasionally, the biggest step toward improving database operation may be a meeting in which the SA and DBA staffs put their respective awarenesses on the table and polish them. Neither side of the table needs to know all of the details of performing the others' tasks, but they need to understand enough about the other job to know when their own procedures may be having an adverse effect on the other.

As systems administrators, we should take the initiative in improving the way our systems support database operations. We may not be the center around which the universe revolves, but it's our job to keep chaos in order there.

Sincerely yours,
Ralph Barker