SROAUG N EWS

Southwest Regional Oracle Applications Users Group

March 2007 Volume 14, Issue 1

www.sroaug.oaug.org

Board of Directors Update

By Deborah Emmett, Newsletter Director
demmett@helio.com

Inside This Issue

BOD Update SROAUG Board of Directors Rapid Clone Advanced Techniques, Tips and Tricks for 11i environment cloning Oracle Safety Stock: The Decoder Ring (Updated) 1 1 2 8

SROAUG 2007 Conferences The SROAUG Board invites our members to join us at three scheduled local conferences in 2007. Our first full day conference will be held on Friday, March 23rd at the Crown Plaza, Los Angeles at LAX. This conference will be an extensive exploration of Oracle Release 12. We have selected July 13th and October 12th as the dates for our two conferences later in 2007. SROAUG In Las Vegas at Collaborate 07 Board members will be available at Collaborate 07 to meet with SROAUG members and potential members to learn how we can provide better service to the user community. Please meet with us at your convenience at one or more of the following times: Monday, April 16th 6:00-8:00 PM Tuesday, April 17th 11:45-1:00 PM Wednesday, April 18th 11:45-1:00 PM SROAUG will be awarded an OAUG Geo/SIG Certificate of Distinction at Collaborate 07 for its support of the OAUG mission to provide a forum for the sharing of information and fostering education and training programs for members during 2006 Invitation to Share Your Oracle Experience The SROAUG Board invites you to share your Oracle knowledge and experience. Please consider submitting an article, tip or trick that would be of interest to other Oracle users for publication in a future newsletter. Both technical and functional topics are welcome. Submissions may be sent to: umamaniac@hotmail.com or debemmett@aol.com

SROUAG Board of Directors

Position Chairperson/ Financial Director/ Treasurer Vice Chairperson Secretary Membership Director Communications Director Website Director Newsletter Director Newsletter Director Meeting Director Vendor/Sponsorship Director Vendor/Sponsorship Director Presentation Director Presentation Director Parliamentarian Oracle Liaison Oracle Liaison Name Brandon Behrstock Basheer Khan Sandra Vucinic Samir Sachdev Sandra Vucinic James Lui Deborah Emmett Uma Mani Les Sakai Sid Patki Charlton Wang Mike Adams Les Sakai Lisa Palermo Jennifer Huston Michael Barrette e-Mail Address bbgoto@yahoo.com bk@innowavetech.com sandrav@vladgroup.com ssachdev@mwdh2o.com sandrav@vladgroup.com jlui@intelligencia.com debemmett@aol.com umamaniac@hotmail.com lsakai@helio.com sid@sycamoresol.com Charlton@twindragonmarket ing.com mike.adams@innowavetech. com lsakai@helio.com lisa@peopleroa.com Jennifer.huston@oracle.com michael.barrette@Oracle.co m

Page 2

SROAUG News

Rapid Clone Advanced Techniques, Tips and Tricks for 11i environment cloning
4

Sandra Vucinic, VLAD Group, Inc., email: sandrav@vladgroup.com

11i Cloning overview and available methods Cloning is the process of creating an identical copy of an already existing Oracle Applications system. There are various reasons for cloning an Oracle Applications system such as: Creating a copy of the production system for testing updates. Migrating an existing system to new hardware. Creating a stage area to reduce patching downtime.

To clone an 11i Oracle Applications EBS environment there are various available cloning methods: Cloning using AD Clone utility (adclone.pl). Cloning using Rapid Clone. Custom cloning methods. Automated tools.

Most widely used method for 11i EBS system cloning is Rapid Clone. This method has been developed and supported by Oracle Corporation. Rapid Clone review Rapid Clone is a new cloning utility introduced in Oracle EBS 11i Release 11.5.8. Rapid Clone utility leverages the new installation and configuration technology utilized by Rapid Install. To determine if Oracle 11i EBS system is Rapid Clone enabled DBA needs to first verify that Oracle11i EBS system is AutoConfig enabled. It is also an imperative to review Rapid Clone prerequisite steps and to apply the latest Rapid Clone and AutoConfig Template patches provided by Oracle. Oracle development team very frequently releases AutoConfig and Rapid Clone patches. Please assure your Source system (applications system being cloned) is updated with the latest patches prior to starting the cloning process. The following are high level Rapid Clone steps: Please note the Source system is an applications system being cloned and target system is an applications system being created as a copy of the source system. Rapid Clone utility creates template files for cloning on the source system. After the source system is copied to the target, Rapid Clone updates these templates to contain the new target system configuration settings. Please note the Rapid Clone will not change the source system configuration. 1. Verify prerequisites. Before cloning, prepare the source system by applying any required patches and running AutoConfig. 2. Prepare Source System (database and apps). 3. Copy Source System to Target System.

Page 3
4. Configure Target System. 5. Complete finishing tasks.

SROAUG News

During Verify prerequisites phase of Rapid Clone DBAs needs to complete the following steps: Verify source and target nodes software versions. Apply the latest AutoConfig Template patch. Apply the latest Rapid Clone patches. Setup Rapid Clone on the Applications Tier. Setup Rapid Clone on the Database Tier. Maintain Snapshot information.

In the Prepare Source System phase of the Rapid Clone process DBA runs perl commands on the source database and applications tiers to gather specific configuration information of a source system. Please note the source environment is up and running and available for use while perl commands are running. In the Copy Source System to Target System phase of the Rapid Clone process DBA needs to copy the application tier file system from the source applications system to the target node. Please note both database and application process needs to be shutdown in this step. For environments on raw partitions or plan to use hot backup cloning for cloning DBA needs to recreate database control files manually and then use Rapid Clone to complete the remaining configuration steps on the target system (node). During the Configure Target System phase of the Rapid Clone process DBA runs perl commands on the target database and applications tiers to configure specific values (SID, paths, ports, hosts, etc ) of a target system. DBA should complete the following steps during the Finishing Tasks phase of Rapid Clone process: Update profile options. Update printer settings. Update workflow configuration settings. Verify the APPLCSF variable setting. Update the SESSION_COOKIE_DOMAIN value in ICX_PARAMETERS.

Each DBA should develop his or her own cookbook that contains post Rapid Clone tasks and steps. In the Rapid Clone tips section of this paper some additional finishing tasks will be outlined. Please note Rapid Clone method for EBS environment cloning is also applicable for cloning Oracle Applications Release 12. This document focuses in steps, methods and Rapid Clone process for Release 11i EBS.

Page 4
Advanced Rapid Clone Options

SROAUG News

This paper describes the following advanced cloning procedures for 11i EBS. Each one of these procedures will be reviewed in detail in the next paragraphs. 1. 2. 3. 4. 5. 6. Cloning single-node system to multi-node system Cloning multi-node system to multi-node system Reducing number of nodes in a multi-node system (merge appl_tops) Cloning RAC Adding nodes to an existing RAC environment Cloning shared appl_top configurations

I) Cloning single-node system to multi-node system This procedure allows the original single-node system to be cloned into a multi-node system. In 11i EBS environment the applications system comprises five server types:
o o o o o

Database server (database tier). Forms server (application tier). Web server (application tier). Concurrent Processing server (application tier). Administration server (application tier).

During the single-node to multi-node cloning process, each of these servers can be placed on its own node, resulting in a multi-node target system. DBA needs to complete the following steps as described in detail in the Rapid Clone review section pf this document: a) Verify prerequisites b) Prepare, copy and configure the cloned Applications System. When creating more than one application tier server node from a single node system, the copy and configure steps must be performed on each target node. DBA can specify the server type for each target node while answering the prompts during the target configuration step. The database ORACLE_HOME and database only need to be copied to the node on which the database will be run. c) Finishing tasks II) Cloning multi-node system to multi-node system A multi-node 11i EBS system can be cloned provided the number of nodes and distribution of servers in the target system matches that of the source system. To clone a multi-node system to a multi-node system, perform the cloning process on each node. For example, if the source system contains three nodes, perform the cloning process three times.
o o o

Clone source system node 1 to target system node 1. Clone source system node 2 to target system node 2. Clone source system node 3 to target system node 3.

Page 5
The database server node must be cloned first. III) Reducing number of nodes in a multi-node system (merge appl_tops)

SROAUG News

This process allows DBAs to clone a multi-node system to a single node system or a multi-node system to a multi-node system with a fewer nodes. DBA can use Rapid Clone method to clone a multi-node system to a single-node system (or a multi-node system with fewer nodes) by merging the APPL_TOPs file system together. In order to complete this process DBAs need to follow the procedure for Merging existing APPL_TOPs in Oracle Metalink document id: 233428.1 Merging existing APPL_TOPs. IV) Cloning RAC DBAs can use Rapid Clone to clone a RAC system. While cloning, DBA has a possibility to remove or add nodes to the cluster in the target RAC system. To clone a RAC system, DBA needs to perform the following tasks: a) Verify prerequisites:
o

Apply TXK patch 3571388 (AutoConfig support for Oracle RAC instances). Please note this patch could be obsolete in a future, so apply the available replacement patch. Migrate the source system cluster ORACLE_HOMEs to AutoConfig as documented in Oracle Metalink document id: 165195.1

b) Prepare the Source system: Choose one of the ORACLE_HOMEs on the source cluster. This ORACLE_HOME will be used as a master to create all the target cluster system ORACLE_HOMEs. Run "perl adpreclone.pl dbTier" on it. c) Copy Source system to the Target System:
o

Copy the master ORACLE_HOME from the source system to each node that will compose the target cluster. For example, if your source RAC system had 2 nodes, and you want to clone it to a 3 node target RAC system, you should copy the source master ORACLE_HOME to the 3 nodes on the target system. Copy the database files from the source to target system.

d) Configure Target System:

o

Log on to any ORACLE_HOME in the target cluster and run

adcfgclone.pl dbTier

This step configures the first node of the target system RAC cluster and recreates the database control files. The prompts, however, will gather information about every node in the target RAC cluster and the data will be re-used when configuring each subsequent node in the next step.

Page 6
o

SROAUG News
For each remaining RDBMS ORACLE_HOME in the target system, run the following command as the ORACLE file system owner: adcfgclone.pl dbTier If your database is version 10g or higher, DBA should run the following commands to register the database and the instance to the cluster manager: srvctl add database -d <database_name> -o <oracle_home> srvctl add instance -d <database_name> \ -i <instance_name> -n <host_name>

Please note that if the cluster manager is not on Linux (ORACM) or the database is version 10g or higher, DBA has to manually start up the cluster manager on the target system before running adcfgclone.pl command. Clone the application tier: DBA should follow the steps to prepare, copy and configure the application tier. When prompted for the database SID, DBA should specify any one of the RAC service names. If DBA plans to clone from RAC to non-RAC environment, same above steps needs to be followed , but copy the master ORACLE_HOME to one target node only, and answer "No" to the question "Target instance is a Real Application Cluster (RAC) instance (y/n)", when prompted by adcfgclone.pl. V) Adding nodes to an existing RAC environment DBAs can use Rapid Clone to add one or several nodes to an existing RAC Cluster. In order to accomplish this process DBA needs to perform the following tasks: Choose any one of the ORACLE_HOMEs in the existing cluster and run "perl adpreclone.pl dbTier" on it. This ORACLE_HOME will be used as a master to create the additional node(s). Copy the master ORACLE_HOME file system to the new node(s). Reconfigure the RAC Cluster to include the new node(s):
o

Log on to the new node, or any one of the new nodes if adding more than one, and run the following command: cd $ORACLE_HOME/appsutil/clone/bin perl adcfgclone.pl dbTier When instructed so by the previous step, log on to every node from the original cluster and run the following command on each of them: cd $ORACLE_HOME/appsutil/clone/bin
perl adcfgclone.pl addracnode <context file>

o o

Go back to the first node and complete adcfgclone.pl If DBA is adding more than one node to the original cluster, log on to each of the remaining new nodes and run
cd $ORACLE_HOME/appsutil/clone/bin perl adcfgclone.pl dbTier

Page 7
VI) Cloning shared appl_top configurations

SROAUG News

DBAs can use Rapid Clone method to clone a shared APPL_TOP system. Since all the nodes share a unique APPL_TOP DBAs only need to fully clone one of the source system nodes to its target machine and add more nodes directly sharing the APPL_TOP on the target system. Choose one of the shared APPL_TOP nodes on source system (the rest of this section will refer to it as Node A) and perform the following tasks: a) Prerequisites Perform these steps on Node A b) Prepare, copy and configure Perform a full clone (prepare, copy and configure steps) of the Database Tier and Node A (application tier). c) Add the shared file system nodes to the target system On the target system, follow the instructions for adding a node to a shared APPL_TOP system in document 233428.1adding a node to a shared APPL_TOP system in document 233428.1 on Oracle Metalink and add more nodes sharing the target system APPL_TOP to match the source system topology.

Sandra Vucinic has over thirteen years of experience with Oracle database administration specifically supporting Oracle Applications environments including installation, implementations, administration, maintenance, upgrades and remote support. Her focus is in areas of infrastructure planning, architecture design, review and support with emphasis on Oracle Applications implementations and upgrades. For years Sandra has been a presenter and panel member at OAUG, NCOAUG, CSOAUG, SROAUG, Oracle Apps World and Oracle Open World Conferences (40+ sessions). Sandra continues to be active in the OAUG organization. For a fifth year Sandra continues to serve on the Board of Directors for OAUG Database Special Interest Group and OAUG SysAdmin Special Interest Group. In 2004 Sandra joined the SROAUG Board as the Secretary Director and Communications Director. In 2005, Sandra has accepted a position on the OAUG Middleware Special Interest Group (formally known as Applications Technology Stack SIG) Board of Directors and currently serves as the Membership Director.

Page 8

SROAUG News

Oracle Safety Stock: The Decoder Ring Updated

4

Deborah Emmett, Helio LLC email: demmett@helio.com

An earlier version of this article was included in a previous edition of the SROAUG Newsletter. It has been updated to reflect changes in how MRP Planned safety stock is calculated in Oracle particularly in periods with a zero forecast quantity. Oracle provides four methods of entering/generating safety stock requirements for planned items. However, the Oracle documentation for these safety stock methods is often either incomplete or difficult to understand. This article discusses both the applicability of each of the safety stock methods relative to planning type and item demand as well as providing explanations and illustrations for sample safety stock calculations.

Safety Stock Method Applicability

Planning Method Reorder Point Planning Item Conditions No Item Forecast (Dependent Demand Item) Item Forecast (No History) Item Forecast (Forecast and Sales Order History) No Item Forecast (Dependent Demand Item) Item Forecast (No History) Item Forecast (Forecast and Sales Order History) NA User MRP Planned % NA NA NA NA NA NA Forecast Percent NA Forecast MAD NA NA

Defined

MRP Planning

Min-Max Planning

NA

NA

NA

User Defined User Defined safety stock in Oracle can be used whether or not an item has an Oracle forecast for both the Reorder Point and MRP Planning Methods. Two setups are required. The safety stock portion of the General Planning item attribute form is set to Non MRP Planned, Bucket Days =1 and Percent = 100. (Note that the percent entered here is not used in any calculation. However, MRP fails to pick up the User Defined Safety Stock values when these setups are left blank.) Under Inventory > Planning > Safety Stock a quantity must be entered for each item to which the user wants Oracle safety stock to be applied. The user determines the quantity entered. The quantity may either be applied indefinitely (no end date is specified) or different quantities can be entered with distinct start and end dates. If no end date is specified, the quantity entered will remain static as the safety stock requirement regardless of changes in business conditions (increase or decrease in demand) until the user resets it. User defined safety stock may be the only option if a companys business requirements such as the need to ramp down inventory from the start through the end of a quarter (without reference to a similarly ramped forecast) cannot be accomplished using any of the other safety stock methods.

Page 9

SROAUG News

MRP Planned MRP Planned safety stock in Oracle can be used only with MRP planning and can be used for items with an Oracle forecast or for dependent demand items. The safety stock portion of the General Planning item attribute form is set to MRP Planned, Bucket Days = as required and Percent = as required. Oracle will calculate the safety stock level based on the item requirements (dependent or independent demand) per the example below. This example is for a setup of MRP Planned, Bucket Days = 6, Percent = 100.
Total Requirement Across Bucket Days 1350 Average Bucket Quantity 225

Week 1 Forecast/ Requirement Oracle Safety Stock Calculation Safety Stock 500 =(500/ 1350)* (225*1) 83.3

Week 2 300 =(100/ 1350)* (225*1) 50

Week 3 200 =(300/ 1350)* (225*1) 33.3

Week 4 0 =(0+200/ 1350)* (225*1) 33.3

Week 5 150 =(150/ 1350)* (225*1) 25

Week 6 200 =(200/ 1350)* (225*1) 33.3

Percent 100

Oracle first calculates the Total Requirement across the specified number of bucket days (bucket level may be days, weeks, or periods). In this example the total is 1350. Oracle then calculates the Average Bucket Quantity. Safety stock for each period is calculated by dividing the period forecast quantity by the Total Requirement Across Bucket Days and multiplying the result by the Average Bucket Quantity multiplied by the setup forecast percent. However, the calculation is modified when the forecast for a period is zero to prevent the safety stock requirement from dropping to zero. In that case, the safety stock for the last period with a forecast value greater than 0 is carried forward until the next period with a forecast value greater than 0 when the calculation described above is resumed. An advantage of this method is that as business conditions change, safety stock calculations will reflect either increases or decreases in demand.

Forecast Percent Forecast Percent safety stock in Oracle can only be used when an item has an Oracle forecast and is applicable to both the Reorder Point and MRP Planning Methods. Two setups are required. The safety stock portion of the General Planning item attribute form is set to Non MRP Planned, Bucket Days =1 and Safety Stock Percent = as required. Under Inventory > Planning > Safety Stock Updates, a concurrent request must be initiated referencing the name of a Forecast in Oracle. Oracle then uses the Safety Stock Percent assigned to the item(s)/category in the named Forecast to compute the applied buffer quantity. When the bucket type being used is days, the Oracle calculation for Forecast Percent Safety Stock is what would be expected. However, when the bucket type is either weeks or periods Oracle adds a factor to the calculation.
Week 1 Forecast Oracle Safety Stock Calculation Safety Stock 500 =500*175/ (100*7) 125.0 Week 2 300 =300*175/ (100*7) 75.0 Week 3 200 =200*175/ (100*7) 50.0 Week 4 0 =0*175/ (100*7) 0.0 Week 5 150 =150*175/ (100*7) 37.5 Week 6 200 =200*175/ (100*7) 50.0 Percent 175 Workdays (between current week start date and next week start date) 7 (weekly bucket with 7 working day/week)

Page 10

SROAUG News

The example above shows the Safety Stock quantities that would be calculated for an item with the stated forecast using weekly buckets (with 7 working days) and an entry in the Percent field of the General Planning Item Attribute form of 175. The calculation computed by Oracle is the forecast amount multiplied by the entered Percent divided by 100 times the bucket workdays (7). Note that while the expected result in week 1 might intuitively have been 875 (175% of 500), the result is actually 125 (25% of 500) due to the division by the bucket workdays. Oracle applies a similar approach factoring by workdays when the planning bucket is a period (month). One outcome of this calculation is that the Oracle Safety Stock will be zero (0) when the forecast for a bucket are zero. An advantage of this method is that as business conditions change as reflected in the forecast, safety stock calculations will reflect either increases or decreases in forecast demand. Forecast MAD (Mean Absolute Deviation) Forecast Percent safety stock in Oracle can only be used when an item has an Oracle forecast and is applicable to both the Reorder Point and MRP Planning Methods. Two setups are required. The safety stock portion of the General Planning item attribute form is set to Non MRP Planned, Bucket Days =1 and Service Level Percent = as required. Under Inventory > Planning > Safety Stock updates a concurrent request must be initiated referencing the name of a Forecast in Oracle. Oracle then uses the Service Level Percent assigned to the item(s)/category in the named Forecast to compute the applied buffer quantity. MAD is a measure of the variance between two series of numbers. For the Forecast MAD calculation the two number series used are an Oracle forecast and the actual demand in each bucket for that forecast. If calculated MAD is low (this will be the case when forecast accuracy is high), comparatively low quantities of safety stock are required to achieve a target Service Level Percent. If calculated MAD is higher, the suggested safety stock quantity would be higher for the same forecast bucket quantity and Service Level Percent. The formula to calculate MAD is:

MAD =

l Dt - Ft l n

where, t = the period number Dt = demand in period t Ft = the forecast for period t n = the total number of periods l l = the absolute value

Oracle uses the returned MAD value in its Forecast MAD calculation: Safety Stock = Z x (1.25 x MAD) where, Z = value from a normal distribution probabilities table corresponding to the service level specified by the user Note that this is the basic formula used by Oracle for the Forecast MAD safety stock calculation. However, the actual C code computation is more complex making it difficult to exactly predict the Oracle result for a given set of data without the actual algorithm. When calculated MAD is low, it is generally financially feasible to carry the suggested level of safety stock necessary to achieve a 97-98% service level. However, the incremental inventory that would be required to achieve a 100% service level is often prohibitive and not justifiable using cost/benefit analysis