SQL Server事务日志管理最佳实践

时间 2021-08-15 标签数据库大数据 python mysql java

In this article, we will go through a number of SQL Server Transaction Log recommendations and best practices that each database administrator needs to follow in order to enjoy his holidays and have a pleasant sleep without nightmares or calls during the night.

在本文中，我们将介绍许多SQL Server事务日志建议和最佳实践，每个数据库管理员都需要遵循这些建议和最佳实践，以度过假期，并在不做噩梦或夜间打电话的情况下睡个好觉。

Before reading this article, it is recommended to check the previous articles of the SQL Server Transaction Log series (see the TOC below), in order to be familiar with the different SQL Server Transaction Log related concepts that you will meet in this article.

在阅读本文之前，建议先阅读SQL Server事务日志系列的前几篇文章（请参阅下面的TOC），以便熟悉本文中将要遇到的与SQL Server事务日志相关的其他概念。

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

When a user database is created, the initial size and the auto-growth settings of the SQL Server Transaction Log file will replicate the initial size and auto-growth settings of the model system database, also known as Template database. By default, the SQL Transaction Log file initial size of a newly created database is 8MB, with the auto-growth amount of 64MB, as shown in the Files page of the Database Properties window ge below:

创建用户数据库后，SQL Server事务日志文件的初始大小和自动增长设置将复制模型系统数据库（也称为模板数据库）的初始大小和自动增长设置。默认情况下，新创建的数据库SQL事务日志文件的初始大小为8MB ，自动增长量为64MB ，如下面的“数据库属性”窗口ge的“文件”页面中所示：

SQL Server Transaction Log - DB File Properties

It is recommended to set the initial size and the auto-growth of the Transaction Log file to reasonable values. Although there is no one optimal value for Transaction Log File initial size and auto-growth that fits all situations, but setting the initial size of the SQL Server Transaction Log file to 20-30% of the database data file size and the auto-growth to a large amount, above 1024MB, based on your database growth plan can be considered as a good starting point for the normal workload. In this way, we will avoid the problem of the frequent and the small increments in the SQL Transaction Log file size, that may lead to queries slowness, due to pausing all log writing processes until the log file size increase process is completed, and generates a large number of Virtual Log Files. Keep in mind also that the Transaction Log file cannot take advantages from the Instant File Initialization option, that makes the Transaction Log file extending process slower.

建议将事务日志文件的初始大小和自动增长设置为合理的值。尽管没有适合所有情况的事务日志文件初始大小和自动增长的最佳值，但是将SQL Server事务日志文件的初始大小设置为数据库数据文件大小和自动增长的20-30％根据数据库的增长计划，将其最大数量（超过1024MB）视为正常工作负载的良好起点。这样，我们将避免由于暂停所有日志写入过程直到完成日志文件大小增加过程而导致SQL事务日志文件大小频繁且小幅增加的问题，这可能导致查询缓慢。大量的虚拟日志文件。还请记住，事务日志文件不能利用“ 即时文件初始化”选项的优势，这会使事务日志文件的扩展过程变慢。

Setting the SQL Server Transaction Log file initial size for the tempdb system database with a proper large amount should be considered from the beginning. This is due to the fact that, restarting the SQL Server instance will drop the tempdb data and log files and create it again with the original predefined initial size and auto-growth amount. If the SQL Transaction Log file of the tempdb is configured with small initial size, the extra overhead that is caused by increasing the size of the tempdb Transaction Log will affect the performance of the tempdb database.

从一开始就应该考虑为tempdb系统数据库设置SQL Server事务日志文件的初始大小。这是由于以下事实：重新启动SQL Server实例将删除tempdb数据和日志文件，并使用原始的预定义初始大小和自动增长量再次创建它。如果将tempdbSQL事务日志文件配置为较小的初始大小，则由于增加tempdb事务日志的大小而导致的额外开销将影响tempdb数据库的性能。

Another factor that should be taken into consideration is the maximum size that the SQL Server Transaction Log file can reach. Two things should be considered when setting the maximum size amount; preventing the Transaction Log file from filling the disk drive and protecting the database from being inaccessible when the Transaction Log file runs out of free space, as follows:

应考虑的另一个因素是SQL Server事务日志文件可以达到的最大大小 。设置最大大小量时应考虑两点：防止事务日志文件填充磁盘驱动器，并防止事务日志文件用完可用空间时无法访问数据库，如下所示：

After providing the proper values for the initial size, auto-growth, and maximum file size, we should keep an eye on the SQL Server Transaction Log file and monitor the database file growth while handling the incoming workload, and tune it based on that growth amount. The sys.dm_db_log_space_usage DMV can be used to monitor the log space in a specific database. It provides information about the amount of log space currently used and if the SQL transaction log needs truncation:

在为初始大小，自动增长和最大文件大小提供适当的值之后，我们应该关注SQL Server事务日志文件，并在处理传入的工作负载时监视数据库文件的增长，并根据该增长对其进行调整量。 sys.dm_db_log_space_usage DMV可用于监视特定数据库中的日志空间。它提供有关当前使用的日志空间量以及SQL事务日志是否需要截断的信息：

Note: For more information about the operations that cause the Transaction log file to grow and how to monitor and manage it, check SQL Server Transaction Log Growth Monitoring and Management.

注意：有关导致事务日志文件增长的操作以及如何监视和管理它的更多信息，请检查 SQL Server事务日志增长监视和管理 。

多个事务日志文件 (Multiple Transaction Log Files)

SQL Server provides us with the ability to create more than one SQL Transaction Log file on each database. But we should distinguish between the ability and the advantages of having more than one SQL Server Transaction Log file in your database. This decision is built mainly on the architecture of the Transaction Log file and the fact that the transaction logs are written in sequential order into the transaction log, without performing parallel I/O operations if there are multiple SQL Transaction Log files. In other words, the SQL Server Engine will keep writing to the first Transaction Log file until it has no free space, then it will start writing to the second one and so on.

SQL Server使我们能够在每个数据库上创建多个SQL事务日志文件。但是，我们应该在数据库中拥有多个SQL Server事务日志文件的能力和优点之间进行区分。该决定主要基于事务日志文件的体系结构和以下事实：事务日志按顺序写入事务日志，如果有多个SQL事务日志文件，则不执行并行I / O操作。换句话说，SQL Server引擎将继续写入第一个事务日志文件，直到没有可用空间为止，然后它将开始写入第二个事务日志文件，依此类推。

Creating multiple SQL Transaction Log files has no enhancement to the queries performance but can help only if extending the Transaction Log file size is required but the current disk drive runs out of free space.

创建多个SQL事务日志文件不会提高查询性能，但仅在需要扩展事务日志文件大小但当前磁盘驱动器用完可用空间时才有帮助。

VLF数量 (Number of VLFs)

The Virtual Log Files, also known as VLFs, are the smallest logical units for storing the SQL Transaction Logs in the Transaction Log file.

虚拟日志文件（也称为VLF）是用于在事务日志文件中存储SQL事务日志的最小逻辑单元。

The large number of VLFs in the Transaction Log file, that results from growing the file very frequently in small chunks every time a size extend is required, can lead to bad performance issues.

事务日志文件中的大量VLF是由于每次需要扩展大小时都经常以小块的形式频繁增长文件而导致的，这可能导致性能问题。

Note: For more information about monitoring the number of VLFs in the SQL Transaction Log file and how to fix the large number of VLFs issue check What are SQL Virtual Log Files aka SQL Server VLFs.

注意：有关监视SQL事务日志文件中的VLF数量以及如何解决大量VLF的更多信息，请检查 什么是SQL虚拟日志文件（又名SQL Server VLF） 。

事务日志文件位置 (Transaction Log File Location)

As the sequential writing mechanism into the Transaction Log file differs from the random writing mechanism, using the proportional fill algorithm, into the database data files, it is highly recommended to place the SQL Transaction Log files on a separated physical drive, not just store it on different partitions, in order to isolate the effect of the simultaneous sequential workload on the random workload. For Transaction Log file intensive writing workload, use Enterprise-grade SSD drives or minimum RAID 10 drive technology.

由于向事务日志文件中的顺序写入机制与随机写入机制不同（使用比例填充算法）到数据库数据文件中，因此强烈建议将SQL事务日志文件放置在单独的物理驱动器上，而不仅仅是将其存储在不同分区上，以隔离同时发生的顺序工作负载对随机工作负载的影响。对于需要大量事务日志文件的写入工作，请使用企业级SSD驱动器或最低RAID 10驱动器技术。

恢复模型 (Recovery Model)

The database recovery model option specifies how the SQL Server Engine treats the database transaction logs. SQL Server provides us with three recovery model types: Full, Bulk-logged and Simple recovery models.

数据库恢复模型选项指定SQL Server Engine如何处理数据库事务日志。 SQL Server为我们提供了三种恢复模型类型： 完整，批量记录和简单恢复模型。

Note: For more information about the differences between the recovery model types, check the SQL Server Transaction Log and Recovery Models.

注意：有关恢复模型类型之间差异的更多信息，请检查 SQL Server事务日志和恢复模型 。

SQL Server Transaction Log - DB Recovery Model

The recovery model of any new database will be the same as the recovery model of the model system database, which is the Full recovery model by default. The decision of what recovery model should be set for any new database should be built on multiple factors. For example, whether this database participate in any database-level high availability solution such as Database Mirroring or Always On Availability Groups, how critical your data is and how frequent the data changes will specify if it is required to configure the database with Full or Bulk-Logged recovery model in order to provide point in time recovery for the database.

任何新数据库的恢复模型都将与模型系统数据库的恢复模型相同，默认情况下为完全恢复模型。对于任何新数据库应设置哪种恢复模型的决定应基于多个因素。例如，此数据库是否参与任何数据库级高可用性解决方案（例如数据库镜像或始终可用组），您的数据有多关键以及数据更改的频率将指定是否需要将数据库配置为“完整”或“批量” -记录的恢复模型，以便为数据库提供时间点恢复。

On the other hand, you need to consider the SQL Transaction Log monitoring and administration tasks that are required for the configured recovery model. The simplest example is configuring a Transaction Log backup when the database recovery model is set to Full or Bulk-Logged.

另一方面，您需要考虑配置的恢复模型所需SQL事务日志监视和管理任务。最简单的示例是在数据库恢复模型设置为“完全记录”或“批量记录”时配置事务日志备份。

事务日志文件备份 (Transaction Log File Backup)

When building a proper backup strategy for a production database, configured with Full or Bulk-Logged recovery model, you should ask your self-important questions: How much sensitive your business to the data loss? How frequent your data is changed?

为配置了完整或批量记录恢复模型的生产数据库构建适当的备份策略时，您应该问自己的重要问题：您的企业对数据丢失有多敏感？您的数据多久更改一次？

Based on the answers of such questions, you can specify the frequency of the SQL Transaction Log backup and take advantages from the point in time recovery option that works only if you are taking Transaction Log backup using a proper backup strategy:

根据此类问题的答案，您可以指定SQL事务日志备份的频率，并从时间点恢复选项中受益，该选项仅在使用适当的备份策略进行事务日志备份时才有效：

SQL Server Transaction Log - Data loss in the context of SQL Server database backups and Simple recovery mode

A Transaction Log backup is required also to truncate the inactive part of the Transaction Log to release it and make it available for reuse. If the SQL Server Transaction Log backup is not in your backup strategy and the daily Full backup is working fine with your database, change the recovery model of that database to Simple and the SQL Transaction Log will be truncated automatically after each Checkpoint.

还需要事务日志备份来截断事务日志的非活动部分以释放它并使它可供重用。如果您的备份策略中没有SQL Server事务日志备份，并且每日完全备份在您的数据库上运行良好，则将该数据库的恢复模型更改为“简单”，并且SQL事务日志将在每个检查点之后自动被截断。

事务日志文件缩小 (Transaction Log File Shrink)

In the SQL Transaction Log file Shrink operation, all free VLFs will be deallocated from the end of the Transaction Log file and returned back to the operating system, in order to reduce the physical size of the SQL Transaction Log file. The Shrink operation helps when the SQL Transaction Log file contains unused space or after performing a database operation that writes a large number of Transaction Logs.

在SQL事务日志文件收缩操作中，将从事务日志文件的末尾释放所有可用的VLF，然后将其返回操作系统，以减小SQL事务日志文件的物理大小。当SQL事务日志文件包含未使用的空间时，或者在执行写入大量事务日志的数据库操作之后，收缩操作会有所帮助。

Performing a SQL Transaction Log file shrink operation very frequently, or worse, enabling the Auto Shrink database option that shrinks the 25% of the Transaction Log file size is free, is NOT recommended. This is because you will not keep track of the normal growth of the Transaction Log file, and most probably the Transaction Log file will grow again after decreasing its size, causing performance degradation during the new space allocation that needs zeroing the space by the operating system before it is being allocated:

不建议频繁执行SQL事务日志文件收缩操作，或者更糟糕的是，不建议启用自动收缩数据库选项以缩小25％的事务日志文件大小是免费的。这是因为您将无法跟踪事务日志文件的正常增长，并且很有可能事务日志文件在减小大小后会再次增长，从而在需要由操作系统将空间清零的新空间分配期间导致性能下降。在分配之前：

In the next article of the SQL Server Transaction Log series, we will show how to recover deleted or updated data from the transaction log file. Stay tuned!

在SQL Server事务日志系列的下一篇文章中，我们将展示如何从事务日志文件中恢复已删除或已更新的数据。敬请关注！