Hallo Michael,
vieleicht gehe ich hier jetzt ein wenig am Thema vorbei, doch ich glaube,
dass das Aufteilen der Datenbank das Problem nicht oder nur kurzfristig
l�st. Bei einer Vierprozessormaschine, die hoffentlich auch gut mit Speicher
best�ckt ist, sind 20GB Datenvolumen nur geringf�gig mehr, als nichts...
Das Splitten einer Datenbank ist eine ziemlich aufreibende und
problembehaftete Angelegenheit, weil zum Beispiel deklarative referenzielle
Integrit�ten immer nur innerhalb einer Datenbank die Konsistenz der Daten
durchsetzen k�nnen.
Klassisches Beispiel: Du splittest eine Tabelle nach einem Status ("Alt"
oder "Neu") und legst diese mit allen dazugeh�rigen Daten in eine andere DB.
Das wird am Anfang ganz toll funktionieren - doch sp�testens dann, wenn sich
ein Status eines Datensatzes �ndert wird's eklig. Dann zieht man entweder
mit allen referenzierten Daten um oder legt den Satz doppelt an. Egal, was
Du tust: Nach einiger Zeit sehen dann beide Datenbanken so aus, wie die, die
Du so m�hsam aufgeteilt hast (War ein �u�erst schmerzhafter Erfahrungswert
;-))
F�r besser halte ich es, der Ursache der langlaufenden Transaktionen auf den
Grund zu gehen und diese zu bek�mpfen. Hier gibts es im Prinzip drei
Ausl�ser f�r ein solches Problem:
1. Ein Fehler in der SQL Server 2000 Datenbankengine
Mir selber sind zwei Probleme bekannt, welche durch Bugs in der Engine
hervorgerufen werden. Das erste tritt bei komplexen Abfragen mit mehr als 16
(glaub' ich) Tabellen auf. Hier hat der Optimizer massivste Probleme, was
sich verheerend auf die Laufzeit der Abfragen auswirkt. Dieses Problem wurde
im SQL Server 2000 SP1 gefixed. Das zweite Problem kommt Deiner Situation
schon etwas n�her. Hier werden von SQL Server unter bestimmten Umst�nden
Tabellensperren gehalten, wo ein simples Row-Level-Locking angebrachter (und
so auch versprochen) sind. Dieses Problem ist mit dem SQL Server SP2
gefixed.
2. Falsche oder unvollst�ndige Indizierung
Ja, ja. Das soll's ja auch geben... Hier kannst Du dir zun�chst mit dem
Profiler die Abfragen auslesen, die lange laufen und damit einen schlechten
Einfluss auf die Performance haben. Anschlie�end l�sst Du Dir f�r diese
teueren Abfragen die Abfragepl�ne (am besten mit dem Query Analyzer)
anzeigen. "Table Scans" und "Clustered Index Scans" sind dabei von Natur aus
"Bah!" und sollten, falls m�glich durch Index-Seeks ersetzt werden. Alle
Tabellen sollten (wegen dem Hashing) �ber einen Clustered Index verf�gen,
der idealerweise klein und eindeutig ist. M�glicherweise fehlen ja auch noch
einige Statistiken... Wie dem auch sei: Hier kann man richtig was
rausholen - es lohnt sich wirklich.
3. Fehler bei der Transaktionssteuerung
Manchmal kann es auch einmal passieren, dass in einer Anwendung nach einem
BEGIN TRANSACTION ein COMMMIT oder ROLLBACK vergessen wurde. Dies f�hrt dann
zu weit l�ngeren Transaktionslaufzeiten, mit entsprechenden
Sperrenproblemen, als es sein muss. Ebenso kann es auch passieren, dass
zwischen einem BEGIN TRANSACTION und dem dazugeh�rigen COMMIT oder ROLLBACK
noch auf Eingaben gewartet wird. Wenn dann die Person am Bildschirm sich
w�hrendessen entschlie�t, in die Mittagspause zu gehen, dann ist das,
bezogen auf die Sperrensituation, ziemlich bl�d - selbst dann, wenn den
Connect nach 20 Minuten automatisch gel�st wird... Abhilfe schafft da nur
eine �berpr�fung und ggf. Korrektur der Anwendung und das kann (leider)
recht zeitaufwendig sein...
Mein pers�nlicher Tipp: Schau' erst einmal nach, wie's mit dem SP aussieht.
Ist das OK, dann nimm' Dir die Indizes zur Brust und, wenn auch das
�berhaupt nichts bringt, dann ist ein Checkup der Anwendung oder ein
Splitting der Datenbank f�llig...
In diesem Sinne
Sch�nen Feierabend
Michael Busch
http://www.sql-klinik.de
-----Urspr�ngliche Nachricht-----
Von: Michael Seirer [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 5. Februar 2002 17:13
An: ASP Datenbankprogrammierung
Betreff: [aspdedatabase] RE: aufsplitten einer datenbank - skalierung
hi!
wir haben eine sql-server 2000-db mit einer aktuellen groesse von 20GB.
leider sind unsere geschaeftsprozesse eher sequentiell und sehr trans-
aktionsorientiert. das heisst, wir nutzen unsere 4-prozessor-maschine
derzeit eher schlecht aus (nur die ersten beiden prozessoren worken
parallel).
wir wollen nun einige kernprozesse entkoppeln und auf mehrere daten-
banken aufteilen. es geht uns nicht um die groesse der DB sondern darum,
dass die transaktionen timeouts bekommen (also zulang ben�tigen).
habt ihr schonmal datenbanken in der art (user aufteilen) gesplittet?
ich hab so gut wir gar nix im web dazu gefunden...
*wink*
Michi
| [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
