The WordPress.com stats helper monkeys prepared a 2012 annual report for this blog.

Here’s an excerpt:

19,000 people fit into the new Barclays Center to see Jay-Z perform. This blog was viewed about 140,000 times in 2012. If it were a concert at the Barclays Center, it would take about 7 sold-out performances for that many people to see it.

Today a friend of mine pinged me an error while he was trying to create database using DBCA from 11.2.0.3 RDBMS home on an exadata box.Screenshot of the error is below

The error was easy to understand as compatible parameter set in the database initialization parameter was lower than the compatible.rdbms set for the diskgroup in ASM. The db compatible parameter was set to 11.2.0.0.0 whereas for the diskgroup compatible.rdbms was set to 11.2.0.2.0.

The compatible.asm diskgroup attribute controls the format of the ASM diskgroup metadata. Only ASM instances with a software version equal to or greater than compatible.asm can mount the diskgroup.

The compatible.rdbms diskgroup attribute determines the format of ASM files themselves. The diskgroup can be accessed by any database instance with a compatible init.ora parameter set equal to or higher than the compatible.rdbms attribute.

DBCA (choose General Purpose) doesn’t provide any screen wherein we can change the parameter value. But as we want to create the database using dbca, we need to change the parameter value in the template stored in ORACLE_HOME/assistants/dbca/templates

While starting the extract on UAT DB env which had been recently moved to exadata we got the below error.As we had redo and archive logfiles on ASM, we used “TRANLOGOPTIONS DBLOGREADER” in extract parameter file.

The first thing which we did is checked whether the role exists or not.

22:41:53 SYS@xxxxx1 > select role from dba_roles where role like 'DV_%';
no rows selected

Ahh, No roles starting with DV_ exists in the db. Then why is GOldenGate asking for this role.Doing some search on tahiti.oracle.com pointed to a document which mentioned

Grant the DV_GOLDENGATE_REDO_ACCESS role to any user who is responsible for using the Oracle GoldenGate TRANLOGOPTIONS DBLOGREADER method to access redo logs in an Oracle Database Vault environment. This enables the management of Oracle GoldenGate processes to be tightly controlled by Database Vault, but does not change or restrict the way an administrator would normally configure Oracle GoldenGate.

So, now we have a clue. Its something to do with Database Vault.The UAT env had recently been moved to exadata box, prior to which it on a normal server where the extract was running fine.