Hallo Patrick, Informationen zur Gr��e des Daten- und Logmediums liefert Dir die Prozedur 'sp_helpdb datenbankname'. Dass selbst ein COUNT langsam l�uft deutet ziemlich klar darauf hin, dass f�r diese Tabelle keine oder keine brauchbaren Indizes verf�gbar sind. Hast Du schon einmal mit dem Query Analyzer einen Abfrageplan gezogen? Welches ServicePack hast Du denn auf dem SQL Server installiert?
Zum Thema Transaktionsprotokoll: Werden Datenbank UND Transaktionsprotokoll regelm��ig gesichert? Dann sollte das mit dem Vollaufen des Transaktionsprotokolls (beim SQL Server 2000) kein Thema sein. Zum Thema Indexkonzept kann ich meine eigene Erfahrung mit dem von mir verwalteten System skizzieren: Ausgangsbasis war eine von einer AS/400 auf den SQL Server gespiegelte Datenbank mit einem Datenvolumen von knapp 24GB. Noch aus den 6.5er Zeiten hatten wir ein Indexkonzept mit gemischten und covering Indizes, wobei der gruppierte Index in der Regel die meisten Abfragen abgefangen hat. Das ging auch eine ganze Weile gut, bis zu dem Zeitpunkt, wo nicht mehr alles Indizes in den Cache passten und somit die Anzahl langsamer E/A-Festplattenzugriffe dramatisch anstieg. Das System wurde von Tag zu Tag zusehends langsamer. Wir haben dieses Problem gel�st, indem wir das gesamte Indexkonzept umgestellt haben: 1. Jede Tabelle verf�gt �ber einen gruppierten Index auf einem einzigen eindeutigen Attribut. 2. Allen anderen Indizes (Fremdschl�ssel, Auswahlkriterien usw.) wurden als Einzelattributindies angelegt. 3. Zu jedem Index wurde eine Statistik angelegt. Bei nicht selektiven Indizes wurde die Scanrate der Statistik entsprechend gesetzt, so dass die zugrundeliegenden Indizes auch verwendet werden. 4. Die Datenbankoption 'Autocreate Statistics' wurde deaktiviert, da diese eine immense Beeintr�chtigung der Performance zur Folge hatte. 5. Die Datenbankoption 'Autoupdate Statistics' bleibt aktiviert. ABER: Die ganze Aktion konnten wir nur im Rahmen einer vollst�ndigen Synchronisation unseres SQL Servers mit unserer AS/400 nach einem Harwarecrash unseres SQL Server Systems durchf�hren. Bei den zu diesem Zeitpunkt noch leeren Tabellen lief das Script innerhalb weniger Sekunden durch und die Synchronisation lief mit den 'neuen' Indizes sogar ein wenig schneller. W�ren jedoch alle Tabellen mit Daten gef�llt gewesen, dann h�tte das einen zus�tzlichen Ausfall von mehreren Stunden bedeutet. Alles in Allem: Das optimale und allgemeing�ltige Indexkonzept gibt es LEIDER nicht und Indizierung bleibt auch beim SQL Server 2000 immer noch ein iterativer Prozess (MS Bezeichnung f�r Trial & Error ;-). Hmmm... Das waren ja schon wieder viele Worte ,-)) Gru� Michael > -----Urspr�ngliche Nachricht----- > Von: Patrick-M. Engel [mailto:engel@;united-online.com] > Gesendet: Freitag, 18. Oktober 2002 16:45 > An: ASP Datenbankprogrammierung > Betreff: [aspdedatabase] AW: Re: AW: Probleme mit SQL2000-Server > > > Hallo Michael, > > vielen, vielen Dank f�r Deinen Crash-Kurs. > > Also: IMPLICIT_TRANSACTIONS habe ich gar nicht gesetzt, das steht also auf > default, demnach auf OFF. > > Wie kann ich mit sp_locks sehen, inwiefern der SQL-Server "volll�uft"? Ich > habe n�mlich wirklich keine Ahnung, warum das passiert. Jetzt, wo ich den > SQL alle 3 Stunden restarten lassen, geht alles prima. Aber, das kann ja > nicht die L�sung sein. > > Mit komplizierten Datensatzsperrungen arbeite ich �brigens nicht. > Schreibzugriffe sind meistens nur INSERT-Befehle, gar nicht > soviele UPDATE. > > Kann es vielleicht daran liegen, dass der SQL f�r count-Abfragen ne Weile > braucht und daher ins "Schleudern" kommt? W�ren hier zus�tzliche Indizies > empfehlenswert oder macht das den SQL noch langsamer? > > Viele Gr��e, > Patrick > | [aspdedatabase] als archive@jab.org 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
