New Oracle OLAP White Paper released to OTN

A new Oracle OLAP white paper has been released to OTN titled "Using Oracle Business Intelligence Enterprise Edition with the OLAP Option to Oracle Database 11g"

This contains a guide on how to configure the OBIEE metadata layer to leverage the 11g Oracle OLAP option, both indirectly via OLAP cube based materialized views, and directly via OLAP cube views. For those working with 10g OLAP (cube views only), the best guide to configuring OBIEE is found in the online tutorial on OTN.

Personally, I think that it is great that this white paper captures an explanation of how to write SQL that is optimised for Oracle OLAP cube views. This is something I find customers initially struggle with - they write what they believe is a simple query and then cannot understand why the performance is not good.

This is because there are a few golden rules to writing optimal SQL for OLAP cube views and while they are simple to understand, they are not obvious to those who are new to the technology. I hope to write a more detailed Blog entry on this subject very soon, but for the time being take a look at the white paper (particularly pages 10 & 11) to see what I mean.

More 11.1.0.7 ports now available

The Oracle Database 11g Release 11.1.0.7.0 Server Patch has now been released for several other ports, including Windows 32-bit.

The full list of operating systems currently supported is:

• Linux x86
• Linux x86-64
• Solaris (SPARC) (64-bit)
• IBM AIX (64-bit)
  
• HP-UX Itanium
• Microsoft Windows (32-bit)

I would recommend that all 11g OLAP users apply the 11.1.0.7 patch as soon as it is available for their operating system.

I would also recommend that all 11g OLAP users upgrade their AWM client to the 11.1.0.7A release which can be downloaded from Metalink or OTN

As always, the best source of information for recommended releases and patches is the Oracle OLAP certification page on OTN

I'm now going to download the Windows 32-bit patch (all 1.5GB of it!), and give it a roadtest....

Analytic Workspace Manager 11.1.0.7A released to Metalink

The 11.1.0.7A version of AWM has been released to Metalink as patch 7420490

It includes important fixes and new features including:

• the ability to add multiple languages to a single analytic workspace
• individual aggregation definitions may now be defined for each measure of a cube
• the Create Dimension user interface has been modified to allow levels of the dimension to be created at the same time as the dimension
• the functionality of dimension and cube mapping has been enhanced to allow the application to refresh the definitions of database objects interactively to reflect the current state of database schema tables

To take advantage of all the new fixes and features, the Oracle Database 11g Release 11.1.0.7.0 Server Patch must be installed as well. This is currently only available for Linux 32-bit & Linux 64-bit, but other ports are likely to be available soon.

Oracle OLAP Newsletter - September 2008

The latest edition of the excellent Oracle OLAP Newsletter has just been released here

Highlights this time include a customer feature on Oss Council in the Netherlands who use Oracle OLAP for management reporting, details of the new 11.1.0.7 release, and a guide to delivering summary management through cube materialized views.

Oracle Open World 2008 - HP-Oracle Database Machine launch

The big news at Oracle Open World last week was that Oracle CEO Larry Ellison used his keynote, entitled "Extreme. Performance." to talk about Data Warehousing and launch the HP-Oracle Database Machine featuring the innovative new Oracle Exadata storage server.

You can learn all about these exciting new products on the oracle.com web site, so I won't bore you with that here, except to tell you that the performance of the Database Machine that we have seen from our Beta test customers is deeply impressive (the "10x" claims in the ads are pretty conservative from what I've seen).


The market reaction to the news that Oracle, together with HP, are now offering a 'DW Appliance' with superior performance, based on proven hardware components & including Oracle Database 11g, has reflected a common view that I heard while answering questions from customers at Open World: that the rationale for purchasing one of the niche vendors' DW Appliances, with their narrow sweet spot and less capable database software is now more questionable than ever.

But why would anyone say that? Surely 'performance' is a game of leap-frogging, and if/when one of the DW Appliance vendors releases a newer faster machine before HP-Oracle does, won't that mean that the Oracle Database Machine's advantage is short-lived?

Not at all.

The HP-Oracle Database Machine is a DW Appliance like no other. This is because Oracle Database has depth & breadth of functionality and power that none of the others can claim. When you purchase a Database Machine you get Oracle Database EE, Real Application Clusters and Partitioning pre-installed and preconfigured, with ASM being used to manage the storage grid. All of the features included in there are available for use as soon as you plug in your new machine. But you can leverage much more even than that, of course.


And this is a key point - all the capabilities, features and options available in Oracle Database 11g are available on the Database Machine. Security, High Availability, Manageability, support for a Mixed Workload, and Embedded Analytics - all of it. And because this is standard Oracle Database, it is easy to run any of your applications on it - no specialised knowledge of rarely used niche RDBMS's required. Anything that runs your existing Oracle servers will run on Database Machine without change.

This includes OLAP of course. Oracle Database OLAP is there too - pre-installed along with the rest of Oracle Database EE. You just need to license it for use on the DB Machine when you choose to use it. And this is great news as it adds multidimensional calculation and analysis sophistication to an already awsome piece of kit.

A majority of the Oracle OLAP Option customers that I have met who report disappointing performance turn out to be IO Bound on their servers. That is, the server and storage they are using is out of balance, and constraining the ability of the Database to process the data. The HP-Oracle Database Machine (like some of the Optimized Warehouses also available from Oracle and it's other hardware partners) provides excellent IO performance thanks to the balanced high speed infiniband interconnects between the storage and the database servers included in the machine, and is optimised for data warehousing queries across the spectrum - OLAP included. Good IO performance directly translates to even more effective OLAP implementations.

So, the HP Oracle Database Machine is a great fit for Oracle Database OLAP Option, and other embedded analytics features of the Oracle Database, including Data Mining, SQL Analytics and Statistical Functions, and the OWB (Oracle Warehouse Builder) Data Profiling and Data Quality features. Delivering BI applications that leverage these powerful capabilities is also much easier thanks to them being pre-installed on the Database Machine.

And Oracle OLAP is a great fit for the Database Machine, too. Which leads to the other question I have been asked by a couple of people: if Database Machine makes queries really really fast, does it mean that OLAP is no longer needed? Can I just dump all the data into tables and ignore all the other optimisations for Data Warehousing that Oracle Database provides?

This question misunderstands the primary reason that people invest in OLAP systems. It is not only about performance, but also (especially) about the calculation capability, and the ease with which even the most complex of business calculations can be expressed. Many business calculations are difficult to do in SQL on regular relational tables. Some are still not even possible. And in turn, many BI tools resort to the transfer of large amounts of data across the network to mid-tier servers, or even the client, where the calcs are performed. Database Machine will allow them to pull the raw data much faster than before, but you still have a more complex architecture than you need, and network performance will be impacted. The OLAP Option makes time series, shares, indexes, ratios and so on that businesses use on all their performance dashboards really easy to define, and really efficient to process. In the Database.

As regular readers of this blog know, the OLAP Option provides sophisticated multidimensional calculation and query functionality, accessible by pretty much any tools via a simple SQL query. There are hundreds of multidimensional-aware analytic calculation functions delivered by the OLAP Option - best of breed capability. This in turn leads to further performance benefits of course, but especially phenomenal ease of use and cost of ownership improvements. If all your KPIs are calculated within the Database, and surfaced to your BI tools, BI apps and Dashbards as simple columns that can be SELECTed; you reduce to trivial levels the amount of work you need to do in each BI Tools metadata layer with regard to (re)defining those calculations.

Other Data Warehouse vendors - appliance & non-appliances alike - cannot do this, and instead force you into further fragmenting your information asset across multiple servers and engines, with the added complications to the BI infrastructure that brings. The other vendors will require you to purchase, install, build and manage seperate standalone multidimensional data marts, usually from 3rd party vendors. None of them have embedded analytics into the core of the Database like Oracle has. And none provide simple high performance SQL access to the results of these analytics.

The combination of extremely fast performance for IO intensive queries (which characterise the work of some of the users of the data warehouse and are typicaly the queries targetted by the DW Appliance vendors) together with the multidimensional calculation power of the OLAP Option (which are commonly consumed by the masses via interactive dashboards etc, as well as used by the analyst users) in an easy to install, pre-configured, balanced hardware platform is very compelling.

Exciting times for Oracle BI and Data Warehousing.

Article : Closing the Ad Hoc Query Performance Gap for Good

I found an interesting article today in amongst my Google alerts. It related to a topic of conversation at the recent TDWI conference in May about the issue of adhoc query performance within data warehouse environments. The article, on the whole, was very good (in my opinion) and included comments by Oracle's vice-president of database marketing, Willie Hardie.

The full article in Enterprise Systems is available here.

The article examines the reasons why business users feel their queries are taking too long and what steps companies are taking to try to improve query performance. The basic reasons for poor query performance was given as being down to two issues:

• success of pervasive BI - so more users are running adhoc queries
• more data - users want access to more and more data, both in terms of level of detail and time span.

I would add a third reason, which is increasing sophistication. Simply presenting users with reports that show revenue and expenses for the latest month, quarter and year to date are not adequate in today's highly competitive environment. Business users want to know about trends - this period vs last period, this year vs last year, this period vs the same period last year, like-for-like, shares, ranks, forecast, customer segmentation, market basket analysis. The list goes on and on and on.

Here is a direct quote from the article:

......The RDBMS -- or, more specifically, the Oracle RDBMS -- is an unmatched analytic workhorse, Hardie argues. Oracle is one of the biggest data warehousing players in the business, he points out, and the Oracle database powers some of the largest DWs in existence.

"The Oracle database is proven to be the fastest database out there for both transactional systems and data warehousing systems, across all scales, from small to extremely large systems. You ask any Oracle customer out there and they'll all give you the same answer: Oracle is the fastest database out there on the market right now," he claims.

What I would add is the Oracle Database is the only database with embedded multidimensional OLAP, which is fine tuned for adhoc query performance, query scaleability and, most importantly, calculation power. As I stated above it is no longer about simply what is happened in the last trading period, BI analysis is now all about comparisons, trends and KPIs (calculations) at aggregate levels with the ability to drill right through to the lowest level of detail.

As the article quite clearly acknowledges there is a trend to opening up the corporate data warehouse to more and more users, which means query performance and scalability are becoming increasingly important. Only Oracle Database has specific built-in optimisations, such as OLAP and data mining, to meet these growing requirements.

For those of you new to Oracle OLAP Option and Oracle Data Warehousing you can get more information from these links:

Oracle OLAP Option on OTN
Oracle OLAP Option Forum on OTN
Oracle OLAP Option Wiki
Oracle OLAP Option on Oracle.com
Oracle Data Warehousing on OTN
Oracle Data Warehousing on Oracle.com
Optimised Warehouse Initiative

Best Practice Tips : SQL Access to Oracle DB Multidimensional AW Cubes (#2)

One of the most useful features introduced with Oracle Database OLAP is the ability for the powerful multidimensional calculation engine and the performance benefits of true multidimensional storage in the Analytic Workspace (AW), to be accessed and leveraged by simple SQL queries.

This single feature dramatically increases the reach and applicability of multidimensional OLAP – to a vast range of BI query and reporting tools, and SQL-based custom applications that can now benefit from the superior performance, scalability and functionality of a first class multidimensional server, but combined within the Oracle Database with all the other advantages that derive from that.

This post is the second in a series that I will use to share some general best practice tips to get the most out of this feature, so that you can deliver even better solutions to your business end-users:

Best Practice Tip #2: General AW Object Naming Conventions for dimensions, levels, hierarchies and attributes…(Oracle Database 10g and 11g)

The following advice will result in much easier to understand and use relational views over your AW. It makes the implementation much cleaner to visualise, and easier for other users to understand what they are looking at. It also saves a lot of typing for developers that are writing their own SQL queries!

The objective is to ensure that the generated column names in your views are easy to read, and also to avoid the possibility that generated column names may get truncated to fit within the limits for a column name in Oracle Database (when that happens your views get really ugly really quickly). Finally, it has the additional desirable side effect of making it easier and therefore quicker to do the mappings in AWM because the screens are less cluttered with long-winded object names!

Note: this advice follows both for Oracle Database 10g OLAP (eg views created by the AWM10g View Generator Plug-in) and for Oracle Database 11g OLAP, where views are auto-generated (eg when creating your Standard From AW via AWM11g).

Here is the idea:

• Keep the names used for dimensions, levels, hierarchies, and attributes as short as possible, while still meaningful of course.
• If possible (simply for readability in the resulting relational view and column names), avoid the use of the "_" char especially for dimension, hierarchy, level and attribute names.
• If possible (also recommended if Oracle OLAP API clients such as OracleBI Spreadsheet Add-in , OracleBI Discoverer Plus OLAP and OracleBI Beans will be used on the same AW), create the AW in its own schema.
  

Don't be seduced into thinking it is a good idea to put "DIM" in the name of everything that is a dimension, or "ATT" into the name of all the attributes. You don't need to do this. The AW knows what objects are what, and you can very simply query the AW if you need, for example, to find out the names of all the Dimensions in an AW. (Another topic for another day is to walk thru all the Data Dictionary stuff that helps with this).

In other words: If you have a Product Dimension, it is self-evidently a dimension, so clogging up its name with "_DIM" or "_DIMENSION" is just extra wear and tear on your keyboard!

Example:

To illustrate the impact this advice can have, here are two Product Dimensions, which apart from the fact one follows best practice advice and one does not, are identical (example is from Oracle Database 11g AW) (you can click on the picture to see it full size):

First – two ways I could have created my Product Dimension:

Second – what the resulting dimension views for the Main hierarchy would look like in each case:


Third – how much harder it is to read and write the SQL to query the AW’s dimension as a result:

Which of these functionally identical examples is easier to read, easier to understand and easier to query?

I rest my case. Giving a bit of thought to the way you build your AW before you build it nearly always pays dividends later.