维护VLDB最佳建议清单之存储篇

维护VLDBDBA来说是一项挑战。它涉及诸多方面。对此,SQL Server Storage Team的大佬PaulSQLSkills.com公司创始人Kimberly提出如下建议。

 

原文见:

http://blogs.msdn.com/sqlserverstorageengine/archive/2007/04/30/very-quick-list-of-vldb-maintenance-best-practices.aspx

作者有些地方介绍的很简略,看看有多少不理解的?我将其翻译和解释一下(蓝色文字为我的解释)。

 

l  启用磁盘校验和

磁盘校验和选项可保护磁盘数据不致因硬件问题导致数据不可用。SQL Server2005中,该选项默认为开启。SQL Server2000中,默认开启比Checksum较低一级的安全保护项。

l  设置自动更新统计

统计信息可有助于查询优化器更好地评估查询计划。

l  注意索引碎片

(1)       逻辑碎片影响主要是预读性能

索引叶级别的页如果物理上不连续称为逻辑碎片。例如一个索引叶级别包含3页磁盘空间,对应的页号如果是234,则表明索引是连续的。但如果对应的页号顺序是245page 3 被分配给其它索引,则出现了逻辑碎片。与之相对的另一种碎片是区碎片(Extend Fragmentation),指的是堆中两个物理上连续的区(一个区包含8个页)未被分配给同一个对象(例如表或者索引等)。

 

预读是在物理读取数据时,如果连续读取了第12两页,则系统预测下一步可能也需读取第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 REORGANIZESQL2000中为DBCC INDEXDEFRAG)对索引叶级别重新排序,此方法对于正执行的语句可继续使用索引,但效果有时不很好,且不更新统计信息。另外可使用 ALTER INDEX REBUILDSQL2000中为 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值来初始化文件。可大大缩短数据库文件的创建、维护。

posted on 2007-08-10 07:49 鸟儿飞过 阅读(...) 评论(...) 编辑 收藏

导航

公告