Hash keys are often used as primary keys in Data Vault environments. When loading dimensional data marts from a Data Vault schema, it seems to be obvious to use them as dimension keys, too. At least in combination with Oracle Database In-Memory, this is not a good idea.
Analytic Views, in combination with Attribute Dimensions and Hierarchies, are very useful for ad-hoc queries in a Star Schema. But how about the performance of this Oracle 12.2 feature? I wanted to know it and analyzed the execution plans of some simple queries.
In summer time, the nights are very short. For some Data Warehouses, this is the case all year round, but not because of late sunset and early sunrise. The night is not long enough to finish all the ETL jobs. Long-running load jobs that run for several hours are not a seldom situation. Here some tips how this can be avoided.
On 13 and 14 September 2017, the Trivadis Performance Days 2017 will take place in Zurich. As in previous years, it will be an exciting event for everybody interested in Oracle performance features. For me, it will be a very special adventure this year.
Virtual Columns in Oracle are a convenient feature to implement derived measures of a fact table. But in combination with Oracle Database In-Memory, it has an impact on performance – unless you use Oracle 12c Release 2.
Hash keys can be used instead of sequence numbers to build surrogate keys in a Data Warehouse. This is often done in Data Vault environments, and there are some good reasons to do that. But there are also several issues and restrictions with hash keys. So, use hash keys only if you have good reasons for them. And if you decide to use hash keys in your Oracle Data Warehouse, make sure that you do it the right way.
There are many good reasons to use ANSI join syntax instead of the old Oracle join syntax. With one exception: If you want to use your Materialized Views for Query Rewrite, avoid to write them with ANSI joins.