Oracle® Fusion Applications

Installing and Managing in an Oracle VM Environment

11g Release 8 (11.1.8)

E26570-16

June 2014

Documentation for users that describes how to install and configure Oracle Fusion Applications as an Oracle VM instance.

Oracle Fusion Applications Installing and Managing in an Oracle VM Environment, 11g Release 8 (11.1.8)

E26570-16

Copyright © 2014 Oracle and/or its affiliates. All rights reserved.

Primary Author: Emilio Jasso

Contributing Author: Bor-Ruey Fu

Contributing Author: Pranab Pradhan

Contributing Author: Ian Lawler

Contributing Author: Vickie Laughlin

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Contents

Preface

- Audience

- Documentation Accessibility

- Related Documents

- Conventions

What's New in This Guide

- New and Changed Features for 11g Release 8 (11.1.8)

1 Introduction to Oracle VM Installation

- 1.1 Overview

- 1.2 Oracle VM Installation Roadmap

2 Prerequisites for Oracle VM Deployment

- 2.1 Oracle VM Servers and Virtual IP Addresses

- 2.2 Allocate a Deployer Host

- 2.3 Set the Privilege Escalation Mechanism

- 2.4 Install Oracle VM Manager

- 2.5 Provide Access to NetApp or Sun Storage Server

- 2.6 Allocate BIG IP End Points

- 2.7 Create a Database

- 2.7.1 Applying Patches to Exadata

- 2.7.2 Configure spfile on the Database

- 2.7.3 Set Up an Oracle Real Application Clusters (RAC) Database

- 2.7.3.1 Database Parameters

- 2.7.3.2 Collect Oracle RAC Database Information

- 2.7.3.3 Specify a Stage Location

- 2.7.4 Set Up a Single-Instance Database

- 2.7.5 Change the Paths for DBA Directories

- 2.8 Prepare an Oracle Enterprise Manager Instance

- 2.8.1 Install Oracle Enterprise Manager 12c Cloud Control

- 2.9 Configure Standalone Oracle Identity Management

- 2.9.1 Three-Host Standalone Oracle Identity Management

- 2.9.2 Properties Specific to idsdb

- 2.9.3 New Additions for oiddb and oimdb

- 2.9.3.1 Single-Tenant IDM OID database-related properties

- 2.9.3.2 Single-Tenant IDM OIM Database-related Properties

- 2.9.4 Non-Oracle Fusion Customer Relationship Management Topology

- 2.10 Confirm the Oracle Virtual Assembly Builder Home is Accessible

- 2.11 Register Templates with Oracle VM Manager

- 2.12 Install the Oracle VM Automation Utility

- 2.13 Enable Secure Shell (SSH) for Deployer Host

3 Deployment of Oracle VM Templates

- 3.1 Prepare Deployment Properties

- 3.1.1 Additional Deployment Properties

- 3.1.1.1 Changed Default Deployment Properties Values

- 3.1.2 Deprecated Deployment Properties from Prior Releases

- 3.2 Run Deployment

- 3.2.1 Check the Status of createTopology

- 3.2.2 Check the Status of Each Oracle VM

- 3.3 Post-Rehydration Steps

- 3.3.1 Perform Postinstallation Tasks

- 3.3.1.1 Perform Postinstallation Tasks

- 3.3.2 Apply Oracle Fusion Middleware Patches

- 3.3.3 Apply Oracle Fusion Applications Patches

- 3.3.4 Oracle Fusion Applications Post-installation Steps

- 3.3.4.1 Manage User Passwords for Login Access to Applications Components

- 3.3.4.2 Enable Product Offering Functionality

- 3.4 Other Oracle VM Life Cycle Management Tasks

- 3.4.1 Scale Out the OHS Node

- 3.4.2 Scale Out the Primary Node

- 3.4.3 Remove a Deployed Topology (Optional)

- 3.4.4 Remove Exported Template Storage (Optional)

- 3.4.5 Rerun a Deployment (Optional)

- 3.5 Troubleshooting Oracle VM Deployment

- 3.5.1 Re-triggering Rehydration

- 3.5.2 Oracle VM Fails to Shutdown While Removing a Deployed Topology

- 3.5.3 Update Oracle Data Integrator (ODI) Server Startup Properties if High Availability is Enabled

4 Content Movement Services: Production-to-Test and Cloning

- 4.1 Perform a Production-to-Test Data Refresh

- 4.1.1 Introduction

- 4.1.1.1 Technical Assumptions and Requirements

- 4.1.1.2 Which Servers are Involved

- 4.1.1.3 What's Included in the Production-to-Test Package

- 4.1.1.4 Process Overview

- 4.1.2 Move the Required Oracle Identity Management Data

- 4.1.2.1 Prerequisites for Oracle Identity Management Movement

- 4.1.2.2 Execute Oracle Identity Manager Prerequisite Script

- 4.1.2.3 Move the Oracle Internet Directory

- 4.1.2.4 Run Oracle Identity Manager Post-Replication Script

- 4.1.2.5 Modify Oracle Platform Security Services Properties and Run the OPSS Script

- 4.1.3 Perform the Data Refresh

- 4.1.3.1 Register the Production-to-Test Components

- 4.1.3.2 Edit the Properties File

- 4.1.3.3 Execute the Production-to-Test Scripts

- 4.1.3.4 Apply Data Masking to Sensitive Data

- 4.2 Perform a Full Clone

- 4.2.1 Introduction

- 4.2.1.1 Concepts and Terminology

- 4.2.1.2 Technical Assumptions and Requirements

- 4.2.1.3 Process Overview

- 4.2.2 Prepare the Source and Create a Backup

- 4.2.3 Prepare the Destination Environment

- 4.2.4 Prepare Deployer Host and Fill Out Oracle VM Deploy Properties

- 4.2.4.1 Deployment Properties for Databases

- 4.2.4.2 Deployment Properties for Storage

- 4.2.4.3 Oracle Identity Management Properties

- 4.2.4.4 Beehive/webchat Properties (if using):

- 4.2.4.5 Set Cloning-Specific Block of Parameters

- 4.2.5 Run the Cloning Deployment

- 4.2.5.1 Set the Environment Variables and Invoke Deployment

- 4.2.5.2 Invoke the Deploy Script

- 4.2.5.3 Verify Status

- 4.2.6 Remove a Cloned Environment (Optional)

Glossary

Preface

The Oracle Fusion Applications Installing and Managing in an Oracle VM Environment describes how to install, configure, and manage instances of Oracle VM environments created from the Oracle VM templates for Oracle Fusion Applications. This document is applicable for the environments created from the official releases of Oracle VM templates for Oracle Fusion Applications Release 2 (11.1.2) and higher. The content is not applicable for any Oracle VM environments that are created using other methods.

Audience

This guide is intended for users who are installing, configuring, and managing an Oracle VM environment for Oracle Fusion Applications for the first time. Users should be comfortable with system administration tasks such as installing, setting up, and configuring Oracle Database 11g, installing and setting up Oracle VM manager, installing and managing Oracle Enterprise Manager, and applying patches on the computer where the product offerings will be installed.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

Related Documents

For more information, see the following documents:

- Oracle Fusion Applications Installation Guide

- Oracle Fusion Applications Administrator's Guide

- Oracle Fusion Middleware Administrator's Guide

- Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management (Oracle Fusion Applications Edition)

- Oracle Database Installation Guide for your platform

- Oracle Fusion Applications Common Implementation Guide

- Oracle Fusion Applications Patching Guide

- Oracle VM Documentation

Conventions

The following text conventions are used in this guide:

Convention

Meaning

boldface

Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary.

italic

Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values.

monospace

Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter.

What's New in This Guide

The following topics introduce the new and changed features of Oracle Fusion Applications Installation Guide for Oracle VM and other significant changes that are described in this guide, and provides pointers to additional information.

New and Changed Features for 11g Release 8 (11.1.8)

Oracle Fusion Applications Installation Guide for Oracle VM 11g Release 8 (11.1.8) includes the following new and changed features for this document.

Section 3.1.1.1

- Section 3.1.1 has been changed to reflect updated deployment properties. See: Section 3.1.1, "Additional Deployment Properties".

- Section 3.1 has been changed to reflect updated deployment properties. See: Section 3.1, "Prepare Deployment Properties".

- Section 2.9 has been altered to reflect that only 3-host standalone IDM is supported. See: Chapter 2, "Configure Standalone Oracle Identity Management".

- Table 2-1 has been altered to properly reflect current values. See: Table 2-1, "Suggested Memory (in GB) and Number of vCPUs".

- Section 2.8 has been altered to reflect the discontinuation of the use of Oracle Enterprise Manager 11g Grid Control See: Section 2.8, "Prepare an Oracle Enterprise Manager Instance".

1 Introduction to Oracle VM Installation

This chapter introduces the user to the installation and configuration of Oracle Fusion Applications as an Oracle VM instance.

This chapter includes the following sections:

- Section 1.1, "Overview"

- Section 1.2, "Oracle VM Installation Roadmap"

1.1 Overview

Oracle VM provides the topology required by Oracle Fusion Applications on a virtual server. An Oracle VM Template contains all of the software required to run a fully provisioned environment, including Oracle Database, Oracle Fusion Middleware, Oracle Identity Management, and Oracle Fusion Applications, all running on Oracle VM technology. It defines the topologies that will be deployed on Hypervisor servers along with associated artifacts, such as volumes and firewall configuration necessary to set up an Oracle Fusion Applications instance. The Oracle VM template is created using Oracle Fusion Applications Provisioning Installers with combinations of the following product configurations:

- Oracle Fusion Customer Relationship Management (Sales and Marketing), Enterprise Contracts, and Oracle Fusion Incentive Compensation

- Oracle Fusion Financials (Financials, Oracle Fusion Procurement, and Oracle Fusion Projects)

- Oracle Fusion Human Capital Management (Workforce Deployment, Workforce Development, and Compensation Management)

- Oracle Fusion Supply Chain Management (Product Management, Order Orchestration, Material Management and Logistics)

Note:

Oracle Fusion Accounting Hub is a subset of Financials product configuration. Customer Data Hub is a subset of CRM Sales and Marketing product configuration.

Table 1-1 displays a list of available templates along with their included product configurations. Each template has a fixed topology that cannot be altered.

Table 1-1 Oracle VM Templates and Product Configurations

Template Name

Included Product Configurations

GSI (Global Single Instance)

Oracle Fusion Customer Relationship Management, Enterprise Contracts, Incentive Compensation, Oracle Fusion Financials, Oracle Fusion Supply Chain Management, and Oracle Fusion Human Capital Management

CRM

Oracle Fusion Customer Relationship Management, Enterprise Contracts, and Incentive Compensation

HCM

Oracle Fusion Human Capital Management

The enterprise deployment architectures provided by Oracle VM templates implement High Availability (HA) because each component or functional group of software components is replicated on a different computer, and configured for component-level high availability. You choose whether you want HA or not during the creation of the Oracle VM instance. After you select the template that meets your needs, you complete the prerequisite steps to prepare the reference environment, and then you run the deployment steps to make the environment available for use (a reference environment is the environment delivered in the Oracle VM template). When you run the Oracle VM process, your entire Oracle Fusion Applications environment, except for the Oracle Fusion Applications Database, Oracle internet Directory Database, and Oracle Identity Management Database, runs on Oracle VM servers using Hypervisor. Outside of the Hypervisor, you need a deployer host where you install and run Oracle VM Manager to create and deploy Oracle VMs on the Hypervisor servers.

The deployment is the process that is triggered on the deployer host when the user invokes the faovmdeploy.sh createTopology command. During the process of deployment, the Oracle VM servers that are part of the topology are created from the Oracle VM template and are started. The initial phase of Oracle VM Deployment includes a process called rehydration, which performs additional reconfiguration steps that are specific to each Oracle VM. Before deployment, however, a set of prerequisites must be met to ensure that Oracle VM can be deployed properly. One of these steps is to establish a target database, an existing database located on a physical machine where Oracle VM Manager restores the Recovery Manager backup that is delivered as part of the Oracle VM template.

1.2 Oracle VM Installation Roadmap

The following table lists the high-level tasks included in the end-to-end Oracle VM Installation flow.

Table 1-2 Oracle VM Installation Flow

Task

Description

Documentation

Select the appropriate template.

Review the Oracle Fusion Applications product offerings included in each template.

"Selecting Product Offerings" in Oracle Fusion Applications Installation Guide

Complete prerequisites.

To install an Oracle VM environment, you must complete prerequisite steps to ensure that your system meets certain requirements and is configured properly.

Chapter 2, "Prerequisites for Oracle VM Deployment"

Prepare deployment properties.

Modify the properties file for the topology you are deploying.

Section 3.1, "Prepare Deployment Properties"

Run deployment.

Create the Oracle Fusion Applications topology, including Oracle Identity Management, onto the Oracle VMs.

Section 3.2, "Run Deployment"

Post-rehydration.

Perform post-rehydration steps.

Section 3.3, "Post-Rehydration Steps"

Scale out nodes.

Scale out the Oracle HTTP Server (OHS) and Primary nodes.

Section 3.4.1, "Scale Out the OHS Node", Section 3.4.2, "Scale Out the Primary Node"

Remove a deployed topology.

Remove a previously created topology, as needed.

Section 3.4.3, "Remove a Deployed Topology (Optional)"

Remove Exported Template Storage.

Remove pre-exported templates that are no longer needed.

Section 3.4.4, "Remove Exported Template Storage (Optional)"

Rerun a deployment.

Reset a database so a deployment can be rerun.

Section 3.4.5, "Rerun a Deployment (Optional)"

2 Prerequisites for Oracle VM Deployment

This chapter describes the prerequisites for the deployment of an Oracle VM Template.

This chapter includes the following sections:

- Section 2.1, "Oracle VM Servers and Virtual IP Addresses"

- Section 2.2, "Allocate a Deployer Host"

- Section 2.3, "Set the Privilege Escalation Mechanism"

- Section 2.4, "Install Oracle VM Manager"

- Section 2.5, "Provide Access to NetApp or Sun Storage Server"

- Section 2.6, "Allocate BIG IP End Points"

- Section 2.7, "Create a Database"

- Section 2.8, "Prepare an Oracle Enterprise Manager Instance"

- Section 2.9, "Configure Standalone Oracle Identity Management"

- Section 2.10, "Confirm the Oracle Virtual Assembly Builder Home is Accessible"

- Section 2.11, "Register Templates with Oracle VM Manager"

- Section 2.12, "Install the Oracle VM Automation Utility"

- Section 2.13, "Enable Secure Shell (SSH) for Deployer Host"

2.1 Oracle VM Servers and Virtual IP Addresses

The High Availability (HA) topologies require creation of the following Oracle VMs by default. You must have one or more Oracle VM servers that can host the following Oracle VMs.

- Node 1: (FA) Contains Administration Servers from all of the Oracle Fusion Applications domains.

- Node 2: (Primary) Contains all Managed Servers from Oracle Fusion Applications domains that need to scale out.

- Node 3: (Secondary) Contains the remaining Managed Servers from Oracle Fusion Applications domains.

- Node 4: Contains the Oracle Business Intelligence domain.

- Node 5: Contains the base Oracle HTTP Server (OHS) instance.

- Node 6: Contains the High Availability OHS instance and is optional.

- Node 7: Contains the primary Managed Servers and is a replica of Node 2. This node is optional.

- Node 8: Contains the secondary Managed Servers and is a replica of Node 3. This node is optional.

- Node 9: Contains the IDM OID.

- Node 10: Contains the IDM MW.

- Node 11: Contains the IDM OHS (also called Auth OHS).

Ensure that you allocate virtual host names and virtual IP addresses (static IPs) for each of these nodes. The Domain Name System (DNS) server used in the subnet where the Hypervisors and Oracle VMs reside must resolve the virtual host names and virtual IP addresses. During deployment you specify the values of virtual host names and virtual IP addresses in deployment properties. For more information, see Section 3.1, "Prepare Deployment Properties."

The following table displays suggested values for memory and number of virtual CPUs (vCPUs) for each topology.

Table 2-1 Suggested Memory (in GB) and Number of vCPUs

Node Type/Topology

CRM

HCM

GSI

Node 1 - FA

19 G 6 CPU

14 G 6 CPU

24 G 6 CPU

Node 2 - Primary

29 G 12 CPU

32 G 12 CPU

60 G 12 CPU

Node 3 - Secondary

59 G 12 CPU

61 G 12 CPU

85 G 12 CPU

Node 4 - BI

13 G 6 CPU

13 G 6 CPU

13 G 6 CPU

Node 5 - OHS

3 G 2 CPU

3 G 2 CPU

3 G 2 CPU

Node 9 - IDM3_OID

4 G 4 CPU

4 G 4 CPU

4 G 4 CPU

Node 10 - IDM3_MW

11 G 4 CPU

11 G 4 CPU

11 G 4 CPU

Node 11 - IDM3_OHS

1.5 G 2 CPU

1.5 G 2 CPU

1.5 G 2 CPU

The memory settings provided are a minimum number to successfully complete deployment and rehydration. Both the memory number and the number of vCPUs on an Oracle VM may be changed during deployment, according to requirements based on a formal sizing exercise.

At the end of deployment, the Administration Servers on the Node 1 are shut down and the memory allocated to this Oracle VM is reduced to only 1.5 GB after rehydration completes successfully. The memory is returned to the pool. This behavior is controlled by the following deployment properties.

faovm.ha.adminserver.shutdown=true
faovm.ha.fa.post.rehydrate.memory=1536

If you do not want the Node 1 Administration Servers to shutdown at the end of deployment, you can modify the properties as follows. For information about how to modify these properties, see Section 3.1, "Prepare Deployment Properties."

faovm.ha.adminserver.shutdown=false
faovm.ha.fa.post.rehydrate.memory=value_in_MB

If you set the property, faovm.ha.adminserver.shutdown=false, the Administration Servers stay up and the memory is not changed. If you leave this property set to true but increase the post.rehydrate.memory from 1536, then you are specifying the quantity of memory allocated to the Oracle VM after shutting down the servers.

If you leave the settings at their original values, true and 1536, to get enough memory returned to the Oracle VM to start the Administration Servers, you need to perform the following on the Oracle VM:

login as root
echo 30000MB > /proc/xen/balloon

After this step, you can start the Administration Servers. Note that when you use the previous method to increase the memory of the Oracle VM, you can increase the memory only up to the value that was initially allocated for the Oracle VM during rehydration.

2.2 Allocate a Deployer Host

Allocate one server host, which can be a smaller machine, as a deployer host. You can use this host to run Oracle VM Manager, mount the Oracle Virtual Assembly Builder home with the templates, and run the deployment. The deployment uses network and disk resources, so two vCPUs and 4 GB of RAM are sufficient.

Do not use one of your Oracle VM servers (Hypervisors) as the deployer host because Hypervisors are not suited for heavy I/O processing and may lock up.

2.3 Set the Privilege Escalation Mechanism

Certain operations that run from the deployer host require root privilege. There are four deployment properties that control how root privileges are obtained, as shown in the following examples. Note that lines beginning with a pound sign, '#', are comments.

# Deploy-only privilege escalation properties, supported methods: run_as_root, sudo, pbrun
faovm.privilege.escalation.method=run_as_root

# If escalating via run_as_root, path to properly configured run_as_root binary relative to deployfw
faovm.privilege.escalation.run_as_root.path=bin/run_as_root

#faovm.privilege.escalation.run_as_root.path=/usr/local/packages/aime/ias/run_as_root
#Supported privilege escalation methods: none, sudo, pbrun
#If escalating via sudo, path to sudo binary:
faovm.ha.fusiondb.new.host.privilege.escalation.sudo.path=/usr/bin/sudo

# If escalating via pbrun, path to pbrun binary
faovm.ha.fusiondb.new.host.privilege.escalation.pbrun.path=/path/to/pbrun
faovm.ha.fusiondb.new.host.privilege.escalation.pbrun.policy.name=policy1-root

The property, faovm.privilege.escalation.method, takes a value of run_as_root, sudo, or pbrun, as the method to obtain root privilege. The corresponding properties, faovm.privilege.escalation.x.path where x is run_as_root, sudo or pbrun, specify where the corresponding root privilege utility is located.

The property, faovm.privilege.escalation.run_as_root.path specifies where the run_as_root utility is located. The Oracle VM Automation Utility, described in Section 2.12, "Install the Oracle VM Automation Utility", includes the run_as_root utility in the FAOVM/deployfw/bin directory. You can prepare the FAOVM/deployfw/bin/run_as_root utility by following these steps before starting the deployment:

1. Become the root user on the deployer host.

2. Run these commands:

chown root deployfw/bin/run_as_root
chmod u+s deployfw/bin/run_as_root

If you want to use sudo or pbrun instead, then set the faovm.privilege.escalation.method property to sudo or pbrun, and update the location of the utilities as shown in the following example:

# If escalating via sudo, path to sudo binary
faovm.privilege.escalation.sudo.path=/usr/bin/sudo

# If escalating via pbrun, path to pbrun binary
faovm.privilege.escalation.pbrun.path=/path/to/pbrun

2.4 Install Oracle VM Manager

Oracle VM Manager orchestrates the deployment. Follow the steps in the Oracle VM Manager Installation Guide to install Oracle VM Manager on your deployer host.

http://download.oracle.com/docs/cd/E15458_01/doc.22/e15439/toc.htm

After you install Oracle VM Manager, register your Oracle VM server pools with the Oracle VM Manager. For more information, see Section 2.11, "Register Templates with Oracle VM Manager."

2.5 Provide Access to NetApp or Sun Storage Server

Access to a NetApp or a Sun Storage Server is required so that Oracle Fusion Applications Oracle VM automation can create volumes required for deployment. For each deployment instance, the following volumes are created on the storage server during the deployment process if you are using NetApp or Sun Storage Server. If you are using generic Network File System (NFS), then the following volumes must be created and must exist before the deployment process begins. During deployment, the file volumes are mounted in the respective Oracle VMs. To configure the storage server, see Step 5 of Section 3.1, "Prepare Deployment Properties."

- Volume 1: Shared by the FA, Primary, Secondary, and BI nodes (120 GB) The name of volume 1 must be specified for the faovm.ha.fa.storage.name deployment property.

- Volume 2: Used by the OHS nodes. (12 GB) The name of volume 2 must be specified for the faovm.ha.ohs.storage.name deployment property.

- Volume 3: Shared by IDM3_OID and IDM3_MW nodes. (25 GB) The name of volume 3 must be specified for the faovm.ha.idm3oid.storage.name deployment property.

- Volume 4: Used by IDM3_OHS node (10 GB) The name of volume 4 must be specified for the faovm.ha.idm3ohs.storage.name deployment property.

The volume sizes specified are based on the assumption that Volume 1 consumes approximately 90 GB after rehydration and that OHS and WebChat use approximately 8 GB. These volume sizes can be adjusted during deployment.

2.6 Allocate BIG IP End Points

Allocate BIG IP end points, both external and internal, for the Oracle VM topology deployment. The following two tables illustrate examples of BIG IP end points and their mappings to OHS virtual host end points. Replace OHS_VM_IP_ADDR with the IP address of your OHS Oracle VM. The port values for internal end points and the mapped OHS virtual host end points, both internal and external, are fixed and should have the exact values listed. Note that not all end points may be required for all topologies. For example, the end point for ICDomain will not be required for any of the published topologies, but Oracle reserves these ports for future use.

Table 2-2 Internal BIG IP End Points (HTTP - Non-SSL)

Domain

Internal End Point (host:port)

Mapped to OHS Virtual Host End Point (host:port)

CommonDomain

gsi-elha-fs-int.example.com:10613

OHS_VM_IP_ADDR:10613

HCMDomain

gsi-elha-hcm-int.example.com:10619

OHS_VM_IP_ADDR:10619

CRMDomain

gsi-elha-crm-int.example.com:10615

OHS_VM_IP_ADDR:10615

FinancialDomain

gsi-elha-fin-int.example.com:10603

OHS_VM_IP_ADDR:10603

ProjectsDomain

gsi-elha-prj-int.example.com:10605

OHS_VM_IP_ADDR:10605

ProcurementDomain

gsi-elha-prc-int.example.com:10607

OHS_VM_IP_ADDR:10607

ProcurementDomain (Supplier Portal)

gsi-elha-prc-sp-int.example.com:10609

OHS_VM_IP_ADDR:10609

SCMDomain

gsi-elha-scm-int.example.com:10617

OHS_VM_IP_ADDR:10617

BIDomain

gsi-elha-bi-int.example.com:10621

OHS_VM_IP_ADDR:10621

ICDomain

gsi-elha-ic-int.example.com:10611

OHS_VM_IP_ADDR:10611

IDMDomain

gsi-cln-ha-ldap-int.example.com:7777

IDM_Auth_OHS_IP_ADDR:7777

IDM Admin

gsi-cln-ha-ldap-admin.example.com:443

IDM_Auth_OHS_IP_ADDR:7777

Table 2-3 External BIG IP End Points (HTTPS - SSL enabled)

Domain

External End Point (host:port)

Mapped to OHS Virtual Host End Point (host:port)

CommonDomain

gsi-elha-fs-ext.example.com:10614

OHS_VM_IP_ADDR:10614

HCMDomain

gsi-elha-hcm-ext.example.com:10620

OHS_VM_IP_ADDR:10620

CRMDomain

gsi-elha-crm-ext.example.com:10616

OHS_VM_IP_ADDR:10616

FinancialDomain

gsi-elha-fin-ext.example.com:10604

OHS_VM_IP_ADDR:10604

ProjectsDomain

gsi-elha-prj-ext.example.com:10606

OHS_VM_IP_ADDR:10606

ProcurementDomain

gsi-elha-prc-ext.example.com:10608

OHS_VM_IP_ADDR:10608

ProcurementDomain (Supplier Portal)

gsi-elha-prc-sp-ext.example.com:10610

OHS_VM_IP_ADDR:10610

SCMDomain

gsi-elha-scm-ext.example.com:10618

OHS_VM_IP_ADDR:10618

BIDomain

gsi-elha-bi-ext.example.com:10622

OHS_VM_IP_ADDR:10622

ICDomain

gsi-elha-ic-ext.example.com:10612

OHS_VM_IP_ADDR:10612

IDMDomain

gsi-cln-ha-login.example.com:443

OHS_VM_IP_ADDR:7777

IDM Admin

gsi-cln-ha-ldap-admin.example.com:443

IDM_Auth_OHS_IP_ADDR:7777

2.7 Create a Database

The Oracle Fusion Applications database, Oracle Internet Directory database, and Oracle Identity Management database that is delivered as part of the Oracle VM template was created by an RMAN backup. The Oracle VM process restores this backup to an already existing database, called the target database. The target database can be either a two-node Oracle Real Application Cluster (Oracle RAC) or a single instance database and should be on a physical machine, not an Oracle VM. This means no Oracle Database server is running in any of the Oracle VM servers listed in Section 2.1, "Oracle VM Servers and Virtual IP Addresses". For this release, the supported database version is Oracle Database 11.2.0.3.

Review these sections to prepare your database:

- Section 2.7.1, "Applying Patches to Exadata"

- Section 2.7.2, "Configure spfile on the Database"

- Section 2.7.3, "Set Up an Oracle Real Application Clusters (RAC) Database"

- Section 2.7.4, "Set Up a Single-Instance Database"

2.7.1 Applying Patches to Exadata

For customers on the Linux64 operating system who use the Oracle Exadata Database Machine, please download and apply patch p13734832_112030_Linux-x86-64.zip from Oracle Support, making sure to follow any manual patch postinstallation steps described in the readme file for the patch.

Then, the following patches for Generic and Linux64 must be applied with the included considerations:

Generic/Linux Patch

Exadata Equivalent

p13508115_112030_Generic.zip

Apply as is

p10263668_112030_Linux-x86-64.zip

Download and apply the overlay patch on 11.2.0.3.5ExadataDatabase for the same Bug number

p12312133_112030_Linux-x86-64.zip

Download and apply the overlay patch on 11.2.0.3.5ExadataDatabase for the same Bug number

p12358083_112030_Linux-x86-64.zip

Apply as is

p12672969_112030_Linux-x86-64.zip

Ignore (included in p13734832_112030_Linux-x86-64.zip)

p12772404_112030_Linux-x86-64.zip

Download and apply the overlay patch on 11.2.0.3.5ExadataDatabase for the same Bug number

p12880299_112030_Linux-x86-64.zip

Apply as is

p12889054_112030_Linux-x86-64.zip

Ignore (included in p13734832_112030_Linux-x86-64.zip)

p12977501_112030_Linux-x86-64.zip

Apply as is

p12985184_112030_Linux-x86-64.zip

Apply as is

p13014128_112030_Linux-x86-64.zip

Apply as is

p13073340_112030_Linux-x86-64.zip

Apply as is

p13257247_112030_Linux-x86-64.zip

Ignore (included in p13734832_112030_Linux-x86-64.zip)

p13365700_112030_Linux-x86-64.zip

Apply as is

p13382280_112030_Linux-x86-64.zip

Download and apply the overlay patch on 11.2.0.3.5ExadataDatabase for the same Bug number

p13404129_112030_Linux-x86-64.zip

Apply as is

p13454210_112030_Linux-x86-64.zip

Ignore (included in p13734832_112030_Linux-x86-64.zip)

p13503598_112030_Linux-x86-64.zip

Ignore (included in p13734832_112030_Linux-x86-64.zip)

p13714926_112030_Linux-x86-64.zip

Download and apply the overlay patch on 11.2.0.3.5ExadataDatabase for the same Bug number

p13775960_112030_Linux-x86-64.zip

Download and apply the overlay patch on 11.2.0.3.5ExadataDatabase for the same Bug number

p13787482_112030_Linux-x86-64.zip

Apply as is

p13790109_112030_Linux-x86-64.zip

Download and apply the overlay patch on 11.2.0.3.5ExadataDatabase for the same Bug number

p13983131_112030_Linux-x86-64.zip

Download and apply the overlay patch on 11.2.0.3.5ExadataDatabase for Bug 13949189

p14019600_112030_Linux-x86-64.zip

Download and apply the overlay patch on 11.2.0.3.5ExadataDatabase for Bug 14192095

p14029429_112030_Linux-x86-64.zip

Apply as is

p14058884_112030_Linux-x86-64.zip

Apply as is

p14143796_112030_Linux-x86-64.zip

Download and apply the overlay patch on 11.2.0.3.5ExadataDatabase for Bug 14235967

p14237907_112030_Linux-x86-64.zip

Download and apply the overlay patch on 11.2.0.3.5ExadataDatabase for Bug 14179751

2.7.2 Configure spfile on the Database

The RMAN restore procedure relies on the target database being configured with an spfile. Follow these steps to add an spfile file to the database:

1. Log in as the sys user.

2. For the following command:

create spfile from pfile = 'ORACLE_HOME/dbs/initORACLE_SID.ora';

replace ORACLE_HOME and ORACLE_SID with the value of the database that you created and run the command.

If an spfile does not exist for the target database before running the RMAN restore, an error occurs, related to not being unable to find /dbs/spfile.

2.7.3 Set Up an Oracle Real Application Clusters (RAC) Database

The following is the setup for a two-node Oracle RAC database for Oracle VM deployment. See Section 2.7.4, "Set Up a Single-Instance Database" for the setup of a single instance database.

2.7.3.1 Database Parameters

The following table describes the recommended database parameters that should be set before database cloning.

Table 2-4 Recommended Fusion Applications Database Parameters for Oracle 11.2.0.3

Parameter

Recommended Value for Starter

Recommended Value for Production

_fix_control

5483301:OFF, 6708183:ON

5483301:OFF, 6708183:ON

_b_tree_bitmap_plans

FALSE

FALSE

audit_trail

NONE

NONE

nls_sort

BINARY

BINARY

open_cursors

500

500

pga_aggregate_target

4 GB

8 GB

plsql_code_type

NATIVE

NATIVE

processes

5000

5000

session_cached_cursors

500

500

sga_target

9 GB

18 GB

undo

6 GB; autoextend ON

6 GB; autoextend ON

temp

6 GB; autoextend ON

6 GB; autoextend ON

redo

3 groups; each 2 GB per database instance

3 groups; each 2 GB per database instance

DB_SECUREFILE

ALWAYS

ALWAYS

PARALLEL_MAX_SERVERS

CPU_COUNT

CPU_COUNT

JOB_QUEUE_PROCESSES

CPU_COUNT

CPU_COUNT

add_active_session_legacy_behavior

TRUE

TRUE

The following table describes the recommended Oracle Internet Directory Database parameters for Oracle 11.2.0.3

Table 2-5 Recommended Oracle Internet Directory Database Parameters for Oracle 11.2.0.3

Parameter

Recommended Value

db_securefile

Always

parallel_max_servers

cpu_count

job_queue _processes

cpu_count

_b_tree_bitmap_plans

FALSE

audit_trail

NONE

nls_sort

BINARY

open_cursors

500

session_cached_cursors

500

plsql_code_type

NATIVE

processes

2500

sga_target

4 GB

pga_aggregate_target

2 GB

undo

6 GB

temp

6 GB

redo

3 groups; each 2 GB per database instance

The following table contains recommended Oracle Internet Management Database parameters for Oracle 11.2.0.3.

Table 2-6 Recommended Oracle Internet Management Database Parameters for Oracle 11.2.0.3

Parameter

Recommended Value

db_securefile

Always

parallel_max_servers

cpu_count

job_queue _processes

cpu_count

_b_tree_bitmap_plans

FALSE

audit_trail

NONE

nls_sort

BINARY

open_cursors

500

session_cached_cursors

500

plsql_code_type

NATIVE

processes

2500

sga_target

4 GB

pga_aggregate_target

2 GB

undo

6 GB

temp

6 GB

redo

3 groups; each 2 GB per database instance

When changing Oracle RAC database parameters to conform with Performance, Scalability and Reliability (PSR) requirements, use and update the spfile in Oracle Automatic Storage Management. Do not save the parameters to a local spfile. The Oracle VM database restore process uses and updates only the Oracle Automatic Storage Management spfile. Oracle VM assumes that the location of the Oracle Automatic Storage Management spfile is:

spfile='+DATADISCGROUP/RACDBNAME/spfileRACDBNAME.ora'

For example:

spfile='+DATA_SLCC10/dbm/spfiledbm.ora'

In this example, DATA_SLCC10 is the Data Disc Group name and dbm is the Oracle RAC database name.

2.7.3.2 Collect Oracle RAC Database Information

Collect the following information about your Oracle RAC database, which is required when you specify input property values in the deploy.properties file before deployment:

- Oracle RAC service name

- Physical host names for the two-node Oracle RAC database

- SID values for the two-node Oracle RAC database

- Listener port for the two-node Oracle RAC database, where the ports must be the same on each instance

- Oracle home

- Operating system user credentials that own the Oracle RAC instance, generally for the oracle user

- SYS schema credentials

- Oracle Automatic Storage Management DATA disc and REDO disc names

- Path to the folders where datafiles, temporary files and redo logs will be restored. You may want to query the Oracle RACs Oracle Automatic Storage Management to get these values.

- Path to the spfile in Oracle Automatic Storage Management.

2.7.3.3 Specify a Stage Location

Specify a stage location that is not in the Oracle Automatic Storage Management, to which the contents of the Recovery Manager (RMAN) database backup tar.gz file can be unpacked in preparation for the RMAN restore. The deployment process will restore the RMAN backup of the reference environment database to the target Oracle RAC database using the first node of the two-node Oracle RAC.

2.7.4 Set Up a Single-Instance Database

Restoring to a single-instance database is similar to restoring to a Oracle RAC database, with the following exceptions:

- Set the faovm.ha.fusiondb.new.is.rac property to false.

- If the single instance database (SIDB) is not configured to use Oracle Automatic Storage Management, then you must provide database data file paths to these properties: faovm.ha.fusiondb.new.datafile.path, faovm.ha.fusiondb.new.tempfile.path, and faovm.ha.fusiondb.new.recolog.path. These must be set to the absolute path of the folder where the target database stores data/temp files.
Run show parameter control_files; in SQLPlus before running deploy, to find this path.

- Leave the properties for Oracle RAC, faovm.ha.fusiondb.new.datadisc, and faovm.ha.fusiondb.new.recodisc as they are, but do not leave them empty.

- Set the service name to be the same as the SID.

- If the single instance database is configured to use Oracle Automatic Storage Management, the following properties should be filled with the correct Oracle Automatic Storage Management disc group names: faovm.ha.fusiondb.new.datafile.path, faovm.ha.fusiondb.newtempfile.path, faovm.ha.fusiondb.new.recolog.path, faovm.ha.fusiondb.new.spfile, fusiondb.new.datadisc, and fusiondb.new.recodisc. You may want to query the Oracle Automatic Storage Management to get these values.

- Set the listener port in fusiondb.new.port.

- Set both faovm.ha.HOST_DB and faovm.ha.HOST_DB2 equal to the database host.

2.7.5 Change the Paths for DBA Directories

To create an Oracle Fusion Applications database, several DBA directories must be set accordingly and manually created on the file system. The paths of the DBA directories are defined in the deployment properties file using the following properties. For more information, see Section 3.1, "Prepare Deployment Properties".

# dba_directories configuration (can add as many as needed)
faovm.ha.fusiondb.new.oracle.base=/u01/app/oracle/product/11.2.0
faovm.ha.fusiondb.new.dba.dir.name0=APPLCP_FILE_DIR
faovm.ha.fusiondb.new.dba.dir.path0=${fusiondb.new.oracle.home}/incident_logs
faovm.ha.fusiondb.new.dba.dir.name1=APPLLOG_DIR
faovm.ha.fusiondb.new.dba.dir.path1=${fusiondb.new.oracle.home}/appllog_dir
faovm.ha.fusiondb.new.dba.dir.name2=ADMIN_DIR
faovm.ha.fusiondb.new.dba.dir.path2=${fusiondb.new.oracle.home}/rdbms/admin
faovm.ha.fusiondb.new.dba.dir.name3=EQ_CONFIG_DIR
faovm.ha.fusiondb.new.dba.dir.path3=${fusiondb.new.oracle.home}/search/webapp/config
faovm.ha.fusiondb.new.dba.dir.name4=XMLDIR
faovm.ha.fusiondb.new.dba.dir.path4=${fusiondb.new.oracle.home}/rdbms/xml
faovm.ha.fusiondb.new.dba.dir.name5=EQ_LANG_DIR
faovm.ha.fusiondb.new.dba.dir.path5=${fusiondb.new.oracle.home}/search/data/language
faovm.ha.fusiondb.new.dba.dir.name6=ORACLE_OCM_CONFIG_DIR
faovm.ha.fusiondb.new.dba.dir.path6=${fusiondb.new.oracle.home}/ccr/state
faovm.ha.fusiondb.new.dba.dir.name7=DATA_PUMP_DIR
faovm.ha.fusiondb.new.dba.dir.path7=${fusiondb.new.oracle.base}/admin/${fusiondb.new.service.name}/dpdump
faovm.ha.fusiondb.new.dba.dir.name8=EQ_CACHE_DIR
faovm.ha.fusiondb.new.dba.dir.path8=${fusiondb.new.oracle.base}/oradata/${fusiondb.new.service.name}/cache

If you do not change these properties in the deployment property file, then manually create the following directories on the database server where ORACLE_HOME is the Oracle Database home directory:

/u01/app/oracle/product/11.2.0_CHANGEME
ORACLE_HOME/incident_logs
ORACLE_HOME/appllog_dir
ORACLE_HOME/rdbms/admi
ORACLE_HOME/search/webapp/config
ORACLE_HOME/rdbms/xml
ORACLE_HOME/search/data/language
ORACLE_HOME/ccr/state
ORACLE_HOME/admin/fusion_apps_database_service_name/dpdump
ORACLE_HOME/oradata/fusion_apps_database_service_name/cache

2.8 Prepare an Oracle Enterprise Manager Instance

The Oracle VM deployment process installs an Oracle Enterprise Manager agent into each of the Oracle VMs in the topology. You must prepare an Oracle Enterprise Manager 12c Cloud Control instance (Cloud Control) for the wiring of these agents.

2.8.1 Install Oracle Enterprise Manager 12c Cloud Control

Perform the following steps to prepare a Cloud Control instance.

1. Refer to the Oracle Enterprise Manager Cloud Control Basic Installation Guide to install this product.

2. Download and deploy the Oracle Fusion Applications plug-in in your Cloud Control. This is required for the discovery of the deployed Oracle Fusion Applications OVM topology into Cloud Control. For more information, follow the steps in "Deploying and Updating Plug-ins" in the Oracle Enterprise Manager Cloud Control Administrator's Guide.

3. Ensure that you can deploy the Java VM Diagnostics (JVMD) Manager on your Oracle Enterprise Manager 12c Oracle Management Service. This is required for the JVMD agent deployment that occurs as part of the Oracle Fusion Applications Oracle VM rehydration. For more information, see "Installing JVM Diagnostics" in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

4. Apply Bundle Patch 1 as described in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

2.9 Configure Standalone Oracle Identity Management

If you use the single-tenant or standalone templates, a standalone 11g Oracle Identity Management Oracle VM is rehydrated as part of the deployment process. This Oracle VM can be deployed in one of two ways: using a single host or using three hosts.

2.9.1 Three-Host Standalone Oracle Identity Management

When using single-tenant templates, you have the option of deploying the IDM in an EDG-compliant three-host configuration where the IDM is split as follows:

- Host 1: OID

- Host 2: OIM

- Host 3: AuthOHS

These components cannot be rearranged. To tell the deployer to create these three hosts, the faovm.topo.ovms property must look like this:

foavm.topo.ovms=idm3oid,idm3mw,idm3ohs,fa,secondary,primary,bi,webchat

In this scenario, the following properties must be set:

faovm.ha.HOST_IDSDB=idsdb_hostname
faovm.ha.HOST_IDSDB2=idsdb2_hostname
faovm.ha.HOST_OIDDB=oiddb_hostname
faovm.ha.HOST_OIDDB2=oiddb2_hostname
faovm.ha.HOST_OIMDB=${HOST_IDSDB}
faovm.ha.HOST_OIMDB2=${HOST_IDSDB2}
faovm.ha.HOST_LDAP=ldap_host.com
faovm.ha.HOST_PSTORE=${HOST_LDAP}
faovm.ha.HOST_OIM=idm3mw_hostname
faovm.ha.HOST_OAM=${HOST_OIM}
faovm.ha.HOST_WEBGATE=idm3ohs_hostname

Properties beginning with the prefix faovm.ha.idm3.* must be configured. Properties beginning with faovm.ha.idm1.* can be ignored.

Optionally, you can uncomment the following properties to replace the user name and password for the Fusion Application administration user in the identity store:

#faovm.ha.idm3oid.faappsadmin.username=fa_admin_user_name
#faovm.ha.idm3oid.faappsadmin.password=password

For more information on creating and managing users, see "Provisioning Identities" in Oracle Fusion Applications Administrator's Guide

Note also that when using a shared Oracle Identity Management, the property faovm.topo.ovms should not contain an entry for any Identity Management related nodes.

2.9.2 Properties Specific to idsdb

The faovm.idsdb.new properties are used to wire up the Oracle Fusion Applications OWSM datasources to the ids database. You need to replace dbname, port, sid1, sid2, port1, and port2 with values that match the Oracle Identity Management database.

# IDM Database-related properties, these must be specified whether MTIDM is enabled or not
faovm.idsdb.new.is.rac=true
faovm.idsdb.new.dbname=oimdb917
faovm.idsdb.new.service.name=${idsdb.new.dbname}
faovm.idsdb.new.sid=${idsdb.new.dbname}
faovm.idsdb.new.port=1917
faovm.idsdb.new.rac.sid1=oimdb917a
faovm.idsdb.new.rac.sid2=oimdb917b
faovm.idsdb.new.rac.port1=1917
faovm.idsdb.new.rac.port2=1917
faovm.idsdb.new.rac.dbhost1=${HOST_IDSDB}
faovm.idsdb.new.rac.dbhost2=${HOST_IDSDB2}

2.9.3 New Additions for oiddb and oimdb

The following new properties enable Oracle VM automation utility to locate the database backup for each of the external databases for Oracle Internet Directory and Oracle Identity Management. They provide attributes necessary to restore database backup to the remote, pre-requisite database shell and then wire the single tenant IDM to these database instances.

2.9.3.1 Single-Tenant IDM OID database-related properties

You must enter values that match the external OID database for the following properties: dbname, port, sid1, sid2, port1, port2, owner.user.name, and password.

# Source/reference OID database information
faovm.ha.oiddb.src.backup.dir=idm/oiddb
faovm.ha.oiddb.src.backup.archive=${oiddb.src.backup.dir}/dbbackup.tar.gz

# Target/New OID database-related properties
faovm.ha.oiddb.new.is.rac=true
faovm.ha.oiddb.new.dbname=oiddb817
faovm.ha.oiddb.new.service.name=${oiddb.new.dbname}
faovm.ha.oiddb.new.sid=${oiddb.new.dbname}
faovm.ha.oiddb.new.port=1817
faovm.ha.oiddb.new.rac.sid1=oiddb817a
faovm.ha.oiddb.new.rac.sid2=oiddb817b
faovm.ha.oiddb.new.rac.port1=1817
faovm.ha.oiddb.new.rac.port2=1817
faovm.ha.oiddb.new.rac.dbhost1=${HOST_OIDDB}
faovm.ha.oiddb.new.rac.dbhost2=${HOST_OIDDB2}

# Target/New OID database-restore-related properties
faovm.ha.oiddb.new.do.restore=true
faovm.ha.oiddb.new.do.backup.push=false
faovm.ha.oiddb.new.do.reset.on.cleanup=false
faovm.ha.oiddb.new.backup.stage.path=/u01/app/backup/ha-crm-v1r3_20120430/oiddb
faovm.ha.oiddb.new.host=${HOST_OIDDB}
faovm.ha.oiddb.new.host.db.owner.user.name=oracle
faovm.ha.oiddb.new.host.login.user.name=${oiddb.new.host.db.owner.user.name}
faovm.ha.oiddb.new.host.login.user.password=CHANGEME
# Supported privilege escalation methods: none, sudo, pbrun
faovm.ha.oiddb.new.host.privilege.escalation.method=none
# If escalating via sudo, path to sudo binary
faovm.ha.oiddb.new.host.privilege.escalation.sudo.path=/usr/bin/sudo
# If escalating via pbrun, path to pbrun binary
faovm.ha.oiddb.new.host.privilege.escalation.pbrun.path=/path/to/pbrun
faovm.ha.oiddb.new.host.privilege.escalation.pbrun.policy.name=policy1-root
faovm.ha.oiddb.new.sys.user.name=sys
faovm.ha.oiddb.new.sys.user.password=CHANGEME
faovm.ha.oiddb.new.oracle.home=/u01/app/oracle/product/11.2.0.3/dbhome_1
faovm.ha.oiddb.new.crs.home=/u01/app/11.2.0.3/grid
faovm.ha.oiddb.new.asm.home=${oiddb.new.crs.home}
faovm.ha.oiddb.new.is.asm=true
faovm.ha.oiddb.new.asm.sid=+ASM1
faovm.ha.oiddb.new.datadisc=+DATA_SLCC10
faovm.ha.oiddb.new.recodisc=+RECO_SLCC10
faovm.ha.oiddb.new.datafile.path=${oiddb.new.datadisc}/${oiddb.new.sid}/datafile
faovm.ha.oiddb.new.tempfile.path=${oiddb.new.datadisc}/${oiddb.new.sid}/tempfile
faovm.ha.oiddb.new.recolog.path=${oiddb.new.recodisc}/${oiddb.new.sid}/ONLINELOG
faovm.ha.oiddb.new.spfile=${oiddb.new.datadisc}/${oiddb.new.sid}/spfile${oiddb.new.sid}.ora
faovm.ha.oiddb.new.tns.admin=${oiddb.new.oracle.home}/network/admin
faovm.ha.oiddb.new.set.archivelogmode=true

2.9.3.2 Single-Tenant IDM OIM Database-related Properties

You must enter values that match the external OIM database for the following values: owner.user.name, password.

# Source/reference OIM database information
faovm.ha.oimdb.src.backup.dir=idm/oimdb
faovm.ha.oimdb.src.backup.archive=${oimdb.src.backup.dir}/dbbackup.tar.gz
# Target/New OIM database-related properties
faovm.ha.oimdb.new.is.rac=${idsdb.new.is.rac}
faovm.ha.oimdb.new.dbname=${idsdb.new.dbname}
faovm.ha.oimdb.new.service.name=${oimdb.new.dbname}
faovm.ha.oimdb.new.sid=${oimdb.new.dbname}
faovm.ha.oimdb.new.port=${idsdb.new.port}
faovm.ha.oimdb.new.rac.sid1=${idsdb.new.rac.sid1}
faovm.ha.oimdb.new.rac.sid2=${idsdb.new.rac.sid2}
faovm.ha.oimdb.new.rac.port1=${idsdb.new.rac.port1}
faovm.ha.oimdb.new.rac.port2=${idsdb.new.rac.port2}
faovm.ha.oimdb.new.rac.dbhost1=${HOST_OIMDB}
faovm.ha.oimdb.new.rac.dbhost2=${HOST_OIMDB2}

# Target/New OIM database-restore-related properties
faovm.ha.oimdb.new.do.restore=true
faovm.ha.oimdb.new.do.backup.push=false
faovm.ha.oimdb.new.do.reset.on.cleanup=false
faovm.ha.oimdb.new.backup.stage.path=/u01/app/backup/ha-crm-v1r3_20120430/oimdb
faovm.ha.oimdb.new.host=${HOST_OIMDB}
faovm.ha.oimdb.new.host.db.owner.user.name=oracle
faovm.ha.oimdb.new.host.login.user.name=${oimdb.new.host.db.owner.user.name}
faovm.ha.oimdb.new.host.login.user.password=CHANGEME
# Supported privilege escalation methods: none, sudo, pbrun
faovm.ha.oimdb.new.host.privilege.escalation.method=none
# If escalating via sudo, path to sudo binary
faovm.ha.oimdb.new.host.privilege.escalation.sudo.path=/usr/bin/sudo
# If escalating via pbrun, path to pbrun binary
faovm.ha.oimdb.new.host.privilege.escalation.pbrun.path=/path/to/pbrun
faovm.ha.oimdb.new.host.privilege.escalation.pbrun.policy.name=policy1-root
faovm.ha.oimdb.new.sys.user.name=sys
faovm.ha.oimdb.new.sys.user.password=CHANGEME
faovm.ha.oimdb.new.oracle.home=/u01/app/oracle/product/11.2.0.3/dbhome_1
faovm.ha.oimdb.new.crs.home=/u01/app/11.2.0.3/grid
faovm.ha.oimdb.new.asm.home=${oimdb.new.crs.home}
faovm.ha.oimdb.new.is.asm=true
faovm.ha.oimdb.new.asm.sid=+ASM1
faovm.ha.oimdb.new.datadisc=+DATA_SLCC10
faovm.ha.oimdb.new.recodisc=+RECO_SLCC10
faovm.ha.oimdb.new.datafile.path=${oimdb.new.datadisc}/${oimdb.new.sid}/datafile
faovm.ha.oimdb.new.tempfile.path=${oimdb.new.datadisc}/${oimdb.new.sid}/tempfile
faovm.ha.oimdb.new.recolog.path=${oimdb.new.recodisc}/${oimdb.new.sid}/ONLINELOG
faovm.ha.oimdb.new.spfile=${oimdb.new.datadisc}/${oimdb.new.sid}/spfile${oimdb.new.sid}.ora
faovm.ha.oimdb.new.tns.admin=${oimdb.new.oracle.home}/network/admin
faovm.ha.oimdb.new.set.archivelogmode=true

2.9.4 Non-Oracle Fusion Customer Relationship Management Topology

If you use an Oracle VM template that does not contain Oracle Fusion Customer Relationship Management, then do not include webchat in the faovm.topo.ovms property. If WebChat is enabled in a single-instance IDM non-Oracle Fusion Customer Relationship Management topology, users are redirected to the OAM Logon page after any cursor movement in the Manage User page of the Function Setup Manager application.

To prevent WebChat from being deployed in a single-instance IDM non-Oracle Fusion Customer Relationship Management topology, ensure that the following line in the deployment property file does not contain webchat:

faovm.topo.ovms=idm1,ohs,fa,secondary,primary,bi (if 1-host standalone IDM)
foavm.topo.ovms=idm3oid,idm3mw,idm3ohs,fa,secondary,primary,bi (if 3-host standalone IDM)

2.10 Confirm the Oracle Virtual Assembly Builder Home is Accessible

Confirm that the Oracle Virtual Assembly Builder software, OVAB_HOME, is accessible from the deployer host. The following table describes the file location.

Table 2-7 Home Directories

Home Directory

Description

Variable Representation

Oracle Virtual Assembly Builder Home

This directory is the top-level directory for the Oracle Virtual Assembly Builder that contains all of the software needed to deploy Oracle Fusion Applications as an Oracle VM instance.

OVAB_HOME

Oracle VM Automation Utility

This directory is the top-level directory where you install the Oracle VM Automation Utility, as described in Section 2.12, "Install the Oracle VM Automation Utility". Confirm that this directory is accessible from the deployer host.

FAOVM

2.11 Register Templates with Oracle VM Manager

Follow these one-time setup steps to register the topology templates in the appropriate server pools in Oracle VM Manager.

1. Determine template paths for each node (ohs, fa, bi, webchat) inside the Oracle Virtual Assembly Builder catalog:

1. setenv ORACLE_HOME OAVB_HOME

2. setenv AB_INSTANCE $ORACLE_HOME/ab_instance

3. setenv JAVA_HOME $ORACLE_HOME/jre (or to a valid JDK 1.6 location)

4. cd $AB_INSTANCE/bin

5. Run the following command to print information about the following assemblies: component_wls_fa (for the FA node), component_wls_bi (for the BI node), composite_ohs (for the OHS node), and wls_webchat (for the WebChat node, if applicable.)

./abctl edit <<!
? open component_wls_fs
? print
!

The output of this command contains the location of the template *.img and *.cfg files inside the catalog for the respective assembly. For example:

template UCMCluster /ovab/small_20110510/ab_instance/catalog/shared/cid_8B6Qd53dUBj2PE3/templates/tid_m1K0GgbdUBj2PE3/templateFiles

There may be multiple template entries in the output, but all of them contain the same directory path for a given assembly. Under the directory there are multiple *.img files and one vm.cfg file. Usually there are System.img, AB.img and vm.cfg files.

Repeat this step to locate the template directories for Oracle Business Intelligence, OHS, and WebChat by using assembly names component_wls_bi, composite_ohs, component_wls_webchat, respectively, in the abctl edit command. Note that for OHS there is an additional ORACLE_INSTANCE.img file, which you must also copy.

2. Log in to each of your Oracle VM servers and create directories for the fa, bi, ohs, and webchat templates under /OVS/seed_pool. An example for FSCMH V1 MT templates from 20111013 follows:

cd /OVS/seed_pool
mkdir ha-fscmh-v1-mt_20111013_ohs (for ohs)
mkdir ha-fscmh-v1-mt_20111013_fa (for fa)
mkdir ha-fscmh-v1-mt_20111013_bi (for bi)
mkdir ha-fscmh-v1-mt_20111013_webchat (for webchat)
- Cl.

Copy the *.img files and vm.cfg file, which are located inside the catalog, for the OHS, FA and BI templates into the directories you just created, making sure to copy the correct.img file for the given node type, such as bi. If the wrong.img files are copied, rehydration will fail.

3. Log in to Oracle VM Manager for example, http://server01.com:8888/OVS. Go to Resources, then Import, and choose Select from Server Pool (Discover and register) to register the templates in Oracle VM manager.

Now the templates are registered in Oracle VM Manager and they correspond to the latest packaged bits stored in your OVAB home.

Register the IDM Oracle VM template in Oracle VM Manager. The IDM template's System.img file and vm.cfg files are located under the OVAB_HOME/idm directory. When copying the IDM template files to the Hypervisor's /OVS/seed_pool, ensure that they are renamed to System.img and vm.cfg.

2.12 Install the Oracle VM Automation Utility

Perform the following steps to install the Oracle VM Automation Utility on your deployer host.

1. Create a faovm directory, for example, mkdir /scratch/faovm.

2. Copy OVAB_HOME/oracle-ovmautomation-all.zip to /scratch/faovm and unzip.

3. setenv FAOVM /scratch/faovm

2.13 Enable Secure Shell (SSH) for Deployer Host

During deployment steps, the deployer host must be able to establish secured shell (SSH) with all the database hosts (Oracle Fusion Applications and IDM), and all of the OVM hosts to be created during the deployment steps. The SSH session uses the OS user credentials specified in the deployment properties.

The default SSH port is port 22. This port must be open for bi-directional communication if you place a firewall between the hosts.

3 Deployment of Oracle VM Templates

This chapter describes the steps for the deployment of an Oracle VM Template.

This chapter includes the following sections:

- Section 3.1, "Prepare Deployment Properties"

- Section 3.2, "Run Deployment"

- Section 3.3, "Post-Rehydration Steps"

- Section 3.4, "Other Oracle VM Life Cycle Management Tasks"

- Section 3.5, "Troubleshooting Oracle VM Deployment"

3.1 Prepare Deployment Properties

Note:

All input properties in the deployment properties file must have a value after the "=" character. Do not leave it blank for any optional input properties. Otherwise, you will encounter error messages during deployment. If no value will be provided for an optional input property, comment the property by adding a comment character (#) before the property.

From the FAS/deployfw/deployprops directory created in Section 2.12, "Install the Oracle VM Automation Utility", copy the ovm- crm|fscmh|hcm-deploy.properties file to the ova-ha-deploy.properties file, depending on which topology you are deploying. This file contains the input properties for the deployment instance that are required for creating a topology from the templates. The properties file should be modified as described in the following steps. Each step includes an example of the file properties to be modified.

1. Update the following properties to specify your Oracle VM Manager connection information and the default pool name.

faovm.ovmm.host=server01.com
faovm.ovmm.port=8888
faovm.ovmm.secure.port=8889
faovm.ovmm.use.secure=false
faovm.ovmm.username=admin
faovm.ovmm.password=<password you must provide>

2. Update the following properties to specify the Oracle Enterprise Manager 12c Cloud Control (Cloud Control) information for the wiring for the Oracle Enterprise Manager agents inside the Oracle VMs.

#EM Agent properties
#Enable rehydration-time emagent install and application discovery
faovm.emagent.install.enabled=true
faovm.emagent.oms.host=omshost.example.com_CHANGEME
#EM Agent 11g: HTTP port, EM Agent 12c: HTTPS port
faovm.emagent.oms.ports=4900
faovm.emagent.agent.password=CHANGEME
# Version of the EM agent to install, must be supported by your OMS
faovm.emagent.version=12.1.0.3.0
# Optional property to specify a manually staged EM agent install bundle
#faovm.emagent.install.bundle.file.name=${emagent.version}_AgentCore_226.zip

Additionally, to configure 12c EM agent, specify the following properties:

#EM Agent 12c configuration properties, applicable only for 12c
faovm.emagent.port=3875
faovm.emagent.os.user.name=emcadm
faovm.emagent.os.user.password=CHANGEME
faovm.emagent.os.user.id=10101
faovm.emagent.os.user.group.name=${os.apps.user.group.name}
faovm.emagent.os.user.home.dir=/home/${emagent.os.user.name}
faovm.emagent.oracle.base=/oem/app/oracle/product/12c
faovm.emagent.oracle.home=${emagent.oracle.base}/core/${emagent.version}

Note:

By default, the EM agent OS user will be created to belong to the same OS group as the FA OS user. This is required for the EM Agent to be able to monitor the FA system.

3. Update the following properties to specify your Cloud Control Oracle Management Server (OMS) Repository information.

faovm.oms.url=http://server01.com:4889/em/
faovm.oms.user=sysman
faovm.oms.password=<password you must provide>
faovm.oms.db.host=server01.com
faovm.oms.db.port=1521
faovm.oms.db.service.name=emdb.example.com

4. Update the following JVM Diagnostics properties to specify your Cloud Control OMS.

faovm.jvmd.host=server01.com
faovm.jvmd.port=3600

5. Update the following properties to point to your storage server. Use faovm.storage.type to indicate the type of storage that you will use, for example, netapp, sun or genericnfs, and specify the properties for that storage type in subsequent sections. Note that if you are using generic Network File System (NFS) with storage type genericnfs, then the volumes must be created and must exist before the deployment process begins. During deployment, the file volumes are mounted in the respective Oracle VMs.

# Storage-related properties, supported types: netapp, sun, genericnfs
faovm.storage.type=netapp

# location where the shared storage is mounted on the reference system (DO NOT CHANGE)
faovm.storage.mount=/u01
# location to mount the deploy shared storage on deployer and VMs (MAY BE CHANGED)
faovm.storage.physical.mount=/u1234

# Netapp Storage properties
faovm.storage.netapp.host=server01
faovm.storage.netapp.username=fusionst
faovm.storage.netapp.password=<password you must provide>
faovm.storage.netapp.containing-aggregate=emsprod01
# snapshot disable property should be set only in developer's environment
faovm.storage.netapp.snapshot.disable=true
# NFS options to use when mounting storage
faovm.storage.netapp.nfs.export.root=/vol
faovm.storage.netapp.nfs.mount.options=rw,tcp,hard,nointr,rsize=32768,wsize=32768,nfsvers=3,timeo=600
#Host/IP to use on the deployer when mounting storage
faovm.storage.netapp.deployer.nfs.mount.host=${storage.netapp.host}
#Host/IP to use in deployed VMs when mounting storage
faovm.storage.netapp.vm.nfs.mount.host=${\storage.netapp.host}

# Sun Storage properties
faovm.storage.sun.host=server404
faovm.storage.sun.username=fusovm
faovm.storage.sun.password=<password you must provide>
faovm.storage.sun.pool=pool-404
faovm.storage.sun.project=emsprod02
faovm.storage.sun.snapshot.disable=true
# NFS options to use when mounting storage
faovm.storage.sun.nfs.export.root=/export
faovm.storage.sun.nfs.mount.options=rw,tcp,hard,nointr,rsize=131072,wsize=131072,nfsvers=3,timeo=600
#Host/IP to use on the deployer when mounting storage
faovm.storage.sun.deployer.nfs.mount.host=${storage.sun.host}
#Host/IP to use in deployed VMs when mounting storage
faovm.storage.sun.vm.nfs.mount.host=${storage.sun.host}

# Generic, Predefined NFS
faovm.storage.genericnfs.host=server123
faovm.storage.genericnfs.nfs.export.root=/vol
faovm.storage.genericnfs.nfs.mount.options=rw,tcp,hard,nointr,rsize=32768,wsize=32768,nfsvers=3,timeo=600
#Host/IP to use on the deployer when mounting storage
faovm.storage.genericnfs.deployer.nfs.mount.host=${storage.genericnfs.host
#Host/IP to use in deployed VMs when mounting storage
faovm.storage.genericnfs.vm.nfs.mount.host=${storage.genericnfs.host}

Note:

If you chose to use genericnfs storage and run into the file lock issue, then "nolock" should be added to the nfs mount option for genericnfs like this:

faovm.storage.genericnfs.nfs.mount.options=rw,hard,nointr,nolock,rsize=32768,wsize=32768,timeo=600

6. If you plan to use the same template several times, you can use the pre-exported template storage feature. Instead of exporting template contents during deployment, this feature exports the template file system contents, once before you begin, and then each deployment uses clones of this volume to save time and space on the storage appliance.

To use this feature, set the following property to true:

# Controls whether createTopology will attempt to thin-provision storage
# using exploded template storage already provisioned using the
# createExportedTemplateStorage verb. Note: this can not be used when
# the storage.type is genericnfs
faovm.storage.use.parent=true

The following properties become relevant and should be set based on what storage type is in use:

# Settings used when using flex-cloning
faovm.storage.netapp.exported.template.nfs.export.root=${storage.netapp.nfs.export.root}
faovm.storage.netapp.exported.template.snapshot.name=faovm_exported_template_snapshot

# Settings used when using snapshot-cloning
faovm.storage.sun.exported.template.project=${storage.sun.project}
faovm.storage.sun.exported.template.nfs.export.root=${storage.sun.nfs.export.root}
faovm.storage.sun.exported.template.snapshot.name=faovm_exported_template_snapshot

The following properties are used to construct the names and sizes of the volumes used for the base exported template volume and need to be updated only when using netapp flexclones because the "-" character is not allowed in volume names:

faovm.ha.fa.storage.exported.template.size=80g
faovm.ha.fa.storage.exported.template.name=${faovm.ha.fa.vm.template.name}
faovm.ha.primary.storage.exported.template.name=${faovm.ha.fa.storage.exported.template.name}
faovm.ha.secondary.storage.exported.template.name=${faovm.ha.fa.storage.exported.template.name}
faovm.ha.bi.storage.exported.template.name={faovm.ha.fa.storage.exported.template.name}
faovm.ha.ohs.storage.exported.template.size=8g
faovm.ha.ohs.storage.exported.template.name=${vm.template.name}

7. (Optional) Update the following properties for your system and VNC console credentials for the Oracle VMs.

faovm.os.vnc.console.password=<password you must provide>
faovm.os.system.user.name=root
faovm.os.system.user.password=<password you must provide>

8. (Optional) Update the following properties to specify the operating system (OS) user and group name and IDs for the OS user that owns the Netapp volumes:

faovm.os.apps.user.name=oracle
faovm.os.apps.user.password=<password you must provide>
faovm.os.apps.user.id=1000
faovm.os.apps.user.group.name=dba
faovm.os.apps.user.group.id=1001
faovm.os.apps.user.home.dir=/home/oracle

9. Update the following properties to configure the eth0 network for the Oracle VMs. These settings may be the same as the setting of the Hypervisors where the Oracle VMs will be started.
If you have Oracle VMs spread across different Hypervisors that happen to be located in a different subnet, then you can add additional properties for the specific combination of topology type and Oracle VM host type. The format of the additional properties is faovm.<topologyType>.<hostType>.os.network.X, where topologyType = ha, hostType takes one of the values from ohs|fa|primary|secondary|bi|idm1|idm3oid|idm3mw|idm3ohs, and X is the remainder of the property such as dns.server, eth0.gateway, and so on.

The following properties are the default network properties for all Oracle VM host types:

faovm.os.network.dns.server=144.20.190.70
faovm.os.network.eth0.gateway=10.232.144.1
faovm.os.network.eth0.netmask=255.255.248.0

10. Update the following properties for your BIG IP end point host and ports. Note that ports are optional.

faovm.ha.bigip.mapping.fs.host.external=fscmhcm-cln-large-fs-ext.example.com
faovm.ha.bigip.mapping.fs.port.external=10614
faovm.ha.bigip.mapping.fs.host.internal=fscmhcm-cln-large-fs-int.example.com
faovm.ha.bigip.mapping.crm.host.external=fscmhcm-cln-large-crm-ext.example.com
faovm.ha.bigip.mapping.crm.port.external=10616
faovm.ha.bigip.mapping.crm.host.internal=fscmhcm-cln-large-crm-int.example.com
faovm.ha.bigip.mapping.fin.host.external=fscmhcm-cln-large-fin-ext.example.com
faovm.ha.bigip.mapping.fin.port.external=10604
faovm.ha.bigip.mapping.fin.host.internal=fscmhcm-cln-large-fin-int.example.com
faovm.ha.bigip.mapping.scm.host.external=fscmhcm-cln-large-scm-ext.example.com
faovm.ha.bigip.mapping.scm.port.external=10618
faovm.ha.bigip.mapping.scm.host.internal=fscmhcm-cln-large-scm-int.example.com
faovm.ha.bigip.mapping.hcm.host.external=fscmhcm-cln-large-hcm-ext.example.com
faovm.ha.bigip.mapping.hcm.port.external=10620
faovm.ha.bigip.mapping.hcm.host.internal=fscmhcm-cln-large-hcm-int.example.com
faovm.ha.bigip.mapping.prj.host.external=fscmhcm-cln-large-prj-ext.example.com
faovm.ha.bigip.mapping.prj.port.external=10606
faovm.ha.bigip.mapping.prj.host.internal=fscmhcm-cln-large-prj-int.example.com
faovm.ha.bigip.mapping.prc.host.external=fscmhcm-cln-large-prc-ext.example.com
faovm.ha.bigip.mapping.prc.port.external=10608
faovm.ha.bigip.mapping.prc.host.internal=fscmhcm-cln-large-prc-int.example.com
faovm.ha.bigip.mapping.prc.supplierportal.host.external=fscmhcm-cln-large-prc-sp-ext.example.com
faovm.ha.bigip.mapping.prc.supplierportal.port.external=10610
faovm.ha.bigip.mapping.prc.supplierportal.host.internal=fscmhcm-cln-large-prc-sp-int.example.com
faovm.ha.bigip.mapping.bi.host.external=fscmhcm-cln-large-bi-ext.example.com
faovm.ha.bigip.mapping.bi.port.external=10622
faovm.ha.bigip.mapping.bi.host.internal=fscmhcm-cln-large-bi-int.example.com
faovm.ha.bigip.mapping.default.port.external=443

If external ports are not specified, they are configured with the default value of 443.

11. This step includes updating Oracle RAC database properties and database directories.

1. Update the following properties to specify Oracle RAC database properties. Specify the following values that you collected when setting up the Oracle RAC instance in Section 2.7.3, "Set Up an Oracle Real Application Clusters (RAC) Database":
- Oracle RAC service name

- Physical host names for the two-node Oracle RAC database

- SID values for the two-node Oracle RAC database

- Listener port for the two-node Oracle RAC database, where the ports must be the same on each instance

- Oracle home

- Operating system user credentials that own the Oracle RAC instance, generally for the oracle user

- SYS schema credentials

- Oracle Automatic Storage Management DATA disc and REDO disc names

Examples follow:

faovm.ha.fusiondb.new.service.name=dbm
faovm.ha.fusiondb.rac.new.sid1=dbm1
faovm.ha.fusiondb.rac.new.sid2=dbm2
faovm.ha.fusiondb.new.do.restore=true

faovm.ha.fusiondb.src.backup.dir=db <an absolute path or relative path to $OVABHOME/db, where db backup archive is located >

faovm.ha.fusiondb.src.backup.archive=${fusiondb.src.backup.dir}
/dbbackup.tar.gz <path to the RMAN backup archive
>
faovm.ha.fusiondb.new.do.backup.push=true <this enables the deploy to untar the DB tar ball directly to target DB, make sure there is enough disk space on target DB.>

faovm.ha.fusiondb.new.backup.stage.path=<path to where src.backup.archive should be staged on the HOST1 of the target DB. If do.backup.push is enabled, the backup.archive will be exploded to this location during deployment. This is a non-ASM path.>

faovm.ha.fusiondb.new.host.user.name=oracle
faovm.ha.fusiondb.new.host.user.password=<password you must provide>

faovm.ha.fusiondb.new.sys.user.name=sys
faovm.ha.fusiondb.new.sys.user.password=<password you must provide>

faovm.ha.fusiondb.new.oracle.home=/u01/app/oracle/product/11.2.0/dbhome_1

faovm.ha.fusiondb.new.datadisc=+DDATA
faovm.ha.fusiondb.new.recodisc=+RECO

faovm.ha.fusiondb.new.datafile.path=${fusiondb.new.datadisc}/${fusiondb.new.service.name}/datafile
faovm.ha.fusiondb.new.tempfile.path=${fusiondb.new.datadisc}/${fusiondb.new.service.name}/tempfile
faovm.ha.fusiondb.new.recolog.path=${fusiondb.new.recodisc}/${fusiondb.new.service.name}/ONLINELOG
faovm.ha.fusiondb.new.spfile=${fusiondb.new.datadisc}/${fusiondb.new.service.name}/spfile${fusiondb.new.service.name}.ora

# physical host 1 for 2-node RAC
faovm.ha.HOST_DB=db_host.com

# physical host 2 for 2-node RAC
faovm.ha.HOST_DB2=db2_host.com

Note:

The Oracle Automatic Storage Management directory structures defined by the variables below must exist and be writable:

- faovm.ha.fusiondb.new.datadisc=+DATA_SLCC10

- faovm.ha.fusiondb.new.recodisc=+RECO_SLCC10

- faovm.ha.fusiondb.new.datafile.path=${fusiondb.new.datadisc}/${fusiondb.new.sid}/datafile

- faovm.ha.fusiondb.new.tempfile.path=${fusiondb.new.datadisc}/${fusiondb.new.sid}/tempfile

- faovm.ha.fusiondb.new.recolog.path=${fusiondb.new.recodisc}/${fusiondb.new.sid}/ONLINELOG

- faovm.ha.fusiondb.new.spfile=${fusiondb.new.datadisc}/${fusiondb.new.sid}/spfile${fusiondb.new.sid}.ora

For each of the above directory structures in Oracle Automatic Storage Management, the following must exist and can be created using asmcmd:

+DATA/hcmtest1/datafile
+DATA/hcmtest1/tempfile
+RECO/hcmtest1/ONLINELOG
In addition, if specifying a path in the controlfile location, the directory structure *.control_files='+DATA/hcmtest1/controlfile/control01.ctl','+DATA/hcmtest1/controlfile/control02.ctl' must exist before you run the command.

2. Review and update, if necessary, the following properties that specify the paths for database directory objects in the database:

# dba_directories configuration (can add as many as needed)
faovm.ha.fusiondb.new.oracle.base=/u01/app/oracle/product/11.2.0_CHANGEME
faovm.ha.fusiondb.new.dba.dir.name0=APPLCP_FILE_DIR
faovm.ha.fusiondb.new.dba.dir.path0=${fusiondb.new.oracle.home}/incident_logs
faovm.ha.fusiondb.new.dba.dir.name1=APPLLOG_DIR
faovm.ha.fusiondb.new.dba.dir.path1=${fusiondb.new.oracle.home}/appllog_dir
faovm.ha.fusiondb.new.dba.dir.name2=ADMIN_DIR
faovm.ha.fusiondb.new.dba.dir.path2=${fusiondb.new.oracle.home}/rdbms/admi
faovm.ha.fusiondb.new.dba.dir.name3=EQ_CONFIG_DIR
faovm.ha.fusiondb.new.dba.dir.path3=${fusiondb.new.oracle.home}/search/webapp/config
faovm.ha.fusiondb.new.dba.dir.name4=XMLDIR
faovm.ha.fusiondb.new.dba.dir.path4=${fusiondb.new.oracle.home}/rdbms/xml
faovm.ha.fusiondb.new.dba.dir.name5=EQ_LANG_DIR
faovm.ha.fusiondb.new.dba.dir.path5=${fusiondb.new.oracle.home}/search/data/language
faovm.ha.fusiondb.new.dba.dir.name6=ORACLE_OCM_CONFIG_DIR
faovm.ha.fusiondb.new.dba.dir.path6=${fusiondb.new.oracle.home}/ccr/state
faovm.ha.fusiondb.new.dba.dir.name7=DATA_PUMP_DIR
faovm.ha.fusiondb.new.dba.dir.path7=${fusiondb.new.oracle.base}/admin/${fusiondb.new.service.name}/dpdump
faovm.ha.fusiondb.new.dba.dir.name8=EQ_CACHE_DIR
faovm.ha.fusiondb.new.dba.dir.path8=${fusiondb.new.oracle.base}/oradata/${fusiondb.new.service.name}/cache

For most directories, their paths are relative to fusiondb.new.oracle.home, so the default value should be sufficient. The DATA_PUMP_DIR and EQ_CACHE_DIR directories depend on the value of the fusiondb.new.oracle.base property by default. Specify a value for the fusiondb.new.oracle.base property if you want to use the default values for the DATA_PUMP_DIR and EQ_CACHE_DIR directories.

3. Alter the properties to run the fusiondb restore with these enhancements:

faovm.ha.fusiondb.new.backup.stage.path=/u01/app/backup/ha-crm-v1r3_20120430/fusiondb

# Supported privilege escalation methods: none, sudo, pbrun
faovm.ha.fusiondb.new.host.privilege.escalation.method=none
# If escalating via sudo, path to sudo binary
faovm.ha.fusiondb.new.host.privilege.escalation.sudo.path=/usr/bin/sudo
# If escalating via pbrun, path to pbrun binary
faovm.ha.fusiondb.new.host.privilege.escalation.pbrun.path=/path/to/pbrun
faovm.ha.fusiondb.new.host.privilege.escalation.pbrun.policy.name=policy1-root

faovm.ha.fusiondb.new.datadisc=+DATA_SLCC10
faovm.ha.fusiondb.new.recodisc=+RECO_SLCC10
faovm.ha.fusiondb.new.spfile=${fusiondb.new.datadisc}/${fusiondb.new.sid}/spfile${fusiondb.new.sid}.ora
faovm.ha.fusiondb.new.crs.home=/u01/app/11.2.0.3/grid
faovm.ha.fusiondb.new.asm.home=${fusiondb.new.crs.home}
faovm.ha.fusiondb.new.is.asm=true
faovm.ha.fusiondb.new.asm.sid=+ASM1
faovm.ha.fusiondb.new.set.archivelogmode=true

12. Update the following properties for the host names of the Oracle VMs for the topologies to be deployed.

faovm.ha.HOST_FA=fa_host.com
faovm.ha.HOST_PRIMARY=primary_host.com
faovm.ha.HOST_SECONDARY=secondary_host.com
faovm.ha.HOST_BI=bi_host.com
faovm.ha.HOST_OHS=ohs_host.com

13. Update the following properties for your Oracle VMs for the HA nodes if you plan to create a High Availability (HA) Oracle VM.

faovm.ha.HOST_PRIMARY_HA1=primary_host.com
faovm.ha.HOST_SECONDARY_HA1=secondary_host.com
faovm.ha.HOST_OHS_HA1=ohs_host.com

The creation of HA nodes for Primary, Secondary, and OHS Oracle VMs as part of createTopology is disabled by default with the following settings in ovm-ha-deploy.properties. If you want the HA nodes for primary and secondary Oracle VMs to also be created, set the following properties to true:

faovm.ha.primary.create.ha.node=true
faovm.ha.secondary.create.ha.node=true
faovm.ha.ohs.create.ha.node=true

14. Update the following properties to point to your external dependency hosts, for example, LDAP, IDMDB, OAM, OIM, and so on.

# host 1 for 2-node RAC
faovm.ha.HOST_DB=db_host.com
# host 2 for 2-node RAC
faovm.ha.HOST_DB2=db2_host.com
faovm.ha.HOST_LDAP=ldap_host.com
faovm.ha.HOST_IDSDB=idsdb_host.com
faovm.ha.HOST_IDSDB2=idsdb2_host.com
faovm.ha.HOST_OIDDB=oiddb_host.com
faovm.ha.HOST_OIDDB2=oiddb2_host.com
faovm.ha.HOST_OIMDB=${HOST_IDSDB}
faovm.ha.HOST_OIMDB2=${HOST_IDSDB2}
faovm.ha.HOST_PSTORE=${HOST_LDAP}
faovm.ha.HOST_WEBGATE=webgate_host.com
faovm.ha.HOST_OAM=oam_host.com
faovm.ha.HOST_OIM=oim_host.com
faovm.ha.HOST_SMTP=smtp_host.com

Note that hosts specified in Steps 12, 13, and 14 are used to identify the IP addresses to update /etc/hosts during rehydration of each Oracle VM.

15. Specify the template name that you previously registered with Oracle VM Manager, and any VM-specific properties for the FA node.

faovm.ha.fa.ovmm.pool.name=adcgei12-pool
faovm.ha.fa.vm.template.name=ha-fscmh-v1-mt_20111013_fa
faovm.ha.fa.cpus=6
faovm.ha.fa.memory=13312
faovm.ha.fa.storage.name=ha_fscmh_v1_fa
faovm.ha.fa.storage.size=120g

16. Update VM-specific properties for the Primary node. The Primary node uses the same template as the FA node and shares the same volume.

faovm.ha.primary.ovmm.pool.name=adcgei12-pool
faovm.ha.primary.cpus=12
faovm.ha.primary.memory=20480

17. Update VM-specific properties for the Secondary node. The Secondary node uses the same template as the FA node and shares the same volume.

faovm.ha.secondary.ovmm.pool.name=adcgei12-pool
faovm.ha.secondary.cpus=24
faovm.ha.secondary.memory=51200

18. Specify the template name that you previously registered with OVM manager and any VM-specific properties for the BI node. The BI node shares the volume with the FA node.

faovm.ha.bi.ovmm.pool.name=adcgei12-pool
faovm.ha.bi.vm.template.name=ha-fscmh-v1-mt_20111013_bi
faovm.ha.bi.cpus=4
faovm.ha.bi.memory=6144

19. Specify the template name that you previously registered with Oracle VM Manager and any VM-specific properties for the OHS node. The OHS node has its own volume.

faovm.ha.ohs.ovmm.pool.name=adcgei12-pool
faovm.ha.ohs.vm.template.name=ha-fscmh-v1-mt_20111013_ohs
faovm.ha.ohs.cpus=2
faovm.ha.ohs.memory=1024
faovm.ha.ohs.storage.name=ha_fscmh_v1_ohs
faovm.ha.ohs.storage.size=12g

20. For deployment of a single-tenant IDM based topology, specify the template name that you previously registered with Oracle VM Manager and any VM-specific properties for the IDM node. The IDM node has its own volume so you must replace user_idm_CHANGEME with the file system that you allocated to the IDM node. See Section 2.5, "Provide Access to NetApp or Sun Storage Server" for more information.

faovm.ha.idm1.ovmm.pool.name=adcgei12-pool
faovm.ha.idm1.vm.template.name=ha-fscmh-v1_20111013_idm
faovm.ha.idm1.cpus=4
faovm.ha.idm1.memory=16384
faovm.ha.idm1.storage.size=70g
faovm.ha.idm1.storage.name=user_idm_CHANGEME

21. (Optional) If you need to apply additional approved patches to Fusion Middleware, Fusion Applications, and OHS during rehydration, un-comment these properties and enter the location where the patches are stored:

#faovm.ha.fa.fapatch.home=CHANGEME
#faovm.ha.ohs.mwpatch.home=CHANGEME

You may find that the ovm-ha-deploy.properties file has more properties defined than the ones listed in this section. You do not need to change the values of these properties.

Save the ovm-ha-deploy.properties file after you complete your updates.

3.1.1 Additional Deployment Properties

This section lists additional deployment properties added in this release, as well as their default values. You can make changes to these properties to suit your needs and then continue with deployment.

- BI Specific email configuration properties

# BI Does not use SOA Email
# The outgoing mail server and outgoing mail server port should
# match the configuration that is setup in sendmail configuration for
# the BI host
faovm.bi.email.config.enable=true
faovm.bi.email.outgoing.from.address=bi-sender.example.com
faovm.bi.email.outgoing.from.display.name=Oracle Business Intelligence Reporting
faovm.bi.email.outgoing.mail.server=localhost
faovm.bi.email.outgoing.mail.server.port=25

#faovm.ha.ovab.wlst.timeout=1200

faovm.ha.fa.max.memory=${faovm.ha.fa.memory}
faovm.ha.fa.originally.provisioned.max.memory=${faovm.ha.fa.originally.provisioned.memory}
faovm.ha.primary.max.memory=${faovm.ha.primary.memory}
faovm.ha.primary.originally.provisioned.max.memory=${faovm.ha.primary.originally.provisioned.memory}
faovm.ha.secondary.max.memory=${faovm.ha.secondary.memory}
faovm.ha.secondary.originally.provisioned.max.memory=${faovm.ha.secondary.originally.provisioned.memory}
faovm.ha.bi.max.memory=${faovm.ha.bi.memory}
faovm.ha.bi.originally.provisioned.max.memory=${faovm.ha.bi.originally.provisioned.memory}
faovm.ha.ohs.max.memory=${faovm.ha.ohs.memory}
faovm.ha.ohs.originally.provisioned.max.memory=${faovm.ha.ohs.originally.provisioned.memory}
faovm.ha.idm1.max.memory=${faovm.ha.idm1.memory}
faovm.ha.idm1.originally.provisioned.max.memory=${faovm.ha.idm1.originally.provisioned.memory}
faovm.ha.idm3oid.max.memory=${faovm.ha.idm3oid.memory}
faovm.ha.idm3oid.originally.provisioned.max.memory=${faovm.ha.idm3oid.originally.provisioned.memory}
faovm.ha.idm3mw.max.memory=${faovm.ha.idm3mw.memory}
faovm.ha.idm3mw.originally.provisioned.max.memory=${faovm.ha.idm3mw.originally.provisioned.memory}
faovm.ha.idm3ohs.max.memory=${faovm.ha.idm3ohs.memory}
faovm.ha.idm3ohs.originally.provisioned.max.memory=${faovm.ha.idm3ohs.originally.provisioned.memory}

#faovm.ha.ohs.mwpatch.home=CHANGEME

faovm.ha.oiddb.new.oracle.base=/u01/app/oracle/product/11.2.0.3
faovm.ha.oiddb.new.dba.dir.name0=DATA_FILE_DIR
faovm.ha.oiddb.new.dba.dir.path0=${oiddb.new.oracle.home}/demo/schema/sales_history/
faovm.ha.oiddb.new.dba.dir.name1=DATA_PUMP_DIR
faovm.ha.oiddb.new.dba.dir.path1=${oiddb.new.oracle.base}/admin/${oiddb.new.dbname}/dpdump
faovm.ha.oiddb.new.dba.dir.name2=LOG_FILE_DIR
faovm.ha.oiddb.new.dba.dir.path2=${oiddb.new.oracle.home}/demo/schema/log/
faovm.ha.oiddb.new.dba.dir.name3=MEDIA_DIR
faovm.ha.oiddb.new.dba.dir.path3=${oiddb.new.oracle.home}/demo/schema/product_media/
faovm.ha.oiddb.new.dba.dir.name4=ORACLE_OCM_CONFIG_DIR
faovm.ha.oiddb.new.dba.dir.path4=${oiddb.new.oracle.home}/ccr/state
faovm.ha.oiddb.new.dba.dir.name5=SS_OE_XMLDIR
faovm.ha.oiddb.new.dba.dir.path5=${oiddb.new.oracle.home}/demo/schema/order_entry/
faovm.ha.oiddb.new.dba.dir.name6=SUBDIR
faovm.ha.oiddb.new.dba.dir.path6=${oiddb.new.oracle.home}/demo/schema/order_entry//2002/Sep
faovm.ha.oiddb.new.dba.dir.name7=XMLDIR
faovm.ha.oiddb.new.dba.dir.path7=${oiddb.new.oracle.home}/rdbms/xml

faovm.ha.oimdb.new.oracle.base=/u01/app/oracle/product/11.2.0.3
faovm.ha.oimdb.new.dba.dir.name0=DATA_FILE_DIR
faovm.ha.oimdb.new.dba.dir.path0=${oimdb.new.oracle.home}/demo/schema/sales_history/
faovm.ha.oimdb.new.dba.dir.name1=DATA_PUMP_DIR
faovm.ha.oimdb.new.dba.dir.path1=${oimdb.new.oracle.base}/admin/${oimdb.new.dbname}/dpdump
faovm.ha.oimdb.new.dba.dir.name2=LOG_FILE_DIR
faovm.ha.oimdb.new.dba.dir.path2=${oimdb.new.oracle.home}/demo/schema/log/
faovm.ha.oimdb.new.dba.dir.name3=MEDIA_DIR
faovm.ha.oimdb.new.dba.dir.path3=${oimdb.new.oracle.home}/demo/schema/product_media/
faovm.ha.oimdb.new.dba.dir.name4=ORACLE_OCM_CONFIG_DIR
faovm.ha.oimdb.new.dba.dir.path4=${oimdb.new.oracle.home}/ccr/state
faovm.ha.oimdb.new.dba.dir.name5=SS_OE_XMLDIR
faovm.ha.oimdb.new.dba.dir.path5=${oimdb.new.oracle.home}/demo/schema/order_entry/
faovm.ha.oimdb.new.dba.dir.name6=SUBDIR
faovm.ha.oimdb.new.dba.dir.path6=${oimdb.new.oracle.home}/demo/schema/order_entry//2002/Sep
faovm.ha.oimdb.new.dba.dir.name7=XMLDIR
faovm.ha.oimdb.new.dba.dir.path7=${oimdb.new.oracle.home}/rdbms/xml

#faovm.ha.idm1.faappsadmin.firstname=CHANGEME
#faovm.ha.idm1.faappsadmin.lastname=CHANGEME
#faovm.ha.idm1.faappsadmin.email=CHANGEME

#faovm.ha.idm3oid.faappsadmin.firstname=CHANGEME
#faovm.ha.idm3oid.faappsadmin.lastname=CHANGEME
#faovm.ha.idm3oid.faappsadmin.email=CHANGEME

faovm.patch.file82=shiphome/fasaaslcmtools.zip
faovm.patch.todir82=${ovabext.dir}

#faovm.mwpatch.home=CHANGEME
#faovm.ha.wls.server.aux.sysprops=-Dweblogic.slc=true -Dweblogic.slc.exceptions.verbose=true -Dweblogic.kernel.debug=true
#faovm.ha.mwpatch.apply.timeout=43200

3.1.1.1 Changed Default Deployment Properties Values

The default values for these deployment properties have changed from the previous release:

BEFORE:

faovm.emagent.oms.ports=4901

AFTER:

faovm.emagent.oms.ports=4900

BEFORE:

faovm.emagent.install.bundle.file.name=12.1.0.2.0_AgentCore_226.zip

AFTER:

#faovm.emagent.install.bundle.file.name=${emagent.version}_AgentCore_226.zip

BEFORE:

faovm.emagent.oracle.home=${emagent.oracle.base}/core/12.1.0.2.0

AFTER:

faovm.emagent.oracle.home=${emagent.oracle.base}/core/${emagent.version}

BEFORE:

faovm.oms.url=https://${emagent.oms.host}:4901/em/
faovm.oms.url.http=http://${emagent.oms.host}:4890/em/

AFTER:

faovm.oms.url=https://${emagent.oms.host}:7799/em/
faovm.oms.url.http=http://${emagent.oms.host}:7788/em/

BEFORE:

faovm.default.email.outgoing.mail.server=smtp.oracleoutsourcing.com
faovm.osn.email.outgoing.mail.server.port=25
faovm.bi.email.outgoing.mail.server.port=25

AFTER:

faovm.default.email.outgoing.mail.server=localhost
faovm.osn.email.outgoing.mail.server.port=587
faovm.bi.email.outgoing.mail.server.port=587

3.1.2 Deprecated Deployment Properties from Prior Releases

These properties are no longer used in this release:

#faovm.mtidm.source.tenant.id=UNDEFINED
#faovm.mtidm.source.tenant.name=acme
#faovm.mtidm.source.enterprise.id=UNDEFINED
#faovm.mtidm.source.jps.root=cn=acme.FAService,cn=OPSS
#faovm.mtidm.oim.admin.username=oim_admin
#faovm.mtidm.oim.admin.password=CHANGEME
#faovm.mtidm.oam.admin.username=oamadminuser
#faovm.mtidm.oam.admin.password=CHANGEME
#faovm.mtidm.global.jps.root=cn=FAPolicies
#faovm.mtidm.pstore.binddn.username=cn=orcladmin
#faovm.mtidm.pstore.binddn.password=CHANGEME
#faovm.mtidm.oim.mds.schema.username=oim_mds
#faovm.mtidm.oim.mds.schema.password=CHANGEME
#faovm.mtidm.oim.admin.port=17001
#faovm.mtidm.oam.admin.port=17001
#faovm.mtidm.oam.server.name=oam_server1

#faovm.patch.file10=fasaaslcmtools/fa_startstop_saas.zip
#faovm.patch.todir10=${ovabext.dir}

#faovm.ha.fusiondb.new.genoptimizedqueryplan.enabled=true
#faovm.ha.fusiondb.new.genoptimizedqueryplan.schema=BEE_MDS,SCM_FUSION_MDS_SOA,SETUP_FUSION_MDS_SOA,PRC_FUSION_MDS_SOA,OIC_FUSION_MDS_SOA,HCM_FUSION_MDS_SOA,FUSION_MDS,PRJ_FUSION_MDS_SOA,FUSION_MDS_SPACES,CRM_FUSION_MDS_SOA,FUSION_MDS_ESS,FIN_FUSION_MDS_SOA

#faovm.ha.HOST_WEBCHAT=webchathost.example.com_CHANGEME

# Defaulted/Overridden properties - these base values should not be changed
#faovm.ha.storage.create=false
#faovm.ha.storage.unmount=false
#faovm.ha.bigip.mapping.enabled=false
#faovm.ha.sendmail.enabled=false
# Controls whether files are created during deploy to allow later scaleout.
#faovm.ha.allow.scale.out=false
# Controls whether the HA nodes are created during the initial topology setup.
#faovm.ha.create.ha.node=false

#faovm.ha.fa.bigip.mapping.enabled=true

#faovm.ha.fa.patch.file100=wlspatches/fa/pre-host-patch/wlspatches.txt
#faovm.ha.fa.patch.todir100=${ovabext.dir}
#faovm.ha.fa.patch.file101=wlspatches/fa/pre-host-patch/p13349651_1036_Generic.zip
#faovm.ha.fa.patch.todir101=${faovm.ha.fa.patch.todir100}
#faovm.ha.fa.patch.file102=fasaaslcmtools/cloudlangpack.zip
#faovm.ha.fa.patch.todir102=${ovabext.dir}
#faovm.ha.fa.patch.file103=opatches/fa/pre-host-patch/patches.txt
#faovm.ha.fa.patch.todir103=${ovabext.dir}
#faovm.ha.fa.patch.file104=opatches/fa/pre-host-patch/p14787722_Generic.zip
#faovm.ha.fa.patch.todir104=${faovm.ha.fa.patch.todir103}
#faovm.ha.fa.patch.file105=opatches/fa/pre-host-patch/p16294200_linuxx64.zip
#faovm.ha.fa.patch.todir105=${faovm.ha.fa.patch.todir103}
#faovm.ha.fa.patch.file106=opatches/fa/pre-host-patch/p16326775_Generic.zip
#faovm.ha.fa.patch.todir106=${faovm.ha.fa.patch.todir103}
#faovm.ha.fa.patch.file107=opatches/fa/pre-host-patch/p16389043_Generic.zip
#faovm.ha.fa.patch.todir107=${faovm.ha.fa.patch.todir103}
#faovm.ha.fa.patch.file108=opatches/fa/pre-host-patch/p16417375_111500_Fusion_Linux-x86-64.zip
#faovm.ha.fa.patch.todir108=${faovm.ha.fa.patch.todir103}

#
# Webchat host specific properties
#
#faovm.ha.webchat.ovmm.pool.name=slce08-pool
#faovm.ha.webchat.vm.template.name=ha-crm-v1r4_2012MMDD_webchat
#faovm.ha.webchat.vm.template.dir=/testmnt/template/webchat
#faovm.ha.webchat.ovab.sharedfs.component.name=component_wls_webchat
#faovm.ha.webchat.logical.hostname=webchat.oracleoutsourcing.com
#faovm.ha.webchat.hostname=${HOST_WEBCHAT}
#faovm.ha.webchat.cpus=4
#faovm.ha.webchat.memory=5120
#faovm.ha.webchat.originally.provisioned.memory=5120
#faovm.ha.webchat.storage.create=true
#faovm.ha.webchat.storage.size=12g
#faovm.ha.webchat.storage.name=user_webchat_CHANGEME
#faovm.ha.webchat.storage.parent.size=10g
#faovm.ha.webchat.storage.parent.name=${vm.template.name}
#faovm.ha.webchat.storage.unmount=true
# Comma separated list of BOSH domain names to be configured.
# List should be comprehensive and include all domains including any that were
# previously configured and are still needed
# Leave empty if no changes are needed and to skip BOSH rehydration
#faovm.ha.webchat.bosh.domain.names=example.com_CHANGEME
#faovm.ha.webchat.os.apps.user.name=aime
#faovm.ha.webchat.os.apps.user.id=94110
#faovm.ha.webchat.os.apps.user.group.name=svrtech
#faovm.ha.webchat.os.apps.user.group.id=42424
#faovm.ha.webchat.os.apps.user.home.dir=/home/aime
#faovm.ha.webchat.lockfile=/dev/shm/ohs_webchat_http_lock
# Use range 600-699 for patch files applicable for webchat ovm type

#faovm.ha.idm1.update.login.page=true

#faovm.ha.idm3oid.storage.unmount=true

#faovm.ha.idm3mw.standalone.file.archive0=idm/u01_oim.tar
#faovm.ha.idm3mw.storage.create=true
#faovm.ha.idm3mw.storage.size=30g
#faovm.ha.idm3mw.storage.parent.size=30g
#faovm.ha.idm3mw.update.login.page=true

3.2 Run Deployment

This step initiates the creation of the Oracle Fusion Applications topology, including Oracle Identity Management, onto the Oracle VM systems.

1. Set the following environment variables.

setenv OVAB_HOME path_to_your_ovab_home
setenv JAVA_HOME path_to_jre (in OVAB_HOME/jre) or path_to_JDK_1.6
setenv FAOVM path_to_ovm_utility

Note that the path_to_ovm_utility refers to the directory you created in Section 2.12, "Install the Oracle VM Automation Utility".

2. Run the faovmdeploy.sh utility to create exported template storage. This step is optional and is necessary only if you followed Step 6 in Section 3.1, "Prepare Deployment Properties".

cd $FAOVM/deployfw/bin
./faovmdeploy.sh createExportedTemplateStorage type=ha

This utility operates on all host types for which storage is created, such as ohs, fa, and idm hosts. It does not operate on hosts that share storage, such as primary and secondary hosts. Optionally, you can add the following command line option to skip pinging the existing hosts from the deployer host: skipPingExistingHosts=true.

This utility generates a log file for the creation of your topology in the directory, $FAOVM/deployfw/logs.

An example of the output follows:

[13:33:13/ohs] Executing Task: Create Sun Storage Share - ha-crm-v1r1-mt_20111213_ohs ... Done. [0m45s]
[13:33:59/ohs] Executing Task: Mount Storage - /u1234 ... Done. [0m1s]
[13:34:00/ohs] Executing Task: Change Storage Owner to Deploy User - /u1234 ... Done. [0m11s]
[13:34:12/ohs] Executing Task: Read Shared File Sets ... Done. [0m28s]
[13:34:41/ohs] Executing Task: Export File Sets ...
[13:34:41/ohs] Executing Task: Export File Set - fmwHome ... Done. [8m29s]
[13:43:10/ohs] Executing Task: Export File Set - webgate ... Done. [0m49s]
[13:44:00/ohs] Executing Task: Export File Set - ora_inventory ... Done. [0m26s]
[13:44:26/ohs] Executing Task: Export File Set - ovabext ... Done. [0m26s]
[13:44:52/ohs] Executing Task: Export File Set - EMAgent ... Done. [0m44s]
... Done. [10m55s]
[13:45:36/ohs] Executing Task: Unmount Storage - /u1234 ... Done. [0m1s]
[13:45:44/ohs] Executing Task: Create Sun Storage Snapshot - ha-crm-v1r1-mt_20111213_ohs@faovm_exported_template_snapshot ... Done. [0m8s]
[13:45:52/fa] Executing Task: Create Sun Storage Share - ha-crm-v1r1-mt_20111213_fa ... Done. [0m31s]

3. Run the faovmdeploy.sh utility to create an Oracle VM.

cd $FAOVM/deployfw/bin
./faovmdeploy.sh createTopology type=ha

This utility generates a log file for the creation of your topology in the directory, $FAOVM/deployfw/logs.

An example of the output follows:

[19:40:59] Starting createTopology execution for FSCM+HCM HA Topology

[19:40:59/ohs] Executing Task: Create Volume - ilawler_ohs ... Done. [0m9s]
[19:41:08/ohs] Executing Task: Change Volume Owner ... Done. [0m5s]
[19:41:13/ohs] Executing Task: Read Shared File Sets ... Done. [0m32s]
[19:41:46/ohs] Executing Task: Export File Sets ...
[19:41:46/ohs] Executing Task: Export File Set - fmwHome ... Done. [3m46s]
[19:45:33/ohs] Executing Task: Export File Set - ORACLE_INSTANCE ... Done. [0m40s]
[19:46:14/ohs] Executing Task: Export File Set - webgate ... Done. [0m43s]
[19:46:57/ohs] Executing Task: Export File Set - ovabext ... Done. [0m31s]
[19:47:29/ohs] Executing Task: Export File Set - EMAgent ... Done. [0m38s]
... Done. [6m21s]
[19:48:07/ohs] Executing Task: Instantiate Rehydration Templates ... Done. [0m5s]
[19:48:12/ohs] Executing Task: Copy Rehydrate Framework Files to Volume ... Done. [0m0s]
[19:48:13/ohs] Executing Task: Stage Rehydration Patches ... Done. [0s]
[19:48:13/ohs] Executing Task: Fix APPLTOP Permissions ... Done. [0m15s]
[19:48:29/ohs] Executing Task: Change Volume Owner ... Done. [0m24s]
[19:48:53/ohs] Executing Task: Create OVM - EXAMPLE.us.example2.com ... Done. [3m35s]
[19:52:29/ohs] Executing Task: Unmount Volume Mount Point - /u01 ... Done. [0m5s]
.....

[19:52:35] Completed createTopology execution for CRM Small Topology [11m35s]

The faovmdeploy.sh command completes after the storage volumes are created and populated and the Oracle VMs are powered on. The rehydration of the domains continues within each individual Oracle VM even after the command completes.

3.2.1 Check the Status of createTopology

Use the status argument to check the status of the createTopology session. You can check the status of the entire topology with this command:

cd $FAOVM/deployfw/bin
./faovmdeploy.sh status type=ha

You can also check the status of a single node type by specifying the hostType argument:

cd $FAOVM/deployfw/bin
./faovmdeploy.sh status type=ha hostType=[ohs|fa|primary|secondary|bi]

3.2.2 Check the Status of Each Oracle VM

To manually check the status of each Oracle VM, log in to each Oracle VM using the root credentials that you specified, and monitor the rehydration progress within that Oracle VM.

For example, to check progress of the FA node, log in to the FA Oracle VM and run this command:

cd /u01/APPLTOP/ovabext/crmapps.oracleoutsourcing.com/CRMDomain
ls wls-latebinding-*.out

This command lists the Managed Servers for the CRMDomain, such as the Administration Server and Managed Servers, that have been rehydrated so far. An example of the output follows:

-rw-r-r- 1 root   root   33 May 12 03:50 wls-latebinding-CRMDomain-AdminServer.properties.out
-rw-r-r- 1 root   root   33 May 12 03:53 wls-latebinding-CRMDomain-ODICluster.properties.out
-rw-r-r- 1 root   root   33 May 12 03:56 wls-latebinding-CRMDomain-EmailMarketingCluster.properties.out
-rw-r-r- 1 root   root   33 May 12 04:00 wls-latebinding-CRMDomain-ContractManagementCluster.properties.out
-rw-r-r- 1 root   root   33 May 12 04:05 wls-latebinding-CRMDomain-SalesCluster.properties.out
-rw-r-r- 1 root   root   33 May 12 04:10 wls-latebinding-CRMDomain-CRM_SOACluster.properties.out
-rw-r-r- 1 root   root   33 May 12 04:14 wls-latebinding-CRMDomain-CRMAnalyticsCluster.properties.out
-rw-r-r- 1 root   root   33 May 12 04:18 wls-latebinding-CRMDomain-MarketingCluster.properties.out
-rw-r-r- 1 root   root   33 May 12 04:22 wls-latebinding-CRMDomain-CustomerCluster.properties.out
-rw-r-r- 1 root   root   33 May 12 04:27 wls-latebinding-CRMDomain-CRMPerformanceCluster.properties.out
-rw-r-r- 1 root   root   33 May 12 04:33 wls-latebinding-CRMDomain-CRMCommonCluster.properties.out
-rw-r-r- 1 root   root   33 May 12 04:38 wls-latebinding-CRMDomain-OrderCaptureCluster.properties.out
-rw-r-r- 1 root   root   33 May 12 04:41 wls-latebinding-CRMDomain-CRMSearchCluster.properties.out
-rw-r-r- 1 root   root   33 May 12 04:45 wls-latebinding-CRMDomain-ESSCluster.properties.out

Each file contains the following text if the rehydration of that Managed Server was successful:

/u01/APPLTOP/ovabext/crmapps.oracleoutsourcing.com/CRMDomain/wls-latebinding-CRMDomain-AdminServer.properties.out
deployer.rehydration-result = OK

Additional log files related to rehydration are located under the /assemblybuilder/log directory within the Oracle VM.

3.3 Post-Rehydration Steps

Perform the following steps after rehydration completes successfully:

- Perform Postinstallation Tasks

- Apply Oracle Fusion Middleware Patches

- Apply Oracle Fusion Applications Patches

- Oracle Fusion Applications Post-installation Steps

Note:

In the following sections, references to hosts, such as HOST_SECONDARY and HOST_BI, represent the host names that you defined in Steps 12 through 14 in Section 3.1, "Prepare Deployment Properties". You must replace them with the host names in your environment to perform the manual steps.

3.3.1 Perform Postinstallation Tasks

Complete the following post-rehydration step that is related to Oracle VM.

- Perform Postinstallation Tasks

3.3.1.1 Perform Postinstallation Tasks

After Oracle VM deployment is complete, follow the manual "Postinstallation Tasks" described in the Oracle Fusion Applications Installation Guide.

3.3.2 Apply Oracle Fusion Middleware Patches

Apply the mandatory Oracle Fusion Middleware patches. For more information, see "Oracle Fusion Middleware" in Oracle Fusion Applications release notes.

3.3.3 Apply Oracle Fusion Applications Patches

Refer to Oracle Fusion Applications release notes for information related to any additional patches that must be applied after Oracle VM deployment.

3.3.4 Oracle Fusion Applications Post-installation Steps

You must now perform the necessary implementation and functional setup tasks.

3.3.4.1 Manage User Passwords for Login Access to Applications Components

For complete information about setting up and managing passwords for your new environment, see "Securing Oracle Fusion Applications" and "Provisioning Identities" in Oracle Fusion Applications Administrator's Guide

3.3.4.2 Enable Product Offering Functionality

Before you can start using any of the product offerings you have installed, you must complete some common implementation tasks and enable the functionality of the offerings in your environment.

A large library of product-related documentation is available for use after provisioning. Some of the guides that you will find useful are listed here:

- Oracle Fusion Applications Common Implementation Guide

- Part VII, Completing Oracle Fusion Applications Post-Installation Tasks in the Oracle Fusion Applications Installation Guide

- Product-specific Oracle Fusion Applications implementation guides

3.4 Other Oracle VM Life Cycle Management Tasks

These are other life cycle management tasks that might be useful for your Oracle VM installation.

- Scale Out the OHS Node

- Scale Out the Primary Node

- Remove a Deployed Topology (Optional)

- Remove Exported Template Storage (Optional)

- Rerun a Deployment (Optional)

3.4.1 Scale Out the OHS Node

To scale out the OHS node, first prepare the ovm-ha-deploy.properties file by updating the scale-out Oracle VM information. You must specify your Oracle VM host names. Other properties are determined automatically based on the specifications for the base OHS Oracle VM.

faovm.ha.HOST_OHS_SCALE1=server02.com

You must add the number of scale-out host names based on the number of scale out OHS Oracle VM. Update environment information in POD's excel sheets that you want to create.

To execute the scale out:

cd $FAOVM/deployfw/bin
./faovmdeploy.sh scaleoutOHS type=ha scaleoutInstances=1

3.4.2 Scale Out the Primary Node

To scale out the Primary node, first prepare the ovm-ha-deploy.properties file by updating the scale-out Oracle VM information. You must specify your Oracle VM host names. Other properties are determined automatically based on the specifications for the base Primary Oracle VM.

faovm.ha.HOST_PRIMARY_SCALE1=primary_host_scale1.com

You must add the number of scale-out host names based on the number of scale out Primary Oracle VMs that you want to create.

To execute the scale out:

cd $FAOVM/deployfw/bin
./faovmdeploy.sh scaleoutApps type=ha scaleoutInstances=1

3.4.3 Remove a Deployed Topology (Optional)

If you want to remove a topology that you previously created, use the cleanupTopology argument with faovmdeploy.sh.

cd $FAOVM/deployfw/bin
./faovmdeploy.sh cleanupTopology type=ha

Additionally, if you want to reset the Oracle RAC database to its original state, you can do this by setting the following property to "true":

faovm.ha.fusiondb.new.do.reset.on.cleanup=true

3.4.4 Remove Exported Template Storage (Optional)

If you previously used the pre-exported template storage feature, as described in Step 6 under Section 3.1, "Prepare Deployment Properties", you can remove these templates by using the cleanupExportedTemplateStorage command. Do not use this command if any topologies exist with volumes that are clones of the base exported template storage volumes and shares. If you run this command when these clones exist, the command will fail and it may also remove all of the storage for those clones. The command syntax follows:

cd $FAOVM/deployfw/bin
./faovmdeploy.sh cleanupExportedTemplateStorage type=ha

3.4.5 Rerun a Deployment (Optional)

If you want to rerun a deployment, reset the database and reexecute the restore process because some steps cannot be rerun on a database that has already undergone a deployment and rehydration. To reset the database, create a shell script /tmp/resetdb.xxxx.sh, where xxxx is the source database name, to help stop the database and drop or remove the data files.

3.5 Troubleshooting Oracle VM Deployment

The following troubleshooting scenarios are included in this section.

- Re-triggering Rehydration

- Oracle VM Fails to Shutdown While Removing a Deployed Topology

- Update Oracle Data Integrator (ODI) Server Startup Properties if High Availability is Enabled

3.5.1 Re-triggering Rehydration

During rehydration, if for some reason, you need to log in to an Oracle VM and manually re-trigger rehydration for that Oracle VM by invoking abinit-host.sh, remember to set the following environment variables first:

export JAVA_HOME=/assemblybuilder/jre
export PATH=$PATH:$JAVA_HOME/bin

3.5.2 Oracle VM Fails to Shutdown While Removing a Deployed Topology

When you remove a topology by following the steps in Section 3.4.3, "Remove a Deployed Topology (Optional)," it may appear that the VMs are not responding or not able to shutdown because the network has been cutoff or shut down. If this is the case, the ./etc/init.d/dimstartstop or ./etc/init.dfastartstop scripts may not be responding.

To work around this, log into the corresponding hypervisor and use the "xm destroy" command to forcibly shut down the VM.

3.5.3 Update Oracle Data Integrator (ODI) Server Startup Properties if High Availability is Enabled

If you create an Oracle VM environment with corresponding High Availability (HA) deployment properties, then you need to follow the instructions below to add the missing server startup properties to the od1_serverHA server in the HA node prior to performing ODI import.

1. Repeat Steps 1-4 for both odi_server1 and odi_serverHA in the CRM and HCM domains.

2. Login to the Oracle WebLogic Server Administration Console for the respective domain (CRM or HCM). In the Domain Structure window, expand the Environment node. Click Server. The Summary of Servers page appears.

3. Select the odi server (odi_server1 or odi_serverHA) from the appropriate column in the table. The Settings page appears. Click Lock & Edit. Click the Server Start tab. Enter the following into the Arguments field, replacing the values in <...> accordingly. Click Save and Activate Changes.
For odi_server1:

-DJDBCProgramName=DS/<domain>/odi_server1 -Dserver.group=ODICluster -Dtangosol.coherence.localhost=secondary.oracleoutsourcing.com -Dtangosol.coherence.localport=<odi server coherence port> -Doracle.odi.coherence.wka1=secondary.oracleoutsourcing.com -Doracle.odi.coherence.wka1.port=<odi server coherence port> -Doracle.odi.coherence.wka2=secondary-ha1.oracleoutsourcing.com -Doracle.odi.coherence.wka2.port=<odi server coherence port> -Dtangosol.coherence.cluster=ODICluster

For odi_serverHA:

-DJDBCProgramName=DS/<domain>/odi_serverHA -Dserver.group=ODICluster -Dtangosol.coherence.localhost=secondary-ha1.oracleoutsourcing.com -Dtangosol.coherence.localport=<odi server coherence port> -Doracle.odi.coherence.wka1=secondary.oracleoutsourcing.com -Doracle.odi.coherence.wka1.port=<odi server coherence port> -Doracle.odi.coherence.wka2=secondary-ha1.oracleoutsourcing.com -Doracle.odi.coherence.wka2.port=<odi server coherence port> -Dtangosol.coherence.cluster=ODICluster

Where:

- <domain> is the HCMDomain or CRMDomain

- <odi server coherence port> is the coherence port allocated to the ODI managed servers (odi_server1 orodi_serverHA). Note that this will be the same on both secondary and secondary-ha1 Oracle VMs.

Note:

There should be no line breaks between the different -D parameters. Do not copy and paste the code from above into your Administration Console's Arguments text field. Copying and pasting this code may result in HTML tags being inserted into the Java arguments. In addition, the text that you enter should not contain characters other than those included in the example above.

4. Restart the odi_server1 and odi_serverHA managed servers.

4 Content Movement Services: Production-to-Test and Cloning

This chapter describes how to move or copy Fusion Applications components and/or data from one environment to another when the source environment was installed using Oracle Virtual Machine (Oracle VM) templates.

This chapter describes two types of content movement. Each is independent of the other:

- Section 4.1, "Perform a Production-to-Test Data Refresh"

- Section 4.2, "Perform a Full Clone"

4.1 Perform a Production-to-Test Data Refresh

It may be necessary periodically to bring production data into the test environment to conduct certain types of tests. For example, it might be useful to test Oracle Fusion Applications with realistic data in the following circumstances:

- Testing new functionality

- Testing bug fixes and code changes

- Testing previously unused functionality

- Testing upgrades

- Testing performance

- Training users

4.1.1 Introduction

Production-to-test data movement includes two distinct parts: updating the Oracle Identity Management components, using a particular set of scripts and properties files, and updating the Fusion Applications test database using a different set of scripts and properties files.

4.1.1.1 Technical Assumptions and Requirements

Before moving production data, consider the following:

- Matching systems: Test and Production systems must be identical in terms of product version, patch levels, deployment topology and configurations. Test and Production environments were initially created using the same Oracle VM Template. Note that Oracle VM installations do not support Windows.

- Oracle Identity Management: Because the production data references real users and applications policies, the identity store and policy store at the test environment must contain a copy of these objects.

- Databases: Both the source and target databases must be on RAC and Automatic Storage Management (ASM).

- Data Masking: When moving data from the production environment to the test environment, you must mask all sensitive information in the copied data.
Even when sensitive information is masked, you must use caution in granting access to this data in the test environment. In certain cases, you may not be able to mask out all sensitive data. For example, if you want to conduct heavy-duty payroll testing to validate new tax formulas, you may not want to conduct the test with real payroll data.

- Cloud Control: An instance of the Oracle Enterprise Manager Cloud Control is required. If Cloud Control has not yet been installed, you can obtain and install it now. See Section 2.8.1, "Install Oracle Enterprise Manager 12c Cloud Control".
The Oracle Enterprise Manager Cloud Control Basic Installation Guide provides details on how to install, create a software library, add named credentials, register the necessary Fusion Application servers with Cloud Control, and deploy Management Agents on each server to establish communication between them and Cloud Control. All of these configurations are required prerequisites to performing the data refresh.

By default, when installing Cloud Control along with an Oracle VM version of Fusion Applications, you are prompted to establish credentials and deploy agents on each of the Oracle VM hosts. If this was not completed, you can do it manually now, following the instructions in the Oracle Enterprise Manager Cloud Control Basic Installation Guide

- Access: If firewalls are in place, ensure that there is JDBC database access from the destination mid-tier host to the source database and destination database hosts.

- Backup locations: Production to test uses the following backups from the Source (Production) environment:
RMAN backup (HOT) of the Source DB: The database backup should be taken with archive mode ON and the database still open (HOT backup of database plus archive logs). The file system location of the RMAN backup should be accessible from the Destination (Test) database host.

APPLTOP snapshot (COLD) of the Source Mid-Tier: The snapshot should be COLD (all mid-tier servers shutdown before taking the snapshot). The file system location of the snapshots should be accessible from the Source (Production) Mid-Tier host.

Note:

It is important that the RMAN backup and the file system snapshots are done simultaneously (time-synched), otherwise the database and the file system contents might not be consistent in the destination environment after completing content movement.

- Credentials: You will need the credentials of the owner of the Cloud Control instance (typically sysman). You also need the credentials for the owner of the database host to run the production-to-test scripts.

4.1.1.2 Which Servers are Involved

An installation of Fusion Applications may be spread over any number of server hosts; different machines or Oracle VMs may be used for the transactional database, the Oracle Identity Management components, the Fusion Applications components themselves, the particular products such as Oracle Fusion Customer Relations Management, and/or the Business Intelligence (BI) applications. With two matching installations, those servers are doubled.

When performing the production-to-test data movement, only the following servers are involved and need to be registered and called from Cloud Control:

Production Hosts

Test Hosts

None

Database host

Fusion Applications host aka MidTier host

Fusion Applications secondary host aka MidTier host

None

Beehive-CRM host

None

BI host

Note that, as a security measure, the production database is not touched directly. Instead, the database contents are accessed through the RMAN backup file, which must be accessible to the destination (test) database host.

4.1.1.3 What's Included in the Production-to-Test Package

Unzip the famigratep2t.zip in a location that is accessible by the host machine where the Cloud Control is running.

After unzipping, you should see the following directory structure and files:

components  directives  metadata  procedures  sample_inputs  swlib.xml

./components:
famigratep2t_component.zip

./directives:
extract_component.sh

./metadata:
dictionary_extract_component.xml  properties_extract_component.xml
dictionary_famigrate_p2t.xml      properties_famigrate_p2t.xml

./procedures:
FA_P2T.xml

./sample_inputs:
FA_P2T_DP_rac.input  FA_P2T_DP_single.input

Note:

The path where you unzipped the P2T package will be required in the subsequent emctl calls. It will be referred to as the unzip_location_path.

The components directory contains a zip file with all the shell scripts, .jar files, and other code that comprise the Production-to-Test logic. You do NOT need to unzip this component; Cloud Control will do that automatically when a deployment procedure is run.

The directives directory contains a shell script to unzip and install the code at a location where Cloud Control can find it.

The metadata directory contains the metadata used by the component and directive.

These three directories, along with swlib.xml, constitute the Cloud Control "software library" that will be registered with Cloud Control in the following procedures.

The sample_inputs files will be edited with your environment variables.

4.1.1.4 Process Overview

After the prerequisites are met and the backups and snapshots taken, you can proceed with the two major processes:

- Section 4.1.2, "Move the Required Oracle Identity Management Data"

- Section 4.1.3, "Perform the Data Refresh"

4.1.2 Move the Required Oracle Identity Management Data

When you update the test environment with the production transaction data, you must also bring the Oracle Identity Management objects to which those data refer. These include such objects as the enterprise users, roles, and application policies. The process includes the following steps:

- Identify and perform the prerequisites. See Section 4.1.2.1.

- Execute the Oracle Identity Manager prerequisite script. See Section 4.1.2.2

- Move the Oracle Internet Directory. See Section 4.1.2.3.

- Run the Oracle Identity Manager post-replication script. See Section 4.1.2.4

- Modify Oracle Platform Security Services properties and run the OPSS script. See Section 4.1.2.5.

4.1.2.1 Prerequisites for Oracle Identity Management Movement

- Servers: Before beginning movement on the Oracle Identity Management components, the Fusion Applications servers should be shut down. After the Oracle Identity Management movement is complete, those servers must be restarted.

- Access Oracle Identity Management production-to-test components: Moving the Oracle Identity Management objects requires using properties files and scripts to transfer the Oracle Identity Manager, the Oracle Internet Directory, and the Oracle Policy Store.
To begin, access the automated scripts location:

$oim_home/idmscripts/idmp2t/

There you will find the properties files referenced in the following tasks.

Note:

If the Oracle Internet Directory and the Oracle Identity Manager are set up on different hosts, you will need to copy the scripts from $oim_home/idmscripts/idmp2t to the Oracle Interest Directory host.

Each of the various scripts uses the elements described in the following table.

Table 4-1 Script Elements Used in Production-to-Test Scripts

Script Elements

Description

-pfile

Properties file with input parameters. For example oim-params.txt.

-stage

Stage in which the script is being executed. Supported values for OIM are PRE and POST

-target

Host against which the script is being executed. Supported values are SOURCE and DESTINATION.

-logdir

Optional. Directory name where log files are written

4.1.2.2 Execute Oracle Identity Manager Prerequisite Script

1. On the destination Oracle Identity Manager host, update the oim-params.txt file with the appropriate destination values, as described in the comments within the file.

2. Execute the following script:

./p2t-oim.sh --pfile oim-params.txt --STAGE pre --target destination --logdir /u01/oim/oim_home/idmscripts/idmp2t/oim/logs

4.1.2.3 Move the Oracle Internet Directory

1. On the destination Oracle Internet Directory host, update the oid-params.txt file with the appropriate destination values, as commented in the file itself.

2. Execute following script, which takes care of pre-replication, replication, configuration, and post-replication steps.

./p2t-oid.sh --stage all --rename TRUE

4.1.2.4 Run Oracle Identity Manager Post-Replication Script

On the destination Oracle Identity Manager host, execute the following script:

./p2t-oim.sh --pfile oim-params.txt --STAGE post --target destination --logdir /u01/oim/oim_home/idmscripts/idmp2t/oim/logs

4.1.2.5 Modify Oracle Platform Security Services Properties and Run the OPSS Script

1. Copy the jps-config.xml file and the bootstrap directory from the Oracle Identity Manager host to the matching destination host.

2. On the destination host, update the opss.properties file with appropriate destination values, as commented in the file itself.

3. Execute the following script to migrate the Oracle Platform Security Services:

./p2t-opss.sh --pfile opss.properties --stage post

Note:

Remember to restart the Fusion Applications servers before moving on to the next section.

4.1.3 Perform the Data Refresh

After the Oracle Identity Management components have been updated, the production-to-test movement for Fusion Applications data can begin.

To copy data from the production environment to the test environment:

1. Unpack the production-to-test components and register them in the Oracle Enterprise Manager Cloud Control (Cloud Control). See Section 4.1.3.1.

2. Edit the sample properties file included in the Production-to-Test package to match your system environment. See Section 4.1.3.2.

3. Execute the production-to-test scripts. See Section 4.1.3.3.

4. Apply data masking to sensitive information. See Section 4.1.3.4.

4.1.3.1 Register the Production-to-Test Components

It is presumed that you have Enterprise Manager Cloud Control installed and configured, with all the necessary Fusion Applications servers registered and successfully communicating with Cloud Control. If not, go to the Oracle Enterprise Manager Cloud Control Basic Installation Guide and complete those procedures before returning here.

To set up the production-to-test software library and deployment procedure so they can be launched:

1. On the host where the Cloud Control instance resides, register the software library using the following command:

emctl register oms metadata -service swlib -file unzip_location_path -pluginId "oracle.sysman.emas" -sysman_pwd "OMS password"

The following output should result:

Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.1.0
Copyright (c) 1996, 2011 Oracle Corporation.  All rights reserved.
Metadata registration successful

2. You can also check the Cloud Control interface to confirm that the software library was successfully registered. From the Enterprise menu, select Provisioning and Patching, then Software Library. The Software Library page is displayed.

3. To register the deployment procedure, use the following command:

emctl register oms metadata -service procedures -file unzip_location_path/procedures/FA_P2T.xml -pluginId "oracle.sysman.emas" -sysman_pwd "OMS password"

The following message should be displayed:

Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.1.0
Copyright (c) 1996, 2011 Oracle Corporation.  All rights reserved.
Metadata registration successful

4. You can also check the Cloud Control interface to confirm that the deployment procedure was successfully registered. From the Enterprise menu, select Provisioning and Patching, then Procedure Library. The Deployment Procedure Manager is displayed, showing the Production to Test Procedure.

4.1.3.2 Edit the Properties File

The deployment procedure requires a set of variables and their values which must be defined in one of the.input files supplied with the package.

1. Access the appropriate sample file for your environment, either FA_P2T_DB_single.input (for a single-instance database), or FA_P2T_DB_rac.input (for RAC/ASM environments).

2. Edit the host names, paths, credentials, and other values to match your production (source) and test (destination) environments. Note that the credentials for the mid-tier host should match the user ID that owns ORACLE_HOME. Similarly, the credentials for the database host should match the user ID that owns the database. All variables are annotated with comments in the file itself.

4.1.3.3 Execute the Production-to-Test Scripts

The deployment procedure can be run either from the Cloud Control host or from any of the Oracle VM hosts that have emcli available under APPTOP.

To launch the deployment procedure:

1. Log in to emcli:

emcli login -username="sysman"

2. Run the command:

emcli submit_procedure -name=FA_P2T_DP -input_file=data:file name

The following output is displayed:

Verifying parameters ...
Schedule not specified, defaults to immediate
B11EF6EAE4E0E958E040E40A4F887E88
Deployment procedure submitted successfully

To review and track the progress of the deployment procedure execution using the Cloud Control interface:

1. From the Enterprise menu, select Provisioning and Patching, then Procedure Activity.
The Deployment Procedure Manager displays the Activity page, including the status of the run of this deployment procedure.

2. Select the appropriate link in the Run column to see more details. The resulting screen lists all phases and steps of the deployment procedure.

3. Select a link in the Status column to see the output of a step.

4. Click an item in the Status column to review the Job Execution page. Click an item in the Job Status column to review the complete log file.

4.1.3.4 Apply Data Masking to Sensitive Data

After the data has been moved to the test system, sensitive information should be masked for legal and security reasons. For instructions, see the "Data Masking" section of the Oracle Fusion Applications Administrator's Guide.

4.2 Perform a Full Clone

It is often convenient to create a new Fusion Applications instance from an existing one, particularly when creating multiple staging instances. Cloned instances might be used for training purposes, to sandbox different sets of customizations, or to complete a long customization process without being disrupted by patch or upgrade bundles. Each clone will be identical to, and independent from, the source instance.

4.2.1 Introduction

Review the core concepts of cloning and its requirements.

4.2.1.1 Concepts and Terminology

- Full clone: A full clone is an instantaneously created, read-writable copy of a snapshot. One or more full clones can be created from a single snapshot. Only full cloning is supported now.

- Cold clone vs. hot clone: The full clone service supports only cold cloning, that is: cloning from a backup, when all source system or server components are shut down. This implies that the source will not change during cold cloning, so server information will be duplicated with 100% accuracy. A "hot" clone, by contrast, occurs as just one of many running processes, and the integrity of the copied data may be compromised if any files are in use during the hot cloning process.

4.2.1.2 Technical Assumptions and Requirements

Review the cloning requirements for administrators, the installation environment, and the instance configurations:

4.2.1.2.1 Users

It is assumed that Oracle Fusion Application administrators who will use this document to perform cloning are:

- Familiar with installing and configuring Oracle Fusion Applications using Oracle VM template deployment

- Familiar with using and NFS storage application such as NetApp or Sun ZFS Storage Appliance.

4.2.1.2.2 Environment

Cloning requires the following system and database versions:

- Operating system: Oracle Enterprise Linux 4.x, 5.x, (and higher)

- Oracle Transaction Database: Oracle 11.2.0.3 and above. Both source and target databases must be on RAC and ASM.

- Protocol: NFSv3, NFSv4

- Storage: Such as NetApp or Oracle Sun ZFS Storage Appliance

4.2.1.2.3 Configurations

Note the configuration requirements:

- The source was created using Oracle VM templates, or is a clone of such a deployment.

- Only software components and configurations supported natively in Oracle VM deployment are supported in cloning.

- The source and destination must have the same topology.

- The source can be HA-enabled/ scaled-out.

- Source and destination may have different database configurations. For example, the source can run on RAC while the destination runs on single-instance, and vice versa.

- Source does not need to be accessible while cloning is in progress.

- Long-running, in-flight data will be cleared at the destination.

- Alterations made to local storage (as opposed to the external NFS storage) will not be moved. Such local storage could include files such as /temp, /scratch, and /var, as well as any FA OHS configuration changes or third-party software installed separately from Fusion Applications.

4.2.1.3 Process Overview

The cloning process requires the following high-level steps:

- Section 4.2.2, "Prepare the Source and Create a Backup"

- Section 4.2.3, "Prepare the Destination Environment"

- Section 4.2.4, "Prepare Deployer Host and Fill Out Oracle VM Deploy Properties"

- Section 4.2.5, "Run the Cloning Deployment"

- Section 4.2.6, "Remove a Cloned Environment (Optional)"

4.2.2 Prepare the Source and Create a Backup

Begin with a fully configured Oracle Fusion Applications source, built from Oracle VM templates. Ensure that you have sufficient memory/hypervisor capacity to accommodate a duplicate of the source environment. Then follow the tasks below to prepare the topography, take an RMAN backup of databases, gather source database parameters, and create an rsync -a backup of the entire source.

Task 1   Prepare the topology

Create NFS storage locations that duplicate the source storage locations. For example, a typical installation might require five to seven locations, such as:

- 1 for the database backups (fusiondb, oimdb, and oiddb)

- 1 for OHS

- 1 for FA (eventually to be mounted to four hosts: Admin, Primary, Secondary, and BI (Business Intelligence))

- 1-3 for Oracle Identity Management (depending on whether a single- or 3-node installation was used on source)

- 1 for Webchat (if installed and used on source).

The NFS locations must be accessible from the source, destination, and deployer hosts. They will be used to store the RMAN database backups and the rsync copies of the source directories.

Task 2   Back up the databases

Take an RMAN backup of the transaction database (fusiondb), and the Oracle Identity Management databases (oimdb and oiddb). If archivelog mode is turned ON, a HOT backup must be taken using "backup database plus archivelog". (This requirement is due to an RMAN duplicate limitation.) If archivelog mode is NOT on, a COLD backup must be taken using "backup database".

Task 3   Gather database parameters on the source system

These will be used in the deployment properties on the destination.

Queries for looking up properties on each database:

select name from v$datafile;
select member from v$logfile;
select name from v$tempfile;
select tablespace_name from dba_tablespaces where tablespace_name like '%UNDO%';

Note: If you are using a RAC database, use the tablespace from node1.

Task 4   Use rsync to back up the source

We recommend using rsync-a (archive) to make an identical copy of the source file system. Log in to a source host where the source storage location is mounted, and run a command such as:

rsync-a/OHS1/*/net/xxxx

where OHS1 is a source directory, and xxxx is a matching destination storage location. This creates a copy. Repeat for each source storage (OHS, FA, IDM, and Webchat).

4.2.3 Prepare the Destination Environment

Cloning is similar to a fresh installation and requires many of the same prerequisite steps, as described in Chapter 2. These include:

- Establishing the appropriate VM Servers and IP addresses for the destination. See Section 2.1. (Note that you can use the same Deployer Host that was allocated for the source installation.)

- Setting the "privilege escalation mechanism" for handling root privileges. See Section 2.3.

- Allocating IP endpoints for the destination. See Section 2.6.

- Creating new (empty) database instance so that the rman backup can be restored back as part of fullclone process. Section 2.7.

- Confirm that the OVAB Home is accessible to the deployer host. See Section 2.10

- Registering templates. If the hypervisor used for the destination already has the templates registered, this step is not needed. Otherwise, see Section 2.11.

- Installing the Oracle VM Automation utility to the deployer host. (This utility includes the CloneTopography option.) See Section 2.12.

- Enabling a Secure Shell (SSH) for the deployer host. See Section 2.13

Observe that not every step in Chapter 2 is replicated; it is unnecessary to allocate a deployer host, install an Oracle VM Manager, prepare an Oracle Enterprise Manager instance, or configure a stand-alone Oracle Identity Management for cloning.

4.2.4 Prepare Deployer Host and Fill Out Oracle VM Deploy Properties

Ensure that you have unzipped oracle-ovmautomation-all.zip on the deployer host, so that the cloning tools are available.

Then fill out the Oracle VM deploy properties (~/deployfw/deployprops/ovm-ha-deploy.properties) as in a fresh installation (Section 3.1). Also include the cloning-specific properties annotated in the following sections.

4.2.4.1 Deployment Properties for Databases

Properties for the transaction database and the Oracle Identity Management databases must be set.

4.2.4.1.1 Transaction Database (Fusion DB)

Note that .src file properties are new and must be added to the properties file.

faovm.ha.fusiondb.new.do.restore=true
faovm.ha.fusiondb.new.do.backup.push=false
faovm.ha.fusiondb.new.do.reset.on.cleanup=false
faovm.ha.fusiondb.new.backup.stage.path=/net/slcaf463/db_clone/fusiondb
(This the fusionDB backup location, make sure it's accessible from the target)
faovm.ha.fusiondb.src.datafile.path=<enter-source-datafile-location>
faovm.ha.fusiondb.src.tempfile.path=<enter-source-tempfile-location>
faovm.ha.fusiondb.src.recolog.path=<enter-source-log-location>
faovm.ha.fusiondb.src.undo.tablespace.name=<enter-source-undo-tablespace-name>

4.2.4.1.2 Oracle Internet Directory Database (OIDDB)

faovm.ha.oiddb.new.do.restore=true
faovm.ha.oiddb.new.do.backup.push=false
faovm.ha.oiddb.new.do.reset.on.cleanup=false
faovm.ha.oiddb.new.backup.stage.path=/net/slcaf463/db_clone/oiddb
(This is the oidDB backup location; make sure it's accessible from the target)
faovm.ha.oiddb.src.datafile.path=<enter-source-datafile-location>
faovm.ha.oiddb.src.tempfile.path=<enter-source-tempfile-location>
faovm.ha.oiddb.src.recolog.path=<enter-source-log-location>
faovm.ha.oiddb.src.undo.tablespace.name=<enter-source-undo-tablespace-name>

4.2.4.1.3 Oracle Identity Manager Debatable (OIMDB)

faovm.ha.oimdb.new.do.restore=true
faovm.ha.oimdb.new.do.backup.push=false
faovm.ha.oimdb.new.do.reset.on.cleanup=false
faovm.ha.oimdb.new.backup.stage.path=/net/slcaf463/db_clone/oimdb
(This the oimDB backup location; make sure it's accessible from the target)
faovm.ha.oimdb.src.datafile.path=<enter-source-datafile-location>
faovm.ha.oimdb.src.tempfile.path=<enter-source-tempfile-location>
faovm.ha.oimdb.src.recolog.path=<enter-source-log-location>
faovm.ha.oimdb.src.undo.tablespace.name=<enter-source-undo-tablespace-name>

4.2.4.2 Deployment Properties for Storage

A full clone uses rsync backup.

4.2.4.2.1 From an rsync Backup:

faovm.storage.type=genericnfs
faovm.storage.use.parent=true

# Generic, Pre-defined NFS
faovm.storage.genericnfs.host=<sun storage hostname>
faovm.storage.genericnfs.nfs.export.root=/vol
faovm.storage.genericnfs.nfs.mount.options=rw,hard,nointr,rsize=32768,wsize=32768,timeo=600
# Host/IP to use on the deployer when mounting storage
faovm.storage.genericnfs.deployer.nfs.mount.host=${storage.genericnfs.host}
# Host/IP to use in deployed VMs when mounting storage
faovm.storage.genericnfs.vm.nfs.mount.host=${storage.genericnfs.host}
# Settings used when external storage solution is managing parent storage cloning
faovm.storage.genericnfs.parent.nfs.export.root=${storage.genericnfs.nfs.export.root}

faovm.ha.fa.storage.name=<fa-storage-clone-name>
faovm.ha.fa.storage.parent.name=<parent-clone-name>

faovm.ha.ohs.storage.name=<ohs-storage-clone-name>
faovm.ha.ohs.storage.parent.name=<parent-clone-name>

4.2.4.3 Oracle Identity Management Properties

The properties differ depending on the number of nodes in the source Oracle Identity Management system.

4.2.4.3.1 If using a single-node, stand-alone Oracle Identity Management:

faovm.ha.idm1.storage.name=<idm-storage-clone-name>
faovm.ha.idm1.storage.parent.name=<parent-clone-name>

4.2.4.3.2 If using a 3-node, stand-alone Oracle Identity Management:

faovm.ha.idm3oid.storage.name=<idm-oid-storage-clone-name>
faovm.ha.idm3oid.storage.parent.name=<parent-clone-name>

faovm.ha.idm3mw.storage.name=<idm-mw-storage-clone-name>
faovm.ha.idm3mw.storage.parent.name=<parent-clone-name>

faovm.ha.idm3ohs.storage.name=<idm-ohs-storage-clone-name>
faovm.ha.idm3ohs.storage.parent.name=<parent-clone-name>

4.2.4.4 Beehive/webchat Properties (if using):

faovm.ha.webchat.storage.name=<webchat-storage-clone-name>
faovm.ha.webchat.storage.parent.name=<parent-clone-name>

4.2.4.5 Set Cloning-Specific Block of Parameters

Note: All credential.<user>.password keys must have <USER> uppercased, regardless of the <user> case used elsewhere. All <user> values are uppercased before property lookup. Below are the required overrides when cloning.

faovm.credential.BEE_DATA.password=CHANGEME
faovm.credential.BEE_CODE.password=CHANGEME
faovm.credential.BEE_MDS.password=CHANGEME
faovm.credential.FUSION.password=CHANGEME
faovm.credential.CRM_FUSION_SOAINFRA.password=CHANGEME
faovm.credential.OAMADMINUSER.password=CHANGEME
faovm.credential.OIM_ADMIN.password=CHANGEME
faovm.credential.TECHSTACK.BI.RPD.password=CHANGEME
faovm.credential.FUSION_APPS_PROV_PATCH_APPID.password=CHANGEME
faovm.credential.OAM.WEBGATE.password=CHANGEME

4.2.5 Run the Cloning Deployment

As in a fresh install, this involves setting environment variables, running a deploy script, and verifying the status of data and scheduling.

4.2.5.1 Set the Environment Variables and Invoke Deployment

Set the environment variables:

export JAVA_HOME=<JAVA_HOME location>
export OVAB_HOME

4.2.5.2 Invoke the Deploy Script

Invoke the deploy script in cloning mode:

\-bash-3.2$ faovm/deployfw/bin/faovmdeploy.sh cloneTopology type=ha

4.2.5.3 Verify Status

Verify the status of the clear inflight data and schedule.

4.2.5.3.1 Verify Status of Clear Inflight Data

Log in to the Fusion Applications host. /assemblybuilder/logs/ab.out shows the status of the execution.

\[00:23:17/fa\]&nbsp;&nbsp; Executing Task: Purge FA Queues ... Done. \[0m6s\]
\[00:23:23/fa\]&nbsp;&nbsp; Executing Task: Truncate Soa Tables ... Done. \[0m15s\]
\[00:23:38/fa\]&nbsp;&nbsp; Executing Task: Truncate Ess Tables ... Done. \[0m6s\]
\[00:23:45/fa\]&nbsp;&nbsp; Executing Task: Recreate UMS Tables ... Done. \[0m2s\]
\[00:23:47/fa\]&nbsp;&nbsp; Executing Task: Truncate Table ATK_POPUP_ITEMS ... Done. \[0m0s\]

4.2.5.3.2 Verify Status of the Schedule Recreation

Log in to the secondary host. /assemblybuilder/logs/ab.out shows the status of the execution.

ab.out output :
\[20:39:24/secondary\] Executing Task: oracle.apps.fnd.provisioning.ovm.rehydratefw.cli.cmd.fa.HR2HRODICmd ... Done. \[0m8s\]
\[20:39:33/secondary\] Executing Task: Export SES Schedules ... Done. \[0m25s\]
\[20:39:58/secondary\] Executing Task: Delete SES Schedules ... Done. \[0m8s\]
\[20:40:07/secondary\] Executing Task: Update SES Schedules ... Done. \[0m9s\]
\[20:40:16/secondary\] Executing Task: oracle.apps.fnd.provisioning.ovm.common.cli.cmd.WLSTScheduleESSJobsForAllPillarsCmd ... Done.

4.2.6 Remove a Cloned Environment (Optional)

Should you want to completely remove the components you've installed on a destination environment, use the cleanupTopology option

\-bash-3.2$ faovm/deployfw/bin/faovmdeploy.sh cleanupTopology type=ha

This will clean up the destination Virtual Machines, but does not revert any changes made to the destination NFS storage locations and databases.

Glossary

deployment

The process that is triggered on the deployer host when the user invokes the faovmdeploy.sh createTopology command. During the process of deployment, the Oracle VM servers that are part of the topology are created from the Oracle VM Template and are started.

HA

A method of implementation in which each component or functional group of software components is replicated on a different computer and configured for component-level high availability. You can choose whether you want HA during the creation of the Oracle VM instance.

High Availability (HA)

See HA.

Oracle VM Template

Defines all of the topologies that will be deployed on Hypervisor servers along with associated artifacts, such as volumes and firewall configurations necessary to set up an Oracle Fusion Applications instance.

reference environment

The environment delivered in the Oracle VM Template.

rehydration

The process that runs during the initial phase of Oracle VM deployment and performs additional reconfiguration steps that are specific to each Oracle VM

target database

An existing database located on a physical machine, where Oracle VM Manager restores the Recovery Manager backup that is delivered as part of the Oracle VM Template.

Oracle Legal Notices

Copyright Notice

Copyright © 1994-2014, Oracle and/or its affiliates. All rights reserved.

Trademark Notice

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

License Restrictions Warranty/Consequential Damages Disclaimer

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

Warranty Disclaimer

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

Restricted Rights Notice

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

Hazardous Applications Notice

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Third-Party Content, Products, and Services Disclaimer

This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Alpha and Beta Draft Documentation Notice

If this document is in preproduction status:

This documentation is in preproduction status and is intended for demonstration and preliminary use only. It may not be specific to the hardware on which you are using the software. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to this documentation and will not be responsible for any loss, costs, or damages incurred due to the use of this documentation.