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

[zc_0101]

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

[Q315054403]

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

[zc_0101]

顶一下，大家可以讨论一下~

[昵称被占用了]

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

[Garnett_KG]

1. sort_in_tempdb 某种程度上可以减少i/o的竞争

2. 缩短日志备份的时间.

[zc_0101]

[Quote=引用 2 楼 haiwer 的回复:]
SORT_IN_TEMPDB选项只是在索引生成过程中，将中间的排序结果放在tempdb，从而在tempdb与数据库不在一个物理磁盘的情况下提高生成索引的速度，日志该放哪里放哪里。
[/Quote]
恩，我后来仔细看了一下tempdb 和索引创建，发现它只是临时占用磁盘空间，
所以我又重新做了一次测试，在开启sort_in_tempdb选项时，整理碎片的过程中去观察tempdb所在的磁盘空间，也没有发现明显的变化，在之前的测试中tempdb的数据以及log文件也没有明显的变化，这又是为什么呢？

[zc_0101]

[Quote=引用 3 楼 garnett_kg 的回复:]
1. sort_in_tempdb 某种程度上可以减少i/o的竞争

2. 缩短日志备份的时间.
[/Quote]
跟日志备份有什么关系？

[Garnett_KG]

[Quote=引用 4 楼 zc_0101 的回复:]

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

恩，我后来仔细看了一下tempdb 和索引创建，发现它只是临时占用磁盘空间，
所以我又重新做了一次测试，在开启sort_in_tempdb选项时，整理碎片的过程中去观察t……
[/Quote]

整理碎片的过程中,请用下面的查询观察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;

[Garnett_KG]

[Quote=引用 5 楼 zc_0101 的回复:]

引用 3 楼 garnett_kg 的回复:
1. sort_in_tempdb 某种程度上可以减少i/o的竞争

2. 缩短日志备份的时间.

跟日志备份有什么关系？
[/Quote]

日志备份后可以使日志空间重复使用，可以控制日志文件的暴涨。

[zc_0101]

[Quote=引用 7 楼 garnett_kg 的回复:]
日志备份后可以使日志空间重复使用，可以控制日志文件的暴涨。
[/Quote]
哦，明白了，你是这个意思，但是它仍然不能控制碎片整理时的实际增长量，
退一步说，如果我能容忍此时的日志暴涨，那又有什么办法控制镜像端的同步暴涨呢？

[昵称被占用了]

镜像的同步依赖日志，这问题没法解决
索引碎片整理没必要经常做

[Garnett_KG]

[Quote=引用 8 楼 zc_0101 的回复:]

引用 7 楼 garnett_kg 的回复:
日志备份后可以使日志空间重复使用，可以控制日志文件的暴涨。

哦，明白了，你是这个意思，但是它仍然不能控制碎片整理时的实际增长量，
退一步说，如果我能容忍此时的日志暴涨，那又有什么办法控制镜像端的同步暴涨呢？
[/Quote]

没办法，设计使然。

你主服务在做Index Rebuild,同样镜像端也必须要做才能保持两台DB的同步啊。

所以主服务器的日志必须全部发送到镜像端,然后再Apply.

[zc_0101]

[Quote=引用 10 楼 garnett_kg 的回复:]
引用 8 楼 zc_0101 的回复:

引用 7 楼 garnett_kg 的回复:
日志备份后可以使日志空间重复使用，可以控制日志文件的暴涨。

哦，明白了，你是这个意思，但是它仍然不能控制碎片整理时的实际增长量，
退一步说，如果我能容忍此时的日志暴涨，那又有什么办法控制镜像端的同步暴涨呢？


没办法，设计使然。

你主服务在做Index Rebuild,同样镜像端也必……
[/Quote]
呵呵，谢谢仁兄~
得寸进尺一下，有没有不断开镜像关系的前提下，截断日志的方法？

[zc_0101]

[Quote=引用 9 楼 haiwer 的回复:]
镜像的同步依赖日志，这问题没法解决
索引碎片整理没必要经常做
[/Quote]
嗯，谢谢，收到

[Garnett_KG]

[Quote=引用 11 楼 zc_0101 的回复:]

引用 10 楼 garnett_kg 的回复:
引用 8 楼 zc_0101 的回复:

引用 7 楼 garnett_kg 的回复:
日志备份后可以使日志空间重复使用，可以控制日志文件的暴涨。

哦，明白了，你是这个意思，但是它仍然不能控制碎片整理时的实际增长量，
退一步说，如果我能容忍此时的日志暴涨，那又有什么办法控制镜像端的同步暴涨呢？


没办法，设计使然。

你……
[/Quote]

还是做日志备份。