pedro.lopes@microsoft.com Pedro Azevedo LopesPremier Field EngineerMicrosoft Corporation

Log file management - impact in ongoing operationsIV Encontro da comunidade SQLPort

Agenda

Log File Architecture OverviewWhat is it?What’s it for?Log StructureLog TruncationVLFs

DemoCorrecting VLFs

Agenda

Log File Architecture OverviewWhat is it?What’s it for?Log StructureLog TruncationVLFs

DemoCorrecting VLFs

What is it?

Operations in an RDBMS are logged (or recorded) at the physical and logical level in terms of what happens in the storage structures of the database. Each change to the storage structures has its own log record, which describes the structure being changed and what the change was. This is done in a way that the change can be replayed or reversed.A set of one or more such changes are grouped together in a transaction.

What’s it for?

The transaction log supports the following operations:

Recovery of individual transactions.Recovery of all incomplete transactions when SQL Server is started.Rolling a restored database, file, filegroup, or page forward to the point of failure. Supporting transactional replication.Supporting standby-server solutions.

Database mirroringLog shipping

Log Structure

The transaction log is implemented as a separate file or set of files in the database.SQL Server allocates Log space in logical sections called Virtual Log Files (VLFs) within each physical Log File.

Log Truncation

Log truncation frees any virtual logs before the VLF that contains the minimum recovery log sequence number (MinLSN).

Log truncation frees space in the log file for reuse by the transaction log (wrap-around).

Log Truncation

Transaction log is truncated every time when:

A TLog backup under the full or bulk-logged recovery model. Every transaction checkpoint, if using the simple recovery model (which provides no transaction log recovery).

Note: Truncation does not reduce the size of a physical log file, it reduces the size of the logical log file.

Log Truncation

Log truncation can be delayed during:Data Backup Operations and Restore OperationsLong-Running Active TransactionsDatabase MirroringTransactional Replication

Log Truncation

You can discover what, if anything, is preventing log truncation by using the log_reuse_wait and log_reuse_wait_desc columns of the sys.databases catalog view.

SELECT name, recovery_model_desc, log_reuse_wait_desc FROM sys.databases

VLFs

VLFs are created with each file growth with no defined size.The size of the VLF after a Log File has been extended is the sum of the size of the existing log and the size of the new file increment. The size or number of VLF cannot be configured or set by administrators

VLFs

To find how many VLFs you have, use the following undocumented command, and look at the rowcount: DBCC LOGINFO('UserDatabase')

According to Kimberly Tripp, VLFs are spawned in the following ratio:

Growth of less than 64MB creates 4 VLFs. Growth of more than 64MB and up to 1GB creates 8 VLFs. Growth larger than 1GB creates 16 VLFs.

VLFs – Growth Example

Example of a newly created log file with 256MB with autogrow setting of 5MB:

Initially 8 VLFs of 32MB each

At 10 growth iterations = 40 VLFs of ~640KB each + initial 8 VLFs of 32MB.

At 20 growth iterations = 88 VLFs (…)

At 80 growth iterations = 328 VLFs (…)

At 250 growth iterations = 1008 VLFs (…) (1.2GB)

Etc.

Managing VLFs

VLFs (number and size) impact on the performance of such actions as:

The discovery and generation of a linked list of all the VLFs when starting up a Database.Scanning all VLFs for transactions that are marked for replication. Backup operations.Application-related operations such as INSERT, UPDATE, and DELETE. (As demonstrated by Linchi Shea in his blog).

Agenda

Log File Architecture OverviewWhat is it?What’s it for?Log StructureLog TruncationVLFs

DemoCorrecting VLFs

16

Demo

How VLFs and pre-growth impact performance

Demo conclusions

Few growth iterations and few VLFs display:

Higher update performanceReduced recovery time

Correcting VLFs

If log size cannot be predicted in advance, wait for it to reach a stable size.Then keep the VLFs under control:

Shrink the TLog to a minimum (via DBCC SHRINKFILE (<logfile>, 1))Grow it manually (via ALTER DATABASE (…) MODIFY FILE), based on the VLF creation figures given, until you reach the stable size found for that specific TLog and Database.

In a nutshell…

Bottom line, plan your log size and don’t rely on autogrow except for unforeseen growth needs.

© 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.

The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after

the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.