Do one of the 20 things seasoned DBA and Oracle expert Rachel Carmichael of
Dragonfly Consulting LLC listed in her presentation at the Oracle user event
International Oracle Users Group (IOUG) Live!, and you could find yourself
holding a pink slip faster than you can say "Victoria's Secret on Fox Tonight at
Carmichael wasn't actually encouraging those in attendance to turn on,
tune in and get booted out. Instead, she came up with a Top 20 list of
potentially mortal mistakes Oracle DBAs make on the job.
1 >> Don't back up your database. After all, your disks
are RAID 5! Carmichael said that's a great way to get security to escort you
out the door. RAID 5 is a cool tool unless you lose two disks or if there's some
form of logical corruption.
2 >> You're backing up the database every
single night. So don't bother exporting the data. Don't bother if you just
won the lottery. If you lost Big Game again, export that data. Export it anyway.
3 >> Here's a good way to never get out of that Chevette: Don't ever test
the recovery features. After all, you don't want to take the production system
away from the users! You know what that means -- you're going to find out
your procedures don't work long after Conan comes on the tube, but well before
Katie and Matt.
4 >> Monitoring schmonitoring! Why bother? Users will loudly let you know
about any problems. It's much more fun to watch "The Osbournes" than to keep an
eye on the system. Don't bother to monitor and you can watch MTV all day,
because there won't be the hassle of a job to go to!
5 >> Only use cache hit ratios instead of wait events to monitor
performance. Cache hit ratios were fine on older systems, but they're not as
integral as they used to be. Which brings us to a "bigger picture alert!"
Carmichael noted that one of the biggest general mistakes is thinking what you
might have learned on one product automatically applies to subsequent upgrades.
For example, you may know the ins and outs of Version 6 of Oracle's database --
details that are totally true and valid. But that doesn't mean those same
details are true on Versions 8 or 9. Evidently, truth is relative in IT!
And now we join our regularly scheduled "smaller picture."
6 >> Got a performance problem? Increase your shared pool. Smack it with
memory. Sometimes memory is more of a problem than a panacea.
7 >> Don't ever change any of the defaults Oracle gives you. After all,
Larry and the gang know exactly what you need, right? Wrong. As Carmichael
pointed out, if Oracle thought it knew exactly what you needed when you needed
it, it wouldn't let you change anything.
8 >> The tables have more than five extents? Recreate them! Especially
if you want to move back in with your parents, like the slacker guy in the
Holiday Inn commercials.
9 >> Index every single column in every single table just in
case -- you might need them. Sure, and Arthur Andersen had no idea those
shredders would actually DESTROY those documents! Carmichael pointed out that
the more indexes you have, the more upkeep Oracle has to do. She said you need
to know why an index is justified.
11 >> Don't analyze tables or generate stats! Oracle's optimizer will figure
out the best path without them.
10 >> Fix your space problems by turning autoextend on every datafile in
every tablespace. Fix your space problems like that in every tablespace, and
there may be a lot of space on your table all right -- your dining room table.
It's better not to put so much onus on
Oracle's optimizer. Besides, aren't analyzing tables and generating stats part
of your job?
12 >> Grant everyone "connect," "resource" and "DBA"
privileges. Go ahead and leave their default and temporary tablespaces as
SYSTEM. Geez, Louise, don't give them the keys! If you do and something goes
wrong (and Murphy's Law pretty much guarantees it), it's going to be your fault.
And a lot can go wrong -- keep in mind a DBA alone can have more than 100
13 >> To retrieve space from a tablespace, just drop the
datafile, and delete the file from disk. Someone from security will retrieve
the personals from your cubicle, and drop them in the mail after YOU'VE been
deleted from the payroll.
14 >> You only need one user account in the
database for everyone to use. Sharing isn't always caring.
15 >> Go ahead -- apply every critical fix without testing them first.
It's probably MORE critical to make sure the fix doesn't fix you first.
16 >> Don't keep a source code repository. The source is current.
"Current" can get cold in a hurry.
17 >> Give developers unrestricted access to the production database.
How about just popping open a can of worms instead? If you let all the
programmers design all the tables because "they surely know what the
applications need," then you're asking for chaos. And if you let programmers
code business rules and referential integrity into the app code rather than into
the triggers and/or constraints on tables, you could be in for some trouble.
Allowing developers to directly modify production data is another place you
don't want to go. Unless you want to go hungry!
18 >> Surely every environment, database, or application has the same set
of code. It's better to assume they don't. Better and safer.
19 >> Don't script anything, and don't save or document what you've done
-- you'll never need that stuff again anyway. Famous last words that could
turn into your infamous last day.
20 >> When new releases come out, upgrade ASAP and use all the new
features in each release. Just because Oracle releases it, doesn't
necessarily mean you need it. If you are going to upgrade, don't do them in
place just in case there are problems or undocumented features. And read those
release notes on installing.