Oracle
 sql >> Datenbank >  >> RDS >> Oracle

Trigger ist in Oracle ungültig

Immer wenn wir eine Änderung an einem Datenbankobjekt bereitstellen, wird jeglicher Code, der davon abhängt, ungültig. Dies betrifft Trigger, Ansichten und gespeicherte Prozeduren. Das nächste Mal, wenn etwas diesen Code aufruft, wird die Datenbank ihn jedoch automatisch neu kompilieren.

Da brauchen wir uns also keine Sorgen zu machen, oder? Nun ja, bis zu einem gewissen Punkt. Die Sache ist die, dass die Invalidierung der Trigger (oder was auch immer) für uns ein Hinweis darauf ist, dass eine Änderung vorgenommen wurde, die den Betrieb dieses Triggers beeinflussen könnte, was Nebenwirkungen haben könnte. Der offensichtlichste Nebeneffekt ist, dass der Trigger nicht kompiliert wird. Auf subtilere Weise wird der Trigger kompiliert, schlägt jedoch während des Betriebs fehl.

Daher ist es eine gute Idee, die Neukompilierung von Triggern in einer Entwicklungsumgebung zu erzwingen, um sicherzustellen, dass unsere Änderung nichts grundlegend beschädigt hat. Aber wir können diesen Schritt überspringen, wenn wir unsere Änderung in der Produktion bereitstellen, weil wir so zuversichtlich sind, dass alles bei Bedarf neu kompiliert wird. Hängt von unseren Nerven ab :)

Oracle bietet Mechanismen zum automatischen Neukompilieren aller ungültigen Objekte in einem Schema.

  • Am einfachsten ist die Verwendung von DBMS_UTILITY.COMPILE_SCHEMA() . Dies ist jedoch seit 8i zweifelhaft (weil die Unterstützung für gespeicherte Java-Prozeduren das Potenzial für zirkuläre Abhängigkeiten einführte) und es ist nicht mehr garantiert, dass alle Objekte beim ersten Mal erfolgreich kompiliert werden.

  • In 9i gab uns Oracle ein Skript $ORACLE_HOME/rdbms/admin/utlrp.sql die Dinge neu kompiliert. Leider erfordert es SYSDBA-Zugriff.

  • In 10g haben sie das UTL_RECOMP-Paket hinzugefügt, das im Grunde alles tut, was dieses Skript tut. Dies ist der empfohlene Ansatz zum erneuten Kompilieren einer großen Anzahl von Objekten. Leider erfordert es auch SYSDBA-Zugriff. Erfahren Sie mehr .

In 11g führte Oracle ein feinkörniges Abhängigkeitsmanagement ein. Das bedeutet, dass Änderungen an Tabellen mit einer feineren Granularität ausgewertet werden (im Wesentlichen auf Spaltenebene statt auf Tabellenebene) und nur Objekte betroffen sind, die direkt von den Änderungen betroffen sind. Erfahren Sie mehr .