LOGGING/NOLOGGING hjælper med at administrere aktivering af direkte stiskrivning for at reducere genereringen af REDO og UNDO. Det er en af flere måder at kontrollere den delikate balance mellem genvindelighed og ydeevne.
Oracle Architecture-baggrundsoplysninger
GENGØR er, hvordan Oracle giver holdbarhed, "D" i ACID. Når en transaktion er begået, bliver ændringerne ikke nødvendigvis gemt pænt i datafilerne. Det holder tingene hurtigt og lader baggrundsprocesser klare noget arbejde. REDO er en beskrivelse af ændringen. Det gemmes hurtigt, på flere diske, i en "dum" log. Ændringer er hurtige, og hvis serveren mister strøm et mikrosekund efter, at commit er returneret, kan Oracle gennemgå REDO-logfilerne for at sikre, at ændringen ikke går tabt.
UNDO hjælper Oracle med at give konsistens, "C"et i ACID. Den gemmer en beskrivelse af, hvordan ændringen kan fortrydes. Disse oplysninger kan være nødvendige for en anden proces, der læser tabellen og skal vide, hvad værdien brugte at være på et ældre tidspunkt.
Direkte sti skriver spring over REDO, UNDO, cachen og nogle andre funktioner, og modificer datafiler direkte. Dette er en hurtig, men potentielt farlig mulighed i mange miljøer, hvorfor der er så mange forvirrende muligheder for at kontrollere den. Direkte stiskrivning gælder kun for INSERTS, og kun i scenarierne beskrevet nedenfor.
Hvis du ikke gør noget, er standardindstillingen den sikreste, LOGGING.
De mange måder at kontrollere direkte stiskrivning på
LOGGING/NOLOGGING er en af flere muligheder for at styre direkte stiskrivning. Se denne tabel fra SpørgTom for at forstå, hvordan de forskellige muligheder alle arbejder sammen:
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 tilsidesætte alle disse indstillinger. Der er sikkert nogle andre kontakter jeg ikke er klar over. Og selvfølgelig er der de mange begrænsninger, der forhindrer direkte sti - triggere, fremmednøgler, klynge, indeksorganiserede tabeller osv.
Reglerne er endnu mere restriktive for indekser. Et indeks vil altid generere REDO under DML-sætninger. Kun DDL-sætninger, såsom CREATE INDEX ... NOLOGGING eller ALTER INDEX ... REBUILD på et NOLOGGING-indeks vil ikke generere REDO.
Hvorfor er der så mange måder? Fordi inddrivelse er utrolig vigtig, og forskellige roller kan have forskellige syn på sagen. Og nogle gange skal nogle menneskers beslutninger tilsidesætte andre.
Udviklere beslutte på erklæringsniveauet "Indsæt tilstand". Mange mærkelige ting kan ske med en /*+ APPEND */ tip, og udviklere skal vælge omhyggeligt, hvornår de vil bruge det.
Arkitekter beslutte på objektniveau "Tabeltilstand". Nogle tabeller, uanset hvor hurtigt en udvikler ønsker at indsætte i dem, skal altid kunne gendannes.
Databaseadministratorer beslutte i database- eller tablespace-tilstand, "Arkivlog" og FORCE LOGGING. Måske er organisationen bare ligeglad med at gendanne en bestemt database, så sæt den til NOARCHIVELOG-tilstand. Eller måske har organisationen en streng regel om, at alt skal kunne gendannes, så sæt tablespacet til FORCE LOGGING.