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

误区 #30:有关备份的30个误区
全是错的
在开始有关备份的误区之前,如果你对备份的基础没有了解,请看之前我在TechNet Magazine的文章:Understanding SQL Server Backups

30-01)备份操作会导致阻塞
不,备份不会导致对用户对象加锁,虽然备份对IO系统的负担导致看起来阻塞了,但实际上不会。唯一的特例是当备份包含到那些最小日志操作涉及到的数据区需要被加锁时,这个操作会阻塞CheckPoint,但DML操作永远不会受到备份操作的阻塞。

30-02)由完整恢复模式切换到大容量事务日志恢复模式再切换回来会导致日志链断裂
不,这两种模式互相切换不会导致日志链断裂。

30-03)只有完整备份才能重新开始被断裂的日志链
除了完整备份模式可以重新日志链之外,差异备份也可以重新开始日志链-总而言之,日志断裂那部分只要被差异备份所包含,就可以重新开始日志链。详情请看我之前的一篇博文:SQL Server误区30日谈-Day20-破坏日志备份链之后,需要一个完整备份来重新开始日志链

30-04)在完整或是差异备份时,不允许进行日志备份
错误,在SQL Server 2005之后,完整或是差异备份的同时可以进行日志备份,详情请看:Search Engine Q&A #16: Concurrent log and full backups

30-05)完整或差异备份会清除日志
不,因为日志备份包含了自上次日志备份以来所有的日志,这点无可改变,即使这期间的日志被完整或是差异备份所备份。我在Twitter上曾经有一个有名的文章阐述了这点:Misconceptions around the log and log backups: how to convince yourself。总之,在完整或大容量事务日志恢复模式下,只有备份日志才会清除日志。

30-06)如果使用大容量事务日志恢复模式中含有了那些最小记录日志的操作,则下一次日志备份的日志会减少
不,“最小记录日志”之所以这么叫是因为只有涉及到相关的页分配才会被记录到日志。日志备份中必须包含使得这类操作可以回滚的部分,也就是所有日志以及“最小记录日志”操作所涉及的相关区。这使得大容量事务日志模式下日志需要备份的内容和完整恢复模式下日志需要备份的内容大小基本一致。

30-07)完整或差异备份中所包含的日志仅仅是这个操作进行时生成的日志
错误,完整或差异备份需要日志来将数据库还原到当完整或差异备份结束时的事务一致性状态。
下面两篇博文对此有更详细的解释:

30-08)备份操作会检查页的校验和
错误,只有在备份时指定WITH CHECKSUM选项时才会检查校验和,这也是备份应该指定的选项。

30-09)备份通过缓冲区中读取数据
不,备份子系统会对数据文件单独开一个通道以避免将所有涉及到的内容读到内存后再存到存储设备,因为如果这样的话备份时性能会严重下降(因为这涉及到虚拟内存置换回磁盘)。如果备份时你指定了WITH CHECKSUM,则会涉及到少量内存使用。

30-10)备份会进行一致性检查(也就是和DBCC CHECKDB功能一样)
不会,这没什么好说的。

30-11)如果备份成功,那么还原也能成功
错误,希望你不要形成这样的思维定势。你必须定期检查备份以确保在灾难发生时,可以正确的进行还原。详情请看:Importance of validating backups

30-12)即使镜像的路径不可用,镜像备份依然可以成功
错误,如果镜像中的一个路径失效,那么整个镜像备份都都会失败。我倒是希望这种机制可以改成镜像备份时即使一端路径不可用,那另一端还可以成功备份,但遗憾的是,这不行。

30-13)任何时候都可以进行尾端日志备份
错误,尾端日志包含了自上次日志备份以来所有的日志,但这是一种紧急情况,如果数据文件受损,并且日志中包含了那些“最小记录日志”的操作,由于此时需要备份日志以及这类“最小记录日志”涉及到的相关区。如果数据文件中的这些区收缩,则无法备份尾端日志。所以,对于那些24*7的生产环境,永远不要使用大容量日志恢复模式。

30-14)备份可以替代DBCC CheckDB
错误,详情请看SQL Server误区30日谈-Day27-使用BACKUP WITH CHECKSUM可以替代DBCC CheckDB

30-15)可以备份数据库快照
不可以,虽然我也希望可以备份数据库快照。

30-16)可以使用数据库镜像来替代日志备份
不,只有在数据库镜像所基于的数据库可用时,镜像才可用。如果数据库本身被损坏,镜像一般也不会幸免。而数据库本身suspect,数据库镜像往往也会suspect。
当然,由于当数据库中页被修改时,也需要被同步到镜像,因此存在多个镜像对数据库性能的影响会非常大。此外,当数据库中被修改的部分越来越多时,镜像也会不断膨胀。因此无法用镜像代替日志备份。

30-17)日志备份所占的大小会和日志所占的大小一致
错误。日志中包含了需要回滚活动事务的日志。DBCC SQLPERF (LOGSPACE)所体现出来的日志空间使用并不能正确反映出日志条目所占的空间。Search Engine Q&A #25: Why isn't my log backup the same size as my log?。此外,需要备份的日志部分往往是自上次日志备份以来所有的日志。如果日志大于自上次日志备份以来所有的日志,说明还有长时间活动未结束的事务。

30-18)无法备份损坏的数据库
错误,你可以使用WITH CONTINUE_AFTER_ERROR选项来备份损坏的数据库(如果这个选项还不行,可能是boot页或文件头页损坏了),这也是除了OS级别之上的SQL SERVER备份损坏数据库的唯一办法。

30-19)你不能禁止别人进行BACKUP LOG .. WITH NO_LOG 和TRUNCATE_ONLY操作
错误,在SQL Server 2005中,的确是这样,但是在SQL Server 2008中,你可以通过跟踪标记3231来实现这一点。

30-20)日志备份无论在什么条件下都会清除日志
错误。如果日志备份的同时并没有并行执行数据库备份,则日志备份会尝试清除不活动的VLF。对于SQL Server的角度来说,那些没有备份的日志是也就是SQL Server所必须的日志,这类日志不能被清除。因此对于某些特殊情况,虽然进行了日志备份,但SQL Server仍然认为这些日志是必须的,SQL Server会不断检查这些日志直到认为这些日志不再必须,我在TechNet杂志的一篇文章对此有详细的探讨:Understanding Logging and Recovery in SQL Server

30-21)差异备份是增长式的
错误,差异备份所备份的数据是自上次完整备份后所有修改的数据区-所以是积累性质的(译者注:比如说在期间你对用一个数据区进行多次修改,差异备份的大小不会变)。只有日志是增长式的。虽然很多人认为差异备份是积累性质的,但实际不是。

30-22)当备份完成时,你就可以删除前一个备份了
No. No. No.
如果当你还原时发现完整备份已经损坏,此时你就该束手无策了吧。如果此时你没有前一个完整备份,你还是赶紧去招聘网站更新简历吧。你需要按照策略多留几个备份,这样就能有备无患了。

30-23)可以备份镜像数据库
错误,镜像(Mirror)只能通过数据库快照访问。对其也不能进行备份。

30-24)你可以单独备份一个表
错误,如果凑巧这个单独表在一个文件组上,那么你可以通过备份文件组来达到这个目的,但没有所谓的:BACKUP TABLE。

30-25)备份数据需要关闭SQL Server
这个,我真不知道这个谣言从哪来的。(编辑:显然从Oracle来的,因为我们都知道和SQL Server比起来Oracle要强很多:-)。

30-26)正在执行的事务只要在备份完成之前提交就一定会包含在这个备份中
错误,只有在备份的数据读取阶段完成之前提交并写入磁盘的事务才会包含在备份之。详情请看:Search Engine Q&A #6: Using fn_dblog to tell if a transaction is contained in a backup

30-27)在备份之前收缩数据库可以减少备份的大小
错误,收缩仅仅是移动页,并不会引起备份大小的改变。详情请看:Conference Questions Pot-Pourri #10: Shrinking the database before taking a backup。除此之外,还有一篇博文:SQL Server误区30日谈-Day9-数据库文件收缩不会影响性能。不但如此,还有人提醒我说,如果在完整备份之后进行了数据库收缩,则即使数据没有改变,下一次差异备份也会变得巨大。

30-28)从备份进行恢复是当灾难发生时最好的办法
错误,只有当0数据损失时,备份才是灾难恢复最好的办法。但要减少DownTime由备份进行还原并不是一个好办法,如果业务允许,故障转移或允许一些数据损失会更好。

30-29)不需要备份master, msdb, model...等几个系统数据库

错误,这几个系统数据库是需要进行备份的。Master数据库包含了安全信息以及实例上存在哪些数据库。MSDB数据库包含了SSIS的包,代理任务,备份历史。Model数据库包含了新建数据库的模版。不要仅仅只备份用户数据库,否则从头开始配置实例将会非常痛苦。

30-30)你需要一个好的备份策略

错误

我猜想你一定会说”什么”?你需要的是一个好的还原计划,而不是备份计划。根据业务需求和技术限制来决定什么时间还原什么,再根据还原来决定应该什么时间备份什么。请看下面两篇文章:

很多人都做了一个备份策略,但不测试也不想怎么还原。当灾难发生时导致无法还原,希望你不是这样。

(0)

相关推荐

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

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

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

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

  • SQL Server误区30日谈 第27天 使用BACKUP WITH CHECKSUM可以替代DBCC CheckDB

    误区 #27:使用BACKUP ... WITH CHECKSUM可以替代DBCC CheckDB错误    乍一看,由于BACKUP WITH CHECKSUM会检测所有分配出去的页的校验和的值,这个误区貌似是这么回事,但实际上并不是这么回事,原因如下:    由SQL Server 2000或是更早版本升上来的数据库page checksums必须开启,在开启后,并不是数据库中所有的页都会被叫上页校验和,当页损坏发生时,IO系统可不会区分损坏的页是有页校验和还是没有校验和的.所以使用BACK

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

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

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

    误区 #19:Truncate表的操作不会被记录到日志 错误 在用户表中的操作都会被记录到日志.在SQL Server中唯一不会被记录到日志的操作是TempDB中的行版本控制. Truncate Table语句会将整个表中的所有数据删除.但删除的方式并不是一行一行的删除,而是将组成表的数据页释放,将组成表的相关页释放的操作交给一个后台的线程进行队列处理的过程被称为deferred-drop.使用后台线程处理deferred-drop的好处是这个操作不会使得其所在的事务需要执行很长时间,因此也就不

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

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

  • 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 PAGE_VERIFY CHECKSU

  • SQL Server误区30日谈 第28天 有关大容量事务日志恢复模式的误区

    误区 #28:有关大容量事务日志恢复模式的几个误区 28 a)常见的DML操作可以被"最小记录日志"    不是.在大容量事务日志恢复模式下只有一小部分批量操作可以被"最小记录日志",这类操作的列表可以在Operations That Can Be MinimallyLogged找到.这是适合SQL Server 2008的列表,对于不同的SQL Server版本,请确保查看正确的列表. 28 b)使用大容量事务日志恢复模式不会影响灾难恢复    首先,在上次事务日

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

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

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

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

  • 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 DATABASE SET COMPATI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • SQL Server误区30日谈 第26天 SQL Server中存在真正的“事务嵌套”

    误区 #26: SQL Server中存在真正的"事务嵌套"错误 嵌套事务可不会像其语法表现的那样看起来允许事务嵌套.我真不知道为什么有人会这样写代码,我唯一能够想到的就是某个哥们对SQL Server社区嗤之以鼻然后写了这样的代码说:"玩玩你们".    让我更详细的解释一下,SQL Server允许你在一个事务中开启嵌套另一个事务,SQL Server允许你提交这个嵌套事务,也允许你回滚这个事务.    但是,嵌套事务并不是真正的"嵌套",对

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

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

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

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

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

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

  • SQL Server误区30日谈 第25天 有关填充因子的误区

    误区 #25:多个有关填充因子的误区    都是错误的 25a) 填充因子是一直存在的    不是的,通过Books Online可以看到(译者:我在新版的BOL没有找到这句话):重要: 填充因子仅仅在索引创建或重建时生效,SQL Server存储引擎并不会一直保证页内的空闲值和填充因子保持一致.如果为了保证页内的空余值和指定的填充因子保持一直那么填充因子就会失去意义.因为这时页即使不满也需要进行分页. 25 b)填充因子0和100是不同的    错误,由BOL的一句话可以看到    填充因子0

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

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

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

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

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

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

  • 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日谈 第22天 资源调控器可以调控IO

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

随机推荐