Dan English's BI Blog: Analysis Services

SSAS Deployment Wizard Retaining Permissions

Sun, 20 Jul 2008 13:37:12 GMT

Had a great question last week at the MNPASS SQL Server User Group in regards to using the Analysis Services Deployment Wizard and I just wanted to post the follow-up. I have read about the wizard, but actually have never used it (but you need to know about it for the MCTS test 70-445 or 70-448). I have just always deployed my databases through BIDS and have always had the roles and permissions defined in the solution. This provided me a great opportunity to explore the wizard. What I needed to find out was if the issue of losing the database permissions had been fixed in 2008 (refer to this MS KB article for the current issue here – basically the permissions do not get pulled into the XMLA script using the ‘Retain roles and members. The roles and members will not be deployed.’ option).

So first I tested this out in 2005 to verify that this was an issue and there wasn’t a hidden checkbox somewhere to resolve the issue. I generated the script and reviewed it and it did pull in the roles and members, but no permissions (database, dimensions, etc.). So whatever permissions were setup on the server would be wiped out once the script was executed. Here is a snippet of the script and if you performed a search in the file you would see that no permissions were included.

I then setup a project in BIDS 2008 (VS 2008) and performed the same steps as with 2005 and everything was pulled into the script properly (cube, database, and dimension permissions) this time

The one thing is though if you are trying to separate the security control and permissions from the developers and DBAs this really won’t fix that problem because the wizard needs to extract the permissions and include them in the file to be executed against the SSAS database. This means that the developers will be able to view and modify the permissions prior to executing the script. I suppose this would mean that the DBAs would need to take over the responsibilities of using the deployment wizard or at least have a backup script of the existing Roles setup on the server prior to deployment.

SSAS MDX Round = Banker's Rounding

Sat, 19 Apr 2008 13:10:09 GMT

A couple of weeks ago I was working on a project where I had to implement some Ranking calculations within an Analysis Service (SSAS) cube. I went ahead and added in the calculations and then the client came back to me and stated that there was some additional business logic that we needed to implement. At different levels of reporting they utilize some rounding into the calculation that is used to determine the Ranking. When viewing the report at a store level then we need to round the calculation to two decimal places and at all other levels the value will be rounded to four decimal places to be used in the Ranking function. I thought to myself 'no problem' and I went ahead and added in this additional logic and put the Round function into place to handle this logic. Done.

Well was I wrong. The client came back to me and said that stores were not being ranked properly and why if these had the same calculation score, 93%, did they not have the same rank. I was like 'what? all i did was add the business logic you requested'. So I went ahead and started digging into the issue and this opened up a whole can of worms that took me a couple of days to sort out and it was a nightmare -- rounding is just plain bad. What we were seeing on the report was a score of 93% and two scores would have values of say 92.75% and 92.50%. Now back from my school days using the basic arithmetic round that we all used we would say that these should both be rounded up to 93%, well that 'depends'. It turns out that there are quite a few methods of rounding and unfortunately the Microsoft products all differ in how they use the round function and I found a good article explaining that here. It turns out that in this case Banker's Rounding was implemented where if the value is at say .5 it will simply round to the nearest even number. And sure enough this is what was happening; here are some examples that show this (replace cube name with a valid cube name):

--this does not round 92.5 up to 93 as expected
with member measures.test1 as round(.923,2)
member measures.test2 as round(.925,2)
member measures.test3 as round(.927,2)
select {measures.test1, measures.test2, measures.test3} on columns
from [cube name]

This was not what we wanted, so now I was on a quest to resolve this. I thought I could just try and utilize the vbamdx.round call, but that returned the same thing. I went ahead and tried using the system.math.round call in .NET code to see what that returned to see if I could possibly just implement an SSAS stored procedure (functions are what I call them), but same thing. I opened up my trusty Excel and tried the round function in there and it worked the way I expected it to. I was like it is about time...so I thought I would simple use the excelmdx.round in my calculation, but it turns out you actually need to install Excel on the server (found reference to this in the MSDN forums here) for this to work and it will fire up an instance of the excel object when you use this. So this was not a solution either since we were not going to do that. I found another solution in the MSDN forums here that stated that you could just use the following logic -int(-(VALUE*100)) and sure it works for my .9250 value, but this logic is basically just returning the CEILING and this is not what I wanted for all of my values (like .9210 would display as 93 -- not what we wanted). What I ended up doing was implementing some crazy CASE logic that evaluated the value to determine if the last numeric value on the right was a 5 then use the CEILING function that I just listed, otherwise just go with the regular round function.

So now I was done, right? Wrong. Now we were still getting a few stores that were still not lining up where the report would show 93%, but what was being used by the Ranking was still 92%, so now what was the problem. It turns out the calculation was returning .9250, but it was actually .92499999, so why was the calculation returning .9250? I didn't have any type of formatting in the calculation, this was just a straight calculation returning the underlying value. This was driving me completely insane. How did I go about resolving this additional rounding issue, good question. I ended up doing the following: int(value*100000)/100000 and using this value instead of just value.

So now I was done, right? Wrong again. Now we were still seeing some incorrect values. This is what we ended up seeing and shows the different values returned by int and cint.

value = .57549

Incorrect calc: int(round(value),2)*100) = 57

Fixed calc: cint(round(value),2)*100) = 58

I went ahead and changed my references of int to cint and finally I had victory! I was actually done solving this crazy rounding issue. It wouldn't have been that bad if we were just rounding and displaying values; this could have basically been handled by using some formatting in the calculation, but when you need to actually use the result in a Ranking function it is a completely different story. I am really hoping that there was an easier solution for this, but being under the gun and needing this implemented by the deadline this is what I came up with. I was able to finally get a good night sleep.

SSAS returning wrong results (cache related)

Wed, 12 Dec 2007 01:30:51 GMT

Ran into a rather odd issue today. End-user reported that the chart being displayed to them was returning the wrong results and different filters were returning the same results. Here is the example of two queries that I used to validate the results and I was able to reproduce the issue:

SELECT NON EMPTY { { [Date].[Quarter Year].&[2007]&[3], [Date].[Quarter Year].&[2007]&[4], [Date].[Quarter Year].&[2008]&[1] } } ON COLUMNS,

NON EMPTY { Crossjoin({ [Brand].[Brand Label].[Brand1]}, { [Measures].[TBA], [Measures].[TBA(Base)] } ) } ON ROWS

FROM [cube] WHERE ( ( [Market].[Market].[USS] ), { [State].[State].&[Georgia], [State].[State].&[Florida], [State].[State].&[South Carolina] } )

AND

select {[Measures].[TBA], [Measures].[TBA(Base)]} on columns,

non empty([Brand].[Brand Label].[Brand1]) on rows

from cube where ([Market].[Market].&[USS], [Date].[Quarter Year].&[2007]&[3])

If I ran these queries in this order the results for 2007 Q3 were 56% and 1082. This was correct for the first one based on the WHERE clause, but not for the second MDX statement. I was really puzzled, but I decided to clear the cache and try again. This time I ran the queries in reverse order and I got the correct values (second query was 49.6% and 3312. I found a posting about setting the Cache Policy in the connection string to 9 or setting this at the server level in the msmdsrv.ini file (setting CalculationCoverPolicy to 9 instead of 0 which is the default). When I did this modification and restarted SSAS everything worked properly no matter which order I ran the MDX statements in. Really odd behavior still since both queries have different filters for the WHERE clause. Luckily I saw the Cache Policy setting in Mosha's posting and Chris Webb also had a similar posting about this type of issue. There was also a posting in the Microsoft Forums that I used for reference.

I tested this in SQL 2008 Nov CTP5 and similar results. When I ran them in this order the second query actually returned 151.9% instead of 56% even though the correct result was supposed to be 49.6%. The second value was the same in SQL 2005. The same fix to the msmdsrv.ini file fixes the issue though. I will have to make a call ticket with MS Support and make them aware of this bug. I will let you know if they tell me to make a different fix to resolve this issue.

UPDATE (12/19/2007):

Just wanted to provide an update in regards to this issue with the cache reuse in Analysis Services. I did test both these MDX statements in Mosha's MDX Studio and when the 2nd statement is executed it will only return the results from the cache and it will not perform any calculations. If you clear the cache and run them in the reverse order then it will perform the necessary calculations and everything is fine. Making the 'Cache Policy' setting change does resolve the issue and you can run the statements in either order.

MS Support got back to me and they did state that there is an issue with the cache reuse with the current product (and actually the next version of the product) and they have filed the issue with the development team. The interesting thing is that another way that they reported that this can be resolved was swapping out the function being used in one of the calculations. The current calculation is using the Aggregate function and they switched it to the Sum function and this fixed the problem also. Really odd since these are basically setup to do the same thing. They stated that it can be problematic using the Aggregate function to aggregate a calculated member.

In regards to the Cache Policy setting here is what they had to say:

The cache policy setting (9 instead of 0) you were using as a workaround is intended to change how the formula engine answers queries; it will cause the formula engine to lean towards using block evaluation mode more, instead of cell-by-cell mode. Generally, this can result in faster queries, but it can also slow down some queries, so there is a risk involved with it. Microsoft CSS does not usually recommend this setting as a general approach/resolution.

It’s usually a better idea to find ways to improve the queries without using cache policy; it should only be used as a last resort, and only under the direction of CSS. We generally do not make the details of the cache policy settings public, because they do carry risks, and they are intended only for special cases that should be determined by customer support.

Makes sense, but how would I have ever come to the conclusion that the issue was actually with the function we were using to perform the calculation? Extremely odd behavior if you ask me and this is pretty scary. Hopefully they will come up with a solution to resolve the incorrect cache reuse. How do I know that this is the only scenario that is going to return incorrect results?