it-swarm-eu.dev

Oracle - Gibt es eine Möglichkeit, nicht festgeschriebene Änderungen an einer bestimmten Tabelle anzuzeigen?

Ich debugge derzeit durch einen Batch-Prozess, der viele DML-Anweisungen ausführt, aber nicht sofort ein Commit ausführt. Es wäre schön, die "ausstehenden" Änderungen einer anderen Sitzung anzeigen zu können, während die Transaktion nicht festgeschrieben ist. Ist das möglich?

Beispiel:

Insert into table myTable (col1, col2) values ("col1", "col2");

--Somehow view the pending transaction maybe by system view?....

...other DML statements....

commit;
24
contactmatt

Abhängig von den Details Ihres Batch-Prozesses und dem Grund, warum Sie versuchen, die nicht festgeschriebenen Änderungen anzuzeigen, gibt es verschiedene Ansätze.

1) Oracle Workspace Manager ist ein Tool, das ursprünglich entwickelt wurde, um Personen, die Spatial-Anwendungen entwickeln, die Möglichkeit zu geben, Transaktionen mit extrem langer Laufzeit auszuführen (dh Transaktionen, bei denen mehrere Tage oder Wochen erforderlich sind, um herauszufinden, wo sich Menschen befinden eine Pipeline in einer Transaktion ausführen). Ihr Stapelverarbeitungsprozess kann einen neuen Arbeitsbereich erstellen (was logischerweise dem Erstellen einer neuen Transaktion ähnelt) und alle gewünschten Änderungen in diesem Arbeitsbereich vornehmen, während Sie festlegen, wann immer dies gewünscht wird. In einer separaten Sitzung würden Sie keine der festgeschriebenen Änderungen sehen, bis Sie den Arbeitsbereich des Stapelverarbeitungsprozesses betreten haben. Wenn der Stapelprozess abgeschlossen ist, kann der Arbeitsbereich wieder mit dem Live-Arbeitsbereich zusammengeführt werden, was dem Festschreiben einer Transaktion entspricht.

2) Mit dem DBMS_XA-Paket können Sie eine Transaktion von einer Sitzung an eine andere "übergeben" und einer Sitzung die Verbindung zu einer Transaktion ermöglichen, die von einer anderen Sitzung gestartet wurde. Dies ist ein ziemlich obskures Paket, aber es gab kürzlich ein schönes Beispiel für die Verwendung in PL/SQL Challenge (möglicherweise benötigen Sie ein kostenloses Konto, um darauf zuzugreifen).

3) Wenn Sie nur versuchen, den Status des Stapelprozesses anzuzeigen, anstatt die tatsächlichen Daten anzuzeigen, kann der Stapelprozess Protokollinformationen mithilfe autonomer Transaktionen schreiben, die Sie dann aus einer anderen Sitzung abfragen können. Oder Sie können das Paket DBMS_APPLICATION_INFO verwenden, um Ihre Anwendung verschiedene Attribute in V $ SESSION und/oder V $ SESSION_LONGOPS aktualisieren zu lassen, damit Sie den Status des Ladevorgangs aus einer anderen Sitzung überwachen können.

18
Justin Cave

Bearbeiten: Dies wurde geschrieben, bevor die Frage geklärt wurde

Sie können Flashback-Abfragen verwenden, um die Tabelle ohne Ihre eigenen nicht festgeschriebenen Daten anzuzeigen.

Erwägen:

SQL> CREATE TABLE my_table
  2  AS SELECT ROWNUM ID FROM dual CONNECT BY LEVEL <= 5;

Table created

SQL> INSERT INTO my_table VALUES (6);

1 row inserted

Um den Unterschied zwischen der Tabelle mit meiner Transaktion und der Tabelle zu sehen, wie er von anderen gesehen wird, könnte ich Folgendes ausgeben:

SQL> SELECT * FROM my_table
  2  MINUS
  3  SELECT * FROM my_table AS OF TIMESTAMP (systimestamp);

        ID
----------
         6
10
Vincent Malgrat

Was Oracle nicht hat, ist ein nicht festgeschriebener Isolationsmodus zum Lesen . Mit anderen Worten, Sie können nicht festgeschriebene Daten in einer anderen Transaktion nicht abfragen.

Es gibt Möglichkeiten, Informationen aus einer lang laufenden Transaktion herauszuholen - eine bisher nicht erwähnte ist autonome Transaktionen (die mit Vorsicht verwendet werden sollte)

Ja - LogMiner kann dies tun. In der Tat, wenn Sie nur festgeschriebene Transaktionen wollen, müssen Sie speziell Filter die Ausgabe! Und da ist TABLE_NAME im V$LOGMINER_CONTENTS, so würden Sie einen einzelnen Tisch betrachten.

8
Gaius

Es gibt keine direkte Methode; Sie müssen entweder die Protokolle analysieren (wie in einer anderen Antwort erwähnt) oder alternative Methoden verwenden, um zu sehen, was in einem lang laufenden Prozess passiert.

Persönlich schlage ich vor, autonome Transaktionen zu verwenden, um diese Funktion zu aktivieren - nicht für die Transaktion selbst, sondern als Protokollierungsmechanismus, der Sie darüber informiert, was gerade passiert. Beispielsweise könnte PROCEDURE LONG_ACTION PROCEDURE WRITE_LOG_ENTRY (definiert als autonome Transaktion) aufrufen, um ein VARCHAR2 in eine andere Tabelle zu schreiben. Autonome Transaktionen beeinträchtigen Ihre aktuelle Transaktion NICHT (aus logischer Sicht; achten Sie auf mögliche Auswirkungen auf die Leistung), sodass Sie unabhängig von einem COMMIT oder ROLLBACK in Ihrer aktuellen Transaktion sehen können, was in Ihren Protokollierungseinträgen vor sich geht. Das heißt, Sie können das mit einer massiven DML-Anweisung tun; Sie müssten eine Schleife verwenden.

Erwägen:

TABLE LOG_ENTRIES defined as
    activity_date  date,
    log_entry varchar2(2000)

TABLE BIG_JOB (definition doesn't really matter)

PROCEDURE WRITE_LOG_ENTRY
                        ( str VARCHAR2 )
IS
    PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
    INSERT INTO LOG_ENTRIES VALUES ( SYSDATE, str );
    COMMIT;
END;

PROCEDURE LONG_ACTION IS
    c NUMBER;
BEGIN
    FOR r IN ( SELECT * FROM BIG_JOB )
    LOOP
       c := c + 1;
       UPDATE BIG_JOB z
          SET fld = hairy_calculation
        WHERE z.rowid = r.rowid;
       IF MOD(c,500) = 0 THEN
           WRITE_LOG_ENTRY ( c || ' rows processed.' );
       END IF;
    END LOOP;
    COMMIT;
END;

In Anbetracht dessen erhalten Sie einen Protokolleintrag für jeweils 500 verarbeitete Zeilen, unabhängig vom Erfolg der langen Aktion. Wenn Sie ein genaues Duplikat der Daten benötigen, um zu sehen, wie es funktioniert, empfehle ich, eine doppelte Tabelle zu erstellen und eine Prozedur aufzurufen, die die Daten dupliziert (die Prozedur ist eine autonome Transaktion). Dann nuke die Daten nachträglich. (Keine Vervielfältigung erforderlich.)

Wenn dies zu Debugging-Zwecken dient, empfehle ich außerdem, die Notwendigkeit einer solchen Protokollierung zu entfernen oder drastisch zu reduzieren, wenn die Dinge getestet wurden. Und wie immer testen, testen, testen Sie auf Ihrem eigenen System, um zu überprüfen, wie die Dinge funktionieren. (Im Kommentar von Niall finden Sie ein gutes Beispiel dafür, wie sich die Protokollierung drastisch auf die Leistung auswirken kann.)

(Schließlich, weil ich es zuvor versäumt habe, es zu erwähnen: Vorsicht vor autonomen Transaktionen. Verstehen Sie sie vollständig, bevor Sie sie implementieren, und verwenden Sie sie nicht "nur weil". Sie können auf millionenfache Weise falsch verwendet werden (z. B. zu ATTEMPT to Vermeiden Sie einen Mutationsfehler in einem Trigger. Daher ist es immer am besten, nach Möglichkeit nach Alternativen zu suchen. Wenn Sie dies nicht können, gehen Sie vorsichtig vor. Die Protokollierung während lang laufender Operationen war immer ein Fall, in dem sie ziemlich sicher ist (Ignorieren) Leistungsprobleme), aber beeilen Sie sich nicht, es auf andere Zwecke anzuwenden, ohne die Konsequenzen zu kennen.)

5
Kerri Shotts

Nicht verfügbar in 10g, aber DBMS_XA kann es einer Transaktion ermöglichen, mehrere Sitzungen zu überqueren. Auf diese Weise kann die zweite Sitzung sehen, was in der Transaktion geschieht

3
Gary

Zusätzlich zu den anderen Informationen hier können Sie Informationen zu einer nicht festgeschriebenen Transaktion zusätzlich senden, indem Sie eine E-Mail senden oder in eine Textdatei schreiben.

3
Leigh Riffel