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
signature.asc
Description: OpenPGP digital signature
