Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: DBA Vs Apps DBA

RE: DBA Vs Apps DBA

From: C.S.Venkata Subramanian <csvenkata_at_lycos.com>
Date: Mon, 21 Jan 2002 20:29:37 -0800
Message-ID: <F001.003F6A91.20020121195518@fatcity.com>

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:csvenkata_at_lycos.com]
>> 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: csvenkata_at_lycos.com
>>
>> 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: ListGuru_at_fatcity.com (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: john.kanagaraj_at_hds.com
>
>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: ListGuru_at_fatcity.com (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: csvenkata_at_lycos.com 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: ListGuru_at_fatcity.com (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).
Received on Mon Jan 21 2002 - 22:29:37 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US