Wenn das Produktivsystem Dein Testsystem ist

Dann brauchst Du keine Lasttests –
die Kunden übernehmen das für Dich.
Mit echten Daten. Mit echten Konsequenzen.

Ein einzelnes UPDATE kann reichen, um Wochenarbeit zu zerstören.
Oder ein neuer Report, der mal eben 1 Million Zeilen scannt – mitten im Tagesgeschäft.

Was produktives Testen wirklich bedeutet

• Kein Rollback möglich
• Kein Vergleich zwischen alt und neu
• Keine isolierte Fehleranalyse
• Kein belastbarer Performance-Test
• Stress für alle Beteiligten

„Hat bei mir in der Entwicklungsdatenbank funktioniert“ ist kein Freifahrtschein.

Was ein Staging-System leisten muss

• Gleiche Struktur wie Produktion
• Ähnliche Daten (aber anonymisiert)
• Automatisiert aktualisiert
• Klar getrennt (optisch + technisch)
• Sicher gegen versehentliches Verbinden von externen Tools

Beispiel: Kopie einer SQL Server-Datenbank als Staging

-- Restore mit neuem Namen
RESTORE DATABASE MeineDatenbank_Staging
FROM DISK = 'D:\Backups\MeineDatenbank_FULL.bak'
WITH MOVE 'MeineDatenbank' TO 'D:\SQLData\MeineDatenbank_Staging.mdf',
     MOVE 'MeineDatenbank_log' TO 'D:\SQLData\MeineDatenbank_Staging.ldf',
     REPLACE;

Danach:

-- Umbenennen zur besseren Erkennbarkeit
ALTER DATABASE MeineDatenbank_Staging SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE MeineDatenbank_Staging MODIFY NAME = MeineDatenbank_Staging;
ALTER DATABASE MeineDatenbank_Staging SET MULTI_USER;

Option: Nur ausgewählte Daten übernehmen

Große Tabellen müssen nicht 1:1 rüber.
Für viele Tests reicht ein Auszug.

-- Nur die letzten 3 Monate kopieren
SELECT *
INTO Staging.dbo.Bestellungen
FROM Prod.dbo.Bestellungen
WHERE Bestelldatum >= DATEADD(MONTH, -3, GETDATE());

Dazu eigene Staging-Skripte pro Umgebung.
Keine Einmal-Aktion – ein fester Prozess.

Beispiel: Automatisierung per SQL Agent Job

-- Wöchentliches Refresh der Staging-Tabellen
EXEC dbo.Refresh_StagingDaten;

-- In Refresh_StagingDaten
TRUNCATE TABLE Staging.dbo.Kunden;

INSERT INTO Staging.dbo.Kunden (KundenID, Name, PLZ)
SELECT KundenID, LEFT(Name, 1) + '***', PLZ
FROM Prod.dbo.Kunden;

So hast Du Testdaten, aber keine Datenschutzprobleme.

Visualisierung: Staging ist nicht Produktion

Ich ändere die Oberfläche bewusst:

• roter Hintergrund in Formularen
• fetter Hinweis im Menüband
• separate Datenbanknamen (_STAGE)
• ODBC-Verbindungen in separaten DSNs

Das verhindert versehentliche Änderungen.
Gerade bei Access-Frontends oder Power BI wichtig.

Tabelle: Produktion vs. Staging

Merkmal	Produktion	Staging
Daten	Echt	Kopie, anonymisiert
Umgebung	Stabil	Flexibel
Risiko	Hoch	Kein Risiko
Monitoring aktiv	Ja	Optional
Performance-Messung	Verfälscht durch Nutzer	Realistisch möglich

Mein Setup für KMU

Ebene	Werkzeug
Datenbank	SQL Server mit nightly Restore
Schnittstellen	Kopien mit dedizierten Endpunkten
Frontend	Access / Web mit Dev-DSNs
Automatisierung	SQL Agent + Powershell
Tests	per Datenvergleich + Logging

Norddeutsch zum Schluss

Wer in Produktion testet, testet auch seine Nerven.
Und die Geduld der Buchhaltung.

Richte Dir ein Staging-System ein.
Dann kannst Du Fehler machen – bevor sie jemand merkt.