名站网址导航为大家提供关于数据库教程相关的教程网站知识。
误区 #30：有关备份的30个误区SQL Server误区30日谈 第29天 有关堆碎片的误区
全是错的
在开始有关备份的误区之前，假如如果您对备份的基础没有了解，请看之前我在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)完整或差异备份中所包含的日志仅仅是这个操作办法进行时生成的日志
错误，完整或差异备份需要日志来将网站数据库还原到当完整或差异备份结束时的事务一致性状态。
下面两篇博文对此有更详细的解释:
错误，只有在备份时指定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)您需要一个好的备份策略
错误
我猜想您一定会说”什么”?您需要的是一个好的还原计划，而不是备份计划。根据业务需求和技术限制来决定什么时间还原什么，再根据还原来决定应该什么时间备份什么。请看下面两篇文章:
