The Future of Database Tuning and Database Administration
Let’s deviate from our technical topics for a blog or two. As database administrators, it is important for us to know what educational topics we should be spending our most precious resource on. That resource is our time. When it comes to tuning education, what should we be learning? Where should we be spending our time? Is it how Oracle shifts bits and bytes around in hash join processing or is it attempting to have a thorough understanding of the tools and advisors that are becoming increasingly prevalent in each new release of the Oracle product’?
We should all know by now that the preferred administration and tuning tool of choice is either GRID or its standalone counterpart, the Database Console. The advanced alerting, monitoring and administration features make these tools invaluable to Oracle DBAs. The advanced performance monitoring and analysis features should also make them your number one tool for performance problem determination.
The future of Oracle database tuning will be administrators interpreting and implementing the recommendations generated by the intelligent advisors and ADDM. It is a foregone conclusion that Oracle will continue to improve upon their performance monitoring and analysis toolsets. Self tuning features are no longer options that are “nice to have”, they are requirements for Oracle’s competitive survival. Microsoft SQL Server is continuing to scale, moving into areas that were once dominated by UNIX big-iron machines running Oracle databases. Oracle must compete with SQL Server’s ease of use or it will undoubtedly lose market share.
As the intelligence of the advisors and ADDM increases, the need to possess an in-depth knowledge of Oracle and the requirement to review reams of detailed diagnostics to improve database performance will decrease. And you heard it here first folks, I also think that reading SQL traces and statistics dumps will be a thing of the past. My crystal ball tells me that its just a matter of time until Oracle’s SQL advisors make SQL traces and statistics dumps less and less important until they become totally unnecessary. Tuning should NOT be a high ROI activity, it should be delegated to a mere maintenance activity. There is just too many other things for us to do. IT shops will continue to demand that DBAs be more than just technicians. Our role will be how to utilize the ever-increasing number of features provided by the database to solve business problems. NOT looking at a 47 step access path.
The new breed of top tuners will be the administrators who focus on how to use the toolsets and interpret their output. Not the tuners who spend the majority of time digging down into the dark, inner workings of the Oracle software. I’m not saying that knowing how the database works is immaterial. I am stating that this intimate knowledge will become less and less important as the tools mature. It’s only a matter of time until tuning is relegated to a minor sub-task that can be scheduled between other activities.
There will always be a breed of “super tuners” that write articles, books and speak at various events. But this segment of our population will be forced to focus less and less on the core internals of the database. The scope of the information they disseminate will need to broaden to cover new tuning toolsets and performance enhancements in the “latest and greatest” release of the Oracle product set.
If we look at a history of Oracle database enhancements, we can easily see that the vendor is identifying facets of the database that are complex or problematic and providing solutions for them. Remember manual rollback segments? How big were they supposed to be? How many? Oracle recognized that DBAs didn’t do that great of a job administering them and decided that the database was better off doing that job on its own. How about freelists? Dictionary managed extents? Multiple settings for sizing individual SGA components? Log checkpoint tuning? There is no doubt that managing the core Oracle internals is becoming easier.
I also think that Oracle will eventually become self-tuning. Personally, it can’t come soon enough for me. Don’t get me wrong, I enjoy tuning. I’m actually a fairly accomplished tuner.
But as the director of a remote services provider that manages thousands of Oracle, SQL Server, DB2 and MYSQL databases, the less time our product support teams spend on tuning, the better. If we do tune, our focus is on proactive and not reactive tuning. The remote database administration field is a tough job. Our customers hold us to an extremely high standard. I’m OK with that. They have turned over the keys to their most valued corporate assets – their data. As database administrators, we understand the gravity of that decision and we don’t take the responsibility lightly. The less time we spend on tuning, the more time we are able to spend on being proactive, using technology to solve business problems, adding strategic value, improving communication and, in general, just building a positive rapport with our customers.
And just because we won’t be spending time performing proactive or reactive tuning, we all won’t be out of jobs. We’ll just be doing different things. I have listened to various industry pundits proclaim that the next release of so-and-so database was going to no longer require DBAs for support. Bull. I knew it was bull then, it is bull now and it will be bull in the future. Database companies know that they must add new features to be competitive. Every new release contains so many new features that I feel like I have to learn to support the database all over again (which is why I like this job, by the way).
Oracle now allows us to administer disk, lash multiple computers together to enable grid computing and the list goes on, and on, and on…. It took me four different articles to cover just a subset of the new features available in Oracle’s latest release. The database may become easier to administer in some areas, but there are so many new features being incorporated into the product that administrative duties are just migrated to other areas. Oracle ASM allows us to administer our own disk. How many Oracle DBAs could have predicted that they would have the capability to administer their own disk storage subsystems? Can anyone of us predict what IBM, Oracle and Microsoft have up their sleeves in their next “latest and greatest” release? Not me. But THAT is what makes this job exciting.
Thanks for Reading,
Chris Foot
Oracle Ace
Director Of Service Delivery
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
Well, I tried to be proactive and generate a certificate for dbconsole before it expired at six months, but it didn’t seem to work, and trying it again seems to have completely immolated itself. So you hit me at a particularly bad time to be saying Oracle can manage itself or with console.
As far as the future, the complexity of the new features outruns the ability of tools to manage them. Look at how long it took to implement the features you describe – and they still aren’t managed properly. Adding additional levels of abstraction allows more control, but has a big downside if everything is not totally perfect. And software always has bugs, and new hardware etc will often outrun the abstraction.
The ability to display status and properly drill down with these tools to find problems is lacking. That is a fundamental problem that will take a very long time to solve, if ever.
Then there is the pricing issue…
I agree 100% with your points, Chris. In fact, I’ve been saying it very clear in many public venues for years now that the cacophony of tuning methods and approaches with Oracle, if anything, works in its detriment!
Who wants to spend a week analysing a 10053 dump to reach the conclusion an optimizer bug has crept up and the solution is to tweak a hint into a statement locked away in a third party package?
Anyone for that kind of “fun”? Thought so…
No one in the SQL Server world wastes time reading the equivalent of a 10046: there simply ain’t one *and* it’s not needed. For a great many reasons I won’t go into here. As for tuning tools, you got remarkably few in SQL Server compared to the flood of grid, ADDM, ASH, etcetc.
But Joel makes a very valid point: all these bells and whistles that Oracle is adding to its “dba tools” are adding to complexity, rather than making it easier. And with complexity come the bugs. Inevitably! Let’s skip the cost thing for now.
I’ll add the following as well: some of the so-called dba2.0 screens are in fact terribly confusing for folks who don’t necessarily understand the subtleties of graphical representations.
Case in point: there is a screen in grid that displays a graph of redo log waits, with number on (y) and length of wait on (x). In a well tuned db, the graphic should look like a very high peak on the left, quickly tappering off to almost nothing as the wait length increases. Now, this is what I get every time I’ve shown that well-tuned db graph to SQL Server dbas or folks with no clue how to read a graph: “Look at all those waits on the left! Something is wrong with that db, it needs redo tuning!”!
See what I mean? Graphical representations are subjective in their interpretation, in this day and age of little advanced education. And no amount of graphical artistry is going to help one bit in doing capacity planning, for example.
And no, SQL Server is not popular because it is self-tuning or dba-friendly. Far from it. In fact, it is a common error of Oracle to claim it is.
It is popular because it is good enough, it has heaps of applications and it is *CHEAP*.
Something Oracle doesn’t understand, no matter how many times it gets hammered into them.
It is useless to spend squillions in developing “dba replacement” tools like GRID and its plethora of tuning tools if they are buggy, hard to understand and follow, and on top of that they are expensive.
For the umpteenth time: dbas are NOT where the major cost of using Oracle! The real high cost is the software, which Oracle insists on over-pricing. Period.
Man! I feel a blog post coming up!…
Chris,
WOW!!
You scared me with that post.
No, I am not a DBA and frankly speaking I am not inclined to be a DBA who only performs backups, recoveries, tablespace management etc. But since you mentioned DBA spending time on tuning, I really doubt if any tool, at present or in future, can resolve performance issues that occur due to poor design, bad coding practices etc. As long as there are applications that require developers, mostly non-database ones, writing SQL, performance tuning will need human brains which can understand what is going on under the covers to perform accurate root cause analysis.
And at the end, Oracle (or any other RDBMS) is a piece of software. It does follow the infamous rule “if you fix one bug, you introduce N other bugs”. I am not that familier with history of other RDBMSs but from what I have seen with Oracle, how does one figure out whether some “scenario” is a “feature” or a “bug” ?
All database competitors will only continue to add new features and functionality. Just because we aren’t being forced into the bowels of the database to fix a problem doesn’t mean we still won’t be techs. As Narenda stated, we will need to continue to focus on the database ecosystem (application, database, hardware, network, O/S) to uncover issues. Database ecosystems that will only continue to increase in complexity.
The database vendors adding features and functionality will continue to challange our technical skills. I’d be much happier doing that than looking at a SQL Dump. Those days can’t end soon enough for me.
NOONS – I am an Oracle Bigot. I bet my career on it and it has been a good bet. My organization supports hundreds (and hundreds) of Oracle and SQL Server databases. Every configuration imaginable. Our customers beat the daylights out of both products. Both product support teams report to me so I am involved daily in Oracle and Msoft technologies, support issues, problems, etc..
So my relationship now with both products is more from a supervisory level. What I can tell you is that the more I work with SQL Server, the better I like it. I totally agree that Oracle has to do something with pricing. Msoft continues to add features. It can now support the bulk of configurations that most customers are looking for.
What I find the most interesting is that I have folks that work on the Microsoft support team that have NEVER had to call MSOFT support. I don’t have any newbies on any of my teams. No slouches here. Trust me on that one. I found it amazing that guys with 6 years of MSOFT experience have only had to call support 2 times in their CAREER. Have you EVER heard of an Oracle DBA going years without opening a ticket? Maybe ones that have systems that are never changed…. I dumped the bug “fix list” for a recent Oracle point release recently (more as a novelty than anything). There were thousands of bug fixes. I mean thousands. What the?
[...] begin with remoteDBAexperts blog, and Chris Foot’s prediction of the future of database tuning and database administration. It will be, “ . . . administrators interpreting and implementing the [...]
chris,
This is sainath,Im an engineer just passed out in 2009.I like to learn DBA,but i dont know what is the future.I want to know better than DBA any other oracle course is good for future stands.I want to know.Which course can i join.Any Suggstions from your side for my future.
Hello Mr. Foot,
is there a reprint from your article “Using 10g’s V$SESS_TIME_MODEL and V$SYS_TIME_MODEL Performance Views to Evalute Database Performance” ?
I can’t find it.