专门做冷门旅行的网站,网站群建设的意义,wordpress主题汉化插件,韩国最新新闻消息SQL Server 2012 ldf日志文接太大的截断和收缩日志处理操作
--- SQL Server 2012 ldf日志文接太大的截断和收缩日志处理 ----- 查看所有 database 列表及详情
select * from sys.databases;-- 切换到指定的操作数据库
use testdb;-- 查询当前数据库的日志文件ID和逻辑文件名
S… 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 nametestdb;-- 查看所有数据库的日志文件大小及使用百分比
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 nametestdb;-- 如果是 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?viewsql-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?viewsql-server-ver16redirectedfromMSDN#factors-that-can-delay-log-truncation
日志截断不会减小物理日志文件的大小。 若要减少物理日志文件的物理大小则必须收缩日志文件。 有关收缩物理日志文件大小的信息请参阅管理事务日志文件的大小https://learn.microsoft.com/zh-cn/sql/relational-databases/logs/manage-the-size-of-the-transaction-log-file?viewsql-server-ver16。 但是请记住可能延迟日志截断的因素https://learn.microsoft.com/zh-cn/sql/relational-databases/logs/the-transaction-log-sql-server?viewsql-server-ver16redirectedfromMSDN#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?viewsql-server-ver15
可能延迟日志截断的因素https://learn.microsoft.com/zh-cn/sql/relational-databases/logs/the-transaction-log-sql-server?viewsql-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?viewsql-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_sizeDBCC 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 nametestdb; -- 删除数据文件或日志文件 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?viewsql-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日志收缩和数据文件收缩不一样日志中的VLFVirtual Log File虚拟文件状态只有在可复用时候才能收缩。而且凡是有活动的日志的日志虚拟文件都是活动的不能收缩。 4如果收缩日志失败可以通过 sys.databases 系统视图查看事务日志不能被截断的原因。例如SELECT log_reuse_wait, log_reuse_wait_desc FROM sys.databases WHERE nametestdb; 2日志中的VLFVirtual 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 标记成 Status0这些VLF可以被不断重用。如果没有大量的事务导致 checkpoint 延迟或者“脏数据”回写延迟LDF事务日志文件就不需要增长。 收缩日志文件时数据库引擎会检查 VLF 的状态将 Status0即 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?viewsql-server-ver16 2然后收缩日志文件大小DBCC SHRINKFILE(2, 10); 最后再释放文件空间给操作系统磁盘 DBCC SHRINKFILE(2, TRUNCATEONLY);
6BACKUP 命令和其他命令的互操作性影响
在数据库仍在使用时SQL Server 使用联机备份过程对数据库进行备份。 在备份过程中可以进行多个操作例如在执行备份操作期间允许使用 INSERT、UPDATE 或 DELETE 语句。
在数据库或事务日志备份的过程中无法运行的操作包括 1文件管理操作例如带有 ADD FILE 或 REMOVE FILE 选项的 ALTER DATABASE 语句。 2收缩数据库或文件操作。 这包括自动收缩操作。
如果备份操作与文件管理或 DBCC SHRINK 操作重叠则会出现冲突。 无论哪个冲突操作先行开始第二个操作总会等待第一个操作设置的锁超时超时期限由会话超时设置控制。 如果在超时期限内释放锁第二个操作将继续执行。 如果锁超时则第二个操作失败。
