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

SQL Server Patch – Server startet nicht mehr

Manchmal treffen gewisse Themen zeitnah zusammen, in diesem Fall waren es mehrere Mails aus der Data-Platform-MVP-Distributionlist, mehreren Kunden-Meldungen und dazu noch passsende Beiträge in anderen Blogs, daher möchte ich dazu einen deutschen Beitrag leisten. 😉
Es geht um einen Fehler der anscheinend schon seit mehreren Jahren in allen SQL Server Versionen und Editionen in unterschiedlichen Konstellationen auftritt, die meisten DBAs werden sehr wahrscheinlich nie mit diesem Problem zusammentreffen, wahrscheinlich auch nie vorher an dieses Problem denken. Falls doch, kommt hier eine Erläuterung…

Wann tritt der Fehler auf? – Ausgangslage

Wer kennt es nicht? Man stößt das Rollout von Patchen auf seine Windows Server (inkl SQL Server Cumulative Updates) an und wartet auf die Fertigmeldung…. nach einiger Zeit meldet sich die WSUS Konsole und meldet alle Patches als “erfolgreich” ausgerollt… man meldet an die beteiligten Abteilungen, dass man den Rollout-Vorgang erfolgriech abgeschlossen hat… dann kommt aber die Fertigung und meldet, dass die Produktion nicht wieder anläuft…

Oder ein Kunde meldet sich mit den Worten:

Übrigens spielen wir gerade ein Backup ein, weil nach dem Windows Update (inkl. SQL Server Updates) der Service für den Server (und ein paar andere Services) nicht mehr startet…

Jetzt geht die Fehlersuche los und irgendwann stellt man fest, dass der SQL Server zwar das Patch erhalten hat, danach auch sauber gebootet hat aber der SQL Server Datenbank-Dienst nicht wieder sauber gestartet wurde… noch weiter in das Trouble-Shooting einsteigen und dann im Errorlog des SQL Servers entsprechende Meldungen finden:

Error: 2714, Severity: 16, State: 6.
There is already an object named 'TargetServersRole' in the database.
Error: 2759, Severity: 16, State: 0.
CREATE SCHEMA failed due to previous errors.
Error: 912, Severity: 21, State: 2.
Script level upgrade for database 'master' failed because upgrade step 'msdb110_upgrade.sql' encountered error 2714, state 6, severity 25. This is a serious error condition which might interfere with regular operation and the database will be taken offline. If the error happened during upgrade of the 'master' database, it will prevent the entire SQL Server instance from starting. Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.
Error: 2714, Severity: 16, State: 25.
There is already an object named 'DatabaseMailUserRole' in the database.
Error: 2759, Severity: 16, State: 0.
CREATE SCHEMA failed due to previous errors.
Error: 912, Severity: 21, State: 2.
Script level upgrade for database ‘master’ failed because upgrade step ‘sqlagent100_msdb_upgrade.sql’ encountered error 2714, state 6, severity 25. 
This is a serious error condition which might interfere with regular operation and the database will be taken offline. 
If the error happened during upgrade of the ‘master’ database, it will prevent the entire SQL Server instance from starting. 
Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.

Es sollte allen DBAs bekannt sein, dass der SQL Server im Rahmen eines Patches auch Änderungen an den Datenbank-Strukturen der System-Datenbanken durchführt, diese Änderungen werden in der Regel mithilfe von T-SQL-Statements über ein SQL-File mitgeführt. Diese Skripte sollten eigentlich in der Regel auf ALLEN (!) SQL-Servern bei allen Kunden in allen Ausprägungen funktioneren, genau hier ist das Problem… es wird immer ein (oder zwei) Systeme gehen, die vom “Standard” abweichen… sei es “per accident” oder aufgrund einer administrativen Anpassung.

Bezogen auf “TargetServersRole” – hier reicht es den SQL Dienst mit dem Traceflag 902 manuell zu starten und das Schema in der “msdb => Security => Schema” zu löschen.

Bei “DatabaseMailUserRole” wird es etwas schwieriger, hier muss ein wenig mehr T-SQL Code ausgeführt werden, denn über das SQL Server Management Studio findet man diese Rolle nicht, da es sich hier um einen Oprhaned User handelt. Pinal Dave hat hierzu eine gute Erläuterung mit Lösung geschrieben:

USE [msdb]
GO
CREATE ROLE [DatabaseMailUserRole] AUTHORIZATION [dbo]
GO
USE [msdb]
GO
ALTER AUTHORIZATION ON SCHEMA::[DatabaseMailUserRole] TO [DatabaseMailUserRole]
GO

Bei meiner letzten Korrektur trat erst der Fehler mit der TargetServersRole als erstes auf, dann die SQL Server Engine ohne Traceflag neu gestartet und wieder in eine Fehlersituation gelaufen, diesmal mit der DatabaseMailUserRole, also dieser Fehler/diese Fehler können auch hintereinander auftreten. Meine Kunden konnte ich in beiden Situationen mit der Hilfe der Blogbeiträge doch recht schnell wieder bereinigen und innerhalb kürzester Zeit den SQL Server wieder lauffähig zur Verfügung stellen.

Danke an Tim Wappat für die Lösung und die Bereinigung der TargetServersRole
https://timwappat.info/post/2019/02/15/SQLUpgradeFailMsdb110_upgradesql (lässt sich leider nicht so schön einbetten 🙁 )

Danke an Pinal Dave für die Lösung und die Bereinigung der DatabaseMailUserRole

SQL Server Failover Cluster on Azure

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 😉

aMS Germany 2020 – ein weiterer virtueller Event

Am gestrigen Dienstag durfte ich zwei Sessions auf der aMS Germany 2020 halten, ein virtueller Event organisiert durch mehrere Community-bekannte Größen wie Sascha Fredrich und Martin Gudel. Diese Zusammenarbeit zeigt auch sehr schön, dass es möglich ist solche Veranstaltungen zu organisieren, auch wenn man 100te Kilometer auseinander wohnt. Sascha im Süden von Deutschland (also zumindest für mich – Süden 😉 ) und Martin in Hamburg. Dem Organisationsteam gehörten auch noch Patrick Guimonet an, sowie Mr. OneDrive Hans Brender, gemeinsam haben Sie einen Event erstellt, der insgesamt in 7 parallelen Tracks mit mehr als 50 Session beinhaltet.

Einen Überblick über alle Sprecher und Sessions könnt ihr auf den Schedule-Seiten der Veranstaltung finden. => https://ams-germany-2020.sessionize.com/

meine erste Session – Einstieg in Azure SQL Managed Instance

In dieser Session ging um einen ersten groben Einblick, was die Azure SQL Managed Instance ist, was sie kann und was man für sein Geld bekommt. Begonnen habe ich mit einem ersten Überblick welche Möglichkeiten Azure SQL alles bietet, zum Beispiel das Deployment eines normalen SQL Server in einer Azure virtuellen Maschine oder als Azure SQL Database in den unterschiedlichen Ausprägungen. Weiter ging es mit den verschiedenen Fakten zu aktuellen Features und Fakten rund um die Managed Instance und woran man bei der Vorbereitung und Planung eines Deployments denken sollte.

aMS Germany 2020 - Bjoern Peters - Einstieg in Azure SQL Managed Instance - Beispiele für Features und Capabilities - Business Continuity

In der Demo bin ich einmal ein exemplarisches Deployment einer Azure SQL Managed Instance über das Portal durchgegangen und habe zu den wichtigsten Konfigurationspunkten etwas erklärt, damit alle Teilnehmer der Session verstehen was wichtig ist und was man beachten sollte. In meiner Demo-Umgebung konnte ich abschließend noch zeigen, wie sich die neue Instanz sowohl im SQL Server Management Studio als auch im Azure Data Studio darstellt.

Fragen wurden leider keine gestellt, was darauf hindeutet, dass mein Vortrag verständlich und nicht zu kompliziert war. 😉

meine zweite Session – Change your skills – Überblick über aktuelle Lernpfade und Zertifizierungen

Da ich mich in diesem Jahr verstärkt um das Thema Zertifizierungen gekümmert habe, vor allem meine eigenen, und immer wieder in Gesprächen feststellen musste, das viele hier große Fragen haben, wollte ich hier einmal Licht ins Dunkel bringen. Also ging es in diesem Vortrag um die verschiedenen – unter anderem kostenfreien – Möglichkeiten wie man zum einen Wissen aufbauen kann zu den aktuellen Themen im Microsoft Umfeld, zum anderen wie man mit diesem Wissen sich die dazugehörigen Prüfungen vorbereiten kann.

aMS Germany 2020 - Bjoern Peters - Change your skills - Überblick über aktuelle Lernpfade und Zertifizierungen - von der produktspezifischen Prüfung zur Rollenbasierten Zertifizierung

Microsoft bietet mit Microsoft Learn ein sehr gute Plattform und vor allem in Zeiten der Corona-Pandemie erweiterte Möglichkeiten zur Weiterbildung, wie man hier seinen eigenen Bildungsweg findet und welche Inhalte für wen relevant sind, sowie was man mit diesem Wissen erreichen kann, darum ging es in diesem Vortrag. Ich wollte einen Überblick über die unterschiedlichen Plattformen und Wege aufzeigen mit denen man sich den neuen Herausforderungen in der aktuellen Projektsituation bewähren kann oder eben auf neue, zukünftige Aufgaben vorbereiten kann.

Gerade heute habe ich erst wieder ein längeres Gespräch mit einem Kollegen gehabt, der mich zu den Details in der Vorbereitung und Durchführung einer Microsoft Prüfung aus dem Home-Office heraus befragte. Ich erklärte im die wichtigen Punkte beim System-Test, dem CheckIn-Prozess und auf was man achten muss, wenn man die Prüfung aus den eigenen vier Wänden angehen möchte. Denn Microsoft hat diese Möglichkeit eingeräumt bzw ausgeweitet, damit viele neue Teilnehmer – trotz geschlossener Prüfungscenter – und gerade bei Kurzarbeit oder Unternehmungsschließung sich auf neue Abenteuer vorbereiten kann.

Hierzu gibt es auch eine neue Zusammenarbeit zwischen Microsoft und Linkedin, bei der es darum geht, Arbeitssuchenden oder Umschulungswilligen eine Plattform zu bieten, auf einfachen und unkomplizierten Wegen sich Wissen anzueignen und so sich Vorteile auf dem Arbeitsmarkt zu verschaffen.

meine Präsentationen der aMS Germany 2020

Mir haben diese beiden Vorträge – sowohl in der Vorbereitung und der Durchführung – sehr viel Spaß gemacht, ich hoffe ich konnte zumindest einem Teilnehmer ein wenig helfen. Vielen Dank den Organisatoren und Sponsoren der #aMSGermany2020.

SQL Server on Docker – Demo-Umgebung mit Docker Desktop

Ich benötige für mehrere Demos und Präsentation immer mal wieder einen SQL Server um gewisse Dinge zu zeigen, egal ob beim Kunden, bei Veranstaltungen oder mal eben so dem Kollegen. Meist hat man ja irgendwie eine Internet-Verbindung und könnte dann seine virtuelle Maschine in Azure hochfahren und dann dort die Aufgaben durchführen, manchmal gibt es diesen Luxus nicht oder manchmal muss es auch schneller gehen, um zum Beispiel den Gesprächsfluss nicht zu unterbrechen. Daher habe ich mir überlegt, dass es doch ganz großartig wäre, wenn ich einen SQL Server auf meinem Laptop starten könnte… nun habe ich aber keinen “großen” Laptop auf dem ich mal eben eine virtuelle Maschine mit VirtualBox oder VM-Workstation starten könnte. Also musste eine andere Lösung her 😉
In den vergangenen Monaten hatte ich mich immer wieder mit Frank Geisler (b|t) unterhalten, bei dem in jedem Satz mindestens einmal “Docker” vorkommt (Sorry Frank 😉 )… also was lag näher als sich selber noch einmal damit auseinanderzusetzen. Wie kann man nun ohne großen Aufwand auf einem Windows 10 Laptop eine Docker-Umgebung installieren???

Docker Desktop for Windows 10

Docker selber bietet hier eine Laufzeit-Umgebung für Windows und Mac an, den kostenfreien “Docker Desktop“. Mit ~930MB nicht unbedingt ein Leichtgewicht, aber es bietet sehr viele Möglichkeiten inklusive dem Rollout eines lokalen 1-Knoten Kubernetes Clusters für Dev-Zwecke, aber dazu in einem weiteren Post mehr Informationen. Jetzt geht es hier erst einmal um das einfach Rollout eines oder mehrerer SQL Server Container mittels Docker Desktop.

Dazu lade ich den Docker Desktop herunter und starte die Installation, hier geht es dann mit “weiter, weiter, Finish” durch… dann dauert etwas, bis Docker Desktop überprüft hat, ob die Installationsroutine noch etwas nachladen muss, aber alles in allem keine “Ewigkeit”.

Docker Desktop checks installable packages

Danach findet ihr im Startmenü ein entsprechenden Verweis auf die neue Installation des Docker Desktops, diese müsst ihr als Administrator starten und erhaltet als “Startbildschirm” die folgende Ansicht… es ist aktuell nach der Erst-Installation natürlich kein Container verfügbar 😉

Docker Desktop show "no containers running" - and gives example

Wenn man nun diesen Beispiel-Container einmal startet, erhält man auf jeden Fall eine Web-Applikation in/aus einem Container, welche sich auch über den Browser aufrufen lässt. Damit dies aber geschieht, beginnt docker erst einmal mit der Überprüfung ob das Container-Image überhaupt verfügbar ist bzw in welcher Version es vorliegt und ob es ggfs ein Update dazu gibt. Je nach Ergebnis wird dann ein entsprechender Download durchgeführt, um im Anschluss den Container erfolgreich zu starten.

docker run -d -p 80:80 docker/getting-started
Unable to find image 'docker/getting-started:latest' locally
latest: Pulling from docker/getting-started
cbdbe7a5bc2a: Pull complete
85434292d1cb: Pull complete
75fcb1e58684: Pull complete
2a8fe5451faf: Pull complete
42ceeab04dd4: Pull complete
bdd639f50516: Pull complete
c446f16e1123: Pull complete
Digest: sha256:79d5eae6e7b1dec2e911923e463240984dad111a620d5628a5b95e036438b2df
Status: Downloaded newer image for docker/getting-started:latest
74ff7cc76ca107a5bb27e7013e3d9715129ce182518d9fd8d4c363ffadc84b51

Jetzt sehen wir in Docker Desktop unsere Beispiel-Applikation als laufenden Container, nach dem Aufrufen der Webseite (localhost) gelangen wir zu dem Einstiegs-Tutorial und weiteren Erläuterungen rund um die Möglichkeiten von Containern.
Soviel erst einmal zu den Grundlagen von Docker Desktop und dem Starten von Containern… wir wollten uns aber um den SQL Server kümmern bzw die Erstellung einer lokalen Demo-Umgebung mit Docker Containern. Wie man es aus den Blogbeiträgen von Frank Geisler , anderen Docker-Enthuasiasten oder auch von mir kennt, muss man nun das zu ladende Image aus einem Container-Repository definieren, mittels “docker pull” herunterladen und dann über “docker run” entsprechend starten.

$imagepath = 'mcr.microsoft.com/mssql/server:2019-latest'
## CU5
$imagepath = 'mcr.microsoft.com/mssql/server:2019-CU5-ubuntu-16.04'
## Windows 
$imagepath = 'mcr.microsoft.com/microsoft/mssql-server-windows-developer'

docker pull $imagepath

$new_sqlserver_name = "SQLServer2019"

docker run -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=SQLServerDemo@2020" -p 1433:1433 --name $new_sqlserver_name -d $imagepath
Docker Desktop dashboard shows a container called SQLServer2019 is running based on SQL Server 2019 latest image.

Nun läuft unser SQL Server 2019 in einem Docker Container und wir können wie gewohnt den vollen Umfang entsprechend nutzen und auch mit dem SQL Server Management Studio als auch dem Azure Data Studio auf diese neue SQL Server Instanz zugreifen. Aber auch über die Commando-Zeile ist es möglich den SQL Server zu administrieren, hierzu muss man sich entsprechend mit dem Container verbinden und z.B. eine Connection über sqlcmd eröffnen oder einen Zwischenschritt in die Bash und dann erst auf den SQL Server… hier sind die Möglichkeiten vielfältig.

docker exec -it $new_sqlserver_name /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P SQLServerDemo@2020

docker exec -it $new_sqlserver_name "bash"
cd /var/opt/mssql/data/
wget https://github.com/Microsoft/sql-server-samples/releases/download/wide-world-importers-v1.0/WideWorldImporters-Full.bak
/opt/mssql-tools/bin/sqlcmd -S . -U sa -P SQLServerDemo@2020 -Q "RESTORE DATABASE [WideWorldImporters] FROM  DISK = N'/var/opt/mssql/data/WideWorldImporters-Full.bak' WITH  FILE = 1,  MOVE N'WWI_Primary' TO N'/var/opt/mssql/data/WideWorldImporters.mdf',  MOVE N'WWI_UserData' TO N'/var/opt/mssql/data/WideWorldImporters_UserData.ndf',  MOVE N'WWI_Log' TO N'/var/opt/mssql/data/WideWorldImporters.ldf',  MOVE N'WWI_InMemory_Data_1' TO N'/var/opt/mssql/data/WideWorldImporters_InMemory_Data_1',  NOUNLOAD,  STATS = 5"

Ich wünsche euch viel Spaß beim Ausprobieren eurer lokalen Demo-Umgebungen. 😉
Bei Fragen stehe ich natürlich gerne zur Verfügung!

Azure Data Studio shows basic dashboard direct after first connection to sql server in a docker container