THINGS TO DO AFTER AN ORACLE APPS R12 INSTALL

THINGS TO DO AFTER AN ORACLE APPS R12 INSTALL

OK, so there are a ton of things to do right after a fresh R12 install. And before anyone says anything, I know each of my steps has multiple steps; I though 6 things made a simpler blog title, that’s all.

Nevertheless, below are the major tasks I think every Apps DBA should do right away before letting anyone log in. I call these out for two reasons. First because they’re invasive and tough to do once people start logging in and using the system. And second, some are security-related, so it’s good to get them done right away.

1. Perform intrusive DB/application security steps.

There are many security precautions that should be applied to a fresh install, but these should be done immediately before allowing anyone to log in. A fresh install is basically a wide open portal complete with known passwords (APPS/APPS, SYSTEM/MANAGER) so until some of these steps are taken, your new system is extremely vulnerable. In no particular order:

Change all the standard database and application passwords. All of them. Except APPLSYSPUB because you’ll end up handing it out anyway.
Set up auditing (love the syslog feature).
Lock down the listener with a password.
Drop unneeded DB links.
Set up node validation checking if you can. If you have developers or others connecting via sqlplus and you can’t consolidate them onto a Terminal Services box or similar, then you won’t be able to do this.
2. Clean up the database.

The default database has all the data, but it’s woefully lacking in structure. I see MANY systems that years later still have the same structure set by rapidwiz. At a minimum:

Spread out the control files. Put one copy on at least two separate devices.
Multiplex the online redo log groups and spread them out over separate devices as well.
Enable Oracle Managed Files (OMF). Huge convenience factor, so I do it whenever possible. This step is optional, though.
Convert to ASM if possible. ASM provides a lot of benefits and is getting better with every release.
Create a flash recovery area, then enable archiving and flashback. Even if you don’t want to back up the environment, set RMAN up to clean up the archive logs periodically and keep your database archiving. Flashback is incredibly valuable in a test environment and archiving is required for flashback.
Set up a password file.
Set up the SPFILE.
3. Set up a custom tablepsace and application top.

Even if you have no stated need for a custom application top, build one. When you or your customer needs it, you’ll want it right away. Having it available will prevent you from taking shortcuts and placing files and objects where they don’t belong out of expediency.

Create a custom tablespace.
Create a custom application top with OAM so it’s in the context file.
Register the application top in the application.
Set up custom environment variables in $APPL_TOP/APPS${CONTEXT_NAME}.env
4. Clean up the users.

Set up custom profiles and assign them to all users. You can’t really set standard accounts to expire, but you can create profiles that require password complexity and prevent password reuse. Nothing should use the DEFAULT profile; take control of system access before it becomes too big of a pain.

Lock unneeded user accounts.
If people need APPS account access, set up proxy users.
Create some roles for named accounts. If people need to connect directly to the database, don’t try to manage all the privileges individually.
Make sure to use your custom tablespace as the default tablespace for all named accounts. Set up a different tablespace if you like, just don’t use a standard application tablespace.
Change all the passwords (see step 1 above).
5. Patch it up.

Before anyone gets in, lift the entire system to the highest possible rev. Once users and developers dig in, they aren’t going to want to make any fundamental changes, so patch your new system as high as you can right away. Core tech especially. Iin no particular order:

Latest CPU patches for all tiers
Java server version
Desktop JRE
Patchsets for technology components, e.g. 11.1.0.6 to 11.1.0.7, 10.1.3.0 to 10.1.3.4, etc. Follow the certification matrix on Metalink for certified combinations.
Updated family packs (Financials, HRMS, etc)
Individual product updates
Latest AD patchset
Latest Autoconfig templates
6. Back it all up and create a gold copy.

Once you’ve done all this work, create a cold backup. Next time you need a clean environment, just restore your gold copy. Sounds basic, but I’m amazed at how many people don’t back up an environment they really want to live with going forward; why repeat all of this work?

Of course there are many other steps – security, OS management, monitoring, ongoing backups, etc. But the steps above will get your users set up nicely so they won’t be bugging you and you won’t have to bug them any more than necessary while you all get your feet wet in your shiny new R12 environment