Post reply

Database running very slow

  • December 30, 2008 at 3:04 pm

    #94626

    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

    #919397

    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?


    Shamless self promotion - read my blog http://sirsql.net

  • December 30, 2008 at 7:16 pm

    #919401

    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

    #919705

    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

    #924810

    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

    #924843

    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.

    Follow me on Twitter: http://www.twitter.com/way0utwest
    Forum Etiquette: How to post data/code on a forum to get the best help
    My Blog: www.voiceofthedba.com

  • January 10, 2009 at 11:46 pm

    #924957

    Was it ever fast? If so, what changed? If not, then it's probably the code.

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".
    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply