Keine Angst vor SQL Server 2017!

Auf der diesjährigen SQL Konferenz in Darmstadt fragte ein Besucher den Speaker, ob der SQL Server 2017 für den produktiven Einsatz stabil genug sei. Der Speaker war sichtlich überrascht, denn so eine Frage hatte er nicht erwartet. „Natürlich können Sie den SQL Server 2017 produktiv einsetzen!“, sagte er.
Die Gründe:

  • Der Code von SQL Server 2017 basiert auf SQL Server 2016.
  • Microsofts Strategie „Cloud First“. Alle neuen Features werden zuerst in der Azure Cloud getestet.
    Der On-Premises SQL Server erhält diese Features erst Monate später.
  • Die Denkweise, dass eine produktive Nutzung erst ab Service Pack 1 möglich ist, ist veraltet, seitdem Microsoft die Update Strategie geändert hat.

Der SQL Server 2017 wurde am 02.10.2017 veröffentlicht. Anfang Januar durfte ich bei einem Kunden das erste Mal einen SQL Server 2017 produktiv installieren. Leider sieht man in der realen Welt immer noch, dass viele Kunden die aktuellste Version des SQL Servers meiden.
Dieser Kunde hatte die MS Strategie inhaliert und ich konnte endlich meinen ersten produktiven SQL Server 2017 installieren – inklusive Always On Availability Groups! Die Erstinstallation ist immer noch etwas Besonderes – auch trotz der etlichen Teststellungen. Die Installation und Konfiguration des SQL Server 2017 verlief wie erwartet reibungslos und die absolvierten H/A Tests und Anwendungstests waren erfolgreich. Es fühlte sich auch unter Stresssituation ausgereift an.

Availability Group Clustertyp

Ich möchte noch kurz auf eine Neuerung in den SQL Server 2017 Always On Availability Groups eingehen. Und zwar kann man bei der Erstellung der Availability Group den „Cluster type“ auswählen. Aber was bedeuten diese drei Typen?

Windows Server Failover Cluster
  • Always On Availability Group basiert auf einem Windows Server Failover Cluster. Das ist das Szenario, welches bis SQL Server 2016 standardmäßig eingesetzt wurde.
EXTERNAL
  • Bei diesem Clustertyp wird ein externer Cluster-Manager verwendet wie z.B. Pacemaker unter Linux. Ab SQL Server 2017 möglich.
NONE
  • Einsatz ohne Cluster, wenn keine Hochverfügbarkeit oder Disaster Recovery Szenarien notwendig sind. Datenbanken werden als Kopie auf mehrere Server repliziert, um eine hohe Leselast zu bewerkstelligen.
  • Einsetzbar für die Replikation zwischen Windows und Linux.

Diese Einstellungen können auch mit T-SQL konfiguriert werden.

 

Fazit

Ja, der SQL Server 2017 ist stabil.

 

Links

Leave a Comment

Your email address will not be published. Required fields are marked *