Azure SQL Database – Allgemeines – Refresh Teil 1

Ich betrachte die weiteren Beiträge als einen persönlichen Refresh meiner Kenntnisse über die Azure SQL Database und all ihre zahlreichen Features. Es war nach längerer Zeit mal wieder notwendig sich im Detail damit zu beschäftigen und für mich und meine eigenen Erfahrungen mit dem Lernen zeigen, dass “aufschreiben” sehr gut hilft, sich Inhalte und wichtige Punkte zu verinnerlichen. Also werde ich einfach die nächsten (wenn auch vielleicht kürzeren) Blogpost dafür verwenden, euch an meinem “Refresh” teil haben zu lassen. Dies ist in sofern auch relevant, als dass Microsoft Produktgruppe im Laufe der vergangenen Monate nicht untätig war und zahlreiche neue Features präsentiert hat bzw Optimierungen an den bereits vorhandenen vorgenommen hat. (Danke dafür 😉 )

Grundlegendes zu Azure SQL Database

Es geht also im Grunde erst einmal um den Azure Service, der uns eine SQL Server Datenbank bereitstellt, hierzu gibt es zahlreiche Möglichkeiten im Deployment bzw in der Ausprägung. Beginnend natürlich mit der Auswahl des benötigten Service (aka “Was brauche ich bzw meine Applikation?”)… beginnend mit der Frage, wieviele Datenbanken benötigt meine (neue oder vorhandene) Applikation wirklich? Sollte es sich um eine eigene Neu-Entwicklung handelt, hat man ggfs noch Einfluss auf gewisse Funktionalitäten, bei bereits exisitierenden Eigenentwicklungen oder Kaufprodukten ist dies schwerlich möglich. Beispiel VMWare… hier werden in der Regel mindestens 3 Datenbanken benötigt, beim Sharepoint noch viel mehr, bei einem CRM-System vielleicht nur eine.

Aber zum Verständnis, es geht hierbei nicht darum, dass z.B. mein Mandantenfähiges CRM pro Mandanten eine eigene Datenbank anlegt sondern darum, dass pro Mandant nur eine (!) Datenbank benötigt wird, also keine “Cross-Database” Abfragen benutzt werden.

Sollte man hier also eine Aussage treffen können, ist man einen Schritt weiter und kann zumindest einmal eine Entscheidung treffen, dass Azure SQL Database das richtige Produkt ist, nun kommt der vielleicht schwierigste Punkt, der sich aber (unter Umständen) nachträglich gut anpassen lässt.

Aber die Überschrift heißt ja, Grundlegendes zu Azure SQL Database… Mircosoft stellt uns in Azure einen Platform-as-a-Service Datenbank Dienst zur Verfügung, der auf dem SQL Server basiert, hier kommt immer die letzte stabile Version zum Einsatz, wir als Administratoren müssen uns hier um wenig Gedanken machen, da Microsoft uns schon sehr viel abnimmt, wie zum Beispiel Upgrades, Backup oder Monitoring, zu den einzelnen Punkten komme ich später noch einmal. Ebenso in Sachen “Hochverfügbarkeit” müssen wir uns keine Gedanken machen, alle Azure SQL Database Services (je nach SKU und Deployment) kommen auf mindestens 99,99% Verfügbarkeit und lassen sich so auch für kritische und performante Business-Applikation verwenden.

Wie wir es vom SQL Server kennen, können auch in der Cloudrelationale als auch nicht relationale Datenstrukturen verwendet werden, genauso wie In-Memory-Technolgien.

Auswahl-Möglichkeiten für alle Anforderungen

Der Azure Service Azure SQL Database lässt sich in unterschiedlichen Ausprägungen und Leistungsklassen “mieten”, so dass man nahezu jeder Anforderung gerecht werden kann.

  • Einzel- oder Pool-Datenbank
  • Hyperscale
  • Serverless

Jedes einzelne Deployment lässt sich noch unterteilen in die verschiedene Performanceklassen, welche ich später auch noch näher erläutern werde. Hier spielen Aspekte wie CPU, RAM, Datenbank-Größe und Nutzungsdauer eine Rolle, um eine optimale Entscheidung treffen zu können.

Azure SQL Database - Darstellung des Azure Portals - Auswahl der unterschiedlichen Services

Deployment-Unterschiede einer Azure SQL Database

Sollte man also zu der Entscheidung kommen, dass man nur eine Datenbank benötigt, dann ist die Azure SQL Single-DB (oder Singleton) das Optimale. Hierbei stellt uns Azure eine einzelnen Datenbank auf einer gesharten Umgebung zur Verfügung, die aber so abgeschottet bzw isoliert läuft, dass man sich keine Gedanken machen muss, dass hier etwas passiert (also keine Fremdzugriffe von ausserhalb ihrer eigenen Datenbank). Hierbei erhält jede Azure Single DB eigene Compute-Ressourcen und kann diese dann entsprechend exklusiv nutzen.

Hat man zum Beispiel mehrere kleine Datenbanken, die zu unterschiedlichen Zeiten unterschiedliche Auslastungen haben, so kann man sich genau für eine Azure SQL Elastic Pool entscheiden, hierbei werden mehrere Einzel-Datenbanken in einen Pool konfiguriert, die sich dann – je nach Nutzungsverhalten und Workload – die geteilten Compute-Ressourcen teilen können.

Je nach Anforderungen der Applikation oder des Businesses können sowohl Einzel- als auch Elastic-Pool Datenbanken dynamisch skaliert werden, um so die Leistung der Datenbanken an die zu verarbeitende Workload anzupassen.

Microsoft unterscheidet in diesen Performanceklassen in Serverless oder Server-based, wobei Server-based auch noch einmal unterteilt wird in “General Purpose / Universell” und “Business Critical / Unternehmens-kritisch” und darin auch noch weiter in die Möglichkeiten die Compute-Ressourcen auszuwählen, in vCore- oder DTU-basiert. Bei den Elastic-Pools gibt es aktuell kein Serverless-Deployment, aber die Unterscheidungen in GeneralPurpose und BusinessCritical sowie die Einteilung in DTU (Data Transaction Units) und vCores.

Azure SQL Database - Darstellung des Azure Portals - Auswahl der Performance-Klassen von Elastic Pools

Zu Verfügbarkeiten, Monitoring und Backup von Azure SQL Datenbanken komme ich in einem der weiteren Blogbeiträge.

Hochverfügbarkeit beim SQL Server – DBCC 2021 – Teil 1

Jeder meiner Kunden hat sich irgendwann mal die Frage gestellt oder zumindest sollte er sich diese Frage stellen, “brauche ich für meine SQL Server oder einen meiner SQL Server eine gewisse Hochverfügbarkeit”. Leider enden diese Überlegungen immer bei der Frage nach dem Budget… natürlich kosten solche HA-Lösungen mehr Geld, je nach Auswahl der Lösung und der Ausstattung der Umgebung müssen entsprechende Lizenzen zur Verfügung gestellt werden. Aber wenn man die im “worst-case” anfallenden Kosten während oder durch einen Ausfall dagegen rechnet, sollte man ganz klar zur Einsicht kommen, dass diese Kosten vertretbar sind.

Ich durfte heute auf der Data Blaster Community Conference 2021 einen Vortrag dazu halten (Vielen Dank liebe SQLPASS Deutschland), hier kommt eine kleine Zusammenfassung aus meinem Vortrag.

Ich habe direkt am Anfang dargestellt, wie hoch solche Kosten sein können, hierzu habe ich mit Hilfe eines Online-Rechners von Percona eine beispielhafte Rechnung aufgemacht. Der SQL Server fällt für 1-2 Stunden aus, 5 Mitarbeiter sind an dem Restore beschöftigt, jeder von ihnen verdient 100.000 pro Jahr, 100 weitere Mitarbeiter können nicht richtig arbeiten, diese verdienen durchschnittlich 50.000 pro Jahr. Im folgenden Screenshot könnt ihr die Zahlen lesen, die unter Umständen während des Ausfalls, bei der Behebung und deren Nachwirkungen entstehen können.

Warum SQLServer Hochverfuegbarkeit sich rechnet - Percona Calculator

Bei Gesamtkosten von rund 8.000.000 Euro für einen Ausfall eines SQL Servers von rund 2 Stunden, würde ich mir schon vorher überlegen, ob ich z.B. 250.000 Euro im Rahmen der Installation mehr ausgebe, um einen zweiten Server hinzustellen und mit den jeweiligen Lizenzen auszustatten. Aber wie können solche Hochverfügbarkeiten im SQL Server Umfeld aussehen, dazu komme ich in den nächsten Abschnitten, aber erst einmal sollten wir die Überschriften klären… 😉

Hochverfügbarkeit vs Desaster Recovery

Die Definition von Hochverfügbarkeit auf wikipedia.de lautet wie folgt :

Hochverfügbarkeit (englisch high availabilityHA) bezeichnet die Fähigkeit eines Systems, trotz Ausfalls einer seiner Komponenten mit einer hohen Wahrscheinlichkeit (oft 99,99 % oder besser) den Betrieb zu gewährleisten. In Abgrenzung zur Fehlertoleranz kann es bei dem Betrieb im Fehlerfall zu einer Unterbrechung kommen.

https://de.wikipedia.org/wiki/Hochverf%C3%BCgbarkeit

Im Vergleich dazu die Definition von Desaster Recovery

Der englische Begriff Disaster Recovery (im Deutschen auch Katastrophenwiederherstellung oder Notfallwiederherstellung genannt) bezeichnet Maßnahmen, die nach einem Ausfall von Komponenten in der Informationstechnik eingeleitet werden. Dazu zählt sowohl die Datenwiederherstellung als auch das Ersetzen nicht mehr benutzbarer InfrastrukturHardware und Organisation. Umfassender als Disaster Recovery ist der Begriff Business Continuity, der nicht die Wiederherstellung der IT-Dienste, sondern unterbrechungsfreie Geschäftsabläufe in den Vordergrund stellt.

https://de.wikipedia.org/wiki/Disaster_Recovery

Bei der Hochverfügbarkeit geht es eben mehr darum, die eintretende Zeit des Ausfalls, also die Downtime möglichst gering zu halten, so dass alle angeschlossenen Systeme möglichst ohne Datenverlust und manuellen Eingriff schnellstmöglich weiterlaufen. Hierzu sollte man sich vor der Installation natürlich Gedanken zur Prozessgestaltung, den zu erreichenden Zielen und der Notwendigkeit zu machen.

  • Was braucht das Business?
  • Was kostet es das Business wenn sie nicht mehr arbeiten können?
  • Gibt es ggfs einen Kompromiss zwischen Technik und Business? Müssen es wirklich die minimalsten Ausfallzeiten (< 10 Sekunden) sein oder reichen vielleicht auch maximale Ausfallzeiten von kleiner einer Minute?
  • Was kann die Technik überhaupt abbilden? Wissen, Prozesse u.ä.
  • Welceh rechtlichen Rahmen müssen ggfs eingehalten werden?

Und erst wenn man diese Fragen vorher geklärt hat, kann man sich Gedanken über die eigentliche Hochverfügbarkeitslösung machen und wie diese implementiert werden kann/soll.

Das AlwaysOn Failover-Cluster (FCI)

Hochverfuegbarkeit - SQLServer - AlwaysOn Failover Cluster

Kommen wir zu einer der möglichen Lösungen zur Realisierung der Hochverfügbarkeit des SQL Servers innerhalb des eigenen Rechenzentrums, das Windows Failover Cluster (im Grunde identisch zu einem Linux Failover Cluster, hier sollte man sich an die Angaben/Dokumentation der jeweiligen Distribution und eingesetzten Cluster-Software halten).

Initial erstellt man aus zwei Windows Servern mit dem zusätzlich installierten Failover-Cluster Feature ein Windows Failover Cluster, grob gesagt, man verbindet beide Server logisch (und im AD) miteinander. Beide kennen sich und wissen nun, dass sie zusammengehören und tauschen mehrere entsprechenden Health-Status Informationen untereinander aus. Dieses Windows Failover Cluster erhält eine eigene IP und einen eigenen DNS Namen, sowie ein Cluster-Named-Object im AD, dieses CNO “steuert” später das Cluster im AD.

Zu den notwendigen Storage-Requirements kann ich hier wenig sagen, da dies von den jeweiligen Umgebungen abhängt… SAN, NAS, NFS, HCI oder ähnliches, auf jeden Fall muss es sich um einen Storage handeln, der in der Lage ist beiden Servern Zugriff zu gewähren. Microsoft schreibt dazu folgendes:

Storage

Im Gegensatz zur Verfügbarkeitsgruppe muss eine FCI freigegebenen Speicher zwischen allen Knoten der FCI für Datenbank und Protokolle verwenden. Der freigegebene Speicher kann die Form von WSFC-Clusterdatenträgern, direkten Speicherplätzen (Storage Spaces Direct, S2D), Datenträgern auf einem SAN oder Dateifreigaben auf einem SMB aufweisen. Auf diese Weise verfügen alle Knoten in der FCI immer dann über die gleiche Sicht der Instanzdaten, wenn ein Failover auftritt. Dies bedeutet jedoch, dass der freigegebene Speicher das Potenzial hat, die einzelne Fehlerquelle zu sein. Die FCI hängt zudem von der zugrunde liegenden Speicherlösung ab, um Datenschutz sicherzustellen.

https://docs.microsoft.com/de-de/sql/sql-server/failover-clusters/windows/always-on-failover-cluster-instances-sql-server?view=sql-server-ver15&WT.mc_id=DP-MVP-5002576#Recommendations

Nun kann man mit der eigentlichen Installation des SQL Servers beginnen, auf dem Node 1 wird die Basis-Installation für das SQL Server Failover Cluster geschaffen “Erstellung eines Failover-Clusters”, während auf dem Node 2 “nur” ein Knoten zu einem bestehenden SQL Server Cluster hinzugefügt wird.

Je nach Ausgestaltung dieses Cluster – nur eine Instanz oder mehrere Instanzen – müssen SQL Server Lizenzen beschafft werden. Hierbei kann man zwischen zwei Betriebsmodis unterscheiden, aktiv/passiv oder aktiv/aktiv. Bei aktiv/passiv dürfen die SQL Server Instanzen immer nur auf einem Knoten des Clusters laufen, im Fehlerfall für einen begrenzten Zeitraum auch auf beiden Knoten. Bei aaktiv/aktiv können beide Knoten gleichermaßen und zeitlich unbegrenzt voll genutzt werden, was gerade bei mehreren Instanzen unter Umständen Sinn machen kann, da man so eine gewisse Last-Aufteilung vornehmen kann.

Sollte nun ein Knoten im Cluster ausfallen, so kann der zweite Knoten vereinfacht gesagt nicht mehr der anderen Seite kommunizieren und versucht schnellstmöglich die ausgefallenen Services auf seine Seite zu holen und dort zu starten.

Ein hybrides Szenario ist hierbei leider nicht möglich, da es keine Möglichkeit der gesharten Ressourcen zwischen on-premise und Cloud gibt. Aber man kann alternativ auch ein Failover-Cluster in der Azure Cloud aufbauen. Hierzu benötigt man eine Proximity Placement Group, entsprechende Managed Disks mit aktiviertem “Shared Storage” Feature und die beschriebenen zwei virtuellen Maschinen, die eigentliche Installation und Betrieb ist im Grunde identisch.

Hochverfügbarkeit Azure SQLServer Failover Cluster - DBCC2021

Mehr zu Hochverfügbarkeiten des SQL Servers kommt demnächst in einem zweiten Beitrag.

Azure SQL VM – keine Möglichkeit den Plattenplatz zu konfigurieren

Ein Kunde hatte mich die letzten Tage gebeten, ihn bei der Optimierung eines SQL Servers auf einer Azure VM zu unterstützen. Der Kunde hatte immer mal wieder leichte Performance Probleme mit dem SQL Server, der Applikation Hersteller bzw Betreuer wollte oder konnte nicht mehr sagen bzw helfen. Von dort erhielten der Kunde erst einmal nur die Aussage, man empfehle für die DATA-Platten des SQL Servers eine Latenz von 5ms… ok, in Azure lässt sich dies offiziell nur mit ULTRA Disks erreichen. Ich möchte hier in diesem Beitrag nicht unbedingt auf das Wie eingehen, sondern nur auf einen Fehler, der mir im Rahmen der Analysen aufgefallen ist.

Erst einmal zur Erläuterung, ich habe mit dem Kunden gesprochen und ihm vorgerechnet was es kostet den Server mit 2 TB Ultra-Disks auszustatten und ob es nicht vielleicht sinnvoller und zielführender ist, den SQL Server auf “Herz und Nieren” zu prüfen, zu optimieren (auch die Applikation bzw deren T-SQL) und im letzten Schritt notfalls doch auf Ultra-Disks zu gehen.

Der Kunde war einverstanden und gemeinsam haben wir den SQL Server einem Review unterzogen, auch wenn die Marketplace-Images von Microsoft (Danke an das Produktteam!) schon sehr gut konfiguriert sind, lässt sich doch noch das ein oder andere anpassen.

Azure SQL VM und die Data-Disks

Wenn man den Empfehlungen zu Azure SQL in einer virtuellen Maschine folgt, dann kann man dort in den Empfehlungen lesen:

Stripe multiple Azure data disks using Storage Spaces to increase I/O bandwidth up to the target virtual machine’s IOPS and throughput limits.

https://docs.microsoft.com/en-us/azure/azure-sql/virtual-machines/windows/performance-guidelines-best-practices-storage

In einem ersten Anlauf haben wir die 1TB Platte durch mehrere kleine Platten ersetzt, um den maximalen Throughput von 200MB auf 625MB zu erhöhen. Das hat soweit auch ohne Downtime funktioniert, der Kunde ist bisher sehr glücklich. Aber im Zuge dieser Arbeiten bin ich eben auch auf eine Meldung im Azure Portal an dieser virtuellen Maschine bzw der SQL Server Konfigurationsübersicht gestossen, mit der ich im ersten Moment nichts anfangen konnte und Google auch keinerlei Hilfe brachte.

Im Azure Portal gibt es die Möglichkeit für alle SQL Server innerhalb einer Azure VM entsprechend mehrere Extensions auszurollen, die den Administrator dabei unterstützen sollen, die VM bzw den SQL Server über Powershell, Azure CLI oder das Portal zu administrieren und deren Daten in Logs und Metrics darzustellen. Hierzu nutzt Microsoft unter anderem den “SQL Server IaaS Extension Query Service” oder “SQL Server IaaS Agent extension”, beide sammeln Daten aus der virtuellen Maschine und dem SQL Server und stellen diese nutzerfreundlich im Portal dar. Leider war das bei diesem Kunden und dieser VM nicht zu 100% verfügbar, wie der folgende Screenshot zeigt.

Azure SQL VM im Portal leider ohne Anzeige der verfügbaren und belegten Plattenkapazitäten

Auch in der weiteren Übersicht “Configure” waren keine Daten zum Storage ermittelbar, obwohl alle Extensions auf dem Server ausgerollt waren und auch nach einem/mehreren Reboots keinerlei Daten anzeigten. Also bin ich auf die Suche nach der Ursache gegangen…

Extension-Log und fn_trace_gettable

Wie man der Microsoft-Dokumentation entnehmen kann, gibt es unterschiedliche Modis, für unterschiedliche Anforderungen und natürlich kann man hier auch entnehmen, dass es ein lokales Errorlog gibt, welches man unter Umständen zur Fehlersuche nutzen kann. Bei diesem Errorlog handelt es sich um ein XE-File und ein Tracefile, beide nicht mit dem Notepad sondern nur SQL Server Management Studio lesbar… also blieb nichts anderes, als kurzerhand mit einer T-SQL Systemfunktion auf das Tracefile zuzugreifen, um festzustellen, dass der Systemuser anscheinend keinerlei oder zu wenige Berechtigungen hat. Normalerweise befindet sich die Extension direkt auf dem C-Laufwerk im Verzeichnis C:\SQLIaaSExtension, so dass man diesen Pfad in der SQL Abfrage entsprechend nutzen muss.

SELECT * FROM fn_trace_gettable('C:\SQLIaaSExtension\Log\log.trc', default);  
GO  

Durch die Ausführung dieses T-SQL Statements zum Auslesen des Extension-Logfiles, erhielt ich unter anderem die folgende Zeile :

alter server role [sysadmin] add member [NT Service\SQLIaaSExtensionQuery]

Bei der Suche nach dem User musste ich dann feststellen, dass der Kunde diesen User – warum auch immer – gelöscht hat (später stellte ich fest, dass dies anscheinend nicht “per accident” passiert ist, sondern bewusst, denn auf anderen SQL Servern in Azure fehlt der User ebenfalls)

USE [master]
GO

/****** Object:  Login [NT SERVICE\SqlIaaSExtensionQuery]    Script Date: 5/10/2021 3:35:08 PM ******/
DROP LOGIN [NT SERVICE\SqlIaaSExtensionQuery]
GO

/****** Object:  Login [NT SERVICE\SqlIaaSExtensionQuery]    Script Date: 5/10/2021 3:35:08 PM ******/
CREATE LOGIN [NT SERVICE\SqlIaaSExtensionQuery] FROM WINDOWS WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english]
GO

ALTER SERVER ROLE [sysadmin] ADD MEMBER [NT SERVICE\SqlIaaSExtensionQuery]
GO

Testweise habe ich diesen User erneut angelegt, berechtigt und im Azure Portal überprüft, ob es eine Veränderung in den Ansichten gibt… Ja, die SQL Server IaaS Agent Extension kann nun wieder auf den SQL Server zugreifen und die notwendigen oder relevanten Daten auslesen.

Azure SQL VM im Portal mit Anzeige der verfügbaren und belegten Plattenkapazitäten

Azure SQL – Change your Skills – DataSaturday #6 Malta

Gestern durfte ich meinen Vortrag im Rahmen des DataSaturday #6 auf Malta halten, dabei ging es um die Veränderungen im Leben eines DBAs, wenn er sich damit konfrontiert sieht, dass seine SQL Server und/oder Datenbanken in die Microsoft Cloud Azure migriert werden sollen. Ich wollte mit diesem Vortrag die Ängste minimieren und aufzeigen, dass es sich bei Azure SQL eben auch “nur” um einen SQL Server bzw einen SQL Datenbank handelt.

Abweichend von allen anderen Veranstaltungen hatte sich Dennes (und sein Team) etwas neues im Ablauf einfallen lassen, die Session hatte keine 60 Minuten sondern 90 Minuten. Die ersten 15 Minuten wurden als Interview oder Einleitung genutzt, der Host stellte den nächsten Sprecher vor, dazu hatte man ein kleines Video produziert und individuelle Fragen zum jeweiligen Lebenslauf vorbereitet. Dann kam der eigentliche Vortrag über volle 60 Minuten, gefolgt von weiteren 15 Minuten für Fragen und Antworten der Teilnehmer oder der Host konnte selber entsprechende Fragen stellen. Alles in allem eine gelungene Lösung, die den Talk eher wie ein Gespräch leitete und allen ein wenig “Druck” nahm und man sich (hoffentlich auch als Teilnehmer) mehr dazugehörig fühlte.

Mein Host war Deepthi Goguri, es hat mir viel Spaß bereitet diese Session gemeinsam mit Ihr zu halten. Auch wenn dies nicht mein erster Vortrag auf Englisch war, so bin ich doch immer noch ein wenig nervöser… finde ich die richtigen Worte im richtigen Moment, spreche ich alles richtig aus… Durch die ruhige und freundliche Art von Deepthi wurde auch ich ruhiger und konnte mich ein wenig besser auf die Session vorbereiten. Half zwar nicht darüber hinweg, dass ich wieder einmal mehr erzählen und zeigen wollte, als ich Zeit zur Verfügung hatte, daran muss ich dringend arbeiten! Vor zwei Jahren hatte ich mich mit Rob Sewell unterhalten, dass ich meine Komfortzone dringend verlassen möchte => nicht nur Vorträge auf Deutsch zu halten, sondern auch einmal mit Englisch starten wolle und ob er mich bei meinem englischen Start – als Mentor sozusagen – unterstützen könne. Und dann kam Corona und alles kam anders… ich bin einfach mal gesprungen und habe es gewagt… womit wieder wir beim Thema wären 😉

It is just a SQLServer - dont be afraid of moving you databases into Azure

Einfach mal trauen und ausprobieren

Deepthi fragte mich gestern, was ich den Teilnehmern denn empfehlen würde, wenn der Auftraggeber oder Arbeitgeber mit der Migration in die Cloud starten wolle. Hier kann ich allen Interessierten nur empfehlen, keine Angst zu haben, nur weil der SQL Server nicht mehr im eigenen Rechenzentrum steht, sondern jetzt in einem Rechenzentrum von Microsoft, heißt dies nicht, dass Microsoft all die Arbeit übernimmt und man – als Datenbank-Administrator – nichts mehr zu tun hat… ok, man muss etwas neues lernen und etwas anders denken, aber es ist immer noch ein SQL Server mit seinen Datenbanken!
Die ersten Schritte könnten die folgenden sein:

  • einen Azure Free Account anlegen
  • einfach mal bspw. eine kostenfreie Linux VM deployen und ausprobieren, wie man dort einen SQL Server installiert
  • oder eine Azure SQL Database, um zu sehen welche Schritte man hier gehen muss, um dies zu erreichen
  • und natürlich all die großartigen Ressourcen von Microsoft Learn – Learning Paths and Modules mit vielen Inhalten und Übungen – erarbeiten
    Azure Fundamentals – AZ-900
    Azure Data Fundamentals – DP-900
  • wenn man dann Fragen zu den einzelnen Optionen hat, dann kann man auch die sehr nützliche Dokumentation lesen, die auch mir, sehr oft hilft gewisse Themen besser zu verstehen.

zahlreiche Lern-Unterstützung zu Azure SQL verfügbar

Microsoft – hauptsächlich in Form von Anna Hoffman und Bob Ward – stellt auch sehr viele interaktive Lernmaterialien zur Verfügung, die man sich in Form von Workshops, Labs oder Youtube Videos erarbeiten kann! Es gibt Material für mehrere Wochen durchgängiges Lernen rund um den SQL Server und/oder Azure SQL… egal ob Azure SQL Database oder die Managed Instance oder auch als SQL Server VM in Azure. Hier heißt es einfach mal starten und ausprobieren, keine Scheu… es ist keine Magie, sondern eigentlich recht einfach, da man sich alles selber zusammenstellen kann, wie man es benötigt 😉

Microsoft Learn: Azure SQL fundamentals learning path
aka.ms/azuresqlfundamentals
Select the Azure SQL Workshop
aka.ms/sqlworkshops
How to choose tool
aka.ms/chooseazuresql
Azure SQL documentation
aka.ms/azuresqldocs
More videos from our team
aka.ms/dataexposed

Change your Skills - Learning - Ressourcen-Overview

Hier geht es zu meinen Slides aus diesem Vortrag:
Azure SQL – Change your skills to become a cloud DBA

und wer jetzt noch etwas zu Azure SQL Database lesen möchte, der kann dies natürlich entweder in meinem Blog hier tun oder in dem relativ neuen Post zu Azure SQL von Deepthi 😉

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

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_CLOSEWenn 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