Re: Help deciding

1. you really only have one task. Keep your job. But really, in order of precedence.
2. Make sure the database is protected from damage. This includes primarily hardware failures, but can also include damage from SQL that doesn't work as expected, and corrupts data. This is done, by protecting the data with raid 0, 3, 5 or 10 technologies. Backups of both the physical files, and exports of the tables (this protects from SQL issues).
3. Keep the database running at an optimal level by constantly monitoring the health of the database and making changes as needed.
4. Aiding the developers in writing efficient SQL, so that the database CAN perform well.

I was once told that the DBA's that are constantly busy are the poor DBA's because they aren't actively performing tasks a & b. My personal issue is that I am constantly defending and having to prove that the problem with the database isn't the database at all, but the SQL the developers have it process. By the way, I have almost never lost that argument. I am about 99 to 1 in the win column.

2) That varies a lot based upon the companies philosophy. Most likely you will have a DEV/QA/TEST in addition to each Production database that you have. So figure that you have 4 X (production databases) to manage. The number of production databases is the indeterminate here. My company has about 8 production databases. My group is made up of 1 senior (myself), one experienced and one junior DBA. We can handle the 32 databases without too much difficulty, the issues that make it difficult are when performance issues arise. This puts all other items on hold, and you are left trying to defend the system you worked so hard getting right.

Knowing how everything works is a plus, and I will say, that I came from a SysAdmin role myself, and it has made me a much better DBA than if I didn't have that experience. The only issue is that the SysAdmins sometimes resent the fact that you have the knowledge that you have. Having the ability to both write Unix scripts, Java, Perl, ... SQL & PL/SQL can make your job a lot easier.

3) It is more common to use tools for backups, but they usually require some sort of customization on your part. I personally try and stick with as few tools as possible. Basically, if oracle supplies something close, even if it isn't quite as good, I will use it so that there isn't an issue later on with compatibility. You don't want to be in a situation where you upgrade the database, and then can't back it up.

--
Robert Fazio, Oracle DBA
rfazio_at_home.com
remove nospam from reply address
http://24.8.218.197/
"Christy" <kisstene_at_hotmail.com> wrote in message
news:8hmjfp$2286$9_at_newssvr04-int.news.prodigy.com...


>

> Hello All,

>

> I am new to the scene, and i need to know a little background information

> about Oracle.  I am an Unix Administrator by nature, who has been

> considering crossing over to DBA work.  I need a little background

> information before I decide to take the  position.

>

> 1.  What are the daily tasks of a DBA?  (please be detailed)

>

> 2.  How may instances does an average DBA administer?  How large are the

> databases?

>

> 3.  Is it more common to use 3d party tools to create scripts for tuning &

> backup purposes and if so, which 3 party tools?  (does that go for

 creating


> objects - procedures, triggers, users... too?)

>

> ** Please feel free to include any other useful information for me.

> Thanks for your help :)

>

>

>

>