From the Archives: What Self-Management Is (and Isn’t)
This post was originally written by Glenn Paulley and published to sybase.com in June of 2008. Self-management has been a cornerstone of the success of SQL Anywhere, and our ability to simply determine and ‘do the right thing’ given an almost infinite set of operating environments is unmatched in the database world.
Recently I’ve received some questions/criticism about software (DBMS) self-management as a goal, not specifically regarding SQL Anywhere but in more general terms. The argument is that while self-management is a worthwhile vision, it’s a utopia that is unachievable. What’s implied is that because this utopian vision can’t be implemented, any efforts toward self-management aren’t worthwhile. I’m not naive enough to believe that we’ll achieve utopia in my lifetime, but I disagree that efforts towards self-management aren’t worthwhile. I believe that software usability is a big deal, and anything that lessens the administration/configuration effort of a software package is worthwhile. That goal is applicable to any software product, not only database systems. When you think about, self-management within a database management system is primarily about implementing solutions to problems that as an industry we already know how to solve: dynamic buffer pool management, dynamic access plan changes, self-tuning histograms have been studied for years, and the best place in which to make behaviour changes to this functionality is within the database server itself. Histograms are a good example: the server is in the best position to determine the number of buckets necessary for any particular histogram, taking into account the number of values and their distribution. There is no need whatsoever to make the DBA decide this; the level of expertise necessary to make a “good” decision is exceedingly rare. In a nutshell the goal of self-management technology is to achieve superlative performance out-of-the-box, and that is a very worthwhile goal. However, self-management technologies by themselves do not eliminate the need for capacity planning, performance analysis, or problem determination. What self-management does do is permit the DBA to focus on the larger problems, some of which are:
- identifying where to place specific functionality in an end-to-end application: in the client, in a mid-tier, or on the server itself.
- identifying and solving application scalability issues.
- making it significantly easier to conduct capacity planning.
- supporting logical and physical schema design.
- improving application developer productivity.
As an industry, we need to get beyond the nuts-and-bolts of specific self-managing algorithms within the server, and start to look at tools and techniques that address these larger issues.