Hallo Leute,

wie groß ist die maximale Größe, die ein Datenbankstatement mit ODBC haben darf ?

Ich weiß, das es eine Funktion SqlGetInfo gibt, jedoch nicht, wo ich diese finde. Irgendwelche Tipps ?

Wie kann ich die maximale Größe für Statements ändern ?

Das Problem: Erstellung eines Triggers mit 73.000 Zeichen (Oracle)

Danke

Don.Zwiebel

Das Problem: Erstellung eines Triggers mit 73.000 Zeichen (Oracle)

Schulligung, dass ich dir nicht weiterhelfen kann bezueglich Oracle, aber welcher vernuenftige Mensch packt 73.000 Zeilen in EINEN Trigger?

Mich wuerde jetzt doch sehr interessieren, wie es dazu kommen kann.

Goos (*unglaeubig*)

Also soviel kann ich dir auch net dazu sagen. Hab nur gerade mal ein Statement mit knapp 90.000 Zeichen über ODBC auf einer Oracle-DB ausgeführt und das funktionierte. Soweit ich weiß gibt es über ODBC bei Oracle aber Probleme bei sehr langen Zeilen, sprich mehr als 2000 Zeichen. Dann stürzen die ausführenden Anwendung mehr oder weniger heftig ab.

Abstürzen tut die Anwendung nicht.

Der Trigger wird so lang, da er dynamisch angelegt wird und die Tabelle weit über 100 Felder hat und jedes Feld überwacht wird. -> Trigger wächst und wächst.

Ah, danke. Jetzt kann ichs mir in etwa vorstellen.

Goos

Das Problem dabei ist, dass der Trigger auf etwa 8.000 Zeichen gekürzt wird (von den 73.000)

Nur warum ? :confused: :confused: :confused:

Abstürzen tut die Anwendung nicht.

Was ist den dann dein Problem?

Oder stürzt das ding nicht ab, ist aber langsam? Würde mich nicht wundern. Was heißt überhaupt das der Trigger dynamisch geändert wird? Bei jedem INsert ändert sich der Trigger?

Wenn du den Trigger tatsächlich ständig änderst, kann ich dir grundsätzlich nur empfehlen, das ganze in ein Package auszulagern und im Trigger das Package bzw. die Funktion im Package zu rufen. Ist bestimmt auch besser im Bezug auf recompilieren usw....

Interessehalber: Wie hoch ist den dein Oracle-Parameter "open_cursors" ?

Grüße mme

Hast du mal versucht das ganze ohne ODBC abzusetzten?

Also direkt unter SQLPLus o.ä.?

Das Problem dabei ist, dass der Trigger auf etwa 8.000 Zeichen gekürzt wird (von den 73.000)

Nur warum ? :confused: :confused: :confused:

Oha, ich hab zwar keine Ahnung von Oracle (bin MS User), aber das hoert sich schwer nach ner Datentyp Begrezung an.

Es scheint mir so, als wuerdest versuchen den ganzen Trigger dynamisch in einer Variable zusammenzubasteln um ihn dann auszufuehren. So ne Variable vom Typ varchar/char kann aber wahrscheinlich nur 8000 Zeichen aufnehmen. Zumindest ist das beim MS SQL-Server so.

Goos

Also:

Wir haben ein Programm, das die Zugriffe auf die Tabellen überwachen soll.

Da man bei Oracle keinen Trigger, der sich dynamisch (für jede Tabelle geeignet!) die Feldnamen holt und damit die :OLD. und :NEW. Werte holt wird von unserem Tool die Tabellenstruktur ausgelesen und für jede Tabelle ein Trigger von diesem Format generiert:

CREATE OR REPLACE TRIGGER ##TRIGGERNAME##

AFTER ##OPERATIONS## ON ##TABLENAME##

FOR EACH ROW

BEGIN

##FIELDS##

/* Dadurch ist ##FIELDS## für jedes Feld zu ersetzen:

IF (:OLD.##FIELDNAME## IS NOT NULL AND :NEW.##FIELDNAME## IS NOT NULL AND :OLD.##FIELDNAME## <> :NEW.##FIELDNAME##)

OR (:OLD.##FIELDNAME## IS NULL AND :NEW.##FIELDNAME## IS NOT NULL)

OR (:OLD.##FIELDNAME## IS NOT NULL AND :NEW.##FIELDNAME## IS NULL) THEN

INSERT INTO LOGBUCH (TABNAME, OLDVALUE, NEWVALUE, EDITNAME, EDITDATE, BEA_LOGIN, BEA_DATUM, UPDATE_NO)

VALUES ('##TABLENAME##',:OLD.##FIELDNAME##, :NEW.##FIELDNAME##, USER, SYSDATE, 'KOLIBRI', SYSDATE, 1);

END IF;

*/

COMMIT;

END;

Das Problem ist nun, das bei einigen Tabellen mit vielen Columns der Trigger über 73.000 Zeichen lang wird. Der Trigger ändert sich nicht ständig, sondern wird nur einmal angelegt.

Vorschläge ?

Es gibt doch verschiedene Auditing funktionen in Oracle... Ich glaube ich würde sowas damit lösen....

Kannst du den ausschließen was goos sagte (also das die Variable in deinem erstellungprogramm das von der Länge mitmacht) ? Ich glaube nicht umbedingt das das an ODBC liegt...

Also die Variable ist ein LongString (bis 2MB) und passt auch im Debug - Modus.

Über auditing ist es aber so ohne weiteres auch nicht möglich Änderungen an den Tabellen zu überwachen (wer wann welchen alten und neuen Wert geändert hat, usw.)

Jedenfalls bin ich damit nicht weiter gekommen.

Wie es genau mit dem Audit geht weiß ich auch nicht, aber was ich schon benutzt habe ist der logminer. Wenn sich deine DB im archive-modus befindet kannst du jede Änderung jederzeit nachvollziehen. Befindet sie sich nicht im Archive-Modus, kannst du nur die letzten paar minuten nachvollziehen... Aber das ding ist recht umfangreich. Du kannst dir alle Änderungen anschauen die ein DB-User gemacht hat, oder du Filterst nach BS-USer, oder nach der Client-Workstation usw.... Du bekommst sogar scripte erstellt um diese Änderungen rückgängig zu machen... vielleicht würde das ding dir helfen.

Ansonsten kann ich nur meine Fragen von oben wiederhohlen, ob es den Funktioniert, wenn du den Trigger in SQLplus erstellst und nicht über odbc???

Das Problem mit SQLPlus ist nur, dass der Puffer für Statements da noch kleiner ist (2000 Zeichen oder so)!

Wie funktioniert Logminer ? Ist das ein extra Programm ?

Du kannst das ganze Statement doch in ein Textfile legen und dann das textfile in sqlplus mit @c:\...pfad\dateiname.txt aufrufen!?

Der logminer besteht aus ein paar dbms-Packeten. Wenn du den Oracle-Managemt-Server einsetzt ist das ganze recht komfortabel in der gui zu bedienen. Das ist das was ich empfehlen kann.

Wenn man keinen OMS einsetzt kann man den Logminer auch verwenden, ist aber etwas umständlicher... Hier eine Anleitung dazu:

rem vorher die Punkte 1) und 2) ausführen

rem 1) initD60.ora-Parameter setzen:

rem ---------------------------------------------------

rem utl_file_dir=/verzeichnis/unterverzeichnis

rem Achtung: - Hier kann man nicht $HOME verwenden!

rem - Oracle muss Rechte auf das Verzeichnis log besitzen.

rem startup

rem 2) Dictionary-Datei erzeugen

rem ---------------------------------------------------

rem execute sys.DBMS_LOGMNR_D.BUILD('d_logmnr.dict', '/verzeichnis/unterverzeichnis');

rem Achtung: - Als internal bzw. sys arbeiten oder als system mit Aufruf SYS.DBMS_...

rem - Das Verzeichnis in DBMS_LOGMNR_D.BUILD('datei', 'verzeichnis') muss

rem bereits vorhanden und dasselbe sein wie in dem Parameter utl_file_dir.

rem - Auch hier darf nicht $HOME stehen.

rem Aufruf: sqlplus -s internal @logmnr.sql

rem ====================================================

rem ----------------------------------------------------

rem Log-Dateien aufnehmen:

execute sys.DBMS_LOGMNR.ADD_LOGFILE('/verzeichnis/log1a.rdo',DBMS_LOGMNR.NEW);

execute sys.DBMS_LOGMNR.ADD_LOGFILE('/verzeichnis/log2a.rdo',DBMS_LOGMNR.ADDFILE);

rem ----------------------------------------------------

rem LogMiner-Session starten

execute sys.DBMS_LOGMNR.START_LOGMNR(dictfilename=>'/verzeichnis/d_logmnr.dict');

rem ----------------------------------------------------

rem Inhalt selektieren:

SELECT timestamp, username, sql_redo, sql_undo

FROM v$logmnr_contents

WHERE seg_name = 'DEPT';

rem ----------------------------------------------------

rem LogMiner-Session beenden

execute sys.DBMS_LOGMNR.END_LOGMNR;

exit

Schöne Grüße mme