A recent email exchange has prompted me to examine ADDM, AWR and ASH in more detail. While I make no judgment on the effectiveness at Diagnosis and Optimization (yet), I do wonder why Oracle has taken such a stand on licensing the base products. I have no problem with Oracle asking for additional license fees for the OEM packs, but I do object to installing and running products that I am told to not use or look at, even though they are taking up storage and processing in "my" database.
I do wonder...what would the current state of Oracle Diagnosis and Optimization be if the Wait Interface, Extended SQL Trace and Statspack were additional charges? We would be back in the "Dark Ages" of Diagnosis. Lots of Grimacing and Guessing (thanks, Mogens). More ratios (assuming we could still query v$sysstat), less response time. I could never have identified a disk issue because all I could say is that the statement takes more time...but I could never tell the user that the problem was that disk reads were taking almost 4 times as long. I hate to even think of our abysmal diagnostic track records.
I do wonder...what would the current state of Oracle market share be if we had limited access to diagnostic views and tools? Perhaps Informix, Sybase, DB2 would be leading the pack because their performance was enhanced by system and session diagnostic and optimization information. Granted, the market determines the winner based on marketing, not technology (or else we would all be working on Vax/VMS). But how quickly would the word get around that the slow performance of that new multi-million dollar database system can't be addressed in a timely manner? Or that the only way to solve problems was to hire Oracle Consulting at $750/hr to look at views and use tools that already exist within your system?
Guesses, Grimaces, Black Boxes and Bloated Consulting Engagements...not a pretty picture.
Friday, February 22, 2008
Subscribe to:
Post Comments (Atom)
Followers
8 comments:
I know, I know, it's a sorry state of affairs and I've done my share of complaining about it in the past.
What's most sad about this, though, is that because I'm working at a site that is licensed to use these features, I can confirm that they're a big step forward (well, in my opinion). They're based on sound principles and although possibly not up to the tuning capabilities of the very best human with the same data, they're much better than most jobbing DBAs I come across.
So that's the shame, that these features have been tarnished with a licensing brush and will take a long time to recover from that.
I have no problem with Oracle asking for additional license fees for the OEM packs,
Oh, but whilst I'm half-expecting a lightning bolt to strike me shortly after sharing this, these features are horrible to use without using OEM. The OEM screens struck me as terrific the first time I used them (I vaguely recall telling a certain Chief Architect that in Dallas) and they continue to impress me.
>> the only way to solve problems was to hire Oracle Consulting at $750/hr to look at views and use tools that already exist within your system?
Bingo.
I have tools that I've never published (as do most others), that drill-in to a performance problem.
Tuning is a semi-structured" task, and while the well-structured components of the decision domain can be automated, it's a classic DSS.
Experience and intuition are required, no automation, no shortcuts . . .
Guesswork with sound "experience and intuition" is better than without but it's still guesswork. It's been a while when Oracle database performance tuning was associated with black magic mastered only by "experts" with their proprietary tools.
Fortunately, there are publicly available tools and methods that try to minimize the impact of guess so that it's not required to hire $750/hr 20-years-experienced consultant with private tools to investigate vast majority of performance problems.
750 Dolliras is about 42 Euros, right? That's not so bad :-)).
Charging for various extra options in OEM is one thing, and requiring EE is - in my opinion - a wrong decition. But it's a decision that one can understand and argue pro et contra.
Having utterly stupid rules about when not to use certain scripts, fixed tables and procudures that are installed by default quite another thing, and is beyond silly.
It's the sort of thing that make close to a million people shake their head, smirk a bit, and then adjust their love for Oracle a little bit downwards.
It MUST have been a lawyer that came up with this nonsense. Or a big committee...
People with skill and knowledge would never have been that unintentionally funny.
At the university of Copenhagen they taught me that you should never put something into law that you couldn't enforce...
As for guessing and having intuitions, I'm all for it when it comes to love, sex and relations in general.
But it has no place among technical people.
It's there, but it shouldn't be there.
All this guesswork and "Oh, there's also this memory parameter you can use..." and "It's really really difficult, so hire me" prostitution stuff is nothing but intellectual laziness.
Makes me ashamed of some of the people in the profession.
I cannot for the World believe that they don't want to be scientific and strict about it, but instead wants to continue with the dishonest thing.
"Honesty lasts longer, the other thing is much quicker", as my old math teacher in basic school always said.
Mogens
Partly, it's a matter of history. The wait interface was developed in an attempt to resolve a performance problem on a specific customer site. Having seen how successful and valuable trace has become, they decided to turn it into a product that could be sold.
Plenty of customers use trace, tkprof and even statspack to resolve performance problems without resorting to external consultancy. But any diagnostic information, AWR/ASH/ADDM/OEM included, is useless unless you know how to interpret it. It is a skill that has to be learned and practiced. You also have to understand the underlying processes and structures that are being described. Although, there is no doubt that this much easier when it is presented by a tool in a structured fashion.
In many companies, I see the DBAs located in a different 'silo' from the application support people. They often have so many databases to contend with, that don't have time to develop these skills. If that model isn't generally typical, then it is a feature of the kind of company that chooses to use expensive consultancy.
There is no place for guesswork in this process. But experience will help to improve the speed and accuarcy of that interprettation. It reminds me of a line from the Hound of the Baskervilles. Holmes, accused of guesswork, responds: "Say, rather, [we come] into the region where we balance probabilities and choose the most likely. It is the scientific use of the imagination, but we have always some material basis on which to start our speculation."
Bravo! Well said.
I have made a few public remarks on this subject myself, but I don't think I have ever been able to state this point nearly so nicely.
I, too, acknowledge Oracle's right to license their products in any way they see fit, however, as a parent of a six-year-old child I am no stranger to the bafflement of the "poor choices" people sometimes make.
Require me to pay extra for the pretty bells and whistles offered by the OEM "packs"? Sure. Why not? If they really add a lot of value, I should be happy to pay for them.
But I continue be be baffled by Oracle's insistence that I pay money to simply look at the underlying data. Perhaps they feel that this data is just too valuable; not so much to me or other end users, as (perhaps) to organizations that might want to market tools that compete with the OEM Tuning and Diagnostics Packs.
Oh well, things are improving. At least I no longer have to pay money for a (legal) means of turning AWR off. Not as long as I am paying for support and know enough to go download the necessary patch from Metalink, that is. (Ooh -- wait. That particular patch might actually be available for free on OTN...)
That is an improvement, right?
Hmmm... Here is an interesting question for a real lawyer:
AWR licensing questions aside, who actually owns the data gathered by AWR? As this is data about my computers, my applications, and my business, and it is gathered with my resources, does it not stand to reason that I own it? (Well, okay, perhaps nothing "stands to reason" when it comes to law.) If I do own this data, can a software licence agreement (particularly a "shrinkwrap" agreement) actually prevent me from looking at it?
(I suspect, sadly, that there are probably as many answers to that question as there are legal jurisdictions in which Oracle products are sold. Still, it might be really cool to hear a few qualified legal opinions on that subject.)
By the way, people, we are talking about some pretty basic data here. Stuff as simple as "what was the second-to-last SQL statement executed by a given session?"
I have faced some rather unpleasant situations that could have been resolved instantly had I just been able to look at ASH to find the last few SQL statements statement executed by a session that has been idle for 3 hours, but is now blocking my entire production database on row-locks.
(Somehow, it seems to have never occurred to the development manager insisting that I provide this information to instrument his own code, but that is a whole other story.)
First, I'm glad people are finding the OEM 10g performance screens useful. I must admit I like them if I do say so myself, though the sluggishness and monolithic nature of OEM drives me a bit crazy, thus I've been working on a light weight OEM but you need the ASH license
http://perfvision.com/ashmon.php
On the other hand you can collect the ash data your self and skip the license. It's pretty easy with 10g as almost everything you need is in v$session. I put together a pl/sql package to collect that at
http://perfvision.com/ash.php
I guess that we ("the DBA community
with signficant experience with
Oracle" -- and I'll come to why I
said that) have a grouse against
the licencing of the AXXXX products
because we are so familiar with
the data dictionary, v$views V$SYSTEM_EVENT, V$SESSION_EVENT, event 10046/dbms_system.set_ev etc
and have been using them for years and do not see why we should have to pay for them now.
Let's step back and think of a very new Oracle customer to whom
Oracle is a black box. He doesn't
know that he could have obtained all that performance and wait information if he knew how. All he knows is that he has to pay for the licence for these features.
If you buy some complicated electronic or other equipment you might find one or two "black boxes" inside the equipment. A sticker on the box(es) says "Warranty void if seal is broken". So you don't touch those boxes.
The new Oracle customer doesn't touch the V$ views because he has been warned not to.
The problem with *US* is that we have known these views and how to query them. Since Oracle8 (or 8i?) Oracle has been providing documentation on the V$ interfaces.
Since 9i Oracle has been bundling a "Performance Tuning Guide".
But we have written our own scripts or scripts from the web, from experts etc.
Third party vendors (Quest or whoever) also has built GUI frontends against the same views.
So the question is "Did Oracle say that we had free, unfettered access to all the performance information we could get out of the database instance before 10g ?"
We believe so. But are we sure ?
Post a Comment