Riesiges Sqlfile über psql einlesen

Ihr habt jetzt wochenlang getestet und probiert und an Beispielen herumgearbeitet, oder?

Warum habt ihr nicht gleich jemanden mit den grundlegenden Arbeiten beauftragt?

Wer soll denn “JEMAND” sein?

Offensichtlich jemand der Erfahrung mit PostgreSQL mitbringt.

War ja einfach.

Eine Richtige Diskussion darüber würde zu weit führen in diesem Topic.

Nur kurz (oder doch nicht :P)

Fakt ist das ich gerne an einem Workshop teilgenommen hätte aber man es mir verwehrt hat.

Dafür konnte ich 2 Bücher “durchboxen” und die viele Zeit investieren.

Die Bücher sind ->

PostgreSQL-Administration: Peter Eisentraut, Bernd Helmle: Amazon.de: Bücher

PostgreSQL. Datenbankpraxis für Anwender, Administratoren und Entwickler: Andreas Scherbaum: Amazon.de: Bücher


Eines der beiden wird erst noch erscheinen. Daher vermute ich nicht das Ihr mir darüber schon sagen könnt ob es gut ist oder nicht (und das andere ist gerade erst erschienen)

Aber ich muss sagen das ich mich selten so gerne mit einer Datenbank beschäftigt habe wie heute :slight_smile:

man lernt durch 2-3 Wochen eigenes ausprobieren (und auch scheitern) sicher mehr als in einem workshop von 2-3 tagen (warte bevor du dich auf mich stürzt und lese erst weiter).

Zumindest wenn man konkrete Anwendungsfälle hatte wie ich. Und ich muss sagen dafür das ich mich außer mit sql (auf mysql) nie mit dbs beschäftigt habe (mal n bischen oracle im studium) bin ich schon ein wenig stolz darauf das ich die postgres quasi im alleingang soweit verstanden und anwenden kann das die Performace wie zuvor schon mal kurz erwähnt von ca 10 mins auf 14 secs reduzieren konnte. alles beim selben select statement, den selben Daten etc. nur durch die mem settings customizen. Wenn ich durch nen workshop das gleiche (oder evtl. noch besser ? ) Ergebnis hinbekommen hätte wäre es nicht MEIN Erfolgserlebnis gewesen :slight_smile:

Bsp:
das work_mem quasi pro query allocated wird habe ich dank doku lesen verstanden ABER ich habe genau 4 Benutzer der DB und die 4 schicken seriell queries mit riesigen joins über riesigen datenmengen ab (also unter riesig verstehe ich wenn man 7 tables jeweils zwischen 50Mio - 60 Mio Datensätzen hat und die NATURAL joint und dazu noch UNIONs durchführt mit einem weiteren select mit solchen joins und dann noch distinct und grouped und ordered)

Dann muss das Ergebnis noch weiter nachbearbeitet werden und schwupps kommen arrays mit n tiefen heraus und alle sind glücklich.

Unser heutiges System benötigt dafür eine Stunde.

Wenn ich also daher komme und nach 3 Wochen “spielen” etwas mache das das in 14 secs erledigt bin ich hier schon der Gott und alle liegen mir zu füssen (naja träumen darf an doch noch) .

:slight_smile:

Nichts für ungut aber um zurück zum Thema zu kommen:

Bei einer 1,3 GB großen file.sql kam wieder die gleiche Fehlermeldung.

Ich haben natürlich sofort die chunks kleiner gemacht und mir dabei die file.sql die nicht funktionierte gelöscht (Ich dämelack denn langsam glaube ich das es vielleicht am Inhalt der Zeile liegt statt an der Größe des Logfiles (Also das atomare Statement zu lang ?))

Aber das neue file.sql lasse ich schon generieren und schaue falls er meckert erstmal die Zeile an.

Oh, ich bin mir sehr sicher, daß ads zu dem noch nicht veröffentlichtem Buch was sagen können wird g

Workshop: die gibt es an und ab für lau bei den passenden Events, hab ich selber schon durchgeführt. Okay, in 2 Stunden oder so kann man nicht so dolle viel machen, aber es wäre ein Anfang…

Andreas

Dürfte er, schließlich schreibt er es …
Das ist allerdings auch etwas früh angekündigt.


Workshop: die gibt es an und ab für lau bei den passenden Events, hab ich selber schon durchgeführt. Okay, in 2 Stunden oder so kann man nicht so dolle viel machen, aber es wäre ein Anfang…

Ich werde mal schauen ob wir in Chemnitz einen Workshop halten können. Aber wie du sagst: in 2 Stunden ist da nicht sehr viel unterzubringen.

Dann sag ich es anders.

Du bist befangen und kannst daher nicht sagen ob es gut ist oder nicht :stuck_out_tongue:

So könnte man das auch ausdrücken.

Hab folgende Aussage in einer Präsentation gefunden

How much buffer space ?
● We hope enough not to block
● Average entry size ×
Maximum event burst rate ×
Maximum time waiting for collection
Listeners should not run long running transactions,
although notifiers can

Quelle: http://www.pgcon.org/2008/schedule/attachments/62_notif.pdf

Das könnte glaube ich mein Problem beschreiben

Das bezweifle ich nun sehr stark. Der Vortrag hat überhaupt nichts mit deinem Problem zu tun.

Zu deinen Problemen bei der Konfiguration hatte ich früher schon etwas gesagt - aber hey, ihr habt wochenlang probiert und habt das als beste Lösung ermittelt.

vielleicht sollte man mal in ein Logfile schauen :slight_smile:

TopMemoryContext: 50992 total in 6 blocks; 5704 free (27 chunks); 45288 used
PL/PgSQL function context: 24576 total in 2 blocks; 16544 free (8 chunks); 8032 used
PL/PgSQL function context: 24576 total in 2 blocks; 11520 free (11 chunks); 13056 used
RI compare cache: 8192 total in 1 blocks; 1800 free (0 chunks); 6392 used
RI query cache: 8192 total in 1 blocks; 5968 free (0 chunks); 2224 used
Operator class cache: 8192 total in 1 blocks; 3848 free (0 chunks); 4344 used
Operator lookup cache: 24576 total in 2 blocks; 14072 free (6 chunks); 10504 used
PL/PgSQL function context: 24576 total in 2 blocks; 11520 free (11 chunks); 13056 used
CFuncHash: 8192 total in 1 blocks; 4936 free (0 chunks); 3256 used
Rendezvous variable hash: 8192 total in 1 blocks; 3848 free (0 chunks); 4344 used
PLpgSQL function cache: 24596 total in 2 blocks; 5904 free (0 chunks); 18692 used
Record information cache: 8192 total in 1 blocks; 1800 free (0 chunks); 6392 used
TopTransactionContext: 8192 total in 1 blocks; 7208 free (0 chunks); 984 used
ExecutorState: 57344 total in 3 blocks; 22032 free (3 chunks); 35312 used
MessageContext: 1169536032 total in 51 blocks; 1208 free (1 chunks); 1169534824 used
smgr relation table: 8192 total in 1 blocks; 2808 free (0 chunks); 5384 used
TransactionAbortContext: 32768 total in 1 blocks; 32752 free (0 chunks); 16 used
Portal hash: 8192 total in 1 blocks; 3912 free (0 chunks); 4280 used
PortalMemory: 8192 total in 1 blocks; 8176 free (2 chunks); 16 used
Relcache by OID: 8192 total in 1 blocks; 3376 free (0 chunks); 4816 used
CacheMemoryContext: 667472 total in 20 blocks; 187168 free (1 chunks); 480304 used
CachedPlan: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
CachedPlanSource: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
CachedPlan: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
CachedPlanSource: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
CachedPlan: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
CachedPlanSource: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
pids_pid_key: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
pids_pkey: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
CachedPlan: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
CachedPlanSource: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
CachedPlan: 1024 total in 1 blocks; 312 free (0 chunks); 712 used
CachedPlanSource: 3072 total in 2 blocks; 1896 free (3 chunks); 1176 used
SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
CachedPlan: 1024 total in 1 blocks; 616 free (0 chunks); 408 used
CachedPlanSource: 1024 total in 1 blocks; 304 free (0 chunks); 720 used
SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
CachedPlan: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
CachedPlanSource: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
CachedPlan: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
CachedPlanSource: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
CachedPlan: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
CachedPlanSource: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
uas_ua_key: 1024 total in 1 blocks; 304 free (0 chunks); 720 used
uas_pkey: 1024 total in 1 blocks; 304 free (0 chunks); 720 used
CachedPlan: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
CachedPlanSource: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
CachedPlan: 3072 total in 2 blocks; 1920 free (0 chunks); 1152 used
CachedPlanSource: 3072 total in 2 blocks; 1544 free (0 chunks); 1528 used
SPI Plan: 1024 total in 1 blocks; 904 free (0 chunks); 120 used
CachedPlan: 1024 total in 1 blocks; 496 free (0 chunks); 528 used
CachedPlanSource: 1024 total in 1 blocks; 32 free (0 chunks); 992 used
SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
CachedPlan: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
CachedPlanSource: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
CachedPlan: 3072 total in 2 blocks; 1696 free (0 chunks); 1376 used
CachedPlanSource: 3072 total in 2 blocks; 1168 free (0 chunks); 1904 used
SPI Plan: 1024 total in 1 blocks; 904 free (0 chunks); 120 used
CachedPlan: 1024 total in 1 blocks; 368 free (0 chunks); 656 used
CachedPlanSource: 1024 total in 1 blocks; 72 free (0 chunks); 952 used
SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
CachedPlan: 1024 total in 1 blocks; 504 free (0 chunks); 520 used
CachedPlanSource: 1024 total in 1 blocks; 128 free (0 chunks); 896 used
SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
CachedPlan: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
CachedPlanSource: 1024 total in 1 blocks; 352 free (0 chunks); 672 used
SPI Plan: 1024 total in 1 blocks; 928 free (0 chunks); 96 used
CachedPlan: 1024 total in 1 blocks; 616 free (0 chunks); 408 used
CachedPlanSource: 1024 total in 1 blocks; 312 free (0 chunks); 712 used
SPI Plan: 1024 total in 1 blocks; 928 free (0 chunks); 96 used
CachedPlan: 1024 total in 1 blocks; 616 free (0 chunks); 408 used
CachedPlanSource: 1024 total in 1 blocks; 304 free (0 chunks); 720 used
SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used

LOCALLOCK hash: 8192 total in 1 blocks; 3912 free (0 chunks); 4280 used
Timezones: 48616 total in 2 blocks; 5968 free (0 chunks); 42648 used
ErrorContext: 540696 total in 3 blocks; 16256 free (10 chunks); 524440 used
2008-11-24 11:47:40 CET ERROR: out of memory
2008-11-24 11:47:40 CET DETAIL: Failed on request of size 1048576.

MessageContext: 1169536032 total in 51 blocks; 1208 free (1 chunks); 1169534824 used

Kommt mir doch sehr übel vor. Was ist das ?

Dem würde ich mehr Aufmerksamkeit widmen: der Query (bzw. das, womit sich die DB gerade beschäftigt) ist ca. 1 MB groß und macht Probleme.

akretschmer kann vielleicht die passende Option aus dem Hut zaubern.

OMG

Doch:

MessageContext: 1169536032 total in 51 blocks; 1208 free (1 chunks); 1169534824 used

ist ein guter Indikator …

Das besagt nämlich das der Server über 1GB an output an den client schicken möchte (welcher daran verreckt).

Ich habe das > 2GB file.sql in stücke zerhackt und ausprobiert.

die ganze Zeit vermutete ich das die Filegröße ein Problem darstellt da ja kleinere Dateien funktionieren.

-> Falsch

das ca. 120.000.000 Mio Statement hat mist gebaut und alles was darauf folgte dann auch. in den kleineren dateien habe ich ja nie alle ca. 120 Stück ausprobiert sondern mal die jene oder diese.

das ganze hat dann soviel error msg gebaut das der server das nicht mehr an den client schicken konnte :astonished:

Na da haben wir doch alle was gelernt.

Ist eine Transaction soooo groß das ein Statementfehler irgendwo darin soviel Error erzeugt das er nicht mehr an den Client gesendet werden kann, so gibt es anscheinend den am Anfang beschriebenen Fehler.

Danke euch trotzdem für die Diskussion und Anregungen.


Anschlußfrage ist nun

Kann man das Verhalten beeinflussen ?

Also es würde mir ja reichen wenn der Server beim ersten Statement das nicht klappt die Transaction abbricht und mir den Fehler entgegen wirft. Er muss ja in der Transaktion nicht erst noch die unzähligen folgenden Zeilen durchgehen.

Dokumentation lesen:

stop psql on first error - ads’ corner

Das ist allerdings nicht die offizielle Doku…

Andreas

Nein, aber dort habe ich das auch bloß her :wink:

Wie ich bin suche ich solche guten Infos immer nochmal in der offiziellen Doku (Auch um ein Gefühl für die Doku zu bekommen wo man etwas vermuten könnte)

Falls es also nochmal jemand dort nachlesen möchte sei er auf den folgenden Link verwiesen.

psql


Prima :slight_smile:

Damit kann das Thema geschlossen werden.

Dankeschön euch allen nochmal für die Hilfe.