10 most important SQL Server transaction log myths February 12, 2014 by Ivan Stankovic Myth: SQL transaction log truncation will make it smaller The truncation process does not reduce the size of a physical log file During the truncation process, only the active portion of the online SQL Server transaction log file is scanned. Some parts of the scanned portion are marked as inactive and they will be used as free space to write down new transactions. There isn’t a change in the online transaction log size because the inactive parts remain intact, nothing is deleted or removed Every SQL Server transaction log is made of Virtual Log Files (VLFs). During the truncation process, only the Logical log is scanned. A Logical log is made of active VLFs. A Log Sequence Number (LSN) is used to uniquely identify every transaction in the online transaction log. The MinLSN is the starting point of the oldest active transaction in the online transaction log The online SQL Server transaction log file is circular by internal organization. When logging reaches the end of the transaction log, it starts again from the beginning by overwriting the parts marked as inactive Orange represents the Logical log, blue the truncated part of the online transaction log ready to be overwritten Myth: Having multiple online SQL Server transaction log files will increase performance This myth is based on the belief that having multiple online transaction log files will result in parallel writing of transactions into the files and therefore result in performance gain. SQL Server can’t operate with more than one online transaction log file at the time, so any kind of parallel I/O is not possible Having multiple transaction log files is needed only in the situations where the initial SQL Server transaction log can’t record more transactions due to a lack of free space on the disk Myth: The SQL Server transaction log won’t grow if the database is in the Simple recovery model However, it happens just in some specific situations – when there is a long running transaction or transaction that creates many changes In the Simple recovery model, the online transaction log is cleared automatically. SQL Server automatically reclaims log space to keep space requirements small – but that doesn’t mean it won’t grow. The online transaction log must provide enough information for a database rollback, therefore it must provide enough space for all necessary information. As all transactions must be written into the online transaction log, in case of a large number of changes in a transaction, there might not be enough space in the log, so it must be expanded Myth: A SQL Server transaction log backup will be the same size as the online transaction log itself The online transaction log must have enough information to rollback active transactions, so some space is reserved for eventual rollbacks. If a rollback occurs, SQL Server doesn’t want to expand the online transaction log because if the expanding fails, the SQL Server database can become inconsistent or go into the Suspect mode. That’s why the online transaction log has some reserved space and is usually bigger than the SQL Server transaction log backup Moreover, a transaction log backup contains only the transactions made after the last transaction log backup. If the online transaction log contains the transactions that have already been backed up, they will not be present in the new SQL Server transaction log backup, therefore the transaction log backup will be smaller for that amount of space Myth: A full or differential database backup clears the online transaction log The inactive parts of the online SQL Server transaction log are marked for clearing only when a transaction log backup is created Full and differential database backups don’t contain much SQL Server transaction log information, only the transactions necessary to recover the database into a consistent state. These transactions are not a backup of the online transaction log, therefore these transactions are not marked for overwriting in the online transaction log Myth: The TRUNCATE TABLE and DROP TABLE commands are not logged into the online transaction log The exact deleted values are not logged in the online SQL Server transaction log, only the IDs of the pages that held the truncated records are logged. These pages are marked for overwriting in the database data file and the truncated data will be gone for good when the new transactions are written to these pages This myth is also based on the fact that these commands take little time to execute, they are almost instantaneous Myth: My SQL Server is too busy, I don’t want to make SQL Server transaction log backups One of the biggest performance intensive operations in SQL Server is an auto-grow event of the online transaction log file. By not making transaction log backups often enough, the online transaction log will become full and will have to grow. The default growth size is 10%. The busier the database is, the quicker the online transaction log will grow if transaction log backups are not created Creating a SQL Server transaction log backup doesn’t block the online transaction log, but an auto-growth event does. It can block all activity in the online transaction log Myth: A SQL Server transaction log backup isn’t needed for a point in time restore. A full database backup is enough This myth comes from using the RESTORE command with STOPAT clause to restore from a full database backup. The STOPAT clause specifies a point in time for the RESTORE LOG command, and it works well when it’s used with a transaction log backup. The fact that it can be used with a full database backup makes you believe that transaction log backups are not needed to recover to a specific point in time An example of T-SQL code for restoring the AdventureWorks database to December 31st 2013 10:59 PM RESTORE DATABASE AdventureWorks FROM DISK = 'D:\AdventureWorks.bak' WITH NORECOVERY GO RESTORE LOG AdventureWorks FROM DISK = 'D:\AdventureWorks.bak' WITH RECOVERY, STOPAT = 'Dec 31, 2013 10:59:00 PM' GO 1234567 RESTORE DATABASE AdventureWorks FROM DISK = 'D:\AdventureWorks.bak'WITH NORECOVERYGORESTORE LOG AdventureWorks FROM DISK = 'D:\AdventureWorks.bak'WITH RECOVERY, STOPAT = 'Dec 31, 2013 10:59:00 PM'GO Although the SQL Server database cannot be restored to a point in time, SQL Server doesn’t clearly identify the problem, and it allows you to use the STOPAT clause without a transaction log backup specified RESTORE DATABASE successfully processed 24436 pages in 5.498 seconds (34.722 MB/sec). This backup set contains records that were logged before the designated point in time. The database is being left in the restoring state so that more roll forward can be performed. RESTORE LOG successfully processed 4 pages in 0.088 seconds (0.338 MB/sec). Myth: SQL Server transaction log backups are not needed for successful disaster recovery if the full database backup is taken daily It also depends on how much data you can lose. If you can afford to lose up to 24 hours of data, then you don’t need transaction log backups and you should use the Simple recovery model If the information you can lose is measured in minutes and hours, regular transaction log backups are necessary, as the maximum you will lose is the time between to transaction log backups Myth: The SQL Server transaction log shrinking will make free space in the online transaction log so I don’t need to create transaction log backups The shrink operation is not a good maintenance practice because it doesn’t solve the transaction log size issue permanently. After the initial shrinking, the transaction log will grow again. As the auto-growth event is one of the most intensive SQL Server operations, it should be avoided. The recommended method to keep the size of the online transaction log is to create transaction log backups regularly. Or, switching to the Simple recovery model, if you can tolerate data loss See more To read the SQL Server transaction log, consider ApexSQL Log, a 3rd party SQL Server transaction log reader, that renders transaction log information into a searchable, sortable grid and can produce Undo and Redo scripts. Resources A SQL Server DBA myth a day: (30/30) backup myths Transaction log myths About Latest Posts Ivan StankovicIvan is a SQL Server professional and computer geek with years of IT and SQL Server experience. He has startedwith playing computer games, continued with computer programming and system administration. His areas of expertise are SQL Server disaster recovery, auditing, and complianceView all posts by Ivan Stankovic Latest posts by Ivan Stankovic (see all) Using Extended Events to review SQL Server failed logins - August 5, 2014 SQL Server backup – models and types - May 26, 2014 SQL Server Policy Based Management – Categories and Database Subscriptions - May 21, 2014 See also How to recover SQL Server data from accidental UPDATE and DELETE operation Recover SQL data from a dropped table without backups How to recover SQL Server data from accidental updates without backups How to recover a single table from a SQL Server database backup Related posts: What are virtual log files in a SQL Server transaction log? A beginner’s guide to SQL Server transaction logs Top 10 articles on the SQL Server transaction log SQL Server backup – models and types What is backup and restore in SQL Server disaster recovery?