Re: Tabellen im laufenden Betrieb auf andere Tablespaces verlagern ohne DB-Server Downtime?

Quoting Andreas 'ads' Scherbaum <adsmail(at)wars-nicht(dot)de>:

> > Es gibt nicht viele Provider die eine redundante Leitung zum DECIX
> > haben, ein Rechenzentrum nach den neuesten Standards und Spitzenhardware
> > zu gue¼nstingen Discountpreisen sowie unlimited Traffic inkl.
>
> Du willst ganz viel Leistung fuer ganz wenig Geld, verstehe.
> Ich enthalte mich weiterer Kommentare.

Wer will das nicht?

> > Doch, tut es, weil PG es nicht selber kann.
> > Es liest beim Start env(PGDATA) aus und erstellt relativ
> > dazu ein Verzeichnis "mydd_name" und setzt die FS Rechte
> > und Ownership auf postgres.postres. Danach connected
> > es sich selbst auf die DB und legt die Tablespaces
> > mit CREATE TABLESPACE in dem vorher erstellten Verzeichnis
> > an. Dies ist schon deswegen notwendig, da PG für CREATE
> > TABLE Spaces nun einmal einen existenten Ordner verlangt.
>
> [X] Du hast Tablespaces nicht verstanden.
>
> *Grusel* Bitte beschäftige dich erst mit einem Thema, bevor du
> versuchst, selbiges einzusetzen.

Also nun frage ich mich ob Du die Doku von der Du dauernd
redest wirklich verstanden hast.

Lies mal besser selber:
http://www.postgresql.org/docs/8.0/interactive/sql-createtablespace.html

Da steht:
Examples

CREATE TABLESPACE dbspace LOCATION '/data/dbs';

Genau das führt mein Programm aus, nur der Parameter
LOCATION eben $PGDATA/mylocation entspricht.

Was soll denn daran bitte schoen falsch sein?
Möglicherweise hast Du ja auch etwas nicht richtig verstanden,
man lernt nie aus ;d

> > Weil es nun mal so ist und ohne Downtime funktionieren muss, ganz
> > einfach, das ist die Anforderung!
>
> "Ohne Downtime" kann nicht die einzige Anforderung sein.

Downtime bedeutet Verlust von Geld. Daher ist es eigentlich recht
logisch das man sie versucht so gut es geht zu vermeiden. Natürlich
ist das die wirtschaftliche Seite, aber die ist eben auch
wichtig.

> > Downtimes und schlechte Performance bei konstanten sowie stark
> > wachsenden Userzahlen sind ein KO Kriterium und no go das unbedingt
> > vermieden werden muss und daher ist es Gegenstand der aktuellen
> Planspiele.
>
> Marketing ...

Tja, für irgendwen entwickelt man seine Software als Softwareentwickler
nun mal, am liebsten fue diejenigen Kunden die auch bereit sind
dafuer zu zahlen und fuer Binsenweisheiten zahlen die Leute nun mal
nicht viel.

> > ein verteiltes Szenario ist aber ein interessanter Gedanke, nur scheinen
> > 80 GByte Server Festplatte dabei trotzdem zu wenig, gerade wenn eine
> > Tabelle schon über 450 GByte gross ist und stark weiter wächst.
>
> Ich erinnere dich mal an deine eigenen Aussagen, dass du Terabyte bzw.
> Exobyte an Daten ablegen wolltest. Da sind auch Festplatten mit 450 GB

Ich sprach davon das eine bestimmte Tabelle bereits die Marke von
450 GByte erreicht hat und das Oracle 8 Exobate an Daten verwalten kann.

Un nun bleib mal locker;D