Oracle’s excellent Big Data Lite VM has been updated, to version 4.5. Download it here Changes: CDH 5.5 -> 5.7 Big Data Spatial and Graph 1.1 -> 1.2 Big Data Discovery 1.1 -> 1.2 Oracle Big Data Connectors 4.4 -> 4.5 Oracle NoSQL 3.5 -> 4.0 GoldenGate 12.2.0.1 -> 12.2.0.1.1

Recently added to the oracledi project over at java.net is an adaptor enabling Oracle GoldenGate (OGG) to send data to Elasticsearch. This adds a powerful alternative to [micro-]batch extract via JDBC from Oracle to Elasticsearch, which I wrote about recently over at the Elastic blog. Elasticsearch is a ‘document store’ widely used for both search and analytics. It’s something I’ve written a lot about (here and here for archives), as well as spoken about - preaching the good word, as it were, since the Elastic stack as a whole is very very good at what it does and a pleasure to work with.

In Oracle 11g, the DBMS_STATS procedure GATHER_SCHEMA_STATS takes a parameter ‘options’ which defines the scope of the objects processed by the procedure call, as well as the action. It can be either GATHER or LIST (gather the stats, or list out the objects to be touched, respectively), and AUTO, STALE or EMPTY (defining the object selection to process). GATHER on its own will gather stats on all objects in the schema GATHER EMPTY / LIST EMPTY is self-explanatory - objects with no statistics.

Have you defined CLIENT_ID in your OBIEE RPD yet? You really ought to. As well as helping track down users of troublesome queries, it also tags dump files with the OBIEE user of an offending query should the worst occur: For details, see: Identify your OBIEE users by setting Client ID in Oracle connection Instrumenting OBIEE for tracing Oracle DB calls

Here’s a scenario that’ll be depressingly familiar to most reading this: after ages of running fine, and no changes to the code, a query suddenly starts running for magnitudes longer than it used to. In this instance it was an ETL step which used to take c.1 hour, and was now at 5 hours and counting. Since it still hadn’t finished, and the gods had conspired to bring down Grid too (unrelated), I generated a SQL Monitor report to see what was happening: [sourcecode language=“sql”] select DBMS_SQLTUNE.

There is a well-documented problem relating to DBMS_STATS.COPY_TABLE_STATS between partitions where high/low values of the partitioning key column were just copied verbatim from the source partition. This particular problem has now been patched (see 8318020.8). For background, see Doug Burns’ blog and his excellent paper which covers the whole topic of statistics on partitioned tables. This post Maintaining statistics on large partitioned tables on the Oracle Optimizer blog details what the dbms_stats.

Chucking a stick in the spokes of your carefully-tested ETL/BI … My opinion is that automated stats gathering for non-system objects should be disabled on Oracle Data Warehouses across all environments. All it does it cover up poor design or implementation which has omitted to consider statistics management. Once you get into the realms of millions or billions of rows of data, the automated housekeeping may well not have time to stat all of your tables on each run.

Just because something produces the correct numbers on the report, it doesn’t mean you can stop there. How you are producing those numbers matters, and matters a lot if you have an interest in the long-term health of your system and its ability to scale. OBIEE is the case in point here, but the principle applies to any architecture with >1 tiers or components. Let me start with a rhetorical question.

Chris Mellor at The Register posted an interesting article a couple of days ago, entitled HP and Violin build Oracle Exadata killer. The slidedeck has been removed from HP’s FTP site, but a bit of Google magic throws up a couple of mirror copies. It’s an entertaining read (“Do a Proof of Concept! 94% win rate!! We can and do win against Exadata!!”), and a nice illustration of the FUD techniques that companies use in marketing their products against others.

Whilst perusing the Oracle database documentation, I noticed something which caught my eye: As well as reading the documentation online as HTML or downloading as PDF for viewing on your computer etc, you can also download it in formats (Mobi and ePub) designed for eReaders such as the Kindle and iPad (the latter obviously isn’t “just” an eReader). For information on format support, there’s a handy table on Wikipedia. It looks like the availability of mobi/epub files isn’t universal.