删除不需要的（辅助）SQL Server事务日志文件

This article explores the use of multiple SQL Server Transaction Log Files and the process of removing the secondary transaction log file.

本文探讨了多个SQL Server事务日志文件的使用以及删除辅助事务日志文件的过程。

介绍 (Introduction)

By default, a SQL Server database contains a primary data file and transaction log file. It is a good practice configuring multiple data files and split data across multiple data files. We can have these data files in separate storage drives to have multiple IO. It helps data management, improves performance, plans backup approaches according to filegroups.

默认情况下，SQL Server数据库包含主数据文件和事务日志文件。这是配置多个数据文件并将数据拆分到多个数据文件中的一个好习惯。我们可以将这些数据文件放在单独的存储驱动器中以具有多个IO。它可以帮助数据管理，提高性能，根据文件组计划备份方法。

We can have multiple transaction log files for a database as well.

我们也可以有一个数据库的多个事务日志文件。

SQL Server uses the multiple transaction log files in sequential order. Suppose we have two transaction log files. SQL Server uses one log file at a time and once it is full, SQL Server uses another log file. Since SQL Server does not use it in parallel, we do not get any performance benefit of it. Ideally, we should have only one transaction log file per database.

SQL Server按顺序使用多个事务日志文件。假设我们有两个事务日志文件。 SQL Server一次使用一个日志文件，一旦它满了，SQL Server将使用另一个日志文件。由于SQL Server不会并行使用它，因此我们无法获得任何性能优势。理想情况下，每个数据库应该只有一个事务日志文件。

Let’s assume we have a production database, and we receive a critical alert that disk is running out of space. After investigation, we’ve found out that this drive holds a transaction log file. Due to active transactions, this SQL Server transaction log file is full. We’ve tried shrinking the log file, but it did not work. We back up the transaction log also, but due to active transactions, it could not release needed space. Adding another transaction log file in a separate disk with free space will resolve this issue.

假设我们有一个生产数据库，并且收到一个严重警报，提示磁盘空间不足。经过调查，我们发现该驱动器包含一个事务日志文件。由于事务处于活动状态，因此此SQL Server事务日志文件已满。我们尝试缩小日志文件，但是没有用。我们也备份了事务日志，但是由于事务处于活动状态，因此无法释放所需的空间。在具有可用空间的单独磁盘中添加另一个事务日志文件将解决此问题。

As SQL Server uses serial mode for writing data in a transaction log file, we should remove the additional log file later. Let’s explore the process of removing an additional log file.

由于SQL Server使用串行模式在事务日志文件中写入数据，因此我们应在以后删除其他日志文件。让我们探讨一下删除其他日志文件的过程。

创建具有多个SQL Server事务日志文件的数据库 (Create a database with multiple SQL Server Transaction Log files)

Connect to a SQL instance in SQL Server Management Studio. Right-click on the Databases node in the Object Explorer pane and click on the New Database command:

连接到SQL Server Management Studio中SQL实例。右键单击“对象资源管理器”窗格中的“数据库”节点，然后单击“新建数据库”命令：

It opens the New database window. Specify a database name and add another transaction log file. For testing purposes, we’ve disabled auto-growth of transaction log files. The initial size of the transaction log file is 8MB:

它打开“新建数据库”窗口。指定数据库名称并添加另一个事务日志文件。为了进行测试，我们禁用了事务日志文件的自动增长。事务日志文件的初始大小为8MB：

After everything is set, click the OK button to create a database in a default data/log file directory. Create a table and insert data into:

设置完所有内容后，单击“确定”按钮以在默认数据/日志文件目录中创建数据库。创建一个表并将数据插入到：

USE MultipleLogFiles;
GO
CREATE TABLE Employee
(EmpID   INT IDENTITY(1, 1), EmpName VARCHAR(50)
);
Insert into Employee (EmpName) Values ('Raj')

查看SQL Server事务日志文件中的虚拟日志文件状态 (View the virtual log file status in SQL Server transaction log files)

In the article, SQL Server Transaction Log Architecture, we explored the internal of the transaction log file. Each transaction log file consists of multiple virtual log files. A transaction log file is a combination of multiple virtual log files (VLF). The following screenshot shows the physical and logical architecture of the log file:

在“ SQL Server事务日志体系结构”一文中，我们探讨了事务日志文件的内部。每个事务日志文件都包含多个虚拟日志文件。事务日志文件是多个虚拟日志文件（VLF）的组合。以下屏幕快照显示了日志文件的物理和逻辑体系结构：

SQL Server stats a database with minimum VLF based on the initial log size and auto grow file (based on the auto-growth configuration). In the following image, we get a glimpse of the SQL Server transaction log file:

SQL Server根据初始日志大小和自动增长文件（基于自动增长配置）来统计具有最小VLF的数据库。在下图中，我们可以看到SQL Server事务日志文件：

In the case of a single transaction log file, SQL Server uses a circular virtual log file path. We can check the number of virtual log files and their status using the following:

对于单个事务日志文件，SQL Server使用循环虚拟日志文件路径。我们可以使用以下方法检查虚拟日志文件的数量及其状态：

DBCC LOGINFO(‘Database’) – It is an old statement and works with all SQL Server versions DBCC LOGINFO（'Database'）–这是一条旧语句，适用于所有SQL Server版本
sys.dm_db_log_info (DBID). It is available from SQL Server 2016 SP2 or later sys.dm_db_log_info（DBID）。可从SQL Server 2016 SP2或更高版本获得

Any of the commands can be used for the VLF check. For this article, we will use the dynamic management view (DMV):

任何命令都可以用于VLF检查。对于本文，我们将使用动态管理视图（DMV）：

SELECT *
FROM sys.dm_db_log_info(DB_ID('MultileLogFiles'));

In the above screenshot, we’ve verified that our sample database contains two transaction log files (file_id 2 and file_id 3).

在上面的屏幕截图中，我们已经验证了示例数据库包含两个事务日志文件（file_id 2和file_id 3）。

File_id 2 has active VLF (vlf_active=1 and vlf_status=2) File_id 2具有活动的VLF（vlf_active = 1和vlf_status = 2）
File_id 3 does not have any active VLF (vlf_active=0 and vlf_status=2) File_id 3没有任何活动的VLF（vlf_active = 0和vlf_status = 2）

Let’s insert a few more records in the table so that active VLF will change:

让我们在表中插入更多记录，以便活动VLF发生变化：

Insert into Employee (EmpName) Values ('Raj')
Go 3000

The transaction log space usage monitoring and VLF status will be done with DMV (sys.dm_db_log_space_usage):

事务日志空间使用情况监视和VLF状态将通过DMV（ sys.dm_db_log_space_usage ）完成：

VLF status

VLF状态

SELECT DB_name() as DatabaseName,File_ID as transaction_log_file_ID, vlf_active , vlf_status
FROM sys.dm_db_log_info(DB_ID('MultileLogFiles'));

Transaction log usage (used and free space)

事务日志使用情况（已用空间和可用空间）

SELECT total_log_size_in_bytes*1.0/1024/1024 total_log_size_in_MB,
used_log_space_in_bytes*1.0/1024/1024 used_log_space_in_MB,
(total_log_size_in_bytes - used_log_space_in_bytes)*1.0/1024/1024
AS free_log_space_in_MB
FROM sys.dm_db_log_space_usage;

We get the following output of the above queries:

我们得到以上查询的以下输出：

On the left-hand side, we see that once the primary log file (file_id 2) becomes full, it moves to the next log file (file_id 3). At this point, we have active VLF in both primary and secondary log files. In a database with a full recovery model, we need a transaction log backup so that it marks VLF as inactive 在左侧，我们看到一旦主日志文件（file_id 2）变满，它将移至下一个日志文件（file_id 3）。此时，我们在主日志文件和辅助日志文件中都有活动的VLF。在具有完整恢复模型的数据库中，我们需要备份事务日志，以便将VLF标记为非活动状态
The right-hand side output (using DMV) shows the transaction log file used space 8.51 MB. As you recall, we’ve set 8 MB size for each transaction log file and we’ve disabled log auto-growth. When the primary log file is full (at 8 MB), SQL Server will switch to the secondary transaction log file 右侧输出（使用DMV）显示事务日志文件已使用空间8.51 MB。您还记得，我们为每个事务日志文件设置了8 MB的大小，并且禁用了日志自动增长功能。当主日志文件已满（8 MB）时，SQL Server将切换到辅助事务日志文件

删除辅助SQL Server事务日志文件 (Remove secondary SQL Server transaction log file)

To remove the secondary transaction log file (file id 3), we will use the edited Alter database statement.

要删除辅助事务日志文件（文件ID 3），我们将使用编辑后的Alter数据库语句。

We will add the REMOVE FILE clause and specify the file that we want to remove:

我们将添加REMOVE FILE子句并指定我们要删除的文件：

ALTER DATABASE [MultipleLogFiles]  REMOVE FILE [MultipleLogFiles_log_1]
GO

Execution of this statement will result in the following error message:

执行该语句将导致以下错误消息：

Note: The active transaction log file cannot be removed.

注意：无法删除活动事务日志文件。

Previously, we saw that once the primary log file becomes full, SQL Server uses the secondary log file. We need to make a secondary transaction log empty, so we can remove it.

以前，我们看到一旦主日志文件变满，SQL Server就会使用辅助日志文件。我们需要使辅助事务日志为空，以便将其删除。

In the SQL database with a full recovery model, we use transaction log backups so SQL Server can truncate the logs. We might need multiple log backups for this depending upon transaction log size, active VLF and active transaction.

在具有完整恢复模型SQL数据库中，我们使用事务日志备份，以便SQL Server可以截断日志。为此，我们可能需要多个日志备份，具体取决于事务日志大小，活动的VLF和活动的事务。

Let’s perform a full database and transaction log backup:

让我们执行完整的数据库和事务日志备份：

Full database backup

完整的数据库备份

backup Database MultipleLogFiles to disk='C:\Temp\MultipleLogFiles.bak'

Transaction log backup

交易日志备份

backup log MultipleLogFiles to disk='C:\Temp\MultipleLogFiles_log.trn'

Once the backup is completed, verify the VLF status. The active VLF should be in the first log file(primary) so that we can remove the secondary log file. We’ve verified that only the primary log file (file_id 2) is active ( VLF Status 2):

备份完成后，请验证VLF状态。活动的VLF应该在第一个日志文件（主文件）中，以便我们可以删除第二个日志文件。我们已经验证了只有主日志文件（file_id 2）是活动的（VLF状态2）：

Now, the secondary transaction log file should be removed without any problems. Let’s execute the edited Alter database statement again. The secondary transaction log file will be removed:

现在，应该删除辅助事务日志文件，而不会出现任何问题。让我们再次执行编辑后的Alter数据库语句。次要事务日志文件将被删除：

Once the secondary transaction log file is removed, verify it using the GUI as well as T-SQL with system view sys.database_files:

除去辅助事务日志文件后，使用GUI以及带有系统视图sys.database_files的T-SQL对其进行验证：

SELECT file_id, name, type_desc, physical_name
FROM sys.database_files;

The removed secondary transaction log file is still present as per the following screenshot:

根据以下屏幕截图，已删除的辅助事务日志文件仍然存在：

Now right-click on the database and view existing files. We see the removed transaction log file in GUI as well. But why?

现在，右键单击数据库并查看现有文件。我们还可以在GUI中看到已删除的事务日志文件。但为什么？

Let’s execute the edited Alter database statement again and see if SQL Server again removes the transaction log file.

让我们再次执行编辑后的Alter数据库语句，看看SQL Server是否再次删除事务日志文件。

We got the message that SQL Server could not find the specified log file:

我们收到一条消息，指出SQL Server找不到指定的日志文件：

SQL Server removes the transaction log file after a subsequent log backup. Let’s take another log backup and verify that the transaction log file still exists:

SQL Server在后续的日志备份后删除事务日志文件。让我们进行另一个日志备份，并验证事务日志文件是否仍然存在：

backup log MultipleLogFiles to disk='C:\Temp\MultipleLogFiles_log_1.trn'

Verify the transaction log file in both GUI and T-SQL methods. We see that the removed transaction log file does not show up now.

在GUI和T-SQL方法中验证事务日志文件。我们看到已删除的事务日志文件现在没有显示。

结论 (Conclusion)

In this article, we explored the usage of the secondary SQL Server transaction log and the process of removing it. You should avoid using multiple transaction log files, especially on the production database. You should take a database backup before planning any activity and do it in non-productivity hours.

在本文中，我们探讨了辅助SQL Server事务日志的用法以及删除它的过程。您应该避免使用多个事务日志文件，尤其是在生产数据库上。您应该在计划任何活动之前进行数据库备份，并在非生产时间进行备份。

翻译自: https://www.sqlshack.com/drop-unwanted-secondary-sql-server-transaction-log-files/