March 6, 2012 at 8:28 am
I am seeing a lot of these errors in one of the database production servers:
Autogrow of file 'bridge_Log' in database 'Bridge' was cancelled by user or timed out after 842 milliseconds. Use ALTER DATABASE to set a smaller FILEGROWTH value for this file or to explicitly set a new file size.
Should something be done about this? We see these errors only in the mid night. I suspect some bulk inserts happening here?
March 6, 2012 at 8:33 am
Your autogrow is too large for the disk subsystem to complete. As the error says: "Use ALTER DATABASE to set a smaller FILEGROWTH value for this file or to explicitly set a new file size."
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
March 6, 2012 at 8:50 am
GilaMonster (3/6/2012)
Your autogrow is too large for the disk subsystem to complete. As the error says: "Use ALTER DATABASE to set a smaller FILEGROWTH value for this file or to explicitly set a new file size."
ANy major performance issue if this errors keep coming?
March 6, 2012 at 9:21 am
SQL trying and trying and retrying to grow the log and stopping any data modifications from running while it's trying to grow the log.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
March 6, 2012 at 9:24 am
GilaMonster (3/6/2012)
SQL trying and trying and retrying to grow the log and stopping any data modifications from running while it's trying to grow the log.
Let me put it this way:
Say a database is there with log file size of 10 GB..
I have auto growth set for 10% of the size..
Next increment of log growth will be 10% of 10GB right?
So, unless and until the database reaches 10GB, it wouldn't try to grow or expand?
March 6, 2012 at 9:31 am
Correct, but that message says that it was growing, and while the log is growing data modifications must wait.
10% is a poor autogrow setting. Set a fixed size in MB, small enough that you don't get timeouts, large enough that the log doesn't need to grow repeatedly
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
March 6, 2012 at 9:32 am
Sure..Thanks..
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply