SQL 2008 索引重建优化
sql2008r2生产环境有一个数据库约700G，每周六晚安排一次索引重建，现在有两个问题想请教：

1.  每次重建约产生100G的日志，因磁盘资源有限（多数据库共用200G日志盘)，能否在重建时将恢复模式改为“大容量日志”，是否会带来隐患？
2.  因重建索引时数据库在线，经常会发生死锁并被选择为牺牲品。又因磁盘资源限制无法设置为重试，试问设置为联机重建能否改善死锁情况发生，或是否有其他更好的办法来避免此问题？联机索引有何弊端没？
------解决方案--------------------
第一步：可以，也建议这样做，但是记得重建完改回完整模式，然后做一次日志备份。
第二步：可以使用联机更新，但是时间会比较久，而且tempdb耗用大，这些部分要小心处理。但是切记别在重建过程中结束进程，否则有可能会让数据库变成【正在还原中】，而让用户不能访问。
------解决方案--------------------
扩展说明，使用代理直接重建可以减少维护开销，但是如果有可能，应该先检查是否有必要使用到“重建”，微软的建议是索引碎片小于10%不用管，10~30%建议重组，30%以上使用重建。但是在重建或者重组的时候，应该监控一下，是否很快又有碎片，如果是，那么有可能证明你的索引不合理，这时候就不要单纯的重建或者重组可以解决的，要分析和处理。因为你的数据库重建索引时还在联机，这时侯切换恢复模式不是不可以，但是存在比较大的风险，所以可以考虑在不更改恢复模式的前提下，重建完马上做日志备份，并收缩一定程度的日志文件（记得别一次性收缩干净，后果同样严重）。

对于700G的数据库，不能单纯考虑重建了事，要分析大表是否有做分区？是否有周期性做压缩处理（2008以后才有，不是收缩）？数据文件是否分开存放以便分摊IO？有没有用文件组来管理？索引是否不合理？如过多、过宽、范围过大（这个可以用筛选索引来解决）。对于你这种规模的库，要做非常多的管理和配置。否则随便都出问题。
------解决方案--------------------
700G 应该有相当一部分数据是不会再变化了的吧.
可以考虑把历史的不变化的数据放进只读文件组里面.
这样要处理的数据就少多了.
------解决方案--------------------
如果索引列数据更改并不频繁，就不需要每周重建
不过太多“指南或经验”一股老儿的推荐和建议，容易误导不少人
------解决方案--------------------

引用:

谢谢各位达人的回复！
我想再询问一下，联机重建索引在重建期间，索引数据的存放位置是在哪里，tempdb或是当前数据库所在位置？如果把当前的索引重建任务改为联机索引重建，对存储空间有新的要求么；因为我理解的联机索引是索引重建好了以后才会删除现有索引，这样会在重建期间需要双倍索引空间，不知这样理解是否恰当？

放在哪里看你的设置了，是需要多的空间，但不是一倍，因为重建索引也是一个一个重建，空间释放之后可以重用。在线重建索引时间会比现在长很多，而且日志空间也会增长，建议先做测试，不要直接改。另外索引为何不能拆成多个计划？多个晚上执行？
象版主说的是否有必要重建？重新组织呢？碎片少的直接过滤
------解决方案--------------------

引用:

谢谢各位达人的回复！
我想再询问一下，联机重建索引在重建期间，索引数据的存放位置是在哪里，tempdb或是当前数据库所在位置？如果把当前的索引重建任务改为联机索引重建，对存储空间有新的要求么；因为我理解的联机索引是索引重建好了以后才会删除现有索引，这样会在重建期间需要双倍索引空间，不知这样理解是否恰当？

联机重建你可以看到有在tempdb中执行的选项，不勾选也是可以的。重建索引可能会添加新页，大小不保证一致，可以使用drop_existing子句。来加快重建速度
------解决方案--------------------
太高深，学习中
------解决方案--------------------
重建索引时怎么一个过程？
还是没明白。