Es gibt ein Oracle-Datenbankschema (sehr klein in Daten, aber immer noch etwa 10-15 Tabellen). Es enthält eine Art Konfiguration (Routing-Tabellen).
Es gibt eine Anwendung, die dieses Schema von Zeit zu Zeit abfragen muss. Benachrichtigungen sind nicht zu verwenden.
Wenn keine Daten im Schema aktualisiert wurden, sollte die Anwendung ihre aktuelle In-Memory-Version verwenden.
Wenn irgendeine Tabelle irgendeine Aktualisierung hatte, sollte die Anwendung alle Tabellen in den Speicher neu laden.
Was wäre der effektivste Weg, um das gesamte Schema für die Aktualisierung seit einem bestimmten Schlüsselpunkt (Zeit oder Transaktions-ID) zu überprüfen?
Ich bin überzeugt, dass Oracle eine Transaktions-ID pro Schema speichert. Dann sollte es möglich sein, eine solche ID abzufragen und mit der nächsten Umfrage zu vergleichen.
Ich habe diese Frage gefunden, wo eine solche Pseudospalte auf Zeilenebene existiert:
So finden Sie wenn eine Oracle-Tabelle das letzte Mal aktualisiert wurde
Ich würde denken, dass etwas Ähnliches auf einer Schemaebene existiert.
Kann mir bitte jemand in die richtige Richtung zeigen?
Mir ist keine solche Funktionalität in Oracle bekannt. Siehe unten.
Die beste Lösung, die ich finden kann, besteht darin, für jede Ihrer Tabellen einen Trigger zu erstellen, der eine einreihige Tabelle aktualisiert, oder Kontext mit dem aktuellen Datum / Uhrzeit. Solche Trigger könnten auf Tabellenebene (im Gegensatz zu Zeilenebene) sein, so dass sie nicht so viel Overhead wie die meisten Trigger enthalten würden.
Übrigens kann Oracle keine Transaktions-ID pro Schema behalten, da eine Transaktion mehrere Schemata betreffen könnte. Es könnte möglich sein, V $ Views zu verwenden, um eine Transaktion zurück zu den betroffenen Objekten zu verfolgen, aber es wäre nicht einfach und es würde fast sicher schlechter ablaufen als das Triggerschema.
Wenn Sie 10g haben, können Sie die Flashback-Funktion von Oracle verwenden, um diese Informationen zu erhalten. Allerdings müssten Sie Flashback aktivieren (was mit einem gewissen Overhead einhergeht) und die Abfrage ist lächerlich langsam (vermutlich, weil sie nicht wirklich für diesen Zweck gedacht ist):
%Vor%Um Sperrprobleme in der "Zuletzt aktualisiert" -Tabelle zu vermeiden, möchten Sie das Update wahrscheinlich in eine Prozedur einfügen, die eine autonome Transaktion verwendet, wie zum Beispiel:
%Vor%Dadurch wird Ihre Anwendung bis zu einem gewissen Grad serialisiert: Jede Anweisung, die diese Prozedur aufrufen muss, muss warten, bis die vorherige beendet ist. Die Tabelle "Letzte Aktualisierung" kann ebenfalls nicht mehr synchron sein, da das Update weiterhin besteht, auch wenn das Update, das den Trigger aktiviert hat, zurückgesetzt wird. Schließlich, wenn Sie eine besonders lange Transaktion haben, könnte die Anwendung das neue Datum / die neue Zeit abholen, bevor die Transaktion abgeschlossen ist, und den Zweck vereiteln. Je mehr ich darüber nachdenke, desto mehr scheint es eine schlechte Idee zu sein.
Die beste Lösung, um diese Probleme zu vermeiden, besteht darin, nur eine Zeile aus den Triggern einzufügen. Dies würde die Tabelle nicht sperren, so dass es keine Serialisierung geben würde und die Einfügungen nicht asynchron durchgeführt werden müssten, so dass sie zusammen mit den tatsächlichen Daten zurückgesetzt werden könnten (und für Ihre Anwendung erst sichtbar wären, wenn die Daten sind ebenfalls sichtbar). Die Anwendung würde das Maximum erhalten, was sehr schnell sein sollte, wenn die Tabelle indiziert wird (tatsächlich wäre diese Tabelle ein idealer Kandidat für eine indexorganisierte Tabelle). Der einzige Nachteil ist, dass Sie einen Job möchten, der regelmäßig ausgeführt wird, um alte Werte zu bereinigen, damit er nicht zu groß wird.
Tags und Links sql oracle schema timestamp sql-update