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).
