Thanks a lot!

> Als sie das gemerkt haben mussten sie in der Folge 4
> Wochen lang den Betrieb komplett stilllegen, das Lager
> manuell leer räumen und alles neu einlagern. Die Pointe
> ist: sie hatten die Software eigentlich deshalb intern
> entwickelt, um Geld zu sparen, weil ihnen der externe
> Dienstleister zu teuer war.

lol. Eine teure Lektion. Aber das wird wohl auch recht häufig passieren, wenn ich bedenke, wie viele Firmen lieber eigenes Personal für Dinge einstellen, die ein Dienstleister womöglich 10x zuverlässiger (da mehr Erfahrung) erledigen kann – auch wenns eventuell erstmal teurer ist als eigenes Personal…

Naja, ich bin mal gespannt, was da noch alles möglich ist. Ich habe, zugegeben, keinerlei derartige Großprojekte bisher gehabt – bin da auch nicht scharf drauf – aber so, wie du des darlegst, Tom, ist das für mich dann jedenfalls auch schlüssig.

und wenn es auch nur so kleine dinge wie die analyse procedure von mysql sind: “SELECT * FROM my_table PROCEDURE ANALYSE()”

Als sie das gemerkt haben mussten sie in der Folge 4 Wochen lang den Betrieb komplett stilllegen, das Lager manuell leer räumen und alles neu einlagern. Die Pointe ist: sie hatten die Software eigentlich deshalb intern entwickelt, um Geld zu sparen, weil ihnen der externe Dienstleister zu teuer war.

Der Vorteil der automatischen Umsetzung liegt aber auf der Hand: der Entwickler kann nicht immer vorhersehen wo die größte Last auftreten wird und wann. Nehmen wir eine Lastspitze auf einem bestimmten Subsystem (vielleicht als Folge einer DOS-Attacke): die Datenbank optimiert sich dann selbst um die Spitze besser bewältigen zu können.

Natürlich muss das System nach der Lastspitze wieder zurück in den Ausgangszustand. Die Frage wie schnell das passiert ist aber nicht Pro- oder Kontra der Technik an sich, sondern eine Frage, wie intelligent die Technik implementiert ist.

Aber das beschriebene Problem hat man auch OHNE die Optimierung. Montagmorgens ist die Datenbank nach den Cronjobs vom Wochenende auch so schon langsamer, weil die Caches ja ebenfalls nicht mehr aktuell sind bzw. die falschen Dinge im Cache liegen.
Die Datenbank muss darauf schnell reagieren können – nichts anderes erwartet man bei anderen Techniken zur Selbstverwaltung auch.

Ein weiteres Beispiel: Wir hatten am WE eine IBM DB2 Datenbank synchronisiert und automatisiert mit neuen Daten befüllt. Der Prozess, der Freitagabend gestartet worden war, lief wider erwarten montags um 8 Uhr immer noch.
Was war passiert? DB2 hat den existierenden Index nicht verwendet weil es keine aktuellen Statistiken hatte. Außerdem hatte es permanent versucht nach jedem neu eingefügten Datensatz alle Indexe zu aktualisieren, was die Zeit für die Inserts und Updates vervielfachte.
Wir mussten die Skripte so anpassen, dass vor dem Cronjob alle Indexe gelöscht und anschließend neu angelegt werden. Danach lief alles wieder normal – zumindest solange der Cronjob nicht wegen eines Fehlers zwischendurch abbrach.

Anderes Beispiel: ein Mitarbeiter hatte am Wochenende ein Data-Mining auf einer PostgreSQL Datenbank durchgeführt via Remote-Zugriff. Dabei hat er eine lang-laufende Abfrage gestartet, die sich in einer Endlosschleife verfangen hatte. Als er merkte, dass etwas schief läuft, hat er den Client einfach geschlossen, die Session auf dem Server aber nicht beendet. Als folge davon lief seine Datenbankabfrage weiter.
Die Deadlock-Erkennung auf PostgreSQL hat versagt. Die Datenbank hat die Query nicht automatisch beendet (Standardkonfiguration). Die laufende Abfrage sperrte mehrere Tabellen. Dadurch wurden am Wochenende die Reports nicht erzeugt. Am Montag morgens stand der ganze Betrieb still, weil die Verkaufszahlen nicht da waren und der Datenbank Anfragen entweder nur träge oder gar nicht entgegen nahm.
In der Folge haben wir PostgreSQL rekonfiguriert und alle Queries, die länger als 6 Stunden liefen, automatisiert abgeschossen. Wenn nun wieder jemand den Server am Freitag lahmlegte so ging uns nur noch das Update vom Samstag verloren, dass dann vom Update am Sonntag überschrieben wurde, sodass Montag wieder alles lief. Zumindest solange niemand den Server am Montag nochmal lahmlegte.

Der Datenbank-Admin wird also in nächster Zeit nicht überflüssig werden. Aber die Arbeit etwas erleichtern wollen wir ihm schon
Und dabei geht es mir vor allem um die Frage: was kann der Entwickler im Vorfeld tun und wie kann die Datenbank-API ihn dabei unterstützen.