Thanks John and others for very good update. -- On Mon, 21 Jan 2002 12:10:25 John Kanagaraj wrote: >Hi all, > >I guess this question has been asked many times both in this list and >offline. I had promised to write this sometime back, so it's time to get >to the bottom of this: > >History: Oracle has had an ERP (Enterprise Resource Planning) application - >simply named "Oracle Applications" - for a long time. Originally developed >as a Forms 2.4 (yes - 2.4 was a 'special' version of Forms 2.x that could >handle what they called Flex fields) and ReportWriter 1.x based application >starting at Applications release 9, it developed into a version 10.x and at >some point moved to 'Client/Server' mode (10.7 Smart Client) and then onto a >N-tier mode (10.7NCA, 11.0 and now 11i). Starting off as an packages >Application that catered purely to the Financial side of the organization in >the beginning days, the scope has been widened to cater to almost all >aspects of a Business, including CRM (Customer Relations Management). In >short, 'Apps' now caters to Finance (GL/AR/AP, etc.), HR, Inventory, Order >Entry, Manufacturing, Sales, CRM, etc. > >The Database has always been Oracle, starting with 7.0 and moving onto 7.3, >and later 8.0.x and now 8.1.x/9.0.x. To support the Web layer in an N-tier >architecture, Oracle started using OWAS 3.0/4.0 and then progressed to WebDB >2.x (short lived) and is currently using Oracle 9iAS based on the Apache Web >server for the Web portion. The Forms and Reports versions has moved from >2.4 (character only) to Dev2K and now stands at Dev 6i. The forms runs off a >Forms server that is accessed via the Intranet/Internet and interacts with a >JInitiator that is downloaded to your PC. > >All versions of Apps have had a batch job scheduler - known as the >Concurrent Manager. This is quite a complicated (and well thought-out) piece >of technology and handles Report/Scripts and other execution on the >Application layer. A set of FND (Foundation) tables forms the base for the >Concurrent Manager. Multiple queues, Specialization rules, Interface tables, >Responsibility-based access have been part of the whole system since >inception. This 'Application stack' - as it is usually referred to >*normally* runs in an OS account (usually 'applmgr') that is separate from >the 'oracle' account. > >Apps caters to most of the standard functionality, but a lot of >customization is still required. All of this needs to be done outside of the >Standard schemas. The system is highly parameterized and there are strict >guidelines as to what can be done and what cannot be 'tweaked'. For e.g., >until 11i (or 11.5.x), the optimizer_mode *HAD* to be set to RULE. A lot of >sites that upgraded from 10.7/11.0 to 11i are now tripping up on performance >issues related to the change in mode. > >Because of the complexity and business involvement required, there are two >types of people who manage this - a 'Functional' person who understands the >business side of things and maps the business process to the Apps >functionality. Then there is the 'Technical' person who again consists of >the Apps Developers/System Admins and the DBAs. While the System Admins are >supposed to deal with the Setup and management of the Concurrent manager, >etc. there is quite a bit of overlap and depending on the organization, the >DBAs sometimes act in this capacity. There are also cases of Apps SysAdmins >becoming DBAs by default. > >Since Apps is a complex application, it is inevitable that it needs constant >maintenance, mainly to fix functionality problems. Hence 'Apps Patching' is >a *MAJOR* issue, especially for DBAs and the Tech team. There are literally >hundreds of patches to be applied between minor version releases, so much so >that patches are rolled up into 'Family packs', one per application schema. >This effort is usually underestimated, and the need for a Dev, Test, UAT >environment and a proper Change management system becomes critical. > >Upgrades from one version of Apps to the next are *MAJOR* steps, both >Organizationally and Technically. Upgrade projects need to be well managed >and there are highly paid Consultants (some upto $300/hr and above) that >need to be brought in to perform these or at least plan this out. These >upgrades are mandatory as the Database/Apps versions change, and the >Business depends on it. > >So, what does a 'normal' DBA need to know? In addition to the Oracle DBA >related stuff, the Apps DBA needs to know about the Apps setup, Concurrent >Managers, Forms/Reports servers, Web servers, Patching, Upgrades. Most >important, you need to know what's allowed and what's not - a wrong step can >mess up the whole thing and take you out-of-support. Depending on the >organization and the role, you may also be performing critical work during >period closes (monthend/quarter or year end) as well as SysAdmin stuff. >Going into an Apps situation with both guns blazing can have dire >consequences, maybe not immediately, but certainly at period-closes or >upgrades when it falls apart. There is a lot more to it, such as Printer >configuration, Self-Service Web apps setup, etc. that I have't touched upon >- it would take a separate book to get it all out (Hint : Someday, maybe!). >Tuning, in many cases, is simply a search for Apps patches on Metalink, >followed by escalation to Oracle Support via iTARs if required, as you >cannot change the Application directly. > >My advice : Typically, the number of users connected, the data size and the >complexities brought on by the Concurrent Manager, patching, etc., coupled >with Global access and the dependency of the Business on this single >instance can be overwhelming, esp. if you are new to the Apps DBA world. Do >NOT attempt to be the ONLY Apps DBA in the organization, or jump into it >without understanding the whole process. Bring in an *experienced* outside >consultant that knows Apps to help you over the initial curve, or be a >junior part of the Apps DBA team in case it is already there (even if you >have more 'normal' DBA experience than the rest combined!). Resist >management pressure to act as the Functional person (this happens when the >organization takes on Apps for the first time) - this is an entirely >separate role. And READ - tons of additional reading. Creating a 'play' Apps >system is not an option as a lot of functional setup is required. If you are >well read and can appreciate the points noted above, and are able to >convince someone that you have the qualities required to start up, then go >for it! > >This is from more than a year's worth of 'Apps DBA' experience after having >been a 'normal' DBA for more years than I can remember. Sorry if this sounds >very complex - it IS! > >Hope this helps. >John Kanagaraj >Oracle Applications DBA >DBSoft Inc >(W): 408-970-7002 > >Fear is the darkroom where Evil develops your negatives. >Wanna break free of fear? Click on 'http://www.needhim.org' > >** The opinions and statements above are entirely my own and not those of my >employer or clients ** > > >> -----Original Message----- >> From: C.S.Venkata Subramanian [mailto:[EMAIL PROTECTED]] >> Sent: Monday, January 21, 2002 12:15 AM >> To: Multiple recipients of list ORACLE-L >> Subject: OT:DBA Vs Apps DBA >> >> >> Hello Listers, >> Can any one tell me, what is the basic difference between a >> "DBA" and an "Apps DBA", what additional tasks an Apps dba >> has to do than compared to a normal dba. >> >> Secondly what will be career prospective of a Support DBA in >> the long run. >> >> Pl enlighten me. >> >> >> -- >> Please see the official ORACLE-L FAQ: http://www.orafaq.com >> -- >> Author: C.S.Venkata Subramanian >> INET: [EMAIL PROTECTED] >> >> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 >> San Diego, California -- Public Internet access / Mailing Lists >> -------------------------------------------------------------------- >> To REMOVE yourself from this mailing list, send an E-Mail message >> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in >> the message BODY, include a line containing: UNSUB ORACLE-L >> (or the name of mailing list you want to be removed from). You may >> also send the HELP command for other information (like subscribing). >> >-- >Please see the official ORACLE-L FAQ: http://www.orafaq.com >-- >Author: John Kanagaraj > INET: [EMAIL PROTECTED] > >Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 >San Diego, California -- Public Internet access / Mailing Lists >-------------------------------------------------------------------- >To REMOVE yourself from this mailing list, send an E-Mail message >to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in >the message BODY, include a line containing: UNSUB ORACLE-L >(or the name of mailing list you want to be removed from). You may >also send the HELP command for other information (like subscribing). >
-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: C.S.Venkata Subramanian INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
