维护VLDB最佳建议清单之存储篇
维护VLDB对DBA来说是一项挑战。它涉及诸多方面。对此，SQL Server Storage Team的大佬Paul和SQLSkills.com公司创始人Kimberly提出如下建议。
原文见：
- Have page checksums turned on
- Make sure auto-stats update is turned on
- Pay attention to index fragmentation
- Logical fragmentation only affects read-ahead performance
- Only rebuild/defrag indexes that have this will help
- Low page density affects IO throughput and memory usage
- Low page density could be a sign of page-splits, so investigate the cause
- If you defrag instead of rebuild, make sure you manually update stats
- Be wary of doing large index maintenance jobs if you use log shipping or DBM
- They contribute to large log backups
- Index rebuilds are always full-logged when DBM is present
- They contribute to large log backups
- Make sure all indexes are actually needed
- See http://blogs.msdn.com/sqlserverstorageengine/archive/2007/04/20/how-can-you-tell-if-an-index-is-being-used.aspx
- Run adequate consistency checks
- See http://blogs.msdn.com/sqlserverstorageengine/archive/2007/04/20/how-can-you-tell-if-an-index-is-being-used.aspx
- Even a VVVVLDB can be checked for corruptions
- See http://blogs.msdn.com/sqlserverstorageengine/archive/2006/10/20/consistency-checking-options-for-a-vldb.aspx
- Have a disaster recovery plan
- See http://blogs.msdn.com/sqlserverstorageengine/archive/2006/10/20/consistency-checking-options-for-a-vldb.aspx
- Test it before you have to use it
- Make sure the most junior DBA can follow it
- See http://blogs.msdn.com/sqlserverstorageengine/archive/2007/04/17/example-corrupt-database-to-play-with.aspx
- Logical fragmentation only affects read-ahead performance
- Understand your SLAs
- Have a backup strategy that allows you meet your SLAs
- E.g. Weekly full backups with no HA solution only won’t allow you to meet zero data-loss SLAs
- E.g. Weekly full backups with no HA solution only won’t allow you to meet zero data-loss SLAs
- Make sure tempdb is optimized for the workload
- Make sure you’re managing the transaction log correctly
- E.g. being in full recovery mode with no log backups means you’ll eventually run out of space on the log drive
- Don’t have multiple log files – no need
- Don’t let auto-grow go nuts – causes VLF fragmentation which leads to horrible perf
- E.g. being in full recovery mode with no log backups means you’ll eventually run out of space on the log drive
- Don’t run database shrink
- See http://blogs.msdn.com/sqlserverstorageengine/archive/2007/04/15/how-to-avoid-using-shrink-in-sql-server-2005.aspx
- Don’t rely on auto-grow
- Pro-actively manage file growth but have auto-grow on as a safeguard
- See http://blogs.msdn.com/sqlserverstorageengine/archive/2007/04/15/how-to-avoid-using-shrink-in-sql-server-2005.aspx
- Consider turning on Instant Initialization to speed up file growth and restores
作者有些地方介绍的很简略，看看有多少不理解的？我将其翻译和解释一下（蓝色文字为我的解释）。
l 启用磁盘校验和
磁盘校验和选项可保护磁盘数据不致因硬件问题导致数据不可用。SQL Server2005中，该选项默认为开启。SQL Server2000中，默认开启比Checksum较低一级的安全保护项。
l 设置自动更新统计
统计信息可有助于查询优化器更好地评估查询计划。
l 注意索引碎片
（1） 逻辑碎片影响主要是预读性能
索引叶级别的页如果物理上不连续称为逻辑碎片。例如一个索引叶级别包含3页磁盘空间，对应的页号如果是2、3、4，则表明索引是连续的。但如果对应的页号顺序是2、4、5，page 3 被分配给其它索引，则出现了逻辑碎片。与之相对的另一种碎片是区碎片(Extend Fragmentation)，指的是堆中两个物理上连续的区（一个区包含8个页）未被分配给同一个对象（例如表或者索引等）。
预读是在物理读取数据时，如果连续读取了第1、2两页，则系统预测下一步可能也需读取第3页，而顺便把第3页也读取到内存。出现预读时，所预读的页并不被计算为物理读。这样，一次物理读实际上可以读取多达512KB的数据（即64页）。但这些数据必须是物理上连续的。现实中，在有索引的表上发生扫描操作时（Clustered Index Scan或者Non Clustered Index Scan），可能发生预读，预读实际上也提高了读取效率。
显然，逻辑碎片的存在可能导致在预读时物理读数增加。但对于非预读的情况，每次读取一页都会计算为一次物理读。因此，这里逻辑碎片只影响预读的效率。（相关内容参阅联机丛书以及如下URL:
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx）
（2） 重建索引或者整理索引碎片可解决此问题。
可以使用DBCC SHOWCONFIG或者通过sys.db_db_index_physical_stats来查看索引碎片信息。对于索引碎片的消除，有三种方式：一是删除重新创建聚集索引，二是使用ALTER INDEX REORGANIZE（SQL2000中为DBCC INDEXDEFRAG）对索引叶级别重新排序，此方法对于正执行的语句可继续使用索引，但效果有时不很好，且不更新统计信息。另外可使用 ALTER INDEX REBUILD（SQL2000中为 DBCC DBREINDEX）重新生成索引。
（3）较低的页密度影响IO吞吐量和内存使用率。
原因见4。每次操作可能有更多的页被读入内存。
（4）较低的页密度可能导致更多的页拆分。
页密度低则每一页只能存储较少数据。
（5）如果重组索引碎片而不是重建索引，一定要手工修正统计信息。
（6）若使用Log-shipping或者镜像，则应谨慎对待大索引的维护
――考虑对大规模日志备份的影响
――数据镜像情况下，重建索引将产生完全日志行为。
使用LogShipping，则表明为完全恢复模式或者大容量恢复模式。而使用DBM只能为完全恢复模式，此时，维护索引而被系统记录的事务日志最多。而在简单恢复模式最少。所以，实际在做索引碎片消除时，常把数据库模式设置成简单模式待维护后再修改回来。
（7）确定索引实际被使用了
--链接的文章介绍了如何确定。
--进行适当的一致性检查。
（8）对VVVVLDB也能够进行完整性检查
--推荐的文章介绍了如何对VLDB进行完整性检查。
--设计灾难恢复方案。
（9）在使用前进行测试
（10）确定最初级的DBA也可以照招规范做好
似乎在说灾难恢复方案？
（11）链接的文章介绍了如何使用DBCC CHECKDB修正数据库错误。
l 理解你的服务水平协议
服务水平协议简而言之是DBA与客户或者雇主之间就维护数据库系统应该达到标准的约定。例如要求灾难时最多允许15分钟的数据丢失、20分钟当机时间。
l 根据服务水平协议制定合适的备份策略
例如每周进行全备而没有其它高可用性方案并不适合0数据丢失的SLAs。
l 确保正确管理事务日志
（1）例如完全恢复模式而没有进行日志备份则会让日志驱动器空间填满。
（2）不要用多个日志文件-不需要。
日志文件和数据文件不同，对于数据文件，适当分布成多个文件（尤其是通过磁盘条带化等)，可以提高读写性能，因为可以并发防问多个文件。但对于日志文件，SQLServer采取的是填充到满的策略，即先将某个文件填满再填充其它文件。因此，多个日志文件并不能提高性能，反而为备份、恢复等增加了困难。
现实中，有时候会出现日志空间满了的情况下，紧急增加一个日志文件情况。此情况下，建议在可能的时候还是通过备份事务日志截断日志，然后在收缩日志文件时使用EMPTYFILE选项将某个日志文件清空，再通过ALTER DATABASE方式删除无用的日志文件。
（3）不要使用日志自动增长--大日志文件增长将产生可怕的性能问题
l 不要进行数据库收缩
--介绍了如何避免数据库收缩。
--不要依赖自动增长
--预先将文件设置到足够大，自动增长只是作为保护
l 考虑启用实例初始化选项
--实例初始化在数据文件创建时使用0值来初始化文件。可大大缩短数据库文件的创建、维护。
