当前位置: 代码迷 >> Sql Server >> 文件组怎么规划?online rebuild索引有关问题
  详细解决方案

文件组怎么规划?online rebuild索引有关问题

热度:191   发布时间:2016-04-24 18:29:31.0
文件组如何规划?online rebuild索引问题
数据库有点大, 300GB, 用的Windows Azure 存放在一个磁盘的盘驱,性能比较差。 现在计划多加几个磁盘,Windows Azure 限制1个磁盘只有500 IOPS/秒, 现在是有2核物理cpu,逻辑的8个cpu, 再加3个磁盘应该行了吧?   
加了后,如何规划文件组呢? 方法如下:
1. 不新建文件组,只往主文件组里面添加3个ndf文件分布在其他磁盘,
2. 还是新建1个文件组,然后新建3个ndf分别分布在其他磁盘? 
3. 还是新建3个文件组,再每一个有一个ndf 分布在其他磁盘?

另外,平时的读写很频繁,如果整个db 作online rebuild索引, 一般多长时间运行一次呢? 有了online rebuild索引,是否还需要更新统计信息的job执行? 
------解决方案--------------------
一个文件组放3个文件,和3个文件组,分别放1个文件,是有区别的。

前一种,会把数据比较平均的放到三个文件,而后一种,就是只能放到一个文件中。

建议用第一种把。


------解决方案--------------------
建议: 
1. ndf, mdf 都是物理数据文件,是没有区别的。filegroup只是逻辑文件区分。物理文件是需要IO 分布,提高paralled IO. 例如 如果是物理服务器,日志文件和数据文件放在独立的drive,drive挂接独立的磁盘。如果是虚拟服务器的话,需要dedeicated LUN /raw disk mapping

2. Microsoft建议对index碎片>30%的索引进行online rebuild. 尤其是对大表。这是SQL内部碎片进行整理。还可以对物理磁盘进行外部的磁盘碎片整理。索引的整理是有维护开销的,相对于开销和性能获得,每晚对索引碎片>30%的大表进行索引整理还是很值得的。

3. 理论上SQL对 >20% underlying table update 进行auto statistic update; index rebuild的时候statistic 也同时进行100% sample更新。如果你查看execution plan发现actual row count 和estimated row count有很大差距,那么statistic太老了。你也可以通过MDV查看hot table的统计更新last date, 数据变化率,设置规则:对1周没有更新或者当日数据变化超过10%的"大表"进行夜间的统计更新。尤其是大表auto statistic update不大会发生,20% threadhold显的太大。
------解决方案--------------------
online rebuild要消耗tempdb的资源,这个如果是瓶颈,把tempdb独立一个盘,并且大小增加一点,也可以分4个tempdb数据文件。

如果你搞多个盘,可以把数据文件平均分到每个盘,加大并行读写特性。日志文件独立丢一个盘,这是理想化的配置。能否实现要看你的现有资源的瓶颈所在
------解决方案--------------------
图简单,就一个文件组,3个文件。图最优效率,就3个文件组。。但要仔细分布表等,比较费事儿
各有优缺点,不同情况,不同选择。
通常,应该从设计及开发代码质量上优化效率,那是正道及重点处
  相关解决方案