News Stay informed about the latest enterprise technology news and product updates.

Top 20 mistakes an Oracle DBA can make, Part II

Got an IT death wish? Attendees at IOUG Live! now know what it takes to be a lousy database administrator thanks to a presentation that pointed out twenty top mistakes DBAs make.

SAN DIEGO -- Wanna stop being a DBA ASAP?

Do one of the twenty things seasoned DBA and Oracle expert Rachel Carmichael of Dragonfly Consulting LLC listed in her presentation last month at the Oracle user event IOUG Live!, and your IT death wish might come true.

Carmichael wasn't actually encouraging attendees to torpedo their careers. Instead, she came up with a Top 20 list of potentially mortal mistakes Oracle DBAs make on the job. If the italicized thoughts mirror what's on your mind, you could be on the fast track -- to the unemployment line.

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.

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?

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.

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.

You only need one user account in the database for everyone to use. Sharing isn't always caring.

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.

Don't keep a source code repository. The source is current. "Current" can get cold in a hurry.

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!

Surely every environment, database, or application has the same set of code. It's better to assume they don't. Better and safer.

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.

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.

This is the second of a two-part report. Click here to read Part 1.

FOR MORE INFORMATION:

CLICK for Best Web Links on database administration

CLICK to ask our expert Brian Peasland a question about database administration

Dig Deeper on Oracle DBA jobs, training and certification

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchDataManagement

SearchBusinessAnalytics

SearchSAP

SearchSQLServer

TheServerSide.com

SearchDataCenter

SearchContentManagement

SearchHRSoftware

Close