Don.Zwiebel Geschrieben 7. Juni 2004 Teilen Geschrieben 7. Juni 2004 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Goos Geschrieben 7. Juni 2004 Teilen Geschrieben 7. Juni 2004 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*) Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
NoOneKnows Geschrieben 7. Juni 2004 Teilen Geschrieben 7. Juni 2004 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. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Don.Zwiebel Geschrieben 7. Juni 2004 Autor Teilen Geschrieben 7. Juni 2004 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. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Goos Geschrieben 7. Juni 2004 Teilen Geschrieben 7. Juni 2004 Ah, danke. Jetzt kann ichs mir in etwa vorstellen. Goos Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Don.Zwiebel Geschrieben 7. Juni 2004 Autor Teilen Geschrieben 7. Juni 2004 Das Problem dabei ist, dass der Trigger auf etwa 8.000 Zeichen gekürzt wird (von den 73.000) Nur warum ? :confused: :confused: :confused: Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
mme Geschrieben 7. Juni 2004 Teilen Geschrieben 7. Juni 2004 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
mme Geschrieben 7. Juni 2004 Teilen Geschrieben 7. Juni 2004 Hast du mal versucht das ganze ohne ODBC abzusetzten? Also direkt unter SQLPLus o.ä.? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Goos Geschrieben 7. Juni 2004 Teilen Geschrieben 7. Juni 2004 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Don.Zwiebel Geschrieben 7. Juni 2004 Autor Teilen Geschrieben 7. Juni 2004 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 ? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
mme Geschrieben 7. Juni 2004 Teilen Geschrieben 7. Juni 2004 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... Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Don.Zwiebel Geschrieben 8. Juni 2004 Autor Teilen Geschrieben 8. Juni 2004 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. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
mme Geschrieben 8. Juni 2004 Teilen Geschrieben 8. Juni 2004 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??? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Don.Zwiebel Geschrieben 9. Juni 2004 Autor Teilen Geschrieben 9. Juni 2004 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 ? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
mme Geschrieben 9. Juni 2004 Teilen Geschrieben 9. Juni 2004 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 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.