Hallo Jutta und Michel, vielen Dank f�r Eure R�ckmeldungen. Ich hoffe mal sehr, dass es daran liegt.
Ja, es greifen recht viele User gleichzeitig auf die Datenbank zu - und es scheint so, als w�rden nicht alle Tabellen aufh�ngen. Manche Abfragen klappen n�mlich (das sind ganz einfache Abfragen). W�hrend andere sich irgendwann aufh�ngen. > Eine weitere M�glichkeit, die ich noch sehe, sind offen gebliebene > Transaktionen (z.b. vergessenen COMMITS) Mmmh, "COMMITS" kenne ich gar nicht ;-) Wird daher auch nicht in den SPs verwendet. Das kann es also nicht sein. > Das kann auch passieren, wenn der Parameter 'IMPLICIT_TRANSACTIONS' auf 'ON' steht Den Parameter habe ich auch nirgends verwendet. > Sperreninformationen kannst Du im Query-Analyzer mit der > Prozedur 'sp_lock' ausgeben lassen. Das habe ich mal ausprobiert (allerdings habe ich den SQL vor ca. 1 Stunde restartet). Im "Raster" werden mir einige Werte angezeigt. Aber da blicke ich jetzt nicht durch. Was sagt mir das? Bzw. bei was sollte ich alarmiert sein? Viele Gr��e, Patrick -----Urspr�ngliche Nachricht----- Von: Michael Busch [mailto:michael@;sqlklinik.de] Gesendet: Freitag, 18. Oktober 2002 08:42 An: ASP Datenbankprogrammierung Betreff: [aspdedatabase] AW: Re: AW: Probleme mit SQL2000-Server Hallo Patrick, da stimme ich der Jutta uneingeschr�nkt zu. Zur Erl�uterung: In der Grundversion von SQL Server 2000 ist ein Bug im Abfrageoptimierer, welcher dazu f�hrt, das die Erstellung von Abfragepl�nen teils ewig lange dauert und sich verheerend auf die Performance auswirkt. Im SP1 ist diese Bug behoben. Im Releasestand des SP1 tritt allerdings auch noch ein recht fieser Bug in der Sperrenverwaltung auf, welcher dazu f�hrt, dass ein Row-Level Locking so gut wie nie verwendet wurde und statt dessen ein Table-Locking verwendet wird. Wenn mehrere Leute gleichzeitig auf dem Server arbeiten, was ja die Regel ist, tut sich da nach kurzer Zeit gar nichts mehr. Im SP2 ist das auch behoben. Also: Auf jeden Fall auf SP2 upgraden, dann sind die meisten Probleme behoben. Eine weitere M�glichkeit, die ich noch sehe, sind offen gebliebene Transaktionen (z.b. vergessenen COMMITS), welche Sperren auf der Datenbank halten. Das erkl�rt dann ebenefalls, warum anfangs noch alles OK ist und die Maschine sp�ter "zusammenbricht". Wenn Du Transaktionen in Deinen SPs verwendest, dann kannst Du den Transaktionsz�hler mit der Variable @@TRANCOUNT in den Prozeduren auslesen und diese am Ende der SPs ggf. committen oder zur�ckrollen. Das kann auch passieren, wenn der Parameter 'IMPLICIT_TRANSACTIONS' auf 'ON' steht. Dann �ffnet jeder DML Befehl automatisch eine Transaktion, die dann explizit zu commiten oder zur�ckzurollen ist. Ich kenne das Problem beispielsweise von vielen Centura Programmen, wo dieser Parameter automatisch auf ON gesetzt wird. Sperreninformationen kannst Du im Query-Analyzer mit der Prozedur 'sp_lock' ausgeben lassen. Gru� & sch�nen Tag noch. Michael > -----Urspr�ngliche Nachricht----- > Von: Jutta Kavalier [mailto:jutta.kavalier@;demetec.net] > Gesendet: Freitag, 18. Oktober 2002 08:15 > An: ASP Datenbankprogrammierung > Betreff: [aspdedatabase] Re: AW: Probleme mit SQL2000-Server > > > Hallo Patrick, > > wir hatten �hnliche Ph�nomene mit unserem SQLServer. Nach Installieren der > aktuellsten Service Packs (SP3 f�r W2k + Packs f�r SQLServer trat das > Problem nicht mehr auf. > > Gruss > Jutta > > > ----- Original Message ----- > From: "Patrick-M. Engel" <[EMAIL PROTECTED]> > To: "ASP Datenbankprogrammierung" <[EMAIL PROTECTED]> > Sent: Friday, October 18, 2002 1:10 AM > Subject: [aspdedatabase] AW: Probleme mit SQL2000-Server > > > > Hallo Joachim, > > > > Trigger habe ich gar nicht drin. > > Eine Endlosschleife w�re eigentlich auch nicht m�glich. > > > > > Etwas mehr Details solltest Du also schon herauslassen. > > Wenn ich w�sste, woran es liegen kann ... gerne. > > > > > Transaction-Log, Performance-Monitor, ... > > > > Performance-Monitor? Ich habe schon die Leistungsanzeige > laufen. Meinst Du > > das? Aber da sieht man nicht wirklich was. Die Anzahl der "Aktuelle > Anonyme > > Benutzer" ist beim SQL-Stillstand etwa bei 80-100. Nach dem Restart geht > das > > gleich runter, so auf 20-30. > > > > Wo finde ich das Transaction-Log bzw. was kann ich da dann > erkennen? Oder > > kann ich da irgendwie einstellen, wielange der SQL f�r die > Bearbeitung von > > Anfragen braucht. Vielleicht kann ich daran erkennen, was das > Problem ist. > > > > Ich bin echt verzweifelt. Habe gerade den automatischen Restart des SQL > als > > Task alle 4 Stunden eingerichtet. Aber das kann ja nicht die > L�sung sein. > > > > Viele Gr��e, > > Patrick > > > > > > > > -----Urspr�ngliche Nachricht----- > > Von: Joachim van de Bruck [mailto:jvdb@;allmen.de] > > Gesendet: Donnerstag, 17. Oktober 2002 23:48 > > An: ASP Datenbankprogrammierung > > Betreff: [aspdedatabase] AW: Probleme mit SQL2000-Server > > > > > > Hallo! > > > > > habe ein richtig gro�es Problem. Ich setze einen > > > SQL-2000-Server ein und der st�rzt kontinuierlich ab: Ich > > > muss dann den SQL-Dienst einfach neu starten und dann geht > > > wieder alles einwandfrei - zumindest f�r ein paar Stunden. > > > Dann kommen wieder nur TimeOut-Errors bei Datenbankabfragen. > > > > > > Die Datenbank ist ungef�hr 700 MB gro�. Der Server hat 1 GB > > > RAM, l�uft mit einer PIII/750. Eigentlich m�sste das > > > ausreichen. Es finden zwar einige Abfragen statt, aber das > > > muss doch passen. Ich verwende Transact-SQL-Prozeduren > > > (Stored Procedures), die durchaus teilweise komliziert sind. > > > Aber wenn der SQL restartet ist, funktionieren die Abfragen > > > wirklich z�gig. Wenn der SQL abst�rzt (Rest l�uft weiterhin), > > > ist auch die Speichernutzung nicht �berdurchschnittlich hoch. > > > > An der Hardware liegt es ganz bestimmt nicht, eher an den Prozeduren. > > > > Allerdings w�re es hilfreich zu wissen, welche Abfragen den Absturz > > hervorrufen, bzw. ob es wirklich ein Absturz ist oder der SQL Server > > gerade eine Endlos-Schleife bearbeitet, wie sie z. B. durch Trigger > > verursacht werden kann. M�glicherweise wartet die Prozedur auch auf > > externe Dienste, wie z. B. den Mail-Server. Etwas mehr Details solltest > > Du also schon herauslassen. > > > > > Wie kann ich am Server herausfinden, woran das liegt? > > > Bzw. was kann ich da optimieren? > > > > Transaction-Log, Performance-Monitor, ... > > > > Freundliche Gr��e > > Joachim van de Bruck > > > > > > | [aspdedatabase] als [EMAIL PROTECTED] subscribed > > | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv > > | Sie k�nnen sich unter folgender URL an- und abmelden: > > | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp > > > > > > | [aspdedatabase] als [EMAIL PROTECTED] subscribed > > | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv > > | Sie k�nnen sich unter folgender URL an- und abmelden: > > | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp > > > | [aspdedatabase] als [EMAIL PROTECTED] subscribed > | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv > | Sie k�nnen sich unter folgender URL an- und abmelden: > | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp > | [aspdedatabase] als [EMAIL PROTECTED] subscribed | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp | [aspdedatabase] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp
