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

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.

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.

11 >> Don't analyze tables or generate stats! Oracle's optimizer will figure out the best path without them. 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 privileges.

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.