SQL Server误区30日谈 第14天 清除日志后会将相关的LSN填零初始化_MsSql

误区 #14.清除日志后会将相关的LSN填零初始化

错误

    当日志文件在手动增长,自动增长和创建时都会进行填零初始化操作。但是请不要把这个过程和定期清除日志的过程搞混。日志截断仅仅意味着将一个或多个VLF标记为不活动以便被重复使用。在日志清除的过程中,并没有任何日志被清除或是填0。“清除日志”和”截断日志”意思是一样的,但都属于用词不当,因为在这个过程中日志的大小不会有任何改变。

    你可以在我的博客中看到有关日志文件填零初始化的博文:Search Engine Q&A #24: Why can't the transaction log use instant initialization?。以及我发布在TechNet杂志的文章:Understanding Logging and Recovery in SQL Server。

    你可以通过跟踪标记3004来查看SQL Server对日志文件进行填零初始化的过程。将这个追踪标记打开当日志文件增长时,你就可以在SQL Server日志中看到相关信息,下面是测试代码:

复制代码 代码如下:

DBCC TRACEON (3004, 3605);
GO
-- Create database and put in SIMPLE recovery model so the log will clear on checkpoint
CREATE DATABASE LogClearTest ON PRIMARY (
NAME = 'LogClearTest_data',
FILENAME = N'D:\SQLskills\LogClearTest_data.mdf')
LOG ON (
NAME = 'LogClearTest_log',
FILENAME = N'D:\SQLskills\LogClearTest_log.ldf',
SIZE = 20MB);
GO
-- Error log mark 1
ALTER DATABASE LogClearTest SET RECOVERY SIMPLE;
GO
USE LogClearTest;
GO
-- Create table and fill with 10MB - so 10MB in the log
CREATE TABLE t1 (c1 INT IDENTITY, c2 CHAR (8000) DEFAULT 'a');
GO
INSERT INTO t1 DEFAULT VALUES;
GO 1280
-- Clear the log
CHECKPOINT;
GO
-- Error log mark 2
ALTER DATABASE LogClearTest SET RECOVERY SIMPLE;
GO

相应的,在日志中你可以看到:

复制代码 代码如下:

2010-04-13 13:20:27.55 spid53 DBCC TRACEON 3004, server process ID (SPID) 53. This is an informational message only; no user action is required.
2010-04-13 13:20:27.55 spid53 DBCC TRACEON 3605, server process ID (SPID) 53. This is an informational message only; no user action is required.
2010-04-13 13:20:27.63 spid53 Zeroing D:\SQLskills\LogClearTest_log.ldf from page 0 to 2560 (0x0 to 0x1400000)
2010-04-13 13:20:28.01 spid53 Zeroing completed on D:\SQLskills\LogClearTest_log.ldf
2010-04-13 13:20:28.11 spid53 Starting up database 'LogClearTest'.
2010-04-13 13:20:28.12 spid53 FixupLogTail() zeroing D:\SQLskills\LogClearTest_log.ldf from 0x5000 to 0x6000.
2010-04-13 13:20:28.12 spid53 Zeroing D:\SQLskills\LogClearTest_log.ldf from page 3 to 63 (0x6000 to 0x7e000)
2010-04-13 13:20:28.14 spid53 Zeroing completed on D:\SQLskills\LogClearTest_log.ldf
2010-04-13 13:20:28.16 spid53 Setting database option RECOVERY to SIMPLE for database LogClearTest.
2010-04-13 13:20:29.49 spid53 Setting database option RECOVERY to SIMPLE for database LogClearTest.

上面测试代码中ALTER DATABASE是作为日志中这部分的开始和结束标记。在两个Alter Database命令中的CheckPoint并不会引起填0操作。如果你需要进一步验证这点,在Checkpoint之前和之后分别使用DBCC SQLPERF (LOGSPACE)来查看日志文件的大小,你会发现虽然日志文件大小没有变,但是日志的使用空间百分比会大大减少。

   (下图是译者测试的结果):

   

时间: 2024-09-20 10:36:12

SQL Server误区30日谈 第14天 清除日志后会将相关的LSN填零初始化_MsSql的相关文章

SQL Server误区30日谈 第20天 破坏日志备份链之后,需要一个完整备份来重新开始日志链_MsSql

误区 #20:在破坏日志备份链之后,需要一个完整备份来重新开始日志链 错误 事务日志备份会备份自上次事务日志备份以来所有的事务日志(如果从来没有过日志备份的话,那就从上一次完整备份开始).有好几种类型的操作会中断事务日志的连续性,也就是说除非重新开始新的日志链,SQL Server无法再进行日志备份.下面这几种操作都有可能引起日志链断裂: 由完整恢复模式或大容量事务日志恢复模式转为简单恢复模式 从数据库镜像进行恢复 备份日志时指定了NO_LOG 或 WITH TRUNCATE_ONLY(还好在S

SQL Server误区30日谈 第30天 有关备份的30个误区_MsSql

误区 #30:有关备份的30个误区全是错的在开始有关备份的误区之前,如果你对备份的基础没有了解,请看之前我在TechNet Magazine的文章:Understanding SQL Server Backups. 30-01)备份操作会导致阻塞不,备份不会导致对用户对象加锁,虽然备份对IO系统的负担导致看起来阻塞了,但实际上不会.唯一的特例是当备份包含到那些最小日志操作涉及到的数据区需要被加锁时,这个操作会阻塞CheckPoint,但DML操作永远不会受到备份操作的阻塞. 30-02)由完整恢

SQL Server误区30日谈 第24天 26个有关还原(Restore)的误区_MsSql

本系列文章一直所没有触及的就是有关"还原(Restore)"的话题,因为一旦牵扯到这个话题就会涉及大量的误区,多到我无法通过一篇文章说完的地步.事实上,我希望用字母表的顺序为每一个误区进行编号,希望你看了不要昏昏欲睡.下面开始揭穿这26个误区. 误区 #24: 26个有关还原(Restore)的误区都是错误的 24 a)可以通过WITH STOPAT参数在完整备份和差异备份的基础上还原到特定时间点当然不能.虽然这个语法看上去貌似能的样子,但这个语法的最佳实践是你在进行日志还原到特定时间

SQL Server误区30日谈 第30天 有关备份的30个误区

误区 #30:有关备份的30个误区 全是错的 在开始有关备份的误区之前,如果你对备份的基础没有了解,请看之前我在TechNet Magazine的文章:Understanding SQL Server Backups. 30-01)备份操作会导致阻塞 不,备份不会导致对用户对象加锁,虽然备份对IO系统的负担导致看起来阻塞了,但实际上不会.唯一的特例是当备份包含到那些最小日志操作涉及到的数据区需要被加锁时,这个操作会阻塞CheckPoint,但DML操作永远不会受到备份操作的阻塞. 30-02)由

SQL Server误区30日谈 第29天 有关堆碎片的误区

误区 #29:可以通过对堆建聚集索引再DROP后进行堆上的碎片整理 Nooooooooooooo!!! 对堆建聚集索引再DROP在我看来是除了收缩数据库之外最2的事了.      如果你通过sys.dm_db_index_physical_stats(或是老版本的DBCC SHOWCONTIG)看到堆上有碎片,绝对不要通过建立聚集索引再删除聚集索引来整理堆碎片.好的做法应该是建立聚集索引之后不再删除,已经有非常多的资料阐述如何选择一个理想的聚集索引键--窄,很少变动,唯一,自增.Kimberly

SQL Server误区30日谈 第5天 AWE在64位SQL SERVER中必须开启_MsSql

误区 #5: AWE在64位SQL SERVER中必须开启 错误!     在坊间流传的有关AWE的设置的各种版本让人非常困惑.比如说如何设置起作用,如何设置不起作用,在32位和64位上是否需要AWE等.   好吧,我来概括一下:     在64位系统(SQL SERVER 2005+版本) AWE是不需要的(即使是ON状态,也毫无影响) 开启"锁定内存页"使得缓冲池中的内存页不会被置换到虚拟内存中(实际上所有的Single Page Allocator分配和Stolen的内存都不会被

SQL Server误区30日谈 第3天 即时文件初始化特性可以在SQL Server中开启和关闭_MsSql

本系列文章是我在sqlskill.com的PAUL的博客看到的,很多误区都比较具有典型性和代表性,原文来自T-SQL Tuesday #11: Misconceptions about.... EVERYTHING!!,经过我们团队的翻译和整理发布在AgileSharp和博客园上.希望对大家有所帮助. 误区 #3: 即时文件初始化特性可以在SQL Server中 a)开启 和 b)关闭 a)是不允许的  b)是允许的     即时文件初始化是一个在SQL Server 2005以及之上的版本鲜为

SQL Server误区30日谈 第5天 AWE在64位SQL SERVER中必须开启

误区 #5: AWE在64位SQL SERVER中必须开启 错误! 在坊间流传的有关AWE的设置的各种版本让人非常困惑.比如说如何设置起作用,如何设置不起作用,在32位和64位上是否需要AWE等. 好吧,我来概括一下: 在64位系统(SQL SERVER 2005+版本) AWE是不需要的(即使是ON状态,也毫无影响) 开启"锁定内存页"使得缓冲池中的内存页不会被置换到虚拟内存中(实际上所有的Single Page Allocator分配和Stolen的内存都不会被置换) 当开启&qu

SQL Server误区30日谈 第7天 一个实例多个镜像和日志传送延迟_MsSql

误区 #7:一个数据库可以存在多个镜像 错误 这个误区就有点老生常谈了.每一个主体服务器只允许一个镜像服务器.如果你希望存在多个主体服务器的副本,那么请使用事务日志传送,事务日志传送允许针对每一个主体存在多个辅助实例. 使用事务日志传送的一个优点是允许其中一个或多个辅助服务器存在延迟还原备份.这也是就是说对主体服务器进行日志备份(无论你喜欢与否,这几种高可用性技术各自有各自的术语): 数据库镜像:主体服务器-镜像服务器 事务日志传送:主要服务器-辅助服务器 复制:发布服务器-订阅服务器 当使用镜