数据库

在坊间流传的有关AWE的设置的各种版本让人非常困惑。比如说如何设置起作用，如何设置不起作用，在32位和64位上是否需要AWE等

NULL位图是为了确定行中的哪一列是NULL值，哪一列不是。这样做的目的是当Select语句后包含存在NULL值的列时，避免了存储引擎去读所有的行来查看是否是NULL，从而提升了性能

这个误区就有点老生常谈了。每一个主体服务器只允许一个镜像服务器。如果你希望存在多个主体服务器的副本，那么请使用事务日志传送，事务日志传送允许针对每一个主体存在多个辅助实例

在线索引操作会在操作开始时和操作结束时对资源上短暂的锁。这有可能导致严重的阻塞问题

收缩文件的过程非常影响性能，这个过程需要移动大量数据从而造成大量IO，这个过程会被记录到日志从而造成日志暴涨，相应的，还会占去大量的CPU资源

市面上大肆宣传数据库镜像技术可以在故障发生后，立即检测到错误并进行故障转移

数据库镜像的故障转移既可以自动发起，也可以手动发起

TempDB的文件没有必要分布在多个存储器之间。如果你看到PAGELATCH类型的等待，即使你进行了分布也不会改善性能，而如果PAGEIOLATCH型的等待，或许你需要多个存储器，但这也不是必然-有可能你需要讲整个TempDB迁移到另一个存储系统，而不是仅仅为TempDB增加一个

对于兼容模式已经存在了很多误解。80的兼容模式的数据库是否意味着能够附加或恢复到SQL Server 2000数据库?当然不是

当日志文件在手动增长，自动增长和创建时都会进行填零初始化操作。但是请不要把这个过程和定期清除日志的过程搞混

这个误区是由于太多人对日志和恢复系统缺少全面的了解而存在已久。CheckPoint会将自上次CheckPoint以来所有在内存中改变的页写回磁盘(译者注：也就是脏页),或是在上一个CheckPoint读入内存的脏页写入磁盘

我已经听过很多关于数据修复可以做什么、不可以做什么、什么会导致数据损坏以及损坏是否可以自行消失。其实我已经针对这类问题写过多篇博文，因此本篇博文可以作为“流言终结者”来做一个总结，希望你能有收获

从旧的实例升级上来的数据库不会自动开启页校验和，除非你显式使用ALTER DATABASE databasename SET PAGE_VERIFY CHECKSUM进行开启。而在SQL Server 2005或2008新建的数据库页校验和是默认开启的

由于FileStream数据容器(指的是存放FileStream文件的NTFS文件夹，杜撰出来的术语)必须像数据文件或日志文件那样符合本地存储策略-也就是说，这个数据容器必须放在对于运行SQL Server的Windows Server是本地存储

这个误区也同样流传已久，我想是时候通过一些Demo进行揭穿了

事务日志备份会备份自上次事务日志备份以来所有的事务日志(如果从来没有过日志备份的话，那就从上一次完整备份开始)。有好几种类型的操作会中断事务日志的连续性，也就是说除非重新开始新的日志链，SQL Server无法再进行日志备份

SQL Server中没有任何一项操作可以修复数据损坏。损坏的页当然需要通过某种机制进行修复或是恢复-但绝不是通过重启动SQL Server,Windows亦或是分离附加数据库

资源调控器无法调控IO，希望下一个版本的SQL Server支持调控IO，调控IO对于对于减少对于大表的scan操作带来的性能影响很有帮助

在SQL Server 2005和之前的版本，页锁会直接升级到表锁。在SQL Server 2005或SQL Server 2008，你可以通过如下跟踪标志改变锁升级的行为

本系列文章一直所没有触及的就是有关”还原(Restore)”的话题，因为一旦牵扯到这个话题就会涉及大量的误区，多到我无法通过一篇文章说完的地步。