浅谈SQL Server中的三种物理连接操作（性能比较）

2016年07月27日 32 阅读

在SQL Server中，我们所常见的表与表之间的Inner Join,Outer Join都会被执行引擎根据所选的列，数据上是否有索引，所选数据的选择性转化为Loop Join,Merge Join,Hash Join这三种物理连接中的一种。理解这三种物理连接是理解在表连接时解决性能问题的基础，下面我来对这三种连接的原理，适用场景进行描述。 嵌套循环连接（Nested Loop Join） 循环嵌套连接是最基本的连接,正如其名所示那样，需要进行循环嵌套，...

SQL Server误区30日谈 第1天 正在运行的事务在服务器故障转移后继续执行

2016年07月27日 30 阅读

误区 #1：在服务器故障转移后，正在运行的事务继续执行 这当然是错误的！ 每次故障转移都伴随着某种形式的恢复。但是如果当正在执行的事务没有Commit时，由于服务器或实例崩溃导致连接断开，SQL Server可没有办法在故障转移后的服务器重新建立事务的上下文并继续执行事务-无论你使用的故障转移方式是集群，镜像，日志传送或是SAN复制。 对于故障转移集群来说，当故障转移发生后，一个SQL Server实例在另一个故障转移集群的节点启动。所有实例上的数据库都要...

SQL Server误区30日谈 第2天 DBCC CHECKDB会导致阻塞

2016年07月27日 30 阅读

误区 #2: DBCC CHECKDB会引起阻塞，因为这个命令默认会加锁这是错误的！ 在SQL Server 7.0以及之前的版本中，DBCC CHECKDB命令的本质是C语言实现的一个不断嵌套循环的代码并对表加表锁（循环嵌套算法时间复杂度是嵌套次数的N次方,作为程序员的你懂得）,这种方式并不和谐,并且….. 在SQL Server 2000时代，一个叫Steve Lindell的哥们（现在仍然在SQL Server Team）使用分析事务日志的方法来检查...

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

2016年07月27日 33 阅读

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

SQL Server误区30日谈 第4天 DDL触发器就是INSTEAD OF触发器

2016年07月27日 31 阅读

误区 #4: DDL触发器（SQL Server 2005之后被引入）就是INSTEAD OF触发器这是错误的 DDL触发器的实现原理其实就是一个AFTER触发器。这个意思是先发生DDL操作，然后触发器再捕捉操作（当然如果你在触发器内写了Rollback,则也可能回滚）。 存在Rollback也意味着这个触发器并不像你想象的那么轻量，来看下面的例子: ALTER TABLE MyBigTable ADD MyNewNonNullColumn VARCHAR...

浅谈SQL Server 对于内存的管理[图文]

2016年07月27日 32 阅读

理解SQL Server对于内存的管理是对于SQL Server问题处理和性能调优的基本，本篇文章讲述SQL Server对于内存管理的内存原理。二级存储（secondary storage） 对于计算机来说，存储体系是分层级的。离CPU越近的地方速度愉快，但容量越小（如图1所示）。比如：传统的计算机存储体系结构离CPU由近到远依次是:CPU内的寄存器，一级缓存，二级缓存，内存，硬盘。但同时离CPU越远的存储系统都会比之前的存储系统大一个数量级。比如硬...

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

2016年07月27日 30 阅读

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

SQL Server误区30日谈 第6天 有关NULL位图的三个误区

2016年07月27日 34 阅读

这样还能减少CPU缓存命中失效的问题（点击这个链接来查看CPU的缓存是如何工作的以及MESI协议）。下面让我们来揭穿三个有关NULL位图的普遍误区。 误区 #6a:NULL位图并不是任何时候都会用到 正确 就算表中不存在允许NULL的列，NULL位图对于数据行来说会一直存在（数据行指的是堆或是聚集索引的叶子节点）。但对于索引行来说（所谓的索引行也就是聚集索引和非聚集索引的非叶子节点以及非聚集索引的叶子节点）NULL位图就不是一直有效了。 下面这条语句可以有...

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

2016年07月27日 34 阅读

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

SQL Server误区30日谈 第8天 有关对索引进行在线操作的误区

2016年07月27日 31 阅读

误区 #8: 在线索引操作不会使得相关的索引加锁错误！ 在线索引操作并不是想象的那么美好。 在线索引操作会在操作开始时和操作结束时对资源上短暂的锁。这有可能导致严重的阻塞问题。 在线索引操作开始时,会在被整理的资源上加一个共享的表锁,这个表锁在会在新的索引创建时、老索引进行版本扫描时一直持续。 但问题是，这个S锁会和表上的其它锁排成锁队列。这也就是意味着和S锁不兼容的其它锁在表上存在S锁或是表上的锁队列存在中包含S锁时，这类和S锁不兼容的锁操作也需要等待。...

SQL Server误区30日谈 第9天 数据库文件收缩不会影响性能

2016年07月27日 31 阅读

误区 #9: 数据库文件收缩不会影响性能错误！ 收缩数据库文件唯一不影响性能的情况是文件末尾有剩余空间的情况下，收缩文件指定了TruncateOnly选项。 收缩文件的过程非常影响性能，这个过程需要移动大量数据从而造成大量IO，这个过程会被记录到日志从而造成日志暴涨，相应的，还会占去大量的CPU资源。 不仅在收缩的过程中影响性能，并且在文件收缩之后同样影响应能，收缩产生的大量日志会被事务日志传送，镜像，复制能操作重复执行。而空间不够时，文件还需要填0初始化...

SQL Server误区30日谈 第10天 数据库镜像在故障发生后 马上就能发现

2016年07月27日 39 阅读

误区10.数据库镜像在故障发生后，马上就能发现 错误 市面上大肆宣传数据库镜像技术可以在故障发生后，立即检测到错误并进行故障转移。 但事实并不是这样，检测到故障发生的速度要取决于故障的类型。 检测故障发生的最快的情况是，镜像中的主体实例崩溃，从而镜像服务器每秒一次的PING就无法返回值，从而知道主体服务器上不再有这个进程侦听相应的TCP端口，这种情况下，镜像服务器几乎瞬间就能发现故障。 检测到故障发生第二快的情况是主体服务器的操作系统崩溃。此时主体服务器不...

SQL Server误区30日谈 第11天 镜像在检测到故障后瞬间就能故障转移

2016年07月27日 32 阅读

误区 #11:镜像在检测到故障后瞬间就能故障转移错误 数据库镜像的故障转移既可以自动发起，也可以手动发起。 在自动发起的情况下,是由镜像服务器执行故障转移操作（你没有看错，并不是由见证服务器来做故障转移的决定）,在见证服务器和镜像服务器都发现无法和主体服务器交换信息（这个过程被称为”形成仲裁”,译者注:也就是通过程序对集群进行监管，集群可用的依据来自监管程序的算法，比如根据:每个节点的配置，文件共享情况，磁盘访问情况，每个节点的可用性等来确定集群是否可用）...

SQL Server误区30日谈 第12天 TempDB的文件数和需要和CPU数目保持一致

2016年07月27日 30 阅读

误区 #12:TempDB的文件数和需要和CPU数目保持一致错误 哎，由于上述误区是微软“官方”的建议，并且还有大量博文坚持这个观点，这个误区已经是老生常谈。 但让人困惑的是SQL CAT团队给出的建议就是1：1，但这个建议是源自扩展方面的原理来说,而不是一个通用法则。因为他们所面对的大型客户数据量服务器和IO子系统都是大部分人没有机会遇到的。 每个实例仅仅允许有一个TempDb,但需要用到TempDB的地方却有很多，所以TempDB很容易成为性能瓶颈，我...

SQL Server误区30日谈 第13天 在SQL Server 2000兼容模式下不能使用DMV

2016年07月27日 31 阅读

误区 #13.在SQL Server 2000兼容模式下不能使用DMV错误 对于兼容模式已经存在了很多误解。80的兼容模式的数据库是否意味着能够附加或恢复到SQL Server 2000数据库？当然不是。这只是意味着一些T-SQL的语法，查询计划的行为以及一些其它方面和SQL Server 2000中行为一样（当然，如果你设置成90兼容模式则和SQL Server 2005中一样）。 在SQL Server 2008中，你可以使用ALTER DATABA...

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

2016年07月27日 30 阅读

误区 #14.清除日志后会将相关的LSN填零初始化错误 当日志文件在手动增长，自动增长和创建时都会进行填零初始化操作。但是请不要把这个过程和定期清除日志的过程搞混。日志截断仅仅意味着将一个或多个VLF标记为不活动以便被重复使用。在日志清除的过程中，并没有任何日志被清除或是填0。“清除日志”和”截断日志”意思是一样的，但都属于用词不当，因为在这个过程中日志的大小不会有任何改变。 你可以在我的博客中看到有关日志文件填零初始化的博文：Search Engine ...

SQL Server误区30日谈 第15天 CheckPoint只会将已提交的事务写入磁盘

2016年07月27日 33 阅读

误区 #15:CheckPoint只会将已提交的事务写入磁盘 错误 这个误区是由于太多人对日志和恢复系统缺少全面的了解而存在已久。CheckPoint会将自上次CheckPoint以来所有在内存中改变的页写回磁盘（译者注：也就是脏页）,或是在上一个CheckPoint读入内存的脏页写入磁盘。无论事务是否已经提交，其所影响的页都会在Checkpoint时写回磁盘。但对于TempDB来说例外，因为TempDB的Checkpoint的事件周期中并不包含将脏页写回...

SQL Server误区30日谈 第16天 数据的损坏和修复

2016年07月27日 35 阅读

误区 #16:多个关于数据的损坏和修复误区 坊间流传的很多版本都不正确 我已经听过很多关于数据修复可以做什么、不可以做什么、什么会导致数据损坏以及损坏是否可以自行消失。其实我已经针对这类问题写过多篇博文，因此本篇博文可以作为“流言终结者”来做一个总结，希望你能有收获。首先，对于数据修复可以做什么，不可以做什么，我已经写过一篇博文Misconceptions around database repair涵盖了13个误区—从不用DBCC CHECKDB是否能修...

SQL Server误区30日谈 第17天 有关页校验和的误区

2016年07月27日 31 阅读

其实我之前已经有文章详细解释了页校验和：How to tell if the IO subsystem is causing corruptions？ 误区 #17:几个有关页校验和的误区坊间流传的基本是错误的 17 a）页校验和（Page CheckSum）在从SQL Server 2000或7.0升级上来之后自动开启 其实不是，从旧的实例升级上来的数据库不会自动开启页校验和，除非你显式使用ALTER DATABASE databasename SET ...

SQL Server误区30日谈 第18天 有关FileStream的存储，垃圾回收以及其它

2016年07月27日 34 阅读

误区 #18:如下多个有关FileStream的误区全部错误18 a）FileStream数据可以在远程存储 不能，由于FileStream数据容器（指的是存放FileStream文件的NTFS文件夹，杜撰出来的术语）必须像数据文件或日志文件那样符合本地存储策略-也就是说，这个数据容器必须放在对于运行SQL Server的Windows Server是本地存储（译者注：也就是在‘计算机"里能看到的存储，DAC当然是了，其实SAN这类不直接连接服务器的也算是...