query plan caching?

SQL Server has the concept of caching the query plan. Parameterized queries can take advantage of this feature.

I'm wondering if there's an equivalent feature in SSAS. If I use MDX parameters (i.e. using @.Param in the query and setting the Parameters object of the AdomdCommand object) and run the same query twice with similar parameter values, will SSAS be able to reuse the query plan at all?

What I'm wondering is whether it is better (a) to use parameters and then StrToSet to convert those parameters into MDX objects... OR (b) to just run dynamic MDX with no parameters. (Yes, I'm referring to how Reporting Services does MDX queries. Wondering if it would be worth suggesting to the SSRS team that they take the parameter values and build dynamic MDX instead of using MDX parameters.)

There is no equivalent for cached query plans in the SSAS 2005 version.

> What I'm wondering is whether it is better (a) to use parameters and then StrToSet to convert those parameters into MDX objects... OR (b) to just run dynamic MDX with no parameters.

In SSAS 2005, building MDX on the fly is always better than using StrToSet and parameters.

|||

Thanks Mosha. That answered my question. I reported this as a suggestion for Katmai SSRS:

https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=263472

|||I diagree that this is SSRS issue. SSRS is absolutely correct using StrToSet( @.param, CONSTRAINED ) for many reason, one being security. This should be reported as suggestion for Katmai SSAS - to optimize StrToXXX( , CONSTRAINED) family of functions.

Query Notification stops working after 10 minutes

Hi All

We built a Cache component that take advantage of the SQL Server 2005 query notification mechanism, all went well , we tested the component in a console application , and notifications kept coming for as long time as the console application ran.

When we initiate our Cache Component in our web service global.asx application start event , the query notification works for a few minutes , but if we came after 10 minutes or so , we stoped getting notifications from sql, the SQL Server queue is empty , and all is showing that there is nothing wrong on the DB side...

Our Cache component is a Singleton class , that perform all registrations ,catch the notification events and resubscribe for notifications.

What can be the problem? is our Cache component object are being collected by GC?

Does IIS disposes the SQL Connection that the Query notification uses?

We are on a crisis...

Thanks in advance.

It sounds like there's something wrong with your server logic so this probably isn't the right newsgroup to ask. check the sys.dm_qn_subscriptions view to see if there is a subscription active. If not, then your service logic didn't create a new subscription after processing a notification. If it all worked in your test setup you might have an issue with re-entrancy in your component so maybe a lock is required to handle two notifications coming in so close together that only one suscription is registered.|||Could be the issue described in KB 913364: http://support.microsoft.com/Default.aspx?kbid=913364

HTH,
~ Remus|||

I dont see how can this be a problem on the server logic...

I am running the same code in my Console application and in my web application , the context is the difference.

I ran a check to see if the Cache object is disposed , and it doesnt, meaning the Cache component is alive , but notifications are not coming after 10 minutes,

I'll download the fix in the KB , and try it tomorrow morning...I hope this would do the trick.

Eden

|||

Well , Remus, you are right...

The FIX that i've installed on my station solved the problem (I Hope)

Notification events are coming after several hours without any problems...

Just to be sure I'll test it with a few days delay to see if every thing is ok....

I think that my issue is a big bug , and microsoft should publish it approprietly appropriately,

It took my several days to get to this forum , and to Remus answer,

Anyhow , thanks to all of you.