Showing posts with label timed. Show all posts
Showing posts with label timed. Show all posts

Friday, February 24, 2012

Autogrow of log

I get this info message in my NT log:
Autogrow of file 'w2publish_Log' in database 'w2publish' was cancelled
by user or timed out after 546 milliseconds. Use ALTER DATABASE to
set a smaller FILEGROWTH value for this file or to explicitly set a
new file size.
This database is set to autogrow by 10%.
Searching the net, a few have suggested increasing the 10% to a larger
value. But it seems that the error is SQL Server failing to grow the
file in a timely manner. So moving from 10% to larger number will
only make matters worse. If I set it to a fixed size, what if that is
not enough?
What is the correct approach?
You don't want to set it larger you want to change it to a fixed size that
you know will grow in well under the timeout period. Once the files get
beyond 100MB or so you should change it to a fixed size of growth.
Andrew J. Kelly SQL MVP
"pbx" <pbeisel@.gmail.com> wrote in message
news:1183851948.581194.56800@.i38g2000prf.googlegro ups.com...
> I get this info message in my NT log:
> Autogrow of file 'w2publish_Log' in database 'w2publish' was cancelled
> by user or timed out after 546 milliseconds. Use ALTER DATABASE to
> set a smaller FILEGROWTH value for this file or to explicitly set a
> new file size.
> This database is set to autogrow by 10%.
> Searching the net, a few have suggested increasing the 10% to a larger
> value. But it seems that the error is SQL Server failing to grow the
> file in a timely manner. So moving from 10% to larger number will
> only make matters worse. If I set it to a fixed size, what if that is
> not enough?
> What is the correct approach?
>
|||Monitor how your database files grow. This will give you an idea on what
value to specify for autogrow increments. This is critical especially when
the files are very big (imagine 10% autogrow increments for 100GB database
files)
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:%237Qq9gQwHHA.4640@.TK2MSFTNGP03.phx.gbl...
> You don't want to set it larger you want to change it to a fixed size that
> you know will grow in well under the timeout period. Once the files get
> beyond 100MB or so you should change it to a fixed size of growth.
> --
> Andrew J. Kelly SQL MVP
> "pbx" <pbeisel@.gmail.com> wrote in message
> news:1183851948.581194.56800@.i38g2000prf.googlegro ups.com...
>

Autogrow of log

I get this info message in my NT log:
Autogrow of file 'w2publish_Log' in database 'w2publish' was cancelled
by user or timed out after 546 milliseconds. Use ALTER DATABASE to
set a smaller FILEGROWTH value for this file or to explicitly set a
new file size.
This database is set to autogrow by 10%.
Searching the net, a few have suggested increasing the 10% to a larger
value. But it seems that the error is SQL Server failing to grow the
file in a timely manner. So moving from 10% to larger number will
only make matters worse. If I set it to a fixed size, what if that is
not enough?
What is the correct approach?You don't want to set it larger you want to change it to a fixed size that
you know will grow in well under the timeout period. Once the files get
beyond 100MB or so you should change it to a fixed size of growth.
Andrew J. Kelly SQL MVP
"pbx" <pbeisel@.gmail.com> wrote in message
news:1183851948.581194.56800@.i38g2000prf.googlegroups.com...
> I get this info message in my NT log:
> Autogrow of file 'w2publish_Log' in database 'w2publish' was cancelled
> by user or timed out after 546 milliseconds. Use ALTER DATABASE to
> set a smaller FILEGROWTH value for this file or to explicitly set a
> new file size.
> This database is set to autogrow by 10%.
> Searching the net, a few have suggested increasing the 10% to a larger
> value. But it seems that the error is SQL Server failing to grow the
> file in a timely manner. So moving from 10% to larger number will
> only make matters worse. If I set it to a fixed size, what if that is
> not enough?
> What is the correct approach?
>|||Monitor how your database files grow. This will give you an idea on what
value to specify for autogrow increments. This is critical especially when
the files are very big (imagine 10% autogrow increments for 100GB database
files)
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:%237Qq9gQwHHA.4640@.TK2MSFTNGP03.phx.gbl...
> You don't want to set it larger you want to change it to a fixed size that
> you know will grow in well under the timeout period. Once the files get
> beyond 100MB or so you should change it to a fixed size of growth.
> --
> Andrew J. Kelly SQL MVP
> "pbx" <pbeisel@.gmail.com> wrote in message
> news:1183851948.581194.56800@.i38g2000prf.googlegroups.com...
>

Autogrow of log

I get this info message in my NT log:
Autogrow of file 'w2publish_Log' in database 'w2publish' was cancelled
by user or timed out after 546 milliseconds. Use ALTER DATABASE to
set a smaller FILEGROWTH value for this file or to explicitly set a
new file size.
This database is set to autogrow by 10%.
Searching the net, a few have suggested increasing the 10% to a larger
value. But it seems that the error is SQL Server failing to grow the
file in a timely manner. So moving from 10% to larger number will
only make matters worse. If I set it to a fixed size, what if that is
not enough?
What is the correct approach?You don't want to set it larger you want to change it to a fixed size that
you know will grow in well under the timeout period. Once the files get
beyond 100MB or so you should change it to a fixed size of growth.
--
Andrew J. Kelly SQL MVP
"pbx" <pbeisel@.gmail.com> wrote in message
news:1183851948.581194.56800@.i38g2000prf.googlegroups.com...
> I get this info message in my NT log:
> Autogrow of file 'w2publish_Log' in database 'w2publish' was cancelled
> by user or timed out after 546 milliseconds. Use ALTER DATABASE to
> set a smaller FILEGROWTH value for this file or to explicitly set a
> new file size.
> This database is set to autogrow by 10%.
> Searching the net, a few have suggested increasing the 10% to a larger
> value. But it seems that the error is SQL Server failing to grow the
> file in a timely manner. So moving from 10% to larger number will
> only make matters worse. If I set it to a fixed size, what if that is
> not enough?
> What is the correct approach?
>|||Monitor how your database files grow. This will give you an idea on what
value to specify for autogrow increments. This is critical especially when
the files are very big (imagine 10% autogrow increments for 100GB database
files)
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:%237Qq9gQwHHA.4640@.TK2MSFTNGP03.phx.gbl...
> You don't want to set it larger you want to change it to a fixed size that
> you know will grow in well under the timeout period. Once the files get
> beyond 100MB or so you should change it to a fixed size of growth.
> --
> Andrew J. Kelly SQL MVP
> "pbx" <pbeisel@.gmail.com> wrote in message
> news:1183851948.581194.56800@.i38g2000prf.googlegroups.com...
>> I get this info message in my NT log:
>> Autogrow of file 'w2publish_Log' in database 'w2publish' was cancelled
>> by user or timed out after 546 milliseconds. Use ALTER DATABASE to
>> set a smaller FILEGROWTH value for this file or to explicitly set a
>> new file size.
>> This database is set to autogrow by 10%.
>> Searching the net, a few have suggested increasing the 10% to a larger
>> value. But it seems that the error is SQL Server failing to grow the
>> file in a timely manner. So moving from 10% to larger number will
>> only make matters worse. If I set it to a fixed size, what if that is
>> not enough?
>> What is the correct approach?
>

Autogrow of file FORMS in database FORMS cancelled or timed out after 30547 ms.

Afternoon

I'm getting the below error message:

Autogrow of file 'FORMS' in database 'FORMS' cancelled or timed out after 30547 ms. Use ALTER DATABASE to set a smaller FILEGROWTH or to set a new size.

FORMS.LDF file is 7613952 KB and the growth is 512MB .

By how much should I set the filegrowth? The users are complaining that the application is freezing on them.

This is sqlserver 2000.Have you checked to see if the disk that the LDF file on has enough space left to grow? Is your databse in full recovery mode without a tran log backup EVER taking place? Do you need it in full recovery mode, or will simple do? Do you have a long running transaction filling up the log file?|||hi

There is nearly 2GB of free space on the server and the database is set to full recovery mode as it needs to be. There is only 1 transcation log being created and it's filling up day by day. Currently the users are unable to login.|||Are you doing transaction log backups?|||I changed the recovery model to simple and it managed to free up some space, I then changed it back to full and limited the space. All seem's to be working.|||With the database in full recovery mode, you will have to do periodic log backups in order to allow sqsl server to truncate and reuse log file segments.

If you do not institute tran log backups, you will run into the same problem as you had when you started this exercise ... the log file will fill up, autogrow, and continue until there is no more disk space for it to grow.

BTW ... I hope you did a full database backup after you did the change to simple and back to full, because you lost the ability to restore to a point in time with transaction log backups ... oh that's right ... you aren't doing log backups. So you will have lost all changes since your last full backup.

For a database in full recovery mode, best practice is to do a full backup periodically, and transaction log backups on a regular basis until you do another full backup. That helps keep the transaction log from growing out of control, and allows you to restore to a point in time if neccessary.|||Yes I did a full database backup after I made the changes.

I have not lost any data the last database backup was done last night as the database and the server gets backed up every night. The users have not made any changes for the past 5 days.

I will def look into a long term fix for this.