I have just realised that the number of posts about RAC 12c Release 1 on this blog is rather too small. And since I’m a great fan of RAC this has to change :) In this mini-series I am going to share my notes about creating a Data Guard setup on my 2 node 126.96.36.199.161018 RAC primary + identical 2 node RAC standby system in the lab.
NOTE: As always, this is just a demonstration using VMs in my lab, based on my notes. Your system is most likely different, so in real-life you might take a different approach. The techniques I am using here were suitable for me, and my own small scale testing. I tried to make sure they are valid, but you may want to allocate more resources in your environment. Test, test, test on your own environment on test kit first!
The lab Environment
My environment consists of the following entities:
I won’t focus on the creation of the RAC systems, I may have covered some of it in earlier blog posts and of course in the RAC Book.
I have deliberately kept it simple. Although most systems in real life use a dedicated (set of) NICs for Data Guard traffic I decided against it-I didn’t want attention being drawn away from the Big Picture. Similarly I am not touching on the option to create a second SCAN that Oracle allows us to create from 12.1 onwards. If you are interested in these topics kindly refer to my other blog posts.
Creation of the Primary Database
After both RAC systems are set up it’s time to start with the creation of the primary database. This is easy:
dbca -silent -createDatabase -templateName RACDB.dbc \ -gdbName NCDBA -sysPassword ... -systemPassword ... -storageType ASM \ -diskGroupName DATA -recoveryGroupName RECO -sampleSchema true \ -totalMemory 4096 -dbsnmpPassword ... -nodeinfo rac12pri1,rac12pri2
The template referenced in “-templateName” is my own – I always create templates to be license compliant. I covered how to create your custom database template on this blog as well.
I won’t go into detail here about the naming of my databases in a Data Guard configuration. What I learned the hard way was not to use a DB_UNIQUE_NAME that reflects the role. Imagine everyone’s surprise when they connect to a database named STDBY operating in the primary role after a switchover… For lack of better ideas I went ahead and enumerated the databases: my primary database is NCDBA and the standby is NCDBB.
After the database is created, it is started automatically by DBCA.
[oracle@rac12pri1 ~]$ srvctl status database -db NCDBA Instance NCDBA1 is running on node rac12pri1 Instance NCDBA2 is running on node rac12pri2 [oracle@rac12pri1 ~]$
However, the newly created database isn’t patched (this is a known issue documented on Mike Dietrich’s blog for example).
SQL> select name from v$database; NAME --------- NCDBA SQL> select count(*) from dba_registry_sqlpatch; COUNT(*) ---------- 0
No way around it – time to call datapatch:
SQL> alter system set cluster_database=false scope=spfile sid='*'; System altered. SQL> exit ... [oracle@rac12pri1 ~]$ srvctl stop database -db NCDBA [oracle@rac12pri1 ~]$ sqlplus / as sysdba SQL*Plus: Release 188.8.131.52.0 Production on Wed Dec 14 13:39:04 2016 Copyright (c) 1982, 2014, Oracle. All rights reserved. Connected to an idle instance. SQL> startup upgrade ORACLE instance started. Total System Global Area 3221225472 bytes Fixed Size 2929552 bytes Variable Size 771755120 bytes Database Buffers 2432696320 bytes Redo Buffers 13844480 bytes Database mounted. Database opened. SQL> exit ... [oracle@rac12pri1 ~]$ cd $ORACLE_HOME/OPatch/ [oracle@rac12pri1 OPatch]$ ./datapatch -verbose SQL Patching tool version 184.108.40.206.0 on Wed Dec 14 13:08:51 2016 Copyright (c) 2016, Oracle. All rights reserved. Log file for this invocation: /u01/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_16313_2016_12_14_13_08_51/sqlpatch_invocation.log Connecting to database...OK Bootstrapping registry and package to current versions...done Determining current state...done Current state of SQL patches: Patch 24315824 (Database PSU 220.127.116.11.161018, Oracle JavaVM Component (OCT2016)): Installed in the binary registry only Bundle series DBBP: ID 161018 in the binary registry and not installed in the SQL registry Adding patches to installation queue and performing prereq checks... Installation queue: Nothing to roll back The following patches will be applied: 24315824 (Database PSU 18.104.22.168.161018, Oracle JavaVM Component (OCT2016)) 24340679 (DATABASE BUNDLE PATCH: 22.214.171.124.161018 (24340679)) Installing patches... Patch installation complete. Total patches installed: 2 Validating logfiles... Patch 24315824 apply: SUCCESS logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/24315824/20676808/24315824_apply_NCDBA_2016Dec14_13_09_26.log (no errors) Patch 24340679 apply: SUCCESS logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/24340679/20713212/24340679_apply_NCDBA_2016Dec14_13_09_30.log (no errors) SQL Patching tool complete on Wed Dec 14 13:15:08 2016 [oracle@rac12pri1 OPatch]$
This concludes part 1 – the database is now set up and running on the primary cluster. In the next part I’m going to describe how to prepare the primary and standby cluster for the Data Guard setup.