LOGGING/NOLOGGING helpt bij het beheren van het mogelijk maken van directe padschrijfacties om het genereren van REDO en UNDO te verminderen. Het is een van de vele manieren om de delicate balans tussen herstelbaarheid en prestaties te beheersen.
Achtergrondinformatie Oracle-architectuur
OPNIEUW is hoe Oracle duurzaamheid biedt, de "D" in ACID. Wanneer een transactie wordt uitgevoerd, worden de wijzigingen niet noodzakelijk netjes opgeslagen in de databestanden. Dat houdt de zaken snel en laat achtergrondprocessen wat werk afhandelen. REDO is een beschrijving van de wijziging. Het wordt snel opgeslagen, op meerdere schijven, in een "domme" log. Wijzigingen zijn snel en als de server één microseconde nadat de commit is geretourneerd stroom verliest, kan Oracle de REDO-logboeken doornemen om ervoor te zorgen dat de wijziging niet verloren gaat.
UNDOEN helpt Oracle consistentie te bieden, de "C" in ACID. Het slaat een beschrijving op van hoe de wijziging ongedaan kan worden gemaakt. Deze informatie kan nodig zijn voor een ander proces dat de tabel leest en moet weten wat de waarde gebruikt om op een ouder tijdstip te zijn.
Direct pad schrijft sla REDO, UNDO, de cache en enkele andere functies over en wijzig gegevensbestanden rechtstreeks. Dit is een snelle maar potentieel gevaarlijke optie in veel omgevingen, daarom zijn er zoveel verwarrende opties om het te besturen. Directe padschrijfacties zijn alleen van toepassing op INSERTS en alleen in de hieronder beschreven scenario's.
Als u niets doet, is de standaardoptie de veiligste, LOGGEN.
De vele manieren om directe padschrijfacties te beheren
LOGGING/NOLOGGING is een van de vele opties om directe padschrijfacties te beheren. Bekijk deze tabel van Vraag Tom om te begrijpen hoe de verschillende opties allemaal samenwerken:
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 al deze instellingen overschrijven. Er zijn waarschijnlijk nog andere schakelaars die ik niet ken. En natuurlijk zijn er de vele beperkingen die directe paden verhinderen - triggers, externe sleutels, cluster, index-georganiseerde tabellen, enz.
De regels zijn zelfs nog restrictiever voor indexen. Een index zal altijd REDO genereren tijdens DML-instructies. Alleen DDL-instructies, zoals CREATE INDEX ... NOLOGGING of ALTER INDEX ... REBUILD op een NOLOGGING-index genereert geen REDO.
Waarom zijn er zoveel manieren? Omdat herstelbaarheid ontzettend belangrijk is en verschillende rollen daar verschillende opvattingen over kunnen hebben. En soms moeten de beslissingen van sommige mensen voorrang krijgen op andere.
Ontwikkelaars beslis op het niveau van de instructie, "Insert Mode". Er kunnen veel rare dingen gebeuren met een /*+ APPEND */ hint en ontwikkelaars moeten zorgvuldig kiezen wanneer ze het willen gebruiken.
Architecten beslis op objectniveau, "Tabelmodus". Sommige tabellen, ongeacht hoe snel een ontwikkelaar erin wil invoegen, moeten altijd herstelbaar zijn.
Databasebeheerders beslis in de database- of tablespace-modus, "Archief log" en FORCE LOGGING. Misschien geeft de organisatie er gewoon niet om om een specifieke database te herstellen, dus zet deze in de NOARCHIVELOG-modus. Of misschien heeft de organisatie een strikte regel dat alles herstelbaar moet zijn, dus stel de tablespace in op FORCE LOGGING.