1

I have a production MS SQL Server 2005 DB that I have recently become an "unintentional DB Admin" for... while poking around the settings for the DB I found that it has the default AutoGrow settings of 1MB. I've read (and generally believe) that this is not an appropriate setting - the DB is 14GB large. I'm willing (and likely) to change it, but my question is... If no one noticed it in all of the years we've been using it (especially users), why should I change it now? To put it another way, I guess I understand on a basic level why 1MB is too small - it's probably autogrowing often, perhaps daily or several times a day - but I'm thinking "if it ain't broke, don't fix it".

What specific justifications are there to increase the autogrow? Does it lock users out while autogrowing? Does it re-index? Does the DB do anything besides just add more disk space to the DB?

1
  • I wouldn't exactly subscribe to the ain't broke don't fix it motto in IT. A lot of things can be done badly and still "work". You were right to look into this as a lot of the time people ignore all of these little problems until they end up with a giant mess.
    – Shane
    Jul 28, 2010 at 14:10

4 Answers 4

3

Here's a great MS KB article on the topic, which covers all of the potential performance issues: Considerations for the "autogrow" and "autoshrink" settings in SQL Server

I've never seen the default value being 1 MB, though. I believe that the default setting is actually 10%. [Edited per comment by GregD]

1
  • 1
    Default value for the transaction logs is 10% and the data file is 1MB.
    – GregD
    Oct 12, 2009 at 15:08
2

That's not really what autogrowth is for. Autogrowth is a safety valve, so that the database doesn't explode when some unusual growth happens. You'd be better off running a nightly maintenance job to determine if the database will need to grow during that day, and resizing if necessary.

The biggest headache I see is with transaction logs; if you have a big transaction, and it outstrips the size of the transaction log for your database, it's going to delay the heck out of your transaction. Likewise if you're doing a massive insert or something, it's going to slow that down dramatically as well (because it's growing the database as it goes along).

0

It's really hard to answer this question because the answers will be as varied as the people here and we have no idea what your current performance is now.

How is your performance currently?

Autogrowth can impact your users. Frequent autogrowth can frequently impact your users.

How big are your current transaction logs?

Depending on how big your transaction logs are, setting the autogrowth size as a percentage, instead of a fixed growth, can impact your users.

Autogrowth is not a replacement for proper capacity planning.

0

I have heard that when you autogrow in small portions (1 Mb) that the database becomes fragmented which will adversely affect the performance.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .