none
Performance während Index-Reorganisation RRS feed

  • 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
    Donnerstag, 18. Februar 2010 14:48

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
    Donnerstag, 18. Februar 2010 16:27
  • Hallo Olaf,

    vielen Dank für die Info. Leider haben wir einen 24-Stunden Betrieb.
    Da muss ich mir also noch was anderes überlegen.

    Gruß,
      Lars
    Freitag, 19. Februar 2010 08:15
  • 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
    Dienstag, 23. Februar 2010 07:21
  • 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
    Donnerstag, 25. Februar 2010 12:29
  • 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
    Donnerstag, 25. Februar 2010 12:47
  • 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
    Donnerstag, 25. Februar 2010 12:49
  • Hallo Olaf,

    dafür schon einmal vielen Dank! Werde noch DBCC durch  ALTER INDEX ersetzen. MS hat angekündigt, den Befehl nach 2008
    zu entfernen.

    Gruß,
       Lars
    Donnerstag, 25. Februar 2010 15:16
  • 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
    Donnerstag, 25. Februar 2010 15:39
  • 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
    Donnerstag, 25. Februar 2010 15:49
  • 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
    Donnerstag, 25. Februar 2010 16:08