it-swarm-eu.dev

Oracle - Nějaký způsob, jak zobrazit nevázané změny konkrétní tabulky?

V současné době provádím ladění prostřednictvím dávkového procesu, který provádí mnoho příkazů DML, ale neprovádí ihned potvrzení. Bylo by hezké zobrazit "čekající" změny z jiné relace, zatímco transakce není potvrzena. Je to možné?

Příklad:

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

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

...other DML statements....

commit;
24
contactmatt

Existuje několik různých přístupů v závislosti na podrobnostech vašeho dávkového procesu a proč se pokoušíte zobrazit nepotvrzené změny.

1) Oracle Workspace Manager je nástroj, který byl původně navržen tak, aby umožnil lidem vyvíjejícím prostorové aplikace mít ekvivalent extrémně dlouhotrvajících transakcí (tj. Transakcí, které mohou vyžadovat několik dní nebo týdnů, než lidé zjistí, kde spustit potrubí v jedné transakci). Váš dávkový proces by mohl vytvořit nový pracovní prostor (což je logicky jako vytvoření nové transakce), provést jakékoli změny, které by v tomto pracovním prostoru chtěly, a zavázat se, kdykoli bude chtít. V samostatné relaci byste neviděli žádné z potvrzených změn, dokud nevstoupíte do pracovního prostoru dávkového procesu. Po dokončení dávkového procesu by mohl sloučit svůj pracovní prostor zpět do pracovního prostoru, který je ekvivalentem provedení transakce.

2) balíček DBMS_XA lze použít k tomu, abyste umožnili „předat“ transakci z jedné relace do druhé a umožnit jedné relaci připojit se k transakci zahájené jinou relací. Jedná se o docela nejasný balíček, který se má používat, ale byl zde pěkný příklad jeho použití v PL/SQL Challenge (možná budete potřebovat bezplatný účet, abyste k němu měli přístup) nedávno.

3) Pokud se jen pokoušíte vidět stav dávkového procesu a ne vidět skutečná data, může dávkový proces zapisovat informace o protokolování pomocí autonomních transakcí, které byste pak mohli dotazovat z jiné relace. Nebo můžete použít balíček DBMS_APPLICATION_INFO , aby vaše aplikace aktualizovala různé atributy ve V $ SESSION a/nebo V $ SESSION_LONGOPS, abyste mohli sledovat stav zatížení z jiné relace.

18
Justin Cave

pravit: toto bylo napsáno před vyjasněním otázky

Můžete použít flashback dotazy k zobrazení tabulky bez vašich vlastních nespecifikovaných dat.

Zvážit:

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

Abych viděl rozdíl mezi tabulkou s transakcí a tabulkou, jak ji viděli ostatní, mohl bych vydat:

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

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

Co Oracle nemá, je režim čtení, který není doporučen . Jinými slovy nebudete moci v jiné transakci vyhledávat nezveřejněná data.

Existují způsoby, jak získat informace z dlouhodobě probíhající transakce - jedna dosud neuvedená je autonomní transakce (která by měla být používána s opatrností)

Ano - LogMiner to dokáže. Ve skutečnosti, pokud chcete pouze potvrzené transakce, musíte konkrétně filtr výstup! A existuje TABLE_NAME v V$LOGMINER_CONTENTS, tak byste se dívali na jeden stůl.

8
Gaius

Neexistuje žádná přímá metoda; buď budete muset analyzovat protokoly (jak je uvedeno v jiné odpovědi), nebo použít alternativní metody, abyste viděli, co se děje v dlouhodobém procesu.

Osobně doporučuji k aktivaci této funkce použít autonomní transakce - nikoli pro samotnou transakci, ale jako mechanismus protokolování, který vám dá vědět, co se děje. Například byste mohli mít volání PROCEDURE LONG_ACTION PROCEDURE WRITE_LOG_ENTRY (definované jako autonomní transakce), které by zapisovalo VARCHAR2 do jiné tabulky. Autonomní transakce NERUŠUJÍ do vaší aktuální transakce (z LOGICKÉ perspektivy; pozor na možné dopady na výkon), a tak můžete vidět, co se děje prostřednictvím vašich záznamů v protokolu bez ohledu na COMMIT nebo ROLLBACK v aktuální transakci. To znamená, že byste to mohli udělat s jedním masivním příkazem DML; museli byste použít smyčku.

Zvážit:

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;

Vzhledem k výše uvedenému získáte záznam protokolu pro každých 500 zpracovaných řádků bez ohledu na úspěch dlouhé akce. Pokud potřebujete přesný duplikát dat, aby bylo vidět, jak funguje, navrhuji vytvořit duplicitní tabulku a zavolat proceduru, která duplikuje data (procedura je autonomní transakcí). Pak se data po faktu vymknou. (Není třeba duplikovat.)

Dále, pokud je to pro účely ladění, navrhuji odstranit nebo drasticky snížit potřebu takového protokolování, když byly věci testovány. A jako vždy otestujte, otestujte, otestujte na svém vlastním systému a ověřte, jak to bude fungovat. (Viz komentář od Niallu, kde je dobrý příklad toho, jak může protokolování drasticky ovlivnit výkon.)

(Nakonec, protože jsem to zanedbal na to: pozor na autonomní transakce. Porozumějte jim plně před implementací a nepoužívejte je „jen proto, že“. Mohou být použity milionovým způsobem nesprávně (řekněme například, ATTEMPT vyhněte se mutační chybě ve spouštěči), takže je vždy nejlepší najít alternativy, pokud je to možné. Pokud nemůžete, pak pokračujte opatrně. Protokolování během dlouhodobých operací bylo vždy jedním z případů, kdy je to docela bezpečné (ignorování problémy s výkonem), ale nespěchejte, abyste je mohli použít na jiná použití, aniž by znali důsledky.)

5
Kerri Shotts

Není k dispozici v 10g, ale DBMS_XA může umožnit transakci procházet více relacemi. Pomocí této druhé relace lze zjistit, co se při transakci děje

3
Gary

Kromě dalších zde uvedených informací by dalšími způsoby zasílání informací o nesouvisející transakci bylo odeslání e-mailu nebo zápisu do textového souboru.

3
Leigh Riffel