Schlagwort-Archive: Storage Optimization

SharePoint BLOB Management – Archivierung

SharePoint Adventskalender – 22. Türchen

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

————————————————————-

In den letzten Tagen haben wir uns das BLOB Management von aktuellen Inhalten näher angeschaut und wie wir es optimieren können. Der Lebenszyklus von Inhalten sollte aber ebenso im BLOB Management berücksichtigt werden, weil der Datenbestand mit dem Alter des SharePoints exponentiell steigt. Besonders passive Daten beeinflussen diese Entwicklung.

Passive Daten sind beispielsweise Dateien, die veraltet und nicht mehr aktuell oder aus anderen Gründen nicht mehr relevant für die Aufbewahrung in SharePoint sind. Solche Dateien beeinflussen nicht nur die Performance, sondern tauchen auch immer wieder in den Ergebnislisten der SharePoint-Suche auf.

Sind die Daten im SharePoint nicht mehr aktuell, bzw. es ist aufwendiger für Endanwender, die aktuellen Daten zu finden, so sinkt auch die Nutzerakzeptanz. Dies ist neben der allgemeinen Geschwindigkeit des SharePoints ein sehr entscheidender Punkt.

Um die Daten nun aktuell zu halten, empfehle ich die Verwendung von Archiven. Dies kann mit dem SharePoint nativen Records Management realisiert werden. Dateien, die als Record markiert werden, können von einem Workflow „eingesammelt“ und zur Archivierung im Records Center abgelegt werden. Lösungen von Drittanbieter können noch weitere Funktionen in ein SharePoint-Archiv integrieren, sodass Dokumente, die beispielsweise seit drei Jahren nicht mehr bearbeitet oder gar geöffnet wurden, ganz automatisch in ein Archiv verschoben werden.

Auf diese Weise sehen Endnutzer auch stets nur die aktuellen Dokumenten in den Suchergebnislisten. Für den Administrator kann außerdem die Größe der Inhaltsdatenbanken reduziert werden und dies sorgt für eine schnellere Bearbeitungen der SharePoint-Anfragen an den SQL.

Das Archiv kann zusätzlich mit günstigeren Datenbanken betrieben werden, weil Microsoft geringere Anforderung an entsprechende Speicherlaufwerke stellt. Sie sehen also, wie viele Vorteile das Daten- und BLOB-Management über die Lebenszeit des SharePoint bringt. Machen Sie sich also bitte rechtzeitig Gedanken darüber, wie Dateien im SharePoint verwaltet werden sollen.

Viel Spaß beim „SharePointen“!

————————————————————-

Weitere Türchen:

SharePoint BLOB Management – Shredded Storage und RBS “Better Together”

SharePoint Adventskalender – 21. Türchen

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

————————————————————-

In den letzten beiden Türchen hatten wir jeweils den RBS und Shredded Storage im Fokus. Da jede der beiden Technologien ihre Vorteile hat, können wir uns überlegen, wie wir sie gemeinsam nutzen und was es dabei zu beachten gibt.

Die verschiedenen Funktionsweisen sind deutlich voneinander zu unterscheiden. Kurz zusammengefasst, lagert der RBS Dateien aus SQL aus, um die Datenbankgröße zu verringern und eine verbesserte Performance zu erhalten. Der Shredded Storage hingegen optimiert lediglich den Speicher, in dem beispielsweise bei versionierten Dokumenten nur das Delta und nicht jeweils eine komplett neue Datei gespeichert werden muss. Die Daten bleiben jedoch im SQL! Dateien, die doppelt und dreifach über verschiedene Listen und Seiten gespeichert sind, belegen so auch mehrfach Speicherplatz. Durch Auslagerung kann diese „Dopplung“ jedoch durch den Windows Server Deduplication Service egalisiert oder zumindest minimiert werden.

Wir haben außerdem erfahren, dass jede Technologie auch ihre bestimmten Konfigurationen hat, um bestmögliche Ergebnisse zu erzielen. Das ist auf der einen Seite die Chunk-Größe des Shredded Storage und auf der anderen Seite der RBS-Grenzwert, also ab welcher Dateigröße ausgelagert werden soll. Und in der Tat, ist die Chunk-Größe geringer als der Grenzwert, so würde die Auslagerung nie aktiviert werden. Bitte beachten Sie daher diese Abhängigkeit, wenn Sie zum Shredded Storage auch eine Auslagerungen in Echtzeit nutzen möchten.

Da solche Echtzeitprozesse jedoch sehr ressourcenhungrig sind, werden sie nicht mehr von Microsoft empfohlen. Stattdessen kann man bei RBS Providern von Drittanbietern konfigurieren, dass die Datei als ganzes zählen soll und nicht nur die Fragmente betrachtet werden. Auch andere Regeln sind möglich, die nicht nur auf die Dateigröße abzielen.

Die Unterschiede und Funktionsweisen kennen wir nun. Aber für welche Szenarien ist welche Technologie am besten geeignet? Je nach dem, welche Fragen Sie in der folgenden Tabelle mit „Ja“ beantworten, umso mehr ist die entsprechende Technologie für Ihr Szenario besser geeignet. Können Sie Fragen in beiden Spalten mit „Ja“ beantworten, so wäre eine Kombination aus beiden Technologien das beste für Sie.

Shredded Storage? Antworten Sie mit Ja!

RBS? Antworten Sie mit Ja!

Gibt es viele Transaktionen?

Haben Sie viele große Dateien (> 1 MB)?

Nutzen Sie die Versionierung?

Sind diese Dateien versioniert?

Haben Sie viele Office und xml-basierte Dokumente?

Haben Sie ein SQL-Speicher-„Problem“ (Inhaktsdatenbanken von mehr als 100 GB)?

Nutzen Sie intensiv das Co-Authering Feature?

Sollen die Backups der Inhaltsdatenbanken beschleunigt werden?

Haben Sie I/Ops und Netzwerkprobleme?

Haben Sie (bewusst) viele Datei-Duplikate in verschiedenen SharePoint-Bibliotheken (und möchten Sie die Deduplication nutzen)?

 

Beide Technologien erzielen Geschwindigkeitsvorteile gegenüber der bisherigen nativen Mittel. Noch interessanter wird es jedoch, wenn wir beide Technologien aufeinander abstimmen, um so alle ihre Vorteile anwenden zu können. Besonders im Szenario mit großen Dateien können in Kombination zusätzlich bis zu etwa 80% verbesserte Downloadzeiten erreicht werden. Der Hintergrund ist die gestern angesprochene deutlich einfachere Verarbeitung von „vorgekürzten“ Fargmenten, als die gesamte Datei selbst in Pakete zerschneiden zu müssen.

Die allgemeinen Best Practices sind dafür 1250 KB als FileWriteChunkSize für den Shredded Storage und 1024 KB für den RBS Grenzwert. Microsoft MVP Chris McNulty zeigt auch sehr schön im Detail, dass diese Werte je nach Dateigröße und Umgebung etwas variieren. Bei Interesse empfehle ich Ihnen daher sehr seinen Vortrag von der SharePoint Konferenz 2014: https://channel9.msdn.com/Events/SharePoint-Conference/2014/SPC424.

Viel Spaß beim “SharePointen”!

————————————————————-

Weitere Türchen:

SharePoint BLOB Management – Shredded Storage

SharePoint Adventskalender – 20. Türchen

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

————————————————————-

Seit Microsoft den Shredded Storage für SharePoint 2013 herausgegeben hat, kursieren verschiedene Mythen und Gerüchte über Best Practices und die kombinierte Anwendung mit dem Remote BLOB Storage (RBS) bei IT-Administratoren. So habe ich bei Kunden bereits gehört, dass RBS als Synonym für Shredded Storage verwendet wurde. Außerdem hört man, dass aufgrund der kleinen Datei-Chunks, der RBS-Grenzwert nie berührt wird, oder aber, dass Shredded Storage den RBS sogar obsolet macht.

Um mit diesen Mythen aufzuräumen und Best Practice Empfehlungen geben zu können, besonders in der Kombination des Shredded Storage mit RBS, konzentrieren wir uns heute zunächst auf die Spezialitäten des Shredded Storage.

Abstrakt betrachtet macht der Shredded Storage Algorithmus folgendes:


Technisch sieht dies aber natürlich etwas anders aus. Einfach gesprochen ist der Shredded Storage die Aufteilung einer Datei in viele kleine Teile, sogenannte Chunks. Die „FileWriteChunkSize“ ist dabei der Wert, der angibt, wie groß die Fragmente beim Schreiben in den SQL sein dürfen. Es sind jedoch nicht alle Teile gleich groß, denn z.B. der Header und Footer der Datei kann eine andere Größe haben. Diese Architektur lässt somit auch erahnen, dass eine Datei im Shredded Storage Konzept zunächst etwas größer ist, als im alten Format, da mehr Informationen gespeichert werden müssen, um die einzelnen Chunks am Ende wieder zusammensetzen zu können. Sobald jedoch erste Änderungen einer Datei mit Versionierung gespeichert werden, wird dieser anfängliche Mehrbedarf an Speicher wieder egalisiert.

Der Algorithmus macht auch keine Unterschiede mehr zwischen Office Dokumenten, Bildern oder anderen Dateitypen. Er versucht grundsätzlich jedes Dokument in Chunks zu zerlegen. Je nach Dateityp und Komplexität der Datei kann dies besser oder schlechter funktionieren. Zum Beispiel: Bei einem meiner Kunden hat eine neue Version einer PowerPoint-Datei fast die gleiche Größe gehabt, wie die Erstversion. Normalerweise sollte mit dem Shredded Storage aber nur das Delta, also beispielsweise die kleine Änderung im Titel, neu gespeichert werden und nicht das gesamte Dokument. Offensichtlich konnte der Algorithmus die Datei aber nicht in kleinere Chunks zerlegen.

Ziele des Shredded Storage:
Während das Hauptziel des gestern vorgestellten RBS die Auslagerung von großen Dateien ist, so verfolgte Microsoft bei der Entwicklung des Shredded Storage folgende vier Ziele:

  1. Bandbreitenoptimierung
    • nur noch Teile einer gesamten Datei müssen gesendet werden
    • dies ermöglicht und verbessert auch das Co-Authoring bei Office-Dokumenten
  2. I/Ops optimieren
    • durch kleinere Datenpakete werden die I/O Muster geglättet
    • es wird realisiert, dass Schreibkosten proportional zur Größe der Änderungen sind
    • es müssen weniger Änderungen an den SQL gesendet werden (nur Delta, nicht gesamte Datei). Dies verkleinert die Transaction Logs und erhöht damit auch die Backup-Performanc
  3. Storage reduzieren
    • es werden nur noch die Änderungen gespeichert, nicht erneut die gesamte Datei
  4. Sicherheit
    • es ist nun schwieriger eine gesamte Datei mit einem PowerShell-Befehl auszulesen
    • mit aktivierter Verschlüsselung kann jedes Datei-Chunk einzelnd verschlüsselt werden

Best Practice:
Basierend auf mehreren Tests mit unterschiedlichen Dateigrößen hat sich ergeben, dass eine FileWriteChunkSize von 1250 KB die beste Performance für Up- und Downlaods erzielt. Je nach Umgebung sowie Art und Größe der Daten, kann auch ein etwas höherer Wert Sinn machen. Als Beispiel, beim Microsoft Cloud-Storage OneDrive werden 2 MB verwendet. Allerdings sollte der Wert nicht größer als 4 MB sein. Warum? Der Hintergrund ist, dass viele System-Operationen Änderung in 4 MB Paketen verarbeiten. Kommt nun ein größeres Datenpaket, so wird dies nur in 4 MB Schritten gelesen – also in 4 MB Pakete „zerschnitten“. Das verursacht einen signifikanten Anstieg der I/Ops. Stattdessen sind zuvür „gekürzte“ Fragmente durch den Shredded Storage deutlich einfach zu verarbeiten.

„For Your Information:“

  • Zusätzlich zu der FileWriteChunkSize gab es auch noch die FileReadChunkSize. Diese Variable sollte zusätzlich die Größe der Pakete definieren, in denen die Daten ausgelesen werden. Da dies aber keine entscheidenen Vorteile brachte, wurde diese Einstellung wieder abgekündigt und man verwendet nur noch die FileReadChunkSize.
  • In SharePoint 2016 wird der Shredded Storage nicht mehr mit dem Cobalt, sondern mit dem BITS (Background Intelligent Transfer Service) Protokoll arbeiten. Damit sind zusätzliche Vorteile möglich, wie z.B. das Unterbrechen und Fortsetzen von Übertragungen (für mehr Stabilität) oder die Verwendung von ungenutzten Netzwerkresourcen zur Übertragung (um nicht andere Netzwerkaktivitäten negativ zu beeinflussen)

Zur Vollständigkeit hier noch die PowerShell Befehle, um den Shredded Storage zu konfigurieren. Achten Sie darauf, dass der Wert nur für die gesmate Farm konfiguriert werden kann, auch wenn der allgemeine PS-Ansatz etwas anderes vermuten lässt. Dies liegt daran, dass der Shredded Storage ein Web Service ist. Sollten Sie also den Shredded Storage im „gewöhnlich“ Fall mit einer bestimmten Web Application konfigurieren, behalten Sie im Hinterkopf, dass die anderen Web Applications dieses Wert auch übernehmen. Die folgenden Befehle machen diesen Sachverhalt deutlich:

Casual:
$webapp = Get-SPWebApplication http://WebAppUrl
webapp.WebService.FileWriteChunkSize =
chunk size in Bytes
$webapp.webservice.update()

Formal :
[void][System.Reflection.Assembly]::LoadWithPartialName(„Microsoft.SharePoint“)
$service = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$service.FileWriteChunkSize = 1280000
$service.Update()

Viel Spaß beim „SharePointen“

————————————————————-

Weitere Türchen:

SharePoint BLOB Management – BLOB Storage (EBS und RBS)

SharePoint Adventskalender – 19. Türchen

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

————————————————————-

Heute und in den nächsten Kalendertürchen widmen wir uns dem BLOB Management für optimierte Speicherlaufwerke und der daraus resultierenden Verbesserung unserer SharePoint Performance.

Im gestrigen Kalendertürchen sprachen wir noch vom BLOB Caching, um in bestimmten Szenarien die Performance für eine bessere Nutzererfahrung zu steigern. Leider optimiert dies in keinster Weise die Speicherlaufwerke, denn die BLOBs liegen witerhin wie bisher als „Image“ mit einem Dateilimit von 2 GB in den Datentabellen des SQL. Der SQL Server-Storage ist aber sehr ressourcenhungrig und damit teuer. Die Reduzierung der Datenbankgröße durch Auslagerung von Daten und die damit einhergehende Performance-Verbesserung waren daher Ziele bei der Einführung von EBS und RBS. (Die Performance-Verbesserung durch Auslagerung ist auf die Limitationen der Datenbankalgorithmen für große Dateien zurückzuführen, wie gestern bereits erwähnt.)

Der für SharePoint 2007 eingeführte External BLOB Storage (EBS) konnte auf Farmebene angewendet werden. Anhand konfigurierbarer Regeln konnten so große Dateien aus der SQL Datenbank auf einen günstigeren Storage ausgelagert werden. Dafür verwendetet man nun nicht mehr das Image, sondern das VARBINARY Format. Ein Größenlimit gibt es damit theoretisch zwar nicht mehr, aber aus Performance-Gründen behielt Microsoft weiterhin die 2 GB-Limits für SharePoint Datenbanken bei. Mit SharePoint 2016 ist dieses Limit nun endlich auf (aktueller Stand) 10 GB pro Datei angehoben worden.

Da schnell die Grenzen des EBS deutlich wurden, kündigte Microsoft dieses Feature in SharePoint 2010 wieder ab und führte den Remote BLOB Storage (RBS) ein. Dieser kann pro Datenbank angewendet werden und ist somit deutlich flexibler einsetzbar für SharePoint Farm Administartoren.

Ziele und Funktionsweise des RBS

Hauptziel des RBS ist die Auslagerung von entweder großen Dateimengen oder bestimmten Daten anhand definierter Regeln. Hinsichtlich SharePoint-Limitationen werden diese Daten zwar weiterhin zu einer Datenbank hinzugezählt, sie befinden sich jedoch auf einem anderen Storage. Dadurch kann SQL deutlich schneller und effizienter arbeiten, weil keine Table-Queries mehr mit großen BLOBs, sondern nur noch mit kleinen Stubs(Referenz auf den tatsächlichen Speicherort), durchgeführt werden müssen. Außerdem können so auch die erweiterten Datenbankgrenzwerte angewendet werden. Microsoft unterstützt z.B. in SharePoint 2013 Inhaltsdatenbanken mit bis zu 4 TB und einem Disk Subsystem von mindestens 0,25 I/Ops pro GB. Da durch die Auslagerung beispielsweise keine 4 TB, sondern effektiv nur 150 GB in der Datenbank liegen, kann man so auch mit günstigen Laufwerken die erforderten 0,25 I/Ops pro GB erreichen (empfohlen sind 2 I/Ops pro GB – https://technet.microsoft.com/de-de/library/cc262787.aspx).

Beispielrechnung:

Effektive Daten in der Datenbank

Erforderliche I/Ops für das Disk Subsystem

4 TB        (à 0,25 I/Ops * 1024 * 4)

1024

150 GB  (à 0,25 I/Ops * 150)

37,5

Sollten Sie also dieses Szenario verfolgen und mit RBS die 200 GB „virtuell“ überschreiten, bedenken Sie Situationen, in denen die BLOBs wieder zurück in den Datenbanken müssen, z.B. bei Migrationen. Auch dafür gibt es zwar Lösungen, z.B. Migrationssoftware von Drittanbietern wie AvePoint. Ich möchte an dieser Stelle aber lediglich darauf hinweisen, dass im RBS-Fall bestimmte Dinge zu berücksichtigen sind.

Die Auslagerung von Daten als Hauptziel ermöglicht zudem weitere Nebenziele:

Performance:
Die Downloadzeiten, also die Dauer bis ein Dokument oder allgemein ein BLOB gerendert ist, wird deutlich reduziert aufgrund der gestern erwähnten Limitation.

Der RBS-Provider kann also deutlich mehr Daten direkt vom Storage in der gleichen Zeit lesen, als es SQL allein aus seinen Datenbanken kann. Diese Unterscheide sind natürlich abhängig von dem Speicher-Subsystem des SQL sowie vom RBS Storage und der Netzwerkgeschwindigkeit (sollte diese eine andere und langsamere als zum SQL sein). Um das BLOB vom Storage zu lesen und zu rendern, muss der Browser für gewöhnlich folgende Schritte unternehmen:

  1. DNS Lookup
  2. Initiale Verbindung
  3. Warten
  4. Daten erhalten
  5. Verbindung schließen

Das Warten auf Daten wird als sogenannte TTFB (Time To First Byte – Zeit bis zum ersten Byte) bezeichnet. 100-200 ms sind grundsätzlich gute Werte. Möchten Sie jedoch einen NAS als RBS-Storage nutzen, erfordert Microsoft eine TTFB von unter 20 ms (https://technet.microsoft.com/de-de/library/Ff628583.aspx).

Deduplication:
Auf dem RBS-File-System kann die Deduplication (ein Windows Service) genutzt werden. Ist also ein Dokument doppelt und dreifach in mehreren Bibliotheken abgelegt, so erkennt dies der Deduplication-Algorithmus und komprimiert alle Duplikate in ein einziges und verweist dies in einem Index – einfach ausgedrückt.

In Tests hat sich herausgestellt, dass die beste Performance grundsätzlich mit einem RBS-Grenzwert von 1024 KB erreicht wird. Bei kleineren Dateien ist der SQL Algorithmus schneller. Der Wert kann aber auch minimal abweichen, je nach dem, für welches Szenario Ihre Farm eingesetzt wird und somit welche Dateigrößen hauptsächlich gespeichert sind. Dazu aber morgen mehr in Form von Informationen und Mythen zum Shredded Storage.

Hinweis: Auslagerung kann nicht von SharePoint erfolgen. Stattdessen müssen entsprechende RBS Provider installiert werden. Der Microsoft-eigene Provider, genannt FILESTREAM, erfüllt das Grundgerüst, also das Auslagern von Dateien anhand einer kofigurierten Größe x. Leider kann der FILESTREAM auch nur lokale Laufwerke des SQLs als Auslagerungs-Storage verwenden. Wenn Sie Daten auch auf andere Storages, wie z.B. einen SAN oder Cloud-Speicher, bringen oder weitere Auslagerungsregeln, z.B. per Dokumentenversionen oder bestimmte Spaltenwerte, verwenden möchten, dann kann dies nur eine Drittanbieterlösungen ermöglichen. Exemplarisch möchte ich auch hier AvePoint mit dem „Storage Manager“ nennen.

Viel Spaß beim „SharePointen“

————————————————————-

Weitere Türchen:

SharePoint Performance Tuning – Der Papierkorb

SharePoint Adventskalender – 7. Türchen

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

————————————————————-

Oft unterschätztes, aber dennoch wichtiges Element beim SharePoint Performance Tuning ist der Papierkorb. Bei vielen Unternehmen wird dieser sogar in die Backup-Strategie mit einbezogen. Grundsätzlich ist das möglich, aber nicht optimal. Warum? Das möchte ich erklären.

Sobald man Objekte in den Papierkorb verschiebt, bleiben sie immer noch in der SharePoint Inhaltsdatenbank, damit Endnutzer sie notfalls schnell wieder herstellen können. Oft vergessen wird aber, dass ein Objekt beim Löschen, also beim Verschieben in den Papierkorb, bereits einige seiner Metadaten verliert. Genauer möchte ich darauf jedoch erst im Rahmen der Backup-Best-Practices in einem der späterem Adventskalender-Türchen eingehen.

In Hinblick auf die Performance haben Sie den kleinen Hinweis aber vielleicht schon richtig erkannt: Auch Daten im Papierkorb sind Daten, die weiterhin in der Inhaltsdatenbank liegen! Je größer die Datenbanken, desto länger dauern die Queries, bis sie durch die Datenbank-Tabellen gelaufen sind. Bei stark belasteten Instanzen kann sich so ein Unterschied von mehreren GB schon bemerkbar machen. Sicherlich sprechen wir hier nicht von Sekunden, die den Unterschied je Query ausmachen, aber es ist dennoch ein wichtiger Baustein eines optimalen Performance Tunings für SharePoint.

Achten Sie daher darauf, welche Einstellungen Sie für die Aufbewahrung in Papierkörben wählen. Idealerweise so kurz wie möglich und nutzen Sie stattdessen eine bessere Backup-Strategie mit Drittanbieterlösungen.

Viel Spaß beim „SharePointen“!

————————————————————-

Weitere Türchen:

SharePoint Performance Tuning – SQL Datenbanken vor konfigurieren

SharePoint Adventskalender – 5. Türchen

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

————————————————————-

Heute nur eine schnelle und kurze Information in Anlehnung an den gestrigen Beitrag (http://rob-the-ninja.de/sharepoint-performance-tuning-sql-autogrowth-einstellungen).

In Bezug auf die AutoGrowth-Einstellungen ist es fast schon logisch, dass idealerweise die Datenbanken (durch Datenbankadministratoren) für die SharePoint-Installation vor konfiguriert werden. So vermeiden wir schon bei der Installation und Anbindung die ersten Autogrowth-Operationen.

Die Initialgrößen sollten dabei ausreichend groß gewählt werden, in Hinblick auf die zu erwartende Größe der Inhaltsdatenbanken. Dies muss aber noch nicht die von Microsoft empfohlene Maximalgröße sein. Denn eine initial große Datenbankdatei würde natürlich auch die Backup-Größe und -Zeit beeinflussen. Ein paar Wochen sollten die Datenbanken aber ab Ihrer Erstellung ohne Vergrößerung auskommen. Nach Erreichen der konfigurierten Initialgröße beginnt dann der erste Autogrowth.

————————————————————-

Weitere Türchen:

SharePoint Performance Tuning – SQL AutoGrowth-Einstellungen

SharePoint Adventskalender – 4. Türchen

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

————————————————————-

Auch bei den AutoGrowth-Einstellungen sind die SQL Standardwerte leider alles andere als optimal gewählt. Aufgrund einer kleinen Startgröße und kleiner automatischer Vergrößerungsschritte, können Daten nicht fortlaufend in die Blöcke (Extents) und Seiten (Pages) geschrieben werden. Dies geschieht bei allen INSERT-, UPDATE- und DELETE-Vorgängen. Es kommt zur Fragmentierung, die zu einer schlechteren Performance führt.

Weiterhin werden bei jedem AutoGrowth-Vorgang Server-Ressourcen verbraucht. Bei prozentualen Änderungen kommen noch Kalkulationsvorgänge hinzu. Dies sind alles zusätzliche Operationen, die der SQL nebenbei ausführen muss, bevor er die eigentlichen SharePoint-Anfragen abarbeiten kann. Wir erkennen also, dass wir mit den AutoGrowth-Einstellungen viel beeinflussen können.

Häufige AutoGrowth-Operationen fragmentieren außerdem in Hohem Maße das Transaction-Log. Wie können wir uns das vorstellen? Intern ist jedes Transaction-Log in kleinere virtuelle Logs unterteilt (Virtual Log File – VLF). Abhängig von der Größe, um die das Log erweitert werden soll, wird dieser „Chunk“ in unterschiedlich viele virtuelle Logs aufgeteilt. Dies geschieht nach folgender Regel:

  • Chunks bis 64MB = 4 VLFs
  • Chunks mehr als 64MB und bis zu 1GB = 8 VLFs
  • Chunks mehr als 1GB = 16 VLFs

Aber: Ab SQL 2014 wurde diese Regel etwas angepasst. Ist die Chunk-Größe kleiner als 1/8 der aktuellen Log-Größe?

  • Ja: Erstelle eine neue VLF in der Größe des Chunks
  • Nein: Nutze die Formel oben

Bei vielen kleinen AutoGrowth Operationen mit noch kleinere virtuellen Logs (besonders bevor SQL 2014) fragmentiere ich also meine Datenbanken und Logfiles extrem – und dies beeinflusst die Performance.

Wir gehen noch weiter ins Detail: Angenommen, wir haben eine Datenbank von initial 80 MB und ein ebenso großes Log. Nach obiger Regel haben wir also 8 etwa gleich große virtuelle Log Dateien zu je 10 MB. Nun laden wir in SharePoint eine 12 MB Datei hoch. Was passiert?

SQL „schaut“ in jedes virtuelle Log, ob die Datei da rein passt. Wenn nicht, versucht SQL das nächste usw. Wurden alle VLFs probiert, ohne die Datei schreiben zu können, so wird erst danach eine entsprechende AutoGrowth-Operation durchgeführt, um die Operation abschließen zu können. In der Ziwschenzeit sind aber bereits 8 I/Ops für die Versuche vergangen, die Datei in die kleineren VLFs zu schreiben. Und nun stellen Sie sich vor, sie haben extrem viele dieser kleineren VLFs. Die Summer der nötigen I/Ops dürfen Sie sich gern selber ausrechnen…

Mit der einfachen Query „DBCC LOGINFO“ auf die jeweilige Datenbank können Sie herausfinden, wie viele virtuelle Log-Dateien Sie haben. Die ausgegebene Anzahl der Zeilen, entspricht der VLFs. Sollten es mehr als 50 sein, empfehle ich, diese zu bereinigen und die inkrementellen Zuwachsraten (AutoGrowth) anzupassen. (Weitere Details zur Log Datei Bereinigung finden Sie hier: http://www.sqlskills.com/blogs/kimberly/8-steps-to-better-transaction-log-throughput/)

Die Zuwachsraten sollten idealerweise einen festen und keinen prozentualen Wert haben. Der Wert der Vergrößerung sollte etwa 10 % der Datenbankgröße betragen. Bei einer Inhaltsdatenbank von 10 GB wäre somit der Autozuwachs auf 1 GB einzustellen. (Soll die Datenbank 100 GB und größer werden, können auch größere Zuwachsschritte gewählt werden.) Für die Log-Datei sollte dies ähnlich konfiguriert werden.

Als Ergebnis werden wir weniger Vergrößerungsoperationen haben, welche die Serverleistung reduzieren. Weiterhin haben wir eine geringere Fragmentierung, sodass SharePoint-Anfragen schneller bearbeitet werden können.

——————————————–

Danke auch an Paul Randal http://www.sqlskills.com/blogs/paul/important-change-vlf-creation-algorithm-sql-server-2014/

Weitere Türchen: