Paul S. Randal是首屈一指的SQL Server专家，这个关存储备份的系列文章揭示了大多数误区，本系列文章不仅仅是每篇文章所涵盖的知识点，每一篇文章都可以看作一个知识块的切入点。我们团队将这个系列进行了翻译，目录如下，希望你看完有所收获。
误区 #1：在服务器故障转移后，正在运行的事务继续执行
这当然是错误的!
每次故障转移都伴随着某种形式的恢复。但是如果当正在执行的事务没有Commit时，由于服务器或实例崩溃导致连接断开，SQL Server可没有办法在故障转移后的服务器重新建立事务的上下文并继续执行事务-无论你使用的故障转移方式是集，镜像，日志传送或是SAN复制。
对于故障转移集来说，当故障转移发生后，一个SQL Server实例在另一个故障转移集的节点启动。所有实例上的数据库都要经历Recovery阶段-也就是所有没有Commit的事务都要被回滚。
对于数据库镜像来说，来自主体服务器的日志不断传送到镜像服务器进行Redo操作。当镜像服务器被切换作为主体服务器时，原镜像服务器的事务日志将会变为Recovery模式，这使得好像原镜像服务器经历了一次崩溃那样，在这之后所有的连接都会导向原镜像服务器。
对于事务日志传送来说，事务日志被定期备份并传送到辅助服务器.当主服务器崩溃时,DBA按照恢复顺序
将辅助服务器恢复后上线.但最终步骤都是要执行recovery步骤，也就是将没有提交的事务进行回滚。
对于SAN复制来说，本地SAN的I/O被复制到远程SAN上进行重放，当故障转移发生后，系统将会连接到远端SAN但数据库仍然需要执行recovery步骤，这和故障转移集极其类似。
“唯一”使得正在执行的事务在故障转移发生后仍然得以继续执行的技术使用带有实时迁移功能的虚拟化技术，因为这时连接本身并不知道其连接的对象已经变为另一台物理服务器。
但是无论使用那种技术，如果”连接”失效，正在执行的事务将会丢失，所以处理这类问题的这部分工作就需要在程序中用代码实现某种“重新执行”的功能。
误区 #2: DBCC CHECKDB会引起阻塞，因为这个命令默认会加锁
这是错误的！
在SQL Server 7.0以及之前的版本中，DBCC CHECKDB命令的本质是C语言实现的一个不断嵌套循环的代码并对表加表锁(循环嵌套算法时间复杂度是嵌套次数的N次方，作为程序员的你懂得)，这种方式并不和谐，并且…..
析事务日志的方法来检查数据库的一致性的方式重写了DBCC CHECKDB命令。DBCC CHECKDB会
阻止截断日志。当将日志从头读到尾时，在事务日志内部进行了某种Recovery操作，这实际上是另一种全新的实现Recovery的代码，但是仅限于CHECKDB命令内部。但这种方式依然存在问题，比如这个命令存在检查失败的可能性，如果检查失败，你还需要重新执行它看是否还会出现同样的错误。并且有时候，这个命令还会使用SCH_S锁，索然这个锁仅仅阻塞表扫描和表构架的改变，但通过日志来检查一致性的代码也并不是尽善尽美，并且…..
在SQL Server 2005时代，一个叫Paul Randal的家伙（译者：也就是本文作者）再次重写了DBCC CHECKDB命令。这次使用数据库快照来检查一致性（因为数据库快照会提供在数据库某一特定时间点的一致性视图），因此不再有事务日志的分析代码，不再有任何的锁--因为访问数据库快照不需要对原数据库加任何的锁，缓冲池会自动处理可能出现的资源争用。
如果想了解更多内幕消息，你可以阅读下面的文章:
∙CHECKDB From Every Angle: Complete description of all CHECKDB stages超级复制系统百度百科
∙CHECKDB From Every Angle: Why would CHECKDB run out of space?
∙Database snapshots - when things go wrong
∙Issues around DBCC CHECKDB and the use of hidden database snapshots
∙Do transactions rollback when DBCC CHECKDB runs?
∙Diskeeper 10 Intelliwrite corruption bug
现在，在任何SQL Server版本中，如果你依然使用WITH TABLOCK提示，那将会产生表锁来保证事务的一致性。但我不推荐这种方式。因为这种方式不仅需要更长的时间，还将会尝试对数据库加排他锁，但已经活动在数据库的连接有可能导致这种方式失败。
在SQL Server 2000中，这个命令阻止事务日志截断将会导致日志不正常增长的相关问题，但对于SQL Server 2005来说，这个命令就会导致快照相关的问题（具体请看上面的链接）。
但是在默认情况下，自从SQL SERVER 2000之后，DBCC CHECKDB不会再产生阻塞。
误区 #3: 即时文件初始化特性可以在SQL Server中 a)开启和 b)关闭
a)是不允许的 b)是允许的
即时文件初始化是一个在SQL Server 2005以及之上的版本鲜为人知的特性。这个特性允许数据文件(仅仅是数据文件，不包括日志文件)初始化的过程跳过填0初始化过程。这种方式是在发生灾难时大大减少Downtime的好办法---在恢复数据库时由于免去了填0初始化的过程而直接开始恢复过程。
我之前已经写过关于即时文件初始化误区的文章了（见Misconceptions around instant initialization），但这并没有谈到这方面误区。
你并不能在SQL Server中开启这个特性。在SQL Server启动时会检查启动SQL Server的账户是否拥有适当的Windows权限(也就是“执行卷维护任务”这个权限)，当启动SQL Server实例的账户拥有这个权限后，这个特性就会针对这个实例开启，见图1.Kimberly有一篇关于讲述如何开启这个特性细节的文章Instant Initialization - What, Why, and How。
图1.开启执行卷维护任务(Perform Volume Maintenance Tasks )mysql语句的执行顺序
你可以在SQL Server中查看即时文件初始化特性是否开始，通过追踪标志3004(3605可以强制输出错误信息)创建一个数据库，在日志中查看是否有填0操作，如果即时文件初始化有填0初始化操作，则这个特性在SQL Server中并没有开启。
你可以在SQL Server中通过追踪标志1806设置为ON来暂时停止即时文件初始化特性。如果你想永久的禁止这个特性，请把启动SQL Server账户中”执行卷维护任务”这个权限删除。
这两个追踪标志是在SQL Server Premier Field Engineer Blog和How and Why to Enable Instant File Initialization这两篇博文中首次被提到的。
asp源代码怎么操作误区 #4: DDL触发器(SQL Server 2005之后被引入)就是INSTEAD OF触发器
这是错误的
regular fitDDL触发器的实现原理其实就是一个AFTER触发器。这个意思是先发生DDL操作，然后触发器再捕捉操作（当然如果你在触发器内写了Rollback，则也可能回滚）。
存在Rollback也意味着这个触发器并不像你想象的那么轻量，来看下面的例子:
ALTER TABLE MyBigTable ADD MyNewNonNullColumn VARCHAR (20) DEFAULT 'Paul'
如果存在一个defined for ALTER_TABLE事件的DDL触发器，或是一个更宽泛的事件比如
html学多久
DDL_TABLE_EVENTS。上面那个DDL代码将会对表中每一行数据加进新列，之后触发触发器操作。如果你的触发器中存在回滚来阻止DDL操作发生，那么这个代价可不小(不信的话你自己看看这么做后产生的日志)。
当然更好的办法是对ALTER设置GRANT或是DENY权限，或是仅仅允许通过你创建的存储过程进行DDL操作。
但不管怎么样，虽然DDL触发器可以达到禁止DDL的操作的目的，但代价昂贵。而DDL触发器的好处是允许记录某些人做了某些修改表之类的操作，所以我并不是说不允许DDL触发器，而是要小心使用。
Kimberly有一篇非常好的关于DDL触发器的博文："EXECUTE AS" and an important update your DDL Triggers (for auditing or prevention)”。二郎山隧道有部队把守吗
误区 #5: AWE在64位SQL SERVER中必须开启
错误！

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。