SQL Fehler / Datenbankfehler?

Werbung:

ny_unity

SQL-Guru
Beiträge
168
Hab jetzt noch Kinderdienst, danach schalte ich die Kiste nochmal ein :) habe die Logfiles bekommen und die conf, wenn’s hilft kann ich die dann auch bereitstellen.

Was wichtig wäre zu erwähnen:
In der applikation selbst (unter Windows) bekommen einige User beim Mailimport oder bei Anlage von Kontakten auch diese Fehlermeldung mit der User_Id
1669050695075.png
Also meistens bei Insert-Aktionen.
 

ny_unity

SQL-Guru
Beiträge
168
Jeder (grafische) SQL Client sollte den anzeigen können, ansonsten:

Code:
select prosrc
from pg_proc
where proname = 'dblog_lohnabz_ins';

select prosrc
from pg_proc
where proname = 'dblog_lohnabz_ins';


DECLARE
AktLxBediener varchar(5);
AKTIP varchar(100);
AKT_PROGRAMM varchar(250);
zeitpunkt date;
BEGIN
aktlxbediener = '';
SELECT current_setting('USER_SESSION.User_Id') into AktLxBediener;
SELECT LOCALTIMESTAMP(0), abbrev(inet_client_addr()) || '/' || text(inet_client_port()) into zeitpunkt, AKTIP;
SELECT application_name FROM pg_stat_activity WHERE pid = pg_backend_pid() into AKT_PROGRAMM;
INSERT INTO sys_dblog_inhalte (ID,DBID,TABELLE,FELDNAME,BEDIENER,FIREBIRD_USER,ZEITPUNKT,IPADRESSE,PROGRAMM,
PRIMAERSCHLUESSEL_1, PRIMAERSCHLUESSEL_2, PRIMAERSCHLUESSEL_3, PRIMAERSCHLUESSEL_4,
PRIMAERSCHLUESSEL_5, WERT_NEU,STATUS,QUALIFIZIERT)
VALUES (-1, -1, 'lohnabz', 'abrmonat', aktlxbediener, current_user, zeitpunkt, AKTIP, akt_programm
,NEW.personalnr,NEW.datum,NEW.abzugart,0,0 ,New.abrmonat,2, 0);
INSERT INTO sys_dblog_inhalte (ID,DBID,TABELLE,FELDNAME,BEDIENER,FIREBIRD_USER,ZEITPUNKT,IPADRESSE,PROGRAMM,
PRIMAERSCHLUESSEL_1, PRIMAERSCHLUESSEL_2, PRIMAERSCHLUESSEL_3, PRIMAERSCHLUESSEL_4,
PRIMAERSCHLUESSEL_5, WERT_NEU,STATUS,QUALIFIZIERT)
VALUES (-1, -1, 'lohnabz', 'abrjahrbis', aktlxbediener, current_user, zeitpunkt, AKTIP, akt_programm
,NEW.personalnr,NEW.datum,NEW.abzugart,0,0 ,New.abrjahrbis,2, 0);
INSERT INTO sys_dblog_inhalte (ID,DBID,TABELLE,FELDNAME,BEDIENER,FIREBIRD_USER,ZEITPUNKT,IPADRESSE,PROGRAMM,
PRIMAERSCHLUESSEL_1, PRIMAERSCHLUESSEL_2, PRIMAERSCHLUESSEL_3, PRIMAERSCHLUESSEL_4,
PRIMAERSCHLUESSEL_5, WERT_NEU,STATUS,QUALIFIZIERT)
VALUES (-1, -1, 'lohnabz', 'abzugart', aktlxbediener, current_user, zeitpunkt, AKTIP, akt_programm
,NEW.personalnr,NEW.datum,NEW.abzugart,0,0 ,New.abzugart,2, 0);
INSERT INTO sys_dblog_inhalte (ID,DBID,TABELLE,FELDNAME,BEDIENER,FIREBIRD_USER,ZEITPUNKT,IPADRESSE,PROGRAMM,
PRIMAERSCHLUESSEL_1, PRIMAERSCHLUESSEL_2, PRIMAERSCHLUESSEL_3, PRIMAERSCHLUESSEL_4,
PRIMAERSCHLUESSEL_5, WERT_NEU,STATUS,QUALIFIZIERT)
VALUES (-1, -1, 'lohnabz', 'betrag', aktlxbediener, current_user, zeitpunkt, AKTIP, akt_programm
,NEW.personalnr,NEW.datum,NEW.abzugart,0,0 ,New.betrag,2, 0);
INSERT INTO sys_dblog_inhalte (ID,DBID,TABELLE,FELDNAME,BEDIENER,FIREBIRD_USER,ZEITPUNKT,IPADRESSE,PROGRAMM,
PRIMAERSCHLUESSEL_1, PRIMAERSCHLUESSEL_2, PRIMAERSCHLUESSEL_3, PRIMAERSCHLUESSEL_4,
PRIMAERSCHLUESSEL_5, WERT_NEU,STATUS,QUALIFIZIERT)
VALUES (-1, -1, 'lohnabz', 'abrjahr', aktlxbediener, current_user, zeitpunkt, AKTIP, akt_programm
,NEW.personalnr,NEW.datum,NEW.abzugart,0,0 ,New.abrjahr,2, 0);
INSERT INTO sys_dblog_inhalte (ID,DBID,TABELLE,FELDNAME,BEDIENER,FIREBIRD_USER,ZEITPUNKT,IPADRESSE,PROGRAMM,
PRIMAERSCHLUESSEL_1, PRIMAERSCHLUESSEL_2, PRIMAERSCHLUESSEL_3, PRIMAERSCHLUESSEL_4,
PRIMAERSCHLUESSEL_5, WERT_NEU,STATUS,QUALIFIZIERT)
VALUES (-1, -1, 'lohnabz', 'datum', aktlxbediener, current_user, zeitpunkt, AKTIP, akt_programm
,NEW.personalnr,NEW.datum,NEW.abzugart,0,0 ,New.datum,2, 0);
INSERT INTO sys_dblog_inhalte (ID,DBID,TABELLE,FELDNAME,BEDIENER,FIREBIRD_USER,ZEITPUNKT,IPADRESSE,PROGRAMM,
PRIMAERSCHLUESSEL_1, PRIMAERSCHLUESSEL_2, PRIMAERSCHLUESSEL_3, PRIMAERSCHLUESSEL_4,
PRIMAERSCHLUESSEL_5, WERT_NEU,STATUS,QUALIFIZIERT)
VALUES (-1, -1, 'lohnabz', 'zaehler', aktlxbediener, current_user, zeitpunkt, AKTIP, akt_programm
,NEW.personalnr,NEW.datum,NEW.abzugart,0,0 ,New.zaehler,2, 0);
INSERT INTO sys_dblog_inhalte (ID,DBID,TABELLE,FELDNAME,BEDIENER,FIREBIRD_USER,ZEITPUNKT,IPADRESSE,PROGRAMM,
PRIMAERSCHLUESSEL_1, PRIMAERSCHLUESSEL_2, PRIMAERSCHLUESSEL_3, PRIMAERSCHLUESSEL_4,
PRIMAERSCHLUESSEL_5, WERT_NEU,STATUS,QUALIFIZIERT)
VALUES (-1, -1, 'lohnabz', 'abrmonatbis', aktlxbediener, current_user, zeitpunkt, AKTIP, akt_programm
,NEW.personalnr,NEW.datum,NEW.abzugart,0,0 ,New.abrmonatbis,2, 0);
INSERT INTO sys_dblog_inhalte (ID,DBID,TABELLE,FELDNAME,BEDIENER,FIREBIRD_USER,ZEITPUNKT,IPADRESSE,PROGRAMM,
PRIMAERSCHLUESSEL_1, PRIMAERSCHLUESSEL_2, PRIMAERSCHLUESSEL_3, PRIMAERSCHLUESSEL_4,
PRIMAERSCHLUESSEL_5, WERT_NEU,STATUS,QUALIFIZIERT)
VALUES (-1, -1, 'lohnabz', 'personalnr', aktlxbediener, current_user, zeitpunkt, AKTIP, akt_programm
,NEW.personalnr,NEW.datum,NEW.abzugart,0,0 ,New.personalnr,2, 0);
RETURN NEW;
END
 

dabadepdu

Datenbank-Guru
Beiträge
1.123
DECLARE
AktLxBediener varchar(5);
AKTIP varchar(100);
AKT_PROGRAMM varchar(250);
zeitpunkt date;
BEGIN

Recht großzügiges Logging für ein Insert. Dazu kommen noch die Logs für Updates und am Ende interessiert es niemand ... (Wie sonst würde ein System derart eingerichtet und in Betrieb sein?)

Ist natürlich nur geraten anhand eines Codeschnipsels. Aber ich würde den Support nicht nur nach der Behebung des Fehlers fragen, sondern was diese Art Logging soll. Immerhin würde sich hier die gespeicherte Datenmenge (Anzahl records) mit Fehlerbehebung um ca Faktor 10 erhöhen. (Vielleicht lässt sich ja wenigstens nachvollziehen, dass es nicht auch noch als Teil der produktiven Daten gesichert wird oder nach angemessener Zeit wieder gelöscht wird)
 

dabadepdu

Datenbank-Guru
Beiträge
1.123
Das ist eine unbefriedigende Antwort vom Support. Selbst wir hier wissen durch Deine Angaben:

- Fehler in PL/pgSQL-Funktion dblog_lohnabz_ins() Zeile 9

- Auslöser ist ein Insert in Table "public".lohnabz

Das wissen wir.

Nur mal ganz irre spekuliert:

Könnte es sich um den Insert Trigger von Tabelle LOHNABZ handeln?


Insgesamt ergibt sich folgendes Bild:

Vielleicht ein System, das ursprünglich auf Firebird DB entwickelt wurde. Bei der Portierung hat es wohl Lücken gegeben. Eine Lücke sorgt für einen Fehler in einem Insert Trigger. Der Fehler ist harmlos, weil der Insert Trigger offenbar ausschließlich zum (excessiven) Loggen genutzt wird. Man könnte damit fast schon den Support Case schließen ;)

Man könnte dem Support, der offenbar nicht so viel Erfahrung mit Postgres hat, auch helfen und die eigenen Erkenntnisse weitergeben.

Wenn es nicht ganz so spekulativ sein soll wie hier versuch mal folgendes Statement.

allgemein (alle Trigger / Stichprobe):

Code:
select event_object_schema as table_schema,
       event_object_table as table_name,
       trigger_schema,
       trigger_name,
       string_agg(event_manipulation, ',') as event,
       action_timing as activation,
       action_condition as condition,
       action_statement as definition
  from information_schema.triggers
 group by 1,2,3,4,6,7,8
 order by table_schema, table_name;

Einschränkung auf Problemfall:
Code:
select event_object_schema as table_schema,
       event_object_table as table_name,
       trigger_schema,
       trigger_name,
       string_agg(event_manipulation, ',') as event,
       action_timing as activation,
       action_condition as condition,
       action_statement as definition
  from information_schema.triggers
 where action_statement ilike '%dblog_lohnabz_ins%'
 group by 1,2,3,4,6,7,8;


Wenn hier nichts rauskommt, was interessant wäre, dann den like parameter kürzen z.B. auf %lohnabz%.
Ebenso sollte zum Erfolg führen, mit einem grafischen DB Tool die Tabelle LOHNABZ aufzusuchen und dort auf Trigger klicken usw.

Dabei würde wiederum rauskommen, dass die bereits bekannte Funktion dblog_lohnabz_ins() den Fehler produziert. Wie der oder die Trigger dazu lauten, wäre m.E. mehr oder weniger egal. Postgres erlaubt es, Trigger unabhängig von der auszuführenden Funktion zu definieren, das ermöglicht N Trigger mit gleicher Funktion. Funktion ist hier letztlich wörtlich zu nehmen, also eine Stored Function "CREATE OR REPLACE FUNCTION ..", hier dblog_lohnabz_ins().

Eine "Reparatur" wäre, diese Funktion zu leeren (nicht löschen) oder statt der dynamischen Definition des user Wertes eine Konstante einzusetzen, z.B. "Zoro was here" oder so.

Ab diesem Zeitpunkt wird dann
- dieser Fehler nicht mehr auftreten.
- Es wird massiv geloggt bei einem Insert
- Es fehlt lediglich der User Wert im Logging.

Der negative Impact dieser Maßnahme dürfte m.E. nahe bei Null sein. Mglw. bietet das System Auswertungen über die Logdaten oder setzt die Logdaten für irgendwelche Zwecke fachlich ein. Das wäre dann sowieso kritisch und würde unvollständige Daten liefern. Was es mit dem vorliegenden Fehler ebenfalls täte.

Im Prinzip könntest Du das selbst durchführen. Das ist allerdings KEINE Empfehlung meinerseits, sondern soll lediglich die mangelnde Dramatik des Falls verdeutlichen. Alles was ich hier geschrieben habe, sind nur Ideen.

Interessant noch: Ist das ein Websystem oder ein Fatclient (Client / Server) System? Im ersten Fall würde die dynamische Auswertung des User-Parameters sowieso eine Konstante ergeben. Der Informationsgehalt läge bei Null, auch wenn es in jedem Datensatz wiederholt wird.
 
Werbung:

ny_unity

SQL-Guru
Beiträge
168
@dabadepdu danke für deine ausführliche Antwort. Tatsächlich betrifft es mehrere Trigger, bzw. mehrere Tabellen, selbst beim Erstellen von Kontakten etc., aber eins nach dem anderen:

Code:
select event_object_schema as table_schema,
       event_object_table as table_name,
       trigger_schema,
       trigger_name,
       string_agg(event_manipulation, ',') as event,
       action_timing as activation,
       action_condition as condition,
       action_statement as definition
  from information_schema.triggers
 where action_statement ilike '%dblog_lohnabz_ins%'
 group by 1,2,3,4,6,7,8;

ergibt folgendes:
1669378300587.png

Richtig ist, dass das System ursprünglich auf Firebird lief. Am 16.11. haben wir bzw. der Hersteller uns auf PG migriert.

Und, es handelt sich um ein Client-Server-System.
 
Oben