Today I took the Oracle 12c: OCP beta exam (1Z0-063)

Today, I took the beta exam for 12c OCP. I have been a DBA for over 9 years now so thought it shouldn’t be too hard to pass (especially the RMAN parts) and concentrated on studying just the new Multitenant topics…boy I was wrong!

The tough thing is, I used this book as my study guide. Now, I was a little dubious to start with as the “official” Oracle study guide is not due to be released until March 2015. So how could this book cover all the correct topics with the relevant detail?
Well, it didn’t!

Without disclosing the contents of the exam, I would put anyone off using this book and wait until the “official” book is released. For example; one of the key missing subjects that stands out for me was limitations of RMAN backups when connected to a PDB e.g. When connected to a PDB you can’t backup the archive logs.

Lesson’s learnt:

  1. Wait for the “official” study guides to be released.
  2. Is getting certified really worth taking a 3:45hr beta exam, considering my work will pay for the full exam costs?

Whether I have passed or not is still unknown for at least 11 weeks, if the beta closes as expected.
I am not as confident as I was with the 12c OCA mind.

Upgrading ASMLib after OS upgrade

One of our very first ASM databases was created using ASMLib and after a Linux upgrade from 5.9 to 5.10, ASM would not start. After some digging around, I noticed that it was oracleasm that was not loaded.

/etc/init.d/oracleasm status
Checking if ASM is loaded: no
Checking if /dev/oracleasm is mounted: no

So I tried to manually start it, which failed:

/etc/init.d/oracleasm start
Initializing the Oracle ASMLib driver:                     [FAILED]

To fix this, I downloaded the oracleasm RPM that was for the new version of the kernel. Which can be found using the command:

uname -r

Download of the oracleasm RPM is available from here.

I then installed it using this command below (-U performs upgrade of existing RPM):

rpm -Uvh oracleasm-*.rpm

Started ASMLib again:

/etc/init.d/oracleasm start
Initializing the Oracle ASMLib driver:                     [  OK  ]
Scanning the system for Oracle ASMLib disks:               [  OK  ]

And the problem was solved!!

Alternatively…if you have direct internet access from your server, then you can perform this command to download and update your drivers directly from Oracle:

/etc/init.d/oracleasm update-driver

RAC & Data Guard – FAL issues after role change

Today I had to convert a physical standby to snapshot standby using the DG Broker. The steps to perform this are very simple and completed with no errors. However, while performing a health check of the databases I noticed a slight issue.

Messages in the Primary DB alert log were showing this:

<pre>Tue Jul 15 10:25:56 2014
FAL[server, ARC5]: FAL archive failed, see trace file.
ARCH: FAL archive failed. Archiver continuing
ORACLE Instance PPMOBB1 - Archival Error. Archiver continuing.
Tue Jul 15 10:25:56 2014
FAL[server, ARCj]: FAL archive failed, see trace file.
ARCH: FAL archive failed. Archiver continuing
ORACLE Instance PPMOBB1 - Archival Error. Archiver continuing.

And messages in the Standby DB alert log were showing this:

<pre>Tue Jul 15 09:24:23 2014
Creating archive destination file : +FRA (248306 blocks)
Tue Jul 15 09:24:23 2014
Creating archive destination file : +FRA (157408 blocks)

In order to fix this and allow the Primary DB to send the archivelogs to the snapshot standby, I had to set the max_connections property from 4 to 1 within the DG Broker config:

<pre>dgmgrl /
DGMGRL> edit database 'RPMOBB' set property max_connections=1;

After setting this, the snapshot standby started to receive the missing archivelogs and then stayed in sync thereafter.
The solution was found in this MOS Doc. However, it is supposedly fixed in 11.2 and I am running 11.2.0.3 so appears not be the case.

Archive logs Shipping Skipped Intermittently, Standby Fails to Resolve Gap Automatically (Doc ID 1366234.1)

Simplified RAC Patching Scripts

Since the company I work for has deployed 6 node RAC clusters as their license/utilisation consolidation platform, I thought it was wise to invest some time into scripting a simplified solution to ease the patching process.

As the cluster is Admin Managed, the DBA’s make a conscious decision as to which nodes the instance is allowed to run on and depending on the criticality of the database, how many instances it is allowed to run. The DBA then manually disables the other instances to stop CRS from starting them on restarts.

Before I wrote these scripts, we were relying on crsctl stop crs with the default shutdown option being set to transactional for each database. However, it came apparent while tailing an instance alert log that CRS actually aborts the instances and ignores the default shutdown option, meaning sessions connected to the instances CRS was aborting would end up being killed and potentially cause issues with the applications.

The scripts are a little quick and dirty stop gap at the moment but perform the job required.

The workflow is broken down into the following steps and you must have User Equivalence configured between all nodes for these to work:

  1. Runs Pre-Checks as SYSDBA on all running databases.
  2. Sets all databases default shutdown mode to transactional. This is available from 11g onwards and waits for all running transaction to either commit or rollback.
  3. Generates a dynamic script to stop all the instances running on the particular node you wish to stop for patching.

 

Work In Progress