REJESTROWANIE/NIELOGOWANIE pomaga zarządzać włączaniem bezpośredniego zapisu ścieżki w celu zmniejszenia generowania REDO i UNDO. Jest to jeden z kilku sposobów kontrolowania delikatnej równowagi między odzyskiwalnością a wydajnością.
Informacje ogólne o architekturze Oracle
PONÓW w ten sposób Oracle zapewnia trwałość, „D” w ACID. Kiedy transakcja jest zatwierdzona, zmiany niekoniecznie są starannie przechowywane w plikach danych. Dzięki temu wszystko działa szybko i procesy w tle mogą zająć się pewną pracą. REDO to opis zmiany. Jest on szybko przechowywany na wielu dyskach w „głupie” dzienniku. Zmiany są szybkie, a jeśli serwer straci moc jedną mikrosekundę po zwróceniu zatwierdzenia, Oracle może przejrzeć dzienniki REDO, aby upewnić się, że zmiana nie zostanie utracona.
COFNIJ pomaga Oracle zapewnić spójność, „C” w ACID. Przechowuje opis, jak cofnąć zmianę. Ta informacja może być potrzebna przez inny proces, który czyta tabelę i musi wiedzieć, jakiej użyła wartość być w starszym momencie.
Bezpośredni zapis ścieżki pomiń REDO, COFNIJ, pamięć podręczną i niektóre inne funkcje oraz bezpośrednio modyfikuj pliki danych. Jest to szybka, ale potencjalnie niebezpieczna opcja w wielu środowiskach, dlatego istnieje tak wiele mylących opcji jej kontrolowania. Bezpośrednie zapisy ścieżki dotyczą tylko WSTAWEK i tylko w scenariuszach opisanych poniżej.
Jeśli nic nie zrobisz, opcja domyślna jest najbezpieczniejsza, REJESTROWANIE.
Wiele sposobów kontrolowania bezpośredniego zapisu ścieżki
REJESTROWANIE/NIELOGOWANIE to jedna z kilku opcji kontrolowania bezpośredniego zapisu ścieżki. Spójrz na tę tabelę z Zapytaj Toma aby zrozumieć, jak różne opcje współpracują ze sobą:
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 może unieważnić wszystkie te ustawienia. Prawdopodobnie istnieją inne przełączniki, o których nie wiem. I oczywiście istnieje wiele ograniczeń, które uniemożliwiają bezpośrednią ścieżkę - wyzwalacze, klucze obce, klaster, tabele zorganizowane według indeksu itp.
Zasady są jeszcze bardziej restrykcyjne dla indeksów. Indeks zawsze generować REDO podczas instrukcji DML. Tylko instrukcje DDL, takie jak CREATE INDEX ... NOLOGGING lub ALTER INDEX ... REBUILD na indeksie NOLOGGING nie wygeneruje REDO.
Dlaczego jest tak wiele sposobów? Ponieważ odzyskiwanie jest niezwykle ważne, a różne role mogą mieć różne poglądy na tę sprawę. A czasami decyzje niektórych osób muszą mieć pierwszeństwo przed innymi.
Programiści zdecyduj na poziomie wyciągu, „Tryb wstawiania”. Wiele dziwnych rzeczy może się zdarzyć z /*+ APPEND */ wskazówka, a programiści muszą starannie wybrać, kiedy z niej skorzystać.
Architekci decydować na poziomie obiektu „Tryb tabeli”. Niektóre tabele, niezależnie od tego, jak szybko programista może chcieć je wstawić, zawsze muszą być możliwe do odzyskania.
Administratorzy bazy danych zdecydować w trybie bazy danych lub przestrzeni tabel, "Dziennik archiwum" i FORCE LOGGING. Może organizacji po prostu nie zależy na odzyskaniu określonej bazy danych, więc ustaw ją w trybie NOARCHIVELOG. A może organizacja ma ścisłą zasadę, że wszystko musi być możliwe do odzyskania, więc ustaw obszar tabel na FORCE LOGGING.
