I’d rather play golf

When I started at Great-West Life more than 20 years ago, Sybase had just been spun-off out of UC Berkeley, Oracle was primarily a toy database on UNIX systems (and Oracle’s MSDOS port was, well, simply inadequate) and IBM’s IMS database system made the world go round, DB2 version 1.0 just having been released.

Being a DBA in those days involved a lot of tedious administration tasks, particularly if you were constrained by using (only) IBM IMS administrative utility programs. I’ve done my share of PSB maintenance, generated MFS forms, composed JCL to run the image copy, reorganization, and reload utilities. I’ve done physical schema design with HISAM, HDAM, and HIDAM database formats, monitored IMS/TM system performance with respect to OS priority, page size and buffer pool size, and I’ve also done my share of disaster recovery by physically editing IMS VSAM datasets to correct physical database records and get the databases online again.

Those were the days. Being a DBA was a highly specialized position because database systems were not in widespread use. The technology, though complex for its day, was still simple enough that one could get your head around it.

Today, all that has changed. Relational database systems are ubiquitous, available on every sort of hardware platform from the largest mainframe or server-class machines to PDAs and cell phones. Corporations routinely employ tens, if not hundreds, of relational databases across a variety of servers on a selection of hardware platforms. But not only has the number of database instances exploded in that time, database software itself has become tremendously more complex: a glance at the thickness of the 10-part ANSI SQL standard, compared to the ISO 1989 SQL standard, should serve to convince you of the complexity explosion that has taken place in virtually all commercial products. On top of that, many application architectures utilize multi-tier, distributed database systems with bi-directional replication over hundreds if not thousands of remote devices.

And what of the DBA in this environment? With the vast majority of systems, the underlying technology today is different (hierarchical versus relational data models) but the role of the DBA has remained virtually unchanged. Today, with many commercial relational database products, the DBA remains responsible for such low-level tuning details as the number of buckets to specify for a column histogram – how would one know? – and remains responsible for overnight database tuning, backup and reorganization, ensuring that the system is back up and running at 7am.

Frankly, at 7am I’d much rather be on the 1st tee at Conestoga Country Club with my friends Dan and Roger, trying to get in 9 holes before work. I think most DBAs feel the same.

That’s why I’ve named my blog “I’d rather play golf”. Database self-management technology not only exists in products such as SQL Anywhere, it is robust enough for the vast majority of applications and permits DBAs to focus on value-added services to application developers rather than hour-by-hour, day-by-day care and feeding of a production system.

In this blog I plan to illustrate existing self-management and self-tuning trends and technologies in relational database systems, and describe the details of their implementations in SQL Anywhere, including descriptions and background of various internal functions and administrative tools.