Tach zusammen,

mal wieder bitte ich um etwas Verstaendnishilfe fuer den Umgang mit
meiner freundlichen Datenbank. Um der Ursache auf den Grund zu gehen,
warum die DB in der gegebenen Anwendung bisweilen deutlich langsamer
antwortete, als erwartet (das ist nur der Ausloser des Problems und
braucht nicht weiter behandelt zu werden), habe ich mal ein REINDEX der
ganzen Datenbank angeworfen. Die Datenbank heisst 'landcover', ich
lasse also ein:

REINDEX DATABASE landcover;

laufen. Dann sehe ich stundenlang irgendwelche Ausgaben der Art:

NOTICE: table "modis_fire" was reindexed

Alles ganz fein. Und nachdem ich fuer die meisten, aber nicht alle der
Tabellen eine solche Ausgabe gesehen habe, steht da schlussendlich:

ERROR: could not open relation with OID 79045409

Das finde ich natuerlich nicht ganz so fein - ich interpretiere diese
Meldung dahingehend, dass hier irgendwas faul ist .... Also bin ich
hingegangen und habe den Kram einmal zu Fuss gemacht, indem ich fuer
alle Tabellen, die ich auftreiben konnte, ein REINDEX aufgerufen habe.
Das hab' ich natuerlich einmal fuer die Tabellen mit den Nutzdaten
gemacht, also all' diejenigen, die ich mit "\dt" gelistet bekomme aber
auch fuer die Systemtabellen, die nach einem "\dS" angezeigt werden -
bei manchen von diesen habe ich den Datenbankserver dafuer im
Single-User-Mode gestartet.

Das lief alles fehlerfrei durch. Anschliessend habe ich zur Gegenprobe
wieder ein REINDEX auf die komplette Datenbank losgelassen und den
urspruenglichen Fehler bekommen.

Kann mir jemand verraten, was ich hier nicht verstanden habe ? Welche
Stellen kommen denn infrage, die dieses Objekt 79045409 referenzieren
koennten ? Die 'Klassiker', also der Inhalt der Systemtabellen
'pg_class' oder 'pg_index' sind nicht dabei. Wenn ich mir deren Inhalt
anschaue, dann kommt an nicht einer Stelle die besagte, achtstellige
Nummer vor.

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

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

http://archives.postgresql.org

am Wed, dem 30.01.2008, um 9:10:59 +0000 mailte Martin Spott folgendes:
> Tach zusammen,
>
> mal wieder bitte ich um etwas Verstaendnishilfe fuer den Umgang mit
> meiner freundlichen Datenbank. Um der Ursache auf den Grund zu gehen,
> warum die DB in der gegebenen Anwendung bisweilen deutlich langsamer
> antwortete, als erwartet (das ist nur der Ausloser des Problems und
> braucht nicht weiter behandelt zu werden), habe ich mal ein REINDEX der

Wäre doch aber auch nett, das Problem zu lösen, oder?


>
> Kann mir jemand verraten, was ich hier nicht verstanden habe ? Welche
> Stellen kommen denn infrage, die dieses Objekt 79045409 referenzieren
> koennten ? Die 'Klassiker', also der Inhalt der Systemtabellen
> 'pg_class' oder 'pg_index' sind nicht dabei. Wenn ich mir deren Inhalt
> anschaue, dann kommt an nicht einer Stelle die besagte, achtstellige
> Nummer vor.

Sicher?
Ich würde auf pg_index, column indexrelid tippen.


Welche Version ist einklich am Start?



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

Moin Andreas, Dank fuer Deine Antwort.

"A. Kretschmer" wrote:
> am Wed, dem 30.01.2008, um 9:10:59 +0000 mailte Martin Spott folgende=
s:

> > [...] Um der Ursache auf den Grund zu gehen,
> > warum die DB in der gegebenen Anwendung bisweilen deutlich langsamer
> > antwortete, als erwartet (das ist nur der Ausloser des Problems und
> > braucht nicht weiter behandelt zu werden), habe ich mal ein REINDEX d=
er
>
> Wäre doch aber auch nett, das Problem zu lösen, oder?

Sicherlich - allerdings betrachte ich das momentan als zweitrangig,
solange die Datenbank nicht so wirklich konsistent ist.

In vergleichbaren Situationen (Art und Weise, wie die Datenbank be-
respektive umgefuellt wird) hatte ich festgestellt, dass auch ein
"VACUUM FULL" sehr viel bringt. Deshalb gedenke ich, mich noetigenfalls
darauf zu stuerzen, wenn die Indices in Ordnung sind. Vielleicht ist
die Ursache ja auch in dem Moment gegessen, in dem das REINDEX
fehlerfrei durchlaeuft ...
Ich will jedenfalls ungerne zwei Baustellen gleichzeitig beackern, denn
nachher sind dann haeufig die Ursachen und die Symptome nur noch
schwierig auseinander zu sortieren ....

> > Kann mir jemand verraten, was ich hier nicht verstanden habe ? Welche
> > Stellen kommen denn infrage, die dieses Objekt 79045409 referenzieren
> > koennten ? Die 'Klassiker', also der Inhalt der Systemtabellen
> > 'pg_class' oder 'pg_index' sind nicht dabei. Wenn ich mir deren Inhal=
t
> > anschaue, dann kommt an nicht einer Stelle die besagte, achtstellige
> > Nummer vor.
>
> Sicher?

Ja, das ist leider so:

bash-3.00$ tail -1 REINDEX.log
ERROR: could not open relation with OID 79045409
bash-3.00$ psql -d landcover -c "SELECT * FROM pg_index" | grep 79045409
bash-3.00$

Bei 'pg_class' sieht's genau so aus.
Bei dem Apparat handelt es sich um eine Version 8.2.4 (inclusive
PostGIS-1.3.1), die ich mit 'nem GCC als 32-bittiges Binary auf einer
Sun unter Solaris10 gebaut habe.

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

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

Martin Spott wrote:

> bash-3.00$ psql -d landcover -c "SELECT * FROM pg_index" | grep 79045409
> bash-3.00$

Ich hab' das generell mal fuer alle Tabellen exerziert, die ich mit
einem "\dS" gelistet bekommen habe, und die besagte Nummer taucht
nirgendwo auf. Hat jemand noch eine Idee, wie ich dem Fehler auf die
Spur kommen koennte ?

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

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

Am 31.01.2008 um 09:27 schrieb Martin Spott:

> Martin Spott wrote:
>
>> bash-3.00$ psql -d landcover -c "SELECT * FROM pg_index" | grep
>> 79045409
>> bash-3.00$
>
> Ich hab' das generell mal fuer alle Tabellen exerziert, die ich mit
> einem "\dS" gelistet bekommen habe, und die besagte Nummer taucht
> nirgendwo auf. Hat jemand noch eine Idee, wie ich dem Fehler auf die
> Spur kommen koennte ?

Hi,

ich bin ja nun nur Anwender aber für mich liest sich das so, als ob
irgendwann bei Dir mal beim Löschen eines Datensatzes ein Fehler
aufgetreten ist, auf den erst jetzt läufst. Normalerweise prüft die
DB doch vor dem löschen eines Datensatzes, ob es irgendwelche Ab-
hängigkeiten gibt. Nun ist bei Dir ein Datensatz übrig geblieben,
der auf einen anderen verweist, der aber fehlt. Lösung wäre also,
diesen referenzierenden Datensatz zu suchen und ggf. auch zu löschen
oder die Abhängigkeit sonstwie zu entfernen. Wie das gehen kann weiß
ich auch nicht, aber ich denke, Du mußt schon raus finden, wer auf
die OID verweist, bevor Du weiter kommen kannst. Außerdem ist
Andreas Hinweis nicht ohne. Ich mache immer gute Erfahrung damit,
mich bei der Fehlersuche zuerst auf den Fehler zu konzentrieren,
den mir die Maschine als Erstes zurück gibt, weil alle anderen in
der Regel davon abhängen und sich hernach in Luft auflösen. Mag
schon sein, daß Dich die OID mehr beschäftigt, aber Du willst was
von Deiner Maschine und die beschwert sich erst mal über was
Anderes.

Gruß, Christian



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

* Martin Spott <Martin.Spott [at] mgras.net> schrieb:

> Ich hab' das generell mal fuer alle Tabellen exerziert, die ich mit
> einem "\dS" gelistet bekommen habe, und die besagte Nummer taucht
> nirgendwo auf. Hat jemand noch eine Idee, wie ich dem Fehler auf die
> Spur kommen koennte ?

hmm, mach doch mal einen vollen Dump und such dort ...
Ahja, schau doch mal in pg_class.

cu
--
------------------------------------------------------------ ---------
Enrico Weigelt == metux IT service - http://www.metux.de/
------------------------------------------------------------ ---------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
------------------------------------------------------------ ---------

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