Link to home
Start Free TrialLog in
Avatar of TrialUser
TrialUserFlag for Afghanistan

asked on

Error in SQL log about 'autogrow of file '_log' cancelled or timedout.

I have the folloing error in the SQL log.  What does this mean and how can this error be fixed? Thanks in advance.

autogrow of file 'dbname_log' in database 'dbname' was cancelled by user or timed out after 30123 milliseconds. Use ALTER DATABASE to set a smaller FILEGROWTH value for this file or to explicitly set a new file size.
ASKER CERTIFIED SOLUTION
Avatar of Guy Hengel [angelIII / a3]
Guy Hengel [angelIII / a3]
Flag of Luxembourg image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
This appears to be a similar issue, it may be of interest to you.
http://stackoverflow.com/questions/3554592/sql-server-2008-log-autogrow-cancelled-by-user-or-timed-out

Text from site ref.'d above (verbatim)
"I would imagine that you have the filegrowth percentage too high. Try reducing it down to 10%-15%. Seconds thoughts depending on the size of your Log file you should maybe change it to increase by MB size rather than %.

If your Log file is 10GB then a 10% increase is quite a lot of work for SQLServer to do.

Also, check that the disk the log file resides on has plenty of space free.

To change the AutoGrowth property:
 1.Right click on the database.
 2.Go to Properties.
 3.Then go to the Files section.
 4.Click on either the data or log autogrowth column (Click the ...)
 
I would also read this article to help you decide on whether you need AutoGrow enabled. Do you even need the transaction log - could you switch your Database to simple mode?"
First, add some space to the log so the db can function:

USE dbname
EXEC sp_helpfile

--see now much space the log has, then add 30MB (say) to that

ALTER DATABASE dbname
MODIFY FILE ( NAME = dbname_log, SIZE = <size_above_plus_30_mb>, FILEGROWTH = 30MB )

Never use a % as a growth amount, instead use a fixed amount.  Partly because based on my experience it takes SQL longer to process a % value, and because, if the db grows a lot, a % can be way too big.  For example, if the log grew to 100GB, 10% would be 10GB!