SQL 2012 mit SharePoint 2013

Wie auch schon bei SharePoint Server 2010 und SQL Server 2008 R2 ist die Optimierung der Datenbanken das A und O einer schnellen SharePoint Umgebung. Dies hat sich auch mit SharePoint Server 2013 und SQL Server 2012 nicht geändert. Nachstehend listen wir noch einmal kurz die wichtigsten Best Practice Ansätze auf und stellen neue Features von SQL Server 2012 und SharePoint 2013 vor.

Best Practices
Grundsätzlich lässt sich sagen, dass die bereits bekannten BestPractices auch mit SQL 2012 noch ihre volle Gültigkeit haben. Diese sind insbesondere:

  • Dedizierte SQL Instanz für SharePoint
  • Collation «Latin1_General_CI_AS_KS_WS »
  • NTFS File Allocation Unit Size sollte 64KB sein (Performancegewinn bis zu 30%)
  • Priorisierung hinsichtlich Storage Performance
    1. TempDB (optimiert für Schreiben, sollte am schnellsten sein)
    2. DB Transaction Log File (optimiert für Schreiben)
    3. Search DB Data File (optimiert für Lesen/Schreiben)
    4. Content DB Data File (optimiert für Lesen)
  • TempDB in mehrere Files aufsplitten und auf unterschiedliche Disks/LUNs legen
  • MDF und LDF auf unterschiedliche Disks legen
  • Verwenden von SQL Alias
  • ModelDB anpassen (DB-Grösse, Autogrow, Standard-Pfade, etc.)
  • Content DB unter 200GB halten (die Grösse gilt auch wenn RBS verwendet wird)
  • Shrinking sollte nur in Ausnahmefällen angewendet werden
  • Regelmässiges Backup von MDF und LDF (letzteres verhindert allzu grosse Logfiles)
  • Backup Compression verwenden (Höhere Performance, weniger Platzbedarf)
  • Regelmässige Integritätschecks durchführen
  • Index FillFactor zwischen 70% und 80%
  • MAXDOP = 1
  • Min / Max Memory Settings

AlwaysOn
Die wesentlichste Neuerung, die SQL 2012 mit sich bringt, ist sicherlich AlwaysOn. Eigentlich handelt es sich dabei nicht um ein neues Feature, es ist vielmehr die intelligente Kombination aus bestehenden Technologien: Microsoft verknüpft die Vorzüge des Failover-Clusterings (Verfügbarkeit der SQL-Instanz) mit denen der Datenbankspiegelung (Verfügbarkeit der Datenbank). Dadurch werden neue, interessante Möglichkeiten eröffnet.

Konzept
Mittels sogenannten „Verfügbarkeitsgruppen“ werden Datenbanken zusammengefasst, die im Desasterfall verschoben werden sollen. Durch die Datenbankspiegelung wird die Verfügbarkeitsgruppe auf einen entfernten Server repliziert. Dieser Server kann dank der Spiegelung ein unabhängiges Storagesystem haben. Steht der aktive Node nun nicht mehr zur Verfügung, wechselt das Failover Clustering automatisch auf die entfernte Instanz und die Verfügbarkeitsgruppe des dortigen Servers wird aktiv geschaltet.

Subnetz übergreifendes Clustering
SQL AlwaysOn bietet eine Hochverfügbarkeits- und DisasterRecovery-Lösung, mit der sich neu auch über die Subnetz-Grenze hinweg ein Failover machen lässt. So kann auf die komplexe Konfiguration von ausgedehnten, standortübergreifenden VLAN’s verzichtet werden.

Erhöhte Flexibilität für Reportings und Backups
Durch sogenannte „ReadOnly Active Secondary Replicas“ ist es nun möglich, lesend auf replizierte Datenbanken zuzugreifen und diese für Reporting oder Backups zu verwenden. Dadurch wird die produktive Instanz deutlich entlastet und Reports, resp. grössere Backups können auch während der Bürozeiten gemacht werden.

Weitere Informationen zu AlwaysOn finden sich hier: http://technet.microsoft.com/de-de/sqlserver/gg508768.aspx

Shredded Storage
SharePoint-seitig ist im Zusammenhang mit SQL das Feature „Shredded Storage“ hervorzuheben.

Prinzip
Dateien werden in sogenannten „Chunks“ (zu Deutsch: “Stück“) in der Datenbank abgelegt. Ändert nun ein Teil eines Dokuments, wird nur der betroffene „Chunk“ angepasst und als neue Version abgelegt. Details dazu hier: http://blogs.technet.com/b/wbaer/archive/2012/11/12/introduction-to-shredded-storage-in-sharepoint-2013.aspx

Durch die Verwendung von Shredded Storage lässt sich je nach Situation viel Speicherplatz einsparen. Das Feature ist allerdings Dokumenten-basiert und daher eigentlich nur im Zusammenhang mit Versionierung sinnvoll.

Speicherplatz sparen hört sich zunächst gut an, doch die Optimierung geht letztlich auf Kosten der Performance, denn die einzelnen Chunks müssen beim Download jeweils wieder zusammengesetzt werden. Die Firma AvePoint hat hierzu einen interessanten Test durchgeführt: http://www.docave.com/TeamBlog/Lists/Posts/Post.aspx?ID=105

Fazit
Will man Speicherplatz optimieren, setzt man heute besser auf Remote BLOB Storage mit De-Duplication auf dem Storage Level. Dadurch lässt ohne allzu grosse Performanceeinbussen viel teurer Datenbank-Speicherplatz einsparen.

Zu beachten

  • Das Feature ist standardmässig aktiviert und lässt sich nicht über das GUI deaktivieren. Möchte man darauf verzichten, kann die Grösse der Chunks manuell auf einen extrem hohen Wert gesetzt werden.
  • Das Feature greift auch bei Remote BLOB Storage Inhalten
  • Migrierte Dateien werden nicht automatisch „geshredded“. Dies passiert erst, wenn eine neue Version erstellt wird.

0 Responses to “SQL 2012 mit SharePoint 2013”



  1. Schreibe einen Kommentar

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s





%d Bloggern gefällt das: