SAP Note

Header Data

Symptom

This note describes the installation of Oracle database patches with the Multiple Oracle Patch (MOPatch) tool. With MOPatch you can install multiple Oracle database patches in one run into an Oracle Home. It automates the process of unpacking the patches and calling "opatch apply" for each of them. MOPatch is available as of Oracle release 10.2.0.2 and available for UNIX platforms only. MOPatch provides a number of command-line options, which are described in detail in this note. To get a short overview of the available options, run MOPatch with option "-h", for example:     $ /bin/sh $ORACLE_HOME/MOPatch/mopatch.sh -h

What's New

Versions 2.1.11 and 2.1.12:

l MOpatch supports OPatch 11.2.0.1.9.

Versions 2.1.9 and 2.1.10:

l MOPatch distinguishes RDBMS patches and Grid Infrastructure patches and installs them into the appropriate Oracle Homes only.

Version 2.1.8:

l MOPatch does not skip Database-Vault-special patches on RDBMS versions 11.2.0.1.0 and 11.2.0.2.0.

Version 2.1.7:

l MOPatch provides more detailed information regarding online patches in its final status report.

Version 2.1.6:

l MOPatch supports installation of online patches.

l MOPatch does not include the post-installation status in its report, since all post-installation steps are now executed as part of the catsbp.sql script of an SAP Bundle Patch.

Version 2.1.5:

l MOPatch supports new OPatch functionality required by October PSUs.

Version 2.1.4:

l MOPatch detects OPatch version 10.2.0.5.0 as valid OPatch version.

Version 2.1.3:

l MOPatch detects more SUN platforms.

Version 2.1.2:

l MOPatch installs any PSU first to avoid problems with unusual patch dependencies.

Version 2.1.1:

    1027012 - MOPatch - Install Multiple Oracle Patches in One Run  

Version   31     Validity: 10.02.2012 - active   Language   English (Master)

Released On 10.02.2012 12:32:28

Release Status Released for Customer

Component BC-DB-ORA Oracle

BC-DB-ORA-INS Installation SAP System with Oracle

Priority Recommendations / Additional Info

Category Installation information

Other Components

l MOPatch works around a restriction of the awk utility on certain platforms (HP-UX, Tru64).

Version 2.1: MOPatch version 2.1 introduces a number of incompatible changes compared to the previous version 1.9. In the following list, these are marked in bold face.

l MOPatch supports newer OPatch versions, among these 10.2.0.4.7, 10.2.0.4.9, 11.1.0.6.6, 11.1.0.1.1.

l MOPatch does not support some older versions of OPatch any longer (10.2.0.2.4 and earlier, 10.2.0.4.1 and earlier).

l MOPatch supports installation of Patchset Updates, Critical Patch Updates,  and n-apply patches. You can switch this off by disabling flags "apply_psu", "apply_cpu", "apply_napply", respectively. See "Appendix D. MOPatch Flags". In particular, MOPatch supports installation of SAP Bundle Patches.

l MOPatch supports forced installation of conflicting patches.  You can control this feature, also referred to as "automatic conflict resolution", with command-line option "-f". See section "Resolving Patch Conflicts and Errors". By default, MOPatch installs conflicting new patches over installed patches, silently rolling back the installed patches.

l MOPatch detects Critical Patch Updates, Patchset Updates, and other patches that might require special post-installation instructions and flags these in its status report.

l MOPatch parses patch metadata in a more structured way and provides additional information on the new patches and the installed patches in its output.

l MOPatch looks up patches in multiple source files and directories, which you can specify with command-line option "-s". (As a side-effect, you can use MOPatch to conveniently install a single patch.)

l MOPatch recognizes new README templates and strips patch READMEs more reliably.  In addition, MOPatch attempts to detect any non-standard patch READMEs and flags these in its status report.

l The "dry-run mode" has been renamed to "documentation mode".

l MOPatch can be aborted in a controlled way with the "mpkill.sh" script. As a side-effect, MOPatch does not start if another MOPatch process is already running (but that must not be abused as a locking mechanism, as it is not multi-process safe).  See section "Interrupting MOPatch".

l MOPatch reads command-line options from a configuration file or from an environment variable and thus provides per-Oracle-Home and per-user configurability. See "Appendix E. MOPatch Configuration."

l MOPatch provides command-line option "-j" to pass the location of the Java Runtime Environment to all OPatch calls.

l MOPatch uses command-line option "-F" for specification of MOPatch flags (instead of the previous "-f").

You can disable the most important incompatible changes, namely installation of Critical Patch Updates and automatic conflict resolution, by providing a MOPatch configuration file "$ORACLE_HOME/.mopatchrc" with the following contents:     -f old     -F !apply_cpu Alternatively, you can directly specify these command-line options when invoking MOPatch.

Other Terms

l For general and patch-specific information, see the relevant SAP notes about the current Oracle database patches:

¡ SAP note 1431795 (11.2.0.1.0)

¡ SAP note 839187 (10.2.0.4.0)

l MOPatch supports all OPatch versions except those mentioned below.  It is recommended to use the OPatch versions that are available one the SAP Service Marketplace, since these are tested for interoperability with MOPatch. MOPatch does not support the following OPatch versions:

¡ 10.2.0.4.1 and earlier versions

¡ 10.2.0.2.4 and earlier versions

¡ all 10.1 and 9.* versions

l MOPatch requires an up-to-date "unzip" utility. As of version 1.7, MOPatch by default uses the "unzip" utility that is located at $ORACLE_HOME/bin.

l MOPatch requires a Posix shell. The only platform where this seems to be an issue is Tru64 Unix. As a work-around, set environment variable "BIN_SH" to the value "xpg4" on this platform or call MOPatch by means of the shell /usr/bin/posix/sh instead of /bin/sh as shown in the examples.

l You cannot use MOPatch to install some types of Oracle database patches. MOPatch automatically detects whether a patch belongs to any of the following categories and refuses to install it if this is the case. In practice, almost all patches on SAP Service Marketplace are plain OPatch patches or SAP Bundle Patches, and do not belong to any of the following categories:

¡ Cluster Ready Services (CRS) patches and CRS bundle patches CRS patches and bundle patches must be installed in a CRS Home, but not in an Oracle Home.

¡ Database Vault (DV) special patches DV special patches require a special installation procedure. For more information, see SAP note 1020937.

¡ Non-OPatch patches Some patches delivered by Oracle - most notably OPatch itself - cannot be installed with OPatch, but manually by unpacking and copying them into the Oracle Home.

Solution

Table of Contents:

1.  Important Terms and Notations 2.  Installing MOPatch 3.  Downloading the Patches from SAP Service Marketplace 4.  Executing MOPatch in Documentation Mode to Generate Documentation 5.  Executing MOPatch to Install the Patches 6.  Reviewing MOPatch Execution Summary and Log Files 7.  Resolving Patch Conflicts and Errors 8.  Interrupting MOPatch Appendix A. Free Disk Space and Automatic Clean-Up Appendix B. MOPatch and Re-Linking Appendix C. MOPatch and RAC Appendix D. MOPatch Flags Appendix E. MOPatch Configuration Appendix F. MOPatch Version History 1. Important Terms and Notations

l Patch Base Directory MOPatch requires a so-called patch base directory as a working directory. MOPatch uses that directory, for example, to collect the patch README files in documentation mode, or to generate the link script when installing patches. It is recommended to use a fixed patch base directory per Oracle Home and it is required to use a separate patch base directory per Oracle Home.  Furthermore, the patch base directory must be readable, writable, and executable by the OS user ora<dbsid>. A valid location for a patch base directory would be, for example,    /oracle/<dbsid/patches.10204 for database version 10.2.0.4.0.

l Patch Source Path MOPatch looks up the Oracle database patches to process in the patch source path, which may contain both files and directories. You can specify the patch source path with command-line option "-s".  Specify multiple path elements either by specifying option "-s" multiple times or by using a colon-separated path, like in the following two equivalent examples:   ... -s <patch-file-1>:<patch-dir-2> ...    ... -s <patch-file-1> -s <patch-dir-2> ... If an element of the patch source path is a file, then it must be a zip file.  MOPatch processes any Oracle database patches that it finds in the zip file. If an element of the patch source path is a directory, then MOPatch scans the directory for any patch files (p<patch_id>_<version>_<platform>.zip) and SAP Bundle Patches (SAP_<version>_<bundle_id>_<platform>.zip) and processes all Oracle database patches that it finds in these. If you do not specify a patch source path on the command-line, MOPatch uses the location of the patch base directory as patch source path.

l Patch Basename MOPatch uses patch basenames to uniquely identify the patches that it processes in its output, its error messages, and its log file. The patch basename consists of the patch file name and, if the patch file contains more than one patch, of an additional molecule ID. For a simple patch, that contains only one Oracle database patch, the patch basename would look like this:    p5029334_10202_GENERIC.zip For an Oracle database patch from a SAP Bundle Patch, that contains multiple patches, the patch basename would look like this:   SAP_112010_201004_LINUX.zip!SAP_112010_201004!9359939 where the part "SAP_112010_201004!9359939" after the first exclamation mark specifies the molecule ID. This patch basename refers to the Oracle database patch that is located in

directory "SAP_112010_201004/9359939" of the SAP Bundle Patch "SAP_112010_201004_LINUX.zip". MOPatch uses the original, mixed-case patch file names in patch basenames. For example, MOPatch always uses the patch basename "p5029334_10202_GENERIC.zip", even if the patch file is actually called "P5029334_10202_GENERIC.ZIP" in the file system. In addition to that, MOPatch might apply other simplifications to the patch basename to keep it concise without loosing uniqueness.

2. Installing MOPatch

1. Log on to the database server as OS user ora<dbsid>.

2. Download the file mopatch-<version>.zip attached to this note and unpack it into the Oracle Home, for example, with the command:   $ unzip -d $ORACLE_HOME mopatch-<version>.zip This creates the directory $ORACLE_HOME/MOPatch with the following contents:    readme.txt - MOPatch documentation. Identical to this note except                 for minor changes.    mopatch.sh - MOPatch utility    mpkill.sh  - MOPatch kill utility

You must unpack mopatch-<version>.zip on the UNIX database server. Line-endings might be corrupted if you unpack mopatch-<version>.zip on a Windows platform and transfer the contained files to the Unix database server.

3. Downloading the Patches from SAP Service Marketplace

This section describes how to download the current Oracle database patches from SAP Service Marketplace and where to store them. For more information about the current Oracle database patches, see the relevant SAP notes. The 11.2.0.1.0 SAP Bundle Patches are available on SAP Service Marketplace at:     https://service.sap.com/oracle-download       -> Oracle 11.2.0.1.0           -> Database RDBMS              -> <platform> The 10.2.0.4.0 patches are available on SAP Service Marketplace at:     https://service.sap.com/oracle-download       -> Oracle 10.2.0.4.0           -> Database RDBMS             -> Generic (32-bit / 64-bit)   (for generic patches)             -> <platform>        (for platform-specific patches)

3.1 Downloading SAP Bundle Patches

Download the latest SAP Bundle Patch appropriate for your database version and your platform, either with the SAP Download Manager or directly by selecting the SAP Bundle Patch link.

3.2 Downloading Multiple Single Patches

You must download both the generic and platform-specific Oracle database patches appropriate for your database version and your platform.

1. Select all generic and platform-specific patches that you want to download. Select the check boxes next to all items with title matching either of the following patterns:    pNNNNNN_VVVVV_<PLATFORM_NAME>.zip   pNNNNNN_VVVVV_GENERIC.zip You can easily do this by first selecting all check boxes with the "Select All" button and then deselecting those that do not match. Make sure that you only select items that have a title matching the patterns mentioned above. Do not select any items where the version-part "VVVVV" of the title does not match your database version.

2. Select the "Add to Download Basket" button. In the upcoming pop-up window, select the "Close" button.

3. Start the SAP Download Manager. If you have not yet installed the SAP Download Manager, you can download it from    https://service.sap.com/swdc       -> Download Basket          -> Get Download Manager

4. Start the download from the menu bar of the SAP Download Manager:    Object -> Download all objects Wait for the download to complete.

If you download the patches on a Windows platform, the SAP Download Manager changes the names of the files that it downloads by converting all lower-case characters to upper case. For example, if you download patch 5117016, it does not generate a file named:

    p5117016_10202_SOLARIS64.zip Instead, it generates a file named:     P5117016_10202_SOLARIS64.ZIP MOPatch recognizes both alternatives when searching for patches to install. Therefore, you do not need to rename the files before MOPatch is executed.

3.3 Storing SAP Bundle Patches

If you store multiple SAP Bundle Patches in one directory, then you must not specify the path of that directory as a patch source path to MOPatch with option "-s". MOPatch would try to process all patches from all bundle patches in this case. Instead, specify the file name of the single SAP Bundle Patch that you want to process.

3.4 Storing Multiple Single Patches

You can store the Oracle database patches in any directory that is readable and executable by the OS user ora<dbsid>. For optimal interaction with MOPatch, organize the patches on the file server in a version- and platform-specific structure like this:     <patch_root>/10.2.0.2.0/Linux_32     <patch_root> /10.2.0.2.0/Solaris_x86_64     <patch_root>/10.2.0.2.0/Solaris_SPARC_64     ... Some additional notes:

l In the above example, the generic patches must be available in all subdirectories alongside with the platform-specific patches. For example, generic patch p5029334_10202_GENERIC.zip (or at least a symbolic link to it) must be available in each subdirectory Linux_32, Solaris_x86_64, and so on of directory <patch_root>/10.2.0.2.0.

l The patches contained in a subdirectory of the file server must correspond to a consistent snapshot of patches as provided on SAP Service Marketplace. For more information, see "Reason and Prerequisites" above.

l Do not unpack the patches. MOPatch operates on packed patches only and does not recognize unpacked patches.

l If a large number of Oracle installations needs to be patched, it might be useful to maintain and provide the Oracle database patches on a central, company-internal file server.

4. Executing MOPatch in Documentation Mode to Generate Documentation

In documentation mode, MOPatch only checks the patches found in the patch source path without calling OPatch to apply them. In addition, MOPatch collects the patch README files in the patch base directory:

l File READMES-<timestamp>.txt contains the unmodified README.txt files of all successfully checked patches.

l File READMES-STRIPPED-<timestamp>.txt contains the stripped README.txt files of all successfully checked patches. This file is generated by stripping the standard, repeating portion of the patch README files, leaving only the patch-specific information.

l Files README-<patch_id>-<timestamp>.html contain unmodified copies of README.html files of all successfully checked patches.

You do not need to shut down the database instance to execute MOPatch in documentation mode.

1. Log on to the database server as OS user ora<dbsid>.

2. Change to the patch base directory and run MOPatch in documentation mode:    $ cd <patch_base_dir>    $ /bin/sh $ORACLE_HOME/MOPatch/mopatch.sh \              -v -d -s patch-source-path

3. Review the execution summary printed by MOPatch. In the event of errors, see the MOPatch log files in directory $ORACLE_HOME/cfgtoollogs/mopatch for more details.

4. Review the README files generated in the patch base directory. Pay extra attention to README files of patches that are marked specially in the execution summary printed by MOPatch, since these may contain special installation instructions.

A successful documentation run only guarantees that MOPatch can process all patches. However, it does not guarantee that OPatch can process the patches in the following installation run. In particular, patch conflicts are not recognized by MOPatch in documentation mode. By default MOPatch does not collect the README files for patches that are already installed in the Oracle Home. However, in some scenarios it might be useful to get the collected README files of, for example, a complete SAP Bundle Patch from the SAP Service Marketplace, regardless of what patches are installed or not. For this purpose, you can specify the flag "ignore_installed"  in the command-line (see "Appendix D. MOPatch Flags") to let MOPatch ignore any patches installed in the Oracle Home and to let it collect the README files of all patches.

5. Executing MOPatch to Install the Patches

1. Log on to the database server as OS user ora<dbsid>.

2. Make sure that all prerequisites for successfully running OPatch are met, especially the following:

¡ Environment variable ORACLE_HOME must be set.

¡ There must be no processes running from the Oracle Home. Make specially sure that the database instance is shut down and that the Oracle Listener is stopped.

¡ (AIX platforms only) The command slibclean must have been executed by the super user.

3. Execute all patch-specific pre-install instructions. The stripped README files generated by MOPatch in documentation mode provide a concise overview of these.

4. Change to the patch base directory and run MOPatch:    $ cd <patch_base_dir>    $ /bin/sh $ORACLE_HOME/MOPatch/mopatch.sh \              -v -s patch-source-path

5. Execute all patch-specific post-install instructions. The stripped README files generated by MOPatch in documentation mode provide a concise overview of these.

MOPatch by default uses the inventory pointer $ORACLE_HOME/oraInst.loc to locate the central Oracle software inventory. If that file does not exist or if it does not point to a valid inventory, MOPatch instead uses the default central inventory pointer /etc/oraInst.loc or /var/opt/oracle/oraInst.loc. To use a different inventory pointer, specify it with command-line option "-p" when calling MOPatch (corresponding to command-line option "-invPtrLoc" of OPatch). MOPatch by default uses the Java Development Kit that is installed in the Oracle Home to call OPatch. To use a different Java Development Kit, specify it with command-line option "-j" when calling MOPatch (corresponding to command-line option "-jdk" of OPatch).

6. Reviewing MOPatch Execution Summary and Log Files

1. Review the execution summary that MOPatch prints after it has processed all patches.

2. In the event of patch conflicts or errors, see the MOPatch log files in directory $ORACLE_HOME/cfgtoollogs/mopatch for more details. Follow the instructions in section "Resolving Patch Conflicts and Errors" of this note to resolve the issues.

7. Resolving Patch Conflicts and Errors

If MOPatch reports any patch conflicts or errors in its execution summary, you have the following options to resolve them:

l Fix the cause of the issues and re-run MOPatch. If there is a conflict between a new patch PATCH_NEW with an already installed patch PATCH_INSTALLED, check in SAP note 871096 to find out whether PATCH_NEW should replace PATCH_INSTALLED or not. If it should, use OPatch to remove PATCH_INSTALLED from the Oracle Home as described in SAP note 839182. Otherwise, if PATCH_INSTALLED should be kept in favour of PATCH_NEW, prevent MOPatch from processing PATCH_NEW as described below. Then re-run MOPatch. If there are other errors, refer to the MOPatch log files and also to the OPatch log files for more details. If a patch is not installable by means of OPatch (and, therefore, not installable by means of MOPatch), process that patch manually. Then prevent MOPatch from processing the patch as described below. Finally, re-run MOPatch. To prevent MOPatch from processing a particular patch, simply move that patch out of the patch base directory or rename it, for example, from pNNNNNN_VVVVV_PPPPPP.zip to nomopatch.pNNNNNN_VVVVV_PPPPPP.zip.

l Fix the cause of the issues and use OPatch as described in SAP note 839182 to manually install any patches MOPatch has not yet installed. In this case, the link script generated by MOPatch in the patch base directory needs to be executed manually to ensure that all parts of the Oracle software are properly linked:    $ cd <patch_base_dir>   $ /bin/sh link.sh The link script should be removed after its successful execution:    $ rm link.sh

The re-link algorithm described in "Appendix B. MOPatch and Re-Linking" of this note is designed to produce a properly linked Oracle executable and shared libraries in all standard situations. If you are in doubt whether the Oracle executable was properly linked - for example, due to irreproducible errors during patch installation - you can at any time run the standard "relink" utility as OS user ora<dbsid> as follows:     $ $ORACLE_HOME/bin/relink all

8. Interrupting MOPatch

To safely interrupt MOPatch in an installation run, call     /bin/sh $ORACLE_HOME/MOPatch/mpkill.sh

as OS user ora<dbsid> from a separate shell session. After being interrupted that way, MOPatch completes the installation of the patch it is currently processing and skips the installation of all remaining patches. In a shell that supports job control, you can alternatively suspend the running MOPatch process, usually with "Ctrl-Z", call "mpkill.sh" from the shell session with the suspended MOPatch process, and continue the MOPatch process, for example with the command "fg". To interrupt MOPatch in a documentation run, you may simply use "Ctrl-C".

Appendix A. Free Disk Space and Automatic Clean-Up

The installation of patches might require a significant amount of disk space in the OPatch patch storage, which is located in the Oracle Home under directory .patch_storage. When installing a larger number of patches with MOPatch, free disk space in the Oracle Home might be completely used up by the patch storage. Older versions of OPatch do not check whether there is sufficient free disk space available to install a patch. This might result in OPatch leaving the Oracle Home in an inconsistent state when it fails during the patch installation in an uncontrolled way. As of version 1.8, MOPatch checks before each patch installation whether there is sufficient free disk space in the Oracle Home (or, more precisely, in the patch storage). MOPatch requires that free disk space of at least twice the size of $ORACLE_HOME/lib/libserver.a is available to install a patch. (This file was chosen as a measurement unit since most of the patch storage disk space is used by backups of it.) If free disk space falls below that limit, MOPatch fails to apply any further patches. Much information in the patch storage is redundant and can be safely removed after successfully applying the patches. As of version 10.2.0.2.4, OPatch provides a command "util cleanup" to remove the redundant information and to clean up the patch storage. Such clean-ups do not adversely affect the ability to later roll back the patches. As of version 1.8, MOPatch detects whether OPatch supports clean-ups and uses them to automatically clean up the patch storage. The MOPatch command-line option "-c <cleanup-freq>" controls when clean-ups happen. If the clean-up frequency is set to zero (the default), MOPatch cleans up the patch storage if the free disk space of the patch storage falls below a certain limit. If the clean-up frequency is set to a positive number, MOPatch cleans up the patch storage each time after successfully applying the specified number of patches. Regardless of the clean-up frequency specified by option "-c", MOPatch cleans up the patch storage after all patches were successfully applied. Determining the free disk space on a given volume is highly platform-dependent. For example, on some platforms it might take up to twenty seconds until the disk space freed up by a clean-up is reported by the file system to the operating system. While MOPatch has been extensively tested on all platforms relevant for SAP customers, it is not guaranteed that the automatic clean-up algorithm and free disk space checks work properly on all combinations of storage types and platforms. Furthermore, the algorithm used by MOPatch to determine the disk free space might be adversely affected by other processes concurrently acquiring or freeing disk space on the volume holding the patch storage. Therefore, it is recommended to stop all other disk activity on that volume while MOPatch is running, in particular if there is only a limited amount of free disk space available on it. In case of problems, the following MOPatch command-line options can be used to control the automatic clean-up algorithm and free disk space checks:

l -T <timeout> After cleaning up the patch storage, MOPatch first waits for the free disk space to change substantially, and then it waits for the free disk space to stabilize. The maximum wait time for each of these steps is by default twenty seconds. This option can be used to increase the maximum wait time for file systems that take a long time to report changes in the free disk space.

l -F !free_space_check Disables the check for sufficient free disk space before installing a patch. For more information on how to specify flags, see "Appendix D. MOPatch Flags".

l -F !clean_up,!clean_up_final Disables the intermediate and final patch storage clean-ups, respectively.

Appendix B. MOPatch and Re-Linking

Most Oracle patches require the Oracle executable (and other shared libraries) to be re-linked after the patch installation. However, to save execution time MOPatch calls OPatch with option "-no_relink" to suppress immediate re-linking after each patch. Instead, MOPatch collects the information required to re-link the Oracle executable in the so-called link script named "link.sh" located in the patch base directory. MOPatch automatically executes the link script after installing all patches, but only if all patches were installed without conflicts or errors. Consequently, the link script might need to be executed manually in case of conflicts or errors. MOPatch does not remove the link script until after it was successfully executed. This ensures that the information in the link script does not get lost if multiple executions of MOPatch are required to install all patches. Automatic execution and removal of the link script can be explicitly suppressed by specifying option "-n" to MOPatch. You can suppress deferred linking as described above by specifying option "-i" to MOPatch. In this case, the Oracle executable is immediately re-linked after each patch installation and MOPatch neither generates nor runs the link script.

The following pseudo algorithm summarizes how MOPatch works with regard to patch installation and relinking:   FOR EACH patch DO     IF option -i specified THEN       opatch apply patch     ELSE       opatch apply -no_relink patch       append link information to link script     END   END   IF NOT option -i specified AND     NOT option -n specified AND      NOT patch installation failed for some patch AND      NOT patch installation skipped due to conflict for some patch     THEN      execute link script     IF link script executed successfully THEN      delete link script      END   END

Appendix C. MOPatch and RAC

MOPatch can be used to patch RAC databases in exactly the same way as described above for single-instance databases. However, for MOPatch before version 1.8 it is recommended to call MOPatch with the additional command-line option "-l" as shown below:   /bin/sh $ORACLE_HOME/MOPatch/mopatch.sh -v -l This ensures that the patches get installed only once in the shared Oracle Home, and not on each RAC node. As of MOPatch version 1.8, this is the default behaviour.

Appendix D. MOPatch Flags

As of version 1.8, MOPatch provides a generic mechanism to set certain Boolean flags on the command-line that influence its runtime behavior. Most of the flags are for development and test purposes only and must not be used by customers. Here is a short overview of those flags that can be used by customers if required:

l apply_psu (default: on) install Patchset Updates

l apply_cpu (default: on) install Critical Patch Updates

l apply_napply (default: on) install n-apply patches

l free_space_check (default: on) checks for sufficient free disk space before installing a patch

l clean_up (default: on) cleans up the patch storage if required

l clean_up_final (default: on) cleans up the patch storage after complete installation

l ignore_installed (default: off) ignores installed patches in documentation mode

l ignore_warnings (default: on) ignores OPatch warnings known to be uncritical

l local_opatch (default: on) adds the "-local" option to all OPatch calls

To enable a flag, call MOPatch with an additional command-line option   -F <flag> To disable a flag, call MOPatch with an additional command-line option   -F !<flag> Multiple flags or negated flags can be concatenated with a comma as separator. In some shells, the negating exclamation mark must be quoted, for example, by means of a backslash, to prevent the shell from interpreting the flag as a history event. In such shells an error message similar to "!<flag>: event not found" is issued unless the exclamation mark is quoted. The following example shows how to call MOPatch with patch storage clean-up completely disabled:   $ /bin/sh $ORACLE_HOME/MOPatch/mopatch.sh -v -F \ \!clean_up,\!clean_up_final

Appendix E: MOPatch Configuration To be done.

Appendix F: MOPatch Version History

Version 1.9:

l MOPatch fully supports the latest OPatch versions 10.2.0.2.5, 10.2.0.4.2, and 10.2.0.4.3.

l MOPatch better detects and handles patch subset and patch superset installations.

l MOPatch ignores OPatch warnings known to be uncritical unless the flag "ignore_warnings" is disabled. For more information, see "Appendix D: MOPatch Flags".

l MOPatch detects Database Vault-specific patches and refuses to install them. For more information, see "Reason and Prerequisites".

Version 1.8:

l MOPatch does not install patches if there is insufficient disk space available. See "Appendix A. Free Disk Space and Automatic Clean-Up" above.

l MOPatch automatically cleans up the OPatch patch storage. See "Appendix A. Free Disk Space and Automatic Clean-Up" above.

l MOPatch detects CRS homes and CRS patches and refuses to operate on them. See "Reason and Prerequisites" above.

l MOPatch always calls OPatch with the command-line option "-local". It still recognizes the corresponding (MOPatch) command-line option "-l" but silently ignores it.

Version 1.7:

l MOPatch exits with an error message if it detects a non-Posix shell on Tru64.

l MOPatch does not require patch 5117016 to be installed on Solaris x86_64, only on Solaris SPARC.

Version 1.6:

l MOPatch refuses to install Critical Patch Updates. For more information, see "Reason and Prerequisites" above.

Version 1.5:

l MOPatch is also supported for updating patches. Previously, the use of MOPatch was only supported for patching a new database installation. However, there are some important restrictions when using MOPatch to update patches. For more information, see "Reason and Prerequisites" above.

l MOPatch can read patches from a (possible read-only) patch source directory. This way patches can be read from a central, company-internal file server. For more information, see section "Downloading the Patches to a Central File Server" above.

Version 1.4:

l Initial version

Other Attributes

Validity

This document is not restricted to a software component or software component version

References

This document refers to:

SAP Notes

ORACLE

Oracle 10

1503709   Oracle 11.2.0: Patches / Patch collections for 11.2.0.2

1431800   Oracle 11.2.0: Central Technical Note

1431795   Oracle 11.2.0: Patches/Patchcollections for 11.2.0.1

Database System

This document is referenced by:

SAP Notes (9)

Attachments

1431752   Oracle 10.2.0: Patches/Patch Collections for 10.2.0.5

1137346   Oracle 10.2.0: Patches/patch collections for Oracle 10.2.0.4

1026237   FAQ: OPatch and Universal Installer 10.2

871096   Oracle 10.2.0: Patches/patch collections for Oracle 10.2.0.2

839187   Oracle 10.2.0: Applying patch set/patches/patch collection

839182   Oracle patch installation with OPatch

1137346   Oracle 10.2.0: Patches/patch collections for Oracle 10.2.0.4

1431752   Oracle 10.2.0: Patches/Patch Collections for 10.2.0.5

1431795   Oracle 11.2.0: Patches/Patchcollections for 11.2.0.1

1431800   Oracle 11.2.0: Central Technical Note

839182   Oracle patch installation with OPatch

839187   Oracle 10.2.0: Applying patch set/patches/patch collection

1026237   FAQ: OPatch and Universal Installer 10.2

871096   Oracle 10.2.0: Patches/patch collections for Oracle 10.2.0.2

1503709   Oracle 11.2.0: Patches / Patch collections for 11.2.0.2

File Name File Size (KB) Mime Type

mopatch-2_1_12.zip 49 application/x-zip-compressed