Welcome 微信登录

首页 / 数据库 / SQLServer

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

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

理解SQL Server对于内存的管理是对于SQL Server问题处理和性能调优的基本,本篇文章讲述SQL Server对于内存管理的内存原理。二级存储(secondary storage) 对于计算机来说,存储体系是分层级的。离CPU越近的地方速度愉快,但容量越小(如图1所示)。比如:传统的计算机存储体系结构离CPU由近到远依次是:CPU内的寄存器,一级缓存,二级缓存,内存,硬盘。但同时离CPU越远的存储系统都会比之前的存储系统大一个数量级。比如硬...
SQL Server误区30日谈 第5天 AWE在64位SQL SERVER中必须开启

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的内存都...
SQL Server误区30日谈 第6天 有关NULL位图的三个误区

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

误区 #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填零初始化

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

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

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

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

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

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

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

其实我之前已经有文章详细解释了页校验和: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的存储,垃圾回收以及其它

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

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

SQL Server误区30日谈 第19天 Truncate表的操作不会被记录到日志

误区 #19:Truncate表的操作不会被记录到日志 错误 在用户表中的操作都会被记录到日志。在SQL Server中唯一不会被记录到日志的操作是TempDB中的行版本控制。 Truncate Table语句会将整个表中的所有数据删除。但删除的方式并不是一行一行的删除,而是将组成表的数据页释放,将组成表的相关页释放的操作交给一个后台的线程进行队列处理的过程被称为deferred-drop。使用后台线程处理deferred-drop的好处是这个操作不会使得...
SQL Server误区30日谈 第20天 破坏日志备份链之后,需要一个完整备份来重新开始日志链

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

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

SQL Server误区30日谈 第21天 数据损坏可以通过重启SQL Server来修复

误区 #21:数据库损坏可以通过重启SQL Server或是Windows,或是附加和分离数据库解决 错误 SQL Server中没有任何一项操作可以修复数据损坏。损坏的页当然需要通过某种机制进行修复或是恢复-但绝不是通过重启动SQL Server,Windows亦或是分离附加数据库。 而实际上,如果你的数据库的损坏程度无法进行Crash Recovery的话(质疑状态),那么分离附加数据库将会是你做的最糟糕的决定。这个原理是由于附加数据库中包含Crash...
SQL Server误区30日谈 第22天 资源调控器可以调控IO

SQL Server误区30日谈 第22天 资源调控器可以调控IO

误区 #22: 资源调控器可以调控IO错误资源调控器无法调控IO,希望下一个版本的SQL Server支持调控IO,调控IO对于对于减少对于大表的scan操作带来的性能影响很有帮助。下面列表中的功能资源调控器同样也无法完成:调控Buffer Pool的内存,内存调控器仅仅可以调控执行计划所占的内存,但对于Buffer Pool中缓存的数据页是无法调控的可以对多个实例进行当作一个逻辑实体进行资源调控。这是不能的,对于多实例的资源调控只能通过Windows S...
SQL Server误区30日谈 第23天 有关锁升级的误区

SQL Server误区30日谈 第23天 有关锁升级的误区

误区 #23: 锁升级的过程是由行锁升级到页锁,再由页锁升级到表锁错误实际不是,在SQL Server 2005和之前的版本,页锁会直接升级到表锁。在SQL Server 2005或SQL Server 2008,你可以通过如下跟踪标志改变锁升级的行为:标志1211-完全禁止锁升级,但锁使用的内存会被限制在动态分配内存的60%,当超过这个值时,更多的锁将会伴随着内存溢出错误而失败。标志1224-禁止锁升级,但内存使用超过40%时,会自动开启锁升级如果标志1...
<< 121 122 123 124 125 126 127 128 129 130 >>