Upgrade
Before startiing upgrade we must have checked the prerequisit like free space on server, download clusterware and database software , review the document to understance the prerequesit. If required we need tro upgrade OPatch utility , if required Download and unzip latest PSU Patch.
install clusetrware software by ./gridSetup.sh -applyPSU after installation When prompted, run the rootupgrade.sh script on each node in the cluster that you want to upgrade. After upgrade Check the Clusterware upgrade version.
Then Install RAC database software and Check the preupgrade status by using ./runcluvfy.sh
go to the 19c database dump directory and run ./runInstaller
Upgrade RAC database Manually pr DBUA.
There are many ways to convert a single database to RAC. We can use RMAN, DBCA and RCONFIG Method.RMAN Steps
* Create a pfile of the single instance database. Create the adump directories in all nodes of the cluster (in this case it is a two node cluster). * Copy the pfile created earlier to one of the RAC nodes and restore the database. Restore Controlfile using RMAN and then mount the database and then restore and recover database.
* Shutdown and restart the database to see if it opens without any issues.
* The single instance will have only one redo thread. Add another redo thread (or more if RAC has more nodes) and enable it.
* The single instance would have had one undo tablespace. Create undo tablespace for each additional instance
* Create oracle password files for each node
* Run the catclust.sql script to create a cluster related view then Add the database to the cluster using srvctl command.
Patches in RAC Enviroment
There are three total methods by which we can apply patches to the RAC Cluster Environment.
1. Patching RAC as a single instance (All-Node Patch) -- in this scenario, All Instance must be down
2. Patching RAC using a minimum down-time strategy (Min. Downtime Patch) - in this scenario , We bounce instance one by one
3. Patching RAC using a rolling strategy - (Rolling Patch) – In this scenario , No down time required
Patching RAC as a single instance (All-Node Patch)
* In this mode, all instances must be down during the whole patching process. OPatch applies the patch to the local node first, then propagates the patch to all the other nodes, and finally updates the inventory.
Patching RAC using a minimum down-time strategy (Min. Downtime Patch)
* In this mode, OPatch patches the local node, and asks users for a subset of nodes, which will be the first subset of nodes to be patched.
* After the initial subset of nodes are patched, Opatch propagates the patch to the other nodes and finally updates the inventory.
* The downtime would happen between the shutdown of the second subset of nodes and the startup of the initial subset of nodes patched.
Patching RAC using a rolling strategy - No down time (Rolling Patch)
* With this method, there is no downtime. Each node would be patched and brought up while all the other nodes are up and running, resulting in no disruption of the system.
* Rolling patching strategy incurs no downtime, however, some rolling patches may incur downtime due to post-installation steps, i.e. running sql scripts to patch the actual database. We must refer to patch readme to find out whether post-installation steps require downtime or not.
* In Rolling Patching, each node is shut down, the patch is applied, then each node is brought back up again.
* This is done node by node separately until all nodes in Oracle RAC are patched.
* This is the most efficient mode of applying an interim patch to an Oracle RAC setup because this results in no downtime. Only some patches can be applied in this mode. The type is generally specified in the patch metadata.
* The main advantage of this type of patching is that there is absolutely no downtime while applying patches because only one system is brought down at any given time.
* opatch query -is_rolling_patch
* Message:
* Patch is a rolling patch:true
* Note: We can patch one Node and bring it up and down to the second node2 for patching.
