"Excel freezes (or hangs) when I try to change this filter"

Most of us have seen this at one point or another and shrugged it off as a busy time or processing is going on or there are cats clogging up the tubes, etc. Tonight, I finally decided to figure out what's causing it.

When you have an OLAP cube filter in your pivot table and expand the items list to select your filter items, Excel fires a bunch of Discover commands at the cube (these are pretty light in most cases). If you don't have anything selected yet (so you just have the default member selected) Excel isn't doing much work here and the list pops right up. Here's two basic flow examples for what discover commands are fired off when you DO have an item selected:

If you have one level 1 member selected

1. MDSCHEMA_CUBES (whatever cube you're connected to)
2. MDSCHEMA_CUBES (again, same thing)
3. MDSCHEMA_MEMBERS (LEVEL_UNIQUE_NAME of the filter), no TREE_OP
4. MDSCHEMA_MEMBERS (MEMBER_UNIQUE_NAME of the selected member) TREE_OP 4, only immediate parent
5. MDSCHEMA_MEMBERS (MEMBER_UNIQUE_NAME of the selected member's parent) TREE_OP 8, returns itself
6. MDSCHEMA_MEMBERS (MEMBER_UNIQUE_NAME of the selected member's parent) TREE_OP 1, returns all children

If you have one level 2 member selected in a hierarchy

1. MDSCHEMA_CUBES (whatever cube you're connected to)
2. MDSCHEMA_CUBES (again, same thing)
3. MDSCHEMA_MEMBERS (LEVEL_UNIQUE_NAME of the filter), no TREE_OP
4. MDSCHEMA_MEMBERS (MEMBER_UNIQUE_NAME of the selected member) TREE_OP 4, only immediate parent
5. MDSCHEMA_MEMBERS (MEMBER_UNIQUE_NAME of the selected member's parent's parent) TREE_OP 4, immediate parent
6. MDSCHEMA_MEMBERS (MEMBER_UNIQUE_NAME of the selected member's parent's parent) TREE_OP 8, returns itself
7. MDSCHEMA_MEMBERS (MEMBER_UNIQUE_NAME of the selected member's parent's parent) TREE_OP 1, all children
8. MDSCHEMA_MEMBERS (MEMBER_UNIQUE_NAME of the selected member's parent) TREE_OP 8, returns itself
9. MDSCHEMA_MEMBERS (MEMBER_UNIQUE_NAME of the selected member's parent) TREE_OP 1, returns all children

So, that's six requests for a level 1 member and 9 requests for a level 2 member - both of these take milliseconds to complete the whole flow, so no big deal. When does this become a big deal? When you do something like click the "Select multiple items" checkbox, expand a hierarchy and UNCHECK something... like if you opened the Adventure Works 2008 cube, added Delivery Date.Date as a filter, expanded the "All Periods" level and deselected the first day:

Now click OK and expand the items box - we get a familiar popup:

It comes back after a few seconds with the expected item list, but why did it take so long? Well, based on our flows above, we have a whole bunch of level 1 members selected - 1187 of them to be exact. That means there will be 1187 requests for their parent member (TREE_OP 4) which will all return the [All Periods] member. To illustrate this, I traced that exact operation:

The profiler captured 1192 discover requests - 1187 of them were getting the parents of selected members, two were MDSCHEMA_CUBES requests, one was getting [All Periods], one was getting all the children of [All Periods], and one was getting the Unique Name of the root level. Not cool. Imagine what happens when your talking about tens of thousands of members at a particular level! Granted, that seems unlikely but understand that the logic behind this is "I don't want to see this", "hide just this member", and so forth - in some cases people have no idea what actually happened was they unchecked one of 6,000 members.

So what to do about this? Educate. To fix the immediate problem of a seemingly broken Excel pivot table - just wait for the filter to load, it'll come back eventually. In the future when working with Excel filters, always favor selecting vs. deselecting and filtering at higher levels in the hierarchy whenever possible.

After each XMLA command step, insert a T-SQL step to verify that the XMLA command step succeeded:

DECLARE @JobName VARCHAR(64)
 
SET @JobName = ‘Name OF Job This Step Belongs TO’
 
DECLARE @Message VARCHAR(1024)
 
SELECT TOP 1 @Message = CAST([message] AS VARCHAR(1024))
FROM msdb.dbo.sysjobhistory a
INNER JOIN msdb.dbo.sysjobs b
ON a.job_id = b.job_id AND b.[NAME] = @JobName
ORDER BY run_date DESC, run_time DESC, step_id DESC
 
IF @Message LIKE ‘%<Exception %’
RAISERROR (@Message, 17, 1)

UPDATE (2009-04-03): Added , step_id DESC to ORDER BY clause - when the XMLA job fails instantly (say you tried to process a nonexistant partition), run_time doesn't have enough granularity to sort properly.

Once your done, your job steps will look something like this: