Hallo Joachim,
wie bekommt man die Info auf wieviele Lizenzen die DB l�uft?

MfG
Zeljko

-----Urspr�ngliche Nachricht-----
Von: Joachim van de Bruck [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 23. Juli 2003 13:52
An: [EMAIL PROTECTED]
Betreff: AW: [Database.asp] AW: SQL-Server Leistungsprobleme analysieren


Hallo!

> > Ja, aber wenn die Abfrage bei wenigen Benutzern nur 10 ms ben�tigt,
> > liegt es ganz bestimmt nicht an den Indexen, oder?
> 
> Bei 4 GB RAM kann es schon sein, weil der SQL Server ja die 
> Abfragen cacht.

Also je mehr User, desto schneller???

> > Das erkl�rt aber nicht die "Performance-Steigerung". Wenn 
> > Abfragen, die
> > sonst 10 ms dauern, bei steigenden Benutzerzahlen dann bis 
> > zu 5600 ms
> > ben�tigen, riecht das eher nach einem Lizenzproblem, zumal 
> > ja "nur" mit
> > ADO und nicht mit komplexen Stored Procedures zugegriffen wird.
> 
> Wie kommst Du auf das Lizenzproblem?

Wegen "SQL Server 2000 Standard". Der SQL Server arbeitet mit Threads.
Bei 25 Client-Lizenzen k�nnen also 25 Threads gleichzeitig bearbeitet
werden. Das reicht sicherlich f�r 500 Benutzer einer Website v�llig aus.
Wenn zu viele Clients auf den SQL Server zugreifen, geht der SQL Server
per Programm in die Knie, auch wenn gen�gend Prozessorkapazit�t
vorhanden ist. Aus diesem Grunde gibt es ja auch seit SQL Server 2000
eine Website-Lizenz, oder?

Wenn das Problem allein durch Indizes verursacht wird, dann d�rften die
Abfragen auch bei einem Benutzer recht langsam sein. Da hier jeder
Benutzer seine eigenen Daten bearbeitet, gehe ich mal davon aus, dass
zumindest die BenutzerID indiziert ist, und das Cachen nichts n�tzt.
Schlechtes Design und unsachgem��er Einsatz von ADO (falsche oder nicht
sachgerechte Cursor, pessimistic Locking, ...) w�rden die Leistung mit
steigender Benutzerzahl kontinuierlich abnehmen lassen.

Hoffentlich ist es also ein Lizenzproblem (sehr schnell zu l�sen!). Alle
Abfragen auf Firehose-Cursor-Recordsets und alle Modifikationen auf
Commands umstellen ist ja etwas aufwendig, oder?

Freundliche Gr��e
Joachim van de Bruck



_______________________________________________
Database.asp mailing list
[EMAIL PROTECTED]
http://www.glengamoi.com/mailman/listinfo/database.asp
_______________________________________________
Database.asp mailing list
[EMAIL PROTECTED]
http://www.glengamoi.com/mailman/listinfo/database.asp

Antwort per Email an