June 23, 2006 at 4:21 pm
I can't seem to find anything on this error message….
2006-06-23 04:03:10.29 spid51 SysThread 0x7FF96E38 woken up prematurely
2006-06-23 04:03:10.29 Server SysThread 0x7FF93E38 woken up prematurely
.
.
.
2006-06-23 08:46:44.28 Server SysThread 0x7FF98E38 woken up prematurely
2006-06-23 08:46:44.28 Server SysThread 0x7FF98E38 woken up prematurely
We are running SS2K5, SP1 on Windows Server 2003, SP1 with 4GB of RAM. This is a development / staging environment, so we also have a SS2K, SP4 server on this box. We use Idera's SQLSafe 3.0 for backups. BTW, the backups continued during this time w/out issue.
The SQL Server ErrorLog file grew to 30GB in 4.5 hours. We finally had to reboot the server to access it again. I moved the error log to another drive so we would have space again.
There were no entries in the Event Logs related to these messages, except around 6AM, when we started receiving messages that we were low on Disk Space on the C: drive.
I would like to understand what happened and, hopefully prevent it from happening again. Thankfully, this was not a production server J
Leda E. Behseresht
June 26, 2006 at 8:00 am
This was removed by the editor as SPAM
July 30, 2007 at 12:24 am
we encountered the same error on sql server 2005 x64 sp2. Error log grew to 12gb.
Service was restarted
July 30, 2007 at 12:24 am
we encountered the same error on sql server 2005 x64 sp2. Error log grew to 12gb.
Service was restarted
July 30, 2007 at 3:10 am
Wanted to know if AUTOGROW option is enabled ??
check this KB http://support.microsoft.com/kb/317375/en-us
Minaz
"More Green More Oxygen !! Plant a tree today"
July 31, 2007 at 9:02 am
Yes all databases are enabled to auto grow.
August 16, 2007 at 4:59 pm
I'm not longer managing the installation mentioned in the original post, but to be clear...
AUTOGROW was enabled on all databases for that instance.
The issue I experienced was that the Server ERRORLOG (default location = C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\ERRORLOG) grew over 30GB. Because the Server errorlogs were on the C: drive, the server ceased to operate. After the incident the logs were moved to another drive, but the issue occurred a few more times, but not as severe.
This KB article seems to be specific to the TRANSACTION LOG. All database transaction logs were fine.
August 17, 2007 at 6:30 am
I find it interesting that either spid51 or SYSTEM was the user. was it predominantly SYSTEM? or was just the first instance spid51? That may be a hint. Also, was there much in the way of 'ancillary' activity going on when it started? Either in the way of maintenance jobs, or replication, or bcp, or any such? It seems to me, given the infrequent occurrence, that it will take identifying a rare combination of events to trigger this message. Knowing the whole environment may be relevant (but I'm not asking for a full description).
December 31, 2007 at 1:17 pm
I just encountered this error. Similar to previous posts, the errorlog grew dramatically (> 16GB) and SQL Server stopped accepting connections. I also am running SQLSafe for db backups. However, once this error occurred, the very next tran log backup (just milliseconds later) became the first process unable to obtain a connection to SQL Server. Then nothing could obtain a connection until SQL Server was restarted. Hoping someone has a reason why this occurred. It was production.
February 14, 2008 at 1:02 pm
Has anyone heard back on this?
We just had this happen on a Enterprise Edition (64-bit) on Windows NT 5.2 (Build 3790: Service Pack 2)
We were processnig a cube at the time.
February 15, 2008 at 6:53 pm
We are also running sql Safe. PRocess could not backup as well.
August 12, 2008 at 7:49 am
[font="Tahoma"]
Hi, we experienced this similar problem on a SQL SERVER 2005 environment. This error started and created a 30 GB log file in a 30 minute span. It took all the available worker threads and there was no choice but to restart. The databases are set to autogrow.
It is not clear what caused the problem. Has anyone found anything on what can cause this?
thanks
[/font]
August 12, 2008 at 2:49 pm
We found that this problem is often found when the database is set to autogrow. The root of the problem is when the database becomes too big and it needs to expand. Depending on the size of the database this can takes several minutes. Client connections start to time out and the number of locks continue to grow.
The solution is to disable autogrow. Have a monitor that indicates when to expand the database, so it can be scheduled during the next maintenance time.
I hope this helps others.
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply