Tales of an oracle dba

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

OPEN_MODE
--------------------
READ ONLY WITH APPLY 




So no more giving elevated rights to the standby !

Good work oracle
And thank you Pieter for the tip

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
HOT CLONE
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…

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_DESC =
  (SID_NAME = cdbt011)
  …

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

CONFIGURE DEVICE TYPE DISK parallelism 8
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DATA2/C99V02T1/snapshot_ctl.cf'; SQLPLUS

Put the database in
 FORCE LOGGING
CREATE THE …

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

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


…