Re: Fed Up with being a DBA

"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...

-- 
Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam