dtcSoftware - powerShellDba

📌 Grundlagen: Aufbau eines Connection Strings

ÜBERBLICK

Ein Connection String ist eine semikolongetrennte Liste von Schlüssel-Wert-Paaren, die einer Anwendung mitteilt, wie sie eine Verbindung zu einer SQL Server-Instanz herstellen soll. Die wichtigsten Bestandteile sind:

Server (oder Data Source) – Name/IP der SQL Server-Instanz (ggf. mit Instanzname, Port)
Database (oder Initial Catalog) – Name der Zieldatenbank
Authentication – Windows- oder SQL Server-Authentifizierung
User ID / Password – bei SQL‑Auth
Trusted_Connection / Integrated Security – für Windows‑Auth
Optionale Parameter – Timeout, MARS, Verschlüsselung, MultiSubnetFailover u. v. m.

💡 Tipp: Verwenden Sie für .NET-Anwendungen den SqlConnectionStringBuilder, um syntaktisch korrekte Strings zu erzeugen. Für andere Sprachen gibt es analoge Hilfsmittel.

🪟 Windows-Authentifizierung (Integrated Security)

BEWÄHRT

Die Windows-Authentifizierung nutzt das aktuelle Windows-Benutzerkonto (oder das Dienstkonto) für die Anmeldung am SQL Server. Dies ist die sicherste Methode, da keine Passwörter im Connection String stehen.

// Standard – lokale Standardinstanz
Server=localhost;Database=MeineDB;Trusted_Connection=True;

// Mit Instanzname (z. B. SQLExpress)
Server=localhost\SQLEXPRESS;Database=MeineDB;Trusted_Connection=True;

// Mit explizitem Servername und Domain
Server=SRV-DB01;Database=MeineDB;Integrated Security=SSPI;

// Mit IP-Adresse und Port (Standardport 1433)
Server=192.168.1.100,1433;Database=MeineDB;Integrated Security=True;

📌 Hinweis: Trusted_Connection=True, Integrated Security=True und Integrated Security=SSPI sind synonym. Nutzen Sie, was Ihre Bibliothek unterstützt.

🔐 SQL Server-Authentifizierung (Login/Passwort)

KLASSISCH

Bei der SQL‑Auth müssen Sie Benutzername und Passwort im Connection String angeben. Diese Methode wird häufig für Webanwendungen oder wenn keine Windows-Domäne vorhanden ist, verwendet. Achtung: Das Passwort sollte idealerweise aus einer Konfigurationsdatei ausgelagert oder verschlüsselt werden.

// Standardinstanz mit SQL-Login
Server=localhost;Database=MeineDB;User Id=meinBenutzer;Password=geheim;

// Mit Instanzname und festem Port
Server=localhost\SQLEXPRESS,1433;Database=MeineDB;User ID=sa;Password=123456;

// Alternativ mit "Initial Catalog" statt "Database"
Data Source=SRV-DB02;Initial Catalog=MeineDB;Persist Security Info=False;User ID=appuser;Password=passwort;

// Mit Erzwingen der SQL-Auth (selten nötig)
Server=myServer;Database=myDB;User Id=myUser;Password=myPass;Authentication=SqlPassword;

🚨 Sicherheitshinweis: Vermeiden Sie die Verwendung des sa-Kontos in Produktionsumgebungen. Legen Sie eigene Benutzer mit minimalen Rechten an.

☁️ Azure SQL Database & Azure SQL Managed Instance

CLOUD

Für Azure SQL benötigen Sie den vollqualifizierten Servernamen (z. B. server.database.windows.net), oft den Port 1433, sowie spezielle Optionen wie Encrypt=True und TrustServerCertificate=False (Standard seit 2024).

// Azure SQL Database (SQL‑Authentifizierung)
Server=tcp:meinServer.database.windows.net,1433;Database=meineDB;User ID=meinBenutzer;Password=geheim;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;

// Mit Active Directory Integrated (Windows-Föderation)
Server=tcp:meinServer.database.windows.net,1433;Database=meineDB;Authentication=Active Directory Integrated;Encrypt=True;

// Mit Active Directory Password
Server=tcp:meinServer.database.windows.net,1433;Database=meineDB;Authentication=Active Directory Password;User ID=Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.;Password=passwort;Encrypt=True;

💡 Azure-spezifische Optionen: Encrypt=True ist obligatorisch. TrustServerCertificate=False stellt sicher, dass das Serverzertifikat überprüft wird. Für Managed Instance reicht oft der Servername ohne .database.windows.net.

🔄 Always On & MultiSubnetFailover

HOCHVERFÜGBARKEIT

Wenn Sie eine Verbindung zu einem Availability Group Listener herstellen, müssen Sie MultiSubnetFailover=True setzen. Diese Option beschleunigt die Failover-Erkennung erheblich und ist für .NET Framework 4.6.1+ empfohlen.

// Verbindung zu einem AG-Listener (Windows‑Auth)
Server=AGListener,1433;Database=meineDB;Trusted_Connection=True;MultiSubnetFailover=True;

// Mit SQL‑Auth und zusätzlichem Timeout
Server=AGListener;Database=meineDB;User ID=myUser;Password=secret;MultiSubnetFailover=True;Connection Timeout=10;

📌 Best Practice: Setzen Sie MultiSubnetFailover=True immer dann, wenn Sie einen Listener ansprechen – unabhängig davon, ob sich die Replikate im selben Subnetz befinden. Für einzelne Instanzen (kein AG) ist dieser Parameter nicht nötig.

🔄 MARS – Mehrere aktive Resultsets auf einer Verbindung

ADVANCED

MARS erlaubt es einer Anwendung, mehrere Abfragen gleichzeitig auf einer einzigen Datenbankverbindung auszuführen, ohne dass die Resultsets nacheinander abgearbeitet werden müssen. Insbesondere für ORMs wie Entity Framework ist MARS oft nützlich.

// MARS aktivieren
Server=localhost;Database=meineDB;Trusted_Connection=True;MultipleActiveResultSets=True;

// Mit SQL‑Auth und MARS
Server=myServer;Database=myDB;User ID=myUser;Password=passwort;MultipleActiveResultSets=True;

💡 Hinweis: MARS kann die Performance beeinflussen. Nutzen Sie es nur, wenn Ihr Anwendungsmodell parallele Resultsets benötigt. Bei sorgfältigem Design sind oft separate Verbindungen die bessere Wahl.

⏱️ Connection Timeout & Command Timeout

ZEITLIMITE

Mit Connection Timeout (oder Connect Timeout) steuern Sie, wie viele Sekunden die Anwendung auf eine erfolgreiche Verbindung warten soll, bevor ein Fehler ausgelöst wird. Der Standard ist 15 Sekunden. Das Command Timeout wird separat im Code gesetzt (z. B. SqlCommand.CommandTimeout).

// Connection Timeout auf 30 Sekunden erhöhen
Server=myServer;Database=myDB;Trusted_Connection=True;Connection Timeout=30;

// Kurzes Timeout für schnelle Fehlermeldungen
Server=slowServer;Database=myDB;User ID=user;Password=pw;Connect Timeout=3;

🧠 Praxis: Ein zu niedriges Connection Timeout führt zu unnötigen Fehlern, besonders bei Lastspitzen oder Netzwerklatenz. Ein zu hohes Timeout blockiert die Anwendung. 15–30 Sekunden sind ein guter Kompromiss.

🔒 Verschlüsselung – Encrypt & TrustServerCertificate

SICHERHEIT

Seit neueren Treibern ist die Verschlüsselung der Verbindung stark empfohlen. Encrypt=True erzwingt TLS-Verschlüsselung. TrustServerCertificate=True akzeptiert selbstsignierte Zertifikate (nur für Testumgebungen!).

// Standardverschlüsselung (erfordert gültiges Zertifikat auf dem Server)
Server=myServer;Database=myDB;Trusted_Connection=True;Encrypt=True;

// Für Testumgebungen mit selbstsigniertem Zertifikat
Server=myServer;Database=myDB;User ID=user;Password=pw;Encrypt=True;TrustServerCertificate=True;

💡 Best Practice: In Produktionsumgebungen setzen Sie Encrypt=True und TrustServerCertificate=False (letzteres ist bei vielen Treibern der Standard). Installieren Sie ein vertrauenswürdiges Zertifikat auf dem SQL Server.

⚙️ Weitere nützliche Connection String Parameter

OPTIONAL

Application Name – Identifiziert Ihre Anwendung im SQL Server (z. B. für Monitoring)
Pooling – Aktiviert/Deaktiviert Verbindungspooling (Pooling=True ist Standard)
Min Pool Size / Max Pool Size – Größe des Verbindungspools
Load Balance Timeout – Timeout für Failover-Partner
Failover Partner – Für Datenbankspiegelung (veraltet, besser AG)
Packet Size – Netzwerkpaketgröße (Standard 8000)
Enlist – Automatisches Eintragen in verteilte Transaktionen (Standard true)

// Beispiel mit vielen optionalen Parametern
Server=myServer;Database=myDB;Trusted_Connection=True;
Application Name=MeineApp;Pooling=True;Max Pool Size=100;Min Pool Size=5;
Connect Timeout=15;Encrypt=True;Packet Size=4096;

📊 Monitoring-Tipp: Setzen Sie Application Name, damit Sie in sys.dm_exec_sessions sofort erkennen, welche App die Verbindung aufgebaut hat.

🌐 Treiber-spezifische Syntax

ODBC, OLEDB, .NET

Die oben gezeigten Strings gelten primär für den .NET Framework SqlClient (und Microsoft.Data.SqlClient). Andere Treiber verwenden leicht abweichende Schlüssel.

ODBC

Driver={ODBC Driver 17 for SQL Server};Server=myServer;Database=myDB;Trusted_Connection=yes;

OLE DB (veraltet, aber noch genutzt)

Provider=SQLOLEDB;Data Source=myServer;Initial Catalog=myDB;Integrated Security=SSPI;

JDBC (für Java)

jdbc:sqlserver://myServer:1433;databaseName=myDB;integratedSecurity=true;

💡 Empfehlung: Nutzen Sie wenn möglich den aktuellen Microsoft.Data.SqlClient (.NET) oder den ODBC Driver 17/18 für plattformübergreifende Anwendungen.

⚠️ Typische Connection-String-Probleme

FEHLERSUCHE

„Login failed for user“ → Prüfen Sie Benutzername/Passwort und ob der SQL Server die gewählte Authentifizierungsmethode erlaubt (Windows vs. SQL).
„Network related or instance-specific error“ → SQL Server ist nicht erreichbar. Kontrollieren Sie Servername, Instanzname, Port, Firewall, ob der Dienst läuft.
„Certificate chain issued by untrusted authority“ → Setzen Sie TrustServerCertificate=True (nur Test) oder installieren Sie ein gültiges Zertifikat.
„Timeout expired“ → Erhöhen Sie Connection Timeout oder optimieren Sie die Abfrage / Netzwerk.
„MultiSubnetFailover not supported“ → Verwenden Sie einen neueren Treiber (z. B. Microsoft.Data.SqlClient).

🛠️ Hilfreiche Tools: Der UDL-Test (leere Textdatei in .udl umbenennen) testet OLEDB-Verbindungen. Mit sqlcmd oder SSMS prüfen Sie grundsätzlich die Erreichbarkeit.

📋 Cheat Sheet – Die wichtigsten Connection Strings auf einen Blick

SCHNELLREFERENZ

Windows-Authentifizierung (Default-Instanz)

Server=localhost;Database=myDB;Trusted_Connection=True;

Windows-Authentifizierung (Named Instance)

Server=localhost\SQLEXPRESS;Database=myDB;Integrated Security=True;

SQL-Authentifizierung

Server=myServer;Database=myDB;User Id=myUser;Password=myPass;

Azure SQL Database

Server=tcp:server.database.windows.net,1433;Database=myDB;User ID=user;Password=pw;Encrypt=True;

Always On AG (Listener)

Server=AGListener;Database=myDB;Trusted_Connection=True;MultiSubnetFailover=True;

MARS aktivieren

Server=myServer;Database=myDB;Trusted_Connection=True;MultipleActiveResultSets=True;

📎 Zum Speichern: Diese Übersicht können Sie als Cheat Sheet ausdrucken oder in Ihre Dokumentation übernehmen. Passen Sie die Platzhalter (Server, Datenbank, Benutzer) individuell an.