leere Bretter. Wird aber jetzt mal Zeit, daß Nickles die Manpower bereitstellt, um das dauerhaft abzustellen.
Wenn Computer-Bretter dauernd Computer-Schwierigkeiten haben, ist das nicht ohne Ironie.
Man könnte aber auch sarkastische Gedaken über die Kompetenz haben...
cu hp.
Anonym hiddenpeak „ Hallo B@p, glaub ich sofort - nur, die Probleme gehen nun schon seit Monaten....“
Das Problem ist technischer Natur. Wahrscheinlich kann TW fast garnix dagegen machen. Ein Wahnsinnssystem schafft 7.061.000 Steps/h. Das sind 117683 Anfragen die Minute und 1961 in der Sekunde. Ich galube allerdings nicht, dass TW folgende Hardwareausstattungen hat:
http://www.heise.de/newsticker/result.xhtml?url=/newsticker/data/ps-06.07.00-000/default.shtml&words=Datenbank%20Benchmark
http://www.ideasinternational.com/benchmark/sap/sap3sdR4.html
Ausserdem arbeitet er mit MySQL, welches nischt kostet und auch etwas langsamer ist.
Jetzt sieht das ganze so aus: Wenn einer auf einen Datensatz zugreift, wird dieser gesperrt. Je nach Transaktions-Protokoll werden alle dranhängenden gesperrt und nach und nach freigegeben, sobald es unwahrscheinlich wird, dass diese durch den Nutzer beeinflusst werden.
Wer also jetzt Zugriff auf einen Datensatz haben will, muss sich "hinten anstellen". Um das ganze möglichst fix machen zu können, gibt es einen sog. Schedule. Hier werden die einzelnen Logs (vereinfacht: Anfragen) so zusammengestellt, dass sie sich nicht in die Quere kommen.
Warum dieser Aufwand?
Szenario: Zwei Logs. Jedes will denselben Datensatz lesen und Schreiben.
(r=read, w=write)
Zeit->
Log1: r1,,,w1
Log2: ,,r1,,,w1
Wie zu erkennen, schreibt Log2 "veraltete" Daten zurück. Das darf nicht passieren. Also muss log2 warten, bis Log1 fertig ist.
Dabei besteht die Gefahr von Deadlocks. Ein Log wird in der Abarbeitung "vergessen" und der Nutzer wartet sich einen Wolf. Deshalb gibt es TimeOuts. Wird der TimeOut erreicht, gibt der Client eine Fehlermeldung aus, oder zeigt die Daten halt schlicht nicht an.
Um die Anzahl dieser TimeOuts zu minimieren, wird halt ein Transaktionsverfahren eingeführt, wie oben beschrieben.
Je nachdem, wie gut oder wie schlecht das ein DBMS (Datenbankmanagement-System) das hinkriegt, so schnell ist dann die Datenbank. Herr Wölfers Datenbank wird sicher nicht ansatzweise oben genannte Benchmarks erreichen.
Hinzu kommt, so denk ich mir mal, dass er die Sache mit den Deadlocks noch nicht im Griff hat.
DoS-Attacken (und die kann jeder Depp mitlerweile machen) und weitere Hack-Versuche sind natürlich auch eine Bremse. Ich bin mir sicher, dass Nickles sehr häufig angegriffen wird. Manchmal merkt man das erst, wenn der Rechner brüllend am Ende der Belastungsgrenze steht. Wenn es einer schafft den Schedule vollzusauen, dann ist bei Nickles.de Ruhe. Dann kanst Du warten bis Du schwarz wirst.
Hab ich das ungefär richtig gesagt, Herr Wölfer?
PCO
