Oracle
 sql >> Database >  >> RDS >> Oracle

Il trigger non è valido in Oracle

Ogni volta che distribuiamo una modifica a un oggetto di database, qualsiasi codice che dipende da esso viene invalidato. Ciò influisce su trigger, viste e stored procedure. Tuttavia, la prossima volta che qualcosa chiama quel codice, il database lo ricompiglierà automaticamente.

Quindi non dobbiamo preoccuparci di questo, giusto? Ebbene sì, fino a un certo punto. Il fatto è che l'invalidazione dei trigger (o qualsiasi altra cosa) ci segnala che è stata apportata una modifica che potrebbe influire sul funzionamento di quel trigger, il che potrebbe avere effetti collaterali. L'effetto collaterale più ovvio è che il trigger non verrà compilato. Più sottilmente, il trigger viene compilato ma non riesce durante le operazioni.

Quindi, è una buona idea forzare la ricompilazione dei trigger in un ambiente di sviluppo, per garantire che il nostro cambiamento non abbia fondamentalmente rotto nulla. Ma possiamo saltare questo passaggio quando implementiamo la nostra modifica nella produzione, perché siamo così sicuri che tutto verrà ricompilato su richiesta. Dipende dal nostro coraggio :)

Oracle fornisce meccanismi per ricompilare automaticamente tutti gli oggetti non validi in uno schema.

  • Il più semplice è usare DBMS_UTILITY.COMPILE_SCHEMA() . Ma questo è stato incerto dall'8i (perché il supporto per Java Stored Procedure ha introdotto il potenziale per le dipendenze circolari) e non è più garantito che tutti gli oggetti vengano compilati correttamente la prima volta.

  • In 9i Oracle ci ha fornito uno script $ORACLE_HOME/rdbms/admin/utlrp.sql che ricompilavano le cose. Sfortunatamente richiede l'accesso a SYSDBA.

  • In 10g hanno aggiunto il pacchetto UTL_RECOMP, che praticamente fa tutto ciò che fa quello script. Questo è l'approccio consigliato per ricompilare un numero elevato di oggetti. Sfortunatamente richiede anche l'accesso a SYSDBA. Scopri di più .

In 11g Oracle ha introdotto la gestione delle dipendenze a grana fine. Ciò significa che le modifiche alle tabelle vengono valutate con una granularità più fine (sostanzialmente a livello di colonna anziché a livello di tabella) e solo gli oggetti che sono direttamente interessati dalle modifiche sono interessati. Scopri di più .