SQL_Server_Lab erstellt lokale, isolierte SQL-Server-Testumgebungen für Entwicklung, Analyse und Schulung. Das PowerShell-Modul übernimmt Erstellung, SQL-Bereitschaft, Datenbank- und Skriptaufgaben, Start/Stop sowie scopegebundenen Cleanup. Docker und Podman sind die Kernprovider; Hyper-V bietet eigene begrenzte Windows-/SQL-Referenzpfade.

Das Projekt richtet sich an EntwicklerInnen, SQL-AdministratorInnen und SchulungsteilnehmerInnen. Es wird aktiv weiterentwickelt; der implementierte Umfang und tatsächlich ausgeführte Providerabnahmen stehen getrennt in der öffentlichen Referenz und den bekannten Grenzen.

Neue Lab-Connection-Strings und SSMS-Registrierungsexporte verwenden Encrypt=True;TrustServerCertificate=True als einfachen Standard ohne eigene CA-/Client-Trusteinrichtung. Gespeicherte Altverbindungen werden nicht migriert. Die ausdrückliche Wahl von TrustServerCertificate=False ist im begrenzten Windows-/Docker-/Podman-Pfad für SQL 2025 CU9, 2022 CU27 und 2019 CU32 mit qualifiziertem separatem Export implementiert. CLI und GUI zeigen die angegebenen Flags; der Flagwert allein ist kein Qualifikationsnachweis. Die ausdrückliche Liveprüfung am SQL-Ziel liefert eine aktuelle Beobachtung beider strikten Clients. Die Container-Erstellung im Browser verwendet den einfachen True/True-Standard und bietet katalogisierte CUs für SQL 2019, 2022 und 2025 zur ausdrücklichen Auswahl. Die authentifizierte Erstellung im Browser verwendet die bestehende qualifizierte CA-/Clientbindung und die ausdrückliche False-Wahl. Die Kopieraktion an der Lab-Instanz übernimmt deren angezeigten Connection String einschließlich vorhandener Passwortplatzhalter. Weitere Erstellungsoptionen, weitere Plattformen und Lifecyclekontexte bleiben TLS-001-Scope.

• PowerShell 7.2 oder neuer.
• Eine installierte und laufende Docker- oder Podman-Runtime für Containerlabs.
• sqlcmd für die dokumentierten SQL- und Diagnoseschritte.

Die Windows-Installation und Linux-Installation führen durch die Einrichtung. Hyper-V verlangt die zusätzlichen Voraussetzungen aus der Entwicklungs- und Testumgebung.

In PowerShell 7:

git clone https://github.com/gecompat/SQL_Server_Lab.git
Set-Location .\SQL_Server_Lab
Import-Module .\SqlServerLab.psd1 -Force
Invoke-SqlServerLab -Action Setup
Invoke-SqlServerLab

Beim ersten Setup wählt der gemeinsame Assistent Lab_Base und Lab_Data. Die Konsole bietet danach den geführten Zugang zu Labaufgaben. Eine bestehende Einrichtung wird erneut verwendet. Die Schritt-für-Schritt-Anleitung beschreibt Erstellung, Verbindung und Cleanup. Die optionale Browserbedienung startet mit ./Tools/Start-SqlServerLabUi.ps1; Bedienung und Grenzen erläutern den Ablauf.

Sicherheit: Lababläufe können Ressourcen, Konfigurationen und Daten verändern. Verwende isolierte Labs mit zulässigen synthetischen oder öffentlichen Samples. Produktionsbackups, Kundendaten und Secrets gehören nicht in das Repository. Security Policy und bekannte Grenzen gelten vor der Ausführung.

NOTICE: This software is NOT Open Source. Use is governed by a custom Attribution & Non-Commercial Redistribution License.

1. NO RESALE: Selling, renting, leasing, or charging third parties for access to this repository, its scripts, lab definitions, templates, documentation, or generated project content is prohibited.
2. ATTRIBUTION REQUIRED: The copyright notice for gecompat - Gerhard Pisch must be preserved.
3. NO LIABILITY: Use is at your own risk. Lab scenarios may deliberately create resource pressure, failures, configuration changes, or destructive states inside isolated lab scopes.

The complete terms are defined in LICENCE.md.

SA-Passwort-Vorprüfung und Korrektur folgen dem Passwortvertrag; die dokumentierten Erststart-, HTTP- und Browserabnahmen stehen in der Validierungsstrategie. Die nicht ausführbare Autostartvorschau ist in der öffentlichen Referenz beschrieben. Details zur geführten KI-Erstellung und dem internen SQL-HTTPS-Referenzpfad: Podman-KI-Setup, SQL-HTTPS-Brücke.

Das Repository dient insbesondere als gemeinsame Ausführungsbasis für:

• gecompat/SQL_Server_Analyze
• gecompat/SQL_PerformanceSchulung
• gecompat/SQL_Server_Toolbelt

SQL_PerformanceSchulung verwendet überwiegend eine aktuelle Linux-Umgebung zur Konstruktion von Beispielen und kann für besondere Konstellationen Windows oder eine andere katalogisierte SQL-Version anfordern. Für jede freigegebene Demo hält das Schulungsrepository eine Schritt-für-Schritt-Anleitung vor, mit der Dritte Aufbau, Durchführung, Beobachtung und Einordnung reproduzierbar nachvollziehen können. SQL_Server_Analyze und SQL_Server_Toolbelt verwenden Windows- und Linux-Umgebungen mit SQL Server 2019, 2022 und 2025 für versionsabhängige Entwicklungs- und Abnahmetests. Die fachlichen Inhalte und Nachweise bleiben in den konsumierenden Projekten; SQL_Server_Lab stellt den generischen Umgebungs- und Lifecyclepfad bereit und testet seinen Core je Provider nur mit SQL Server 2025.

Status: CONTAINER_CORE_IMPLEMENTED_HYPERV_SQL_CLI_ACCEPTED

Docker und Podman bilden den Containercore. Hyper-V besitzt eigene Windows-/SQL-Lifecycle- und Referenzpfade; vollständige deklarative Drives, Datenbanken und Network Intents bleiben bis zu ihrem End-to-End-Nachweis begrenzt. Implementiertes Verhalten und native Abnahme sind getrennte Aussagen.

Der normale Menüpfad verwendet ProviderPreference = Auto; eine explizite Providerwahl liegt in den erweiterten Eigenschaften. Hyper-V-spezifische Vorlagen-, ISO-, Slot- und Recovery-Aufgaben liegen im Infrastrukturbereich. Die bekannten Grenzen gehören zum öffentlichen Vertrag. Planungsdokumente und historische Abnahmen belegen keinen neueren Repositoryzustand.

Mindestens erforderlich:

• PowerShell 7.2 oder neuer
• Docker oder Podman
• WSL 2 und aktivierte Hardwarevirtualisierung bei Windows-Containerruntimes
• mindestens 4 GB freier RAM für ein kleines Lab
• mindestens 5 GB freier Speicherplatz
• sqlcmd für Datenbankerstellung, Restore, Skriptausführung und den vollständigen Smoke-Test
• Git für Klonen und Aktualisieren des Repository; bei ZIP-Bezug optional

SA-Passwörter werden beim Host-sqlcmd und den Docker-/Podman-Healthchecks unverändert an die Passwortoption gebunden, einschließlich führendem Minus. Die begrenzten Parser- und Providerprüfungen stehen in der lokalen Validierungsstrategie.

Die vollständige Einrichtung mit offiziellen Downloadlinks, Installationsbefehlen, Docker-/Podman-Auswahl und podman machine start podman-machine-default steht in der Windows-Installationsanleitung für AnwenderInnen. No-Profile- und Agent-Shells können Docker, Podman und Python prozesslokal über .\Tools\Initialize-SqlServerLabHostTools.ps1 auflösen; persistierte Benutzer- und Maschinen-PATH-Werte werden dabei nicht verändert. Das gilt für jeden neu gestarteten Prozess erneut; nach erfolgreicher Auflösung ist der ausgegebene absolute Invocation-Pfad zu verwenden. Ein anschließender info- oder Zugriffsfehler bedeutet nicht, dass die CLI fehlt. Der native Ubuntu-Pfad ist getrennt in der Linux-Installationsanleitung beschrieben. ISO-, VHDX- und SQL-Installationsmedien liegen in einem operatorseitig angegebenen externen Media Root, nicht im Repository. Der vollständige Operatorablauf für eine Windows-/Linux-Testmatrix mit SQL Server 2019, 2022 und 2025 sowie einem separaten CMS steht im End-to-End-Runbook. Eine optionale Windows-OS-Baseline wird über die Hyper-V-Image-Build-Anleitung aus der verifizierten ISO erstellt. Wiederverwendbare SQL-Prepared-Images werden gemäß der SQL-Prepared-Image-Anleitung standardmäßig als differenzierende VMs aus einer veröffentlichten OS-Baseline erstellt; dadurch entfällt die Windows-Neuinstallation je SQL-Version. Austauschbare Evaluation-Images und langlebige Daten trennt der Data-Root- und Refresh-Vertrag. Die zusätzlichen Voraussetzungen für Entwicklung, Provider-Smoke-Tests, Self-hosted Runner und Hyper-V beschreibt die Entwicklungs- und Testumgebung. Für einen geführten Überblick über Windows-Baselines, SQL-Prepared-Images und offene Schritte steht außerdem die lokale Workflow-Oberfläche bereit. Ihre gemeinsame HTTP-Grenze prüft Origin/Authority und JSON-POSTs. Sieben direkte POST-Routen begrenzen den Body auf 1 MiB UTF-8 und fünf Sekunden Lesefrist; Operatorauthentifizierung bleibt offen. Der Vorlagen- und Manifestvertrag trennt dabei immutable Vorlagen, wegwerfbare Labs und explizite Expertenaktionen.

Runtime prüfen:

$PSVersionTable.PSVersion
docker info
# oder
podman info

sqlcmd -?

Einen beliebigen katalogisierten CU vorab bereitstellen:

# Windows: offizielles Paket nach Lab_Base; SHA-256 und Microsoft-Authenticode werden erzwungen
Save-SqlServerLabCuResource -SqlVersion 2022 -Cu CU18 -Platform Windows -MediaRoot 'D:\Lab_Base'

# Linux: exakten MCR-Tag in den lokalen Runtimecache ziehen
Save-SqlServerLabCuResource -SqlVersion 2022 -Cu CU18 -Platform Linux -Provider Docker

Katalogisierte Samples und die Offline-Pakete der SQL-2022-Windows- External-Runtimes können unabhängig von einer Provisionierung geplant und bereitgestellt werden:

$ids = @(
    'sample:northwind:script'
    'sample:adventureworks-2019:lightweight'
    'software:sql-python:sql2022-python-windows-hyperv'
)
Get-SqlServerLabResourcePlan -ResourceId $ids -MediaRoot 'D:\Lab_Base'
Save-SqlServerLabResourceSet -ResourceId $ids -MediaRoot 'D:\Lab_Base' -TrustUnknownArtifact

-SourceMediaRoot verwendet einen älteren Bestand vor dem Netzwerkdownload, akzeptiert aber nur die katalogisierte Identität und erneut geprüfte SHA-256. -WhatIf zeigt die geplanten Mutationen. Samples ohne Kataloghash benötigen weiterhin die ausdrückliche einmalige Freigabe -TrustUnknownArtifact.

Der gleiche Ablauf ist ohne Kommandozeilenkenntnisse unter Medien, Testdaten und Speicher → SQL Server CU herunterladen oder prüfen verfügbar.

Ein katalogisiertes SQL- oder Windows-Server-Basismedium herunterladen:

Save-SqlServerLabMediaSource -Id sql-server-2016-evaluation-sp2-iso -MediaRoot 'D:\Lab_Base'

Die direkten Microsoft-URLs und verifizierten historischen Fallbacks sind mit Dateigröße und SHA-256 in Catalogs/sql-server-media-sources.json gebunden. Das SQL-Server-2016-SP2-Evaluation-ISO ist zusätzlich an SHA-1 gebunden und über Volume, Slipstream-Manifest, KB4052908 und Setup-Build 13.0.5026.0 geprüft. Für Windows Server 2016, 2019, 2022 und 2025 sind die öffentlich erreichbaren Microsoft-Binärziele der Evaluation-Center-Weiterleitungen direkt katalogisiert; dabei werden weder Formulare ausgefüllt noch Identitätsdaten übermittelt. Bei Archive.org-Einträgen werden zusätzlich der feste Identifier, die maschinenlesbare Metadata-URL, der frühere Microsoft-Pfad und SHA-1 geführt. Die Freigabe gilt ausschließlich für die konkret katalogisierte Datei; Community-Scans benötigen -AllowCommunityScan und landen in Quarantäne. SQL Server 7.0 und 6.5 benötigen weiterhin manuell bereitgestellte lizenzierte Originalmedien; Azure-Varianten gehören nicht zum Katalog.

Optionale lokale Lizenzprofile ergänzen den Bestand, ohne den bisherigen schlüssellosen Betrieb zu verändern. Evaluation, Developer und Express bleiben ohne Product Key nutzbar. Für ein lizenziertes SQL-Prepared-Image wird eine passende Profil-ID ausdrücklich gewählt; Schlüssel werden nie in Git, Manifeste oder Build-State geschrieben. Siehe Optionale Lizenzprofile.

Vor dem Download kann der aktuelle Microsoft-Stand read-only geprüft werden:

Get-SqlServerLabCuStatus

Im Menü lautet der Weg Medien, Testdaten und Speicher → Aktuelle CUs bei Microsoft prüfen. Neue Funde sind bewusst noch nicht downloadbar: Erst ein geprüfter Katalogeintrag mit MCR-Tag, Microsoft-Downloadziel, SHA-256 und Authenticode-Vertrag gibt sie für Lab_Base frei. Der Katalog enthält alle 67 bei Microsoft weiterhin verfügbaren CUs für SQL Server 2019, 2022 und 2025; SQL Server 2019 CU7 bleibt wegen des Rückzugs durch Microsoft bewusst ausgeschlossen.

Eine SQL-Server-2025-Umgebung erstellen:

$lab = New-SqlServerLab -Version '2025' -Provider docker -AutoStart on

SQL Server 2017 ist als veralteter Containerpfad katalogisiert und benötigt einen ausdrücklichen Opt-in:

$lab = New-SqlServerLab -Version '2017' -Provider docker -AllowDeprecated

Mit Podman:

$lab = New-SqlServerLab -Version '2025' -Provider podman -AutoStart on

Interaktive Bedienung:

Invoke-SqlServerLab

Einen Windows-Slot-Pool interaktiv erstellen oder fortsetzen:

.\Invoke-SqlServerLab.ps1 -Action WindowsSlotPool

Der Workflow prüft zuerst, ob eine geeignete OS_SEALED-Windows-Baseline mit ausreichender Evaluation-Restlaufzeit vorhanden ist. Fehlt sie oder läuft sie bald ab, führt das Menü in den bestehenden Windows-Image-Aufbau. Danach fragt es Anzahl, Slotnummer, vCPU, minimalen/Start-/maximalen RAM (Standard 1024/2048/4096 MB), Region, System-Locale, Anzeigesprache, Tastaturlayout und Zeitzone ab. Für die Slots kann entweder je Slot ein generiertes Passwort oder ein eigenes gemeinsames Passwort verwendet werden. OOBE und Erstanmeldung der Slots laufen unbeaufsichtigt; fertige Slots werden standardmäßig gestoppt.

Der erstmalige Aufbau der generalisierten Windows-Baseline aus einer ISO bleibt derzeit geführt und enthält noch manuelle Windows-Installationsschritte. Der anschließende Poollauf ist wiederaufnehmbar und überspringt bereits fertige, exakt passende Slots.

Der Standalone-Einstieg akzeptiert dieselben Direktaktionen wie das importierte Modul, beispielsweise ./Invoke-SqlServerLab.ps1 -Action Setup oder ./Invoke-SqlServerLab.ps1 -Action CleanupAudit. Die interaktive Fallback- Ansicht zeigt [0] Zurück; freie Textfelder verwenden 0 als sichtbaren Abbruchalias.

Standard für Skript-Hilfeeinträge (-ShowHelp und --help; /? sowie -help/-h/-? können je nach PowerShell-Kontext die Engine-Hilfe auslösen):

.\Invoke-SqlServerLab.ps1 -ShowHelp
.\Tools\Initialize-SqlServerLabDataRoot.ps1 -ShowHelp
.\Tools\Initialize-SqlServerLabMediaRoot.ps1 -ShowHelp
.\Tools\Start-SqlServerLabUi.ps1 -ShowHelp
.\CheckLargeGitFilesPush.ps1 --help

Wenn einer dieser Schalter erkannt wird, wird die Skript-Hilfe angezeigt und die Ausführung beendet.

Status anzeigen:

Get-SqlServerLab

New-SqlServerLab liefert pro Instanz Host, Port und Connection String zurück.

$instance = $lab.Instances[0]
$instance.Host
$instance.Port
$instance.ConnectionString

Beispiel für SSMS:

Server name: 127.0.0.1,14330
Authentication: SQL Server Authentication
Login: sa
Password: das bei der Erstellung gesetzte SA-Passwort
Trust server certificate: aktiviert

Der konkrete Port wird dynamisch im Bereich 14330 bis 14399 vergeben, sofern kein Port vorgegeben wurde.

Für einen verwalteten CMS sind zwei Kennwörter zu unterscheiden: SSMS darf das CMS-SA-Passwort lokal verschlüsselt speichern; ein CMS-Mitglied verwendet dagegen sein eigenes SA-Passwort. Mitgliedsziele werden aus Sicht des SSMS-Hosts registriert, sodass ein veröffentlichter Loopback-Endpunkt nicht in einen containerinternen Host-Alias umgeschrieben wird. Einrichtung, Kennwortanzeige, Zählregeln und die Reparatur eines fehlerhaften SSMS-22-Eintrags beschreibt die SQL-Verbindungszentrale.

$pw = Read-Host 'SA-Passwort' -AsSecureString

New-SqlServerLabDatabase `
    -Port $lab.Instances[0].Port `
    -SaPassword $pw `
    -DatabaseName 'MeineTestDB'

Dateien können auf gemountete Containerpfade gelegt werden:

New-SqlServerLabDatabase `
    -Port $lab.Instances[0].Port `
    -SaPassword $pw `
    -DatabaseName 'PerfDB' `
    -DataFiles @(
        @{ name = 'PerfDB_Data1'; path = '/sqldata/PerfDB_Data1.mdf'; sizeMB = 512 },
        @{ name = 'PerfDB_Data2'; path = '/sqldata/PerfDB_Data2.ndf'; sizeMB = 512 }
    ) `
    -LogFiles @(
        @{ name = 'PerfDB_Log'; path = '/sqllog/PerfDB_Log.ldf'; sizeMB = 256 }
    )

Die Zielpfade müssen als drives beziehungsweise Volumes in der Labdefinition bereitgestellt sein.

Invoke-SqlServerLabScript `
    -ScriptPath '.\setup.sql' `
    -Port $lab.Instances[0].Port `
    -SaPassword $pw `
    -Database 'MeineTestDB'

Relative postProvision-Pfade in Manifesten werden relativ zum Manifest-Verzeichnis aufgelöst.

Manueller Restore:

Restore-SqlServerLabDatabase `
    -Port $lab.Instances[0].Port `
    -SaPassword $pw `
    -BackupSource 'C:\Backups\AdventureWorks2022.bak' `
    -DatabaseName 'AdventureWorks2022' `
    -ContainerName $lab.Instances[0].ContainerName

Fuer einen bereits provisionierten Run ist die RunId-basierte Aufloesung bevorzugt; sie liest Provider, Container, Host und Port aus dem lokalen State:

Restore-SqlServerLabDatabase `
    -RunId $lab.RunId `
    -InstanceId 'primary' `
    -SaPassword $pw `
    -BackupSource 'C:\Backups\AdventureWorks2022.bak' `
    -DatabaseName 'AdventureWorks2022'

Ein von Backup-SqlServerLabDatabase veröffentlichtes Backup wird ohne Weitergabe seines lokalen Pfads oder Hashes über die stabile ID ausgewählt:

Restore-SqlServerLabDatabase `
    -RunId $lab.RunId `
    -InstanceId 'primary' `
    -SaPassword $pw `
    -BackupSetId $backup.BackupSetId `
    -DatabaseName 'AdventureWorks2022'

Ohne -DataRoot verwendet der Aufruf den gespeicherten Lab_Data-Default. Der Bibliotheks-Core prüft Status, Verification-Evidence, Datei und SHA-256 vor dem Restore erneut. -BackupSetId und -BackupSource schließen einander aus.

Eine HTTPS-URL kann ebenfalls als BackupSource verwendet werden. Sie wird zuerst in einen lokalen Staging-Bereich geladen, per SHA-256 geprüft und danach unter diesem Digest im inhaltsadressierten State-Cache gespeichert. Fehlt eine bekannte Prüfsumme, fragt ein interaktiver Aufruf einmalig nach Vertrauen und registriert den berechneten Hash lokal. Mit -NonInteractive endet derselbe Fall ohne Download mit TRUST_REQUIRED.

Ein Manifest kann vollstaendig in der Konsole erstellt werden. Der Wizard liest Pflichtfelder, optionale Felder, Typen, Wertebereiche und Auswahlwerte direkt aus dem JSON-Schema. Pfade zeigen dabei ihren Host-/Gast-/SQL-Server-Scope, ihre Bezugsbasis, Default- und Erzeugungsregel sowie bei relativen Hostwerten eine aufgelöste Vorschau:

New-SqlServerLabManifest -Path '.\mein-lab.json'

Alternativ steht im Hauptmenue die Aktion m zur Verfuegung:

Invoke-SqlServerLab -Action Manifest

Ein vorhandenes Manifest kann ohne Provisionierung geprueft werden:

$result = Test-SqlServerLabManifest -Path '.\mein-lab.json'
$result.Errors
$result.Warnings
$result.Plan.Instances.ExternalRuntimes.Entries

Fehler verhindern das Speichern beziehungsweise Provisionieren. Als reserved klassifizierte serverConfig-Felder sowie reservierte Werte werden mit MANIFEST_RESERVED_RUNTIME_FIELD beziehungsweise MANIFEST_RESERVED_RUNTIME_VALUE fail-closed abgelehnt; Warnungen kennzeichnen weiterhin riskante, aber ausführbare SQL-Konfigurationen. Bei software bietet der interaktive Wizard nur Varianten an, die der Software-Resolver fuer die bereits gewählte SQL-Version, den Provider und das Betriebssystem als RESOLVED freigibt. Die mutationsfreie Planvorschau nennt den SQL-Lifecycle aus dem Versionskatalog einschließlich unbekannter Versionen sowie Artifact-Downloads, Derived-Image-Build oder Gastmutation, Restarts, Downtime, Package Locks, Verification und den sicheren Aenderungsweg (rebuild, restart, recreate oder reprovision). Ein gespeichertes Manifest läuft standardmäßig unbeaufsichtigt: fehlende Voraussetzungen stoppen mit einem Fehler statt eine Passwort- oder Trust-Abfrage zu öffnen.

{
  "$schema": "./Schemas/lab-manifest.schema.json",
  "name": "mein-erstes-lab",
  "automation": {
    "mode": "unattended",
    "secrets": {
      "saPassword": "SQL_SERVER_LAB_SECRET_SA_PASSWORD"
    }
  },
  "instances": [
    {
      "id": "primary",
      "version": "2025",
      "provider": "docker",
      "profile": "standard",
      "databases": [
        {
          "name": "AppDB",
          "options": {
            "recoveryModel": "FULL",
            "queryStore": true
          }
        }
      ]
    }
  ]
}

Ausführen:

$env:SQL_SERVER_LAB_SECRET_SA_PASSWORD = '<aus Secret Store oder CI-Injection>'
$lab = New-SqlServerLab -Manifest '.\mein-lab.json'
Remove-Item Env:SQL_SERVER_LAB_SECRET_SA_PASSWORD

Das Manifest enthält damit nur die Secret-Referenz, nie den Passwortwert. Der Resolver bevorzugt eine gleichnamige Prozessvariable und kann optional einen SecureString derselben Referenz über PowerShell SecretManagement beziehen. Remote-Backups benötigen für automatisierte Läufe eine restore.sha256; ohne bekannte Prüfsumme endet der Lauf mit TRUST_REQUIRED. Für zentrale Testdatenbibliothek, Data Root, die maximal 20 immutable Vorlagen und den ausdrücklich doppelten Opt-in für schreibende Host-Mounts siehe den Vorlagen- und Manifestvertrag.

Vollständige Beispiele liegen unter Schemas/.

Katalogisierte Testdatenbanken mit runtimeStatus: executable werden über den typisierten Sample-Handler installiert. Unterstützt sind direkte .bak-Files, ZIP-Dateien mit einer exakten katalogisierten .bak-Payload (temporär entpackt) sowie gepinnte einzelne T-SQL-Skripte. Die Integrität sichert der Artifact Resolver: Eine im Katalog hinterlegte SHA-256 wird erzwungen; fehlt sie, fragt ein interaktiver Lauf einmalig nach Vertrauen (interactive-once), registriert den berechneten Hash im lokalen Trust Store und legt das Artefakt im inhaltsadressierten Cache ab. Nicht interaktive Läufe enden ohne bekannten Hash mit TRUST_REQUIRED.

Der Download kann vor einem Lab-Lauf mit Get-SqlServerLabResourcePlan geplant und mit Save-SqlServerLabResourceSet ausgeführt werden. Dieser Prefetch nutzt denselben Trust-, Cache- und Quarantänevertrag und installiert keine Datenbank.

Ad-hoc können mehrere Samples pro Instanz gewählt werden – im Menü von Invoke-SqlServerLab über den Schritt Testdatenbanken oder direkt:

$lab = New-SqlServerLab `
    -Version '2022' `
    -Provider docker `
    -Sample 'adventureworks-2022:lightweight', 'wideworldimporters:standard'

Die Zieldatenbanknamen ergeben sich aus den erwarteten Katalog-Outputs. Kollidierende Ausgaben werden als SAMPLE_OUTPUT_CONFLICT abgewiesen. Nach der Installation verifiziert der Handler die erwartete Datenbank als ONLINE (DATASET_READY); eine bereits vorhandene Zieldatenbank blockiert die Installation gemäß fail-if-exists.

Im Manifest bleibt die deklarative Referenz unverändert:

{
  "name": "adventureworks-lab",
  "instances": [
    {
      "id": "primary",
      "version": "2022",
      "provider": "docker",
      "databases": [
        {
          "name": "AdventureWorks2022",
          "sample": {
            "id": "adventureworks-2022",
            "variant": "full"
          }
        }
      ]
    }
  ]
}

Northwind und Chinook sind als SHA-256-verifizierte Skript-Samples direkt wählbar. Katalogisierte .7z-Archive mit genau einer .bak-Payload werden nach expliziter lokaler 7-Zip-Installation unterstützt. Große .7z-Archive mit MDF/LDF-Dateien, Script-Bundles und Attach-Szenarien bleiben bewusst beschreibend und werden nicht als Backup oder Skript umgedeutet.

Der verbindliche Zielvertrag für weitere Script-Bundle-Handler, kontextreiche Pfadführung und LAB_GENERATED-Baselines ist in Testdatenbank-Provisionierung und menügeführte Manifest-Erstellung dokumentiert; diese Teile bleiben für spätere Wellen vorgesehen.

Konsumierende Projekte koppeln sich über einen versionierten Adaptervertrag an den Lab-Core (Schemas/project-adapter.schema.json, Version 0.1-draft). Version 0.1 führt ausschließlich relative T-SQL-Entrypoints innerhalb des Adapter-Roots aus; Pfad-Traversierung, absolute Pfade und unbekannte Major-Vertragsversionen werden abgelehnt.

Test-SqlServerLabAdapter -Path '.\Adapters\Examples\synthetic-demo'

Install-SqlServerLabAdapter `
    -Path '.\Adapters\Examples\synthetic-demo' `
    -RunId $lab.RunId `
    -SaPassword $pw

Install-SqlServerLabAdapter hat keinen Lifecycle-Seiteneffekt: Container, Volumes und Run-State bleiben unverändert; es laufen nur die deklarierten SQL-Entrypoints (preflight, install, update, validate, cleanup). Details stehen in Adapters/README.md, die Roadmap in der Project-Adapter-Priorisierung.

Nach erfolgreichem Remove prüft Get-SqlServerLabRunArtifactRemovalPlan genau einen entfernten Run; Invoke-SqlServerLabRunArtifactRemoval entfernt dessen zugelassene Metadaten mit Vorschau-, Referenz-, Retention- und Recovery-Schutz. Der geführte Dialog Wartung, Aufräumen und Recovery → Artefakte eines entfernten Runs bietet dieselbe Einzelauswahl, Vorschau und bestätigte Entfernung beziehungsweise Wiederaufnahme. Im Browser öffnet Wartung, Aufräumen und Recovery → Run-Artefakte prüfen den eigenen Dialog mit serverseitiger Bindung und separater Bestätigung. Bedienung und Grenzen.

Stop-SqlServerLab -RunId $lab.RunId
Start-SqlServerLab -RunId $lab.RunId
Restart-SqlServerLab -RunId $lab.RunId
Remove-SqlServerLab -RunId $lab.RunId

Der Lifecycle verwendet den pro Instanz gespeicherten Provider. Eine Podman- Instanz wird daher auch dann über Podman verwaltet, wenn Docker zusätzlich installiert ist. Ein Manifest kann Docker- und Podman-Instanzen in einem Run kombinieren; Status, Start, Stop und Cleanup arbeiten dafür je ProviderSubRun.

Achtung: Alle regulären Lab-Umgebungen löschen – auch laufende und gestoppte. Dies ist keine reine Restebereinigung: Auch verwaiste Lab-Container, Builder und alle Lab-Verzeichnisse im konfigurierten Data Root werden entfernt; Datenverlust ist möglich. Die Runs der geschützten Testgruppe und veröffentlichte OS-/SQL-Vorlagen sind ausgenommen. Die Bestätigung steht standardmäßig auf Nein.

Clear-SqlServerLab

Nur Befunde lesen: Get-SqlServerLabCleanupAudit -NoWrite. Nur nachweislich verwaisten State bereinigen: Clear-SqlServerLab -StateOnly.

Container-Batches laufen immer non-interaktiv. Deshalb referenziert der Plan nur den Namen einer eng benannten Prozessvariable; der Secret-Wert selbst wird nicht in Batch-, Operation- oder Event-State geschrieben:

$env:SQL_SERVER_LAB_SECRET_BATCH_SA_PASSWORD = '<aus Secret Store oder CI-Injection>'
$batch = New-SqlServerLabBatch `
    -Name 'Zwei Docker-Labs' `
    -Defaults @{
        ProviderPreference = 'docker'
        Version = '2025'
        SaPasswordEnvironmentVariable = 'SQL_SERVER_LAB_SECRET_BATCH_SA_PASSWORD'
    } `
    -Items @(@{ id = 'sql'; kind = 'SqlEnvironment'; count = 2 })
Invoke-SqlServerLabScheduler -UntilIdle

Nach Neustart eines eigenen operativen TLS-Containers aktualisiert Update-SqlServerLabTlsBinding -RunId $lab.RunId -InstanceId primary -StateRoot $lab.StateRoot ausdrücklich dessen Startbindung nach beiden strikten Clients. Ein unveränderter Start ist kein neuer Nachweis; alte Exporte bleiben ungültig. Vertrag, WhatIf und Recoverygrenze.

Bei einer unterbrochenen Wiederbindung zeigt Get-SqlServerLabTlsBindingRecovery die eigene offene Transaktion. Resolve-SqlServerLabTlsBindingRecovery schließt genau diese mit beiden frischen strikten Clients ab oder nimmt nur die eigenen Metadaten ausdrücklich ohne TLS-PASS zurück. Die verlinkte Recoveryanleitung beschreibt Auswahl, WhatIf, Sperrgrenzen und noch fehlende native Nachweise.

Optionale Volltextsuche und FILESTREAM werden explizit über Manifest, CLI und GUI ausgewählt. Volltext ist für Docker/Podman und Windows/Hyper-V implementiert; FILESTREAM-T-SQL-Zugriff benötigt Windows/Hyper-V. Die Validierungsstrategie trennt implementierte Tests von tatsächlich ausgeführten Providerabnahmen.

CLI-Runstatus und GUI unter Verbindungen und CMS zeigen die angegebenen Werte von Encrypt und TrustServerCertificate je Ziel ausdrücklich an. Fehlende Werte werden nicht geraten; Anzeigevertrag.

Im Windows-Prepared-Pfad wird eine ausgewaehlte Instanzcollation bis CompleteImage weitergegeben und fuer Server, master und tempdb geprueft. Neue interaktive SQL-Zielintents nutzen den editierbaren Standard aus Catalogs/sql-intent-defaults.json, initial SQL_Latin1_General_CP1_CS_AS. Windows ohne Intent bleibt unveraendert; der begrenzte native SQL-2025-Referenznachweis und seine offenen Grenzen stehen in der Validierungsstrategie.

Instanzcollations im Manifest und bei New-SqlServerLab -Collation werden für SQL 2019/2022/2025 vor der Provisionierung an den kuratierten Katalog gebunden. Find-SqlServerLabCollation -Query 'Latin1 UTF8' -SqlVersion 2022 liefert passende vollständige Namen; die Konsole bietet dieselbe Suche als Auswahl. Unbekannte Namen oder nicht katalogisierte Major-Versionen werden abgewiesen. SQL-seitige Verifikation und freie Advanced-Eingaben bleiben offen.

SqlServerLab.psd1 ist die autoritative Liste der exportierten Funktionen.

Vorhandenes lokales Qwen kann über ollama-qwen25-coder-7b-local mit Live-Modellbindung verwendet werden. Die isolierte Hyper-V-Abnahme prüft einen eigenen Prepared-SQL-Run, RAG/Agent, Neustart und Cleanup. Dieser Referenzlauf bestand am 2026-09-21 mit 14 Assertions und vollständigem Cleanup. Defaults und Golden v1 bleiben unverändert.

Run-State liegt außerhalb des Git-Checkouts:

• Windows: %LOCALAPPDATA%\SqlServerLab
• Linux/macOS: ~/.sql-server-lab
• Override: Environment Variable SQL_SERVER_LAB_STATE

Pro Run entstehen unter anderem:

• run-state.json
• cleanup-plan.json
• connection-info.json
• lokale Secret-Dateien
• trust/sample-artifacts.json
• cache/artifacts/sha256/<sha256>/
• cache/quarantine/
• runs/<RunId>/manifest.lock.json bei URL-basierten Artifacts

Diese Dateien enthalten konkrete Laufzeitinformationen und gehören nicht in Git.

Ein nach einem abgebrochenen nativen Hyper-V-Test zurückgebliebener Run kann ausschließlich über den manuellen Workflow Hyper-V Scoped Test-Run Cleanup bereinigt werden. Er akzeptiert nur eine kanonische RunId, prüft den lokalen Test-State, Cleanup-Plan und die Live-VM-Identität und verwendet anschließend den öffentlichen, scopegebundenen Cleanup. Gemeinsame und produktive Umgebungen sind ausgeschlossen.

flowchart TD
    A[New-SqlServerLab] --> B[Manifest oder Ad-hoc Parameter]
    B --> C[Version Catalog]
    B --> D[Resource Assessment]
    D --> E[Run State + Cleanup Plan]
    E --> F{Provider}
    F --> G[Docker]
    F --> H[Podman]
    G --> I[SQL Readiness]
    H --> I
    I --> J[Server Configuration]
    J --> K[Create oder Restore Database]
    K --> L[PostProvision Scripts]
    L --> M[connection-info.json]

Die isolierte Linux-TLS-Kryptomatrix bestand mit beiden echten Clientstacks für Docker und Podman auf den drei genannten SQL-Profilen. Öffentliche Linux-Registry-/Export-/Consumerpfade und die übrige TLS-001-Matrix bleiben getrennt; dieser Testharness ist keine zusätzliche öffentliche Lab-Erstellungsschnittstelle.

Vor jedem Push/Release ist zusätzlich die lokale Readiness-Checkliste sinnvoll:

.\Documentation\Quality\LOCAL_READINESS_CHECKLIST.md

Sie bündelt die empfohlene Reihenfolge für statische und Integration-Checks sowie häufige Umgebungsfehlerursachen.

Statische Konsistenz- und Readiness-Prüfungen:

.\Tests\Static\Invoke-ManifestBuilderChecks.ps1
.\Tests\Static\Invoke-BatchWorkflowChecks.ps1
.\Tests\Static\Invoke-DocumentationChecks.ps1
.\Tests\Static\Invoke-ReadinessContractChecks.ps1
.\Tests\Static\Invoke-MixedProviderLifecycleChecks.ps1
.\Tests\Static\Invoke-ArtifactResolverChecks.ps1
.\Tests\Static\Invoke-SampleHandlerChecks.ps1
.\Tests\Static\Invoke-ProjectAdapterChecks.ps1

Einzelprovider-Smoke-Test:

.\Tests\Integration\Invoke-SmokeTest.ps1 -Provider docker
.\Tests\Integration\Invoke-SmokeTest.ps1 -Provider podman
.\Tests\Integration\Invoke-SmokeTest.ps1 -Provider hyperv
.\Tests\Integration\Invoke-MixedProviderSmokeTest.ps1
.\Tests\Integration\Invoke-RestoreSmokeTest.ps1 -Provider docker
.\Tests\Integration\Invoke-RestoreSmokeTest.ps1 -Provider podman

Aktueller lokaler Validierungsnachweis (2026-08-08):

Invoke-SmokeTest.ps1 -Provider docker   => 33/33 PASS, 0 FAIL
Invoke-SmokeTest.ps1 -Provider podman   => 33/33 PASS, 0 FAIL
Invoke-SmokeTest.ps1 -Provider hyperv   => PASS (Hyper-V-Lifecycle)
Invoke-SmokeMatrix.ps1                 => PASS=5 FAIL=0 SKIP=0

Providerübergreifender Lifecycle-Test für alle lokal erreichbaren Provider mit der SQL-Server-2025-Referenzversion:

.\Tests\Integration\Invoke-SmokeMatrix.ps1

Optionaler Parallelitätsnachweis mit derselben Referenzversion:

.\Tests\Integration\Invoke-SmokeMatrix.ps1 `
    -Provider all `
    -IncludeParallel

SQL_Server_Lab verwendet für seine Runtime-Gates ausschließlich SQL Server 2025. Mehrversions-Abnahmen für 2019/2022/2025 sind Aufgabe der konsumierenden Partnerprojekte SQL Analyze und Toolbelt; der Lab-Core hält dafür weiterhin den katalogbasierten Auflösungspfad bereit.

Nicht erreichbare Provider werden als SKIP ausgewiesen. Erreichbare, aber fehlerhafte Provider führen zu FAIL und Exitcode 1. Details zu Testumfang, Parallelitätsvertrag und Remote Runnern stehen in Tests/README.md.

Für eine reproduzierbare lokale Release-Kopie:

$release = .\Tools\Prepare-LocalRelease.ps1 -CreateArchive -IncludeHashManifest
.\Tools\Prepare-LocalRelease.ps1 -InspectReleaseId $release.ReleaseId

Intent und Abschlussquittung binden die vollständige Veröffentlichung. Die zweite Zeile liest nur: ohne Abschlussquittung INCOMPLETE, bei aktuell passenden vollständigen Bytes COMPLETED. Prozessstatus und Cleanup bleiben getrennt; keine automatische Wiederaufnahme oder Entfernung. Vertrag und Recoverygrenzen.

.ai/             KI-Kontext, Arbeitsregeln und Repo-Map
Adapters/        Project-Adapter-Vertrag und synthetische Beispiele
Catalogs/        SQL-Versionen und Sample-Datenbank-Metadaten
Documentation/   Benutzer-, Architektur-, Qualitäts- und Planungsdokumentation
Private/         interne Modulbausteine
Providers/       Docker, Podman und Hyper-V-Lifecycle
Public/          exportierte Cmdlets
Schemas/         JSON-Schemas und ausführbare Beispiele
Tests/           statische Prüfungen sowie Lifecycle-, Matrix- und Paralleltests
_QuellRepo/      unveränderte Quell-Snapshots anderer Repositories

Der ausdrücklich benannte KI-Einstieg ist AGENTS.md. Er führt über Projektkontext und Repository-Map zu den jeweils betroffenen Fachverträgen. Diese Steuerungsdateien ersetzen keine Produktreferenz und keinen Laufzeitnachweis.

• Documentation/User und Documentation/HowTo erklären Einrichtung und Bedienung.
• Documentation/Architecture, Documentation/Standards, Public und Schemas enthalten gemeinsame technische Quellen für Menschen und Werkzeuge.
• Documentation/Project_Planning beschreibt Vorhaben; Documentation/Quality trennt aktuelle Prüfregeln und Grenzen von datierten Abnahmen.
• .ai und die Root-AGENTS.md dienen der KI-Steuerung und Quellenauswahl.

Ein technischer Prüfweg führt beispielsweise von der Repository-Map zum Manifestvertrag, Schema und Parser. Die Validierungsstrategie benennt ausgeführte Prüfungen und fehlende Providerbelege. Die Exportliste im Modulmanifest ist die Quelle der öffentlichen API; Tabellen in der Dokumentation sind geprüfte Ansichten dieser Quelle.

Die Foundation-Provenienz bindet importierte Regeln an ihre Quelle. Sie ist kein SQL- oder Lesbarkeitsnachweis; die semantische Upgradebewertung erklärt Auswahl, Projektverschärfungen und verbleibende Dokumentationsarbeit. Reale Runtime-States und vertrauliche Evidence bleiben außerhalb Git.

• End-to-End-Testumgebung für Windows/Linux 2019–2025 und CMS
• Konsolidierter Entwicklungs- und Ausführungsplan
• Konsolen-, Lifecycle- und Storage-Konsolidierungsplan aus der manuellen Abnahme
• Providerneutraler Batch-, Queue- und Resume-Workflow
• Getting Started
• Dokumentationsübersicht
• Bekannte Grenzen
• Manifest-Schemas und Beispiele
• Lab_Data und native Runtime-Speicher
• Testdatenbank-Provisionierung und menügeführte Manifest-Erstellung
• Gemischter Container-Provider-Lifecycle
• Hyper-V-, Image-, Provisionierungs- und Netzwerkvertrag
• Vorlagenpool und automatisierte Manifeste
• Öffentliche Cmdlets
• Project Adapter
• Provider
• Tests
• Podman unter Windows
• KI-Projektkontext
• Maschinenlesbare Repo-Map
• Beitragsregeln

Lab-Provisionierung bleibt lokal beziehungsweise auf ausdrücklich dafür vorgesehenen Self-hosted Runnern. Runtime-Workflows verwenden die Labels SQL_Lab plus Docker oder Podman; generische Self-hosted Runner werden nicht verwendet. GitHub-hosted Runner sind nur für nicht mutierende, hostunabhängige Prüfungen vorgesehen.

SQL Server 2025 CU9 kann unter rootful Docker und Podman ausdrücklich mit shared-user-v2-Varianten ausgewählt werden. Dabei entfallen Launchpad-Sandbox- und Worker-Isolation; der isolierte cgroup-v1-Modus bleibt Standard. Auswahl, Voraussetzungen und Nachweisgrenzen.

Nach Container-Stop wird auf Windows auch die Hostspeicherreserve geprüft. Eine begrenzte WSL-Dateicachefreigabe unter Speicherdruck und das getrennte Ergebnis HostMemory verhindern, dass ein gestopptes Lab automatisch als vollständig freigegebener Host-RAM dargestellt wird. Verhalten und Opt-out.

Lokale alternative Bezugsadressen für genau die drei SQL-2025-Bootstrapper werden im Ressourcenbereich von CLI und Browser mit Vorschau, Herkunft und Reset verwaltet. Größe, Hash und Microsoft-Signatur bleiben unverändert; Speichern lädt keine Medien. Bedienung und Grenzen.

Ressourcen bietet einen ausdrücklichen Metadatenvergleich für CUs und genau die katalogisierte SqlPackage-Variante. Die Bedienung und Statusgrenzen stehen in Workflow UI. Menüwechsel greifen nicht auf die Quellen zu. Sitzungscache und Quellenfehler sind sichtbar; neue Metadaten ändern keine Download- oder Supportfreigabe. Die bestehende Monatslane bietet zusätzlich einen manuellen Metadatendispatch ohne Issueveröffentlichung. Dieser eigene Job besitzt keine Issuerechte und verwendet den vollständigen vorhandenen Quellencheck; Standardlauf und Cron bleiben erhalten. Vertrag und Abnahmegrenzen.

Der Bereich „Host-Dienste und Modelle“ bietet den geführten Stop einer eigenen llama.cpp-Sitzung mit Vorschau und bewusster Bestätigung. Verbraucher-Coverage bleibt UNKNOWN; Fremdprozesse und Modell-Lifecycle bleiben offen. Siehe Vertrag.

Im CLI-Menü CMS-Verwaltung und im Browserbereich Verbindungen gibt es eine ausdrückliche lesende Prüfung des bereits registrierten CMS. Sie zeigt Zeitpunkt, SQL-Major und Anzahlen markierter Gruppen/Server. Registrierung lesen und Abbruch öffnen keine SQL-Verbindung; unbekannte Ergebnisse sind keine erfolgreichen Null-Zähler. Einrichtung, Synchronisation, SSMS und Mitgliedsverbindungen bleiben getrennt. Siehe CMS-Prüfvertrag.