Why is my transaction log full?
-
Thanks Gail for this great article!!!!
[font="Times New Roman"]rfr.ferrari[/font]
DBA - SQL Server 2008
MCITP | MCTS remember is live or suffer twice!
the period you fastest growing is the most difficult period of your life! -
Thanks Gail, please keep up the great knowledge transfer.
I agree with others, read what you (and Steve) write and you will be a great DBA.
Well it has helped me quite a bit.
Over 12yrs in IT and 10yrs happily stuck with SQL.
- SQL 2008/R2/2012/2014/2016/2017
- Oracle 8/9/10/11
- MySQL 4/5 and MariaDB -
Do you have replication going?
However, there was a bug in some versions of SQL 2005 that could result in a log reuse wait of Replication
This bug was also present in SQL 2008 R2 RTM. They apparently finally fixed it in the R2 SP1.
What will happen is that when replication refreshes itself, it sends down DDL commands to update, add, and change the syncobj% views as well as it's internal SP's. Those replications get hung, and everything behind it as well. It happens on a very inconsistent basis with a high stress on the servers and databases.
The true fix is get to at least the R2 SP1, and if running 2008 or 2005 get to the SP that came out at about the same time.
----------------
Jim P.A little bit of this and a little byte of that can cause bloatware.
-
Jim P. (8/31/2012)
Do you have replication going?However, there was a bug in some versions of SQL 2005 that could result in a log reuse wait of Replication
This bug was also present in SQL 2008 R2 RTM. They apparently finally fixed it in the R2 SP1.
What will happen is that when replication refreshes itself, it sends down DDL commands to update, add, and change the syncobj% views as well as it's internal SP's. Those replications get hung, and everything behind it as well. It happens on a very inconsistent basis with a high stress on the servers and databases.
The true fix is get to at least the R2 SP1, and if running 2008 or 2005 get to the SP that came out at about the same time.
Hey Jim, do you have a KB article I can look at so I can push to get SP1 installed in all of my environments... we are seeing this happening quite a bit and frankly its getting annoying to reset replication everytime.
Over 12yrs in IT and 10yrs happily stuck with SQL.
- SQL 2008/R2/2012/2014/2016/2017
- Oracle 8/9/10/11
- MySQL 4/5 and MariaDB -
The nearest I could find to it is the blog item that was cited in the article.
But if you look at the dates on the blog it was probably in the code base for SQL 2008 at least.
I think this is one where M$ had problems locating it and fixing it, and thought not many users had run into it. So they quietly just patched it.
----------------
Jim P.A little bit of this and a little byte of that can cause bloatware.
-
Great article Gail. Very well written and organized.
Kenneth FisherI was once offered a wizards hat but it got in the way of my dunce cap.--------------------------------------------------------------------------------For better, quicker answers on T-SQL questions, click on the following... http://www.sqlservercentral.com/articles/Best+Practices/61537/[/url]For better answers on performance questions, click on the following... http://www.sqlservercentral.com/articles/SQLServerCentral/66909/[/url]Link to my Blog Post --> www.SQLStudies.com[/url]
-
damn, a while a go I got this info together searching on various websites
this one definitely goes in my favourites for future reference
thanks for the clear explanation
Axel
-
Jim P. (8/31/2012)
The nearest I could find to it is the blog item that was cited in the article.But if you look at the dates on the blog it was probably in the code base for SQL 2008 at least.
I think this is one where M$ had problems locating it and fixing it, and thought not many users had run into it. So they quietly just patched it.
Thank you very much Jim!
We are now at least looking at patching. 😀
Over 12yrs in IT and 10yrs happily stuck with SQL.
- SQL 2008/R2/2012/2014/2016/2017
- Oracle 8/9/10/11
- MySQL 4/5 and MariaDB -
Wow, what great timing to repost this article. A customer of ours ran into this over the weekend. The cause in sys.databases appears to be ACTIVE_BACKUP_OR_RESTORE.
When I look at the maintenance plan history, his backups started taking 20+ hours to run. Beginning on 8/25/2012 we can see very long backup durations. The maintenance plan checks database integrity, deletes old backups, then runs a new backup. On 9/3/2012, the maintenance plan failed on the DBCC CHECKDB step with the following error:
Executing the query "DBCC CHECKDB(N'DPTS') WITH NO_INFOMSGS" failed with the following error: "The transaction log for database 'DPTS' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases
A database snapshot cannot be created because it failed to start.
The database snapshot for online checks could not be created. Either the reason is given in a previous error or one of the underlying volumes does not support sparse files or alternate streams. Attempting to get exclusive access to run checks offline.
The database could not be exclusively locked to perform the operation.
Check statement aborted. The database could not be checked as a database snapshot could not be created and the database or table could not be locked. See Books Online for details of when this behavior is expected and what workarounds exist. Also see previous errors for more details.
Could not write a checkpoint record in database ID 11 because the log is out of space. Contact the database administrator to truncate the log or allocate more space to the database log files.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
Not out of space on the physical disk. Recovery model is Simple. Any ideas where I should go next?
-
1. Please start new threads for new questions. Don't piggy back. People are not going to be diligent about reading replies in this thread.
2. What are the settings for the log file? Either the growth settings are too big for it to expand with the remaining disk space or the file is set to a size limit that it has reached.
My blog: SQL Soldier[/url]
SQL Server Best Practices: SQL Server Best Practices
Twitter: @SQLSoldier
My book: Pro SQL Server 2008 Mirroring[/url]
Microsoft Certified Master: SQL Server, Data Platform MVP
Database Engineer at BlueMountain Capital Management[/url] -
As you identified, the cause of the log being full is the active backup. The checkDB errors are all a result of the log being full, nothing else.
You need to identify why the backups are running so much longer than usual. Immediate thought - IO subsystem contention.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverabilityWe walk in the dark places no others will enter
We stand on the bridge and no one may pass -
Forgot to mention the tlog growth from the start as I was pretty sure that was also an issue. The log file growth was set to 10 % and the free space on the drive was about 10% of the entire drive. Obviously that's an issue. Changed that to 10 MB and am running another backup.
Gail, I think it's a combination of issues. I think they deleted a backup file that was still in progress. Is there any way to stop this backup operation that the sys.databases table thinks is still in progress?Correction: The backup failed b/c the tlog ran out of space 2 days ago. There is no backup run Sunday night/Monday morning. Then a backup attempted to run this morning with the previous backup showing as still active in sys.databases. Ugh what a mess.
-
I guess the question still is:
Is there any way to stop this backup operation that the sys.databases table thinks is still in progress?
A previous job was stopped and a job that followed that failed. It appears that SQL Server thinks the stopped job is still running. I can see no other indication of this other than ACTIVE_BACKUP_OR_RESTORE as the log_wait_reuse_desc in sys.databases. Even the location of the backup files is empty.
-
New thread please. The discussion thread of an article is not the best place for a problem that isn't directly related to the article.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverabilityWe walk in the dark places no others will enter
We stand on the bridge and no one may pass -
Hi Gail,
Can I please ask a quick question. In your article you say the following:
Log backup
The log backup wait reason will never appear in Simple Recovery.
Now I do agree this is a valid statement, however:
SELECT database_id,recovery_model_desc,
log_reuse_wait_desc
FROM sys.databases
WHERE log_reuse_wait_desc <> 'NOTHING'
database_id recovery_model_desc log_reuse_wait_desc
46 SIMPLE LOG_BACKUP
Why would I be seeing this?
Thanks
Viewing 15 posts - 61 through 75 (of 76 total)
You must be logged in to reply to this topic. Login to reply