Interim patches are also known as one-off patches. For every bug that Oracle delivers, depending on the version and release, bug fixes can be delivered as patches or they will be fixed in the next releases or versions. An interim patch is a fix only for a particular bug. Bugs differ from environment to environment depending upon the OS and Oracle version. Interim patches come in a zipped format, and you have to unzip them before applying the patch. Every interim patch contains the following:

You should not get confused between Critical Patch Update (CPU)and Security Patch Update (SPU) as CPU terminology has been changed to SPU from October 2012. Before that, the terminology was CPU. CPU patches were introduced in January 2005 and they are released every quarter, which is four times a year.

Patch Set Updates (PSU) are cumulative patches for a particular product version. They are cumulative of CPU and include security fixes, wrong results, data corruption, and additional bugs. They have a low risk and do not require changes that require recertification such as dictionary changes, major algorithm changes, and any optimizer plan changes. On an average, each PSU contains typically 25 to 100 bug fixes per PSU. For PSU-related information, you can find more details from the MOS Note:854428.1: Introduction to Database Patch Set Updates. When you apply PSU and CPU, you may come across conflicts. PSUs contain CPUs of every quarter. You can apply PSU patches on any CPU and it is very difficult to go back to CPUs from PSUs.

A patch set provides bug fixes and it includes all the libraries that have been rebuilt to implement the bug fixes in the set. They are fully tested and integrated product fixes and are certified to work with each other. These can be applied on a database, RAC, and client software. If you are going to perform a fresh installation of a database with the latest release and patch set 11.2.0.3, then there is no need of installing 11.2.0.1 and then upgrading it to 11.2.0.3; instead of that, you can directly install the software of 11.2.0.3. This option has been introduced from 11gR onwards. If you have already installed 11.2.0.2 and then upgraded it to 11.2.0.3, this patch set removes the patches applied (bugs and CPU/PSUs) in the previous RDBMS version.

If you have already been maintaining a production database for many years, have probably applied patches to fix bugs, and also applied CPU/PSU patches for the previously discussed reasons, and if your requirement is to create a Data Guard environment for high availability of your production database, then ensure that all the patches that you have applied on the standby database are the same as the primary database. You can also consider the option of cloning ORACLE_HOME for this. It also happens to be the best option. The reason is that the standby database is an exact copy of the primary database in terms of databases and software. Hence, the environment should be compatible and same in terms of patching. If there is any incompatibility with the patch, and the requirement is to perform a switchover/failover and in the past you have applied any patch to fix ORA-00600 on the primary and not applied the same on the standby, then the bug can hit you again. Thus, ensure that all the patches of the primary have been applied on the standby also. Consider it as a basic rule to apply patching first on a standby database and then on a primary database; the standby database can be either physical or logical.

We have seen what patching is, different types of patches (interim/bug, CPU/SPU, PSU, and patch set), and how patching is important in a Data Guard environment.