|< Day Day Up >|
Oracle E-Business Suite (i.e., Oracle Applications, Oracle Apps, Oracle Financials, Oracle Manufacturing, Oracle CRM) is the suite of products that used to be called Oracle Financials. Oracle Financials was first released in the late 1980s and has evolved into a full-fledged solution for enterprise processes for companies of nearly any
Oracle E-Business Suite also incorporates a powerful, flexible combination of state-of-the-art technology integrated to aid in rapid implementation. Various
The question is often raised: What is the difference between a regular Oracle DBA and an Apps DBA? While the answer may sound trite, the difference is what you make it. There are many different thoughts on this from many different people. Some people suggest that there is no difference and to an extent that is probably true. In reality, Apps DBAs are regular DBAs who have to remember and be
You, the Applications DBA, will be responsible for managing, sizing, maintaining, and tuning the database (just like any DBA). Your Apps database is an OLTP (online transaction processing) system. Along with the other responsibilities, go all of the wait and lock concerns that you would have in any transactional system. Oracle E-Business Suite also has some
Get familiar with Concurrent Managers; there are no friendly manuals that you can read to help you with these or any in-depth documents to help. Chapter 9 — Installation and Migration will help you along the way and will point you at some other information that may be of assistance.
Remember that, while you run mostly a transactional system with the end users entering row at a time information through the interface, you are not dealing with a true OLTP system. When a batch gets kicked off through a concurrent request is not usually under your control. An end user from the finance department may decide when to submit a payment batch and not realize that there may be
Never apply a patch to the production databases unless you have
Document all the patches: the day applied, the reason for applying, the errors that they were supposed to solve, and the errors created after applying. Keep the logs of all the patches and do not ever erase them; Oracle will ask for that patch log after maybe six months when one of your current patches
Remember that Oracle Applications is heavily indexed; rebuilding the indexes periodically will improve performance significantly. There is a Concurrent Process that will help you with performing this action. Try to schedule it for a time when there is a minimum of users on the system.
Monitor the rollback segments. This is probably one of the most important and one of the trickiest
Never attempt to add additional indexes for performance without first asking Oracle Support. It is Oracle's application and Oracle Support should know better than
Understand how patch application works. You will be spending a great deal of time involved with some portion of patching: from planning which patches to apply, to acquiring the patches, to applying the patches, to testing and documenting post patching, just in time for the next time you start planning which patches to apply next. Chapter 10 — Patching will help with this.
Know that there will be many invalid objects any time that there are any changes made to the database. Any time you do anything that might have an affect on the database, check the number of invalid objects, and periodically run
to recompile them. Utlrp.squ, located in the Oracle Home Directory's rdbms/admin subdirectory, is responsible for compiling invalid objects. When run as the 'SYS' user, it attempts to recompile all invalid objects to all schema
Understand Alerts. Especially understand Periodic and Event Alerts and understand how they
Remember, being an Apps DBA is pretty simple. With the exception of setting up printers (which can be tricky due to initialization settings) everything is fairly straightforward and you will learn quickly. You will soon become at ease in your environment.
You will create test and development databases (maybe more) and you will keep them refreshed by copying (cloning) the production database. How many instances you choose to create and maintain is enterprise dependent. Much of the decision on exactly how many databases will depend on what the business dictates. Minimally, I suggest having at least three complete and separate environments and four complete sets is even better. First, have a development environment where your developers can develop custom reports and custom PL/SQL (Procedure Language extension to Structured Query Language) packages to support those reports. This environment can be refreshed on a move up cycle or whenever the developers feel that the data is no longer representative of what is in production. This is likely the first environment into which to apply patches. Next, have a test environment where you apply patches before final user acceptance testing and user signoff. Test should be as close as possible to production data before a patching cycle starts, so that the end users can test with data as fresh as possible. Finally, you will have your production environment. Production is self-explanatory. Optimally, you will have a fourth environment: I will call it patching (if you installed the vision environment, you can use this for the patching environment). Patching is where you can apply patches and fix them when they break without having any impact on any of the users of the system. This is a place you can consider your playground. You can test out changes to the system without worrying if your changes are breaking anything or if they are having ill effects on what anyone else is doing.
Cloning (see Chapter 11) is making an exact duplicate environment (both the applications layer and the database layer) against which patches are applied and tested, reports are written and tested, upgrades start and are tested, and in which problems are fixed and the fixes tested all before any of these goes to production.
Patches, both ORACLE Applications and RDBMS (relational database management system) patches, will need to be applied and tested. These should start in the development database (unless you have one just for patching) and
Further, in your capacity as applications administrator, you can likely find yourself involved in the following roles:
Oracle Applications DBA
Capacity planning and sizing the hardware
Architecture and design of the Applications system
Installation of Applications 11i with respect to planned architecture
Cloning Applications 11i and scripts
Splitting and merging the nodes, single node to multiple node and vice versa
Workflow installation and configuration and setting up test workflow
Oracle WebServer (OWS), Oracle Application Server (OAS) tuning
Tuning Concurrent Managers
Tuning application UNIX server and identifying issues
Tuning scripts and other Application troubleshooting
Finally, installs and upgrades will be your responsibility, as well as making sure those upgrades and
You also need to determine the timing and type (e.g., hot, cold, Recovery Manager, or any combination) of
Most likely, you will be responsible for starting and stopping the Concurrent Managers and managing their functionality and performance. It may be your responsibility to create request sets for users to use to submit reports and batch jobs.
The help desk will probably
You may be called on to administer other pieces that are used in conjunction with your Apps install. These may include Discoverer, Forms and Reports, and other software used inhouse that interfaces with Oracle E-Business Suite. When custom programs, forms, or reports are created or
Interim tables, their functions, and what they can and should do are also things that you will have to have a hand in, at some point. Interim tables are the means by which you get external data into your financials database from outside sources. These are the only tables that anyone should ever need to touch from a design standpoint.
Applications' middle tier and the database are intricately connected; that is part of what makes it such a powerful and complex piece of software. What affects one piece often affects others and usually affects the whole. If there are server problems on the database tier, they can become painfully obvious to your users accessing the Apps front end. If a form is not performing correctly, you could see performance issues on your database. Many times, following a patch installation, completely untouched forms and reports will change how they are acting or
You will also need to have a working knowledge of Oracle's Apache Server and the iAS Suite and their foibles on your OS. JServ, Apache, and the internals to iAS that come with Oracle Apps are what allow your users to access your system cleanly.
There are Forms and Reports Servers running on the middle tier. Those may become something that you need to maintain during a patch cycle or upgrade, if at no other time.
To better serve your end users, you will have to gain some basic understanding of the underlying structure and architecture. If there are other systems feeding your installation, you may need to understand where the data comes from and what could, potentially, go wrong in the transfer. You do not have to know everything about accounting and FASB (Financial Accounting Standards Board), but it does help to know things like AR is accounts receivable (money that is coming into your company), AP is accounts payable (money going out), and GL is general ledger (the accounts that the money goes into and out of).
If you are dealing with any Windows version as your middle tier, you will need to have a basic understanding of registry entries and how that can affect you and the differences in how
Besides you, who is responsible for what? It will be helpful to your organization to have a help desk to which the functionals and other technical people can turn when there is a problem, a point of contact. If you have one of these, it can add
System administrators (
Above all, you will be dealing with some of the most complex and powerful software that you may ever have been connected with. The parts of this application cannot be treated entirely independent of each other.
In short, an Apps DBA will need to know a little bit about a lot of things. This book will help you along the way.
|< Day Day Up >|