increase of memory in sql server 2000 fro 2 to 6GB measure memory usage

HI,

I have increase the memory of my sql server 2000 SP3 from 2GB to 6GB due to high disk usage.

Can you explain why, even with my smaler memory i had a cache hit ratio of 100% but disk que lenth of more than 2000?

With adding more memory, the disk queu length has decreasedbut the % disk busy remains very high.

We have a IBM blade server with a disk attached to the EMC san
dababase size is:
1 of 69GB
1 of 69gb
1 of 19gb
1 of 8gb

How can i check if i have to much or to little memory?

/attached is a report of my memory and disk usage (The swap has been done on  02 july at 10 AM
20090703-4-.pdf
20090703-7-dbs05diskactivity.pdf
capsugelAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Racim BOUDJAKDJIDatabase Architect - Dba - Data ScientistCommented:
<<With adding more memory, the disk queu length has decreasedbut the % disk busy remains very high.>>

That is because the increase memory has allowed the server to run more queries and therefore request more data from the disk.  I'd say that your server works better because it actually processes more concurrent requests but this had a bad impact on IO contention.  I'd suggest revising your file/filegroup strategy to get rid of that contention.
0
Racim BOUDJAKDJIDatabase Architect - Dba - Data ScientistCommented:
Please indicate the size of the database on which queries are ran.
0
capsugelAuthor Commented:
Ok thanks just a few little questions to understand it better,

where exactly can i check the concurrent requests?

And why is it that the disk queue length is much less?

Why don't i see a difference to the cache hit ratio % (if it is above 90% doesn't it mean it runs totaly in the ram and not on disk?)

0
capsugelAuthor Commented:
It is a database of +- 96GB and 1 of +-69GB

Is it also normal that the SQL recompilations went up from +-100 pro minute to +-400 pro minute
0
Racim BOUDJAKDJIDatabase Architect - Dba - Data ScientistCommented:
<<where exactly can i check the concurrent requests?>>
Based on how the code is submitted, you can look at the number of transactions/sec

<<And why is it that the disk queue length is much less?>>
The disk queue length is less for the requests that are actually *processed* not all the one in line waiting to be processed.  The real bottleneck here is purely IO related.  Or at least it seems.

<<SQL recompilations went up from +-100 pro minute to +-400 pro minute>>
We can assume that since the number of executions increased the number of recompilation increased as well.  That confirms that the server *does* actually execute 4 times more queries but it's just that the IO does not cope anymore.

Clearly an IO problem.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SQL Server

From novice to tech pro — start learning today.