Hallo Leute,

Ich arbeite gerade an einem Projekt wo JBoss als Webserver zum Einsatz
kommt
und der Zugriff auf PostgreeSQL 8.2 via JDBC erfolgen soll. Das
Betriebssystem
das zum Einsatz kommen soll ist Debian Sarge 3.1 mit Kernel 2.6.x auf
AMD64.
(Es sei denn FreeBSD ist für den DB-Server Part mit PostgreSQL 64-Bit
auf AMD's
die bessere Wahl) ;D

Zurück zum Thema:
Ich wüsste von euch gerne wie Ihr das DB-Layout gestalten würdet und
zwar so, dass
sagen wir ca.10.000 angemeldete User keine Datenbankseitigen
Performanceprobleme
verursachen. In der Hauptbetriebszeit kommen zu 95% Inserts, Selects und
Updates
zum Zuge. Auch Volltextsuche ist ein Thema.

Mein bisheriges Vorgehen setzt komplett auf Tablespaces und Slony und
zwar in der Form
das ich die stark frequentieren Tabellen (Message, User, Interessen, und
Forums Tables) separat
in eigene Tablespaces untergebracht habe (sprich die hochfrequentieren
Tables haben alle einen
eigenen Tablespace).

Im ersten Betriebsjahr erwarte ich alleine bei der Messagetable einen
Datenvolumen von
ca. 800 GByte (und das ist noch vorsichtig geschätzt, da ich ein
Livesystem mit PHP + MySQL kenne
das unter dieser Konstellation (mit ca. 600 GByte) am Limit liegt (und
da wurden schon alle
Optimierungsregister hinsichtlich Soft + Hardware für zig tausend EUR's=

gezogen) ;D
Es geht also nicht um die Optimierung des alten Systems mit LAMP sondern
um eines
mit Postgres und JBoss.

Ich bin für jeden kleinen Geistesblitz oder konstruktive Kritik dankbar=
..
Allerdings
steht JBOSS und PostgreSQL 8.2 als Webserver und DB Gepann nicht zur
Diskussion ;d

Gruß Marc

=09
___________________________________________________________= 20
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

am Tue, dem 13.02.2007, um 9:46:53 +0100 mailte apoc9009 [at] yahoo.de folge=
ndes:
Wer?
> Mein bisheriges Vorgehen setzt komplett auf Tablespaces und Slony und
> zwar in der Form

Slony ist was zum Replizieren, nicht Optimieren.


> das ich die stark frequentieren Tabellen (Message, User, Interessen, un=
d
> Forums Tables) separat
> in eigene Tablespaces untergebracht habe (sprich die hochfrequentieren
> Tables haben alle einen
> eigenen Tablespace).

Denselben? Das wäre dann nicht so optimal. Was Du tun kannst, das auf
unterschiedliche, und zwar physikalisch unterschiedliche, zu verteilen.
Dazu auch Indexe und auch das tx-log.


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

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

>> das ich die stark frequentieren Tabellen (Message, User, Interessen, u=
nd
>> Forums Tables) separat
>> in eigene Tablespaces untergebracht habe (sprich die hochfrequentieren=

>> Tables haben alle einen
>> eigenen Tablespace).
>>
>> Denselben?
Hmm vermutlich habe ich mich undeutlich ausgedrückt "F=DCR JEDE KRITISC=
HE
TABLLE einen
EIGENEN Tablespace" ;D

z.B
Tabelle forum -> Tablespace /usr/local/mydata/tablespaces/tbl_foum
Tablle interrests ->Tablespace /usr/local/mydata/tablespaces/tbl_interres=
ts
u.s.w


>> Das wäre dann nicht so optimal. Was Du tun kannst, das auf
>> unterschiedliche, und zwar physikalisch unterschiedliche, zu verteilen=
..
>> Dazu auch Indexe und auch das tx-log.
>>
=C4hm ja, deswegen habe ich eigentlich überhaupt erst mit Tablespaces
angefangen um
genau das dann damit zu machen * ;D

Die Sache mit den Indexen sehe ich ebefalls als extrem wichtig an. Da
stellt sich
mir die Frage ob ich auch die Indexe auf verschiedene Festplatten verteil=
en
sollte. Mit der Sache mit dem TX-Log bin ich nicht ganz sicher was Du gen=
au
meinst.

Ich denke das Haupthema bleibt die stark frequentierte Messagetable mit
ca. 4 Millionen Nachrichten Operationen in 30 Tagen (und zwar immer
zu bestimmten Stosszeiten mit hohem Useraufkommen).

Hmm bei ORACLE gibt es da Partitioning. Damit kann man den Tabelleninhalt
einer sehr grossen Tabelle in verschiedene Untertabellen aufsplitten, ohn=
e
das man die eigentliche Query ändern müsste (sprich: das wendet der
DB-Server
dann intern an). Dann können Parallelprozesse jede partitionierte
Tabelle getrennt
durchsuchen und jeder Thread liefert ein Teilergebnis seiner Abfrage ab
und steuert
seinen Teil zum Gesammtergebnis der Query bei. Gibt es Table
Partitioning für
PostgreSQL 8.2 schon? Hab nix finden können....

Die Sache mit Slony ist klar, ich will damit eine Master/Slave Umgebung
schaffen
und von einem bestimmten Slave Node ein Permanetbackup fahren, damit
die Master DB nicht zu stark belastet wird (hab gehört das solche Sache=
n
unter
FreeBSD mit PostgreSQL besser laufen sollen - stimmt das??) .

Wo wir gerade dabei sind: Gibt es ein gutes Permanetbackup /
Onlinebackuptool
für Postgres 8.2 ? (Erfahrungswerte würde mich hier interressiern).

Grüße Marc







=09
=09
___________________________________________________________= 20
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Ma=
il: http://mail.yahoo.de

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

am Tue, dem 13.02.2007, um 10:35:49 +0100 mailte apoc9009 [at] yahoo.de folge=
ndes:
> Die Sache mit den Indexen sehe ich ebefalls als extrem wichtig an. Da
> stellt sich
> mir die Frage ob ich auch die Indexe auf verschiedene Festplatten verte=
ilen
> sollte. Mit der Sache mit dem TX-Log bin ich nicht ganz sicher was Du g=
enau
> meinst.

tx-log - Transaction-Log. Also diese je 16 MByte großen WAL-Dateien. Be=
i
Inserts/Updates etc. fällt da einiges an, wenn die auf derselben Platte
wie die eigentlichen Tabellen liegen bremst sich das dann.
Ich weiß ja nicht, was das Budget so hergibt...

>
> Hmm bei ORACLE gibt es da Partitioning. Damit kann man den Tabelleninha=
lt
> einer sehr grossen Tabelle in verschiedene Untertabellen aufsplitten, o=
hne
> das man die eigentliche Query ändern müsste (sprich: das wendet der=

> DB-Server

Hat PG auch, hab ich selber keine Erfahrung mit.
http://www.postgresql.org/docs/current/static/ddl-partitioni ng.html


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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

>> Hmm bei ORACLE gibt es da Partitioning. Damit kann man den Tabelleninh=
alt
>> einer sehr grossen Tabelle in verschiedene Untertabellen aufsplitten, =
ohne
>> das man die eigentliche Query ändern müsste (sprich: das wendet de=
r
>> DB-Server
>>
>
> Hat PG auch, hab ich selber keine Erfahrung mit.
> http://www.postgresql.org/docs/current/static/ddl-partitioni ng.html
>
>
> Andreas

Hi Andreas, das hört sich sehr gut an und ist genau das was ich brauche=
thx!

=09
___________________________________________________________= 20
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

apoc9009 [at] yahoo.de wrote:
> Ich wüsste von euch gerne wie Ihr das DB-Layout gestalten würdet un=
d
> zwar so, dass
> sagen wir ca.10.000 angemeldete User keine Datenbankseitigen
> Performanceprobleme
> verursachen.

Für 10000 gleichzeitige Benutzer braucht man wahrscheinlich auch erstma=
l
so um die 20 GB Hauptspeicher. Dürfte also etwas schwierig werden.

> Mein bisheriges Vorgehen setzt komplett auf Tablespaces und Slony

Slony macht ein einzelnes System langsamer. Irgendwas wird wohl die
replizierten Daten auf den Slave-Systemen auch nutzen?

> und zwar in der Form
> das ich die stark frequentieren Tabellen (Message, User, Interessen,
> und Forums Tables) separat
> in eigene Tablespaces untergebracht habe (sprich die
> hochfrequentieren Tables haben alle einen
> eigenen Tablespace).

Viel wichtiger wäre es, WAL und Indexe auf eigene Platten zu legen.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Peter Eisentraut schrieb:
> apoc9009 [at] yahoo.de wrote:
>
>> Ich wüsste von euch gerne wie Ihr das DB-Layout gestalten würdet u=
nd
>> zwar so, dass
>> sagen wir ca.10.000 angemeldete User keine Datenbankseitigen
>> Performanceprobleme
>> verursachen.
>>
>
> Für 10000 gleichzeitige Benutzer braucht man wahrscheinlich auch erst=
mal
> so um die 20 GB Hauptspeicher. Dürfte also etwas schwierig werden.
>
10.000 User sind nicht gleichzeitig an der DB angemeldet!
Nur wenn ein User auf der Website einen Button oder Link klickt, wird im
Normalfall eine Query gestartet.
Das ganze wird vom J2EE-Server via Connectionpool verwaltet. Also wenn
10 User eine Connection brauchen,
muss der Connectionpooler im Idealfall nur eine Verbindung
bereitstellen, über die alle Anfragen abgewickelt werden
können. Falls das nicht reicht, eröffnet er automatisch eine neue
Connection und verwaltet die inaktiven für neue
Verbindungsanfragen oder schließt die nicht mehr benötigten selbstä=
tig
(tja, ein ausgeklügeltes DB-Interface
ist schon eine feine Sache - vor allem wenn man sich nicht groß drum
kümmern muss) ;D

By the Way: Mit Connect and Close after Operation kann man das auch mit
LAMP hinbekommen,
nur ist das wirklich hässlich (das derzeit aktive System arbeit auf
dieser Basis).

> Slony macht ein einzelnes System langsamer. Irgendwas wird wohl die
> replizierten Daten auf den Slave-Systemen auch nutzen?
>
Das sehe ich eigentlich nicht so kritisch, weil der erste Slave soll nur
für das permanente
Onlinebackup verantwortlich sein soll. Ich will kein ständiges Backup
auf der Master DB
haben. Und Onlinebackup ist absolut erforderlich. Wir rechnen mit ca.
über 1 Million
registrierter User, von denen am Abend ca. 10.000 Online sind auf der
Website.

Da geht es nicht ohne Permanentbackup, da sich über den Tag hinweg
extrem viele
Datenbei den Usern, im Forum und besonders in der Message Table ändern.

Aber Oninebackups für Datenbanken sind ja keine Neuigkeit. Andere Syste=
me
wie MaxDB oder ORACLE haben das schon lange oder man kann es mit DB
Options gänginger Backuppakete wie das von Veritas oder Legato nachrü=
sten.
Ich brauche halt ein ähnliches System für PostgreSQL und besten Fall
OpenSource.
> Viel wichtiger wäre es, WAL und Indexe auf eigene Platten zu legen.
Das sehe ich genau so (danke nochmals an Andreas)und werde das auf jeden
Fall mit
einbauen. Ich Frage mich allerdings ob das eine Sache mit der
heißgestrickten Nadel
ist oder ob PG dafür eigene Befehle anbietet um die WAL Files auszulage=
rn
(Indexe dürften ja in Tablespaces verfrachtbar sein).

Wie steht es eigentlich mit ALTER Tablespace? Kann man Tablespaces
"System konform" bei laufendem DB-System verlagern? Beispielsweise
wenn ich eine neue Festplatte eingebaut habe und auf diese Platte nun
ein bereits existierender Tablespace untergebracht werden soll?

Ich möchte sowas ehrlich gesagt nicht gerne von Hand verschieben
und später crasht mir die DB. Ein ALTER Tablespace sowie zugehöriges
verschieben der Datafiles des Tablespaces mit dem PG Client habe ich
bisher nicht gefunden.




Gruß Marc

=09
___________________________________________________________= 20
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

apoc9009 [at] yahoo.de wrote:
> > Slony macht ein einzelnes System langsamer. Irgendwas wird wohl die
> > replizierten Daten auf den Slave-Systemen auch nutzen?
>
> Das sehe ich eigentlich nicht so kritisch, weil der erste Slave soll
> nur für das permanente
> Onlinebackup verantwortlich sein soll. Ich will kein ständiges Backup
> auf der Master DB
> haben.

Also ich weiß ja nicht was du da genau vorhast oder ob du überhaupt
weißt, dass PostgreSQL auch "Online Backup" kann, aber auf jeden Fall
kann ich mir an einer Hand ausrechnen, dass Datenbank + Slony + Backup
vom Slony-Slave langsamer und unzuverlässiger ist als Datenbank +
Backup direkt.

> Wie steht es eigentlich mit ALTER Tablespace? Kann man Tablespaces
> "System konform" bei laufendem DB-System verlagern? Beispielsweise
> wenn ich eine neue Festplatte eingebaut habe und auf diese Platte nun
> ein bereits existierender Tablespace untergebracht werden soll?

Mach nen neuen Tablespace und verschieb die Objekte dann dahin. Ist
nicht ganz so nett, aber kommt auf's selbe hinaus. Oder nimm gleich
LVM.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Peter Eisentraut schrieb:
> apoc9009 [at] yahoo.de wrote:
>
>>> Slony macht ein einzelnes System langsamer. Irgendwas wird wohl die
>>> replizierten Daten auf den Slave-Systemen auch nutzen?
>>>
>> Das sehe ich eigentlich nicht so kritisch, weil der erste Slave soll
>> nur für das permanente
>> Onlinebackup verantwortlich sein soll. Ich will kein ständiges Backu=
p
>> auf der Master DB
>> haben.
>>
>
> Also ich weiß ja nicht was du da genau vorhast oder ob du überhaupt=

> weißt, dass PostgreSQL auch "Online Backup" kann, aber auf jeden Fall=

> kann ich mir an einer Hand ausrechnen, dass Datenbank + Slony + Backup
> vom Slony-Slave langsamer und unzuverlässiger ist als Datenbank +
> Backup direkt.
>
Nee, das geht nicht. Um einvollständiges Backup zu fahren müsste ich =
de
DB herrunterfahren und
Du kannst Dir sicher denken das bei einer DB von 1 > Terrabyte und
grösser ein tägliches
Backup einfach nicht in Frage kommt. Die Downtimes währen astronomisch
und die
Datenlücken zu heftig. Deswegen muss ein Onlinebackup her (wie bei
ORACLE oder DB2)
her, das die =C4nderungsdaten on the Fly wegschreibt. Nur so lässt sich=

das überhaupt
regeln.
>
>> Wie steht es eigentlich mit ALTER Tablespace? Kann man Tablespaces
>> "System konform" bei laufendem DB-System verlagern? Beispielsweise
>> wenn ich eine neue Festplatte eingebaut habe und auf diese Platte nun
>> ein bereits existierender Tablespace untergebracht werden soll?
>>
> Mach nen neuen Tablespace und verschieb die Objekte dann dahin. Ist
> nicht ganz so nett, aber kommt auf's selbe hinaus. Oder nimm gleich
> LVM.
LVM ist keine gute Option. Der J2EE Server als Webapplicationlayer wurde
nicht ohne Grund
gewählt. Es kann gut passieren das einer der Slaves ein Windows 64-Bit
Server ist und dann
muss das ganze immer noch korrekt funktionieren, daher sind mir
PostgreSQL Mehtoden lieber.

Wie meinst Du das eigentlich? Soll ich einen 800 GByte Tablespace (so
groß ist
alleine die Message-Table) einfach mittels PSQL in einen neuen
Tablespace kopieren??
Geht das auch im laufenden Betrieb? An der Seite wird ständig gearbeite=
t
werden,
wir wollen aber so wenig downtimes wie nur irgend möglich.






=09
=09
___________________________________________________________= 20
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Ma=
il: http://mail.yahoo.de

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

am Tue, dem 13.02.2007, um 11:59:59 +0100 mailte apoc9009 [at] yahoo.de folge=
ndes:
> >Also ich weiß ja nicht was du da genau vorhast oder ob du überhaup=
t
> >weißt, dass PostgreSQL auch "Online Backup" kann, aber auf jeden Fal=
l
> >kann ich mir an einer Hand ausrechnen, dass Datenbank + Slony + Backup=

> >vom Slony-Slave langsamer und unzuverlässiger ist als Datenbank +
> >Backup direkt.
> >
> Nee, das geht nicht. Um einvollständiges Backup zu fahren müsste ic=
h de
> DB herrunterfahren und
> Du kannst Dir sicher denken das bei einer DB von 1 > Terrabyte und
> grösser ein tägliches
> Backup einfach nicht in Frage kommt. Die Downtimes währen astronomisc=
h
> und die
> Datenlücken zu heftig. Deswegen muss ein Onlinebackup her (wie bei
> ORACLE oder DB2)
> her, das die =C4nderungsdaten on the Fly wegschreibt. Nur so lässt si=
ch
> das überhaupt
> regeln.

Erst lesen, dann antworten. Das, was ich in einer anderen Mail zu den
TX-Dateien sagte, _ist_ quasi das Online-Backup. Du kannst z.B. diese
WAL-Files übers Netz auf einer anderen Kiste einlesen, die dann synchro=
n
läuft. Das Problem ist nur, daß sich diese WAL-Files auf den Stand de=
r
letzten Sicherung es Filesystems beziehen. Aber auch das kannst Du ohne
Stillstand der DB machen.

http://www.postgresql.org/docs/8.2/interactive/backup.html


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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

apoc9009 [at] yahoo.de wrote:
> Nee, das geht nicht. Um einvollständiges Backup zu fahren müsste ic=
h
> de DB herrunterfahren

Das ist ja sehr interessant. Und du bist dir sicher, dass du da auch
wirklich PostgreSQL hast?

> Deswegen muss ein Onlinebackup her (wie bei ORACLE oder DB2)
> her, das die =C4nderungsdaten on the Fly wegschreibt.

Richtig. Gibt's doch. Nimm's doch einfach.

> Es kann gut passieren das einer der
> Slaves ein Windows 64-Bit Server ist und dann muss das ganze immer
> noch korrekt funktionieren,

Oha. Dann mal viel Spaß.

> Wie meinst Du das eigentlich? Soll ich einen 800 GByte Tablespace (so
> groß ist
> alleine die Message-Table) einfach mittels PSQL in einen neuen
> Tablespace kopieren??
> Geht das auch im laufenden Betrieb? An der Seite wird ständig
> gearbeitet werden,
> wir wollen aber so wenig downtimes wie nur irgend möglich.

Sachen zwischen Tablespaces verschieben geht natürlich nur, wenn der
Zugriff zwischendurch blockiert wird.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo [at] postgresql.org so that your
message can get through to the mailing list cleanly

> Erst lesen, dann antworten.
Dann fang mal an damit, denn ich habe nichts übersehen aber vielleicht =
Du?
Das Thema Partitioning und Slony ist ein anders, deswegen muss das für
Bachupzwcke nicht gleichbedeutend sein. Also, ließt "Du" selber erstmal=

und schreibe dann.

> Das, was ich in einer anderen Mail zu den
> TX-Dateien sagte, _ist_ quasi das Online-Backup. Du kannst z.B. diese
> WAL-Files übers Netz auf einer anderen Kiste einlesen, die dann synch=
ron
> läuft. Das Problem ist nur, daß sich diese WAL-Files auf den Stand =
der
> letzten Sicherung es Filesystems beziehen. Aber auch das kannst Du ohne
> Stillstand der DB machen.
>
> http://www.postgresql.org/docs/8.2/interactive/backup.html
>
>
> Andreas
>

Das ist mir bekannt und nicht wirklih eine Adäquate Lösung.
Soll ich jetzt von irgendwelchen Skripten ständig die TX Logs Files
sichern lassen oder
wie? Das kann man wohl kaum ein seriöses Onlinebackup nennen, denn
darunter verstehe
ich wesentlich mehr als eine Ansammlung von per Skript erzeugten Files!


=09
___________________________________________________________= 20
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On Tue, 13 Feb 2007 11:59:59 +0100
"apoc9009 [at] yahoo.de" <apoc9009 [at] yahoo.de> wrote:

> Peter Eisentraut schrieb:
> > Also ich weiß ja nicht was du da genau vorhast oder ob du überhaupt=

> > weißt, dass PostgreSQL auch "Online Backup" kann, aber auf jeden Fall=

> > kann ich mir an einer Hand ausrechnen, dass Datenbank + Slony + Backup=

> > vom Slony-Slave langsamer und unzuverlässiger ist als Datenbank +
> > Backup direkt.
> >
> Nee, das geht nicht. Um einvollständiges Backup zu fahren müsste ich =
de
> DB herrunterfahren und Du kannst Dir sicher denken das bei einer DB
> von 1 > Terrabyte und grösser ein tägliches Backup einfach nicht in =
Frage kommt.

Ich bin mir dagegen sicher, das du Peters Antwort nicht richtig gelesen
hast.

Hint:
http://www.postgresql.org/docs/current/static/backup-online. html


> Die Downtimes währen astronomisch und die
> Datenlücken zu heftig. Deswegen muss ein Onlinebackup her (wie bei
> ORACLE oder DB2) her, das die =C4nderungsdaten on the Fly wegschreibt.
> Nur so lässt sich das überhaupt regeln.

Zu einem Backup gehört immer auch ein Restore. Auch darüber würde ich
mir Gedanken machen.


> LVM ist keine gute Option. Der J2EE Server als Webapplicationlayer wurde
> nicht ohne Grund gewählt.

Wir sprachen von Dateien für die Datenbank auf dem LVM, richtig?
Wen interessiert an dieser Stelle, wer die Daten aus der Datenbank
nutzen möchte?


Bye

--
Andreas 'ads' Scherbaum
Deutsche PostgreSQL Usergroup: http://www.pgug.de
DPWN: http://ads.wars-nicht.de/blog/categories/18-PWN

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo [at] postgresql.org so that your
message can get through to the mailing list cleanly

am Tue, dem 13.02.2007, um 12:42:49 +0100 mailte apoc9009 [at] yahoo.de folge=
ndes:
>
> >Erst lesen, dann antworten.
> Dann fang mal an damit, denn ich habe nichts übersehen aber vielleich=
t Du?

Ja, vermutlich die Stelle von mir selbst, die Dich zu solchen Antworten
nötigt. Außerdem sehe noch immer statt eines Namens eine sinnfreie
Zeichenfolge.


> >http://www.postgresql.org/docs/8.2/interactive/backup.html
>
> Das ist mir bekannt und nicht wirklih eine Adäquate Lösung.
> Soll ich jetzt von irgendwelchen Skripten ständig die TX Logs Files
> sichern lassen oder
> wie? Das kann man wohl kaum ein seriöses Onlinebackup nennen, denn

Dazu braucht man kein Script, sondern nur eine Konfig-Option. Und zwar
für archive_command. Das geht in einem Einzeiler.

Ansonsten ist jetzt erst mal EOD, nicht das das hier noch komplett
abdriftet.


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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Tue, 13 Feb 2007 12:42:49 +0100
"apoc9009 [at] yahoo.de" <apoc9009 [at] yahoo.de> wrote:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Kauf dir einen Namen.

Hallo,

> Das ist mir bekannt und nicht wirklih eine Adäquate Lösung.
> Soll ich jetzt von irgendwelchen Skripten ständig die TX Logs Files
> sichern lassen oder wie? Das kann man wohl kaum ein seriöses
> Onlinebackup nennen, denn darunter verstehe ich wesentlich mehr
> als eine Ansammlung von per Skript erzeugten Files!

Ich weiss zwar nicht, was du sonst noch so unter Online Backup,
also einem Backup im laufenden Betrieb verstehst, aber lass gut sein.

Andere Möglichkeiten hat PostgreSQL nicht für dich, geh und kauf dir
eine Oracle oder eine DB2, dort weisst du ja bereits, dass Online
Backup genau so funktioniert, wie du das haben möchtest.


Bye

--
Andreas 'ads' Scherbaum
Deutsche PostgreSQL Usergroup: http://www.pgug.de
DPWN: http://ads.wars-nicht.de/blog/categories/18-PWN

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo [at] postgresql.org so that your
message can get through to the mailing list cleanly

apoc9009 [at] yahoo.de wrote:
> Soll ich jetzt von irgendwelchen Skripten ständig die TX Logs Files
> sichern lassen oder
> wie? Das kann man wohl kaum ein seriöses Onlinebackup nennen, denn
> darunter verstehe
> ich wesentlich mehr als eine Ansammlung von per Skript erzeugten
> Files!

Wie denn sonst?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Tue, 13 Feb 2007 09:46:53 +0100, "apoc9009 [at] yahoo.de" <apoc9009 [at] yahoo.de> wrote:

[...]

> Zurück zum Thema:
> Ich wüsste von euch gerne wie Ihr das DB-Layout gestalten würdet und
> zwar so, dass
> sagen wir ca.10.000 angemeldete User keine Datenbankseitigen
> Performanceprobleme
> verursachen. In der Hauptbetriebszeit kommen zu 95% Inserts, Selects und
> Updates
> zum Zuge. Auch Volltextsuche ist ein Thema.
>
> Mein bisheriges Vorgehen setzt komplett auf Tablespaces und Slony und
> zwar in der Form
> das ich die stark frequentieren Tabellen (Message, User, Interessen, und
> Forums Tables) separat
> in eigene Tablespaces untergebracht habe (sprich die hochfrequentieren
> Tables haben alle einen
> eigenen Tablespace).

Das ist sinnvoll, alternativ kannst du mit constraint exclusion die "heißen"
Tabellen partitionieren, sprich nach einem bestimmten Kriterium einteilen (z.B.
Woche, Monat, User-Prefix etc.). Ich weiß nicht, ob du viel historischen Krams
mit in die Datenbank aufnehmen mußt, aber eine geschickte Partitionierung
erleichtert dann auch das spätere "ausmisten".

Denk auch dran WAL und Index auf separate Spindeln zu legen. Vor allem pg_xlog
auf einer separaten Disk beschleunigt den Transaktions-Durchsatz erheblich.

>
> Im ersten Betriebsjahr erwarte ich alleine bei der Messagetable einen
> Datenvolumen von
> ca. 800 GByte (und das ist noch vorsichtig geschätzt, da ich ein
> Livesystem mit PHP + MySQL kenne
> das unter dieser Konstellation (mit ca. 600 GByte) am Limit liegt (und
> da wurden schon alle
> Optimierungsregister hinsichtlich Soft + Hardware für zig tausend EUR's
> gezogen) ;D

600Gig mit MySQL...Respekt.

[...]

Bernd

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo [at] postgresql.org so that your
message can get through to the mailing list cleanly

Am 13.02.2007 um 12:42 schrieb apoc9009 [at] yahoo.de:

>> Erst lesen, dann antworten.
> Dann fang mal an damit, denn ich habe nichts übersehen aber
> vielleicht Du?

He Leute, ich finde es schon etwas schmerzhaft, hier
solche Schlachten mitzulesen, das ist die Sache nicht
wert. Ich glaube nicht, dass man die Verbreitung von
Postgres foerdern kann, indem man sich mit so jemand
in einen Streit begibt.

Jemand, der Datenbanken im Terabyte Bereich wartet,
hat Geld in der Hand, allein schon der Hardware
wegen, die er nutzt. Ich glaube, ihr muesst Euch
von so jemand nicht von der Seite anpissen lassen.
Wenn er kostenlosen qualifizierten Support abgreifen
will, dann soll er wenigstens freundlich bleiben und
sich erst mal an den Stil hier gewoehnen.

Ihr wisst, was ihr drauf habt und muesst Euch vor
niemand beweisen. Vielleicht ist das Ganze ja auch
nur ein Fake und er muggelt zu Hause als Moechtegern
an seinem Kinderkram rum. Ihr koennt Euer Knowhow zu
vernuenftigen Stundensaetzen direkt anbieten. Nur so
ein Tip.

Gruss, Christian


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

> Ich denke auch, das eine "Hot-Standby-Lösung" für Marc eine Lösun=
g wäre.
> Man hat zwar den WAL-Traffic, spart sich aber den nicht unerheblichen O=
verhead
> von Slony. Slony wird dann interessant, wenn man SELECT-Anfragen über=
versch.
> Nodes clustern will....
>
> Vielleicht sollte man bei dieser Größenordnung dann auch Hochverfü=
gbarkeit mit
> in Erwägung ziehen.
>
Also SLONY werde ich wohl ohnehin benötigen, da das DB Datenvolumen
irgendwann so groß werden wird,
dass ein einzelner, angemieteter Rootserver mit 2 oder 4 GByte RAM +
AMD64 CPU und RAID 1 + redundanter
680 MBit's Anbindung irgendwann nicht mehr ausreichen wird. An der Setup
Spezifikation der Server kann
ich nichts ändern. Allerdings kann ich beim Provider mehrere solcher
Rackserver buchen die alle im gleichen
LAN stehen und für den LAN-Traffc muss ich nichts bezahlen.

Für das Backup steht ein Hochverfügbarkeits SAN-Storage System zur
verfügung, auf das ich
über das interne Provider Netz die SLONY oder Online Backupdaten sowie
das SW
Loadbalancing routing der J2EE Server abwickeln kann.

Da die Webserver (oder rchtiger J2EE Webapplicationserver) im gleichen
LAN stehen,
möchte ich die einzelnen Slavenodes nur für Read Only Abfragen benutz=
en
und auf der
SLONY Master DB Schreib und Updateoperationen ausführen.

Das ist momenten zumindest mein vorläufiger Plan wie ich es umsetzen wi=
ll.
Alles muss so sein, das es im laufenden Betrieb zu keinen Störungen b.z=
..w
Downtimes kommt.

>> Das ist mir bekannt und nicht wirklih eine Adäquate Lösung.
>> Soll ich jetzt von irgendwelchen Skripten ständig die TX Logs Files
>> sichern lassen oder
>> wie? Das kann man wohl kaum ein seriöses Onlinebackup nennen, denn
>> darunter verstehe
>> ich wesentlich mehr als eine Ansammlung von per Skript erzeugten Files=
!
>>
>
> Warum nicht?
>
> DB2 und Konsorten machen das auch nicht anders. Oracle hat RMAN, der im
> Hintergrund aber auch nichts anderes macht. Ferner können dadurch auc=
h
> Backup-Infrastrukturen wie IBM Tivoli usw. einfach eingebunden werden. =
Man
> ist sehr flexibel durch diese Technik und diese hat sich auch bei den "=
großen"
> bewährt.
>
> Bernd
>
Ich kenne das PG Backup momentan noch nicht in allen Details, aber meine
ersten Tests haben
schon gezeigt das ein Dump nicht das gwünscht Resultat erzeugt. Vor
allem habe ich Probleme
damit die komplette DB inkl. Tablespaces wiederherzustellen und im
Notfall will ich vorbereitet
sein und nicht rumrätseln müssen. Vielleicht gibt es das was ich
benötige noch nicht, dann werde
ich es wohl selber basteln müssen oder das was noch fehlt ergänzen.


=09
___________________________________________________________= 20
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

> Zu einem Backup gehört immer auch ein Restore. Auch darüber würde=
ich
> mir Gedanken machen.
>
>
>
Echt? Da wäre ich ja echt nie drauf gekommen!

>> LVM ist keine gute Option. Der J2EE Server als Webapplicationlayer wur=
de
>> nicht ohne Grund gewählt.
>>
>
> Wir sprachen von Dateien für die Datenbank auf dem LVM, richtig?
> Wen interessiert an dieser Stelle, wer die Daten aus der Datenbank
> nutzen möchte?
>

Ich spreche überhaupt nicht von LVM weil die Server Betriebssysteme fü=
r
Appserver und DB mal
Linux, mal Unix und mal Windows sein können. Auc kann ich mir
Hardwareseitigen Bedingungen
nicht aussuchen. Ich muss mit den Euipment auskommen das auch
tatsächlich zur Verfügung steht
da bringen mir irgendwelche Praxisfernen LVM Szenarien Tips nicht
wirklich etwas.

=09
___________________________________________________________= 20
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

apoc9009 [at] yahoo.de wrote:
> Ich kenne das PG Backup momentan noch nicht in allen Details, aber
> meine ersten Tests haben
> schon gezeigt das ein Dump nicht das gwünscht Resultat erzeugt.

Ein Dump ist hier in der Tat nicht angebracht, aber um einen Dump geht's
auch gar nicht.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

>
> Wenn er kostenlosen qualifizierten Support abgreifen
> will, dann soll er wenigstens freundlich bleiben und
> sich erst mal an den Stil hier gewoehnen.

Wer will hier Support?
Ich bin selbst seit 17 Jahren in der Softwareentwicklung und ich bekomm=
e
meine Projekte immer irgendwie zum laufen, dazu brauche ich deine
kommerziellen, kostenpflichtigen Supportofferten ganz sicher nicht.
Und ganz sicher würde ich ein Support Angebot, das sich mit einer
so billigen Provokation ins Gespräch bringt nicht wirklich ernsthaft
in betract ziehen.

Meine Fragestellung dreht sich um Komzeptionelle Dinge. Wie man
verschiedene Dinge mittels PostgreSQL 8.2.3.x in so einem Projekte
sinnvoll einbauen kann. Die Arbeit und Realisierung mache ich selber.




=09
=09
___________________________________________________________= 20
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Ma=
il: http://mail.yahoo.de

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

T24gMi8xMy8wNywgYXBvYzkwMDlAeWFob28uZGUgPGFwb2M5MDA5QHlhaG9v
LmRlPiB3cm90ZToKCj4gV2VyIHdpbGwgaGllciBTdXBwb3J0PwoKRHUgZ2Fu
eiBvZmZlbnNpY2h0bGljaCwgZGVubiBzb25zdCB3w7xyZGVzdCBEdSBoaWVy
IGtlaW5lIEZyYWdlbgpzdGVsbGVuLCBkaWUgbWFuIHByb2JsZW1sb3MgYXVz
IGRlciBEb2t1bWVudGF0aW9uIGVudG5laG1lbiBrYW5uLgoKV2VubiBEdSBl
aW4gT25saW5lLUJhY2t1cCBoYWJlbiB3aWxsc3QsIGhhbHRlIERpY2ggYW4g
ZGllIEFubGVpdHVuZwpkYXp1LiBQb3N0Z3JlU1FMIGJpZXRldCBEaXIgZGll
IE3DtmdsaWNoa2VpdCwgZGFzIGF1Znp1emllaGVuLiBEdQprYW5uc3QgaW0g
QmV0cmllYiBkaWUgRGF0ZW4gcGVyIEZTIEtvcGllIChtaXQgZGVtIFRvb2wg
RGVpbmVyIFdhaGwpCnNpY2hlcm4gdW5kIGRhbm4gZGllIFdBTCBGaWxlcyBh
cmNoaXZpZXJlbiBsYXNzZW4gYnp3LiBhdWYgZWluZW0KQmFja3VwLVNlcnZl
ciAiYWJzcGllbGVuIiwgc29kYcOfIER1IGltbWVyIGVpbmUgS29waWUgRGVp
bmVyIERCIGhhc3QsCmRpZSBtYXggZWluIFdBTCBGaWxlICgxNk1CIGFuIMOE
bmRlcnVuZ2VuIGluIGRlciBEYXRlbmJhbmspIGhpbnRlcmhlcgppc3QuCgpT
byB3aGF0PyBXYXMgaXN0IERlaW4gUHJvYmxlbT8gV2VpdGVyZSBGcmFnZW4g
c29sbHRlc3QgRHUgZG9ydApzdGVsbGVuLCB3byBtYW4gRGlyIGRpZSBaZWl0
IGluIFJlY2hudW5nIHN0ZWxsdCwgZGEgRHUgamEgYW5zY2hlaW5lbmQKc28g
b2RlciBzbyBtZWhyIMO8YmVyIFBvc3RncmVTUUwgd2Vpw590LCBhbHMgZGll
IEFud2VzZW5kZW4gLi4uCgpjdWcKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLShlbmQgb2YgYnJvYWRjYXN0KS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLQpUSVAgNzogWW91IGNhbiBoZWxwIHN1cHBvcnQgdGhlIFBvc3RncmVT
UUwgcHJvamVjdCBieSBkb25hdGluZyBhdAoKICAgICAgICAgICAgICAgIGh0
dHA6Ly93d3cucG9zdGdyZXNxbC5vcmcvYWJvdXQvZG9uYXRlCg==

apoc9009 [at] yahoo.de <apoc9009 [at] yahoo.de> schrieb:

Eigentlich wollt ich Dir 'apoc9009 [at] yahoo.de' nicht mehr antworten, unter
anderem schon wegen dem 'apoc9009 [at] yahoo.de', aber vor allem wegens dem
Tonfall, den Du hier anschlägst. Aber einen Versuch mache ich noch:

>
> >Zu einem Backup gehört immer auch ein Restore. Auch darüber würd=
e ich
> >mir Gedanken machen.
> >
> Echt? Da wäre ich ja echt nie drauf gekommen!

Möglicherweise hat Andreas S. das geahnt...
FdI#125 ;-)

>
> >>LVM ist keine gute Option. Der J2EE Server als Webapplicationlayer wu=
rde
> >>nicht ohne Grund gewählt.
> >>
> >Wir sprachen von Dateien für die Datenbank auf dem LVM, richtig?
> >Wen interessiert an dieser Stelle, wer die Daten aus der Datenbank
> >nutzen möchte?
> >
>
> Ich spreche überhaupt nicht von LVM weil die Server Betriebssysteme f=
ür
> Appserver und DB mal
> Linux, mal Unix und mal Windows sein können. Auc kann ich mir

In Deiner ersten Mail war die Rede von Debian als OS des DB-Servers. Und
es geht hier nur um diesen.


> Hardwareseitigen Bedingungen
> nicht aussuchen. Ich muss mit den Euipment auskommen das auch tatsäch=
lich
> zur Verfügung steht
> da bringen mir irgendwelche Praxisfernen LVM Szenarien Tips nicht wirkl=
ich
> etwas.

Du scheinst keinen blassen Schimmer zu haben, was mit LVM gemeint ist,
stimmts? Das an sich ist kein Problem, Du könntest nachfragen und/oder
eine Suchmaschine Deines geringsten Mißtrauens vergewaltigen. Aber Du
findest den dümmsten aller Wege: diejenigen, die Dir helfen wollen, dum=
m
von der Seite anzupissen.

Das Dein Verhalten hier nur sehr bedingt geeignet ist, einklich gar
nicht bzw. komplett kontraproduktiv ist, hier noch weitere Hilfe und
Ratschläge zu erhalten, haben Dir nun Peter, Christian und 2 mal Andrea=
s
versucht klarzumachen. Du trittst aber weiter munter auf wie der
Geisterfahrer, der im Radio die Warnung vor dem Geisterfahrer vernimmt
und sich wundert: 'einer? hunderte!!1elf'


Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknow)
Kaufbach, Saxony, Germany, Europe. N 51.05082=B0, E 13.56889=
=B0

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Andreas Kretschmer schrieb:
> Du scheinst keinen blassen Schimmer zu haben, was mit LVM gemeint ist,
>
Wenn es Dir besser gefällt (und das scheint der Fall) dann glaub das
einfach mal und komm wieder
runter.

> stimmts? Das an sich ist kein Problem, Du könntest nachfragen und/ode=
r
> eine Suchmaschine Deines geringsten Mißtrauens vergewaltigen. Aber Du
> findest den dümmsten aller Wege: diejenigen, die Dir helfen wollen, d=
umm
> von der Seite anzupissen.
>

Hier wird keiner angepisst aber wenn ich dumme oder völlig beknackte
Antworten erhalte
dann muss man sich über etwas Spott einfach nicht wundern.

z.B. Ich schreibe:
Ich habe alle kritischen Tabellen in Tablespaces verfrachtet...

und die Antwort eines Posters lautet....
"Es ist aber sehr ungünstig wenn du alles in einen Tablespace packst" L=
OL

oder z.B thema Backup:

"Wenn Du ein Backup machst, musst Du auch an ein Restore denken"...LOL*

oder z.B LVM in gemixten Server umgebungen (ich schrieb schon am Anfang
das der DB-Server auch auf Windows läuft, wo definitiv LVM "nicht
verfügbar ist"

Nachdem das dann geklärt wurde, kommt noch so ein Depp und faselt was v=
on
"Wenn Du kostenpflichtigen Support willst, dann musst Du auch bezahlen"

Dabei sollte das eine allgemeine Diskussions zum Thema PostgreSQL 8.2.3.x=
in
Heavy Load Website Projekten. Ich schätze wenn es einigen Leuten schon =
so
extrem schwer fällt beim eigentlichen Thema zu bleiben, sollte
diejenigen sich einfach
besser geschlossen halten.

Hier waren bisher nur 2 Interressante Punkte in der Debatte.

1. Partitioning via Vererbung (auch wenns für Historische Daten nicht
praktikabel ist)
2. TX Logs Auslagerung auf seperate Platten.
3.Tablespaces im laufenden Betrieb mit Bordmitteln zu verschieben.

Es ist schon lustig, wenn einem "keine Ahnung" unterstellt wird, wenn
derjeniege
die ganzen "googlebaren" Stichworte für die Diskussion im richtigen
Kontext liefert
und dann von so einem Noob erzählt bekommt wie wenig er doch eigentlich=

weiß.


(nachdem er dann gegoogelt hat)


Zum Thema immer nett bleiben. Ich glaube nicht das ich mich als erstes im
Ton vergriffen, sondern den Ball eher zurückgespielt habe. So und nun
hoffe ich
mal das sich hier noch ein paar Leute mit "Wissen",
"Abstraktionsvermögen" und
geistiger Reife unterwegs sind, die es nicht nötig haben sich über
triviale Themen der
IT zu produzieren.

bye

=09
___________________________________________________________= 20
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

apoc9009 [at] yahoo.de <apoc9009 [at] yahoo.de> schrieb:
> Ton vergriffen, sondern den Ball eher zurückgespielt habe. So und nun=
hoffe
> ich
> mal das sich hier noch ein paar Leute mit "Wissen", "Abstraktionsvermö=
gen"
> und
> geistiger Reife unterwegs sind, die es nicht nötig haben sich über =
triviale
> Themen der
> IT zu produzieren.

Danke, das Du nun gehen willst.


Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknow)
Kaufbach, Saxony, Germany, Europe. N 51.05082=B0, E 13.56889=
=B0

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

On Tue, 13 Feb 2007 16:27:27 +0100
"apoc9009 [at] yahoo.de" <apoc9009 [at] yahoo.de> wrote:

> > Zu einem Backup gehört immer auch ein Restore. Auch darüber würde=
ich
> > mir Gedanken machen.
> >
> Echt? Da wäre ich ja echt nie drauf gekommen!

Wie dir andere schon gesagt haben, mäßige deinen Ton doch mal bitte.
Ich habe dir den Hinweis gegeben, das du dir bei deinem Backup Konzept
auch Gedanken über das Wiedereinspielen machen sollst. Nicht ohne Grund:
Zum einen müsstest du jedes deiner Backups eigentlich testen, ob sie auch
funktionieren -> ergo brauchst du noch mal irgendwo einen Server, der das
übernehmen kann. Und zum anderen dauert ein Wiedereinspielen eine
gewisse Zeit und in dieser Zeit ist deine Anwendung dann garantiert offline.
Also macht es durchaus Sinn, sich vorher Gedanken zu machen, wie lange
ich im Falle des Falles für das Restore brauche und wie ich dabei am
besten vorgehen kann.

Wenn du allerdings jeden Ratschlag bloss mit Kommentaren und
einem Hinweis, dass du das sowieso schon alles weisst, beantwortest:

Warum bist du überhaupt noch hier?


> >> LVM ist keine gute Option. Der J2EE Server als Webapplicationlayer wur=
de
> >> nicht ohne Grund gewählt.
> >
> > Wir sprachen von Dateien für die Datenbank auf dem LVM, richtig?
> > Wen interessiert an dieser Stelle, wer die Daten aus der Datenbank
> > nutzen möchte?
>
> Ich spreche überhaupt nicht von LVM weil die Server Betriebssysteme f=
ür
> Appserver und DB mal
> Linux, mal Unix und mal Windows sein können.

Wenn du zu dem Problem kommst, das deine DB unter Windows laufen soll,
dann fang dort noch einmal an dir Gedanken zu machen, wie du das am
sinnvollsten aufsetzen kannst. Bis dahin hilft es dir nicht weiter, wenn du=
jeden
Vorschlag einfach nur abschlägst, den man dir gibt. Ein LVM auf einem Unix
Betriebssystem könnte dir durchaus weiterhelfen.


Bye

--
Andreas 'ads' Scherbaum
Deutsche PostgreSQL Usergroup: http://www.pgug.de
DPWN: http://ads.wars-nicht.de/blog/categories/18-PWN

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq