July 26, 2002 at 10:49 am
Well. I'm sorry, but we have been testing some workarounds and we have found another way to temporary "solve" the problem.
I'm going to explain this.
If we use the <sp_recompile> SP for all tables in database, performance seems to become normal (same as down the service).
We think perhaps SQL Server uses their memory structures to construct execution plans depending on memory available. Because of this, forcing to recompile every SP restores normal performance.
We are now testing Index Tuning Wizard and other optimization tools searching for a index or table full scan bottleneck in some "situations", but we've found nothing strange yet.
We don't understand yet why this has happened only when we've upgraded memory (system has worked fine for almost 1 year).
Thank you very much for your support.
July 29, 2002 at 8:03 am
I have no explanation for this, but....
I've observed in some machines that when I upgraded the RAM they would slow down. The BIOS would display the correct amount of RAM and the OS would as well. However, performance didn't change at all or worsened. Eventually I threw up my hands and reinstalled the OS which resolved the problem. After that I just reinstalled the OS as a matter of procedure. This method worked for me because I dislike OEM loads and if it was an existing machine someone had probably junked it up anyway.
"I met Larry Niven at ConClave 27...AND I fixed his computer. How cool is that?"
(Memoirs of a geek)
July 30, 2002 at 8:48 am
We upgraded a 2x processor server to 4x processors and our cube processing times INCREASED by about 350%. After re-optimizing several queries, I was only able to reduce the time to little less than double that of the original, pre-upgrade times.
So much for throwing more hardware at performance problems!
July 30, 2002 at 11:27 am
Interesting. More hardware rarely fails to help in my experience. Were you able to determine why?
Andy
August 7, 2002 at 9:53 am
Nope, still have the same problem. I was able to tune the server and get the times down but basically it is still slower (for this particular query) than before with 2x processors. The query in particular is coming out of Analysis Services during the cube processing. It is a rather large query, hitting a 10 million row fact table (atually a 3 union view) joining with approx 15 dimension tables and returning all the data. Since it comes out of AS, I have no control over the query, I can only tune the back end. Both SQL and AS are running on the same server. I've tuned the query down to an acceptable time and have moved on.
August 8, 2002 at 5:50 pm
Josep;
Had the same problem, upgrading a NT4/SQL7 server from 128mb to 384mb. Found that when I increased the memory, the page file increase and became very fragmented. Now run PageDefrag from Sysinternals.com to defrag the pagefile at boot time, and schedule a forced restart once a week.
Mark
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply