我有一个数据库,大约有17GB的数据,最大大小约为45GB。插件每24小时完成一次(从客户系统导入)。导入时禁用索引。
我发现重组和重建与删除和重建每个索引之间存在性能问题。
重建/重建大约需要1-3分钟才能完成 删除和重建需要10 + min才能完成。
我最近实施了reorg程序,之前我们只进行了重建和重建 - 每个客户每晚需要10分钟。
我的问题是,似乎reorg不足以维持性能,我必须在时间运行完整的重建。我不是DBA,只是一个.NET开发者 - 但我觉得很奇怪,我的表现很多都挂在索引中,而且重建和新鲜。
我找到了Reorganise index vs Rebuild Index in Sql Server Maintenance plan - 这解释了重组与重建索引背后的一些概念。
我的reorg / rebuild脚本可以在这里找到http://www.sqlservercentral.com/Forums/Topic1010651-146-1.aspx#bm1010715(发布者:pavan_srirangam)(我不确定那是我发现的那些日子里的副本,但它看起来像。我做了一些记录开始/停止等变化。 但是如果脚本找到碎片高于30%的索引,它应该重建它。就像从头开始删除和重建索引一样,或者我正在读取elseif(avg frag> max frag)错误。
一个考虑因素可能是现有的索引页面在导入之前与数据一起是最新的。导入后,可以重新组织这些页面并对其进行碎片整理,以指向导入之前的数据。现在出现问题 - 导入产生了大量新数据。使reorg脚本处理这些新数据并为新数据生成索引页面还是已经包含在reorg / rebuild脚本(reorg索引的概念)中需要做些什么?
编辑更新:
我们刚遇到一个表现不佳的案例。我在左右两边都有超时异常。所以我决定运行reorg脚本,最后这样做了4次并在fragment_count = 10
结束。我不能引起任何超时,我的老板说他根本无法进入。请注意,我正在使用相关数据库服务器的VPN。我们的测试页面运行速度为15-20秒。最后,我不得不完全放下并重建,耗时12分钟。测试页面下降到3-5秒。
跌落和重建归结为:
DECLARE @sqlTemplate varchar(50)
SET @sqlTemplate = 'ALTER INDEX @indexName ON @tableName @changeMode'
DECLARE cIndexs CURSOR LOCAL FORWARD_ONLY READ_ONLY
FOR
SELECT obj.name AS TableName,idx.name AS IndexName
FROM sys.indexes AS idx
JOIN sys.objects AS obj
ON idx.object_id = obj.object_id
在哪里obj.type ='U'
AND idx.name LIKE'IX_%'
AND idx.is_primary_key = 0
AND idx.type = 2
ORDER BY obj.name,idx.nameOPEN cIndexes
FETCH NEXT FROM cIndexes INTO @tableName,@ indexName
WHILE @@ FETCH_STATUS = 0
BEGIN
SET @sql = REPLACE(@sqlTemplate,'@ tableName',@ tableName)
SET @sql = REPLACE(@sql,'@ indexName',@ indexName)
SET @sql = REPLACE(@sql,'@ changeMode',@ changeMode)
打印CAST(GETDATE()AS varchar)+'---'+ @sql
执行sp_executesql @sql
SET @sql = NULL
FETCH NEXT FROM cIndexes INTO @tableName,@ indexName
END
关闭cIndexes
DEALLOCATE cIndexes
与reorg脚本相比,这是如此特别。
(注意:我试图缩进,但它对我不起作用)