Oracle: Wie man die Zeitstempel der letzten Aktualisierung (einer Tabelle) in einem schema?

Es ist eine Oracle-Datenbank-schema (sehr klein, in der Daten, aber immer noch etwa 10-15 Tische). Es enthält eine Art von Konfiguration (routing-Tabellen).

Gibt es eine Anwendung, die Umfrage dieses schema von Zeit zu Zeit. Benachrichtigungen sind nicht zu verwenden.

Wenn keine Daten in das schema aktualisiert wurden, sollte die Anwendung verwenden, dessen aktuelle version im Speicher.

Wenn jeder Tisch hatte ein update, sollte die Anwendung neu laden alle Tabellen in den Arbeitsspeicher.

Was wäre der effektivste Weg, um zu überprüfen das ganze schema-update für die seit einem bestimmten Schlüssel Punkt (Zeit-oder Transaktions-id)?

Bin ich mir vorgestellt Oracle hält eine Transaktions-id pro schema. Dann sollte es eine Möglichkeit zum Abfragen eine solche ID und halten Sie Sie vergleichen mit bei der nächsten Umfrage.

Ich gefunden habe, diese Frage, wo so eine pseudo-Spalte auf eine Zeile der Ebene:

Wie finden Sie heraus, wenn eine Oracle-Tabelle aktualisiert wurde das Letzte mal

Ich würde denken, dass etwas ähnliches vorhanden ist, auf ein schema-Ebene.

Kann jemand bitte zeigen Sie mich in die richtige Richtung?

  • Sprechen Sie über änderungen am schema selbst (DDL) oder die Aktualisierung der Daten in den Tabellen?
  • Änderungen an den Daten, sorry für die nicht klar ist.
InformationsquelleAutor Vladimir Dyuzhev | 2011-07-21
  1. 12

    ich bin mir nicht bewusst, der eine solche Funktionalität in Oracle. Siehe unten.

    Die beste Lösung, die ich mit oben kommen kann ist, erstellen Sie einen trigger auf jede Ihrer Tabellen, die updates einer Zeile der Tabelle oder Kontext mit dem aktuellen Datum/Zeit. Ein solcher Trigger könnte der Tisch-Ebene (im Gegensatz zu row-level), damit Sie nicht so viel Aufwand wie die meisten löst.

    Übrigens, Oracle kann nicht halten Sie eine Transaktions-ID pro schema, wie eine Transaktion beeinträchtigen könnten mehrere schemas. Es wäre möglich, V$ views zu verfolgen, eine Transaktion zurück, um die Objekte, die es berührt, aber es würde nicht einfach sein, und es würde fast sicher durchführen ärmer als die trigger-Schema.

    Es stellt sich heraus, wenn Sie haben, 10g, können Sie mit Oracle-flashback-Funktionalität, um diese Informationen zu erhalten. Allerdings müssten Sie zum aktivieren der flashback (der trägt den zusätzlichen Aufwand der eigenen) und die Abfrage ist lächerlich langsam (vermutlich, weil es nicht wirklich beabsichtigte für diese Verwendung):

    select max(commit_timestamp) 
from FLASHBACK_TRANSACTION_QUERY 
where table_owner = 'YOUR_SCHEMA' 
      and operation in ('INSERT','UPDATE','DELETE','MERGE')

    Um zu vermeiden, sperren von Themen in der "letzten Aktualisierung" - Tisch, würden Sie wahrscheinlich wollen, um dieses update in einer Prozedur, die verwendet einer autonomen Transaktion, wie zum Beispiel:

    create or replace procedure log_last_update as
pragma autonomous_transaction;
begin
   update last_update set update_date = greatest(sysdate,update_date);
   commit;
end log_last_update;

    Dies bewirkt, dass Ihre Anwendung zu serialisieren, die bis zu einem gewissen Grad: jede Anweisung, muss zum aufrufen dieser Prozedur müssen warten, bis die Vorherige beendet ist. Die "Letzte Aktualisierung" Tabelle kann auch aus dem Takt geraten, weil das update auf, es wird bestehen bleiben, auch wenn das update, das aktiviert den trigger ein Rollback ausgeführt wird. Schließlich, wenn Sie haben eine besonders lange Transaktion, die Anwendung abholen könne das neue Datum/Zeit, bevor die Transaktion abgeschlossen ist, Sieg über den Zweck. Je mehr ich darüber nachdenken, desto mehr scheint es wie eine schlechte Idee.

    Bessere Lösung, um diese Probleme zu vermeiden, ist nur eine Zeile einfügen von Triggern. Dies würde nicht die Tabelle sperren, so würde es keine Serialisierung und die Einsätze würden nicht müssen, werden asynchron vorgenommen, so konnte Sie Rollback ausgeführt werden, zusammen mit den eigentlichen Daten (und würden nicht sichtbar sein, um Ihre Anwendung, bis die Daten sichtbar sind). Die Anwendung würde man die max, die sollten sehr schnell sein, wenn die Tabelle indiziert ist (in der Tat, diese Tabelle wäre ein Idealer Kandidat für eine index-organisierte Tabelle). Der einzige Nachteil ist, das Sie wollen, ein job, der periodisch ausgeführt wird, zu reinigen, alte Werte, so dass es nicht zu groß.

    • Gute Ideen. Aber denken Sie daran, wenn Sie mit der Rückblende, müssen Sie Aufmerksamkeit zahlen, um Ihre Aufbewahrungseinstellungen. Selbst dann, änderungen der Daten konnten verloren gehen, wenn der server neu gestartet. Sie verwenden müssen, um so etwas wie Oracle Total Recall wirklich garantieren die Aufnahme aller änderungen.
    • In Bezug trigger: mit parallelen updates, wie kann ich Konflikte vermeiden, wenn die Aktualisierung einer Zeile der Tabelle? Gibt es eine Möglichkeit zu sagen, "das update gilt außerhalb der aktuellen Transaktion"?
    • Vielen Dank für die ausführliche Erklärung, das trigger-Konzept. Die updates in der aktuellen Anwendung nicht oft, und sehr kurz (add route, route löschen), so dass die serialisierte Verhalten ist nicht ein Problem. Out-of-sync ist kein Problem zu: das Schlimmste, was passieren könnte, ist eine extra config neu laden, wenn es passiert nur gelegentlich) auch nicht Schaden. Ich gehe mit der trigger für update-ersten. Danke!!!
    InformationsquelleAutor Allan
  2. 3

    dbms_stats.gather_table_stats könnte auch helfen: http://forums.oracle.com/forums/thread.jspa?threadID=607610

       4. Statistics is considered to be stale, when the change is over 10% of current rows. 
   (As of 11g, this value can be customized per objects. Cool feature)


    .
    . 
    .

exec dbms_stats.gather_table_stats(user, 'T_STAT');

select * from sys.dba_tab_modifications where table_name = 'T_STAT';
No row selected

select stale_stats from sys.dba_tab_statistics where table_name = 'T_STAT';
NO

insert into t_stat select rownum from all_objects where rownum <= 20;

select * from sys.dba_tab_modifications where table_name = 'T_STAT';
No rows selected <-- Oops
select stale_stats from sys.dba_tab_statistics where table_name = 'T_STAT';
NO  <-- Oops

exec dbms_stats.flush_database_monitoring_info;

select * from sys.dba_tab_modifications where table_name = 'T_STAT';
TABLE_OWNER TABLE_NAME  PARTITION_NAME  SUBPARTITION_NAME   INSERTS UPDATES DELETES TIMESTAMP   TRUNCATED   DROP_SEGMENTS
UKJA        T_STAT      20  0   0   2008-01-18 PM 11:30:19  NO  0

select stale_stats from sys.dba_tab_statistics where table_name = 'T_STAT';
YES
    InformationsquelleAutor Tim
Schreibe einen Kommentar