SQL2K und XP-Pro-Client

[mailfriend67 10]

Hallo,

habe da mal ein Problem mit meinem SQL-Server und den XP-Clients. Für eine C/S-Anwendung wird über einen System-DN eine Datenbank abgefragt. Diese Kommunikation läuft mit den Client von XP extrem langsam. Hat jemand einen Tipp, speziell da die Windows 2000 Clients das Problem nicht haben.

 

Danke!

 

Ralf

[auer 10]

Möglichkeiten:

 

1. Der Sql-Server ist eine MSDE und bremst ab der sechsten Verbindung - dann wäre ab dem sechsten Client alles langsam, unabhängig vom OS.

 

2. Überprüfe auf XP versus W2K per ClicConfg die Netzwerkbibliotheken. Ist die Verschlüsselung unter XP aktiv?

 

3. Handelt es sich um ein Problem auf der IP-Ebene? Ping-Zeiten zwischen verschiedenen Clients vergleichen.

 

4. Läuft die Anmeldung am Sql-Server über die NT-Authentifizierung oder über die Sql-Server-Version? Falls über die NT: Vergleiche die Zugriffszeit auf eine Dummyfreigabe über net use \\SqlServer von den verschiedenen Clients bzw. richte einen Sql-Server-Nutzer ein und vergleiche mit diesem. Muß die Anmeldung für die XP-Clients erst über eine Domain gelenkt werden?

 

---------

Gruß, Auer

[mailfriend67 10]

Hallo,

herzlichen Dank zunächst für die Tipps, die ich leider erst am Freitag testen kann.

Würde mich dann nochmals melden.

Gruß

Ralf

[mailfriend67 10]

Hallo,

 

@Auer:

habe Deine Tipps mal geprüft. Vorab zur Konfiguration.

Es handelt sich um einen SQL2000 Server unter Windows2000 in der Ausführung als SBS-Edition.

Damit ist der Punkt 1 auszuschließen.

Zum Punkt 2: Was meinst Du mit "ClicConfg"? Habe jedenfalls kein Einstellungen hinsichtlich Verschlüsselung bei der Installation der Clients gemacht. Letztlich läuft die Anmeldung an der entsprechenden Domäne ohne Probleme (PDC ist ja auch der gleiche Server).

Zum Punkt 3: Alle pings unter 1ms. Auch größere ping-Pakete ohne Probleme!

Zum Punkt 4: Der SQL-Server läuft im gemischten Modus, also Anmeldung sowohl über SQL-Konto wie NT-Authentifizierung.

Test hinsichtlicht Zeit habe ich noch nicht gemacht.

 

Hat jemand weitere Ideen?

 

Gruß

Ralf

[auer 10]

Zunächst hat da der Schreibfehlerteufel zugeschlagen - gemeint war die CliConfg. Dieser Befehl, in eine Dosbox eingegeben, startet das 'SqlServer Client Network Utility' zur Konfiguration der Clienteinstellungen. Dort gibt es - wenn ich richtig weiß, neu unter XP - den Punkt 'Force Protocol encryption', das müßte Ressourcen schlucken. Prüfe, ob beide Clienttypen dasselbe Protokoll als Standard verwenden (meist TCP oder NamedPipes), falls dieses nicht in der DSN festgelegt worden ist.

 

Vielleicht gibt es irgendwelche zusätzlichen Einträge, die sich unter XP auswirken. Beiliegend ein Script:

 

Dim conn, t

Set conn = WScript.CreateObject("Adodb.Connection")

conn.Provider = "SQLOLEDB"

'In der folgenden Zeile die korrekten Werte eintragen [edit]

conn.Open "Server=192.168.120.254;Trusted_Connection=Yes;"

With conn.Properties

For i = 0 To .Count - 1

t = .Item(i).Name & Chr(9)

On Error Resume Next

t = t & .Item(i).Value

On Error goto 0

WScript.Echo t

Next

End With

conn.Close()

 

Speichere dies in eine Datei conn-test.vbs und führe es mit

cscript conn-test.vbs > ergebnis.txt

aus. Dann steht der Output, nämlich alle Verbindungsparameter, in der Datei ergebnis.txt. Vergleiche dann (bsp. beide Tabellen nach Excel laden und die Spalten nebeneinander verschieben), ob es irgendwelche Unterschiede in den Parameterbelegungen gibt.

 

Taucht das Problem nur bei der Datenabfrage auf, so daß es sich vielleicht um ein clientseitiges Verarbeitungsproblem handelt? Schreibe irgendeine mehr oder weniger sinnvolle stored Proc, die viel unschädliche Serveraction produziert, lange läuft, aber keine Daten zurückgibt, starte dieses von verschiedenen Clients und stoppe die Zeit. Gibt es bei rein serverseitigen Aktivitäten keine Unterschiede, so dürfte es sich eher um ein rein clientseitiges Problem handeln, daß Daten bsp. unsinnig abgerufen werden. Dann allerdings wäre es ein spezielles Problem von diesem Programm.

 

----------

Gruß, Auer

[mailfriend67 10]

Hallo,

 

die Ursache des Problems konnte ich ermitteln.

Sobald das Virentool Bitdefender komplett deaktivier war, lief die Kommunikation ohne Probleme. Werde wohl ein anderes Antivirentool einsetzen müssen.

Hatte natürlich vorher die anderen Dinge versucht.

@Auer: vielen Dank für die Tipps.

Wo kann man sich denn noch ein paar weitere Tricks zu SQL ablauschen.

 

Gruß und schönen Tag

Ralf

[auer 10]

BitDefender hat vielleicht die Option, Ports zu überwachen. Eventuell genügt es, den TCP-1433 für MSSQL freizugeben. Und wenn ein Online-Virenscanner aktiv ist, so müßte der entsprechende Cache-Bereich des Clientprogramms vom Scannen ausgenommen werden.

 

--------------

Gruß, Auer