Optimierung der TempDB für bessere Performance

12. Juli 202212. Juli 2022 Björn Peters

Ich wurde gerade via E-Mail nach der optimalen Konfiguration der TempDB gefragt, daher möchte ich hier die Gelegenheit nutzen, meine persönliche Erfahrung und Best-Practice darstellen, denn im Grunde wiederholt sich alles und es gibt sicherlich technisch ausführlichere Darstellungen als meine folgende 😉

Ich möchte im folgenden meine Standard-Konfiguration für die TempDB auf allgemeinen SQL Servern (ab SQL Server 2016/2017) vorstellen und daraufhin weisen, dass es natürlich Abweichungen geben kann/sollte, die je nach Anwendung, Anforderungen oder Systemen davon abweichen können. Wenn mich ein Kunde nach einem “0815” SQL Server fragt, auf dem er mehrere gemischte Applikationen betreiben kann, dann erhält er von mir diese Konfiguration als Empfehlung.

Und natürlich sollte man sich bewusst sein, dass die TempDB eine System-Datenbank und für den Betrieb des SQL Servers unerlässlich ist, also eine gewisse Kenntnis und Vorsicht sollte vorhanden sein!

Festplatten für die TempDB

Die TempDB besteht wie alle Datenbanken auf einem SQL Server mindestens aus einer Datendatei und einem Transaktionsprotokoll, mittlerweile sollte allgemeinhin bekannt sein, dass man Datendateien und Transaktionsprotokolle – aufgrund des unterschiedlichen Schreib-Lese-Verhaltens – voneinander trennt, dies ist natürlich auch bei der TempDB der Fall.

Idealerweise liegt die TempDB auf einer eigenen Platte (und ich rede hier von einer eigenständigen Platte und nicht einer Partition) und verfügt idealerweise über einen eigenen Storage-Controller, dies hat nicht nur Bedeutung für die Performance des SQL Servers sondern auch administrative Vorteile… in der TempDB kann theoretisch jeder User unzählige eigenen Objekte anlegen, Daten ablegen, Gruppieren oder Sortieren, also eine ganze Menge Daten dort “speichern”, heißt das Datenfile der TempDB kann enorm wachsen… wenn dies jetzt auf der selben Platte wie die User-Datenbanken liegt… könnte man sehr schnell in ein Problem laufen!

Da die TempDB eigentlich eher selten Transkationen protokollieren möchte/muss, kann das Transaktions-Protokoll der TempDB gerne auf dem Laufwerk der allgemeinen Laufwerk für die Transaktionsprotokolle abgelegt werden.

Fazit => Wir brauchen also eine sehr performante Platte – in einer Azure VM ist es immer die performanteste Platte, die lokale SSD.

Aber wie groß soll diese Platte werden? – Das ist immer schwierig zu sagen, sollte man die Platte so dimensionieren, dass die größte Datenbank (theoretisch) hineinpasst, oder der größte Index… das ist schwierig zu sagen, meine Empfehlung ist meistens => Schauen Sie sich die Gesamtgröße ihrer User-Datenbanken an und orientieren sich daran.

Beispiel:
Alle Datendateien der User-Datenbanken auf dem SQL Server haben in Summe eine Größe von 365GB, die Größe der Transaktionsprotokolle spielt hierfür erst einmal keine Rolle.

dann nehme ich diese Größe als 100% Data an und um nicht in ein Problem zu laufen, addiere ich einen Puffer von 25%, dann habe ich die Größe der Daten-Platte => 365GB + 25% = 456GB (ich rechne noch gerne in den “alten” Plattenkapazitäten, die es zu kaufen gab), also würde ich meinem Kunden empfehlen dem SQL Server eine Festplatte von 450-480GB für die Datendateien der User-Datenbanken zur Verfügung zu stellen.

Davon ausgehend errechne ich die Größen für die TLog-Platte und die TempDB => je nach Vorgespräch und Nutzungsverhalten der Applikationen empfehle ich eine Größe der Platte für diese Systemdatenbank zwischen 25 und 33 Prozent von Data, in unserem Beispiel dann 120-160GB.

Konfiguration der TempDB

Nun kann man mittlerweile im Rahmen des SQL Server Setups zweierlei Dinge tun

Berechtigungen des SQL Server Service-Users für “Instant File Initialization” vergeben
TempDB Konfiguration anpassen

TempDB-Konfiguration - SQL Server 2019 Setup - Screenshot

Hier ist es eine gute Empfehlung einfach mit den Vorgaben von Microsoft weiterzumachen, oder den Best-Practices zu folgen. 😉

Zum einen ist “Instant File Initialization” für das Handling der Datendateien relevant, sollte man also auf jeden Fall die Berechtigungen für den SQL Server Service-User setzen! Zum anderen ist die Default-Konfiguration der TempDB durch das Setup schon einmal ein sehr guter Einstieg.

Also der SQL Server sollte zwischen 1 und 8 Datendateien für die TempDB erhalten, je nach Anzahl der zur Verfügung stehenden Kerne. Wer es ganz genau wissen möchte, und ob 8 für sein System der maximale Wert ist, sollte sich den Artikel zum KB2154548 durchlesen, hier werden die genauen Details beschrieben. Für meinen “0815”-SQL Server gilt daher die grobe Formel:

Anzahl Datendateien der TempDB = wenn Anzahl Kerne kleiner 8, dann Anzahl Kerne sonst 8

Jetzt kommt ein Teil in der Konfiguration über den man sich streiten kann/könnte oder in eine Richtung “Glauben” gehört… sollte man die Datendateien initial klein lassen und mit der Nutzung wachsen oder sollte man die Dateien gleich auf das Platten-Maximum aufblasen?
Ich halte es hier wie Brent Ozar, wenn ich schon eine ganze Festplatte nur für die TempDB habe, dann kann ich diese auch gleich voll nutzen 😉 Also berechne ich wie folgt die Größe der einzelnen Datendatei (aus unserem obigen Beispiel):

160 GB Platten-Kapazität für die TempDB
die meisten Monitoring-Systeme schlagen bei 90% Füllgrad an, daher wird ein Maximum von 89% der Plattenkapazität angenommen => ~142GB
mein SQL Server verfügt über 8 Kerne (siehe Screenshot) = 142GB / 8 Datendateien = 18.176 MB pro Datendatei

Diese Konfiguration lässt sich auch sehr schön und einfach mit dbatools realisieren, denn übernimmt das PowerShell für mich die komplette Konfiguration und Kalkulation.

Set-DbaTempDbConfig -SqlInstance ServerName\InstanceName -DataFileCount 8 -DataFileSize 145408 -DataFileGrowth 0

TempDB diverse Contention Probleme

Nur um die Vollständigkeit zu waren, es kann auch Probleme mit der TempDB geben, diese sind – bei 0815-Systemen – eher selten, können aber vorkommen:

Lassen sich aber auch mit den entsprechenden Anleitungen verhindern oder beseitigen. Mittels dem neuen Feature “Memory Optimized MetaData for TempDB” kann in gewissen Szenarien die Performance der TempDB noch weiter erhöht werden, dazu mehr in diesem Artikel bzw in dem dazugehörigen Video. Ansonsten folgen im Anhang noch relevante Links zur Konfiguration der TempDB.

Zusammenfassung

Der SQL Server Service User sollte die Rechte zum Ausführen der “Instant File Initialization” erhalten, die Datendateien der TempDB auf einer eigenständigen Platte abgelegt werden, es sollten 2-8 Datenfiles angelegt werden und die Datenbank initial voll aufgeblasen werden ohne AutoGrowth.

Sehr guter technischer Artikel zur TempDB

Microsoft Dokumentation zur TempDB

Beitragsfoto von Mike Newbry auf Unsplash

Björn Peters

Björn arbeitet in Hamburg als Senior Consultant – Microsoft Data Platform und Cloud bei Kramer&Crew. Er nimmt regelmäßig an den PASS Regionalgruppen Treffen in Hamburg, den Veranstaltungen der PASS wie SQLSaturday und DataGrillen teil und organisiert in Hamburg das Azure Meetup. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure für Science-Fiction, Snowboarden, Backen 😉 und Radfahren.

Warum “SQL aus Hamburg” oder “Nord DBA” ?

10. August 20219. August 2021 Björn Peters

Eigentlich hätte ich diesen Beitrag schon vor Jahren mal schreiben sollen ;-), um die Historie bzw die Entstehungsgeschichte dieses Blogs zu beleuchten. Aber wie heißt es so schön… es ist nie zu spät.

Damals hatte ich meine ersten Initiativen und Aktivitäten mit der deutschen SQL Server Community unternommen, die ersten Veranstaltungen besucht und die ersten Kontakte geknüpft und musste leider feststellen, dass meine Kenntnis vom SQL Server auch nach mehr als 10 Jahren eher gering ausfiel. Dies gefiel mir selber nicht und ich habe mir das Ziel gesetzt mich mehr mit dem Produkt zu beschäftigen, also im Grunde genau die Geschichte warum ich in der Community aktiv bin. Zu der zeit war ich als Datenbank-Administrator beschäftigt und habe gemeinsam mit meinem Kollegen Thomas, die SQL Server unserer Kunden betreut. Thomas wusste aus anderen Bereich zum SQL Server viel und ich wusste ja auch schon viel, so haben wir uns wunderbar ergänzt. Gemeinsam wollten wir diesen Blog betreiben und über unsere täglichen Erlebnisse, Probleme oder Herausforderungen schreiben. Da wir beide – in einem größeren Team verteilt über Deutschland – aus Hamburg kamen und es um unsere Hauptaufgabe – den SQL Server – ging, war die Suche nach einem Namen relativ einfach…

Aufgrund meiner – damals noch aktiven Selbstständigkeit – war ich bereits im Besitz eines entsprechenden Webspace und die Domäne “SQL-aus-Hamburg.de” war schnell registriert. Der erste Blogbeitrag ließ auch nicht lange auf sich warten, dann wurde es etwas ruhiger 🙁
Wir hatten uns das wahrscheinlich einfacher vorgestellt, die Arbeit wurde mehr… ich kann nicht mehr genau sagen, warum wir nichts geschrieben haben… vielleicht war es oder wir damals einfach noch nicht so weit… Thomas hatte immer gute Ideen und hat mir sozusagen die Überschriften geliefert… aber leider nie selber geschrieben (soll kein Vorwurf sein!)… und dann kam alles anders… Leider ist Thomas unerwartet und plötzlich verstorben, ich musste und habe dann diesen Blog unter demselben Namen weitergeführt.

Für mich ist dieser Blog im Grunde immer noch, siehe die letzten Posts zum Azure SQL Database Refresh, nur ein Notizbuch, in dem ich meine eigenen Erfahrungen für mich selber Revue passieren lasse, um sie vielleicht irgendwann doch einmal herauszusuchen oder mich daran zu erinnern, wann ich was wie erfolgreich lösen konnte.

Warum SQL-aus-HH ???

In den sozialen Medien findet man mich entsprechend auch unter @SQL_aus_HH, für den deutschsprachigen Leser überhaupt kein Problem eine Verbindung zwischen Hamburg und HH zu ziehen… ursprünglich hatte ich auch nie mit dem Gedanken gespielt, dass ich irgendwann auch mal englischsprachige Beiträge schreibe oder sogar Vorträge auf internationalen Veranstaltungen halte… daher hier noch einmal zur Verdeutlichung für die “Ausländer”.

Hamburg ist eine Hansestadt und trägt daher auf dem deutschen KFZ-Nummernschild die Abkürzung HH für “Hansestadt Hamburg“.

Bereits im Mittelalter verdienten sich Kaufleute mit dem Fernhandel eine goldene Nase. Besonders erfolgreich war die Hanse. So nannte sich vor etwa 700 Jahren ein Bündnis aus Städten und Kaufmannsverbänden. Der Hansebund wurde geschlossen, um den Handel zwischen den Mitgliedern, den Hansestädten, zu vereinfachen. Damals erschwerten zahlreiche Zölle, verschiedene Währungen und Maßeinheiten den Fernhandel.
[…]
Letztendlich trugen nur noch Hamburg, Bremen und Lübeck offiziell den Titel einer Hansestadt. Hamburg und Bremen haben ihre hanseatische Eigenständigkeit zum Teil sogar bis heute bewahrt. Sie sind – neben Berlin – die einzigen deutschen Städte, die gleichzeitig ein eigenes Bundesland sind. Auch ihre Autokennzeichen weisen auf den mittelalterlichen Städtebund hin: HH steht für die Hansestadt Hamburg und HB für die Hansestadt Bremen.
http://stadtgeschichtchen.de/artikel/stadtgeschichte/was-ist-eine-hansestadt/

http://stadtgeschichtchen.de/artikel/stadtgeschichte/was-ist-eine-hansestadt/

Da dieser Blog damals von zwei Personen geführt werden sollte, hatte ich mir auch Gedanken über einen Namen für meinen “persönlichen Auftritt” gemacht bzw wollte im Zusammenhang mit einem Favicon für den Blog etwas “kreativer” sein… als “Nord-DBA”… bitte fragt mich nicht nach den Gründen/Gedanken, die zu diesem Namen geführt haben… ich kann es schlicht weg nicht mehr sagen, aber seit gut 10 Jahren gibt es eben dieses Favicon als “Erkennungszeichen” für diesen Blog.

Solltet ihr noch Fragen zu der Entstehungsgeschichte meines Blogs haben… so schreibt mich einfach an.

Björn Peters

Echt jetzt ??? Datenbank mit aktiviertem Auto_Close ???

19. März 202119. März 2021 Björn Peters

Ich bin hvor kurzem erneut über eine Konfiguration auf einer Datenbank bzw auf einem SQL Server gestolpert, bei der ich immer wieder frage: “Wie kommt man im Jahr 2020/21 auf die Idee an einer Datenbank den Parameter “Auto_Close” auf True zu setzen?” Selbst wenn man diesen Wert seit Jahren und etlichen Versionen “mit sich herumschleppt”, so muss das doch irgendwann mal auffallen… In der Vorbereitung auf diesen Blog-Post habe ich zahlreiche Artikel gefunden, die schon mindestens 10 Jahre alt sind (zum Beispiel) und davon abraten, diesen Konfigurationsparameter auf “true” zu setzen. Aber einmal der Reihe nach, was macht dieser Parameter, was bewirkt er und warum waren manche Dienstleister der Meinung, dass das Aktivieren von AutoClose eine gute Idee sei.

Was ist dieses AutoClose

Gemäß Microsoft Dokumentation

AUTO_CLOSE

Wenn ON festgelegt wurde, wird die Datenbank heruntergefahren, und die Ressourcen werden freigegeben, wenn der letzte Benutzer die Datenbank beendet hat. Die Datenbank wird automatisch erneut geöffnet, wenn ein Benutzer versucht, die Datenbank nochmals zu verwenden.Wenn OFF festgelegt wurde, bleibt die Datenbank geöffnet, nachdem der letzte Benutzer die Datenbank beendet hat.

Diese Option ist für alle Datenbanken auf True festgelegt, wenn Sie SQL Server 2000 Desktop Engine oder SQL Server Express verwenden, und unabhängig vom Betriebssystem auf False festgelegt, wenn Sie eine der anderen Editionen verwenden.

-- Aktivieren der AUTOCLOSE Funktion
USE [master]
GO
ALTER DATABASE [WideWorldImporters] SET AUTO_CLOSE ON WITH NO_WAIT
GO

-- Deaktivieren der AUTOCLOSE Funktion
USE [master]
GO
ALTER DATABASE [WideWorldImporters] SET AUTO_CLOSE OFF WITH NO_WAIT
GO

Heißt also, dass alle Datenbanken die irgendwann mal vor “Jahrzehnten” auf einem SQL Server Express oder einer Desktop Engine erstellt wurden, diesen Parameter (im worst-case seit 20 Jahren) bei jeder Migration mit sich mitnehmen… Warum schaut hier denn kein Admin hin und setzt diesen Wert wieder auf das Optimum “false” )? Natürlich muss ich zumindest daraufhin weisen, dass es unter ganz bestimmten Anwendungsfällen auch sinnvoll sein kann, diesen Parameter zu aktivieren! (dazu später mehr)

Also um das noch einmal im Detail zu erläutern, was AutoClose bewirkt… Die Datenbank schläft eigentlich immer, da Auto_Close aktiviert wurde, dann kommt der User und möchte Daten aus der Datenbank abfragen… dann muss der SQL Server diese Datendateien erst öffnen, einen DBCC CheckDB laufen lassen… die Folge davon ist natürlich ein gewisser Zeitverlust je nach Größe der Datenbank, der allgemeinen Leistung des System und der aktuellen Last auf dem System.

Ich kann mir gut vorstellen, warum man früher der Meinung war, dass die Nutzung dieser Option eine gute Idee war… früher – also rund um den SQL Server 2000 bzw 2005 – gab es noch nicht so performante Systeme und Ressourcen waren teurer, daher hat man sich somit erhofft System-Ressourcen zu sparen und für andere Datenbanken und Applikationen nutzen zu können. Ebenso habe ich gelesen, dass es damals was damit zu tun gehabt haben soll, dass der SQL Server auch auf FAT32-Filesystemen lauffähig (Windows 98) war und es hier Befürchtungen gab, dass Datenbanken “zerstört” werden könnten weil sie eben nicht richtig geschlossen (im Filesystem) wurden.*¹ Und natürlich wie in der Microsoft Dokumentation benannt, war das natürlich bei allen “freien” Versionen der Fall, da hier nur eine CPU genutzt werden konnte, hier dann einer Ressourcen-Knappheit vorgebeugt werden sollte.

SQL-Server - Database Properties - Options - Auto_Close

Worst-case: Performance-Impact

Der worst-case ist natürlich, dass die Aktivierung – ob gewollt, ungewollt oder eben per Default – zu Performancebeinträchtigung des SQL Servers und der nutzenden Applikationen kommt. Durch das ständige Öffnen und Schliessen der Datenbanken und das damit verbundene Überprüfen der Datenbank-Konsistenz. Wie bereits angedeutet, kann es Sinn machen, diese Funktion zu aktivieren, denn es gibt immer Ausnahmen… zum Beispiel könnte ich mir Entwickler-Server vorstellen, bei denen jeder Entwickler seine eigene Datenbank hat und ggfs nicht alle gleichzeitig arbeiten/entwickeln, dann könnte es unter Umständen Sinn machen, diesen Konfigurationspunkt zu verändern. Oder – und hier kommt wieder der Blogbeitrag von Greg*¹ zum Tragen – wenn man einen SQL Server mit vielen Datenbanken hat, die aber nicht alle gleichzeitig genutzt werden (zum Beispiel ein weltweit agierender Händler mit sehr vielen Standorten und jeder Standort eine eigene Datenbank hat). Aber wie immer gilt dann, dass man das testen muss, was ggfs sinnvoller ist, dauernd die Datenbank zu schliessen oder eben offen zu lassen.

Ich hatte zum Beispiel in der letzten Woche einen Kunden mit einem langsamen SQL Server, als ich dort ins Log schaute, waren 90% der Einträge genau die Meldungen “Starting database” und “Shutting down database” (das war nicht das einzige Problem hier), aber eben genau diese Kunden-Situation hat mich dazu bewogen, diesen Beitrag zu schreiben.

Wer jetzt – bei nächster Gelegenheit seine SQL Server überprüfen möchte, dem möchte ich den Blogpost aus dem Jahr 2013 von Rob Sewell ans Herz legen, wo er mit Powershell eine Liste von Servern überprüft und ggfs korrigiert. => SQL Express Migration Auto_Close Setting

*¹ – Thx an Greg Low

Björn Peters

SQL Server Failover Cluster on Azure

7. Januar 20213. Mai 2021 Björn Peters

ich bin heute “gezwungen” gewesen mir “schnell” ein SQL Server 2019 Failover Cluster zu erstellen um etwas zu testen, da der Kunde nur eine produktive Umgebung hat und ich erst einen funktionierenden Fahrplan für die Umsetzung benötige… also schnell eine Anleitung rausgesucht, ich wusste was grobes aber musste mich natürlich erst einmal in die Details einlesen…

Ich habe schon mehrfach gehört, dass Microsoft seit einiger Zeit auch “Shared Disks” für eben Failover Cluster anbietet, aber wie man diese nun deployed und zusätzlich noch richtig in Windows bzw dem Cluster Manager einbindet, diese Informationen fehl(t)en mir. Also Google gefragt, dieser mich auf eine Beitrag in den Microsoft Docs verwiesen und ich einfach mal drauflos gelegt.

Erstellen Sie eine FCI mit gemeinsam genutzten Azure-Festplatten

in diesem Beitrag steht unter Voraussetzungen folgendes:

Bevor Sie die in diesem Artikel aufgeführten Anweisungen ausführen, sollten Sie über Folgendes verfügen:
 - Ein Azure-Abonnement
 - Zwei oder mehr virtuelle Windows Azure-Computer. Verfügbarkeitsgruppen und Näherungsplatzierungsgruppe werden bei SSD Premium und Verfügbarkeitszonen werden   bei für Ultra Disks unterstützt. Wenn Sie eine PPG verwenden, müssen alle Knoten in derselben Gruppe vorhanden sein.
 - Ein Konto mit Berechtigungen zum Erstellen von Objekten auf virtuellen Azure-Computern und in Active Directory
 - Die neueste Version von PowerShell.

Meine Überlegungen dazu… Azure Subscription habe ich, zwei virtuelle Maschinen kann ich schnell deployen, AvailabilityGroups oder ProximityGroups habe ich auch bzw brauche ich hier nicht und eine Domäne mit entsprechendem DomainAdmin-User habe ich auch… also schnell zwei virtuelle Maschinen “SQL Server 2019 Developer auf Windows 2019” deployed und die Anleitung genau befolgt.

SharedDiskConfig.json angelegt und gemäß Doku befüllt
ResourceGroupDeployment mit SharedDiskConfig.json ausgeführt, also die SharedDisk angelegt
SharedDisk der ersten virtuellen Maschine hinzugefügt
SharedDisk der zweiten virtuellen Maschine hinzugefügt… HALT STOP, eine Fehlermeldung…

Cannot change network spine of shared disk myDataDisk while it is attached to running VM(s)

die Fehlersuche beginnt…

Da dies meine ersten Versuche mit Shared Disks sind/waren, habe ich natürlich erst einmal alles genauer untersucht bzw versucht, zumal die Shared Disk trotz Fehlermeldung an der zweiten Maschine (zumindest im Portal) zu sehen war. Restart der virtuellen Maschine ging nicht, wegen dem komischen Deployment-Zustand, Abhängen der Platte im ersten Moment auch nicht, als Owner der Platte konnte ich die erste VM ausmachen, aber wie kann ich jetzt die zweite VM zum Owner machen… alles sehr strange…

Aber es gab etwas was mich doch ein wenig irritierte… sowohl in der Anleitung als in den Powershell Snippets gibt es den Hinweis auf die Verwendung von Proximity Placement Groups. Beim Googeln nach der Fehlermeldung stieß ich dann auch einen Beitrag auf Stackoverflow, wo jemand denselben Fehler hatte und die Lösung eben in diesen Proximity Placement Gruppen gefunden hatte. Aber wieso wird in der Dokumentation nicht wirklich daraufhin gewiesen… Na gut, erst einmal selber ausprobieren, ob das dann funktioniert.

Anlegen einer PPG und Maschinen hinzufügen

Ok, also habe ich versucht den kürzesten und einfachsten Weg zu nehmen… Anlegen einer Proximity-Placement-Group und die beiden bereits vorhandenen virtuellen Maschinen dieser hinzufügen. Die Anlage der PPG über das Azure Portal war schnell und einfach (Ressourcengruppe => neue Ressource => PPG suchen und auswählen => Region und Namen eintragen und erstellen), das Hinzufügen der VMs habe ich dann ebenfalls über das Portal gemacht, dazu müssen die Maschinen erst einmal gestoppt werden und die Ressourcen deallokiert werden.

Danach habe ich vorsichtshalber noch einmal die Shared-Disk gelöscht und neu erstellt und konnte diese dann erfolgreich an beide SQL Server VMs anbinden.

$dataDiskConfig = New-AzDiskConfig -Location 'eastus2' -DiskSizeGB 1024 -AccountType Premium_LRS -CreateOption Empty -MaxSharesCount 2

New-AzDisk -ResourceGroupName 'RG-SQLServer' -DiskName 'myClusterDisk' -Disk $dataDiskConfig


$vm = Get-AzVm -ResourceGroupName 'RG-SQLServer' -Name "winsqlcl01"
$dataDisk = Get-AzDisk -ResourceGroupName 'RG-SQLServer' -DiskName "myClusterDisk"
$vm = Add-AzVMDataDisk -VM $vm -Name "myClusterDisk" -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun 2
update-AzVm -VM $vm -ResourceGroupName 'RG-SQLServer'


$vm = Get-AzVm -ResourceGroupName 'RG-SQLServer' -Name "winsqlcl02"
$dataDisk = Get-AzDisk -ResourceGroupName 'RG-SQLServer' -DiskName "myClusterDisk"
$vm = Add-AzVMDataDisk -VM $vm -Name "myClusterDisk" -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun 2
update-AzVm -VM $vm -ResourceGroupName 'RG-SQLServer'

Im Nachgang konnte ich auf beiden Servern problemlos erst das Windows Failover Cluster validieren und erstellen, um dann die SQL Server Knoten zu installieren bzw hinzuzufügen.

Ich werde also zeitnah die Beschreibung bei Microsoft anpassen (lassen). Ich hoffe dieser Blogpost hilft euch bei Zeiten weiter, damit ihr nicht so lange braucht 😉

Björn Peters

SQL Backup auf einer Azure Virtual Machine

29. April 201929. April 2019 Björn Peters

Als Database Administrator kennt man das Thema nur zu gut, wenn man sich nicht gleich zu Anfang voll umfänglich mit der Backup bzw Restore-Strategie beschäftigt, fällt es einem irgendwann vor die Füße… aber wie ist das Ganze jetzt in der Cloud, wie kann man da sein Datenbanken richtig sichern? Darum ging es in meinem Vortrag auf dem Global Azure Bootcamp 2019 in Hamburg mit dem Ziel, die neue Möglichkeit mittels Azure Backup auch direkt SQL Server Datenbanken auf einer virtuellen Maschine in Azure zu sichern.

Serverausfall – was nun?

Man stelle sich vor – in der onprem Welt – ein Server fällt aus, die Datenbanken nicht mehr erreichbar… PANIK (zumindest im ersten Moment)… die Fragen, die man sich dann im ersten Moment stellt:

Haben wir eine Sicherung?
Wann ist die letzte Sicherung erfolgreich gelaufen?
Wie groß ist mein Datenverlust?
Wie komme ich an die Daten?
Wie lange dauert es, bis das richtige Backup für den Restore gefunden wurde?
Wie lange dauert der Restore?
Klappt der Restore auf Anhieb?
Können dann alle wieder auf die Daten zugreifen?

Gehen wir erst einmal von dem Fall aus, dass der Server neu aufgesetzt wird und die Datenbanken dann aus einer Sicherung wieder hergestellt werden müssen. Nun sucht man (vielleicht) über die GUI der Backup-Software nach einer Filesicherung, dem Tape oder einer Datenbank-Sicherung. Spätestens hier wird es interessant 😉

Wie wurde der Datenbank-Server überhaupt gesichert, in welchem Rhythmus, wieviele Files müssen zurück gespielt werden und so weiter… Im schlimmsten Fall gibt es nur eine tägliche Vollsicherung (Full-Backup) auf die lokale Platte mit nur wöchentlicher Filesystemsicherung… 😮
Backup-Lösungen und -Strategien sind aber nicht das Thema dieses Beitrages, denn hier geht es um die Cloud.

Downtime Minimierung durch rechtzeitiges integrieren in die Solution

Azure SQL Databases und das Backup

In der Cloud ist vieles einfacher (oder zumindest anders), denn wie auch on-prem sollte man sich zumindest Gedanken über die Backup-Strategie machen. Aber zumindest hat sich Microsoft sehr viele Gedanken zu diesem Thema für uns gemacht, so dass in vielen Datenbank-Services wie zum Beispiel der Azure SQL Database das Backup schon automatisch inkludiert ist.

Also alle Azure SQL Database Services (SingleDB, Elastic Pool und Managed Instance) haben bereits ein Backup inkludiert, so dass man sich hier nicht wirklich mehr Gedanken zu einer Backup-Strategie oder “Welche Software wollen wir einsetzen?” machen muss. Beispielsweise Azure SQL Single-Database hat in den unterschiedlichen Performance-Klassen (Basic, Standard, Premium) unterschiedliche Aufbewahrungszeiten von 7-35 Tagen… was aber wenn man das Backup, aus welchen Gründen auch immer, länger aufbewahren möchte/muss? Dann bleibt einem – für diesen Fall – nur das Hinzufügen eines sogenannten “Log-Time-Retention” Backups, welches das Backup(-File) zusätzlich auf einem weiteren Storage-Account ablegt und erst nach X Tagen/Wochen/Monaten/Jahren löscht, was einem selber überlassen wird über eine entsprechende Policy zu definieren.

Selbst für den Fall, dass mal ein komplettes Microsoft Rechenzentrum oder sogar eine ganze Region ausfallen sollte, hat Microsoft vorgesorgt und verschiebt alle Backups über Geo-Replication auch in andere Regionen, so dass im Fall der Fälle immer ein entsprechendes Backup für einen Point-in-Time-Restore innerhalb der Retention-Period vorhanden ist.

Automatisierte Backups – da war doch schon was

Ja, automatische Sicherungen (Automated Backup) konnte der SQL Server schon seit der Version 2014, wenn man ihn entsprechend konfiguriert hatte, dann wurde alle Datenbanken bereits “damals” auf einen Azure Storage Account gesichert. Auch mit der Version 2016 und 2017 blieb diese Funktion erhalten, wurde aber angepasst bzw optimiert (Automated Backup v2). Alternativ könnte man sich auch ein Backup-to-URL mittels Ola Hallengren Skripten vorstellen, aber das hängt dann wieder mit der gesamten Backup-Strategie zusammen und muss entsprechend geplant werden.

Enable SQL Server Managed Backup to Microsoft Azure

Gemeinsame Nutzung von Azure Backup ?

Viele Kunden haben in Azure so oder so eine Azure Backup Vault oder den Azure Backup Service laufen, so dass sich diese Kunden gefragt haben, warum sie damit nur Virtuelle Maschinen als “Ganzes” sichern können, aber nicht auch ihre SQL Server. Somit wäre eigentlich eine zentrale Lösung für viele Backups in Cloud gefunden. Man könne auch von dieser zentralen Stelle im Portal aus, alle Backups administrieren und überwachen, bräuchte kein weiteres Tool geschweige denn eine neue Backup-Infrastruktur.

Microsoft hat auf die Wünsche und Bitten seiner Kunden gehört und das Azure Backup entsprechend erweitert, so dass man seit Mitte März 2019 auch endlich reine SQL Server Datenbank-Backups damit ziehen kann.

https://azure.microsoft.com/de-de/blog/azure-backup-for-sql-server-in-azure-virtual-machines-now-generally-available/

Jetzt kann man also die Azure Backup Extension sowohl auf fertige SQL Server Marketplace VM-Images ausrollen, als auch auf selbst erstellte SQL Server, um diese dann als native SQL Server Backups gegen Azure Backup zu sichern. Derzeit gibt es folgende Eckpunkte, die für diesen Service sprechen:

Zentrale Verwaltung und Überwachung
Schutz für verschlüsselte Datenbanken
Automatische Erkennung von (neuen) Datenbanken
RPO-Wert (Recovery Point Objective) von 15 Minuten
Point-in-Time-Wiederherstellungen
Langfristige Aufbewahrung
Kosteneffektiv

Einrichten eines SQL Server Backups über das Portal mit Azure Backup in meiner Demo-Umgebung

Wenn man nun also das native SQL Server Backup über die neue Extension ausgerollt hat, dann kann man während der Konfiguration im Portal entweder den ganzen Server (Instanz) oder einzelne Datenbanken, ebenso “Autoprotection” auswählen. Und “zusehen” wie nach erfolgreichem Deployment die ersten Sicherungen durchgeführt werden. Das Ergebnis sowie Alarme können dann sehr schön und zentral über das Azure Backup Dashboard im Portal überwacht werden. Zusätzlich dazu bietet Microsoft eine PowerBi Application mit der man auf einen (dann einzurichtenden StorageAccount) zu aktivieren, um noch mehr Details zu seinen Sicherungen zu erhalten.

Ein Restore der Datenbanken ist mit wenigen Klicks über das Portal zu realisieren, hierbei stehen dann auch weitere Optionen zur Verfügung, wie man sie aus dem normalen SQL-Restore kennt (z.B. File-Relocation, Overwrite oder Database-Rename).

Fazit zu Azure Backup für SQL Server VMs

Ich persönlich finde diese neue Extension super, wenn man seine SQL Server in einer Azure VM nativ sichern möchte/muss und eine (!!!) zentrale Anlaufstelle für Backups in Azure mit Monitoring, Alerting und Config-Management haben möchte!!!

Björn Peters

Festplatten für die TempDB

Konfiguration der TempDB

TempDB diverse Contention Probleme

Zusammenfassung

Related posts:

Warum SQL-aus-HH ???

Related posts:

Was ist dieses AutoClose

Worst-case: Performance-Impact

Related posts:

Erstellen Sie eine FCI mit gemeinsam genutzten Azure-Festplatten

die Fehlersuche beginnt…

Anlegen einer PPG und Maschinen hinzufügen

Related posts:

Serverausfall – was nun?

Azure SQL Databases und das Backup

Automatisierte Backups – da war doch schon was

Gemeinsame Nutzung von Azure Backup ?

Fazit zu Azure Backup für SQL Server VMs

Related posts: