Post reply

need help

  • March 10, 2008 at 9:37 am

    #128291

    i am getting this message after i run dbcc checkdb every monday

    WARNING: EC 787020c0, 1 waited 300 sec. on latch 431bde14, class FGCB_ALLOC. Not a BUF latch..

    Waiting for type 0x3, current count 0xa, current owning EC 0x459060C0

    Autogrow of file 'DCO_Data' in database 'DCO' took 308922 milliseconds. Consider using ALTER DATABASE to set a smaller FILEGROWTH for this file.

    Autogrow of file PPNDat.mdf' in database 'PPN' took 569890 milliseconds. Consider using ALTER DATABASE to set a smaller FILEGROWTH for this file.

    Thanks

    Sam

  • March 10, 2008 at 10:02 am

    #787461

    Hi Sam,

    What growth size have you configured your files to grow by? How many disk support your files?

    Thanks,

    Phillip Cox

    MCITP - DBAdmin

  • March 10, 2008 at 10:27 am

    #787480

    10% auto grow and i have one physical disk

  • March 10, 2008 at 10:36 am

    #787484

    sam (3/10/2008)

    10% auto grow and i have one physical disk

    Hi Sam,

    Ok, you may want to consider pre-allocating your anticipated space in advance to prevent auto-growth, as the growth requirement for your database does not have enough disk I/O and is taking some time to complete. If you do try this approach, you will need to switch auto-growth off and monitor disk space using an alert to ensure you do not run out of space. The other option is to get more disk to support your database I/O requirements.

    What size is your database, out of curiosity?

    Thanks,

    Phillip Cox

    MCITP - DBAdmin

  • March 10, 2008 at 10:36 am

    #787485

    Sam -

    this is one of those times when the error message is actually telling you something accurate. The advice is to change your growth factor to a fixed amount as opposed to a percentage. It's telling you it takes too long to grow the file based on the 10%.

    Now - you have two avenues of attack (you can do both by the way):

    - change the growth to a fixed amount of space - say 500MB.

    - find a quiet time, and manually grow the file by a LOT so that the auto-grow doesn't kick in.

    I'd strongly recommend you do both if you can. Auto-growth should only be there in case you miss it, but should not be the "default way" to grow SQL files. For one thing - it will always seem to happen at the worse possible time (i.e. when the server is busy); it also tends to create OS-level file fragmentation (never a great thing).

    Since you're on 2005, if you find that those errors are based on data files auto-growing, you may consider turning on Instant File Initialization, which will make growing files a lot less painful. Here's the good and the ugly about Instant File Initialization:

    http://msdn2.microsoft.com/en-us/library/ms175935.aspx

    I think the "security flaw" mentioned is WAY overplayed, but that's my take on it. Anyway - take a quick read - maybe it will work for you.

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • March 10, 2008 at 10:51 am

    #787492

    database size id 12.5gb

    Thanks for the answer

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

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