Verbindungszeichenfolge optimieren

Question

Hallo,
Ich würde gerne den Verbindungsaufbau meines Visual C# Programms, das auf eine SQL Server 2005 Datenbank zugreift, optimieren.

Die Produktivdatenbank liegt auf einem Server, während die Datenbank der Testumgebung lokal vorhanden ist.

Ist es möglich, die Zeitdauer des Verbindungsaufbaus zu verkürzen?

Folgende Verbindungszeichenfolgen wurden gewählt:

1. DB auf Server
Server=agfa_b6.witg.pri\winadmin;
Database=winadmin;
Trusted_Connection=yes;
Connect Timeout=99;
User ID=TestDB;
Password=abc;

2. DB lokal
Data Source=.\SQLEXPRESS;
AttachDbFilename=D:\WinAdmin\DB_Test\WinAdmin.mdf;
Integrated Security=True;
Connect Timeout=99;
User Instance=True;
User ID=TestDB;
Password=abc;


Herzliche Grüße und Danke für eure Antworten.

Answer 1

Servus Walter,

Ist es möglich, die Zeitdauer des Verbindungsaufbaus zu verkürzen?

Du solltest dich mal in Connection Pooling (ADO.NET) einlesen...

---

Microsoft MVP Office Access
https://mvp.support.microsoft.com/profile/Stefan.Hoffmann

Answer 2

Hallo Stefan,

Danke für den Hinweis.

Gruß Walter

Answer 3

Ist es möglich, die Zeitdauer des Verbindungsaufbaus zu verkürzen?

Hallo Walter,

was genau meinst Du damit und was dauert zu lange?

Bei 2. DB lokal wird eine User Instance verwendet, d.h. bei jedem Verbindungsaufbau wird die MDF in einer User Instanz geladen, das kann schon mal etwas dauern. Du könntest die Datenbank stattdessen in den laufenden SQL Server Express Instanz anhängen und sie so belassen. Dann kann Du für 2. den gleichen Connection String wie für 1. verwenden, nur das "Server" natürlich geändert werden muss.

P.S.: In beiden Connection String verwendest Du "Trusted_Connection=YES" (identisch zu "Integrated Security=True"), also läuft die Anmeldung über den Windows Account und somit werden user Id & Pwd ignoriert; die kannst Du also weg lassen.

 

---

Olaf Helper
* cogito ergo sum * errare humanum est * quote erat demonstrandum *
Wenn ich denke, ist das ein Fehler und das beweise ich täglich
Blog Xing

Answer 4

Hallo,

das sind zwei vollständig unterschiedliche Betriebsmodi:

1. das verbinden mit einer Dienstinstanz
2. das Erstellen einer Benutzer Instanz

Bei 1.) sollte ein Connection Timeout unter 15 Sekunden realisierbar sein.
Wenn nicht ist die Netzwerkverbindung zu träge (was nur in WANs / VLAN passieren sollte).

Bei 2.) Erstellen einer Benutzerinstanz wird für den Benutzer ein separater Prozess gestartet,
was naturgemäss beim Erst-/Kaltstart einige Zeit dauern kann, siehe Link oben zu Lebendauer ff.

Beide Verbindungszeichenfolgen sind widersprüchlich, was die Art der Authentifizierung angeht.
Integrated Security=True bedeutet, dass sich mit dem Windows Kontonamen angemeldet werden soll,
Die Angabe von User ID und Password nutzt die Standardsicherheit - und Integrated Security sollte
fehlen bzw. auf False gesetzt sein.

Vorrang hat hier die integrierte Sicherheit, siehe Syntax für Verbindungszeichenfolgen (ADO.NET)
Ergo lass die UserID/Pasword gleich weg.

Das bereits von Stefan angesprochen Connection Pooling ist im Standard aktiviert, siehe
http://msdn.microsoft.com/de-de/library/system.data.sqlclient.sqlconnection.connectionstring.aspx
(bitte auch die englischen Texte anschauen, da einige Übersetzungfehler, so ist ja/nein nicht zulässig)

Gruß Elmar

Answer 5

Hallo Olaf,

Wie würdest du die Verbindung für 2. aufbauen?

Welche Art von Authentifizierung ist sinnvoller? SQL oder Windows? Gibt es Erfahrungswerte?

 

Gruß Walter

 

Answer 6

HAllo Walter,

der SQL Server Express lokal wird ja vermutlich laufen. Also einfach die MDF ins DATA Verzeichnis verschieben/kopieren und übers Management Studio anhängen; siehe Technet Anfügen einer Datenbank. Dann kannst Du, vom Servernamen abgesehen, einen identischen ConnectionString verwenden.

"Sinnvoll" sind beide Authentifizierungsarten, sonst gebe es nicht beide. Die Windows Authentifizierung wird bevorzug verwendet, wenn alle Benutzer, die auf dem SQL Server zugreifen dürfen sollen, in der eigenen Domäne sind. Zudem kann die Verwendung von AD Gruppen die Administration vereinfachen.

SQL Authentifizierung wird dann verwendet, wenn auch User von ausserhalb der Domäne zugreifen dürfen oder man keine Domäne hat (nur Workgroup). Birgt halt die Gefahr, das solche Benutzernamen und Passwort weitergegeben werden könnten.

---

Olaf Helper
* cogito ergo sum * errare humanum est * quote erat demonstrandum *
Wenn ich denke, ist das ein Fehler und das beweise ich täglich
Blog Xing

Answer 7

Hallo Walter,

haben die Tipps hier weitergeholfen?

Gruss,
Raul