This is an interesting observation I wanted to share. I have a feeling as if there didn’t seem to be too much information out there for RAC One Node (RON) users, and I hope this helps someone thinking about patching his system.
RAC-rolling patching is well documented in patch readme files, blog posts and official white papers. Most RAC DBAs have a solid handle on the procedure. Patching RAC One Node is a different affair.
What happens when patching a RAC One Node system? As the name suggests a RAC One Node database is a cluster database restricted to one active instance in normal operations. It is possible to relocate the database from one node to another online. Oracle does this by temporarily adding a second instance to the cluster database with the intention of letting it take over from the source instance. At the end of the online relocation, the source instance is shut down, and only the destination instance remains up and running.
An online relocation quite often is a manual operation. However I noticed that such an online relocation can happen during patching with opatchauto as well, at least in 12.2.
This post is intended to show you the process as it is, in the next part I’d like to show some implications of that approach.
The environment
In this example my lab environment consists of a 2 node RAC system currently patched to 12.2.0.1.180417. I wanted to apply the July 2018 RU to the system next to get some experience with the patch.
I have one RDBMS home in addition to the mandatory Grid home, same release level for both, no one-off patches (it’s a lab after all). The virtual machines run Oracle Linux 7.4 with kernel UEK4. To keep things simple there’s a single RAC One database, named RON. I assigned it DCB (“data centre B”) as unique name because I don’t like setting db_unique_name to reflect roles such as “PROD” and “STDBY”. It gets confusing when “STDBY” runs in primary role :)
Here’s the current status of my components:
[oracle@rac122sec2 ~]$ srvctl status database -db DCB Instance DCB_1 is running on node rac122sec1 Online relocation: INACTIVE [oracle@rac122sec2 ~]$ srvctl status service -db DCB Service RON_SVC is running on instance(s) DCB_1 [oracle@rac122sec2 ~]$
For the curious, here’s the configuration metadata:
[oracle@rac122sec2 ~]$ srvctl config service -db DCB Service name: RON_SVC Server pool: Cardinality: 1 Service role: PRIMARY Management policy: AUTOMATIC DTP transaction: false AQ HA notifications: false Global: false Commit Outcome: false Failover type: Failover method: TAF failover retries: TAF failover delay: Failover restore: NONE Connection Load Balancing Goal: LONG Runtime Load Balancing Goal: SERVICE_TIME TAF policy specification: NONE Edition: Pluggable database name: Maximum lag time: ANY SQL Translation Profile: Retention: 86400 seconds Replay Initiation Time: 300 seconds Drain timeout: Stop option: Session State Consistency: DYNAMIC GSM Flags: 0 Service is enabled Preferred instances: DCB_1 Available instances: CSS critical: no [oracle@rac122sec2 ~]$ srvctl config database -db DCB Database unique name: DCB Database name: RON Oracle home: /u01/app/oracle/product/12.2.0.1/dbhome_1 Oracle user: oracle Spfile: +DATA/DCB/spfileRON.ora Password file: +DATA/DCB/orapwRON Domain: Start options: open Stop options: immediateb Database role: PRIMARY Management policy: AUTOMATIC Server pools: Disk Groups: DATA,RECO Mount point paths: Services: RON_SVC Type: RACOneNode Online relocation timeout: 30 Instance name prefix: DCB Candidate servers: rac122sec1,rac122sec2 OSDBA group: dba OSOPER group: oper Database instances: DCB_1 CSS critical: no CPU count: 0 Memory target: 0 Maximum memory: 0 Default network number for database services: Database is administrator managed
The most important takeaway is that my RON instance DCB_1 is running on node rac122sec1.
Now let’s patch
After having followed the instructions in the patch readme closely, and after double/triple/quadrupel checking that I have (working, tried and tested!) backups of the entire stack I am ready to patch. This time around I’m following the instructions for the automatic application of the Grid Infrastructure RU, eg using opatchauto. Here is some relevant output from the patching session:
... OPatchauto session is initiated at Thu Jul 26 14:12:12 2018 System initialization log file is /u01/app/12.2.0.1/grid/cfgtoollogs/opatchautodb/systemconfig2018-07-26_02-12-14PM.log. Session log file is /u01/app/12.2.0.1/grid/cfgtoollogs/opatchauto/opatchauto2018-07-26_02-13-15PM.log The id for this session is Q4JA Executing OPatch prereq operations to verify patch applicability on home /u01/app/12.2.0.1/grid Executing OPatch prereq operations to verify patch applicability on home /u01/app/oracle/product/12.2.0.1/dbhome_1 Patch applicability verified successfully on home /u01/app/oracle/product/12.2.0.1/dbhome_1 Patch applicability verified successfully on home /u01/app/12.2.0.1/grid Verifying SQL patch applicability on home /u01/app/oracle/product/12.2.0.1/dbhome_1 SQL patch applicability verified successfully on home /u01/app/oracle/product/12.2.0.1/dbhome_1 Preparing to bring down database service on home /u01/app/oracle/product/12.2.0.1/dbhome_1 WARNING: The service RON_SVC configured on dcb will not be switched as it is not configured to run on any other node(s). No step execution required......... Relocating RACOne home before patching on home /u01/app/oracle/product/12.2.0.1/dbhome_1 /u01/app/oracle/product/12.2.0.1/dbhome_1 is not a RACOne database. No step execution required........ Bringing down CRS service on home /u01/app/12.2.0.1/grid ...
Wait a minute, what’s that? Have a look at the line beginning with “Relocating RACOne home before patching…”. Relocating the database wasn’t necessary in this case (remember that the database was active on rac122sec1-the other node), but opatchauto can definitely relocate your RAC One database.
When it does, you will see something like this in the output generated by opatchauto:
... Preparing to bring down database service on home /u01/app/oracle/product/12.2.0.1/dbhome_1 WARNING: The service RON_SVC configured on dcb will not be switched as it is not configured to run on any other node(s). Successfully prepared home /u01/app/oracle/product/12.2.0.1/dbhome_1 to bring down database service Relocating RACOne home before patching on home /u01/app/oracle/product/12.2.0.1/dbhome_1 Relocated RACOne home before patching on home /u01/app/oracle/product/12.2.0.1/dbhome_1 ...
The last 2 lines are those of interest. opatchauto detected that a RAC One database was running on the active node, and relocated it. Under the covers it uses a “srvctl relocate database …” command, as shown in the session log file.
Interestingly however, and contrary to what I expected, opatchauto moves the RAC One database back to where it came from as a post-patch step. Towards then end of the patching session I saw this:
... Starting CRS service on home /u01/app/12.2.0.1/grid Postpatch operation log file location: /u01/app/oracle/crsdata/rac122sec2/crsconfig/crspatch_rac122sec2_2018-07-26_03-01-06PM.log CRS service started successfully on home /u01/app/12.2.0.1/grid Relocating back RACOne to home /u01/app/oracle/product/12.2.0.1/dbhome_1 Relocated back RACOne home successfully to home /u01/app/oracle/product/12.2.0.1/dbhome_1 Preparing home /u01/app/oracle/product/12.2.0.1/dbhome_1 after database service restarted No step execution required......... ...
The relevant bit is in the middle (“relocating …”). After relocating the database to rac122sec1 opatchauto moved it back to rac122sec2.
Summary
Unlike rolling patching on multi-node RAC where all instances on the patched RDBMS home are shut down and applications rely on connection pools and Fast Application Notification to maintain service ability, a RAC One Node database might be relocated to a different node in the cluster. There are implications to that process for application developers, some of which I hope to share in the next post.
