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.
- Wait for the “official” study guides to be released.
- 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.
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:
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:
This post will discuss my findings & experiences of using the new In-Memory option that has been released in version 220.127.116.11.
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 18.104.22.168 so appears not be the case.
Archive logs Shipping Skipped Intermittently, Standby Fails to Resolve Gap Automatically (Doc ID 1366234.1)
Nice high level overview that I found as a starter for MySQL from an Oracle DBA’s perspective.