Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword
Like this
9Activity
0 of .
Results for:
No results containing your search query
P. 1
top20-DBA mistakes

top20-DBA mistakes

Ratings: (0)|Views: 105|Likes:
Published by api-3763657

More info:

Published by: api-3763657 on Oct 16, 2008
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

05/09/2014

pdf

text

original

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?

Activity (9)

You've already reviewed this. Edit your review.
1 hundred reads
mahiroux liked this
harshdba liked this
vedleo78 liked this
Aram Harutyunyan liked this
robinsondba8697 liked this
nvk_it liked this

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->