The Life of an Oracle Apps DBA

In this forum Oracle Applications DBA's, System Administrators & Developers can share their knowledge/issues.
Post Reply
avais
Posts: 3
Joined: Wed May 17, 2006 4:04 am
Location: Saudi Arabia
Contact:

The Life of an Oracle Apps DBA

Post by avais »

[;)]According to my experience, I have worked through out on Oracle Apps Financial and lately one site on 11iCRM, it does pay more if that is what you wanted to know. Typically the industry standard is that they pay no less that 120K for an Apps DBA, but then that depends on the number of concurrent users and the number of databases you would be handling, not to mention the size of the databases and understanding the related interfaces to datawarehouse, OLAP, Legacy systems etc. So it is a complex setup on most sites and that's why it pays. Take it from me you would never be as free as you wanted ever again. There are something called patches, which is like a black hole. Once you get in, no coming back.
1. For starters, get familiar with Concurrent managers, there are no set manual or documents to help, the best one so far is Barbara Mathews paper on Orapub to understand the behavior.
2. Next understand something called Interim tables.
3. Third, remember you are not on a true OLTP, when the batch gets kicked off it is not under your control, the financial department guys decide that and excellent coordination between you and them will make life easier.
4. Fourth, never apply a patch to the production databases unless you test it multiple times and get a UAT done, meaning user acceptance test. Its your neck.
5. Fifth, document all the patches , the day you applied, the reason for applying, the error that it is supposedly to solve and the error it created after applying. Keep the logs of all the patches and do not erase it, oracle will ask for that patch log after maybe 6months when one of your current patches bombs.
6. Sixth, Apps is heavily indexed, so remember to rebuild them periodically, improves performance a lot.
7. Seventh, Monitor the rollback segments, it is the most important and tricky segment. Once your say posting or one of those concurrent programs fail, due to rollback segments, then the whole program is rolled back clogging the cpu and other programs in the queue. It also leaves behind some of the interim tables and indexes for clean up, which has to be done manually and be careful which programs that table belongs to, some of the programs reuse the same interim table for reporting, posting, purging, etc.,
8. Eighth, Never add any additional index for performance, ask Oracle before you do it, its their application remember. Incase you do some changes, then document it, because the next patch would identify the change and replace it back to square one.
9. Ninth, understand how patch application works, you would be spending a lot of time on this.
10. Tenth, remember there will be a lot of invalid objects when any changes happen to databases. Always keep a check and count the number of invalids. When you encounter errors check for any invalids first before raising a TAR.
11. Eleventh, Understand Alerts, specially Periodic and Event alerts and how they are different from database triggers.
12. Twelve, Apps system administration is pretty simple except for setting up the printers which is tricky due to the initialization strings. Test all printer setups properly. Once one of my friends printout came out in England, which was submitted in New York.
Well, that seems enough for the day on Apps to think about. Its really interesting to work on Apps, and I am sure you would enjoy all the latest technology Oracle has to offer comes first on Oracle Applications.
Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests