Oracle E-Business Suite R12 DBA Best Practices...EBS R12 DBA Best Practices • Oracle Applications DBA • Independent Consultant • 18+ years as an E-Business Suite DBA • 20+

Atherio.com © 2013 All rights reserved

Oracle E-Business Suite R12

DBA Best Practices

James J. Morrow

Senior Oracle Applications DBA

mailto:[email protected]

http://thedbalife.blogspot.com

Session #CON4733


http://thedbalife.blogspot.com/


EBS R12 DBA Best Practices

• Oracle Applications DBA

• Independent Consultant

• 18+ years as an E-Business Suite DBA

• 20+ years as a Unix/Linux Administrator

• E-Business Suite versions 9.4 through R12.1.3

• Oracle RDBMS 7.0.16 through 11.2.0.3

James J. Morrow



• Understand business expectations

• Understand business requirements

• Business may want 24x7 but may actually need less

Establish an SLA



• Typical “Financials” customer

• Office workers Monday-Friday 6:00AM to 7:00PM (local

time)

• Understand the requirements vs. expectations

Establish an SLA



• By understanding requirements vs. expectations we gain

flexibility

• You still have a 24x7 system

• During critical business hours downtime may be nearly

impossible to obtain

• However, by understanding requirements vs. expectations,

scheduling outages outside of critical business hours can

become easier

Establish an SLA



• Define/Document key stakeholders, approvers, notification

procedures for unscheduled outages

Establish an SLA



• Stable systems don't tend to have code updates (migrations,

patches) on an ad-hoc basis

• Changes are documented, rehearsed, validated

• Monthly or Weekly

Establish Regular Maintenance Windows



• Reduce ambiguity

• Reduce confusion

• Process leads to stability

Documented Procedures



• COB Monday, 6 days prior – The DBA will produce a list

of patches that are identified as potential promotion

candidates. This list will contain patches applied to lower

level environments that have not yet been migrated. The list

should be sent to various pre-defined approving personnel.

The DBA should also send out a calendar of “DBA Events”

for the next couple of months at this point.

Procedures: Maintenance Window



• COB Wednesday, 4 days prior – All patches destined for

PROD during the maintenance window should be applied to

the QA (PROD -1) instance.




• COB Thursday, 3 days prior – DBA will prepare a “Maintenance

Plan” for the outage (based on a standard template). DBA will also

create a Change Request in the CM portal with the Maintenance Plan

attached. The maintenance plan shall include:• Contact information for key individuals

• Email lists for individuals to be notified of specific changes upon completion

• General objectives for the maintenance window

• List of patches to be applied

• Patch prerequisite research

• List of tasks performed in advance of the outage

• List of tasks to be performed during the outage (with specific commands and

timing estimates, where applicable)




• COB Friday, 2 days prior – Management will give final

approval for the outage.




• Technically challenging

• Even though Oracle provides tools and documentation, site-

specific procedures are still required

Procedures: Cloning



• Site-specific steps• Preparation of the target environment

• Information about the nature of the backup that will be used

• Instructions on how the backup should be restored

• Detailed instructions on how the database should be recovered by the DBA

• Detailed instructions on how the Oracle cloning utilities are used

• Detailed instructions on extra post-cloning tasks

Procedures: Cloning



• Don't use default passwords!

• Change production passwords on a regular basis

• Enforce complex passwords

• Be aware of special characters

• Avoid sharing passwords whenever possible

• Delegation of authority

• Use a secure “Password Safe” when passwords need to be shared

Procedures: Password Change



• Code and patches should follow a strictly defined migration

path

DEVL → TEST → QA → PROD

• PROD and QA (PROD-1) should be restricted access

instances

Procedures: Migration



• Define/understand your organization’s patching philosophy

• Security Patches

• May be dictated externally

• PCI (Credit Card) requirements: Vendor supplied security

patches applied within 30 days

Patching Philosophy



Don't get caught in prerequisite hell

• Stay current on AD, TXK, ATG patches. They're the most

likely prerequisites!

• Minimum requirements for security patches

Patching Philosophy



• Patchsets.sh script (Note 139684.1 and Note 549180.1)sftp –o Port=2021 <mosusername>@sftp.oracle.com

cd support/outgoing/PATCHSET_COMPARE_TOOL

get patchsets.sh

• Patch Wizard in Oracle Applications Manager (Note

976188.1)

Patching Philosophy



• Premier Support for E-Business Suite 11.5.10 ended November 30,

2010. Extended ends November 30, 2013. (Note 1495337.1)

• Exceptions for 11i Sustaining:

• YE 2013 1099 Patches, and 3 payroll updates for FYE 2014 (US,

Canada, UK, Australia)

• SEV1 bugfixes, CPUs through December, 2015 NEW

• Minimum Baseline Patches for Extended Support

• 11.5.10 – After December 1, 2010 (Note 883202.1)

• Patch Wizard Update for 11i (Patch 9803629)

Patching Philosophy



• Release 12.0 Support Milestones

• January, 2007 – R12.0 Released

• February 1, 2012 - Premier Support Ends (R12.0.6)

(845809.1)

• Extended Support Fee waiver until January, 2015

• January, 2015 – Extended Support Ends

Patching Philosophy




• May, 2009 – R12.1 Released

• July 1, 2011 – You must apply R12.ATG_PF.B.delta.2 (R12.1.2

Technology RUP) (845809.1)

• February 1, 2012 – You must apply R12.ATG_PF.B.delta3 (R12.1.3

Technology RUP) (1066312.1)

• February 1, 2013 – You upgrade to EBS R12.1.3

• December, 2016 – R12.1.3 Premier Suport Ends NEW

• December, 2019 – R12.1.3 Extended Support Ends (1495337.1) NEW

Patching Philosophy




• September 19, 2013 – R12.2.2 Released to GA

• September, 2018 – Premier Support Ends NEW

• September, 2021 – Extended Support Ends NEW

Patching Philosophy



• Performance Impact

• Disk Management Impact

• Define maximum retention for all requests

• Schedule daily “blanket purge”

• Schedule more aggressive purges for specific jobs

Concurrent Managers: Purging



• Concurrent Manager Tuning is traffic management

• Tune based on runtime and frequency

• Jobs are either exiled from a queue or eligible for a queue

• Don't over-complicate your queues!

• Remember some jobs require specialized managers!

Concurrent Managers: Tuning



• Pin stored procedures (Except on RDBMS 11g!)

• PIND.sql (Note: 301171.1) [Note has been pulled]

• Gather Schema Statistics

• Run periodically

• Optimizer requires current statistics to effectively do it's job

Statistics and Pinning



• Use in all non-production environments

• Is NOT set by RapidClone

• Defined through Oracle Applications Manager

• Traps outgoing notifications

• Allow multiple users (testers) access to the mailbox

• Allows full-cycle testing of the outbound Workflow

Notification process

Workflow Mailer: Test Address (Outbound)



• Use in all non-production environments

• Is NOT set by RapidClone

• Defined through Oracle Applications Manager

• Prevents non-production instances stealing messages from

production

• Allows full-cycle testing of inbound Workflow processing

Workflow Mailer: Test Mailboxes (Inbound)






Contact Us

Headquarters76 S. Laura Street,

Suite 1702

Jacksonville, FL 32202

+1-904-791-8888

…………………….

Thank You!

James J. MorrowAtherio/Red River Solutions, Inc.


http://thedbalife.blogspot.com

@jjmorrow

Oracle E-Business Suite

R12 DBA Best Practices

Session #CON4733


http://thedbalife.blogspot.com/

Documents

Oracle E-Business Suite R12 DBA Best Practices...EBS R12 DBA Best Practices • Oracle Applications DBA • Independent Consultant • 18+ years as an E-Business Suite DBA • 20+