If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Four months ago I left the comfort of my home network to join the DBA world as a Junior Oracle Financials DBA. Before getting my job I spent the better part of 5 months reading and playing with test Oracle servers in my home lab (studying for my OCP and trying to expose myself to the Oracle world).

I think the point of this message is targeted to many of the people that are just starting their DBA careers. I want to share what I have faced so far in my new career.

My first shock was not in the workload of being a DBA, but yet dealing with the application issues instead. For the most part the workload has been related to Oracle Applications (something I had not had ANY exposure to before getting the position). The point here is that my expectation of relying on all of my DB Admin skills went totally out of the window.

Without going on and on about my experiences, I would like to bullet some of my observations about being a junior dba. If any senior dba's would like to spank my thought processes, please do.. I need all of the help I can get.

1. If you are new to an organization that already had database admin, read the existing documentation, and get a good overview everything as soon as you get on the scene. Make sure that you ask for ALL of the documentation. Just recently one document that would have saved me a ton of work surfaced two months into a process.

2. Start personal documentation at all costs. Something as trivial as a relink error message might mean a lot more to you later than sooner. If nothing else start a spreadsheet and dump every tidbit that comes up into it.

3. Figure out where to find the best information. Metalink, DBA books, DBAsupport.com, white papers, forums etc. I've solved a ton of problems with installs etc. just by using what others have posted on here, and metalink.

4. When you come to a point where calling Oracle support is a last resort, submit the iTar first, then call in and reference it with the iTar number that metalink gave you. The reason I say this is because I have run into support people that want me to read out the entire error message that I'm getting to them character by character, and that becomes very tedious, and annoying. Also our support seems to be hit or miss. Sometimes you get excellent support, and sometimes it really stinks. Sometimes you get someone that understands the situation, and other times you will get people that will try to wiggle out of helping you. With Oracle Support (mainly special interest products like Financials) it is the luck of the draw when you call up support.

5. Document all of your Tars with Tar number, support person name, summary of the problem, date. Reason I say this is because if you rely on your history in Metalink, you might not be able to get to it. Lately it has either been really slow or in some cases unavailable to our network.

6. At the bare minimum, teach yourself where all of the log files reside, and how to get to them as quickly as possible. Also, make life easier for yourself by spending the time to use tools like vi effectively so when you need to edit a portion of a log file or script you can do so without feeling like you wasting a lot of time. There is also a vi for windows, so you NT people can't complain that you don't have a good text editor. =)

These are my opinions on how to survive for at least first 4 months as a DBA. These are my opinions and are subject to a level of newbiehood, so please use accordingly. =)

I would love to hear whether or not you more experienced DBA's think i'm going down the right path or are using the right methodology!?

I guess as a APP DBA, it helps to have experience with ERP (Financials, manufacturing). In your environment, it sounds like you have to wear different hats in addition to DBA, being Application administrator as well. This will be difficult for a JR person but in the long run you will learn a lot.

In terms of Oracle support, I rely on many sources - Metallink, web forums, books, other Sr. or consultant DBAs. There are lots of tricks and shortcuts in terms of administration so knowledge scope is fairly big. You will probably spend 1-2 years learning new stuff. It is critical that you have solid backup and disaster recovery plans and tested them out throughly. Redundancy of logs and control files are also important. The other big issue is peformance so active monitoring and capacity planning are needed as well.

I guess its relevant to post here. I need advise from other DBA`s who work in complex environments, HOW THEY KEEP TRACK OF CRITICAL TASKS THEY PERFORM NOW AND THEN.

I have a problem/question/performance issue and I spent lots of time and break my head with couple of pots of coffee, a bag of snaks and find a solution atlast and fix it. It will be done with a great feeling. I know what I did and remember for weeks or for couple of months... As time passes and keep dealing with other issues coming up I forget, there is noway I could recollect when I hit that again. Thats what we say often saying I don't remember/ I did something...

What is the best solution for this, Time is so pricious and I spent that much time on a specific task and when I get the situation again, I will be doing research and spend time again. There should be an END for this ? HOW ?

Putting stuff on paper/word doc will not help as we mispace/loose often our valuables, paper/doc can easily be misplaced/lost...

Not Sure! Does it goes with the personality ? Or few tips/tricks/hints... Looking forward to hear ...

I think that the best thing to do would to be to fully implement a change management process that would be an application of some nature that you could use to document manipulation of complicated systems. Although we (as DBA's are really not given the opportunity to spend a lot of time, or resources on change management, sometimes adhoc change management is the only affordable method)

What I have started is a framework that will eventually be what i consider a full fledged way of documenting my workflow as a DBA. I use a top level HTML document that points to all of the various documents I use to journal implementations and various notes related to each system.

As I create more documents and save them in various administrative subdirectories, I add a hyperlink to the main (index) document page.

Because all i have to do is add links to the top level document it doesn't take any time and the main maintenance task is adding links to the index document. I find myself adding rough categories to the main document as I find free time.

This is a cheap way to do it, but the great thing is that because it's HTML, i don't have to worry about the file formats behind the scenes, they can be spreadsheets, word documents, txt files, error message screenshots, or a multitude of other file formats.

My dream is to have all of my DBA change management in my own Oracle Database with a pretty front end, but I'm not at that level yet.

I am working as a DBA for both the database and Oracle Financilas applications plus that in the near future we are going to implement WAP on Oracle ,, all this on my own.

I will try to tell some steps that I have always made and see if it can help :

- Rely on Help supplied with Oracle server and Oracle applications
- Document everything
- Consult forums like DBAsupport
- As possible Keep away from Oracle support ( I had bad experinece with them ,, may be it was only my case)
- Try to make friendships with DBAs in similar positions in other companies if possible
- Make a test environment away from your production environment and keep testing everyday tasks that may happen to you ( like a recovery process )
- Study , study and study ,, you will be in need to lean a least a year - actually up till now I read more than 2 hours a day after getting back from work
- Keep all white papars you can get and save it in your personal knowledge base , the paper that you do not need today you will need it tomorrow
- Do not expect to get everything quickly , Oracle is the biggest and the most powerful database and applications in the world so do not expect to know it easily , it takes months of continious work to be in better position

[QUOTE][i]Originally posted by hnagia [/i]
[B]- Do not expect to get everything quickly , Oracle is the biggest and the most powerful database and applications in the world so do not expect to know it easily , it takes months of continious work to be in better position [/B][/QUOTE]

I wouldnt say months but years & practice experience. May be it's harmful but you really learn when real things happens to you :P

All I have done to over come this issue is to immediately, copy/document the issue into appropriate directories. Now I'm having the problem to search through a pile to look for an issue.

It would be really nice, if there is a common web site/ some one could take charge of documenting the issues. I have notice in the past there had been a great deal of discussions on this site alone and some of them are really thought provoking ones. The sad thing is, when some one get to post question on an issue that had been already addressed next time, it is too late to dig through the thread and post it for that user.