Oracle 10G: ordnungsgemäß mit ORA_ROWSCN, um Änderungen der Tabelle Zeile zu erkennen (dh einfügt, Updates, Löschungen)

Question

Einige Nachforschungen über die Überprüfung, wann die Datensätze einer Tabelle zuletzt aktualisiert, geändert oder gelöscht wurden, hat mich zur Pseudo -Spalte geführt, die als ora_rowscn bekannt ist.

Erstens mache ich das:

select max(ora_rowscn) from tablename;

Ich nehme die Nummer zur Kenntnis. Dann mache ich ein Einfügen, aktualisiert und lösche diesen maximalen Wert vor und nach jedem. Es scheint für jede Art von Änderung zu inkrementieren.

Wenn Sie sich fragen, warum ich das mache, werden wir eine Liste von Entitäten in unserem C# Windows -Dienst zwischenspeichern. Dieser Dienst läuft auf zwei Ladebalanced Servern, sodass eine separate Instanz jedes Laufens vorliegt. Wenn ein Update auf dem Server A erfolgt, muss Server B davon wissen. Was ich tun möchte, ist, max (ora_rowscn) in eine Variable. Jedes Mal, wenn unsere Anwendung einen Datensatz einfügt, aktualisiert oder löschen kann, wird aus der Datenbank ein neues Maximum eingerichtet. Wenn der Wert anders ist, weiß er offensichtlich, dass er eine neue Liste aus der Datenbank erhalten muss.

Meine tatsächliche Frage lautet also: Gibt es andere Haken, die mir bewusst sein sollten, dass dies zu einem Einfügen, Aktualisieren oder Löschen eines Datensatzes führen kann, der diesen Wert nicht erhöht?

Bearbeiten: Kann jemand hinzufügen ora_rowscn als Tag?

Answer 1

Gibt es andere Haken, die mir bewusst sein sollten, dass dies zu einem Einfügen, Aktualisieren oder Löschen eines Datensatzes führen kann, der diesen Wert nicht erhöht?

ora_rowscn ist stets Inkrementiert, wenn sich eine Zeile ändert - aber in einer Standardkonfiguration kann sie auch inkrementiert werden Wenn sich eine Zeile nicht ändert

Wenn Sie die gesamte Tabelle auf Udates überprüfen müssen, ist eine Methode zu Verwenden Sie die Prüfung. Andererseits, wenn Sie nur die Zeile überprüfen müssen, die Sie für Konflikte aktualisieren möchten, ora_rowscn mit rowdependencies ist ideal.

Answer 2

Das Erhalten des max (ora_rowscn) erfordert jedes Mal, wenn Sie es tun, einen vollständigen Tabellenscan. Es kann schneller sein, den gesamten Cache jedes Mal zu aktualisieren.

Es hört sich so an, als ob Sie einen Weg brauchen, um den anderen Service zu informieren, dass eine Änderung stattgefunden hat und wie die Änderung war. Sie können eine Protokollentabelle mit einer Spalte verwalten, die angibt, welches System die Änderung konsumieren muss. Die Spalte könnte zwei funktionsbasierte Indizes für jeden Dienst haben, so dass jeder Index nur die Einträge enthält, die verbraucht werden müssen. Wenn sie dann konsumiert werden, können sie den Wert null machen, um ihn aus dem Index zu entfernen.

Oder Sie können einfach Oracle verwenden Erweiterte Warteschlange.

Answer 3

Wie @leigh Riffel feststellte, führt ein ausgewählter Max (ORA_ROWSCN) zu einem vollständigen Tabellenscan. Eine Alternative besteht darin, eine Zeitstempelspalte zu haben (wir werden für dieses Beispiel Sys_ts aufrufen), das bis zur Ausführung von Anweisungen ausgelöst wird (was nicht mit der Aussage -Verpflichtung übereinstimmt, wenn der SCN generiert/besiedelt wird). Mit einem Index in der Spalte SYS_TS können Sie sich die neuesten X -Zeilen (z. B. 25) ansehen, um den max ora_rowscn nur aus diesen Zeilen zu finden.

Der unkomplizierte Weg, dies zu tun, wäre die Verwendung des Rownums, um die Ergebnisse zu begrenzen, wie in diesem [1] Ask TOM -Artikel beschrieben:

select *
from (select sys_ts, ora_rowscn
from table order by SYS_TS desc) where rownum < 25;

Leider führt dies auch zu einem vollständigen Tabellen -Scan (zumindest in Oracle 11.2.0.3). Dies wurde Oracle gemeldet, aber entschlossen, kein Defekt zu sein (Fehler 17347125).

Dies erfordert ein bisschen mehr Arbeit, um das gleiche Ergebnis effektiv zu erzielen:

select b.sys_ts,b.ora_rowscn from
    (select rid from 
        (select rowid as rid from table order by sys_ts desc) 
    where rownum <= 25) a, table b
where a.rid = b.rowid;

[1] - http://www.oracle.com/technetwork/issue-archive/2006/06-sep/o56asktom-086197.html