JAN, APR, JUL, OCT

Yes, OPatch can be used for applying single patches. However, it cannot be used for applying patchsets.

As you know, to apply a patch, both your database and listener must be down. When you use OPatch, it updates your current ORACLE_HOME. To address your question directly: it is not possible to achieve zero downtime with a single instance. However, in a RAC environment, you can apply OPatch without downtime. This is because RAC has multiple separate ORACLE_HOMEs and multiple instances, with each instance running on its respective ORACLE_HOME.

Relink all.

Using NApply, you can apply a single patch from a collection of extracted patches by specifying the patch location and the specific patch ID. For further details, refer to the OPatch utility's NApply help. This will provide you with a clear understanding.
For Example:
This will apply only the patch id 9 from the patch location and will skip duplicate and subset of patch installed in your ORACLE_HOME.

opatch util napply <patch_location> -id 9 -skip_subset -skip_duplicate

From the above discussion, it is clear that once you apply a PSU, the recommended approach is to continue applying subsequent PSUs. There is no need to apply a CPU on top of a PSU, as PSUs already include the CPU updates. In fact, applying a CPU over a PSU would be considered a rollback of the PSU and would require additional effort. Therefore, if you haven't decided on or applied any patches yet, I suggest opting for PSU patches.

CPUs are smaller and more focused than PSUs, primarily addressing security issues. This theoretically more conservative approach can cause fewer problems than PSUs, as it involves less code modification. Therefore, for those concerned only with security fixes and not functionality updates, applying CPUs might be a preferable approach.

If you are using latest support.oracle.com then after login to metalink Dashboard

- Click on "Patches & Updates" tab

- On the left sidebar click on "Latest Patchsets" under "Oracle Server/Tools".

- A new window will appear.

- Just mouseover on your product in the "Latest Oracle Server/Tools Patchsets" page.

- Corresponding oracle platform version will appear. Then simply choose the patchset version and click on that.

- You will go the download page. From the download page you can also change your platform and patchset version.

It is the utility to apply the patch.

1. You MUST read the Readme.txt file included in opatch file, look for any prereq. steps/ post installation steps or and DB related changes. Also, make sure that you have the correct opatch version required by this patch.

2.Make sure you have a good backup of database.

3. Make a note of all Invalid objects in the database prior to the patch.

4. Shutdown All the Oracle Processes running from that Oracle Home , including the Listener and Database instance, Management agent etc.

5. You MUST Backup your oracle Home and Inventory

tar -cvf $ORACLE_HOME $ORACLE_HOME/oraInventory | gzip > Backup_Software_Version.tar.gz

6. Unzip the patch in $ORACLE_HOME/patches

7. cd to the patch direcory and do opatch -apply to apply the patch.

8. Read the output/log file to make sure there were no errors.

opatch napply <patch_location> -skip_subset -skip_duplicate

OPatch skips duplicate patches and subset patches (patches under <patch_location> that are subsets of patches installed in the Oracle home).

OPATCH Utility (Oracle RDBMS Patching)

1. Download the required Patch from Metalink based on OS Bit Version and DB Version.

2. Need to down the database before applying patch.

3. Unzip and Apply the Patch using ”opatch apply” command.On successfully applied of patch you will see successful message “OPatch succeeded.“, Crosscheck your patch is applied by using “opatch lsinventory” command .

4. Each patch has a unique ID, the command to rollback a patch is “opatch rollback -id  <patch no.>” command.On successfully applied of patch you will see successful message “OPatch succeeded.“, Crosscheck your patch is applied by using “opatch lsinventory” command .

5. Patch file format will be like, “p<patch no.>_<db version>_<os>.zip”

6. We can check the opatch version using “opatch -version” command.

7. Generally, takes 2 minutes to apply a patch.

8. To get latest Opatch version download “patch 6880880 - latest opatch tool”, it contains OPatch directory.

9. Contents of downloaded patches will be like “etc,files directories and a README file”

10. Log file for Opatch utility can be found at $ORACLE_HOME/cfgtoollogs/opatch

11. OPatch also maintains an index of the commands executed with OPatch and the log files associated with it in the history.txt file located in the <ORACLE_HOME>/cfgtoollogs/opatch directory.

12. Starting with the 11.2.0.2 patch set, Oracle Database patch sets are full installations of the Oracle Database software. This means that you do not need to install Oracle Database 11g Release 2 (11.2.0.1) before installing Oracle Database 11g Release 2 (11.2.0.2).

13. Direct upgrade to Oracle 10g is only supported if your database is running one of the following releases: 8.0.6, 8.1.7, 9.0.1, or 9.2.0. If not, you will have to upgrade the database to one of these releases or use a different upgrade option (like export/ import).

14.Direct upgrades to 11g are possible from existing databases with versions 9.2.0.4+, 10.1.0.2+ or 10.2.0.1+. Upgrades from other versions are supported only via intermediate upgrades to a supported upgrade version.

Oracle version number refers:
10 – Major database release number
 2 – Database Maintenance release number
 0 – Application server release number
 4 – Component Specific release number
 0 – Platform specific release number

It is a new ASM feature introduced in Database 11g. Starting from Oracle Database 11g release 11.1, ASM instances can be upgraded or patched using the rolling upgrade feature. This allows us to patch or upgrade ASM nodes in a clustered environment without impacting database availability. During a rolling upgrade, the cluster remains functional even if one or more nodes are running different software versions. Rolling upgrades are applicable only to Oracle Database 11g releases from 11.1 onward.

Manual upgrade which involves the following steps:

1.Backup the database.

2.In UNIX/Linux environments, set the $ORACLE_HOME and $PATH variables to point to the new 11g Oracle home.

3.Analyze the existing instance using the "$ORACLE_HOME/rdbms/admin/utlu111i.sql" script.

4.Start the original database using the STARTUP UPGRADE command and proceed with the upgrade by running the "$ORACLE_HOME/rdbms/admin/catupgrd.sql" script.

5.Recompile invalid objects.

6.Restart the database.

7.Run the "$ORACLE_HOME/rdbms/admin/utlu111s.sql" script and check the result of the upgrade.

8.Troubleshoot any issues or abort the upgrade.

$sqlplus "/as sysdba"
SQL> STARTUP UPGRADE

Note:
----
The UPGRADE keyword enables you to open a database based on an earlier Oracle Database release. It also restricts logons to AS SYSDBAsessions, disables system triggers, and performs additional operations that prepare the environment for the upgrade.

You might be required to use the PFILE option to specify the location of your initialization parameter file.
Once the database is started in upgrade mode, only queries on fixed views execute without errors until after the catupgrd.sql script is run. Before running catupgrd.sql, queries on any other view or the use of PL/SQL returns an error.

startup migrate:
---------------
Used to upgrade a database till 9i.

Startup Upgrade
---------------
From 10G  we are using startup upgrade to upgrade database.

Upgrade
Upgrade refers to the process of advancing a database from a lower release to a major release. Examples include moving from 10.2.0.1 to 11.2.0.1, 10.2.0.4 to 11.2.0.3, or 9.2.0.8 to 10.2.0.5.
Typically, upgrades occur on the existing server infrastructure without physically relocating it.

Reasons for Upgrading:
1 .Continued Oracle Support: Maintaining support eligibility with Oracle, as older versions may lose support.
2 .Bug Fixes: Addressing critical bugs that are resolved only in newer releases.
3 .Licensing: Possessing licenses for newer releases that necessitate upgrading.
4 .Performance Enhancements: Leveraging improvements that newer database versions offer for applications.
Migration
Migration involves transferring a database from one OS platform to another. This could entail moving from a Solaris server to a Linux server, or from Windows to Solaris.
In most migration projects, there is a physical relocation of the server infrastructure. For example, upgrading from an outdated Solaris 5.10 server to a newer RHEL 6 server constitutes both migration and upgrade tasks.
Reasons for Migration:
1 .Hardware Limitations: Overcoming constraints on existing servers, such as memory, disk space, or CPU limitations.
2 .OS Licensing Changes: Transitioning to a more cost-effective OS, such as Linux, when existing OS licenses expire.
3 .Data Center Optimization: Relocating to another data center to reduce maintenance costs or improve operational efficiency.