Cubes process forever

So everything has been working fine for 2 months now. Last night some updates got installed. SQL service pack 2 being one of them and some standard windows updates. The server is still running Windows server 2003 service pack 1. I now can't process my cubes or deploy them. It's the only thing that has changed so I am taking it as an assumption. Is there any other reason for cubes to suddenly just sit in the processing state forever?

This is a big problem for me and I am hoping that installing Service pack 2 for the windows server will sort it out but if it doesn't I am pretty much lost. So if you have any ideas please let me know.

Thanks in advance guys

Regards

RyanN

Do you make full process? how meny partitions has your database in all cubes together?

I had a similar problem as your one.

It was solved through increasing of <ThreadPool><Process><MaxThreads>

|||

I can't answer your question but I have a similar problem. My processing doesn't take forever, but at least much longer with SP2 (see thread http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1472639&SiteID=1). I was thinking that maybe SP2 use (much) more memory than SP1, and therefore slows down my processing (or in fact all steps in our ETL process). I gonna set up perfmon to monitor memory, cpu and disks.

Vladimir: Was this after you installed SP2? Does <ThreadPool><Process><MaxThreads> apply to SQL Server Standard aswell?

|||

Thanks, this is one partition. If I create a new cube it deploys and processes perfectly, maybe there is something wrong with the cube database, I don't actually know. But I am sure there is a solution out there. I will definitely post it once I have found it.

Thanks for your help guys. I am definitely exploring all the suggestions posted to me.

|||Well for those of you who want to know. I uninstalled and re-installed, went onto sp1 with all the hotfixes and it works perfectly now. I am going to set up a test environment and try duplicate the scenario and see what went wrong where. It doesn't seem to be too common, so I will se what went wrong|||

Hi RyanN,

Something I did was to replace the named queries in the DSV, with index queries ("materialized queries") at the database level. This helps because the DB "precalculates" and actual stores / caches the views resultset, meaning that when the DSV references that indexed query, that there's no "heavy lifting" for the DB to do, so processing is quicker. However, if the named query in your DSV is already pretty basic, and the tables it's referencing are appropriately linked, this approach probably won't buy you much benefit.

HTH

Greg Withers

|||

Sorry - my preceding reply to RyanN should have said

"and if the tables are appropriately indexed"

|||

Hi HappyCow

Sure, the problem came with SP2 on x86. But on x64 it was on SP1 too.

I can't answer you regardin Std. edition. I use the Enterprise only.

|||Nope, can't believe that installing a new service should make me have to change the design of my cubes and cause me work at all. If anything it should make things more optimal. I am going to duplicate the steps I took and how the cubes reacted. This should never have happened.