Jump to content
Sign in to follow this  
mailfriend67

SQL2K und XP-Pro-Client

Recommended Posts

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

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte überlege Dir, ob es nicht sinnvoller ist ein neues Thema zu erstellen.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

Werbepartner:



×
×
  • Create New...