惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Jina AI
Jina AI
Forbes - Security
Forbes - Security
雷峰网
雷峰网
人人都是产品经理
人人都是产品经理
博客园 - 叶小钗
V
Visual Studio Blog
月光博客
月光博客
博客园 - Franky
有赞技术团队
有赞技术团队
宝玉的分享
宝玉的分享
博客园 - 三生石上(FineUI控件)
酷 壳 – CoolShell
酷 壳 – CoolShell
Apple Machine Learning Research
Apple Machine Learning Research
The Register - Security
The Register - Security
S
SegmentFault 最新的问题
博客园 - 司徒正美
P
Proofpoint News Feed
Know Your Adversary
Know Your Adversary
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
A
Arctic Wolf
Cyberwarzone
Cyberwarzone
Simon Willison's Weblog
Simon Willison's Weblog
U
Unit 42
P
Proofpoint News Feed
Scott Helme
Scott Helme
MyScale Blog
MyScale Blog
T
Tenable Blog
Hugging Face - Blog
Hugging Face - Blog
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
小众软件
小众软件
C
CERT Recently Published Vulnerability Notes
P
Palo Alto Networks Blog
V
V2EX
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
T
Tailwind CSS Blog
V
Vulnerabilities – Threatpost
Latest news
Latest news
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
I
Intezer
Microsoft Azure Blog
Microsoft Azure Blog
爱范儿
爱范儿
博客园 - 【当耐特】
B
Blog RSS Feed
N
Netflix TechBlog - Medium
Recent Announcements
Recent Announcements
NISL@THU
NISL@THU
C
Cisco Blogs
C
CXSECURITY Database RSS Feed - CXSecurity.com
S
Schneier on Security

博客园 - nzperfect

PAGELATCH_EX Contention on 2:1:103 SQL Server AlwaysON 同步模式的疑似陷阱 XEvent – SQL Server Log文件对磁盘的写操作大小是多少 SQL Server Log文件对磁盘的写操作大小是多少 Initializing the FallBack certificate failed . TDSSNIClient initialization failed Error after SQL Server 2012 installation: Login Failure for "SQL Server Integration Services 11.0" SSIS service SQL Server 灾难恢复31天之第6天:管理区分配页损坏处理 SQL Server 灾难恢复31天之第5天:处理损坏的非聚集索引 SQL Server 灾难恢复31天之第3天:在还原数据库时确定需要哪些备份文件 SQL Server 灾难恢复31天之第4天:备份 SQL Server 灾难恢复31天之第2天:包含数据库备份在还原时的保护 SQL Server 灾难恢复31天之第1天:DBCC CHECK命令会自动使用已经存在的数据库快照吗? 发布订阅延迟故障排查案例:分发读进程延迟 Query Hint FAST number_rows 改变SQL Server 执行计划 SQL Server 通过界面生成修改列类型脚本时的一个风险(或Bug) 是什么引起执行计划变得极其糟糕? 应该使用更新统计信息来解决它吗? 如何完整的修改一个数据库的名称 How can I bring mirror database online after principal server is down ? performance monitor没有SQL Server性能计数器
update值与原值相同时,SQL Server会真的去update还是忽略呢?
nzperfect · 2012-12-12 · via 博客园 - nzperfect

考虑下面的情况:

当update值与原值相同时,SQL Server会真的去update还是忽略?例如:

update tbname
set name='abc' --name原来的值就是abc
where id=1

再如:

update tbname
set name='abc' --name原来的值就是abc
where name='abc'


接下来我们将实际测试:

--Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64)   Jun 17 2011 00:54:03   Copyright (c) Microsoft Corporation  Enterprise Edition (64-bit) on Windows NT 6.0 <X64> (Build 6002: Service Pack 2) 

 
1.首先我们先把checkpoint关闭掉,这里用到一个TraceFlog 3505,具体信息参见这里

2.准备测试数据:

CREATE DATABASE DB_test 
GO
USE DB_test
GO
CREATE TABLE t (
   a INT,
   b CHAR(1),
   CONSTRAINT PK_t PRIMARY KEY CLUSTERED (a)
);
 
INSERT INTO t VALUES (1,'A');
INSERT INTO t VALUES (2,'B');
INSERT INTO t VALUES (3,'C');
INSERT INTO t VALUES (4,'D');
INSERT INTO t VALUES (5,'E');
 
CHECKPOINT;

3.查看事务日志

SELECT [Current LSN], Operation, Context, [Transaction ID], AllocUnitName
FROM fn_dblog(null, null);

得到如下结果:

此处显示的是之前步骤2的checkpoint的记录,此时只有两条记录

4.此时查看刚创建的表的page情况

DBCC IND ('DB_test','t',1);

结果:

我们可以看到上面的page78是刚才所插入的5条数据所在的page. (PageType=1是DataPage, PageType=10是IAM Page)

5.执行一个update本身的SQL语句,然后再看事务日志,以及内存中的脏数据

UPDATE t
SET b = 'C'
WHERE a =3;
 
-- 查看日志
SELECT [Current LSN], Operation, Context, [Transaction ID], AllocUnitName
FROM fn_dblog(null, null);
 
-- 查看脏数据
select * from sys.dm_os_buffer_descriptors
where database_id = db_id() AND is_modified = 1
order by page_id;

结果如下:

从上面的结果,我们看到有事务日志的记录,但并不是我们的表t,而是sys.sysobjvalues.clst,它是什么呢?从联机文档查到:

sys.sysobjvalues   存在于每个数据库中。实体的每个常规值属性均存在对应的一行。

从事务日志看,SQL Server并没有真的去update这条记录,然后我们看一下脏数据中是否有对这个page的修改:

从上面看到内存中的被修改的Pageid是152,并不是表t的Page78.

由此我们可以认为SQL Server并不会真的去作一个与原值相同的update操作。

6.如果我们此再更新几个与原值相同的操作,如:

UPDATE t
SET b = 'D'
WHERE a =4;
 
-- 查看日志
SELECT [Current LSN], Operation, Context, [Transaction ID], AllocUnitName
FROM fn_dblog(null, null);
 
-- 查看脏数据
select * from sys.dm_os_buffer_descriptors
where database_id = db_id() AND is_modified = 1
order by page_id;

结果如下:

可以看到事务日志没有增加新的记录,脏数据没有变化,依然是刚才的数据。

7.如果我们此时手动checkpoint,然后再做一个update原值操作呢?

Checkpoint
GO
UPDATE t
SET b = 'E'
WHERE a =5;
 
-- 查看日志
SELECT [Current LSN], Operation, Context, [Transaction ID], AllocUnitName
FROM fn_dblog(null, null);
 
-- 查看脏数据
select * from sys.dm_os_buffer_descriptors
where database_id = db_id() AND is_modified = 1
order by page_id;

结果如下:

8.如果我们更新一个不同的值,会是什么情况?

UPDATE t
SET b = 'Z'
WHERE a =1;
 
-- 查看日志
SELECT [Current LSN], Operation, Context, [Transaction ID], AllocUnitName
FROM fn_dblog(null, null);
 
-- 查看脏数据
select * from sys.dm_os_buffer_descriptors
where database_id = db_id() AND is_modified = 1
order by page_id;

结果如下:

我们可以很清楚的看到它的update的Log以及脏数据page.

9.所以,由上面的多个测试结果可以看出,如果update的值与原值相同,SQL Server并不会真的去做一个这样的操作,而是忽略掉了。

10.通过工具ApexSQL也可以证明这个结论,它只记录了insert和最后一次update;

11.最后,记得DBCC TRACEOFF (3505);


此文基本参考:http://www.bobpusateri.com/archive/2010/10/updates-that-really-arent/