RE: DBA Vs Apps DBA

Excellent

Peter

--


=================================================

Peter McLarty               E-mail: Peter.Mclarty_at_mincom.com
Technical Consultant        WWW: http://www.mincom.com
APAC Technical Services     Phone: +61 (0)7 3303 3461
Brisbane,  Australia        Mobile: +61 (0)402 094 238
                            Facsimile: +61 (0)7 3303 3048


=================================================

A great pleasure in life is doing what people say you cannot do.

    - Walter Bagehot (1826-1877 British Economist)


=================================================

Mincom "The People, The Experience, The Vision"



=================================================








John Kanagaraj <john.kanagaraj_at_hds.com>
Sent by: root_at_fatcity.com
22/01/2002 06:10 AM
Please respond to ORACLE-L

 
        To:     Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
        cc: 
        Fax to: 
        Subject:        RE: DBA Vs Apps DBA


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





-- 
This transmission is for the intended addressee only and is confidential information.  
If you have received this transmission in error, please delete it and notify the 
sender.  The contents of this e-mail are the opinion of the writer only and are not 
endorsed by the Mincom Group of companies unless expressly stated otherwise.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: 
  INET: Peter.McLarty_at_mincom.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).