Re: My woes continue, Bad DBAs

From: Rodger <rodger_at_infobahn.mb.ca>
Date: 1997/07/15
Message-ID: <33CB82EC.78AF_at_infobahn.mb.ca>#1/1

In my experience, complex queries (Select only) will really overload the system and slow it down. But they rarely crash the system. And I have a tendency to really work those CPUs and hard drives!

When I have crashed systems, it was because: - I was creating temporary tables. The DBA had not allocated the extents and table spaces for me, or these queries. The temporary work space took up all the other data space, locking other users off. Crash. Solution was for the DBA to finally get me some proper data in the test database that I was supposed to be using. Then I didn't have to bug the other users.

• the query (view) was defined wrong (actually, mine was done right, but the DBA entered it in wrong, giving too many rows). We needed more space. We kept getting the error: unable to extend temp segment by 256 in tablespace TEMP Solution: have enough work space, and define the query correctly.

What is your DBAs background?

My experience with the DBA that I mentioned had MANY holes in his knowledge, and screwed up our Uniface development environment big time because of his stupid idealistic ideas, and his laziness. We are still spending many hours in wasted productivity because of his decisions. I would hate to calculate what this cost in dollar terms.

But get this. Almost everyone believed anything he said as gospel. He has since taken another job in another city, and been promoted and supposedly has a staff! His incompetence and shooting the mouth off, rather than knowledge, was rewarded!

There are a LOT of incompetent people in the computer business. Warning signs are:

- never admitting that (s)he is wrong.
- walking around boasting.
- quick to point out that you are wrong and make a big deal out

of it. But keeps the trap shut when proven wrong themselves. - no real training to speak of. Got into DBA work by dabbling, and by chance. - says that everything is "Just That Simple". Does not have the discipline to systematically go through things and make the nuts and bolts work. Big ideas only.
- no documentation of procedures.
- no concern for basic performance issues (ie. the question: How many rows per second will this function process? is too difficult for them) - no systematic determination of problems. Draws quick conclusions as to causes, no matter how ridiculous they are. - tells you the obvious to keep from answering the real questions - guard information to themselves, and is not a team player. When asked to show their knowledge, say, "Why should I?" - like to play with their mouse. The computer does EVERYTHING! - desires to get into consulting because it pays more, but has no idea what is involved business wise.

I could thing of more. But that's a good start. How about the rest of you? Any experiences or ideas?

Rodger

kasperle_at_cs.tu-berlin.de wrote:
>
> Joost Ouwerkerk wrote:
> >
> > To all DBA's:
> > My DBA is making my job rather difficult, but I'm having trouble [Quoted]
> > exposing some of his incompetencies to my superiors... Should any of
> > the following statements be true for a well-tuned Oracle 7.3.2
> > database server running on an IBM AIX and serving an organization of
> > 50 users, about 15 of whom are data entry staff, and about 10 of whom
> > run regular queries and reports:
> >
> > 1) A complex query can 'crash' the database and cause corruption of
> > data.
>
> Yes it can (done it myself). If a query is _that_ complex, the
> server can get _that_ overwhelmed, that it just isn't able anymore to
> cry for help.
> Mine came down with a core dump.
> No corruption, though. (can't remember exactly. it's an enginering
> system we quite often shutdown and startup, sometimes even for power
> failures, so corruption isn't anything horrible to us :-))
>
> > 2) Running Personal Oracle on a client (user) machine can 'crash' the
> > database and cause corruption of data
> > 3) Running Developer/2000 on a client machine can 'crash' the database
> > and cause corruption of data.
>
> I don't think, that it makes any difference which tool starts the
> difficult query. In my case, I put it in a stored procedure.
> Anyone who can invoke this, might crash.
>
> > My suspicion is that if any of these are true, there is a server
> > tuning problem. My DBA is suggesting no queries be run while data
> > entry is occuring (during business hours) and is threatening to remove
> > Personal Oracle and Dev/2000 from my computer because of the damage
> > I'm supposedly causing. Am I going crazy?
>
> He's right. Engineers shouldn't try risky thinks in working hours on
> production systems. Go to the off hours or make up a test system.
> You should know, whether things get risky (at least after the first
> crash).
>
> The easy solution to my problem was, to get a _big_ rollback segment
> online. And to use it for the query.
> After a while, I learned, that tuning the DB (extents of some
> log-tables) would do the trick and even better.
> After another while, I learned that tuning the query would even do the
> trick, too.
>
> So don't fight the DBA, try to fix it yourself.
>
> regards,
> Kathrin
Received on Tue Jul 15 1997 - 00:00:00 CEST