Security filters can be difficult beasts at the best of times, especially when it comes to the interaction of multiple filter rows / multiple filters (I glaze over on reading the DBAG statement that “a filter that defines a more detailed dimension combination list takes precedence over a filter with less detail”). In this post I’m going to discuss a particularly confusing behavior involving the interaction of calculation privileges with filter access. I’m not the first to discover or comment on the following phenomenon, but I don’t think it’s been written up comprehensively. The DBAG entry for filters certainly doesn’t make any mention of it, which seems like an oversight.
A very quick post on a perennial Essbase problem: the application that refuses to be deleted. Generally this happens when an application has been corrupted, due either to a bug, a crash or some clown’s1 too-smart-for-own-good file system monkey business. The application then can’t be started, and deleting an application requires that it be started first. I ran into this today with an application that had somehow been created as BSO before an ASO backup was restored into its folder structure.
EPM Support Documentation
Thanks to Oracle’s well-worth-following Business Analytics – Proactive Support blog, I’ve been introduced to a couple of interesting support policy documents relating to the EPM stack:
- Support Document ID 1617238.1: Oracle Enterprise Performance Management Software Error Correction Policy (I’ll call this ‘ECP’)
- Support Document ID 1590676.1: Oracle Enterprise Performance Management 11g Grace Periods for Error Correction (‘GPEC’)
These documents also reference the more widely applicable Lifetime Support Policy: Oracle Applications (‘LSP’).
With no disrespect intended, I’d guess that many EPM practitioners are unaware of some finer points of support policy. I know that I was! And without understanding the content of these documents, it’s impossible to give comprehensive answers to questions such as ‘For how much longer is Oracle committed to providing fixes for my 11.1.2 system?’ (the answer may be more complicated than you think). However, the documents themselves tend towards legalese, and they don’t always make completely clear what the real-world implications of the policies are. The GPEC document was updated on March 6th to include 184.108.40.206 information, so this is an opportune time for a plain-English review.
Some Old News
One relatively unsung enhancement to Essbase in 220.127.116.11 was a change to CALCTASKDIMS behavior. Before 18.104.22.168, CALCTASKDIMS defaulted to a value of 1. From 22.214.171.124, Essbase selects a value for CALCTASKDIMS automatically unless overridden by the user with either the CALCTASKDIMS .cfg file setting or the SET CALCTASKDIMS calculation command.
So why am I blogging about this years after 126.96.36.199 came out? First, there is a good theoretical reason why the above Essbase ‘enhancement’ might have a seriously negative effect on calculation performance, which can be especially surprising when it occurs following a supposed upgrade. Second, this actually bit a coworker a few days ago, and it’s always satisfying (for me, if not my coworker) when empirical data and theory coincide.
Logging out users prior to performing an administrative task is such a common requirement that I give it barely any thought. This complacency bit me recently, and – since I suspect that I’m not alone – I want to share a simple observation about the MaxL operations involved. Continue reading
One feature of all Essbase query tools is the ability to suppress (i.e. remove from the result set) #Missing values, in most cases via a simple, on-or-off option that applies to full rows. In MDX, #Missing suppression is slightly more involved, but also has some interesting subtleties that make possible queries that would be harder or impossible (at least, in one step) to achieve using other tools. Continue reading
Block density – that is, the percentage of non-missing dense intersections at a non-missing sparse intersection – is an important performance parameter for BSO databases, but the Essbase documentation does not provide details of the algorithm used to derive the ‘Average Block Density’ statistic visible in EAS or via MaxL. Continue reading