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.