Oracle E-Business Suite Maintenance Guide Release 12.2（Patching Procedures）

更多内容参考: http://docs.oracle.com/cd/E51111_01/current/acrobat/122ebsmt.zip

Preparing for Patching

For patches that have manual steps, the patch readme file instructs you to use Oracle Patch Application Assistant (PAA) to create customized instructions for your system. PAA consolidates and displays only the relevant manual steps for all the patches you want to apply, including steps that you have completed. It also automatically merges the contents of individual patch readme files for a merged patch.

Create Checklist of Product Functionality Disabled in Online Patching Cycle

During an online patching cycle, the following product restrictions will apply. Before you commence patching, you should therefore ensure there will be no requirement for any these actions or features until the cycle is complete.

• Payroll

  • Users will not be able to define Fast Formulas or use the Fast Formula Assistant.

  • Users will not be able to perform dynamic trigger maintenance.

  • Users will not be able to create, update, or delete US Cities.

  • Data Pump meta-mapper generator will be disabled.

  • The Japanese Balance Dimensions concurrent program will be deferred to after the cutover phase is complete.

  • Pension Calculation Setup cannot be used.

  • US localization earnings and deduction setup cannot be used.

  • Tax Withholding Rules Setup cannot be used.

  • Wage Attachment Earnings Rules Setup cannot be used.

  • Garnishment Rules Setup cannot be used.

  • Quick Paint Reports cannot be used.

  • Quantum Program Update Installer execution is unavailable.

• Order Management:

  • Creation of a new Defaulting Condition in the Attribute Defaulting Rules form is disabled, unless the same seeded condition already exists for a given attribute.

• Warehouse Management:

  • WMS Rule creation is restricted.

• Inventory:

  • Concurrent program “Generate Stock Locator Flexfield Definition for Mobile Transactions” will be disabled.

• Public Sector Financials International:

  • Users will not be able to run the following concurrent programs:

    • Subledger Security: Apply Security

    • Subledger Security: Import/Export Data Fix

• Subledger Accounting:

  • Users will not be able to Validate the Application Accounting definitions.

• Accounts Receivable:

  • Users will not be able to create new Transaction Sources.

• Incentive Compensation:

  • Transaction collection process for new mappings will not be available and any changed mapping will continue to use previous mapping rules.

  • Users will not be able to run the “Synchronize Classification Rulesets” program.

  • Users will not be able to use the “Formula Generation” feature.

  • Users will not be able to specify new formulas or changes to compensation rules.

• Oracle Demand Planning:

  • Demand plans will not be available for users.

Global Inventory Requirements

• A global (central) inventory is required for all Oracle E-Business Suite Release 12.2 application tier nodes.

• The central inventory location must be identified by the /oracle/oraInventory.loc file.

• On a shared file system, the global inventory location must be shared and used by all participating nodes.

• The use of a local inventory per Oracle E-Business Suite installation is not currently supported.

If you are using a UNIX platform, you should verify the existence and contents of the oraInst.loc file, which specifies the location of the oraInventory.loc file global inventory file.

1. Check that oraInst.loc exists in the correct directory for your platform:

   Platform	oraInst.loc Location
   Oracle Solaris SPARC (64-bit)	/var/opt/oracle
   Linux x86-64	/etc
   IBM AIX on Power Systems (64-bit)	/etc
   HP-UX-Itanium	/var/opt/oracle

2. Confirm that the contents of oraInst.loc look like this:

   inventory_loc=/oracle/oraInventory

   where /oracle/oraInventory points to the directory where the central inventory is located. This location must be writable by the user account that is to run Rapid Install.

   Incorrect permissions on oraInventory may cause issues not only with online patching (fs_clone phase), but also when installing a system with Rapid Install or cloning a system with Rapid Clone.

   Note: If your system has separate installation user accounts for the database and the applications, both users must be in the same install group (inst_group) in oraInst.loc, which will need to contain a line such as inst_group=oracle.

If the oraInst.loc file does not exist, create it in the correct directory with contents as shown above.

Set Up Secure Shell on Application Tier Nodes

In a multi-node environment, adop commands are invoked by a user on the primary node. Internally, adop uses Secure Shell (ssh) to automatically execute required patching actions on all secondary nodes. You must set up passwordless ssh connectivity from the primary node to all secondary nodes.

Note: Rapid Install and Rapid Clone set up the ssh key infrastructure.

Principles

The ssh-keygen command is used to generate a private/public key pair. The private key is for the node from where all the remote nodes will subsequently be accessible by an ssh login that requires no password. The public key must be copied to each remote node's <User Home Dir>/.ssh directory.

In essence, the sequence is as follows:

1. The following command initiates creation of the key pair:

   $ ssh-keygen -t rsa

   Note: The <Enter> key should be pressed instead of a passphrase being entered.

2. The private key is saved in <User Home Dir>/.ssh/id_rsa.

   Important: As this read-only file is used to decrypt all correspondence encrypted with the public key, its contents must not be shared with anyone.

3. The public key is saved in <User Home Dir>/.ssh/id_rsa.pub.

4. The contents of the public key are then copied to the <User Home Dir>/.ssh /authorized_keys file on the systems you subsequently wish to ssh to without being prompted for a password.

The following example demonstrates the steps:

1. $ ssh-keygen -t rsa
   Generating public/private rsa key pair.
   Enter file in which to save the key (/u01/user2/.ssh/id_rsa):<Enter> 
   Enter passphrase:<Enter>
   Enter same passphrase again:<Enter>
   Your identification has been saved in /u01/user2/.ssh/id_rsa.
   Your public key has been saved in /u01/user2/.ssh/id_rsa.pub.
   The key fingerprint is: 16:d0:e2:dd:37:2f:8e:d5:59:3e:12:9d:2f:12:1e:5a

2. $ scp -pr /u01/user2/.ssh/id_rsa.pub \
   user2@system1:/u01/user2/.ssh/authorized_keys
   user2@system1's password:<password>
   id_rsa.pub 100% 398 0.4KB/s 00:00

3. $ ssh user2@system1

   Note: If you receive this message, it can safely be ignored: Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding.

Once this has been done for the relevant operating system account on all nodes - that is, ssh can log in from the primary node to each secondary node without entering a password - so you are ready to run adop on multiple application tier nodes. It must be run on at least the master (admin) node: from there, it will attempt to contact all the other application tier nodes that are part of the same Oracle E-Business Suite instance, and will run the required steps remotely on those nodes.

Important: If you change the password for the relevant operating system account on one or more nodes, you must regenerate the ssh credentials either using the $AD_TOP>/patch/115/bin/txkRunSSHSetup.pl script, or your own native solution if you prefer.

The txkRunSSHSetup.pl script has a -help option that shows relevant usage options.

For example, a basic command to enable ssh would be:

$ perl <AD_TOP>/bin/txkRunSSHSetup.pl enablessh -contextfile=<CONTEXT_FILE> -hosts=h1,h2,h3$ 

To verify ssh operation:

$ perl <AD_TOP>/bin/txkRunSSHSetup.pl verifyssh -contextfile=<CONTEXT_FILE> -hosts=h1,h2,h3 \
-invalidnodefile=<filename to report ssh verification failures>
@ nodes list> 

To disable ssh:

perl <AD_TOP>/bin/txkRunSSHSetup.pl disablessh

Creating Customized Instructions for Patching Using PAA

Requirement: How do I know which manual steps associated with a patch apply to my system?

Sorting through the manual steps in a patch readme file to determine which ones apply to your system can be time-consuming. The Patch Application Assistant allows you to create a customized set of steps to that apply to your unique instance. Using the information on this list reduces the possibility of performing steps that are not necessary or that have been completed previously during the application of another patch.

When you download and unzip a patch, it delivers a static README.html file that advises you if the patch requires manual steps. If manual steps are required, you can generate a list of the steps by running a Perl script (admsi.pl) to initiate PAA. Once you have generated the list, use the PAA interface to see a full list of steps, or only those steps that apply to your system.

After successfully performing each manual step, you can record that it was completed. When applying patches in the future, this information is displayed in the PAA interface so that you can see which manual steps you have already performed.

To run PAA

1. Download the patch that you want to apply and set (source) your environment. On UNIX systems, you must also set the environment variable DISPLAY to an active and authorized display.

   For instructions on setting your environment, see: Running AD Utilities in this book.

2. Run the admsi.pl script to generate customized installation instructions.

   $ admsi.pl
   

   The Oracle Patch Application Assistant welcome page appears:

   You can select:

   • View instance-specific instructions for a new patch.

   • View generic instructions as shipped by Oracle for a new patch - to view all the generic manual steps for a particular patch, including the completed steps.

   • Look at all incomplete tasks from previous patches - to view all the manual steps that have not been completed from previous patches.

3. Select View instance-specific instructions for a new patch. Enter the APPS password, and select the location where the patch is staged. Click Next.

   The Summary of Installation Instructions page appears:

   This page summarizes all the manual steps for the patch, grouped into the following categories: Preparation Tasks, Pre-Install Tasks, Apply the Patch, Post-Install Tasks, Finishing Tasks, and Additional Information. This page displays only those categories in which there are manual steps.

4. Click the plus-sign icon in each category for more detailed information. For example, if you click the plus sign icon next to Best Practices, the Preparation Tasks screen appears with the tasks suggested for preparing your system for patching.

5. After you have completed all the manual steps in a category, check the Completed box to record the completion status in the database, then click Next. If a patch that you apply in the future contains any of the same manual steps, it will be marked as completed to inform you that you do not have to perform that task again.

   After you have completed all manual steps in all categories, the system returns you to the Summary of Installation Instructions page.

   Note the column of Completed boxes that corresponds to each task in a category. Check marks appear in the boxes for which you have completed manual steps.

6. Click Save to record tasks completed in the database. Click Cancel to exit PAA.

The Online Patching Cycle

This section describes the online patching cycle from beginning to end, illustrating the actions taken in the different phases and putting into context the more detailed description of online patching in the following sections.

Important: This section is designed to be read in conjunction with the important background material provided in the Patching and Management Tools chapter of Oracle E-Business Suite Concepts.

Applying Oracle E-Business Suite patches without a significant system downtime is referred to as online patching, and a new utility, adop, is used to apply patches.

Online patching is supported by the capability of storing multiple application editions in the database, and the provision of a dual application tier file system. At any given point in time, one of these file systems is designated as 'run' (part of the running system) and the other is the 'patch' (either being patched or awaiting the start of the next patching cycle). Whichever is the current run file system appears to the user in exactly the same way as the single application tier file system did in Oracle E-Business Suite releases prior to 12.2.

Important: The existence of the dual file system has implications for patches that change the system configuration. The adop utility is required for applying software patches to the patch file system, but is not required for applying patches that change the configuration: such patches can be applied to the run file system, or optionally to the patch file system (both options are supported, with automatic synchronization taking place).

There are also implications for where general (non-patching) maintenance activities are carried out. For important information on choosing the appropriate file system to run AD tools from, refer to: Choosing the Correct File System For Maintenance Tasks in Chapter 7 of this book.

A new environment variable, $FILE_EDITION, shows the current designation of a given dual file system member. Three other new environment variables designate the root directories of the run ($RUN_BASE), patch ($PATCH_BASE), and non-editioned ($NE_BASE) file systems.

For example:

• $FILE_EDITION = patch

• $RUN_BASE = /u01/R122_EBS/fs1

• $PATCH_BASE = /u01/R122_EBS/fs2

• $NE_BASE = /u01/R122_EBS/fs_ne

When a patch is being applied, the Oracle E-Business Suite system is running in normal production mode (full functionality, with some documented exceptions) in the run edition of the file system and database. Full application functionality is retained as patch execution proceeds, until the cutover phase is reached (as described later in this section).

Important: Do not attempt to clone an Oracle E-Business Suite system while an online patching cycle is in progress.

The online patching cycle consists of a number of high level phases:

1. prepare

2. apply

3. finalize

4. cutover

5. cleanup

A high level overview of an online patching cycle would, programmatically, look like this:

# Prepare for patching:
$ adop phase=prepare

# Apply patches:
$ adop phase=apply patches=<patch number>

# Apply any customizations to patch edition (optional):
$ . <EBS_ROOT>/EBSapps.env patch
$ sqlplus apps/apps @my_custom_script_01
$ sqlplus apps/apps @my_custom_script_02
...

# Finalize patch application:
$ adop phase=finalize

# Perform cutover:
$ adop phase=cutover
$ . <EBS_ROOT>/EBSapps.env run

# Perform user acceptance testing via application UI

# Perform cleanup:
$ adop phase=cleanup

Important Additional Points

• After an online patching cycle is started, you should not perform any configuration changes in the run edition file system. Any that are made will not be propagated, and will therefore be lost after cutover is complete.

• The prepare, apply, and fs_clone phases all require at least 10GB of free disk space. All other phases require 1GB of free space. A warning message will be displayed if less than the needed amount is available.

• Customizations are applied to the patch edition during the apply phase, normally after any Oracle E-Business Suite patches have been applied.

Special Phases

Two additional phases are provided for specialized use. Neither can be run in conjunction with any other phase. Further details of these phases are described in later sections.

• The abort phase is used to terminate a patching cycle before it is complete, and roll back any changes that have been made.

• The fs_clone phase is a separate command used to synchronize the patch file system with the run file system. Use of fs_clone is normally not required. Situations that do require fs_clone are will explicitly document that requirement.

  Note: Standard cloning (using adcfgclone.pl) cannot be used to synchronize the run and patch file systems. It can only be used for traditional cloning scenarios, for example cloning a development system to a test system. Conversely, fs_clone is only for use with adop.

The Online Patching Cycle

adop will automatically set its environment as required, but it is the user's responsibility to set the environment correctly for any other commands that may be run. Set the run edition environment whenever executing commands that you intend to affect the run edition.

For example:

$ . <EBS_ROOT>/EBSapps.env run
$ adstrtal.sh

Set the patch edition environment whenever you intend to execute commands that affect the patch edition.

For example:

$ . <EBS_ROOT>/EBSapps.env patch
$ sqlplus apps/apps @my_custom_patch_script.sql

The adop tool executes non-interactively, executing the specified phase or phases in order. In a multi-node deployment, adop is only executed by the user on the master node: internally, adop will use ssh remote execution to run required actions on all secondary nodes automatically. In addition, adop can be used to generate reports about patching operations in the environment.