![[object Object],Managing large SQL environment. Large scale migrations, consolidated environments. Performance Tuning and Optimization. ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Microsoft SQL Server Log Management
Similar a Microsoft SQL Server Log Management (20)
Microsoft SQL Server Log Management
- 1. Microsoft SQL Server: The Transaction Log and why you should care about VLF’s Level 400 Presented By: Stephan Lawson SQL DBA
- 3. Blogger at lessthandot.comSQLArcher About Me
- 5. One or many, does it make a difference?
- 6. Can the T-Log be optimized? Diving into the colourful world of Virtual Log Files.
- 7. Demo
- 10. Start and end of each transaction.
- 11. Every data modification(insert, update, delete) including system SP’s, DDL statements to any table including system tables.
- 12. Every extent and page allocation and de-allocation.
- 13. Creating or dropping tables and indexes.What is a transaction log?
- 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?
- 17. Deep Diving into VLF’s
- 19. >= 64MB < 1GB = 8 VLF’s
- 20. > 1GB = 16VLF’s
- 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
- 24. Live Demo
- 25. Comparison
- 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
Notas del editor
- 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.