关于镜像时的索引碎片整理问题

Question

A和B为镜像关系，现在要整理A上的索引碎片，A的日志文件大小遂暴涨，
并且原封不动的将暴涨的日志文件传送至B，感觉很不爽~
遂翻开MSDN联机丛书，发现在重建索引时有SORT_IN_TEMPDB这个选项，
意为节省应用数据库磁盘空间，吾理解为可以减小日志大小，
赶紧进行测试，缺发现用了此选项非但没有减小日志文件，反而增加了
10多兆，tempdb数据库的数据文件和日志文件也没有任何变化，不解，
现有以下疑问请教：
1、Sort_in_Tempdb这个选项到底能为我们提供什么便利？
2、有没有一种方法可以避免在索引碎片整理时日志文件的暴涨(前提：不影响镜像关系)？

Answer 1

SORT_IN_TEMPDB选项只是在索引生成过程中，将中间的排序结果放在tempdb，从而在tempdb与数据库不在一个物理磁盘的情况下提高生成索引的速度，日志该放哪里放哪里。

Answer 2

1. sort_in_tempdb 某种程度上可以减少i/o的竞争2. 缩短日志备份的时间.

Answer 3

恩，我后来仔细看了一下tempdb 和索引创建，发现它只是临时占用磁盘空间，
所以我又重新做了一次测试，在开启sort_in_tempdb选项时，整理碎片的过程中去观察tempdb所在的磁盘空间，也没有发现明显的变化，在之前的测试中tempdb的数据以及log文件也没有明显的变化，这又是为什么呢？

Answer 4

整理碎片的过程中,请用下面的查询观察tempdb的详细使用状况
SELECT SUM(unallocated_extent_page_count) AS [free pages], 
(SUM(unallocated_extent_page_count)*8) AS [free space in KB],
SUM(internal_object_reserved_page_count) AS [internal object pages used],
(SUM(internal_object_reserved_page_count)*8) AS [internal object space in KB],
SUM(version_store_reserved_page_count) AS [version store pages used],
(SUM(version_store_reserved_page_count)*8) AS [version store space in KB],
SUM(user_object_reserved_page_count) AS [user object pages used],
(SUM(user_object_reserved_page_count)*8) AS [user object space in KB]
FROM sys.dm_db_file_space_usage;

Answer 5

没办法，设计使然。你主服务在做Index Rebuild,同样镜像端也必须要做才能保持两台DB的同步啊。所以主服务器的日志必须全部发送到镜像端,然后再Apply.

Answer 6

但愿下一版提供ORACLE的逻辑同步功能