Eine Wiese, die nicht gepflegt wird, verbuscht. – Christian Kropf

In den letzten Beiträgen beschrieb ich, wie in einer Anwendung das Qualtitätskriterium Performance schrittweise verbessert wurde. Dabei kamen unter anderem auch Optimierungen durch Indexe auf der Datenbank zum Einsatz. Durch das Einfügen neuer Datensätze nutzen sich Indexe regelmässig ab. Die Fragmentierung der Indexe nimmt zu, mit dem Resultat das sich die Performance verschlechtert. Der SQL Server bietet Managed Views an, um einen besseren Überblick über diese Abnutzung zu erhalten. Eine Beispiel-Abfrage ist nachfolgend dargestellt:

SELECT 
  s.[name] as 'Schema'
  , tbl.[name] as 'Table'
  , idx.[name] as 'Index'
  , stats.avg_fragmentation_in_percent
  , stats.page_count
FROM sys.dm_db_index_physical_stats (DB_ID('DatenbankName'), NULL, NULL, NULL, NULL) stats
INNER JOIN sys.tables tbl on tbl.[object_id] = stats.[object_id]
INNER JOIN sys.schemas s on tbl.[schema_id] = s.[schema_id]
INNER JOIN sys.indexes AS idx ON idx.[object_id] = stats.[object_id]
  AND stats.index_id = idx.index_id
WHERE stats.database_id = DB_ID('DatenbankName')
ORDER BY stats.avg_fragmentation_in_percent desc

Für den SQL Server gibt es Empfehlungen, ab wann ein Index neu aufgebaut werden soll. Bei einer Fragmentierung zwischen 5 und 30 Prozent wird eine Reorganisation mit ALTER INDEX REORGANIZE empfohlen. Bei einer Fragmentierung grösser 30 Prozent eine Neuerstellung mit ALTER INDEX REBUILD. Im Bereich der Datenqualität beziehungsweise der Qualitätskriterien sind diese Massnahmen systembezogen.

Da die Entwicklung von Software auch im agilen Prozess vielerorts in Silos organisiert ist, bleiben die systembedingten Massnahmen häufig auf der Strecke. Einfach ausgedrückt, eine Wartung der Indexe auf einer Entwicklungsumgebung gibt es nicht. Bei kleinen Datenmengen ist das auch nicht weiter wichtig. Spürbar wird es, wenn die Anwendung auf die reale Datenmenge trifft. Du kannst einen einfachen Test machen. Führe das obere Skript auf einer beliebigen Dev oder Test – Umgebung aus. Fragmentierungen grösser 50 Prozent sind hier normal. Häufig höre ich dann Aussagen wie:  „Ist ja nicht meine Aufgabe, dafür gibt es den Datenbankadministrator.“ Bei solchen Argumenten kommt der Satz bei mir so an: „Ist ja nicht mein Silo, dafür gibt es das Silo.“ Solche Mindsets sind aus meiner Sicht nicht DevOps – Kompatibel. Zudem sind sie ein gutes Messkriterium, ob die Aussage mit der Handlungsweise einer Person zusammen passt, wenn es um Themen wie DevOps geht.

Häufig gibt es hierfür bereits Lösungen und fertige Skripts. Auf unseren Dev und Test-Umgebungen, bei denen ein SQL – Server zum Einsatz kommt, verwenden wir das Skript SQL Server Maintenance Solution von Ola Hallengren. Dieses legt Prozeduren und Jobs an, unter anderem auch für die Pflege der Indexe. Das Skript kannst du ohne Anpassung direkt ausführen, dann werden die Objekte in der Master-Datenbank angelegt. Ich habe die Objekte in einer Maintenance – Datenbank. Auf der Seite gibt es zudem eine ausführliche Dokumentation.

Unter den Jobs, welche das Skript anlegt, existiert auch ein IndexOptimize Job für alle Datenbanken der SQL Server Instanz. Mit wenig Aufwand lässt sich die Indexpflege auf der Dev- und Test – Umgebung ausführen und automatisieren. Die Empfehlungen werden durch das Skript berücksichtigt. Es erfolgt zudem eine Protokollierung der Schritte in der Tabelle CommandLog. Ich finde das sehr nützlich.

Dieses Skript werde ich künftig für die Pfege der Datenbanken in DevOps – Umgebungen im Hinterkopf behalten. Aktuell verwende ich es noch nicht in einer Build-Pipeline.

Wie berücksichtigst du die systembezogene Pflege deiner Qualitätskriterien? Dein Feedback interessiert mich!