Hallo, > Ich denke nicht, das ich auf diese Anzahl pro Woche > mit knapp über 3000 Benutzern gekommen bin. Naja, das geht relativ schnell, kommt immer auf den Programmierstil und die Nutzung an. Wenn ich auf meiner Spiel-Datenbank mit 500000 Zeilen pro Zeile ein Update in einer Transaktion machen lasse, dann kommt man relativ schnell in die Bereiche der Grenze... Auch wenn sich eine Milliarde Transaktionen nach sehr viel anhört, nehmen wir mal deine 3000 User und die Annahme, dass die Datenbank komplett alle 7 Tage erst reorganisiert wird (wichtig, dass insbesondere JEDE Datenbank und JEDE Tabelle aus dem gesamten Cluser reorganisiert wird, aber dafür gibt es ja vacuumdb --all). pro Tag ~ 142857142 Transaktionen pro User/Tag ~ 47619 Transaktionen pro User/Stunde ~ 1984 Transaktionen pro User/Minute ~33 Transaktionen Mit anderen Worten, wenn alle 3000 User die Zugriff auf deine Datenbank haben, nur alle 2 Sekunden eine Transaktion durchführen (wobei ja eine sinnvolle Abfrage durchaus auch aus mehreren Transaktionen bestehen kann) und sowohl Rechenleistung als Anbindung ausreichen, dann knackt man die Grenze innerhalb einer Woche schnell. Ich habe hier Anwendungen, die ca. 1000-2000 Transaktionen in der Minute absetzen könnten (im Lastbetrieb), also sind 33 Transaktionen pro Minute gar nicht mal soo unrealistisch. > Da muß ich nochmal auf pgsql-general nachfragen... > Habe irgendwie nichts zu den Transaktions-ID zu PG8 gefunden. Doku lesen?! Hier: http://borg.postgresql.org/docs/8.0/interactive/maintenance.html > Die 7.1 hatte ja einwandfrei jahrelang funktioniert, weshalb > ich ja auch nicht umgestiegen bin. Noch mehr Doku lesen: > Don't touch a running system ! Vor 7.2 musste man um das gleiche Problem zu beheben alle 4 Milliarden Transaktionen ein reinit durchführen - das ist ja glücklicherweise vorbei, denn während des reinit stand ja die Datenbank, während man ein vacuumdb durchaus in lastarmen Zeiten laufen lassen kann, ohne dass die Datenbank nicht mehr ansprechbar ist. Manchmal sollte man schonmal sich die Mühe machen sich durch die Doku und die Datenbank-Statistiken zu quälen :-) Aber das ist eben etwas, was eindeutig in die Aufgabe des Admins fällt, der so ein System betreut - bei MySQL hast Du das Problem beispielsweise nicht. > Vor allen will ich die Tabellen nun so organisieren, das die > dumps nicht mehr größer sind als die Backup-Medien... Eins hab ich mal gelernt: nie sollte man die Layout einer Datenbank an solche Dinge anpassen, aber das ist Geschmackssahe. Man kann das Dump ja immer mittels einer Pipe und Split auf die passende Größe für ein Band bekommen :-) Cheers, Jan
Attachment:
signature.asc
Description: OpenPGP digital signature