LOGGING/NOLOGGING hjälper till att hantera aktivering av direkta sökvägsskrivningar för att minska genereringen av REDO och UNDO. Det är ett av flera sätt att kontrollera den känsliga balansen mellan återvinningsbarhet och prestanda.
Bakgrundsinformation för Oracle Architecture
GÖR OM är hur Oracle ger hållbarhet, "D" i ACID. När en transaktion genomförs lagras ändringarna inte nödvändigtvis snyggt i datafilerna. Det håller saker och ting snabbt och låter bakgrundsprocesser hantera en del arbete. REDO är en beskrivning av förändringen. Det lagras snabbt, på flera diskar, i en "dum" logg. Ändringarna är snabba och om servern tappar strömmen en mikrosekund efter att commit återkom, kan Oracle gå igenom REDO-loggarna för att se till att ändringen inte går förlorad.
ÅNGRA hjälper Oracle att ge konsekvens, "C" i ACID. Den lagrar en beskrivning av hur man vänder ändringen. Denna information kan behövas av en annan process som läser tabellen och behöver veta vilket värde som används att vara på en äldre tidpunkt.
Direkt sökväg skriver hoppa över REDO, UNDO, cachen och några andra funktioner och ändra datafiler direkt. Detta är ett snabbt men potentiellt farligt alternativ i många miljöer, varför det finns så många förvirrande alternativ för att kontrollera det. Direkta sökvägsskrivningar gäller endast INSLAG, och endast i de scenarier som beskrivs nedan.
Om du inte gör något är standardalternativet det säkraste, LOGGNING.
De många sätten att styra direkta sökvägsskrivningar
LOGGING/NOLOGGING är ett av flera alternativ för att styra skrivning av direkta sökvägar. Titta på den här tabellen från AskTom för att förstå hur de olika alternativen fungerar tillsammans:
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 kan åsidosätta alla dessa inställningar. Det finns säkert några andra switchar som jag inte är medveten om. Och naturligtvis finns det många begränsningar som förhindrar direkt sökväg - triggers, främmande nycklar, kluster, indexerade organiserade tabeller, etc.
Reglerna är ännu mer restriktiva för index. Ett index kommer alltid generera REDO under DML-satser. Endast DDL-satser, som CREATE INDEX ... NOLOGGING eller ALTER INDEX ... REBUILD på ett NOLOGGING-index genererar inte REDO.
Varför finns det så många sätt? Eftersom återvinningsbarhet är otroligt viktigt och olika roller kan ha olika syn på saken. Och ibland måste vissa människors beslut åsidosätta andra.
Utvecklare bestäm på satsnivån "Infogningsläge". Många konstiga saker kan hända med en /*+ APPEND */ tips och utvecklare måste noga välja när de ska använda den.
Arkitekter bestäm på objektnivå, "Table Mode". Vissa tabeller, oavsett hur snabbt en utvecklare vill infoga i den, måste alltid kunna återställas.
Databasadministratörer bestäm i databas- eller tabellutrymmesläget, "Arkivlogg" och FORCE LOGGING. Kanske organisationen helt enkelt inte bryr sig om att återställa en specifik databas, så ställ in den på NOARCHIVELOG-läge. Eller så kanske organisationen har en strikt regel att allt måste kunna återställas, så ställ in tabellutrymmet på FORCE LOGGING.