Allgemein Für Administratoren Für Architekten Für Entwickler Für Projektleiter Für Tester News Produkte Publikationen
X
Manuel Burzler

Manuel Burzler

Hilfe, meine TFS Collection Datenbank ist riesig!

Donnerstag, 24. August 2017

Eine TFS Collection Datenbank wächst stetig an. Das ist völlig normal. Dabei kann es immer wieder Phasen geben, in denen das Wachstum stärker oder schwächer ausgeprägt ist. Auch hier schellen meistens noch keine Alarmglocken. Erst wenn ein vorher eingestellter Schwellwert (z.B. DB-Größe, Festplattenauslastung, Backup-Zeiten) erreicht wird, sucht man nach Ursachen und Möglichkeiten.

Die häufig einfachste Möglichkeit, in einer virtualisierten Umgebung, ist auf dem Data Tier die Festplattenkapazität zu vergrößern. Das kann in vielen Fällen ein ausreichendes Mittel sein. Es gibt aber auch Fälle, in denen Ursachenforschung betrieben werden muss, um festzustellen, wo die riesigen Datenmengen eigentlich herkommen und wie sich diese effektiv verringern lassen.

Gründe für die gezielte Reduktion können folgende sein:

  • Eine weitere Vergrößerung der Festplattenkapazität ist nicht mehr gewünscht. Die Ursache dafür kann wiederum auf verschiedene Motivationen begründet sein:
    • Kostenfaktor
    • Technischer Faktor (Infrastrukturgrenze erreicht)
  • Die Migrationszeit soll verkürzt werden:
    Sowohl bei On-Premises-Migrationen (Backup, Restore und Migration), als auch bei Migrationen nach VSTS (DACPAC-Export und Upload).

Letztendlich ist der Grund für die beabsichtigte Reduktion nicht ausschlaggebend. Anbei geben wir Ihnen einige Ideen mit, wie Sie zielgerichtet nach Einsparpotenzialen in Ihrer Collection suchen können.

  • Nicht mehr benötigte Buildergebnisse löschen:
    Je nach Branch-Struktur gibt es verschiedene Arten von Builds (z.B. Continuous Integration Build-Ergebnisse kann man meist ohne Folgeschäden löschen). Hier kann man schwer pauschalisieren. Das kommt sehr auf das verwendete Branch- und Buildkonzept an.
    Build and release retention policies
  • Nicht mehr benötigte Test Attachments löschen:
    Die Testausführung, insbesondere automatisierte Tests, erzeugen erhebliche Datenmengen. Die Test Attachments lassen sich mit dem Test Attachment Cleaner (bis TFS 2015) aufräumen. Mit einer Test Retention Policy (ab TFS 2015 Update 1) können alle Daten der Testergebnisse gelöscht werden, die ein definiertes Alter erreicht haben.
    Test result data retention with Team Foundation Server 2015
  • Nicht mehr benötigte Workspaces löschen:
    Alte Workspaces, die seit längerem nicht mehr genutzt wurden, können gelöscht werden.

  • Nicht mehr benötigte Shelvesets löschen:
    Alte Shelvesets, die seit längerem nicht mehr genutzt wurden, können ebenfalls gelöscht werden. Es ist zu beachten, dass bei der Verwendung von Gated-Checkins, jedes Mal wenn ein Gated-Checkin nicht erfolgreich war, das Shelveset nicht automatisch gelöscht wird! Daher ist es ratsam, in regelmäßigen Abständen, nicht mehr benötigte Shelvesets zu recyceln.
    Lifetime of ShelveSet used for Gated Checkin

Unsere Erfahrungen haben gezeigt, dass das zu erwartenden Einsparpotenzial sehr stark variiert. Wir haben in unseren Projekten eine Spanne von einem niedrigen einstelligen Prozentwert bis zu 80 Prozent gesehen. Steht auch bei Ihnen die Aktualisierung ihrer TFS Umgebung an oder denken Sie bereits über eine Migration nach VSTS nach, dann zögern Sie nicht uns anzusprechen.

Verwandte Artikel:

Benötigen Sie Unterstützung bei der Software-Entwicklung und Architektur von .NET basierten Lösungen oder bei Einführung und Anpassung von Visual Studio / Microsoft Test Manager / Team Foundation Server?

Wir stehen Ihnen unter info(at)aitgmbh.de gerne zur Verfügung.

Tags: , , ,

Hinterlasse eine Antwort