vlf 用法

In this article we’ll review SQL Virtual Log files aka SQL Server VLFs, providing an overview and review topics related to size, performance, monitoring and troubleshooting.

在本文中，我们将回顾SQL虚拟日志文件（又名SQL Server VLF），提供概述并回顾与大小，性能，监视和故障排除有关的主题。

In a previous article of this series, SQL Server Transaction Log Architecture, we described the internal architecture of the SQL Server transaction log, why and how the SQL Server Engine uses the transaction log and finally how the transaction log truncation process occurs. In this article, we will discuss the Virtual Log File concept in-depth.

在本系列的上一篇文章“ SQL Server事务日志体系结构”中 ，我们描述了SQL Server事务日志的内部体系结构，SQL Server Engine为什么以及如何使用事务日志以及最终如何进行事务日志截断过程。 在本文中，我们将深入讨论虚拟日志文件的概念。

虚拟日志文件概述 (Virtual Log File Overview)

In SQL Server, each transaction log is logically divided into smaller segments, in which the log records are written. These small segments are called SQL Virtual Log Files, also known as VLFs. When the transaction log file is created or extended, the number of SQL Server VLFs in the transaction log and the size of each Virtual Log File are determined dynamically. On the other hand, the size that is determined for the first Virtual Log File will be used for all newly created SQL Virtual Log Files on the same transaction log.

在SQL Server中，每个事务日志在逻辑上分为较小的段，在这些段中写入了日志记录。 这些小段称为SQL 虚拟日志文件 ，也称为VLF。 创建或扩展事务日志文件时，将动态确定事务日志中SQL Server VLF的数量和每个虚拟日志文件的大小。 另一方面，为第一个虚拟日志文件确定的大小将用于同一事务日志上所有新创建SQL虚拟日志文件。

When a new log record is written, the SQL Server Engine will use the existing unused SQL Server VLFs. If all the existing SQL Virtual Log Files are active and the transaction log file extend is required, new SQL Server VLFs will be created based on the size of the transaction log to be written.

写入新的日志记录时，SQL Server引擎将使用现有的未使用SQL Server VLF。 如果所有现有SQL虚拟日志文件均处于活动状态，并且需要扩展事务日志文件，则将根据要写入的事务日志的大小来创建新SQL Server VLF。

事务日志文件大小 (Transaction Log File Size )

When a new SQL user database is created, two database files will be created, a database data file, with MDF extension, in which the tables data will be written and a database log file, with LDF extension, in which all the database transactions will be written for recovery purposes.

创建新SQL用户数据库时，将创建两个数据库文件，一个扩展名为MDF的数据库数据文件（将在其中写入表数据）和一个扩展名为LDF的数据库日志文件，其中将包含所有数据库事务。为恢复目的而编写。

By default, the initial size and the auto-growth settings for the transaction log file will meet the initial size and auto-growth settings of the model system database. For example, in SQL Server 2016, the initial size of the transaction log file is 8MB, that can be increased with the auto-growth amount of 64MB, with no limitation for the maximum file size, as shown below:

默认情况下，事务日志文件的初始大小和自动增长设置将满足模型系统数据库的初始大小和自动增长设置。 例如，在SQL Server 2016中，事务日志文件的初始大小为8MB，可以随着64MB的自动增长量而增加，而对最大文件大小没有限制，如下所示：

The default values of the initial size and auto-growth settings of the transaction log file can be modified during the database creation process, or later when the database is already created, from the database properties page, based on your database growth plan.

事务日志文件的初始大小和自动增长设置的默认值可以在数据库创建过程中进行修改，或者稍后在已经创建数据库时根据数据库增长计划从数据库属性页中进行修改。

The auto-growth option of the database files is enabled by default. The auto-growth option of the transaction log file should be controlled from different aspects. The first aspect is specifying a limit to the maximum size that the transaction log file can reach. In this case, you will protect the hosting disk drive from running out of free space due to the transaction log file growth and protect the database from being inaccessible.

默认情况下，数据库文件的自动增长选项处于启用状态。 应当从不同方面控制事务日志文件的自动增长选项。 第一个方面是指定事务日志文件可以达到的最大大小的限制。 在这种情况下，您将防止托管磁盘驱动器由于事务日志文件的增长而耗尽可用空间，并防止数据库无法访问。

The second aspect of managing transaction log file growth is specifying a reasonable initial size and auto-growth amount or percent. There is no optimal value for transaction log file initial size and auto-growth that can fit all situation. But what should be considered is specifying a proper value for these two settings that prevent the small and frequent increases in the size of the transaction log file. This is due to the fact that the SQL Server Engine will pause all log writing processes until the log file size increase process is completed, causing serious performance issues.

管理事务日志文件增长的第二个方面是指定合理的初始大小和自动增长量或百分比。 没有适合所有情况的事务日志文件的初始大小和自动增长的最佳值。 但是，应该考虑为这两个设置指定一个适当的值，以防止事务日志文件的大小频繁出现小幅增加。 这是由于SQL Server Engine将暂停所有日志写入过程，直到完成日志文件大小增加过程为止，从而导致严重的性能问题。

SQL Server allows us to create more than one transaction log file on each database, but this option is not recommended, as the database transaction logs are written in sequential order into the transaction log. In this case, the SQL Server Engine will not start writing to the second transaction log file until the first file is full. The ability of creating more than one transaction log file on the database can help only when you plan to extend the transaction log file size and the current hosting disk drive runs out of free space.

SQL Server允许我们在每个数据库上创建多个事务日志文件，但是不建议使用此选项，因为数据库事务日志是按顺序写入事务日志的。 在这种情况下，在第一个文件已满之前，SQL Server引擎将不会开始写入第二个事务日志文件。 仅当您计划扩展事务日志文件的大小并且当前托管磁盘驱动器的可用空间不足时，在数据库上创建多个事务日志文件的功能才有帮助。

虚拟日志文件大小 (Virtual Log File Size )

In SQL Server, there is no option to set the number or the size of the SQL Virtual Log Files manually, as the SQL Serve Engine determines the size dynamically when the transaction log file is created at the first time or extended when extra size is required.

在SQL Server中，没有选项可以手动设置SQL虚拟日志文件的数量或大小，因为SQL Serve Engine在首次创建事务日志文件时动态确定大小，而在需要额外大小时进行扩展。

The number of SQL Server VLFs is increased as a response to the transaction log file auto-growth event, where extra SQL Virtual Log Files will be created on the transaction log to provide a location for the new transactions to be written. On the other hand, the number of SQL Virtual Log Files is decreased by performing a file shrink process on the transaction log file, to release the space back to the operating system, resulting smaller transaction log file.

作为对事务日志文件自动增长事件的响应，SQL Server VLF的数量增加了，在该事件中，将在事务日志上创建额外SQL虚拟日志文件，以为要写入的新事务提供位置。 另一方面，通过对事务日志文件执行文件收缩过程来减少SQL虚拟日志文件的数量，以将空间释放回操作系统，从而得到较小的事务日志文件。

The truncation process differs from the shrink process in that, the space will be released for a new transaction log to be written in the transaction log file, in the case of truncation, where the space will be released back to the operating system in the case of shrink. The Virtual Log File is the smallest unit of truncate in the transaction log file, where the Virtual Log File will be truncated only if it contains no single active record.

截断过程与收缩过程的不同之处在于，在截断情况下，将释放空间以将新的事务日志写入事务日志文件中，在这种情况下，将空间释放回操作系统收缩。 虚拟日志文件是事务日志文件中最小的截断单位，其中虚拟日志文件仅在不包含单个活动记录的情况下才会被截断。

虚拟日志文件和性能 (Virtual Log File and Performance)

Having a large number of SQL Virtual Log Files in the transaction log file can lead to performance issues. The SQL Server Engine tries internally to keep the number of SQL Server VLFs as small as possible, as it can process the smaller number of these VLFs more efficiently, specially during the crash and recovery conditions. When the SQL Server service is restarted, the database will be in recovery state, in which the SQL Server Engine reads the SQL Virtual Log Files in order to maintain the databases in consistent state, by rolling forward the committed transactions and rolling back the failed ones. If the transaction log file contains large number of SQL Server VLFs, the SQL Server Engine will take long time recovering the database transitions.

事务日志文件中包含大量SQL虚拟日志文件会导致性能问题。 SQL Server引擎在内部尝试使SQL Server VLF的数量保持尽可能小，因为它可以更有效地处理较小数量的这些VLF，尤其是在崩溃和恢复情况下。 重新启动SQL Server服务时，数据库将处于恢复状态，在该状态下，SQL Server引擎通过前滚已提交的事务并回滚失败的事务来读取SQL虚拟日志文件，以使数据库保持一致状态。 。 如果事务日志文件包含大量SQL Server VLF，则SQL Server Engine将花费很长时间恢复数据库转换。

The large number of the SQL Virtual Log Files results from small initial size and small auto-growth amount of the transaction log file. In this case, the transaction log file will grow very frequently in small chunks each time an extra space is required. As a result, the transaction log file will consist of large number of small SQL Server VLFs, that will result in performance degradation issues. To overcome such issue, it is highly recommended to set the initial size of the transaction log file to a sufficiently large amount that you think it fits your database transaction log growth with large auto-growth value, not less than 1GB for heavily transactional databases.

大量SQL虚拟日志文件是由较小的初始大小和较小的事务日志文件自动增长量引起的。 在这种情况下，每次需要额外的空间时，事务日志文件都会非常频繁地以小块增长。 结果，事务日志文件将包含大量的小型SQL Server VLF，这将导致性能下降问题。 为解决此问题，强烈建议将事务日志文件的初始大小设置为足够大的数量，以使其适合具有较大自动增长值的数据库事务日志增长，对于具有大量事务的数据库，该大小不少于1GB。

监视SQL虚拟日志文件 (Monitoring SQL Virtual Log Files )

As a proactive database administrator, it is a very important task, but unfortunately missed by many, to monitor the number of the SQL Server VLFs on your databases, and make sure that it in the acceptable range, for example less than 50 VLFs per each 10GB, that will not affect the performance of your databases negatively.

作为主动数据库管理员，监视数据库上SQL Server VLF的数量并确保在可接受的范围内（例如每个数据库少于50个VLF）是一项非常重要的任务，但不幸的是许多人错过了它。 10GB，不会对数据库的性能产生负面影响。

The number of SQL Virtual Log Files on the database can be easily monitored using the DBCC command below, that returns one record for each VLF, as follows:

可以使用下面的DBCC命令轻松监视数据库中SQL虚拟日志文件的数量，该命令为每个VLF返回一条记录，如下所示：

DBCC LOGINFO

And the result from a newly created database, will show a small number of SQL Server VLFs, as below:

新创建的数据库的结果将显示少量SQL Server VLF，如下所示：

If we change the default auto-growth amount for the transaction log file of our database, for testing purposes, from 64MB to 1MB as follows:

如果出于测试目的，我们将数据库的事务日志文件的默认自动增长量从64MB更改为1MB，如下所示：

Then insert 1M records to the table, then check the SQL Virtual Log Files number, using the DBCC command, you will see that the number of SQL Server VLFs increased to 89, due to the large number of small increments that are performed on the transaction log file. You can imagine the time required to recover the database after a crash or reboot process:

然后将1M记录插入表中，然后使用DBCC命令检查SQL虚拟日志文件的数量，您将看到由于对事务执行了大量小增量操作，SQL Server VLF的数量增加到了89个日志文件。 您可以想象崩溃或重新启动过程后恢复数据库所需的时间：

解决SQL虚拟日志文件问题 (Fixing SQL Virtual Log Files Issues)

We mentioned previously how to be a proactive database administrator and prevent the issue of having large number of SQL Server VLFs in your database. But what should be done if the issue is occurring now, as we saw in the previous example?

前面我们提到了如何成为主动数据库管理员，并防止数据库中存在大量SQL Server VLF的问题。 但是，如我们在前面的示例中看到的，如果问题现在正在发生，应该怎么办？

In this case, you can fix it by simply shrinking the transaction log file and re-grow it again with a suitable initial size and large auto-growth amount, during non-peak time and after making sure that there is no heavy transaction is running, by following the steps below:

在这种情况下，您可以通过以下方法解决此问题：在非高峰时间，并且在确保没有繁重的事务运行之后，只需收缩事务日志文件，然后以适当的初始大小和较大的自动增长量再次重新增长它即可。 ，请按照以下步骤操作：

1. Perform a transaction log backup for the database to truncate the inactive part of the transaction log. This is valid only if the database recovery model is FULL and can be skipped to step 3 if the database recovery model is simple. 对数据库执行事务日志备份，以截断事务日志的非活动部分。 仅当数据库恢复模型为FULL时才有效；如果数据库恢复模型很简单，则可以跳至步骤3。
2. Perform a manual CHECPOINT in order to write all the pages in the buffer to the database files. 执行手动CHECPOINT以便将缓冲区中的所有页面写入数据库文件。
3. 
4. 

Set the initial size of the transaction log file to a larger suitable size and the auto-growth option to a higher amount that prevents the frequent small increments and protect your database from the high SQL Server VLFs number issue as shown below:

将事务日志文件的初始大小设置为较大的适当大小，并将auto-growth选项设置为较大的值，以防止频繁的小增量并保护数据库免受高SQL Server VLF编号问题的影响，如下所示：

In the next article, we will discuss the relationship between the SQL Server transaction log and database recovery models. Stay tuned!

在下一篇文章中，我们将讨论SQL Server事务日志和数据库恢复模型之间的关系。 敬请关注！

目录 (Table of contents)

翻译自: https://www.sqlshack.com/what-are-sql-virtual-log-files-aka-sql-server-vlfs/

vlf 用法