For those who unfamiliar with Oracle Patch is little confusing what patch to apply when get a table with different patch in the same version.
I will try clarify some doubts.
Note: You must provide a valid My Oracle Support login name in order to access below Links.
Patch version numbering changed
In November 2015 the version numbering for new Bundle Patches, Patch Set Updates and Security Patch Updates for Oracle Database changed the format from 5th digit of the bundle version with a release date in the form “YYMMDD” where:
- YY is the last 2 digits of the year
- MM is the numeric month (2 digits)
- DD is the numeric day of the month (2 digits)
More detail can be found here: Oracle Database, Enterprise Manager and Middleware – Change to Patch Numbering from Nov 2015 onwards (Doc ID 2061926.1)
Changes on Database Security Patching from 22.214.171.124 onwards
Starting with Oracle Database version 126.96.36.199 , Oracle will only provide Patch Set Update (PSU) patches to meet the Critical Patch Update (CPU) program requirements for security patching. SPU (Security Patch Update) patches will no longer be available. Oracle has moved to this simplified model due to the popularity of the PSU patches. PSUs are Oracle’s preferred proactive patching vehicle since their inception in 2009.
Where to find last Patches for Database?
What Patch to apply PSU, GI PSU,Proactive Bundle Patch, Bundle Patch (Windows 32bit & 64bit)?
When using the Patchset Assistant the assistant show below table:
In this case I search for last patch for 188.8.131.52.
Understanding the Patch Nomenclature :
New Patch Nomenclature for Oracle Products (Doc ID 1430923.1)
Note: As of April 2016, the Database Patch for Engineered Systems and Database In-Memory has been renamed from “Bundle Patch (BP) ” to “Database Proactive Bundle Patch”.
Note: Windows Platform must use “Bundle Patch (Windows 32bit & 6bit)”.
Database patch content:
- SPU contains only the CPU program security fixes
- PSU contains the CPU program security fixes and additional high-impact/low-risk critical bug fixes
- Proactive Bundle Patch (PBP) includes all PSU fixes along with fixes targeted at the specific Bundle Patch environment.
They are cumulatives,so if you have a OH (184.108.40.206) in base release (i.e no fix) and apply the last PSU or PBP it will fix all bugs from base release until current version of patch.
Where to apply each Patch?
- PSU – Can be applied on Database Servers, Client-Only and Instant Client.
- GI PSU – Can be applied on GI Home (Oracle Restart or Oracle Clusterware) in conjunction with RAC, RACOne, Single Instance home, Client-Only and Instant Client.
- Proactive Bundle Patch – Can be applied on GI Home in conjunction with RAC, RACOne, or Single Instance home, Client-Only and Instant Client.
An installation can only use one of the SPU, PSU or Proactive Bundle Patch patching methods.
How to choose between them?
The “Database Proactive Bundle Patch” requires a bit more testing than a Patch Set Update (PSU) as it delivers a larger set of fixes.
If you are installing a new fresh installation you should to apply Database Proactive Bundle Patch.
PSU is addressed to environments sensitive to changes, because it required less testing.
I have Applied “Database PSU” how to move to “Database Proactive Bundle Patch”?
Moving from “Database PSU” to “Database Proactive Bundle Patch”
- Back up your current setup
- Fully rollback / deinstall “Database PSU”
- If using OJVM PSU that is likely to require OJVM PSU to be rolled out too
- Apply / install the latest “Database Proactive Bundle Patch”
- Apply any interim patches also rolled out above (including OJVM PSU if that was installed)
Note from Oracle: It is not generally advisable to switch from “Database PSU” to “Database SPU” method.
The below note can clarify any doubt on this post.
Oracle Database – Overview of Database Patch Delivery Methods (Doc ID 1962125.1)
GI PSU and Proactive Bundle Patch are supported by OPlan.
OPlan is a utility that facilitates the patch installation process by providing you with step-by-step patching instructions specific to your environment.
In contrast to the traditional patching operation, applying a patch based on the README requires you to understand the target configuration and manually identify the patching commands relevant to your environment. OPlan eliminates the requirement of identifying the patching commands by automatically collecting the configuration information for the target, then generating instructions specific to the target configuration.
RACcheck is a tool developed by the RAC Assurance development team for use by customers to automate the assessment of RAC systems for known configuration problems and best practices.
RACcheck is a RAC Configuration Audit tool designed to audit various important configuration settings within a Real Application Clusters (RAC), Oracle Clusterware (CRS), Automatic Storage Management (ASM) and Grid Infrastructure environment. The tool audits configuration settings within the following categories:
- OS kernel parameters
- OS packages
- Many other OS configuration settings important to RAC.
- CRS/Grid Infrastructure
- Database parameters
- Many other database configuration settings important to RAC.
1. RACcheck is NON-INTRUSIVE and does not change anything in the environment, except as detailed below:
– SSH user equivalence for the RDBMS software owner is assumed to be configured among all the database servers being audited in order for it to execute commands on the remote database server nodes. If the tool determines that this user equivalence is not established it will offer to set it up either temporarily or permanently at the option of the user. If the user chooses to set up SSH user equivalence temporarily then the script will do so for the duration of the execution of the tool but then it will return the system to the state in which it found SSH user equivalence originally. For those wishing to configure SSH user equivalence outside the tool (if not already configured), consult My Oracle Support Note: 372795.1.
– RACcheck creates a number of small output files into which the data necessary to perform the assessment is collected
– RACcheck creates and executes some scripts dynamically in order to accomplish some of the data collection
– RACcheck cleans up after itself any temporary files that are created and not needed as part of the collection.
2. RACcheck interrogates the system to determine the status of the Oracle stack components (ie., Grid Infrastructure, RDBMS, RAC, etc) and whether they are installed and/or running. Depending upon the status of each component, the tool runs the appropriate collections and audit checks. If due to local environmental configuration the tool is unable to properly determine the needed environmental information please refer to the TROUBLESHOOTING section.
3. Watchdog daemon – RACcheck automatically runs a daemon in the background to monitor command execution progress. If, for any reason, one of the commands run by the tool should hang or take longer than anticipated, the monitor daemon kills the hung command after a configurable timeout so that main tool execution can progress. If that happens then the collection or command that was hung is skipped and a notation is made in the log. If the default timeout is too short please see the TROUBLESHOOTING section regarding adjustment of the RAT_TIMEOUT, and RAT_ROOT_TIMEOUT parameters.
4. If RACcheck’s driver files are older than 90 days, the driver files are considered to be “stale” and the script will notify the user of a stale driver file. A new version of the tool and its driver files (kit) must be obtained from MOS Note 1268927.1.
5. When the RACcheck completes the collection and analysis it produces two reports, summary and detailed. A output .zip file is also produced by RACcheck. This output .zip file can be provided to Oracle Support for further analysis if an SR needs to be logged. The detailed report will contain Benefit/Impact, Risk and Action/Repair information. In many cases it will also reference publicly available documents with additional information about the problem and how to resolve it.
6. The results of the audit checks can be optionally uploaded into database tables for reporting purposes. See below for more details on this subject.
7. In some cases customers may want to stage RACcheck on a shared filesystem so that it can be accessed from various systems but be maintained in a single location rather than being copied to each cluster on which it may be used. The default behavior of the tool is to create a subdirectory and its output files in the location where the tool is staged. If that staging area is a read only filesystem or if the user for any reason would like the output to be created elsewhere then there is an environment variable which can be used for that purpose. The RAT_OUTPUT parameter can be set to any valid writable location and the output will be created there.
Oracle Server – Enterprise Edition – Version: 10.2.0.1 to 220.127.116.11 – Release: 10.2 to 11.2
- Linux x86
- IBM AIX on POWER Systems (64-bit)
- Oracle Solaris on SPARC (64-bit)
- Linux x86-64
To download RAC Check tool use this note on MoS:
RACcheck – RAC Configuration Audit Tool [ID 1268927.1]
Example of report output:
Oracle by Example
This tutorial shows you how to install the Grid Infrastructure for a standalone server, configure Oracle Restart, move the SPFILE for an ASM instance into an ASM diskgroup.
Time to Complete
Approximately 1 hour
This tutorial covers the following topics:
|Preparing to Install Grid Infrastructure|
|Installing Grid Infrastructure for a Standalone Server|
|Enabling Grid Infrastructure Features|