误区30日谈25-30
--25a) 填充因子是一直存在的
--答案: 错误
--扩展: 填充因子仅仅在索引创建或重建时生效， SQL Server存储引擎并不会一直保证页内的空闲值和填充因子保持一致。
--25 b)填充因子和是不同的
--答案: 错误
--解释：和都表示
--25 c)填充因子设置为会在非叶子节点保留 空间
--答案: 错误
--解释：非叶子节点正常情况下应该填充越高越好，填充越高，非叶子节点的个数和层数会越小
--扩展：PAD_INDEX 选项为ON是 fillfactor 指定的可用空间百分比应用于索引的中间级页
--http://www.cnblogs.com/CareySon/archive/2013/01/18/2866428.html
--误区#26: SQL Server 中存在真正的“事务嵌套”
--答案: 错误
--解释: 这是以编程的思想来看 SQL,无论嵌套多少层，你会发现一个 ROLLBACK将所有操作都回滚
--扩展：如果想事务回滚到某个点，可以使用 SAVE TRAN 和ROLLBACK TRAN 来实现
--无论如何，不要使用”嵌套事务“
--对应公用存储过程，不应该在存储过程中使用事务
--http://www.cnblogs.com/CareySon/archive/2013/01/22/2871204.html
--误区#27: 使用BACKUP ... WITH CHECKSUM可以替代 DBCC CheckDB
--答案: 错误
--解释：
--1. 数据库中可能有部分页没有使用 CHECKSUM
--2. BACKUP WITH CHECKSUM 的备份频率和 CHECKDB的频率可能不一致
--3. CHECKSUM不能发现由于在内存中损坏的页，该页写入前被顺坏，再次读出后 HASH值不会变化，因此不能被发现
--http://www.cnblogs.com/CareySon/archive/2013/01/25/2876741.html
--28 a)常见的DML 操作可以被“最小记录日志”
--答案: 错误
--解释：在大容量日志恢复模式下只有大日志操作才会被最小化日志记录
--常见的大日志操作：BCP+BULK INSERT+SELECT INTO+INSERT SELECT
-- +WRITETEXT and UPDATETEXT+CREATE/ALTER INDEX
--各个版本的大容量日志操作可能不一样
--http://msdn.microsoft.com/en-us/library/ms191244.aspx
--28 b)使用大容量事务日志恢复模式不会影响灾难恢复
--答案: 错误
--解释：大容量事务日志恢复模式的日志备份不能指定时间点还原
--28 c)使用大容量事务日志恢复模式会减少日志备份的大小
--答案: 错误
--解释：日志备份时不仅要备份日志 ,还要需要本分大日志操作修改的数据区 ,因此不会日志备份不会被减小
--扩展: 大容量事务日志恢复模式下 ,对于大日志操作只会写入少量的日志 ,从而提升大日志操作的执行速度
--扩展: 很多功能不允许运行在大容量事务日志恢复模式下
--http://www.cnblogs.com/CareySon/archive/2013/02/17/2913937.html
--误区#29: 可以通过对堆建聚集索引再 DROP后进行堆上的碎片整理
--答案: 错误
--解释：如果堆上有其他索引 ,那么建立再删除会是个灾难 ,建议操作时建立聚集索引并保留使用它
--http://www.cnblogs.com/CareySon/archive/2013/02/17/2913939.html
--30-01)备份操作会导致阻塞
--答案: 错误
--解释：备份时会造成IO压力 ,但不会造成对DML的阻塞特例是当备份包含到那些最小日志操作涉及到的数据区需要被加锁时，这个操作会阻塞 CheckPoint.
--30-02)由完整恢复模式切换到大容量事务日志恢复模式再切换回来会导致日志链断裂
--答案: 错误
--解释: 只有切换到简单恢复模式才会导致日志链断裂
--30-03)只有完整备份才能重新开始被断裂的日志链
--答案: 错误
--解释: 差异备份同样可以
--30-04)在完整或是差异备份时，不允许进行日志备份
--答案: 错误
--解释: 在SQL Server 2005之后，完整或是差异备份的同时可以进行日志备份 ,且不相冲突
--30-05)完整或差异备份会清除日志
--答案: 错误
--解释: 在完整或大容量事务日志恢复模式下，只有备份日志才会清除日志。
--30-06)如果使用大容量事务日志恢复模式中含有了那些最小记录日志的操作，则下一次日志备份的日志会减少
--答案: 错误
--解释: 使用大容量事务日志恢复模式下 ,日志备份需要备份日志+数据 ,因此使得大容量事务日志模式下日志需要备份的内容和完整恢复模式下日志需要备份的内容大小基本一致。
--30-07)完整或差异备份中所包含的日志仅仅是这个操作进行时生成的日志
--答案: 错误
--解释: 完整或差异备份需要日志来将数据库还原到当完整或差异备份结束时的事务一致性状态。
--30-08)备份操作会检查页的校验和
--答案: 错误
--解释: 默认不检查页的校验和 ,需指明WITH CHECKSUM
--30-09)备份通过缓冲区中读取数据
--答案: 错误
--解释: 备份子系统会对数据文件单独开一个通道以避免将所有涉及到的内容读到内存后再存到存储设备，因为如果这样的话备份时性能会严重下降 (因为这涉及到虚拟内存置换回磁盘 )。如果备份时你指定了WITH CHECKSUM，则会涉及到少量内存使用。
--30-11)如果备份成功，那么还原也能成功
--答案: 错误
--解释: 备份文件也会有损坏的情况 ,因此需要定期还原备份来确认备份的可用性
--30-12)即使镜像的路径不可用，镜像备份依然可以成功
--答案: 错误
--解释: 如果镜像中的一个路径失效，那么整个镜像备份都都会失败。我倒是希望这种机制可以改成镜像备份时即使一端路径不可用，那另一端还可以成功备份，但遗憾的是，这不行。
--30-13)任何时候都可以进行尾端日志备份
--答案: 错误
--解释: 如果数据文件受损，并且日志中包含了那些“最小记录日志”的操作，由于此时需要备份日志以及这类“最小记录日志”涉及到的相关区。如果数据文件中的这些区收缩，则无法备份尾端日志。
--30-15)可以备份数据库快照
--答案: 错误
--解释: 不可以
--30-16)可以使用数据库镜像来替代日志备份
--答案: 错误
--解释: 每种技术都有自己的优缺点 ,不能使用镜像啦代替日志备份
--30-17)日志备份所占的大小会和日志所占的大小一致
--答案: 错误
--解释: 日志中包含了需要回滚活动事务的日志。 DBCC SQLPERF (LOGSPACE)所体现出来的日志空间使用并不能正确反映出日志条目所占的空间。
--需要备份的日志部分往往是自上次日志备份以来所有的日志。如果日志大于自上次日志备份以来所有的日志，说明还有长时间活动未结束的事务。
--扩展: 被备份过的日志可能仍需要保留在日志中供其他访问 (如镜像+ 复制)
--30-18)无法备份损坏的数据库
--答案: 错误
--解释: 用WITH CONTINUE_AFTER_ERROR选项来备份损坏的数据库
--30-19)你不能禁止别人进行BACKUP LOG .. WITH NO_LOG 和 TRUNCATE_ONLY操作
--答案: 错误
--解释: 错误，在SQL Server 2005中，的确是这样，但是在 SQL Server 2008中，你可以通过跟踪标记来实现这一点。
--30-20)日志备份无论在什么条件下都会清除日志
--答案: 错误
--解释: 日志备份不会清除日志，但会将 VLF修改为可再使用状态，如果日志还需要被其他访问，日志备份也无法截断日志
--30-21)差异备份是增长式的
--答案: 错误
--解释: 差异备份所备份的数据是自上次完整备份后所有修改的数据区，如果某个区被修改上千次，也只需要备份一次，因此不是累积性的
--扩展：只有事务日志是累积性的
--30-22)当备份完成时，你就可以删除前一个备份了
--答案: 错误
--解释: 需要依情况而定，多保留几个备份没有坏处，如果数据需要还原到很早之前的状态呢？
--30-23)可以备份镜像数据库
--答案: 错误
--解释: 很多人想要这个功能，但是就是没有
--扩展：SQL SERVER 2012 的ALWAYS ON上，可以对从库进行备份
--30-25)备份数据需要关闭SQL Server
--答案: 错误
--解释: 无须解释
--30-26)正在执行的事务只要在备份完成之前提交就一定会包含在这个备份中
--答案: 错误
--解释: 只有在备份的数据读取阶段完成之前提交并写入磁盘的事务才会包含在备份之。
--30-27)在备份之前收缩数据库可以减少备份的大小
--答案: 错误
--解释: 收缩仅仅是移动页，并不会引起备份大小的改变。
--30-29)不需要备份master, msdb, model...等几个系统数据库
--答案: 错误
--解释: 系统数据库也需要备份，在发生修改时应该备份，如 JOB修改+ 登录账号修改等
--30-30)你需要一个好的备份策略
--答案: 错误
--解释: 不仅需要备份，还需要定期验证备份，还需要确认故障发生时如果恢复
--http://www.cnblogs.com/CareySon/archive/2013/02/20/2918203.html
