Re: Fed Up with being a DBA

Nuno,

You're a very well informed individual. I couldn't find fault with anything you said. Yes, most of the apps we deal with are bought off the shelf, and I'm powerless to change them, and the SQL code they generate dynamically. Ever tried to tune an app that insists on searching for NULL values? Of course NULL doesn't get indexed (except for bitmaps) so Oracle FTS's itself to death. And I keep telling them, "there's nothing I can do except purge old records, reorg the tables to shrink the HWMs so that the FTS's are less resource consuming).

Now, I could do this ...

CREATE INDEX null_fidx
ON a_huge_table (NVL(any_column, 'NULL')) TABLESPACE whatever;

ALTER SYSTEM SET query_rewrite_enabled = TRUE;

but can I change the compiled code from ...

"AND any_column IS NULL"

to

"AND NVL(any_column, 'NULL') = 'NULL'";

AND, GUESS WHAT, without a hint, CBO will not pick up the index!!!

Domenic.

Daniel's living in a dream-world. And, yes, Oracle is shooting itself (and us) in the foot. By pitching that Oracle 10g is self/automatic managing, many folks will assume it doesn't need a full-time DBA. I'm going to take some 10g courses, but most vendors will never implement these features because like you said, the code must be database vendor independent.

"Noons" <wizofoz2k_at_yahoo.com.au> wrote in message news:<3f634ddc$0$14408$afc38c87_at_news.optusnet.com.au>...
> "Daniel Morgan" <damorgan_at_x.washington.edu> wrote in message news:1063468400.388132_at_yasure...
>
> > >
> > When I see bulk binds and FORALL in one of these packages I'll agree.
> > And they aren't all pure OLTP inserts. Some do real processing.
>
> The poster was talking SPECIFICALLY about OLTP apps. They do NOT need
> bulk binds or FORALL. Those features are useful for the likes of DSS or
> CRM. IOW, the Peoplesofts and SAPs of this world. Which mostly do NOT
> use them. Because their code has to be compatible across different database
> makers. Bulk binds and forall are hardly so.
>
> But none of those are OLTP. And the point was about OLTP.
> Not general purpose apps.
>
>
> > the internals byte-by-byte block dump by block dump. What I mean is that
> > you need to understand how it works and act appropriately. Something as
> > simple as running DBMS_STATS regularly is often enough. Something not
> > required or done by those still clinging to the RBO and its fixed rules.
>
> Sure. But to claim that 7-8 version users are incapable of using anything
> other than RBO is IMHO wishfull thinking. Fact is: CBO WAS available in those
> versions. AND buggy. Still is in 9ir1, you need quite a few patches to
> make it work fine. And we heard here recently of where it STILL is buggy in 9ir2.
>
> Let's not blame users for what Oracle puts out. And you know very well
> that many here have been ramming CBO down everyone's throats since 8.0.
> Despite the fact the darn thing has always been buggy in those versions.
> It's not the user that has a problem, it's the software.
>
>
> > I'd agree with you except that here in the Pacific Northwest region of
> > the U.S. there is a huge pool of people with years of Oracle experience:
> > And they are unemployed. The reason is that there is a large enough pool
>
>
> That has NOTHING to do with the version(s) of Oracle they know about.
> And EVERYTHING to do with the current market and the re-definition of
> the DBA job by Oracle themselves. AND a few other factors.
>
> Like a huge IT recession you folks are finally going through (we've been in it
> for years now) and the outsourcing of trivial jobs to 3rd world countries
> (which we've lived with for years and is FINALLY reaching you folks).
> Those are the REAL reasons for the unemployment.
>
>
> > of highly qualified people that those with old skills, out of date
> > skills, and less than senior skills are no longer needed.
>
> So, the solution is for all those with old skills, out of date skills
> AND less than senior skills to upgrade to 10G? I don't think so:
> if they are unemployed, by definition they CANNOT upgrade to 10G!
>
> Besides, moving to the latest, whitest and brightest has never done
> ANYTHING for one's skills. Training is the key, IF there is a demand
> for the skills. There isn't. Oracle has made sure of that, with their
> push for outsourcing and their "ease of use" marketing. They shot
> themselves on the foot.
>
>
> > I had the CIO of a major companyl tell me yesterday he no longer felt
> > there was any reason to use his budget to train people when there were
> > so many highly qualified people looking for work.
>
> Bingo. It's called offer and demand. Guess what: he is totally RIGHT!
> The people out there are HIGHLY qualified, not some retarded old farts
> completely out of touch with reality. And there are heaps of them.
>
> The problem is NOT the version they know. It NEVER was. Versions mean
> NOTHING, if one doesn't know the basic principles of the job.
>
> > So people may or may not be scared. That's there business. But those
> > signing their paychecks no longer feel the need to hire bodies with less
> > than optimal skills and train them. Three of his employees just
> > registered at the U using their own money and out of a concern that they
> > not be replaced.
>
> There is also something called on-the-job training. Which training
> organisations nowadays point blank refuse to recognize. And was
> for MANY years one of the best ways to ensure employee permanence
> and good bang for $. I still have to hear one argument that sticks
> for it not to be used nowadays.
>
>
> > So it may not be true everywhere ... but it is true here.
>
>
> Believe me: we've been seeing this problem in Australia for
> YEARS now. Nothing new. I've also got news for you: it's got
> NOTHING to do with what version of Oracle you're running or know about
> and it's gonna get MUCH worse.
>
>
> I'll also add: Not only will the rate of upgrade to 9-10 slow
> down, but also MANY will examine their options in favour of
> OTHER products when it comes time to upgrade. There is no point
> in continuing to use a product that is unnecessarily expensive,
> as buggy as any other product out there, requires senior skills
> in order to be used efficiently and that is constantly re-defining
> the skillset needed to use it (thereby forcing costly re-training).
>
> It's not the client at fault: it's the product. Thank Oracle for that.
>
>
> > Then from now on you won't be able to say that. Here are three:
> >
> > Partitioned Tables
> > Index Organized Tables
> > Function Based Indexes
> >
> > Want more? There's a very long list.
>
>
> I'm perfectly aware of the list, you are preaching to the converted.
> My problem is HOW to make the new versions of CBO useful for those that
> will NEVER use any of these features.
>
> I'm referring to arguments for the CBO that WILL convince someone
> using an older version to upgrade. Small things that will TRULY help
> make life easier for someone running one of the disaster apps I talked about.
>
>
> Things like stored outlines, portable stats and partitioned indexes.
> Oracle themselves recognized their value once they started their own service
> bureau: you simply CANNOT run one without those.
>
> These are features that TRULY help the poor sods out there stuck with
> horribly designed apps. Who have NO HOPE in heck of ever seeing their makers
> use a partitioned table or an IOT or a FBI.
>
> This is how Oracle&Co should be pushing for upgrades. Not features that
> will NEVER be used by 3rd party apps. Like it or not, the VAST majority of
> sites uses canned apps. Ignore them, you are ignoring the largest customer
> section. Call them ignorants, and they'll leave faster...
Received on Sat Sep 13 2003 - 18:22:33 CDT