December 30, 2008 at 3:04 pm
Hi Guys,
hopefully some of you can help me, I performed reorganize, and rebuild indexes, I give more disk space, I move the database on to a new server with a little more RAM (4GB) was on 2GB, but my database still running very slow, I also backup the logs, and shrink them...but the same.
OS: Win2003
SQL version: 2000
Please can anybody give me more suggestions?...I don't know what else to do...I also purchase the DMKit from IDERA, but nothing changed.
Any idea?
Thank you in advance.
December 30, 2008 at 7:03 pm
Can you define slow? Slow in what fashion? Inserts/updates/queries?
Is it general slowness, or at particular times?
How large are the databases and tables?
What's your disk subsystem, and how are the files arranged?
December 30, 2008 at 7:16 pm
Maybe you some processes that are blocking other processes ?? Hardware won't fix that. Do you see any blocking during slowness ?
December 31, 2008 at 9:04 am
The memory paging was slow, by when I try to input data in the database it was taking me for so long, I found the TrendMicro was taking more memory usage, so with just 4GB is not enough for 6 databases in the same server.
I already move out this database to another server, and it looks is moving a little faster.
However, I have a doubt, how can I perform a better tuning practices, to avoid this slowness in the future?
I am using SQL 2000.
Thanks a bunch!
January 10, 2009 at 5:09 am
Without knowing your specific configuration or performance issues, some quick rules of thumb.
- ensure that Trend Micro (or any AV for that matter) does not perform real-time scanning on *.mdf, *.ldf, *.ndf. If you can, manually exclude your database data and log directories
- place your database data files on different disks / spindles to your log files
- as appropriate, further split up your databases on separate disks / spindles instead of keeping them all on one disk / set of spindles
- enable SQL Server to address more RAM if required. on a 32bit system you will require AWE enabled. possibly PAE depending on your configuration
--
Andrew Hatfield
January 10, 2009 at 10:46 am
Great advice from Andrew, and if that doesn't work, the likely cause is that you need to tune your SQL more. Badly written code, or a lack of indexes, account for many performance issues.
January 10, 2009 at 11:46 pm
Was it ever fast? If so, what changed? If not, then it's probably the code.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply