A deep dive into Virtual Log Files that make up a SQL Server log file. It also shows the effects of auto growth and the size of the individual VLF\'s on performance.
14. SQL Server uses a write-ahead log, this guarantees that no data modifications is written to the disk before the associated log record is written to disk. This maintains the ACID properties of a transaction. So this is how it works: How does it work?
15. Unlike TempDB which benefits from having multiple data files, the T-Log does not; it only serves as redundancy. The T-Log is written to sequentially and in a round-robin fashion. Example; you create 3 T-logs for a database: One or many, does it matter? T1 T2 T3
16. The T-Log is one of the things we overlook to optimize. Yes, put the log on separate SAN or SSD’s in a RAID 1+0 or 0+1 and give it a 100MB growth rate because that is better than 1MB. But why does 100MB perform better than 1MB? Do we ever look at how VLF’s affect our performance? Short answer; No. Can the T-Log be optimized?
21. Note that SQL 2005, 2008 and 2008 R2 has a bug where growing the T-Log in increments exactly 4Gb/8GB increments fail. It is best to grow the T-Log by 8000MB. This bug is fixed in SQL 11 which I’ll be using in the demo.VLF’s
23. So how do we look at the VLF’s? We use the following command: DBCC LOGINFO(DB_NAME) This command is undocumented but is safe to run as it only reads the T-Log. Important columns to look for is the following: FileSize – VLF size in bytes Status – 0 Not in use, 2 In use CreateLSN – This can be used to determine how many VLF’s was created in a log file growth, 4, 8 or 16. This also indicates the Log Sequence Number. VLF Usage
26. The log file is not Pandora’s Box. Monitoring, and optimizing the log file does have its benefits: Faster query execution. Faster indexing. Summary
27. The following sites provide useful info on T-Logs and VLF’s: Both Paul and Kimberly has more in-depth articles on T-Log internals. http://www.sqlskills.com/blogs.asp T-Log architecture. http://msdn.microsoft.com/en-us/library/ms179355.aspx Resources
Notes de l'éditeur
Modifications are made to a copy of the page in the buffer cache.Modifications are not written to disk until a checkpoint occurs, or the modification is made to disk when the buffer needs to hold a new page.Pages modified in the buffer cache, but not yet written to disk is called dirty pages.When a modification occurs on a page in the buffer cache, the associated log record is built in the log cache.The log must be written to disk before the dirty page is written to disk.If a dirty page is flushed before the log record is written, the modification made cannot be rolled back if the server fails before the log is written to disk.
T1, T2 and T3.T1 will be written to and filled before moving to T2.When writes happen to T2, and T1 clears, then all new transactions will start again in T1.This is because a T-Log consist of multiple Virtual Log Files which gets filled (and created) sequentially. More on that later.