Fragensteller
Performance während Index-Reorganisation

Frage
-
Hallo,
während der Index-Reorganisation (SQL 2005) beschweren sich die Anwender über schlechte Performance oder gar Timeouts.
Laut MSDN sollte aber eine Index-Reorganisation (ich meine auch keinen Index-Rebuild) den Server nicht sonderlich
belasten und lange Locks auf die Objekte halten.
Hat noch jemand solche Erfahrungen gemacht?
Danke!
Lars
Alle Antworten
-
Hallo Lars,
es stimmt soweit, das Locks nicht lange gehalten werden und es ein "Online" Befehl ist, man es also im laufenden Betrieb durchführen könnte ... Betonung auf könnte.
Es ist aber so, das eine Index-Reorganisation reichlich I/O Last verursacht, was andere I/O Operationen behindert. Entsprechend wird alles andere langsamer, was die User zu spüren bekommen.
Solche Aktionen sollte man besser Job-gesteuert in der Nacht durchführen, wenn sonst keiner arbeitet.
Ich lasse das nach der Sicherung ausführen; zur Sicherheit, falls was schief geht (bisher nicht vorgekommen)
Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de -
Wir hatten ebenfalls mit Performance Problemen und Timeouts während der Reorganisierung zu kämpfen, bis wir auf die Idee gekommen sind MAXDOP = 1 in unser Skript einzubauen. Ich habe es nie wirklich nachgeprüft, ob tatsächlich mehrere Prozessoren verwendet wurden, aber nach dieser Aenderung hat sich niemand mehr über schlechte Performance beschwert.
Wir machen so etwas hier ausserdem über ein eigenes Skript. Dieses läuft als Job einmal pro Nacht und kümmert sich nur um Objekte mit mehr als 3.000 Daten-/Index Seiten und einer Fragmentierung > 10%. Zusätzlich enthält dieses Skript einen "Timer", welcher kontrolliert, ob seit Start der Prozedur nicht mehr als 20 Minuten vergangen sind. Ist dies der Fall, wird der nächste Index von der Liste genommen und reorganisiert. Ansonsten eben nicht. Dadurch kriegen wir zwar nur 1 - 2 Indizes pro Nacht reorganisiert, aber das reicht uns, da wir einmal pro Monat ein Maintenance Window haben, in welchem wir sämtliche Indizes reorganisieren können.
-- Frank Kalis Microsoft SQL Server MVP Webmaster: http://www.insidesql.org -
Hallo,
vielen Dank für den Hinweis! Bisher wurde nur der Standard-Auftrag für eine Index-Reorganisation eingesetzt, ohne an dem Script was zu ändern bzw. gar ein eigenes einzusetzen.
Ich werde wohl um ein eigenes Script nicht herum kommen.
Gruß,
Lars -
Hallo,
ich finde aber keine Möglichkeit, bei einem Reorg den Parameter MAXDOP zu setzen bzw. er ist sowieso auf 1:
When you execute ALTER INDEX REORGANIZE with or without LOB_COMPACTION, the max degree of parallelism value is a single threaded operation. The MAXDOP index option cannot be specified in the ALTER INDEX REORGANIZE statement.
Wo hast Du dass denn eingebaut?
Gruß,
Lars -
Da kann ich etwas behilflich sein; die Eckdaten müsstest Du an Deine Belange anpassen:
-- Indizes defragmenitieren (SQL 2005)
DECLARE @TableName sysname;
DECLARE @IndexID smallint;
-- Alle relevanten Indizes ermitteln
DECLARE Fragment CURSOR LOCAL FOR
SELECT OBJ.name AS TableName, IDX.index_id AS IndexID
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) AS FRG
INNER JOIN sys.sysobjects AS OBJ
ON FRG.object_id = OBJ.id
INNER JOIN sys.indexes AS IDX
ON FRG.index_id = IDX.index_id
AND FRG.object_id = IDX.object_id
-- Nur wirklich fragmentierte IDX rausfiltern
WHERE IDX.index_id > 0 -- keine Heaps
AND FRG.avg_fragment_size_in_pages > 1 -- min. über eine Seite
AND FRG.avg_fragmentation_in_percent > 10 -- min. über 10%
ORDER BY FRG.fragment_count DESC, FRG.page_count DESC, FRG.avg_fragment_size_in_pages DESC
-- Open the cursor
OPEN Fragment
FETCH NEXT FROM Fragment
INTO @TableName, @IndexID
WHILE @@FETCH_STATUS = 0
BEGIN
PRINT @Tablename + ' -- ' + convert(varchar(10), @IndexID)
FETCH NEXT FROM Fragment
INTO @TableName, @IndexID
DBCC INDEXDEFRAG (0, @TableName, @IndexID) WITH NO_INFOMSGS
END
CLOSE Fragment
DEALLOCATE Fragment
Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de -
Hallo,
ich finde aber keine Möglichkeit, bei einem Reorg den Parameter MAXDOP zu setzen bzw. er ist sowieso auf 1:
When you execute ALTER INDEX REORGANIZE with or without LOB_COMPACTION, the max degree of parallelism value is a single threaded operation. The MAXDOP index option cannot be specified in the ALTER INDEX REORGANIZE statement.
Wo hast Du dass denn eingebaut?
Gruß,
Lars
Aah, guter Hinweis. Habe jetzt noch einmal in mein Skript geschaut und wir reorganisieren nicht neu, sondern erstellen neu:
SET @sql = 'ALTER INDEX ' + @Index_Name + ' ON ' + @Table_Name + ' REBUILD WITH (ONLINE = ON, MAXDOP = 1)';
Sorry für die Verwirrung!
-- Frank Kalis Microsoft SQL Server MVP Webmaster: http://www.insidesql.org -
Dann ist ja meine Welt wieder in Ordnung :-)
Wie ich sehe, habt ihr die Enterprise Edition im Einsatz (ONLINE = ON). Dass sollte die Performance bei den Clients
auch entlasten.
Gruß,
Lars
Ja, einer der netten Aspekte hier ist, dass alles andere ausser Enterprise Edition keinerlei Beachtung findet, wenn die Datenbank nur wichtig genug ist. :-)
-- Frank Kalis Microsoft SQL Server MVP Webmaster: http://www.insidesql.org