SQL Server 2012 ldf日志文接太大的截断和收缩日志处理

SQL Server 2012 ldf日志文接太大的截断和收缩日志处理操作

--- SQL Server 2012 ldf日志文接太大的截断和收缩日志处理 ---

-- 查看所有 database 列表及详情
select * from sys.databases;

-- 切换到指定的操作数据库
use testdb;

-- 查询当前数据库的日志文件ID和逻辑文件名
SELECT * FROM sys.database_files;
SELECT file_id, name, type_desc, physical_name, state, state_desc FROM sys.database_files;

-- 查看所有数据库的日志文件大小及使用百分比
dbcc sqlperf(logspace);

-- 查询当前数据库的日志信息，包括文件内的所有VLF虚拟日志文件信息 //select * from sys.dm_db_log_info;
dbcc loginfo;

-- 查询当前数据库的数据库文件空间量（已分配、未分配的大小）
SELECT file_id, type_desc,
       CAST(FILEPROPERTY(name, 'SpaceUsed') AS decimal(19,4)) * 8 / 1024. AS space_used_mb,
       CAST(size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS decimal(19,4)) AS space_unused_mb,
       CAST(size AS decimal(19,4)) * 8 / 1024. AS space_allocated_mb,
       CAST(max_size AS decimal(19,4)) * 8 / 1024. AS max_size_mb
FROM sys.database_files;

-- 查询SQL Server数据库 testdb 的日志文件的分配量及使用情况：
SELECT * FROM sys.dm_db_log_space_usage;
SELECT database_id, total_log_size_in_bytes/1.0/1024/1024 AS total_log_size_mb, used_log_space_in_bytes/1.0/1024/1024 AS used_log_space_mb, used_log_space_in_percent FROM sys.dm_db_log_space_usage;
SELECT (total_log_size_in_bytes - used_log_space_in_bytes)*1.0/1024/1024 AS free_log_space_mb FROM sys.dm_db_log_space_usage;


-- 前面了解了足够的日志信息以后，开始执行 DBCC SHRINKFILE 命令进行 数据文件 或 日志文件收缩操作
-- 一般不推荐缩减数据文件的大小、会对Server有较大的性能影响，一般日志文件占用磁盘大，只收缩日志文件大小，如果一定要收缩数据库文件，则 DBCC SHRINKFILE 执行时指定数据文件ID或者数据文件的逻辑文件名
-- 将文件收缩到小于创建大小、单位MB，同时将最小文件大小重置为新值，可以指定0也可以指定一个值，最终的文件大小会重置成收缩后的实际最小值
-- 若要允许 DBCC SHRINKFILE 命令收缩文件，首先需要通过将数据库恢复模式设置为 SIMPLE 来截断该文件，然后再执行 DBCCSHRINKFILE 命令收缩日志文件；
-- 如果是在实际生产环境上操作时，建议分多次操作，每次收缩一定比例，降低单次收缩的耗时，最终分多次收缩达到最终的收缩目标；

USE testdb;

-- Step1:截断日志

-- 方法1：不备份直接截断日志（到实际的最小值）

-- 注意：SQL Server 在高版本中的事务日志截断：SQL Server 已经已停用 BACKUP LOG WITH NO_LOG 和 WITH TRUNCATE_ONLY 选项，
-- 高版本中使用完整恢复模式或大容量日志恢复模式时，如果必须删除数据库中的日志备份链，请切换至简单恢复模式，操作完后，再设回完整恢复模式

-- 高版本需要将数据库恢复模式设置为简单模式
-- ALTER DATABASE testdb SET RECOVERY SIMPLE;

-- 不备份直接截断日志（到实际的最小值）
DBCC SHRINKFILE (testdb_log, 0);
-- DBCC SHRINKFILE (testdb_log, 0);
-- DBCC SHRINKFILE (2, 0);  //也可以用 file_id 方式


-- 方法2：备份日志、会自动截断（方法1和方法2，根据自己的事业业务场景二选一操作即可）
-- 前提是需要有数据库备份存在，否则会报错提示数据库备份不存在；
-- 数据库备份存在以后，后续可以只备份LOG日志文件
BACKUP DATABASE testdb TO Disk = 'D:\Backup\testdb.bak' WITH NOFORMAT, NOINIT, COMPRESSION;
BACKUP LOG testdb TO Disk = 'D:\Backup\testdb_log.bak' WITH NOFORMAT, NOINIT, COMPRESSION;
-- 高版本已不再支持 BACKUP LOG DBNAME WITH NO_LOG; 直接截断日志


-- Step2:收缩日志文件

-- 收缩日志文件、减小日志文件大小、释放磁盘空间
-- 参数 TruncateOnly 的用处是把：“将文件末尾的所有可用空间释放给操作系统，但不在文件内部执行任何页移动”，上面的语句的作用，只能把文件结尾部分有限的空闲数据页回收。也就不能完全达到数据库收缩的作用了。
DBCC SHRINKFILE (testdb_log, TRUNCATEONLY);

-- 高版本将数据库恢复模式设置回完整恢复模式
-- ALTER DATABASE testdb SET RECOVERY FULL;


-- Step3: 查看结果

-- 可以通过 sys.databases 系统视图查看事务日志不能被截断的原因
SELECT log_reuse_wait, log_reuse_wait_desc FROM sys.databases WHERE name='testdb';



-- 查看所有数据库的日志文件大小及使用百分比
dbcc sqlperf(logspace);

-- 查询当前数据库的日志信息，包括文件内的所有VLF虚拟日志文件信息 //select * from sys.dm_db_log_info。日志收缩成功后VLF条目也会少很多
dbcc loginfo;

-- 查询当前数据库的数据库文件空间量（已分配、未分配的大小）
SELECT file_id, type_desc,
       CAST(FILEPROPERTY(name, 'SpaceUsed') AS decimal(19,4)) * 8 / 1024. AS space_used_mb,
       CAST(size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS decimal(19,4)) AS space_unused_mb,
       CAST(size AS decimal(19,4)) * 8 / 1024. AS space_allocated_mb,
       CAST(max_size AS decimal(19,4)) * 8 / 1024. AS max_size_mb
FROM sys.database_files;

-- 查询SQL Server数据库 testdb 的日志文件的分配量及使用情况：
SELECT * FROM sys.dm_db_log_space_usage;
SELECT database_id, total_log_size_in_bytes/1.0/1024/1024 AS total_log_size_mb, used_log_space_in_bytes/1.0/1024/1024 AS used_log_space_mb, used_log_space_in_percent FROM sys.dm_db_log_space_usage;
SELECT (total_log_size_in_bytes - used_log_space_in_bytes)*1.0/1024/1024 AS free_log_space_mb FROM sys.dm_db_log_space_usage;

截断日志&收缩日志也可以合并成1条命令执行：

-- 截断日志&收缩日志（减小日志文件大小、释放磁盘空间）
-- DBCC SHRINKFILE (testdb_log, 0); //仅直接截断日志到实际的最小值，日志文件大小不会减小、末尾剩余空间不会释放
-- DBCC SHRINKFILE (testdb_log, TRUNCATEONLY); //仅收缩日志文件，如果成功，文件会减小、释放给磁盘
-- 参数 TruncateOnly 的用处是把：“将文件末尾的所有可用空间释放给操作系统，但不在文件内部执行任何页移动”，上面的语句的作用，只能把文件结尾部分有限的空闲数据页回收。也就不能完全达到数据库收缩的作用了
-- 把截断和收缩操作合并成一条命令执行: DBCC SHRINKFILE (testdb_log, 0, TRUNCATEONLY)
DBCC SHRINKFILE (testdb_log, 0, TRUNCATEONLY);


-- 查询结果状态，可以通过 sys.databases 系统视图查看事务日志不能被截断（被延迟）的原因，
SELECT log_reuse_wait, log_reuse_wait_desc FROM sys.databases WHERE name='testdb';


-- 如果是 LOG_BACKUP 说明需要日志备份，以将日志的头部前移（仅适用于完整恢复模式或大容量日志恢复模式）。日志备份不会妨碍截断。等下次完成日志备份后，日志头部将会前移，从而使得一些日志空间可能变为可重复使用。
BACKUP LOG testdb TO Disk = 'D:\Backup\testdb_log.bak' WITH NOFORMAT, NOINIT, COMPRESSION

相关问题介绍

如果 SQL Server 数据库的事务日志已满（达到了设定的事务日志文件大小的最大值），则 SQL Server 数据库引擎 会发出 9002 错误。 当数据库联机或恢复时，日志可能会满。 
如果日志在数据库处于联机状态时已满，则该数据库仍会保持联机状态，但只能读取，不能更新。 
如果恢复过程中日志已满，则数据库引擎将数据库标记为 RESOURCE PENDING。
不管哪种情况，都需要 DBA 用户执行操作才能使日志空间可用。因此，平时使用过程中，DBA 就应该频繁的进行维护处理，避免日志文件写满。

SQL Server 官方关于解决事务日志已满的问题（SQL Server 错误 9002）的说明参考：

https://learn.microsoft.com/zh-cn/sql/relational-databases/logs/troubleshoot-a-full-transaction-log-sql-server-error-9002?view=sql-server-ver15

导致已满事务日志的常见原因：

对已满事务日志的正确响应取决于导致日志已满的情况。 常见原因包括：
1）日志未截断（生产环境中，即使在简单恢复模式，也可能是由于很早就 Begin Transaction 打开的长事务，还没有 Commit/Rollback 而导致事务一直未关闭，从而导致事务日志截断被阻断，从而导致日志文件一直增长）；
2）磁盘卷已满；
3）日志大小设置为固定的最大值或禁用自动增长；
4）无法完成复制或可用性组同步。

如果是有大事务未关闭而导致日志截断被阻断一直增长，可以手动执行 CHECKPOINT [checkpoint duration] 命令来将缓存中的数据提交写入到 mdf 文件中。指定多长时间内（单位秒）数据库系统完成 checkpoint 操作。

事务日志截断：

关于事务日志截断，官方的说法如下：

日志截断将释放日志文件的空间，以便由事务日志重新使用。 必须定期截断事务日志，防止占满分配的空间。 几个因素可能延迟日志截断，因此监视日志大小很重要。 某些操作可以最小日志量进行记录以减少其对事务日志大小的影响。

日志截断从 SQL Server 数据库的逻辑事务日志中删除不活动的虚拟日志文件 (VLF)，释放逻辑日志中的空间以便物理事务日志重用这些空间。 如果事务日志从不截断，它最终将填满分配给物理日志文件的所有磁盘空间。

为了避免空间不足，除非由于某些原因延迟日志截断，否则将在以下事件后自动进行截断：

1）简单恢复模式下，在检查点之后发生。

2）在完整恢复模式或大容量日志恢复模式下，如果自上一次备份后生成检查点，则在日志备份后进行截断（除非是仅复制日志备份）。

3）首次使用完整恢复模式创建数据库时，事务日志将根据需要重复使用（类似于使用简单恢复模式的数据库），直到创建完整数据库备份为止。

有关详细信息，请参阅本文后面的可能延迟日志截断的因素（https://learn.microsoft.com/zh-cn/sql/relational-databases/logs/the-transaction-log-sql-server?view=sql-server-ver16&redirectedfrom=MSDN#factors-that-can-delay-log-truncation）

日志截断不会减小物理日志文件的大小。 若要减少物理日志文件的物理大小，则必须收缩日志文件。 有关收缩物理日志文件大小的信息，请参阅管理事务日志文件的大小（https://learn.microsoft.com/zh-cn/sql/relational-databases/logs/manage-the-size-of-the-transaction-log-file?view=sql-server-ver16）。 但是，请记住可能延迟日志截断的因素（https://learn.microsoft.com/zh-cn/sql/relational-databases/logs/the-transaction-log-sql-server?view=sql-server-ver16&redirectedfrom=MSDN#factors-that-can-delay-log-truncation）。 如果在日志收缩后还需要存储空间，则会再次增加事务日志，导致在增加日志操作期间产生性能开销。

是什么阻止了日志截断

可以通过查询 sys.databases 目录视图的 log_reuse_wait 和 log_reuse_wait_desc 列：

SELECT log_reuse_wait, log_reuse_wait_desc FROM sys.databases;

有关延迟日志截断的原因的说明，可参考官方说明：

事务日志：https://learn.microsoft.com/zh-cn/sql/relational-databases/logs/the-transaction-log-sql-server?view=sql-server-ver15

可能延迟日志截断的因素：https://learn.microsoft.com/zh-cn/sql/relational-databases/logs/the-transaction-log-sql-server?view=sql-server-ver15#factors-that-can-delay-log-truncation

如何解决事务日志写满的问题

有多重方法来解决该问题：

1）截断日志

  截断日志常见的解决方案是确保为数据库执行事务日志备份，此操作将确保日志被截断。
  
  截断事务日志和收缩事务日志是有区别的：
  
  a）日志截断是一种逻辑操作，通常发生在事务日志备份期间，用于删除日志中已提交的记录；
  
  b）而日志收缩操作，则是通过减小文件大小来回收文件系统上的物理空间。
  
     收缩数据文件通过将数据页从文件末尾移动到更靠近文件开头的未占用的空间来恢复空间。在文件末尾创建足够的可用空间后，可以取消对文件末尾的数据页的分配并将它们返回给文件系统。
  
     若要通过将文件中的可用空间返回到操作系统来减小物理日志文件的物理大小，请收缩日志文件。只有当事务日志文件包含未使用的空间时，收缩才会产生影响。
     
  c）日志截断发生在虚拟日志文件 (VLF) 边界上，并且一个日志文件可能包含许多 VLF。仅当某个日志文件内有可回收的空白空间时，才能收缩该日志文件。
  
  d）仅收缩日志文件并不能解决完整日志文件的问题。相反，必须找出日志文件已满且不能截断的原因。
  
  注意：被移动用来收缩文件的数据可以分布到文件的任何可用位置。 这将导致索引碎片并可能会使搜索索引范围的查询变慢。 若要消除碎片，请考虑在收缩后重新生成文件的索引。
  
  重新生成索引（ALTER INDEX REBUILD），可参考官方介绍：https://learn.microsoft.com/zh-cn/sql/relational-databases/indexes/reorganize-and-rebuild-indexes?view=sql-server-ver15#rebuild-an-index
  
2）将日志文件移至其他更大的磁盘；

3）更改日志大小限制或不设限制启用自动增长：
  如果日志磁盘上具有可用空间，则可以增加日志文件的大小。 日志文件的最大大小是每个日志文件 2 TB。

大部分场景日志文件写满，都是接近或达到了磁盘的存储上限。因此，大部分场景都是需要考虑用截断日志的方案来处理，截断日志文件并收缩日志文件来减小日志文件大小、从而达到回收磁盘空间的效果。
 

DBCC SHRINKFILE 命令介绍

收缩当前数据库的指定数据或日志文件大小
可以使用它将一个文件中的数据移到同一文件组中的其他文件，这会清空文件，从而允许删除数据库。 
可以将文件收缩到小于创建大小，同时将最小文件大小重置为新值。

DBCC SHRINKFILE 命令语法：

DBCC SHRINKFILE   
(  
    { file_name | file_id }   
    { [ , EMPTYFILE ]   
    | [ [ , target_size ] [ , { NOTRUNCATE | TRUNCATEONLY } ] ]  
    }  
)  
[ WITH 
  {     
      [ WAIT_AT_LOW_PRIORITY 
        [ ( 
            <wait_at_low_priority_option_list>
        )] 
      ] 
      [ , NO_INFOMSGS]
  }
]
       
< wait_at_low_priority_option_list > ::=  
    <wait_at_low_priority_option>
    | <wait_at_low_priority_option_list> , <wait_at_low_priority_option>
 
< wait_at_low_priority_option > ::=
    ABORT_AFTER_WAIT = { SELF | BLOCKERS }

DBCC SHRINKFILE 命令参数：

file_name：是已收缩文件的逻辑名称。文件名必须符合标识符的规则。有关更多信息，请参见使用标识符。

file_id：是要收缩的文件的标识 (ID) 号。若要获得文件 ID，请使用 FILE_ID 函数或在当前数据库中搜索 sysfiles。

target_size：是用兆字节表示的所要的文件大小（用整数表示）。如果没有指定，DBCC SHRINKFILE 将文件大小减少到默认文件大小。
如果指定 target_size，DBCC SHRINKFILE 将试图将文件收缩到指定大小。将要释放的文件部分中的已使用页将重新定位到保留的文件部分中的可用空间。
例如，如果数据文件为 10MB，则带有 target_size 为 8 的 DBCC SHRINKFILE 将导致文件最后 2 MB 中所有已用页重新分配到文件前 8 MB 中的任何可用槽中。
DBCC SHRINKFILE 不会将文件收缩到小于存储文件中的数据所需要的大小。例如，如果使用 10MB 数据文件中的7 MB，带有 target_size 为 6 的 DBCC SHRINKFILE 语句只能将该文件收缩到 7 MB，而不能收缩到 6 MB。

EMPTYFILE：将所有数据从指定文件中迁移到同一文件组中的其它文件。SQL Server 不再允许将数据放在用于 EMPTYFILE 选项的文件上。该选项允许使用 ALTER DATABASE 语句除去文件。

NOTRUNCATE ：导致将释放的文件空间保留在文件中。
当与 target_size 一起指定 NOTRUNCATE 时，释放的空间不会释放给操作系统。
DBCC SHRINKFILE 的唯一影响是将已使用的页从 target_size 行上面重新定位到文件的前面。当未指定 NOTRUNCATE 时，所有释放的文件空间返回给操作系统。

TRUNCATEONLY：导致文件中的任何未使用的空间释放给操作系统，并将文件收缩到上一次分配的大小，从而减少文件大小，而不移动任何数据。不尝试将行重新定位到未分配页。如果使用 TRUNCATEONLY，将忽略 target_size。

-- 截断日志（不进行备份而是直接截断，注意风险）
DBCC SHRINKFILE ('YourDatabaseName_log', EMPTYFILE);

-- 收缩日志文件
SELECT file_id, name FROM sys.database_files;
DBCC SHRINKFILE ('YourDatabaseName_log', TRUNCATEONLY);
DBCC SHRINKFILE (file_id/name, TRUNCATEONLY);
-- 参数 TruncateOnly 的用处是把：“将文件末尾的所有可用空间释放给操作系统，但不在文件内部执行任何页移动”，上面的语句的作用，只能把文件结尾部分有限的空闲数据页回收。也就不能完全达到数据库收缩的作用了。

-- 清空文件
-- 下面的示例展示了如何清空文件，这样文件就能从数据库中删除。 为了方便此示例进行展示，先创建包含数据的数据文件
-- Create a data file and assume it contains data.
ALTER DATABASE testdb02
ADD FILE (
    NAME = testdb02_data2,
    FILENAME = 'C:\testdb02_data2.ndf',
    SIZE = 5MB
    );
-- Empty the data file.
DBCC SHRINKFILE (testdb02_data2, EMPTYFILE);
-- Remove the data file from the database.
ALTER DATABASE testdb02 REMOVE FILE testdb02_data2;

-- 切换数据库恢复模式：简单模式 | 完整恢复模式
ALTER DATABASE YourDatabaseName SET RECOVERY SIMPLE;
ALTER DATABASE YourDatabaseName SET RECOVERY FULL;

-- 如果在执行无错误、收缩操作后文件大小未改变，请尝试执行以下操作来验证文件是否有足够的可用空间
SELECT name, size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128.0 AS available_space_mb FROM sys.database_files;

-- 可以通过 sys.databases 系统视图查看事务日志不能被截断的原因
SELECT log_reuse_wait, log_reuse_wait_desc FROM sys.databases WHERE name='testdb';

-- 删除数据文件或日志文件
ALTER DATABASE testdb02 REMOVE FILE testdb02_dat2;
ALTER DATABASE testdb02 REMOVE FILE testdb02_log2;

BACKUP LOG 命令

-- 备份并截断事务日志: Back up the transaction log (full and bulk-logged recovery models)
-- 备份事务日志会自动截断日志
-- 更多 BACKUP 命令的详细介绍，可参考官网介绍：https://learn.microsoft.com/zh-cn/sql/t-sql/statements/backup-transact-sql?view=sql-server-ver16

语法：
BACKUP LOG
  { database_name | @database_name_var }
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { <general_WITH_options> | <log_specific_options> } [ ,...n ] ]
[;]

eg: 
BACKUP LOG YourDatabaseName TO Disk = 'D:\Backup\YourDatabaseLog.bak' WITH NOFORMAT, NOINIT, COMPRESSION

注意：

1，收缩数据文件的影响
数据库使用数据文件（扩展名是 mdf 或 ndf)来存储数据，使用日志文件（扩展名是 ldf）来存储事务日志，通常情况下，数据文件会持续增长，不会自动释放空闲空间，这样会导致硬盘空间耗尽。

如果一个数据库的文件有很多空闲空间，收缩数据库文件是一种解决硬盘空间紧张的直接方式。

原理与影响：

　　在 SQL Server 中，我们可以使用 DBCC ShrinkFile 命令收缩数据文件，该命令首先将文件尾部的区（extent）移动到文件的开头，文件结尾的空闲的硬盘空间被释放给操作系统。

　　这种操作就像截断将文件的尾部一样，这种方式不需要消耗很多IO就能释放空间。

    但是，如果空闲部分不在文件末尾时，收缩操作必须扫描数据文件，并对正在读取的页面加锁，把文件末尾的区移动到文件开头，这是一个IO密集型的操作，影响数据库的性能。
    
    注意：

　　1）收缩操作不是一个独占行为，在做文件收缩时，其他用户仍然可以对数据库进行读写操作；

　　2）收缩会锁表，会阻塞；

　　3）在任意一个时间点停止 dbcc shrinkfile 收缩命令，任何已经完成的工作都将保留。

建议：

    1）收缩数据库是非常耗费server性能的操作，如果没有必要不要收缩；

　　2）收缩无非就是把已经分配给数据库文件空间收回来，但是：收缩的时候要移动数据页，而且可能造成大量的碎片，影响性能；

　　3）日志收缩和数据文件收缩不一样，日志中的VLF（Virtual Log File）虚拟文件状态只有在可复用时候才能收缩。而且凡是有活动的日志的日志虚拟文件都是活动的不能收缩。

    4）如果收缩日志失败，可以通过 sys.databases 系统视图查看事务日志不能被截断的原因。例如：SELECT log_reuse_wait, log_reuse_wait_desc FROM sys.databases WHERE name='testdb';

2，日志中的VLF（Virtual Log File）虚拟文件状态的4种状态（Status）：

    active：     表示VLF中存在活动的事务（即未完成的事务）；
    recoverable：表示VLF中的事务全部已经完成，但是某些操作（例如数据库镜像、复制等）还需要用到这些数据，因此不可以被覆盖；
    reusable：   表示VLF中的数据已经不需要了，可以被覆盖；
    unused：     表示VLF从未被使用。
    
    例如：
    use testdb;
    dbcc loginfo;
    
    执行 dbcc loginfo 的返回信息说明：
    FileID = 2 表示数据库的第2个文件，对于 testdb 这个测试库，第2个文件就是唯一的 LDF 文件。
    FileSize   表示 VLF 的大小。
    FSeqNo     表示 VLF 的序列号，如果为零则表示这个 VLF 未被使用。
    CreateLSN  如果为零表示创建数据库时就同时创建了这些 VLF；如果不为零则表示在 LSN 产生时才创建这个 VLF。
    Status     表示 VLF 的状态。0：则表示这个 VLF 为 reusable 或者 unused。2：则表示这个 VLF 为 active 或者 recoverable。
    
    在简单恢复模式时，自动或手动 checkpoint 操作，以及对数据库做完全备份都会将 recoverable 状态的 VLF 标记成 Status=0，这些VLF可以被不断重用。如果没有大量的事务导致 checkpoint 延迟或者“脏数据”回写延迟，LDF事务日志文件就不需要增长。
　　收缩日志文件时，数据库引擎会检查 VLF 的状态，将 Status=0（即 reusable 和 unused ）的 VLF 所占用的空间释放出来，然后 LDF 再收缩它的边界。

3，收缩数据文件或日志文件的影响
    1）日志文件收缩，回收磁盘空间。
　　2）数据文件根据设计，设计的大小，一般情况不用收缩，收缩可能带来性能的问题。

4，日志增长
　　如果选择的日志恢复模型是完全（FULL）模式，如果没有日志截断，则日志会增长的很大。

5，运维建议
    
    方案1--生产环境最好是定期备份数据库和日志文件
    1）备份日志：BACKUP LOG DBNAME TO disk='备份设备' [with option]
           BACKUP DATABASE testdb TO disk = 'D:\Backup\testdb.bak' WITH NOFORMAT, NOINIT, COMPRESSION;
           BACKUP LOG testdb TO disk = 'D:\Backup\testdb_log.bak' WITH NOFORMAT, NOINIT, COMPRESSION;
           备份日志同时会自动进行日志截断。
　　
    方案2--测试环境可以直接截断日志并收缩日志文件：
    1）截断日志：BACKUP LOG DBNAME WITH NO_LOG;
           注意：
           在低版本中的事务日志截断：在简单恢复模式下，备份了数据库后会自动截断日志；而在完整恢复模式下，只有备份了事务日志后方才截断日志。但是，截断过程有时也可能发生延迟。
           在高版本中的事务日志截断：SQL Server 已经已停用 BACKUP LOG WITH NO_LOG 和 WITH TRUNCATE_ONLY 选项。 高版本中使用完整恢复模式或大容量日志恢复模式时，如果必须删除数据库中的日志备份链，请切换至简单恢复模式。
           例如：SQL Server 高版本已停用 BACKUP LOG WITH NO_LOG 和 WITH TRUNCATE_ONLY，官网有详细介绍 https://learn.microsoft.com/zh-cn/sql/t-sql/statements/backup-transact-sql?view=sql-server-ver16
    
    2）然后收缩日志文件大小：DBCC SHRINKFILE(2, 10);

    最后再释放文件空间给操作系统磁盘：
    DBCC SHRINKFILE(2, TRUNCATEONLY);

6，BACKUP 命令和其他命令的互操作性&影响：

在数据库仍在使用时，SQL Server 使用联机备份过程对数据库进行备份。 在备份过程中，可以进行多个操作；例如：在执行备份操作期间允许使用 INSERT、UPDATE 或 DELETE 语句。

在数据库或事务日志备份的过程中无法运行的操作包括：

  1）文件管理操作，例如带有 ADD FILE 或 REMOVE FILE 选项的 ALTER DATABASE 语句。

  2）收缩数据库或文件操作。 这包括自动收缩操作。

如果备份操作与文件管理或 DBCC SHRINK 操作重叠，则会出现冲突。 无论哪个冲突操作先行开始，第二个操作总会等待第一个操作设置的锁超时（超时期限由会话超时设置控制）。 如果在超时期限内释放锁，第二个操作将继续执行。 如果锁超时，则第二个操作失败。