Tabellen im laufenden Betrieb auf andere Tablespaces verlagern ohneDB-Server Downtime?

Hi,

Ist es mit PostgreSQL 8.3 möglich eine Tabelle in einen anderen=20
Tablespace zu verschieben (also von Tablespace a nach Tablespace b)?

Hintergrund der Frage:

Mein Provider hat auf seinem Server eine begrenzte Kapazität was=20
Festplattenspeicher betrifft. Bei wachsender DB
möchte ich jedoch Handlungsfähig bleiben, nur wie lässt sich das am=
=20
besten einrichten?

Ich habe ein Tool programmiert das auf einem jungfreulichen, neu in=20
Betrieb zu nehmenden PostgreSQL 8.3 Server
zuerst zwei User anlegt (dbadmin und queryuser). Der user "dbadmin" ist=20
derjenige User dem alle DB-Objekte gehören.
der User queryadmin hat eingeschränkte Rechte und steht für den Named=
=20
user der von allen Applikations-Anfragen
verwendet wird. Das Programm legt ferner in

$PGDATA/mydata/mydb/ die Tablespaces
->forums
->messages
->users
u.s.w

sowie alle Tabellen, Indexe, Trigger und Grants an.

Für das Loadbalancing habe ich bereits eine Lösung. Sie wird via Sequ=
oia=20
abgewickelt,
diese sorgt aber nur für Hochverfügbar und Lastverteilung über alle=
=20
definierten Backends,
nur hilft mir das nicht unbedingt bei limierten Speicher weiter.

Macht es hier eher Sinn ein Colocationangebot zu nutzen und den Server=20
selber
zu bestücken? (Nur DB / WebApplicationserver sind so ok).

Grüße, Rudi






--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

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

guten morgen,

>
> Ist es mit PostgreSQL 8.3 möglich eine Tabelle in einen anderen=20
> Tablespace zu verschieben (also von Tablespace a nach Tablespace b)?
>
....


>
> Für das Loadbalancing habe ich bereits eine Lösung. Sie wird via=20
> Sequoia abgewickelt,
> diese sorgt aber nur für Hochverfügbar und Lastverteilung über al=
le=20
> definierten Backends,
> nur hilft mir das nicht unbedingt bei limierten Speicher weiter.

du machst dir gedankten ueber loadbalancing und bist bei einem provider,=20
der dir nur "eine begrenzte Kapazität was Festplattenspeicher"
einrichtet?? ;
grundsaetzlich haben zwar alle festplattenspeicher nur eine begrenzte =20
kapazität - aber ich kenne selbst anwendungen mit mehreren zig mio.=20
queries am tag, die ohne loadbalancing laufen.

ich meine, du machst dir grad gedanken ueber ungelegte eier ;-)

doch selbst wenn du mehrere GB daten in deiner table haben solltest,=20
waere ein
select * into blah from blubb
kein problem. und damit waeren die daten ggf. in einem anderen tablespace=
..

munter bleiben

ralf


--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

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

am Tue, dem 20.05.2008, um 22:52:09 +0200 mailte rudi@je-more.de folgend=
es:
> Hi,
>=20
> Ist es mit PostgreSQL 8.3 möglich eine Tabelle in einen anderen=20
> Tablespace zu verschieben (also von Tablespace a nach Tablespace b)?

Doku existiert und beantwortet Deine Frage.
http://www.postgresql.org/docs/8.3/interactive/sql-altertabl e.html


Andreas
--=20
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

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

am Wed, dem 21.05.2008, um 6:11:43 +0200 mailte Ralf Burger folgendes:
> doch selbst wenn du mehrere GB daten in deiner table haben solltest,
> waere ein
> select * into blah from blubb
> kein problem. und damit waeren die daten ggf. in einem anderen tablespace.

Nein, nicht wenn andere Tabellen via RI auf diese referenzieren.


Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

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

--On Mittwoch, Mai 21, 2008 06:58:43 +0200 "A. Kretschmer"=20
wrote:

> Doku existiert und beantwortet Deine Frage.
> http://www.postgresql.org/docs/8.3/interactive/sql-altertabl e.html

Es bleibt aber zu beachten, dass ein ALTER TABLE SET TABLESPACE auf=20
Dateisystem-Ebene kopiert und deshalb einen Access Exclusive Lock für die=
=20
Dauer des Kopiervorganges benötigt. Darauf kann man aber, wenn keine=20
Änderungen der Quelltabelle unterschlagen werden sollen, sowieso nicht=20
verzichten.

--=20
Thanks

Bernd

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

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

Bernd Helmle schrieb:

> Es bleibt aber zu beachten, dass ein ALTER TABLE SET TABLESPACE auf=20
> Dateisystem-Ebene kopiert und deshalb einen Access Exclusive Lock für=
=20
> die Dauer des Kopiervorganges benötigt. Darauf kann man aber, wenn ke=
ine=20
> Änderungen der Quelltabelle unterschlagen werden sollen, sowieso nich=
t=20
> verzichten.

Können schon, ist auch nicht sonderlich kompliziert (von der=20
algorithmischen Seite her), erfordert allerdings Logik im Daemon die=20
noch nicht existiert (vgl. RAID-1 Rebuild).

lg,
michael

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

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

--On Mittwoch, Mai 21, 2008 12:17:02 +0200 Michael Renner=20
wrote:

> Können schon, ist auch nicht sonderlich kompliziert (von der
> algorithmischen Seite her), erfordert allerdings Logik im Daemon die noch
> nicht existiert (vgl. RAID-1 Rebuild).

Oder naheliegender, siehe Slony-I, SUBSCRIBE-Kommando. Mir geht es nur=20
darum, dass es ohne Downtime ohne signifikanten Aufwand schlicht schwer=20
wird.

--=20
Thanks

Bernd

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

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

On Tue, 20 May 2008 22:52:09 +0200 rudi@je-more.de wrote:

> Ist es mit PostgreSQL 8.3 möglich eine Tabelle in einen anderen=20
> Tablespace zu verschieben (also von Tablespace a nach Tablespace b)?

Du hast sicherlich schon:

- Die Dokumentation zu "CREATE TABLESPACE", "ALTER TABLE" und "ALTER
INDEX" durchgelesen, was die dortigen Angaben zu "Tablespaces"
betrifft. Was waren die Ergebnisse deiner Recherchen?

- Einen Test durchgeführt. Was kam dabei heraus?


> Mein Provider hat auf seinem Server eine begrenzte Kapazität was=20
> Festplattenspeicher betrifft. Bei wachsender DB
> möchte ich jedoch Handlungsfähig bleiben, nur wie lässt si=
ch das am=20
> besten einrichten?

Indem man einen anderen Provider wählt, der flexibler ist.
Ausserdem: sprechen wir über Tablespaces auf dem gleichen oder auf
einem zweiten Server? So recht will sich mir nämlich der Sinn deiner
Frage nicht erschließen bzw. kann es sein, dass du in die falsche
Richtung denkst.


> Das Programm legt ferner in
>=20
> $PGDATA/mydata/mydb/ die Tablespaces
> ->forums
> ->messages
> ->users
> u.s.w
>=20
> sowie alle Tabellen, Indexe, Trigger und Grants an.

Dein Programm legt hoffentlich hoffentlich unterhalb von $PGDATA
überhaupt nichts alleine an. Auf $PGDATA greift nur die Datenbank zu,
wo genau die Daten dann liegen, interessiert dich nicht.


Bis dann

P.S.: Warum kommt es mir so vor, als ob die Anforderung nur lautete
"muss ohne Downtime funktionieren", ohne sich vorher konkret Gedanken
über die Aufteilung der Struktur gemacht zu haben? Wenn ich deine
Tablespaces sehe, könnte ich mir auch sehr gut verteilte Lösungen
vorstellen, die sich recht einfach realisieren lassen.

--=20
Andreas 'ads' Scherbaum
German PostgreSQL User Group

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

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

Quoting Andreas 'ads' Scherbaum :

> > Mein Provider hat auf seinem Server eine begrenzte Kapazität wa=
s=20
> > Festplattenspeicher betrifft. Bei wachsender DB
> > möchte ich jedoch Handlungsfähig bleiben, nur wie läss=
t sich das am=20
> > besten einrichten?
>=20
> Indem man einen anderen Provider wählt, der flexibler ist.
> Ausserdem: sprechen wir über Tablespaces auf dem gleichen oder auf
> einem zweiten Server? So recht will sich mir nämlich der Sinn dein=
er
> Frage nicht erschließen bzw. kann es sein, dass du in die falsche
> Richtung denkst.

Es gibt nicht viele Provider die eine redundante Leitug zum DECIX
haben, ein Rechenzentrum nach den neuesten Standards und Spitzenhardware
zum günstingen Discountpreis sowie unlimited Traffic inkl. Bei einem kl=
einen
Wald und Wiesen Provider wirds meist teuer und die Leitung von und zum=20
Inet hin ist lahm und meist muss man noch den Traffic extra bezahlen.

Das Thema habe ich schon in verschiedenen Situation erlebt und würde
es sicherlich nicht noch einmal machen.

> > Das Programm legt ferner in
> >=20
> > $PGDATA/mydata/mydb/ die Tablespaces
> > ->forums
> > ->messages
> > ->users
> > u.s.w
> >=20
> > sowie alle Tabellen, Indexe, Trigger und Grants an.
>=20
> Dein Programm legt hoffentlich hoffentlich unterhalb von $PGDATA
> überhaupt nichts alleine an. Auf $PGDATA greift nur die Datenbank =
zu,
> wo genau die Daten dann liegen, interessiert dich nicht.

Doch, tut es, weil PG es nicht selber kann.
Es liest beim Start env(PGDATA) aus und erstellt relativ=20
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.

Danach erstellt es noch die notwendigen User, Schematas
und Tabellen und für Basisbetriesparameter ein.

Damit bin ich relativ schnell in der Lage die AppDB
Struktur auf dem neu in Betrieb zu nehmenden DB-Server
binnen sek zu erstellen.

> Bis dann=20
> P.S.: Warum kommt es mir so vor, als ob die Anforderung nur lautete
> "muss ohne Downtime funktionieren", ohne sich vorher konkret Gedanken
> über die Aufteilung der Struktur gemacht zu haben? Wenn ich deine
> Tablespaces sehe, könnte ich mir auch sehr gut verteilte Lösu=
ngen
> vorstellen, die sich recht einfach realisieren lassen.

Weil es nun mal so ist und ohne Downtime funktionieren muss, ganz=20
einfach, das ist die Anforderung!

Dabei müssen einzelne Komponenten trotzdem austauschbar und das
Gesammtsystem wartbar und skalierbar bleiben. Ich mache mir sicherlich
nicht die ganze konzeptionelle arbeit, messe und evaluiere so mal=20
eben zum Spass. Wenn das Ding mal läuft, soll es Gewinne abwerfen und
da muss man eben besser sein als die Konkurenz.

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

Momentan gilt es eigentlich nur noch das Thema Plattenkapazität erhöh=
en
im laufenden Betrieb abzuklären. Mein Provider bietet einen service an,
der ungefähr in die Richtung geht, aber eher auf Radundanz abzielt
(also Raid 10 SCSI Controller nachrüsten u.s.w)

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.


Mfg

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

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

Quoting Ralf Burger :

> du machst dir gedankten ueber loadbalancing und bist bei einem provider=
,=20
> der dir nur "eine begrenzte Kapazität was Festplattenspeicher"
> einrichtet?? ;

Ich mache mir keine Gedanken über Loadbalancing, sondern habe es schon=20
in meine Applicationabfrage Architektur implementiert. Normale,
preiswerte Rootserver haben nun mal nicht besonders grosse Festplatten,
sie reichen aber aus um einen guten Start für wenig Geld hinzulegen.

> grundsaetzlich haben zwar alle festplattenspeicher nur eine begrenzte =20
> kapazität - aber ich kenne selbst anwendungen mit mehreren zig mio.=20
> queries am tag, die ohne loadbalancing laufen.

Das ist mir auch klar, nur geht es auch um die vermeidung von Singlepoint=
of
Failures. Wenn ich festelle, das mein DB-Server gepatcht oder für
eine Wartung herruntergefahren werden muss und möglicherweise sogar
ein neues Backup eingespielt werden muss, was locker zig Stunden dauern
kann, dann will ich das der Betrieb trotzdem einfach weiter geht.

Dies erreiche ich durch einen gespiegelten DB-Server auf den für
die Zeit der Downtime ausgewichen werden kann. Sobal der gewartete
Server wieder ready ist und wieder online gehen kann, glieder er sicht
wieder in den DB-Server Pool ein. Dann kann man in Ruhe DB-Server
2 und 3 Warten während das Gesammtsystem weiterläuft.

Engpass ist jetzt halt einfach die Festplatte pro Server.
Eine Verteilte Architektur mit DB-Server für spezielle Aufgaben
wäre zwar wünschenswert, aber auch schwerer zu balancen, zu spiegeln,
zu sichern und insgesammt schwerer zu warten, da es hier einfach mehr=20
Komplexität hat.
=20
> doch selbst wenn du mehrere GB daten in deiner table haben solltest,=20
> waere ein
> select * into blah from blubb
> kein problem. und damit waeren die daten ggf. in einem anderen tablespa=
ce.

ERM und Query Design bleiben auch nach wie vor wichtige Dinge, jedoch
kann und will ich nicht die gesammte Applikation mit einem engen
Flaschenhals umsetzen, wenn es sich irgend möglich vermeiden lässt.

Besser vorher Gedanken machen, als hinterher in der Falle sitzen!

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

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

rudi@je-more.de schrieb:

> Es gibt nicht viele Provider die eine redundante Leitug zum DECIX
> haben, ein Rechenzentrum nach den neuesten Standards und Spitzenhardwar=
e
> zum günstingen Discountpreis sowie unlimited Traffic inkl. Bei einem =
kleinen
> Wald und Wiesen Provider wirds meist teuer und die Leitung von und zum=20
> Inet hin ist lahm und meist muss man noch den Traffic extra bezahlen.

Sei mir nicht bös, aber das von dem du da gerade erzählst klingt=20
ziemlich nach Wald&Wiesen-Provider mit Fehleinschätzung der Situation :=
).

Cheap, Fast, Reliable ist nahezu immer (ausser die Housing/Hosting=20
Business Unit der Firma ist nicht Gewinnorientiert) ein "pick two out of=20
three".


[..Storagewahnsinn..]

Mit einzelnen Systemen kannst du bis zu einer gewissen Größe=20
Blockdevicemässig wachsen. Dies wird eigentlich nur durch die Diskslots=
=20
im Gehäuse bzw. die SATA/SAS-Ports am Controller beschränkt. Sinnvoll=
e=20
RAID-Controller (zB HP Smartarray) können Volumes online extenden bzw.=20
erzeugen; obs das darunterliegende OS mit Volume-Manager kann gilt es=20
auszuprobieren.

Falls man Gefahr läuft relativ bald ans Limit des Gehäuses/Controller=
s=20
zu kommen, sollte man einen Blick in Richtung SAN werfen, die sind=20
meistens noch eine Spur besser online erweiterbar.

Oder man knallt gleich einen Abstraktionslayer vor die Datenbanken die=20
sich um Replikation und Verteilung kümmert, dann hast du mit so=20
langweiligen Sachen wie "Blockdevice Space" weniger Stress. Aber das=20
haben wir ja schon kurz angeschnitten...


Da du wieder Gefahr läufst ins 99,999999% Traumland abzudriften wärs=20
langsam wirklich nett wenn du wo ein komplettes Konzept bzw.=20
Anforderungsprofil als Diskussionsbasis hinterlegen könntest,=20
mittlerweile wirds (zumindest für mich) wieder ein bisschen Anstrengend=
=20
dir zu folgen ;).

lg,
Michael


--=20

Michael Renner
InQnet GmbH
Praterstraße 31
A-1020 Wien

Tel.: +43 1 212 7650 521
Fax.: +43 1 212 7650 610

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

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

On Wed, 21 May 2008 14:43:38 +0200 rudi@je-more.de wrote:

> Quoting Andreas 'ads' Scherbaum :
>=20
> > > Mein Provider hat auf seinem Server eine begrenzte KapazitÃ=C2=
=A4t was=20
> > > Festplattenspeicher betrifft. Bei wachsender DB
> > > möchte ich jedoch Handlungsfähig bleiben, nur w=
ie lässt sich das am=20
> > > besten einrichten?

[X] Dein Charset ist kaputt.
Bring deinen Mailclient bitte in Ordnung, du schickst:

Content-Type: text/plain; charset=3DISO-8859-1

aber hast die Umlaute und Sonderzeichen als UTF8 geschrieben.


> > Indem man einen anderen Provider wählt, der flexibler ist.
> > Ausserdem: sprechen wir über Tablespaces auf dem gleichen od=
er auf
> > einem zweiten Server? So recht will sich mir nämlich der Sin=
n deiner
> > Frage nicht erschließen bzw. kann es sein, dass du in die fa=
lsche
> > Richtung denkst.
>=20
> Es gibt nicht viele Provider die eine redundante Leitug zum DECIX
> haben, ein Rechenzentrum nach den neuesten Standards und Spitzenhardware
> zum günstingen Discountpreis sowie unlimited Traffic inkl.

Du willst ganz viel Leistung für ganz wenig Geld, verstehe.
Ich enthalte mich weiterer Kommentare.



> > Dein Programm legt hoffentlich hoffentlich unterhalb von $PGDATA
> > überhaupt nichts alleine an. Auf $PGDATA greift nur die Date=
nbank zu,
> > wo genau die Daten dann liegen, interessiert dich nicht.
>=20
> Doch, tut es, weil PG es nicht selber kann.
> Es liest beim Start env(PGDATA) aus und erstellt relativ=20
> 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.



> Weil es nun mal so ist und ohne Downtime funktionieren muss, ganz=20
> einfach, das ist die Anforderung!

"Ohne Downtime" kann nicht die einzige Anforderung sein.


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

Marketing ...


> 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
nicht geeignet und du solltest dir frühzeitig (nämlich genau jetz=
t)
Gedanken darüber machen, wie du deine Daten ablegst und wie du
Speicherplatz aufrüstest.


Bis dann

--=20
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

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

Hallo Rudi,

rudi@je-more.de wrote:
> Ich mache mir keine Gedanken über Loadbalancing, sondern habe es scho=
n=20
> in meine Applicationabfrage Architektur implementiert. Normale,
> preiswerte Rootserver haben nun mal nicht besonders grosse Festplatten,
> sie reichen aber aus um einen guten Start für wenig Geld hinzulegen.

Kann Sequoia nicht sowas wie RAIDb 1+0 oder 0+1? Oder was ist RAIDb-2=20
von Sequoia? Schau mal hier [1].

Mir ist nicht klar, wie Du mit Tablespaces eine hoehere Verfuegbarkeit=20
erreichen willst. Eher das Gegenteil scheint mir der Fall zu sein:=20
sobald Du Tablespaces auf anderen Systemen baust, erhoehst Du die Zahl=20
der moeglichen Fehlerquellen - und verringerst somit die Verfuegbarkeit.

> Engpass ist jetzt halt einfach die Festplatte pro Server.
> Eine Verteilte Architektur mit DB-Server für spezielle Aufgaben
> wäre zwar wünschenswert, aber auch schwerer zu balancen, zu spiegel=
n,
> zu sichern und insgesammt schwerer zu warten, da es hier einfach mehr=20
> Komplexität hat.

Ja, ja, all die Probleme, die multi-master replication mit sich bringt...

Markus


[1]: Die RAIDb Levels von Sequoia:
http://sequoia.continuent.org/doc/2.10/userGuide/ar01s09.htm l#raidb2


--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

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

Quoting Andreas 'ads' Scherbaum :

> > Es gibt nicht viele Provider die eine redundante Leitung zum DECIX
> > haben, ein Rechenzentrum nach den neuesten Standards und Spitzenhardw=
are
> > zu gue=BCnstingen Discountpreisen sowie unlimited Traffic inkl.
>=20
> 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=20
> > 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.
>=20
> [X] Du hast Tablespaces nicht verstanden.
>=20
> *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=20
redest wirklich verstanden hast.

Lies mal besser selber:
http://www.postgresql.org/docs/8.0/interactive/sql-createtab lespace.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=20
> > einfach, das ist die Anforderung!
>=20
> "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.
=20
> > Downtimes und schlechte Performance bei konstanten sowie stark
> > wachsenden Userzahlen sind ein KO Kriterium und no go das unbedingt=20
> > vermieden werden muss und daher ist es Gegenstand der aktuellen
> Planspiele.
>=20
> 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.
=20

> > ein verteiltes Szenario ist aber ein interessanter Gedanke, nur schei=
nen
> > 80 GByte Server Festplatte dabei trotzdem zu wenig, gerade wenn eine
> > Tabelle schon über 450 GByte gross ist und stark weiter wäc=
hst.
>=20
> 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=20
450 GByte erreicht hat und das Oracle 8 Exobate an Daten verwalten kann.

Un nun bleib mal locker;D



--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

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

Quoting Andreas 'ads' Scherbaum :

> > Es gibt nicht viele Provider die eine redundante Leitung zum DECIX
> > haben, ein Rechenzentrum nach den neuesten Standards und Spitzenhardw=
are
> > zu gue=BCnstingen Discountpreisen sowie unlimited Traffic inkl.
>=20
> 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=20
> > 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.
>=20
> [X] Du hast Tablespaces nicht verstanden.
>=20
> *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=20
redest wirklich verstanden hast.

Lies mal besser selber:
http://www.postgresql.org/docs/8.0/interactive/sql-createtab lespace.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=20
> > einfach, das ist die Anforderung!
>=20
> "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.
=20
> > Downtimes und schlechte Performance bei konstanten sowie stark
> > wachsenden Userzahlen sind ein KO Kriterium und no go das unbedingt=20
> > vermieden werden muss und daher ist es Gegenstand der aktuellen
> Planspiele.
>=20
> 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.
=20

> > ein verteiltes Szenario ist aber ein interessanter Gedanke, nur schei=
nen
> > 80 GByte Server Festplatte dabei trotzdem zu wenig, gerade wenn eine
> > Tabelle schon über 450 GByte gross ist und stark weiter wäc=
hst.
>=20
> 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=20
450 GByte erreicht hat und das Oracle 8 Exobate an Daten verwalten kann.

Un nun bleib mal locker;D



--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

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

Quoting Michael Renner :

> rudi@je-more.de schrieb:
>=20
> > Es gibt nicht viele Provider die eine redundante Leitug zum DECIX
> > haben, ein Rechenzentrum nach den neuesten Standards und Spitzenhardw=
are
> > zum günstingen Discountpreis sowie unlimited Traffic inkl. Bei eine=
m
> kleinen
> > Wald und Wiesen Provider wirds meist teuer und die Leitung von und zu=
m=20
> > Inet hin ist lahm und meist muss man noch den Traffic extra bezahlen.
>=20
> Sei mir nicht bös, aber das von dem du da gerade erzählst klingt=20
> ziemlich nach Wald&Wiesen-Provider mit Fehleinschätzung der Situation=
:).

Ganz groß kann ja auch "auch" ein Problem sein, weil die ausser
Stangenwahre nichts spezielles machen, das ist eben Massengeschäft.
Zu klein kann jedoch den Nachteil haben schlecht angebunden oder technisc=
h=20
nicht auf dem hohen Niveau der großen zu sein.

Daher bin ich dort wo ich bin eigentlich recht zufrieden. Ich habe
mittlerweile angrafragt und sie würden mir auf wunsch auch biszu 4 Plat=
ten
einbauen, das Problem ist somit vorerst aus der Welt ;d

> Cheap, Fast, Reliable ist nahezu immer (ausser die Housing/Hosting=20
> Business Unit der Firma ist nicht Gewinnorientiert) ein "pick two out o=
f=20
> three".
>=20
>=20
> [..Storagewahnsinn..]
>=20
> Mit einzelnen Systemen kannst du bis zu einer gewissen Größe=20
> Blockdevicemässig wachsen. Dies wird eigentlich nur durch die Diskslo=
ts=20
> im Gehäuse bzw. die SATA/SAS-Ports am Controller beschränkt. Sinnvo=
lle=20
> RAID-Controller (zB HP Smartarray) können Volumes online extenden bzw=
..=20
> erzeugen; obs das darunterliegende OS mit Volume-Manager kann gilt es=20
> auszuprobieren.

Debian Etch 4.0 64-Bit. Über NFS mache ich einiges, aber LVM
habe ich bisher nicht angerührt, ist für PG wohl aber auch nciht empf=
ohlen,
zumindest laut Performanceguide aus der offiziellen Doku.


> Falls man Gefahr läuft relativ bald ans Limit des Gehäuses/Controll=
ers=20
> zu kommen, sollte man einen Blick in Richtung SAN werfen, die sind=20
> meistens noch eine Spur besser online erweiterbar.

Und kosten ein Vermögen ;d Das Geld muss erstmal reinkommen, dann
kann das kommen, vorher erstmal kleine Brötchen backen ohne gegen die W=
and
zu fahren. Ich bin überzeug das auch das geht ;d
=20
> Da du wieder Gefahr läufst ins 99,999999% Traumland abzudriften=20

Kann deine Ansicht diesbezüglich nicht teilen, da ich schon standalone =
MySQL
Tabellen habe die jenseits von 450 Gybte liegen und permanent anwachsen.
Die gesammt DB knackt bald die 800 GByte Grenze, daher muss das Ablöses=
ystem
mit Postgres 8.3 bald zum Zug kommen. Dabei dürfen aber die alten, schl=
echten
Attribute wie Downtimes und schlechte skalier und wartbarkeit kein Proble=
m
mehr sein.


>wärs=20
> langsam wirklich nett wenn du wo ein komplettes Konzept bzw.=20

Sorry, das ist etwas zu umfangreich ;d

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

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

rudi@je-more.de schrieb:

> Daher bin ich dort wo ich bin eigentlich recht zufrieden. Ich habe
> mittlerweile angrafragt und sie würden mir auf wunsch auch biszu 4 Pl=
atten
> einbauen, das Problem ist somit vorerst aus der Welt ;d

[..]

> Debian Etch 4.0 64-Bit. Über NFS mache ich einiges, aber LVM
> habe ich bisher nicht angerührt, ist für PG wohl aber auch nciht em=
pfohlen,
> zumindest laut Performanceguide aus der offiziellen Doku.

[..]

>> Falls man Gefahr läuft relativ bald ans Limit des Gehäuses/Control=
lers=20
>> zu kommen, sollte man einen Blick in Richtung SAN werfen, die sind=20
>> meistens noch eine Spur besser online erweiterbar.
>=20
> Und kosten ein Vermögen ;d Das Geld muss erstmal reinkommen, dann
> kann das kommen, vorher erstmal kleine Brötchen backen ohne gegen die=
Wand
> zu fahren. Ich bin überzeug das auch das geht ;d

[..]

>> wärs=20
>> langsam wirklich nett wenn du wo ein komplettes Konzept bzw.=20
>=20
> Sorry, das ist etwas zu umfangreich ;d

[..]

Echt jetzt. Sei mir nicht bös, aber mir drängt sich langsam der Verda=
cht
auf dass du in vielen Bereichen in die das ganze Reinspielt keine
Erfahrung hast _UND_ akut lernresistent bist. Wenn man selbst keine
Möglichkeit hat Sachen auszuprobieren muss man sich Leute suchen deren
Meinung man ernst nimmt, auch wenn es aus der jetzigen Perspektive
keinen Sinn macht. Alles was hier gesagt wurde lässt sich auf Wunsch mi=
t
Beispielen und Fakten untermauern, dazu muss man allerdings bereit sein
seinen eigenen Standpunkt zu wechseln und darf ihn nicht mit einem
Bolzenschussgerät vor Diskussionsbeginn in den Fels rammen.

Eine dieser Konstanten besagt, dass jede "9" hinter dem "99," bei der
Verfügbarkeit ein kleines Vermögen kostet (entweder durch entsprechen=
de
Hardware, komplexere Wartung oder hohe Setupkosten). Wenn man das nicht
im Vorfeld berücksichtigt tritt man sich sehr komplexe und entweder
unverhältnismässig teure oder wenns "billig" gelöst ist, wackelige
Systeme ein.

Bitte tu' dir selbst einen Gefallen und stell mal Anforderungen, Budget
und Realität gegenüber und schau ob das überhaupt Sinn macht, ich h=
ab
schon langsam akute Zweifel. Und lies das Scalable Internet
Architectures. Bitte.

Etwas food for thought zu diesem Thema gibts auch unter
http://highscalability.com/; sind nicht alle Sachen interessant, sind
aber immer wieder nette Beiträge dabei die den Blickwinkel etwas weiten
können.

Und so generell zu Operations oder "Was muss ich alles in meinen 99,9+%
Verfügbarkeit Berücksichtigen": http://www.sysadmin.com.au/sa-bok.htm=
l .


lg,
michael


--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

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

On Wed, 21 May 2008 16:15:26 +0200 rudi@je-more.de wrote:

> Quoting Andreas 'ads' Scherbaum :
>=20
> > > Es gibt nicht viele Provider die eine redundante Leitung zum DECIX
> > > haben, ein Rechenzentrum nach den neuesten Standards und Spitzenhardw=
are
> > > zu gue¼nstingen Discountpreisen sowie unlimited Traffic inkl.
> >=20
> > Du willst ganz viel Leistung fuer ganz wenig Geld, verstehe.
> > Ich enthalte mich weiterer Kommentare.
>=20
> Wer will das nicht?

Du bekommst aber eine Mogelpackung.
Entweder du zahlst für die Leistung, die du verlangst oder irgendwo
fehlt letztendlich etwas, worauf du dich aber verlässt.

Alles andere ist Marktwirtschaftlich Schwachsinn und deine Idee darauf
zu begründen wird dich auf keinen grünen Zweig bringen.


> > [X] Du hast Tablespaces nicht verstanden.
> >=20
> > *Grusel* Bitte beschäftige dich erst mit einem Thema, bevor =
du
> > versuchst, selbiges einzusetzen.
>=20
> Also nun frage ich mich ob Du die Doku von der Du dauernd=20
> redest wirklich verstanden hast.

Ich denke, das habe ich.



> Da steht:
> Examples
>=20
> CREATE TABLESPACE dbspace LOCATION '/data/dbs';
>=20
> Genau das führt mein Programm aus, nur der Parameter
> LOCATION eben $PGDATA/mylocation entspricht.

'/data' !=3D $PGDATA



> Was soll denn daran bitte schoen falsch sein?

Der Grund, warum man Tablespaces benutzt, steht in "Description":

http://www.postgresql.org/docs/8.3/interactive/sql-createtab lespace.html

Lass mich zitieren:

"A tablespace allows superusers to define an alternative location on
the file system where the data files containing database objects (such
as tables and indexes) can reside."

Deine Struktur, die du unterhalb von $PGDATA zementierst, ist keine
"alternative location", das ist schlicht unüberlegter Schwachsinn.
Tablespaces sind dafür gedacht, Daten auf andere Festplatten im System
auszulagern und nicht, weitere Verzeichnisse in $PGDATA anzulegen.


Der andere Grund, den du da früher genannt hattest, dass PG die
Verzeichnisse nicht alleine anlegt:

"directory: The directory that will be used for the tablespace. The
directory must be empty and must be owned by the PostgreSQL system
user. The directory must be specified by an absolute path name."

Warum sollte es - der Administrator der Datenbank bzw. des Systems
weiss selbst am besten, wo die Daten hingeschrieben werden sollen. Wenn
Tablespaces genutzt werden, soll derjenige auch festlegen, wo genau.


> Möglicherweise hast Du ja auch etwas nicht richtig verstanden,
> man lernt nie aus ;d

Ja, genau.
Und du wirst schon wieder persönlich.



> > > Weil es nun mal so ist und ohne Downtime funktionieren muss, ganz=20
> > > einfach, das ist die Anforderung!
> >=20
> > "Ohne Downtime" kann nicht die einzige Anforderung sein.
>=20
> 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.

Ohne Downtime bedeutet "100% Verfügbarkeit". Das zu realisieren nimm
dir besser erst gar nicht vor.

Wenn du so etwas versuchen wolltest, müsste deine Anwendung im
Endausbau bereits stehen, sobald dein Dienst startet. Mit allem drum
und dran, Plattenplatz, Backup und was nicht alles. Obwohl - Backup
brauchst du ja nicht. Schliesslich willst du sowieso 100% Verfügbarkeit
garantieren.

Das was du dir unter "ohne Downtime" vorstellst, ist immer ein Schnitt
aus "möglichst geringe Ausfallzeiten" und "wieviel Hardware und Leute
stehen bereit, das zu garantieren". Wenn du bei einem normalen Hoster
anfängst, hast du schon mal ~ 15 min Downtime, bevor sich irgendjemand
deines Problems annimmt. Das kratzt schon sehr an deinen 100%
Verfügbarkeit.

So, und jetzt überdenk dein Konzept noch mal und leg fest, wieviele
Neunen du hinter dem Komma stehen haben möchtest - und wie ev. die Zahl
vor dem Komma aussieht. Eine Webseite darf auch mal offline
sein. So etwas kündigt man an, richtet Wartungsfester ein und gut ist.
Wenn du den Schnittpunkt zwischen "Kosten für 100% Verfügbarkeit"=
und
"Einnahmen durch die Webseite" überschreitest, wird dich jeder Manager
zurückpfeifen und dir sagen, dass du da etwas falsch angehst.



> > > Downtimes und schlechte Performance bei konstanten sowie stark
> > > wachsenden Userzahlen sind ein KO Kriterium und no go das unbedingt=
=20
> > > vermieden werden muss und daher ist es Gegenstand der aktuellen
> > Planspiele.
> >=20
> > Marketing ...
>=20
> Tja, für irgendwen entwickelt man seine Software als Softwareentwick=
ler
> nun mal, am liebsten fue diejenigen Kunden die auch bereit sind
> dafuer zu zahlen und fuer Binsenweisheiten zahlen die Leute nun mal
> nicht viel.

"Ohne Downtime" ist die Binsenweisheit, die du hier verkaufen möchtest.
Haben dir ein paar andere hier aber auch schon geschrieben, du hörst
nunmal nicht zu.



> > > ein verteiltes Szenario ist aber ein interessanter Gedanke, nur schei=
nen
> > > 80 GByte Server Festplatte dabei trotzdem zu wenig, gerade wenn eine
> > > Tabelle schon über 450 GByte gross ist und stark weiter w=
ächst.
> >=20
> > Ich erinnere dich mal an deine eigenen Aussagen, dass du Terabyte bzw.
> > Exobyte an Daten ablegen wolltest. Da sind auch Festplatten mit 450 GB
>=20
> Ich sprach davon das eine bestimmte Tabelle bereits die Marke von=20
> 450 GByte erreicht hat und das Oracle 8 Exobate an Daten verwalten kann.

Ich möchte dich auf:

http://archives.postgresql.org/pgsql-de-allgemein/2008-05/ms g00017.php

verweisen, wo du genau das selbst schreibst.



> Un nun bleib mal locker;D

Ich bin locker, ich habe ein Archiv der Mailingliste zur Verfügung und
weiss, wie man darin sucht. Was ist dein Argument?


Bis dann

--=20
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

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

Andreas 'ads' Scherbaum schrieb:
>>>> zu guenstingen Discountpreisen sowie unlimited Traffic inkl.
>>>> =20
>>> Du willst ganz viel Leistung fuer ganz wenig Geld, verstehe.
>>> Ich enthalte mich weiterer Kommentare.
>>> =20
>> Wer will das nicht?
>> =20
>
> Du bekommst aber eine Mogelpackung.
> Entweder du zahlst für die Leistung, die du verlangst oder irgendw=
o
> fehlt letztendlich etwas, worauf du dich aber verlässt.
>
> Alles andere ist Marktwirtschaftlich Schwachsinn und deine Idee darauf
> zu begründen wird dich auf keinen grünen Zweig bringen.
> =20
Wenn ich mir mal die Website eurer Firma anschaue und deine bisherigen=20
Tätigkeiten dort mal
als Referenz ansehen kann, dann bist Du nicht unbedingt der richtig=20
Ansprechpartner in Sachen
BWL.

Vielleicht bist du ja technisch eine Leuchte, zumindest behauptest Du=20
das die ganze Zeit in dem
du mir versuchst einzureden ich hätte keine Ahnung, aber Du hast Du =
ober=20
über Mega Ahnun
ohne dabeui jedoch mal kokret zu werden. Ich verlasse mich beim=20
Webhosting Preisleistungstechnisch
auf ein gutes Mittelmaß, was Du allerdings vorschlägst ist nich=
t=20
ersichtlich - nur das alles was mein Provider
anbietet nun mal schlechter sein soll.

Coole Argumentation, das braucht man sicherlich um Consultingleistungen=20
für Leute die sich ein x für ein u
vormachen lassen, aber es bleibt zweifelhaft ob Du jemand der selber aus=20
der Branche ist so einen Unsinn
verkaufen kannst.Wenn Du es nicht bleiben lassen kannst andere=20
Systemearchitekturen zu tollerieren und
immer deine Ansichten als einzig wahrhaftige zu verkaufen solltest Du=20
besser schweigen und gar nichts mehr
sagen, denn sowas geht auf den Keks und glaubhafter wirst Du dadurch=20
bestimmt nicht.

Ist mir nun auch egal ob Du das schön findest oder nicht. Wenn ich=20
lernresistent bin, weil ich mir keinen
Unsinn von Dir erzählen lasse, dann bist Du renitent und penetrant.






--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

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

On Wed, 21 May 2008 19:50:20 +0200 rudi@je-more.de wrote:

> Wenn ich mir mal die Website eurer Firma anschaue und deine bisherigen=20
> Tätigkeiten dort mal
> als Referenz ansehen kann, dann bist Du nicht unbedingt der richtig=20
> Ansprechpartner in Sachen
> BWL.

Ich weiss ja nicht, welche Webseite du dir angeschaut hast ... aber ich
habe gar keine Webseite (für meine Firma). Erst recht brauche ich (und
habe ich auch nicht) meine Referenzen nirgendwo angeben. Mir ist also
nicht bekannt, woher du dein Halbwissen beziehst, aber vielleicht
solltest du mehr Zeit auf Dokumentation lesen und dem Aufsetzen von
Testcases verwenden anstatt herumzuraten, welche Webseite denn von mir
sein könnte. Das bringt dich und dein Projekt weiter.

Dass ich mit einigen der hier ebenfalls Postenden zusammenarbeite
genügt mir persönlich als Aussage, dass ich doch ein kleines bisc=
hen
von dem verstehe, was ich schreibe.

Mit dem Spruch hast du dich jetzt jedoch endgültig disqualifiziert.
Zuerst erzählst du hier Sachen, von denen du hinterher behauptest, das
nie gesagt zu haben (siehe z.B. Aussage über Exobyte Daten) und dann
wirst du ständig ausfallend, sobald man deine Gedankengänge komme=
ntiert
oder in Frage stellt. Konkrete Antworten auf Fragen schaffst du nicht,
aber wenn man dir daraufhin etwas vorschlägt, ist dir das zu schwammig.



Geh weg.

--=20
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

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

ist mir wirklich ein Rätsel wie sehr hier gefüttert wird.

/tm

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein