LOGGING/NOLOGGING aiuta a gestire l'abilitazione delle scritture dirette del percorso al fine di ridurre la generazione di REDO e UNDO. È uno dei tanti modi per controllare il delicato equilibrio tra recuperabilità e prestazioni.
Informazioni di base sull'architettura Oracle
RIFARE è così che Oracle fornisce durabilità, la "D" in ACID. Quando viene eseguita una transazione, le modifiche non vengono necessariamente archiviate in modo ordinato nei file di dati. Ciò mantiene le cose veloci e consente ai processi in background di gestire un po' di lavoro. REDO è una descrizione del cambiamento. Viene archiviato rapidamente, su più dischi, in un registro "stupido". Le modifiche sono rapide e se il server perde alimentazione un microsecondo dopo la restituzione del commit, Oracle può esaminare i registri REDO per assicurarsi che le modifiche non vadano perse.
ANNULLA aiuta Oracle a fornire coerenza, la "C" in ACID. Memorizza una descrizione di come annullare la modifica. Queste informazioni potrebbero essere necessarie a un altro processo che sta leggendo la tabella e ha bisogno di sapere qual è il valore usato essere in un punto temporale più vecchio.
Scrittura diretta del percorso salta REDO, UNDO, la cache e alcune altre funzionalità e modifica direttamente i file di dati. Questa è un'opzione veloce ma potenzialmente pericolosa in molti ambienti, motivo per cui ci sono così tante opzioni confuse per controllarla. Le scritture dirette del percorso si applicano solo agli INSERTI e solo negli scenari descritti di seguito.
Se non fai nulla, l'opzione predefinita è la più sicura, REGISTRAZIONE.
I molti modi per controllare le scritture del percorso diretto
LOGGING/NOLOGGING è una delle numerose opzioni per controllare le scritture del percorso diretto. Guarda questa tabella da Chiedi a Tom per capire come funzionano tutte insieme le diverse opzioni:
Table Mode Insert Mode ArchiveLog mode result
----------- ------------- ----------------- ----------
LOGGING APPEND ARCHIVE LOG redo generated
NOLOGGING APPEND ARCHIVE LOG no redo
LOGGING no append ARCHIVE LOG redo generated
NOLOGGING no append ARCHIVE LOG redo generated
LOGGING APPEND noarchive log mode no redo
NOLOGGING APPEND noarchive log mode no redo
LOGGING no append noarchive log mode redo generated
NOLOGGING no append noarchive log mode redo generated
FORCE LOGGING può sovrascrivere tutte queste impostazioni. Probabilmente ci sono altri interruttori di cui non sono a conoscenza. E, naturalmente, ci sono molte limitazioni che impediscono il percorso diretto:trigger, chiavi esterne, cluster, tabelle organizzate indici, ecc.
Le regole sono ancora più restrittive per gli indici. Un indice sarà sempre generare REDO durante le istruzioni DML. Solo istruzioni DDL, come CREATE INDEX ... NOLOGGING o ALTER INDEX ... REBUILD su un indice NOLOGGING non genererà REDO.
Perché ci sono così tanti modi? Perché la recuperabilità è incredibilmente importante e ruoli diversi possono avere punti di vista diversi sulla questione. E a volte le decisioni di alcune persone devono prevalere su altre.
Sviluppatori decidere a livello di istruzione, "Modalità di inserimento". Molte cose strane possono accadere con un /*+ APPEND */ suggerimento e gli sviluppatori devono scegliere con attenzione quando usarlo.
Architetti decidere a livello di oggetto, "Modalità tabella". Alcune tabelle, indipendentemente dalla velocità con cui uno sviluppatore potrebbe voler inserirle, devono essere sempre recuperabili.
Amministratori di database decidere in modalità database o tablespace, "Registro archivio" e FORCE LOGGING. Forse l'organizzazione semplicemente non si preoccupa di recuperare un database specifico, quindi impostalo sulla modalità NOARCHIVELOG. O forse l'organizzazione ha una regola rigida secondo cui tutto deve essere recuperabile, quindi imposta il tablespace su FORCE LOGGING.
