Schlagwort-Archive: SQL

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 Configuration Best Practices – Benamte SQL Instanzen und dedizierte Ports

SharePoint Adventskalender – 14. Türchen

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

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

Bei der Installation von SQL kann man sicherlich auch die Standardinstanz ohne eigenen Namen und mit dem Standard TCP/IP Port 1433 verwenden, aber dies ist nicht praktikabel und auch nicht zu empfehlen für produktive Systeme. Schon allein, wenn mehr als eine Instanz auf einem SQL laufen sollen, muss logischerweise mindestens ein Name oder ein anderer dedizierter Port vergeben werden. Zudem können Sie mit dedizierten Namen Ihre Infrastruktur besser verwalten und überblicken. Neben der einfacheren Verwaltung spielt in diesem Kontext aber auch die Sicherheit der Infrastruktur eine Rolle.

Sicherheit:

Da Port 1433 der Standardport ist, wird dieser gern von Hackern als einer der ersten abgefragt, um Zugriff auf die Datenbanken zu erhalten. Es ist daher ratsam, der Instanz einen dedizierten Port zu vergeben, der nicht 1433 ist.

Verwaltbarkeit:

Für SQL können dynamische Ports verwendet werden, sodass wir uns nicht auf einen festlegen müssen. Der Nachteil liegt aber auf der Hand. Eine Firewall-Konfiguration anhand von Ports wird dadurch nahezu unmöglich. Sollte nämlich nach einem Restart der Instanz ein neuer Port vergeben werdnen, weil der vorherige einem anderen Service mit dynamischer Portvergabe zugewiesen wurde, so kann im schlimmsten Falle der SharePoint (weiterhin) nicht verfügbar sein. Der Grund ist, der neue Port wurde vermutlich noch nicht in der Firewall geöffnet. Empfehlenswert ist hierbei eine Firewall-Regel, die programmbasiert ankommende Verbindungen am SQL erlaubt. Dafür müssen Sie aber auch alle Programme kennen, die auf den SQL zugreifen können und dürfen. Dies kann umständlich sein, weshalb ich daher empfehle, einen festen Port zu wählen und die Firewall entsprechend zu konfigurieren.

Denken Sie auch daran, dass Sie bei benamten Instanzen auch den Port 1434 für das UDP Protokoll öffnen – unabhängig davon, ob Sie fixe oder dynamische Ports nutzen. Warum ist das so? Nur bei nicht benamten Standard-Instanzen hört der SQL Server selbst auf Port 1433. Bei allen anderen Szenarien hört der SQL Browser Service auf ankommende Verbindungen und weist diesen dann die jeweiligen dynamischen oder fixen Ports zu. Erst danach kommt die Verbindung am tatsächlichen Port an, auf den die SQL Instanz hört. Logischer Weise muss dafür auch immer der SQL Browser Service laufen, da sonst die ankommenden Verbindung nicht zugewiesen werden können.

Im SQL Konfigurationsmanager empfehle ich daher, den fixen Port für die TCP/IP Konfiguration zu setzen und den Dynamischen Port komplett zu löschen (also auch den standardmäßig hinterlegten Wert „0“ zu entfernen, wie im Screenshot zu sehen ist). Achten Sie auch darauf, dass Sie den Port für den Alias im Konfigurationsmanager oder über das cliconfg.exe Tool korrekt setzen.

Ist dies alles erledigt, so ist auch die Firewall-Konfiguration ein leichtes Spiel und schließt die SQL Instanz- und Portkonfiguration ab.

Viel Spaß beim „SharePointen“!

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

Weitere Türchen:

SharePoint Configuration Best Practices – SQL Alias

SharePoint Adventskalender – 13. Türchen

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

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

Einen fröhlichen 3. Advent wünsche ich! Die tief technischen Tipps für eine optimierte SharePoint Performance haben wir nun hinter uns gebracht. Heute und in den nächsten Tagen widmen wir uns ein paar Best Practices in Hinblick auf die Konfiguration von SharePoint und SQL.

Beginnen wir mit einem einfachen Tipp – der SQL Alias. Wie wir wissen, gehört SharePoint und SQL einfach zusammen. Daher muss SharePoint immer wissen, wo sich seine Datenbanken befinden. Diese Referenz wird bei einer benamten Instanz mit „Servername\Instanzname“ angegeben. In einem SQL Cluster referenzieren wir natürlich den virtuellen Hauptknoten der verschiedenen SQL Nodes und den „Windows Listener“ bei einer SQL Always-On-Availability-Group.

Der Vorteil eines Alias ist die Möglichkeit, dass ich das Backend ändern kann, ohne große Konfigurationen am Frontend vornehmen zu müssen. Ist besipielsweise der SQL zu langsam geworden und soll auf einen neuen Server und/oder auf eine neue Instanz, dann muss ich nicht für jede Inhaltsdatenbank und jeden Service in SharePoint die neue Referenz setzen. Stattdessen passe ich nur einmalig den Alias an. Auch eine Änderung des Ports kann so ganz einfach erledigt werden.

Bitte achten Sie auch darauf, sollten Sie noch Systeme im 32bit-Modus haben, dass Sie den Alias sowohl für diese, also auch für die 64bit-Systeme setzen. Das Windows Tool „cliconfg.exe“ setzt für Sie den Alias. Dieses Tool finden Sie hier:

32bit-Mode:
C:\Windows\System32\cliconfg.exe
64bit-Mode:

C:\Windows\SysWOW64\cliconfg.exe

Ob die Einstellungen korrekt am System “angekommen” sind, können Sie in der Registry in folgenden Pfaden überprüfen:

32bit-Mode:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo
64bit-Mode:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\ConnectTo

Achten Sie außerdem darauf, dass Sie diese Einstellungen ebenso auf dem SQL machen, um sich auch von dort lokal mit einem Alias im SQL Management Studio mit der jeweilige Instanz verbinden zu können – dies können Sie auch direkt im SQL Configuration Manager erledigen.

Zusammengefasst ist so ein Alias also ein extrem nützliches Werkzeug, um mögliche spätere Server-, Instanz- oder Portänderungen ohne viel Konfigurationsaufwand am zugehörigen SharePoint erledigen zu können.

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 TempDB Einstellungen

SharePoint Adventskalender – 6. Türchen

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

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

Die TempDB des SQLs kann man im weitesten Sinne wie den RAM-Speicher des Betriebssystems verstehen. Sie speichert unter anderem temporäre Benutzerobjekte wie Tabellen und Prozeduren, interne Objekte z.B. für das Speichern von Zwischenergebnissen und Zeilenversionen zum Beispiel für Datenänderungstransaktionen. Die TempDB wird bei jedem Start von SQL neu erstellt und alle gespeicherten Daten werden beim Trennen der SQL-Verbindung wieder gelöscht.

Mit dieser Analogie zum RAM-Speicher ist also leicht zu verstehen, dass Optimierungen der TempDB auch zur Verbesserung des gesamten SQLs führen und damit auch unseren SharePoint beschleunigen. Die verschiedenen Möglichkeiten, um die TempDBs zu optimieren, möchte ich hier auflisten:

  • Das Recovery Model sollte auf SIMPLE gestellt werden
  • Die TempDB kann auf mehrere Dateien aufgeteilt werden
    • bei bis zu acht logischen Prozessoren: #Kerne = #TempDB-Dateien
    • bei mehr als acht Prozessoren genau acht TempDB-Dateien konfigurieren
      • wenn Speicherkonflikte (In-Memory-Contentions) auftreten, sollten die TempDB-Dateien jeweils um vier erweitert werden, bis die Konflikte auf ein normales Niveau absinken
      • Hinweis: Daumenregel besagt #Kerne = ½ bis ¼ TempDB-Dateien
    • alle TempDB-Dateien sollten die gleiche Größe und gleichen Einstellungen haben
    • jede Datei sollte 25 % der Größe der größten Inhaltsdatenbank haben
    • die Dateien können auch über mehrere Spindeln verteilt werden, um eine noch bessere Performance zu erzielen
      • Hinweis: Da alle zusätzlichen Datendateien per Definition SECONDARY-Dateien sind, sollten Sie das Format *.ndf zuweisen anstelle des *.mdf für die initiale PRIMARY-Datei.
  • Die TempDBs sollten auf den schnellsten Laufwerken platziert werden
  • Auf den TempDB-Laufwerken sollte mehr als 25 % freier Speicher zur Verfügung stehen, um zu Peak-Zeiten das Anwachsen der Dateien zu ermöglichen
    • AutoGrowth ähnlich konfigurieren wie für Inhaltsdatenbanken, siehe 4. Türchen (Link unten)

Das sind einige Punkte, die Sie berherzigen sollten. Gleichzeitig macht dies auch deutlich, wie viele nicht optimale SQL Einstellungen es gibt, wenn unser SharePoint mit ins Spiel kommt. Aber schlechte Gewissen, ob Ihre Datenbanken optimal für SharePoint konfiguriert sind, soll es heute nicht geben. Genießen Sie stattdessen den Nikolaus und den 2. Advent. Aber schauen Sie gleich morgen mal nach bzw. sprechen Sie mit Ihren SQL-Admins.

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:

SharePoint Performance Tuning – SQL MAXDOP

SharePoint Adventskalender – 3. Türchen

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

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

Sicherlich sollte diese Einstellung jedem SharePoint Administrator bekannt sein. In SharePoint 2013 gibt es sogar eine Health Analyzer Regel, die den gesetzten Wert des Maximalen Grad an Parallelität (MaxDegreeOfParallelism) überprüft. Ich möchte dennoch erklären, was genau dahinter steckt und warum dieser Wert so wichtig für die SharePoint Performance ist.

Die MAXDOP kann beschränken, wie viele Prozessorkerne SQL gleichzeitig nutzen soll, um Anfragen abzuarbeiten. Also je mehr Kerne, desto schneller kann SQL arbeiten. Dies funktioniert auch sehr gut, wenn es um reine Datenbankaufgaben geht, weil SQL sehr intelligent die Anfragen verteilt.

Kompliziert wird es nur, wenn SharePoint ins Spiel kommt. Denn SharePoint optimiert die Anfragen, bevor sie tatsächlich an den SQL gesendet werden. Das heißt, der erneute Versuch seitens SQL, die eingehenden Anfragen zu optimieren, lässt das ganze ineffizient werden. Daher sollte der Wert auf 1 gesetzt werden, damit die Anfragen so abgearbeitet werden, wie sie vom SharePoint kommen.

Zur Information: Der Wert 0 (standard), nutzt alle verfügbaren Prozessorkerne. Die Werte 2 bis n adressieren die genaue Anzahl der Kerne, die genutzt werden sollen. Setzen können Sie den Wert pro Instanz in den Instanzeinstellungen. Navigieren Sie dort zu den erweiterten (Advanced) Einstellungen.

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

Weitere Türchen:

SharePoint Performance Tuning – SQL Speicherzuweisung

SharePoint Adventskalender – 2. Türchen

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

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

Kommt Ihnen die Zahl 2147483647 bekannt vor? Dies ist der Speicherwert in MB, der SQL maximal vom Arbeitsspeicher zur Verfügung steht – also 2 PB (PetaByte!).

Der SQL nimmt sich so viel Arbeitsspeicher, wie er braucht und wie er kriegen kann. Dabei ist es SQL egal, ob dem Betriebssystem noch etwas übrig bleibt. Hat SQL einmal so viel Arbeitsspeicher genommen, dass selbst das Betriebssystem keine weiteren Prozesse und Threads bearbeiten kann, so hängt der Server. Die CPU Nutzung und Disk I/O erhöhen sich stark, weil Windows beginnt, mehr und mehr RAM auf die Festplatte auszulagern. Dadurch erhöhen sich die Antwortzeiten und SharePoint wird langsam, bzw. fällt ganz aus, wenn die Datenbankserver neu gestartet werden müssen, um das Problem zu lösen.

Daher sollte man den maximalen Wert der Arbeitsspeicherzuteilung so einstellen, dass stets ein Rest für das Betriebssystem bleibt. Bei kleineren Servern sind etwa 80-85% des maximal verfügbaren Speichers zu empfehlen. Bei sehr viel verfügbarem Speicher (> 64 GB) sollte etwa 8 GB für das Betriebssystem reserviert werden. Bitte denken Sie auch daran, sollten bei Ihnen mehrere SQL Instanzen auf einem Server laufen, dass sich natürlich die zugewiesenen Speicher pro Instanz addieren. Also bei beispielsweise zwei Instanzen sollten beide zusammen nicht die 80-85% überschreiten, bzw. bei größeren Systemen 8 GB übrig lassen.

Auch wenn der minimale Wert keine großen Probleme macht, so empfehle ich, diesen auf 1-2 MB zu setzen, damit SQL immer eine Grundlast hat. SQL läuft damit stabiler und ist schnell auf „Betriebstemperatur“.

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

Weitere Türchen: