Hi all,
Hope you are all good.
I was working in an Upgrade project where some DB’s the downtime must be reduced. So, we decided to use GoldenGate.
In this blog post I will not show how to configure and setup GoldenGate replication.
This blog post is part of a series of 3 blog posts.
This first one I will show how to identify the WWIDs for the disk in case you are using multipath.


As you may be aware, in order to use GoldenGate, you must to do what Oracle calls as “Initial Load”, which means a consistent copy of the source DB to create the target DB.

Mostly of times, the Initial Load is done by a RMAN duplicate, so you can start GoldenGate Replicat process from the specific SCN to make sure that Replicat will continue in a consistent DB. Sometimes, an Export/Import (DataPump) using SCN to make sure that the export is consistent (and so you can start the Replicat from this SCN).
Here on this project we have some huge databases, lots of TB to duplicate. So, if we decided to use RMAN to duplicate a 80TB DB, it will take several hours. The “main issue” here is that several hours means that the GoldenGate lag to replicat will have several hours to catch up.
So, we are thinking in how to optimize this process and decided to take a clone of disks.
A quick overview of environment:
Storage is NetApp.
Part of DB’s are used for SAP applications and they are not using RAC.
For SAP DBs, they are using dNFS to store the database files.
For huge SAP DB’s, we asked Storage Team to execute the “backup” job from NetApp tool called SnapCenter.
So, they are putting the DB on backup mode (alter database begin backup), creating a snapshot for the NFS volumes and then ending backup mode (alter database end backup). With the snapshot taken, Storage Team is creating clones (new volumes) from the snapshot and mounting them in a different DB server. With that said, we create a controlfile for the new DB (using a trace for controlfile from the source DB), recovering the DB at some point, getting the SCN until this point, opening DB, proceeding with Upgrade, sometimes enabling TDE encryption and then starting OGG Replicat from the SCN where recovered has been done.
For the SAP DB’s I will create a blog post soon with more details.
Now, let’s talk about RAC DB’s. Some systems are not SAP and they are using RAC, storing the DB files on ASM.
So, the big question is:
  • How to clone the ASM disks and mount them on same cluster nodes used actually with no conflict?
Some points you must have clearly defined:
  • The cloned ASM Disks must have a different name than the actual disks;
  • The DiskGroup for the cloned disks must be renamed (remember, the cloned disks are part of an “existing” DiskGroup);
  • You must have a PFILE (init) with the parameters pointing to the new DiskGroup names;
  • You must create a trace of controlfile and replace the location of all database files (datafiles, tempfiles, redologs, etc) and use this trace to create the controlfile for new (target) DB.
So, with that said, let’s go. Let’s consider that Storage Team already taken the backup and created the clones.
They will send to us the UUIDs for the new disks.
Our actual DATA disks are:
The name of DiskGroup is DATA.
We must get WWIDs for those disks, remember, those are the actual ones, we will not touch them. We’ll get the WWIDs just to make sure that we’ll not touch the wrong disks.
How can we get the WWIDs?
As root:
oracleasm listdisks |grep DATA | while read x; do oracleasm querydisk -p $x |grep mapper |awk '{print $1}'; done

OK, now we know the WWIDs, let’s improve the output:
oracleasm listdisks |grep DATA | while read x; do oracleasm querydisk -p $x |grep mapper |awk '{print $1}' | cut -d "/" -f4 | cut -d ":" -f1; done

OK, those are the WWIDs, but this “p1” means the partition number.
oracleasm listdisks |grep DATA | while read x; do WWID=$(oracleasm querydisk -p $x |grep mapper | awk '{print $1}' | cut -d "/" -f4 | cut -d ":" -f1); echo "ASM Disk $x: $WWID"; done

ASM Disk DATA_0001: 3600a0980383041626a2b4c38386e7832p1
ASM Disk DATA_0002: 3600a0980383041626a2b4c38386e7833p1
ASM Disk DATA_0003: 3600a0980383041626a2b4c38386e7834p1
ASM Disk DATA_0004: 3600a098038304162745d4c3964754c30p1
ASM Disk DATA_0005: 3600a098038304162745d4c3964754c31p1
ASM Disk DATA_0006: 3600a098038304162745d4c3964754c32p1
ASM Disk DATA_0007: 3600a098038304162745d4c3964754c33p1
OK, so those are the “old” disks.
Storage Team provide us the new WWIDs. First thing to do, we must scan the disks in all cluster nodes:
iscsiadm -m session --rescan
OK, those are the IDs:
DATA_0001: 3600a0980383041626a2b4c38386e7836p1
DATA_0002: 3600a0980383041626a2b4c38386e7837p1
DATA_0003: 3600a0980383041626a2b4c38386e7838p1
DATA_0004: 3600a098038304162745d4c3964754c34p1
DATA_0005: 3600a098038304162745d4c3964754c35p1
DATA_0006: 3600a098038304162745d4c3964754c36p1
DATA_0007: 3600a098038304162745d4c3964754c37p1
Hope that helps.