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.

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?

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” ?

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!…

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…