Paul Randal republishes an older post that is no longer available:
All through my career as a data professional, both inside Microsoft and as a consultant, I’ve found that one of the most misunderstood parts of SQL Server is the transaction log. Lack of knowledge of how the transaction log works and needs to be managed, or just simple misconceptions, can lead to all kinds of production problems, including:
- The transaction log growing out-of-control and potentially running out of space
- Performance issues from repeated shrinking of the transaction log
- Performance issues from a problem known as VLF fragmentation, which I discussed in this post
- The inability to recover to a desired point in time using transaction log backups
- The inability to perform a tail-log backup during disaster recovery (see here for an explanation of tail-log backups)
- Various issues around failovers and restore performance
With this post I’m starting an occasional series (now here on my SQLskills blog) on the transaction log and how it works and should be managed, and I’ll touch on all the problems above over its course. In this post I’ll explain what logging is and why it’s required.
Read on for that explanation.
Leave a Comment