I first attended Kscope in 2010, when it was – serendipitously – held in Washington, D.C., just a short walk from my then apartment. Within a few hours I had met, in person, a number of people with whom I’d develop both friendships and professional relationships over the next several years. The past few months have seen (along with other more severe hardships) almost all the regular, in-person touchpoints in our industry cancelled. Kscope20, Collaborate, Oracle Openworld etc. Many have been replaced with virtual content (special thanks to the hard work of ODTUG staff, volunteers and speakers, who produced an extremely successful Learn From Home Series). This means that I’ve missed the opportunity to catch up with all my old industry friends from all over the world, and the opportunity to meet new ones.
I’ve also been in the ACE Program for over five years now, and the real core of that (to me, at least) is the sharing of information and enabling and participating in an ongoing “conversation” about technology. In the past, I’ve tried to do that via blogging, Twitter, speaking and volunteering for ODTUG. A month or two ago my friend Cameron Lackpour invited me to join him and Celvin Kattookaran in exploring an additional platform – podcasting. Our objective is to talk to interesting people in our industry – software vendors, service providers, people in industry – in a manner that, hopefully, brings to mind the conference post-session hallway / breakfast / lunch / party conversations that we haven’t been able to have this year. Webinars and online sessions are far from redundant, but we feel there’s a personal insight and aspect that gets missed when those are the only form of interaction with our industry peers, and we hope that a casual, conversational format (hence the name – EPM Conversations) can fill some of that void.
We’re not the only recent podcast in this space – Opal Alapat and Anthony Manfredi launched their Performance Management Techcast just a couple of weeks back (perhaps also missing the opportunity to blather about all this stuff at conferences?) – but hopefully there’s room for both of us and plenty more.
Episode 1: Introduction is available now. You can listen and subscribe via EPMConversations.com, Apple Podcasts, Google Podcasts, and Spotify. Please give it a listen (and get in touch, if you’d like to participate!) and let us know what you think, and who you’d like to hear joining us. Cheers!
Essbase 19c appeared on the Oracle Cloud Marketplace back in September 2019, but that initial release was only available on a “BYOL” (bring your own license) basis. That meant that only customers who already owned – or went out and bought – on premises licenses were able to comply with its license terms. The list price for a single processor on premises Essbase license being USD138,000 – plus a cool USD30k and change for annual maintenance – this presented a barrier to entry for potential users accustomed to subscription or usage models for cloud systems. It was also a problem for medium sized consulting shops and people like me who had been in the habit of running the local installations permitted under previous license terms for educational purposes. I’m sure I was not alone in making this point frequently and vigorously to Oracle (aka harassing Product Management) and I’m glad to report that an additional Marketplace option has now appeared under which Essbase is licensed on the Universal Credits Model or “UCM”. This means that there are two competing pricing models for Essbase 19c on Oracle Cloud Infrastructure. So how do they pencil out?
This post expands on a concept I touched on a few years back in the context of #Missing suppression (see the section on NONEMPTY in this post) and specifically the “perspective” from which any kind of filter – for #Missing or not – is evaluated. This question on the Essbase Users board got me thinking about the topic again, and the potential MDX ‘gotcha’ it presents.
A Network54 Essbase board user asked a question today that I’ve heard a few times without ever being sure of the answer:
“If the MDX report run after query tracking is enabled returns no data… ….does it still aggregate?”
In other words, if you turn on query tracking in ASO and then run queries, but those queries only return #Missing instead of finding some data, will the queries still affect the aggregate views that Essbase chooses?
A quick post prompted by a recent OTN thread. The Essbase Database Administrator’s Guide tells us that the recommended size of the Data Cache is 1/8 the size of the Data File Cache. Even granted the usual caveats on these recommendations, I think this one is really odd.
Le Beaujolais Nouveau Oracle Analytics Cloud Est Arrivé!
At long last, Oracle Analytics Cloud – the Oracle Cloud offering that includes Essbase Cloud along with BICS and DV – is on sale. I’m going to have a lot to say in more detail about this product over the coming weeks, but as a long-time “Essbase guy”, my first blog post will be aimed at people who already use Essbase on-premises, and some of the questions I think they’ll have: Why would you want to consider Essbase Cloud? How does it differ from the on-premises product? If Essbase Cloud is compelling, how would you move existing applications to test it out?
I’ve been working on tuning aggregate views with a test copy of a large ASO cube to which I added some additional dimensions. Tuning aggregate views can be tricky, because aggregate views make query performance heavily dependent on the exact combination of levels being queried. And there’s always some user that comes along with an unusual query that happens to hit a combination of levels that performs particularly poorly. So when I handed the system over for front-end certification by users, I enabled query logging. By parsing the log for “worst case” query times, I could proactively monitor and then investigate any particularly nasty cases the users encountered. Unfortunately, I was being a little bit too smart for my own good.
This post is a quick follow-on to my last, inspired by the same piece of client work. Fair warning: it’s only going to make sense if you are already somewhat familiar with aggregate views and view definition scripts (.csc). If you’re not already familiar with the concepts but want to read this anyway, I’d refer you to a presentation given at Kscope11 as an excellent (ahem) primer on the topic (free associate membership of ODTUG required).
But in summary: Many people maintaining larger or complex ASO cubes have developed very carefully crafted sets of aggregate views to optimize query performance. They also know that, unfortunately, some structural changes can invalidate those view definitions – adding levels to stored dimensions and adding new stored dimensions to name two. This can necessitate a lot of painstaking, trial-and-error optimization to generate a new set of aggregate views that provide equivalent performance to the original set.
In the course of adding a new dimension to an existing cube, I realized that there was a straightforward way to preserve the validity of my existing set of aggregate views.
A long gap since my last blog entry – for which I’m going to mostly blame Kscope…
I’ve mentioned before that I really enjoy the Unix tools and am working at becoming more competent with them. In this post, I’m going to explain why adding a new dimension to an ASO cube while retaining existing data is slightly harder than doing the same to a BSO cube, and then show how I used a very simple script (ksh, but these are such basic commands that I’m sure it can be translated easily if not used exactly as is) to modify native export files and solve the problem.
Even fans of MDX like me will agree that it isn’t the most aesthetically pleasing language, so it’s painful to see it made more convoluted than strictly necessary. This post is a grumble about a piece of redundant syntax that appears far too often, and has really begun to grate…