Hallo martin,
ihr habt das vermutlich alles schon auf dem Schirm. Ich kenne solche Probleme von unterschiedlichsten Kunden aus dem Finanzbereich. Was dort als Lösung angestrebt wurde (die "Fachbegriffe" sind teils nicht richtig, da ich kein DBA bin):
* Erhöhung der Buffers, damit mehr Daten, insbesondere Indexdaten, im Arbeitsspeicher gehalten werden
* Auslagerung der Indexe in eine eigene Partition (in einem anderen SAN, angebunden über separaten HBA und Switch)
* Trennung von "Schreib"-DBS und "Lese"-DBS, lazy synchronisation (heißt: die Transaktion auf der Schreib-DBS kommt zurück bevor die Änderung an die Lese-DBS propagiert wurde)
* Reduktion (ungünstiger) paralleler Zugriffe, z.B. durch Einsatz einer "rewriting SQL Proxy" / Reduktion der Anzahl der Worker-Threads auf 1 ( :P )
* Wechsel des Dateisystems (Informix z.B. mag/mochte ZFS überhaupt nicht)
* "Flüchtige" Indexe, die nur im Speicher gehalten werden (und bei Neustart der DB dann erst aufgebaut werden)
* Neukomposition der Indexe, damit diese nur auf (relativ) statischen Daten beruhen (=keine "updatable indexes", insert und delete aber schon)
Aus meinen Projekten heraus haben die ersten Punkte immer eine Besserung gebracht. Eine nachhaltige Lösung war aber immer nur der letzte Punkt, da sonst an den Auswirkungen und nicht am Symptom gearbeitet wird. Je nach DBMS kann man auch unterschiedliche Engines für die Tabellen betreiben?
Grüße
Eis