Path: csiph.com!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Erland Sommarskog Newsgroups: comp.databases.ms-sqlserver Subject: Re: Transaction Log Backup Failing as Deadlock Victim Date: Tue, 28 Jan 2014 22:55:13 +0100 Organization: Erland Sommarskog Lines: 26 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Injection-Info: mx05.eternal-september.org; posting-host="fd3d6d0229f14a752f017d8f9903addd"; logging-data="25556"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18JIkogTtFWDjqTIFmJIOHf" User-Agent: Xnews/2006.08.24 Mime-proxy/2.1.c.0 (Win32) Cancel-Lock: sha1:Fr4+zij12GBLf0oY1rqtDUk7JBs= Xref: csiph.com comp.databases.ms-sqlserver:1646 Mark D Powell (Mark.Powell2@hp.com) writes: > Recently my 64 bit SQL Server 2008 R2 RTM Enterprise Edition failover > cluster running under Windows 2008 R2, the transaction log backup job > has begun to fail every now and then with "was deadlocked on lock > resources with another process and has been chosen as the deadlock > victim" Thirty minutes later when the next set of log backups run the > task will run fine. > > This server is overdue to be migrated to a new cluster where it will can > be patched, but I was wondering if anyone has seen this and knows of an > article on the subject. Supposedly, it is not the T-LOG backup itself that fails, but what fails is when the log backup is recorded in msdb, which is not known for its optimal indexing. This blog post with a script from my fellow MVP Geoff Hiten should help you. You should be able to deduce this from the error message, as it says something like "the log backup itself was succesful". Of course, if the entry is not written to msdb, this will make things a little more difficult if you need to restore after a disaster. -- Erland Sommarskog, Stockholm, esquel@sommarskog.se