Hallo Joachim, also Deine wie immer tollen und ausf�hrlichen Beschreibungen kommen auf jeden Fall in mein pers�nliches Archiv ;) Danke daf�r. Von den aufgef�hrten Punkten kann es eigentlich nix sein - aber den 4. werde ich mal etwas genauer unter die Lupe nehmen. Irgendwoher muss das doch kommen.....
Danke! Jutta > Na ja, es gibt viele M�glichkeiten, einen Datenbank-Server in die Knie > zu zwingen. Hier ein paar, die "versehentlich" passieren k�nnen: > > 1. > TRIGGER - kaskadierende und direkt bzw. indirekt rekursive Trigger sind > anf�llig f�r Designfehler. Also ein Trigger, der sich selbst immer > wieder aufruft (direkt rekursiv) oder einen anderen Trigger aufruft, der > wieder den ersten aufruft (indirekt rekursiv). Beispiel: "Create Trigger > ... On Buchungen For Insert, Update Delete As Update Buchungen Set Feldx > = ..." Hier wird der Trigger immer wieder aufgerufen, weil keine > Trigger-Einschr�nkungen auf bestimmte Spalten definiert werden. > > 2. > CLUSTERED INDEX - Dieser speichert immer exakt in der Reihenfolge des > Schl�ssels. Bei gro�en Datenmengen kann ein CUD (Create / Update / > Delete) dazu f�hren, dass die Datenbank riesige Datenpakete verschieben > muss - Deshalb verzichtet man bei langen Indexes und gro�en Datenmengen > auf das CLUSTERED. > > 3. > VOLLTEXTSUCHE ohne eingebaute Volltextsuche, ggf. auch in BLOBs - > komplexe Suchabfragen mit "LIKE '%...%' k�nnen m�rderisch sein - In der > Regel gibt es gute Workarounds mit geschickt platzierten Indexes oder > der eingebauten Volltextsuche. > > 4. > Komplexe SQL-Statements, die Kreuztabellen erzeugen (Sub-SELECTs, JOINs, > ...) - Wenn man die SQL-Befehle als parametrisierte Procedures oder > Views gespeichert hat, kann man im SQL Query-Analyzer testen, wo es > hakt. Hier hilft auch der Profiler weiter. Wenn man z. B. 3 Tabellen mit > je nur 1.000 Datens�tzen verkn�pft, kann ein "verungl�cktes" > SQL-Statement dazu f�hren, dass 1.000 x 1.000 x 1.000 (= 1 Milliarde) > Datens�tze gelesen werden, die dann durch WHERE-Klauseln auf das > geforderte Ma� reduziert werden. Solche JOINs oder Sub-SELECTs lassen > sich immer optimieren. Wenn man SQL-Statements mit ASP/VBS > zusammensetzt, kann man leider nichts testen. > > 5. > MSDE-Version??? - Optimale Performanz bei bis zu 5 Clients, Blockade ab > 10 Clients - Ihr habt doch sicher einen richtigen SQL-Server, oder? > > 6. > STORED PROCEDURES mit Endlos-Schleifen - Ne, das w�re Euch schon l�ngst > aufgefallen, auch wenn die Endlosschleife durch die Parameter erzeugt > werden. > > 7. > User-Input - Eingaben von Benutzern, die als Parameter in SQL-Statements > eingebaut werden k�nnen auch Schrott enthalten oder auch > Endlos-Schleifen verursachen. Pr�ft Ihr hier alles? > > 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
