My Jouney in the Oracle Cloud

As many of us I took advantage of the COVID-19 isolation to learn a bit more about the Oracle Cloud, something I always put of the last years because I had some bad feelings around it and the Cloud in general.

Mid  April was a partner training around the Oracle Cloud Architect Associate which I followed, and to be honest I was blown away, this really looked like LEGO.

I followed the Training and watched the video material and started playing, this was and is really fun.

As a DBA I forgot about IP's routing and all these things, but by watching
  a couple of times and playing with the cloud, cursing as well because it didn't work as I expected due to my misunderstanding, I learned quite a bit.

Saturday I have my Exam which btw until 15 th of may is free, meaning register your exam before the15th and do you exam later. Scheduling this exam was really good, it forced me …

19c Data Guard Series Part IV monitoring Data Guard with Cloud Control

A non ADG standby database is as you know running in mount mode and receiving and applying redo.

How do you connect to a database in mount, indeed with a user who has SYSDBA or SYSOPER.

In the past we monitored our standby's by either granting DBSNMP the sysdba privilege or by using SYS for the monitoring credentials.

My friend and Oracle Data Guard PM  Pieter Van Puymbroek pointed me to some interesting part of the licensing guide.

It is very important read this thoroughly : The CDB$ROOT and PDB$SEED can be READ ONLY but your PDB's still need to be in MOUNTED mode, if they are in READ ONLY and redo apply is on you need to license ACTIVE DATA GUARD

for more info have a look here

This means that a regular DBSNMP user can log on.

You will see that on the standby the open mode will be

select open_mode from v$database


So no more giving elevated rights to the standby !

Good work oracle
And thank you Pieter for the tip

19c Data Guard Series Part III adding a PDB to and existing Data Guard configuration

In the previous posts we have setup Data Guard with the broker.

Now lets add a PDB we will not create it from the seed but from an existing PDB using the HOT (why in bold keep on reading ) Clone feature introduced in 12.2
ok on our primary

show pdbs CON_ID CON_NAME OPEN MODE RESTRICTED ---------- ------------------------------ ---------- ---------- 2 PDB$SEED READ ONLY NO 3 TDETEST READ WRITE NO 4 ACMEPDB READ WRITE NO 5 NO_TDE_DG READ WRITE NO sys@CDBT01> create pluggable database testphil from acmepdb; Pluggable database created.

In the alert log on the standby we see following :
2020-04-29 12:21:18.831000 +00:00 Recovery created pluggable database TESTPHIL Tablespace-SYSTEM during PDB create skipped since source is in            r/w mode or this is a refresh clone File #72 added to control file as 'UNNAMED00072…

19c Data Guard Series Part II configuring the Broker

In the previous post we created a standby database using the dbca in silent mode

In this post we will do the necessary to put this configuration in a broker config

On the primary alter system set standy_file_management='AUTO';
alter system set dg_broker_config_file1='+DATA2/c20v02t1/DATAGUARDCONFIG/dr1.dat' ;
alter system set dg_broker_config_file2='+RECO2/c20v02t1/DATAGUARDCONFIG/dr2.dat' ;
alter system set dg_broker_start= true;
alter database flashback on;
On the Standby alter system set standby_file_management='AUTO';
alter system set dg_broker_config_file1='+DATA1/c20v01t1/DATAGUARDCONFIG/dr1.dat' ;
alter system set dg_broker_config_file2='+RECO1/c20v01t1/DATAGUARDCONFIG/dr2.dat' ;
alter system set dg_broker_start= true;
alter database flashback on;
What is left to do  Create static listener entries Depending on the node ( node1 will have cdbt011 node2 cdbt012 ) add following to you SID_LIST_LISTENER

  (SID_NAME = cdbt011)

19c Data Guard Series Part I using dbca to create a copy

We are currently scripting our Data Guard creation.

 One of the new features in 19c ( and maybe in 18c as well) is to use the dbca to create a standby. In a normal non RAC or non GI installation

I would never make use of this but on RAC it is different as the dbca also takes care of registering the resources in the clusterware, etc

So easiest would be to write a wrapper around the dbca and execute this is in silent mode, something we already did for the creation of CDBs, registering those in OUD etc....

The configuration : Exadata X4 test system with and oracle user and grid user. So here we go what are the steps we needed to follow.

In this example we have a primary db called cdbt01 with db_unique_name c99v02t2 the standby will be called c99v01t1

Things to do prior on the Primary RMAN configuration


Put the database in

patching Exadata from version to

As you know the 19 release of Exadata is a big one, it upgrades the linux distribution from Oracle Enterprise Linux 6 to 7. We have an OVM Based Exadata and in the progress of testing it. I will write some more this week about the process to upgrade to 19c so far we upgraded : * our cells * dom0 and are now in the process of upgrading the domU's however today we ran into a funny issue, for which we are waiting for the solution, 18.1.12 comes with linux release cat /etc/redhat-release on the upgraded system shows us Red Hat Enterprise Linux Server release 6.10 (Santiago) However the pre upgrade check tool during the upgrade complains on this Make sure you Read Andy Colvin's blog about this release you might need to redownload the patch as it was re-released More to come about this patching later UPDATE : in the meantime yesterday 15 may 2019 a new QFSDP was released

moving Exadata vm to a new node

The customer I am working for has OVM on Exadata for the dev qualification and testing Exadata we recently added two compute nodes. The main driver was RAM, it was less ( or equally priced) expensive to add two new nodes then extending the RAM ( removing existing DIMM and change them with higher capacity ones)

 We now have : 4 X6 nodes and two brand new X7 nodes (we just got them when X8 was released :-( ) there are quite some database running here and we since they are using the same cells no need to duplicate them.

 My colleague Freek D'hooge pointed me to this document : Moving a User Domain to a Different Database Server

 Ok that procedure worked as a charm, at first sight, only infiniband in the vm didn't come up. lspci didn't show us the IB card. luckily there was one vm during the installation of the extra nodes on this vm and we could start comparing the configuration : in the vm.cfg of the vm we "copied" from the X6" we saw following