Re: SQL-Statements protokollieren ?

Tach zusammen,

ich moechte zwecks Fehlersuche gerne mitprotokollieren, was eine
'fremde' Applikation auf meiner Datenbank veranstaltet - die bekommt
naemlich bei ihren Queries immer nur leere Ergebnismengen zurueck und
ich weiss nicht einmal, ob die Queries 'anstaendig' formuliert sind.
Taugt einer der verfuegbaren Debug-Modi auf dem Server dazu, mir die
SQL-Statements der Client-Applikation in einer Datei mitzuschreiben ?

Dank fuer jeden 'sachdienlichen' ;-) Hinweis,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

am 22.02.2006, um 9:07:22 +0000 mailte Martin Spott folgendes:
> Tach zusammen,
>
> ich moechte zwecks Fehlersuche gerne mitprotokollieren, was eine
> 'fremde' Applikation auf meiner Datenbank veranstaltet - die bekommt
> naemlich bei ihren Queries immer nur leere Ergebnismengen zurueck und
> ich weiss nicht einmal, ob die Queries 'anstaendig' formuliert sind.
> Taugt einer der verfuegbaren Debug-Modi auf dem Server dazu, mir die
> SQL-Statements der Client-Applikation in einer Datei mitzuschreiben ?

Ja, seit 8.x werden sogar bei prepared statements die aktuellen
Variablen geloggt.

Schaue Dir dazu die Variable:

log_statement = none

an, statt 'none' kannst Du 'all' nehmen.
Was auch 'geil' ist:

log_min_duration_statement = 100

Das loggt alle SQL's, die länger als 100 ms brauchen.

Es reicht, dem Server nach Änderungen zu sagen, daß er das neu einlesen
muß, Server-Restart ist nicht nötig. Die postgresql.conf ist, zumindest
hier unter Debian, im übrigen sehr gut dokumentiert.

Andreas, der hier eine ORA 8 hat, die all solche schönen Dinge nicht
hat...
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47215, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=== Schollglas Unternehmensgruppe ===

> Schaue Dir dazu die Variable:
>
> log_statement = none
>
> an, statt 'none' kannst Du 'all' nehmen.
> Was auch 'geil' ist:
>
> log_min_duration_statement = 100

das klappt bei mir irgendwie ned (8.1.3). der logt immer alle queries. so
kann ich den wert zb. auf 10000 setzen und erhalte im log dennoch queries,
die <50ms ausführzeiten haben... ja, server reload ist gemacht.

- thomas

am 22.02.2006, um 12:21:05 +0100 mailte me(at)alternize(dot)com folgendes:
Hast Du auch einen Namen? ;-)

> >Schaue Dir dazu die Variable:
> >log_statement = none
> >an, statt 'none' kannst Du 'all' nehmen.
> >Was auch 'geil' ist:
> >log_min_duration_statement = 100
>
> das klappt bei mir irgendwie ned (8.1.3). der logt immer alle queries. so
> kann ich den wert zb. auf 10000 setzen und erhalte im log dennoch queries,
> die <50ms ausführzeiten haben... ja, server reload ist gemacht.

Ähm, wenn Du 'log_statement = all' nimmst, dann tut er dies auch.
Ich habe hier:

log_statement = none
log_min_duration_statement = 100

und sehe dann auch nur:

einspender scholl [local] 2006-02-22 12:05:16 CET INSERT LOG: duration: 104.312 ms statement: insert into ...

Andreas
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47215, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=== Schollglas Unternehmensgruppe ===

"A. Kretschmer" wrote:
> am 22.02.2006, um 9:07:22 +0000 mailte Martin Spott folgendes:

>> ich moechte zwecks Fehlersuche gerne mitprotokollieren, was eine
>> 'fremde' Applikation auf meiner Datenbank veranstaltet - die bekommt
>> naemlich bei ihren Queries immer nur leere Ergebnismengen zurueck und
>> ich weiss nicht einmal, ob die Queries 'anstaendig' formuliert sind.
>> Taugt einer der verfuegbaren Debug-Modi auf dem Server dazu, mir die
>> SQL-Statements der Client-Applikation in einer Datei mitzuschreiben ?

> Ja, seit 8.x werden sogar bei prepared statements die aktuellen
> Variablen geloggt.
>
> Schaue Dir dazu die Variable:
>
> log_statement = none
>
> an, [...]

Ah, wunderbar, die Bedeutung hinter diesem Parameter war mir nicht
klar. Dankeschoen.

> Es reicht, dem Server nach Änderungen zu sagen, daß er das neu einlesen
> muß, Server-Restart ist nicht nötig. Die postgresql.conf ist, zumindest
> hier unter Debian, im übrigen sehr gut dokumentiert.

Das mit dem anHUPen kenn' ich. Was die Kommentare in der
'postgresql.conf' angeht, so kenne ich nur die Variante, die als
Default installiert wird, wenn man den Server aus den Sossen baut. Da
steht einiges drinne, aber ausgerechnet das "log_statement" ist nicht
weiter kommentiert.

> Andreas, der hier eine ORA 8 hat, die all solche schönen Dinge nicht
> hat...

Stell' ein PostgreSQL daneben. Ich mach' sowas gerade fuer einen Kunden
im Dunstkreis von Statistiken und Abrechnungsgedoens von
Krankenhaeusern. Weil sich irgendjemand waehrend einer quasi
politischen Diskussion genoetigt fuehlte, sich demonstrativ aus dem
Fenster zu lehnen, muss jetzt fuer einige tausend Euro ein Oracle
beschafft werden. Das laeuft auf derselben Hardware wie das PostgreSQL,
wird auch mit denselben Daten gefuettern - aber die eigentliche Arbeit
geschieht mit dem PostgreSQL :-)
Wenn das Projekt mal die Pilotphase ueberwunden hat, werde ich
sicherlich auch berichten koennen, ob es interessante Aspekte zum
Laufzeitverhalten der beiden Datenbanken gibt ....

Tschuess,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

am 22.02.2006, um 14:39:41 +0000 mailte Martin Spott folgendes:
> Ah, wunderbar, die Bedeutung hinter diesem Parameter war mir nicht
> klar. Dankeschoen.

http://www.powerpostgresql.com/Downloads/annotated_conf_80.html

> > Andreas, der hier eine ORA 8 hat, die all solche schönen Dinge nicht
> > hat...
>
> Stell' ein PostgreSQL daneben. Ich mach' sowas gerade fuer einen Kunden
> im Dunstkreis von Statistiken und Abrechnungsgedoens von

mache ich gerne ;-)

> Wenn das Projekt mal die Pilotphase ueberwunden hat, werde ich
> sicherlich auch berichten koennen, ob es interessante Aspekte zum
> Laufzeitverhalten der beiden Datenbanken gibt ....

Jo, mach das mal...

Andreas
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47215, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=== Schollglas Unternehmensgruppe ===

"A. Kretschmer" wrote:

> Schaue Dir dazu die Variable:
>
> log_statement = none

Funktioniert wunderbar - jetzt hab' ich zumindest schwarz auf weiss,
dass die Datenbank _wirklich_ nichts zurueckliefert .... :-/

Tschuess,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

* Martin Spott:

> Wenn das Projekt mal die Pilotphase ueberwunden hat, werde ich
> sicherlich auch berichten koennen, ob es interessante Aspekte zum
> Laufzeitverhalten der beiden Datenbanken gibt ....

Wirf aber vor einen Blick in die Verträge mit Oracle.