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
RE: DBA Vs Apps DBA
Title: RE: DBA Vs Apps DBA From past experience: Many companies may classify a DBA as the person that administers the database and the Apps DBA to administer the applications that utilize that database. The Apps DBA may be more of a glorified database developer with some DBA duties and understanding of how the database interacts or is utilized by the application (whether it be COTS or a local beast). The DBA has more responsibility, usually more experience (this usually translates into higher pay as well) than Apps DBA. Jon Baker Database Architect [EMAIL PROTECTED] www.netsec.net -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).
RE: DBA Vs Apps DBA
-Original Message- Sent: Monday, January 21, 2002 2:41 PM To: Multiple recipients of list ORACLE-L The DBA has more responsibility, usually more experience (this usually translates into higher pay as well) than Apps DBA. Well, yes and no. I have seen many orginizations pay the Apps DBA more, because of the Specailized knowledge they have. Jon Baker Database Architect [EMAIL PROTECTED] www.netsec.net Terry -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Ball, Terry 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).
RE: DBA Vs Apps DBA
On the consulting side, I've seen both. The way I've seen it is if they ask for an Apps DBA the rate is lower than for a DBA, but if they ask for a DBA with [Financials|Manufacturing] the rate is higher. HTH, Bambi. -Original Message- Sent: Monday, January 21, 2002 3:06 PM To: Multiple recipients of list ORACLE-L -Original Message- Sent: Monday, January 21, 2002 2:41 PM To: Multiple recipients of list ORACLE-L The DBA has more responsibility, usually more experience (this usually translates into higher pay as well) than Apps DBA. Well, yes and no. I have seen many orginizations pay the Apps DBA more, because of the Specailized knowledge they have. Jon Baker Database Architect [EMAIL PROTECTED] www.netsec.net Terry -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Ball, Terry 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: Bellows, Bambi 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).
RE: DBA Vs Apps DBA
Excellent Peter -- = Peter McLarty E-mail: [EMAIL PROTECTED] Technical ConsultantWWW: http://www.mincom.com APAC Technical Services Phone: +61 (0)7 3303 3461 Brisbane, AustraliaMobile: +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 [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 22/01/2002 06:10 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] 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
RE: DBA Vs Apps DBA
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
