РЕГИСТРАЦИЯ/НЕРЕГИСТРАЦИЯ помага да се управлява разрешаването на директни записи по пътя, за да се намали генерирането на REDO и UNDO. Това е един от няколкото начина за контролиране на деликатния баланс между възможност за възстановяване и производителност.
Основна информация за архитектурата на Oracle
ПЪРВИ така Oracle осигурява издръжливост, "D" в ACID. Когато транзакцията е ангажирана, промените не се съхраняват непременно спретнато във файловете с данни. Това поддържа нещата бързи и позволява на фоновите процеси да се справят с известна работа. REDO е описание на промяната. Съхранява се бързо, на множество дискове, в "тъп" дневник. Промените са бързи и ако сървърът загуби мощност една микросекунда след връщането на ангажимента, Oracle може да премине през регистрационните файлове REDO, за да се увери, че промяната не е загубена.
ОТМЕНЯНЕ помага на Oracle да осигури последователност, "C" в ACID. Той съхранява описание как да отмените промяната. Тази информация може да е необходима на друг процес, който чете таблицата и трябва да знае каква е използваната стойност да бъде в по-стар момент.
Писа по директен път пропуснете REDO, UNDO, кеша и някои други функции и директно модифицирайте файлове с данни. Това е бърза, но потенциално опасна опция в много среди, поради което има толкова много объркващи опции за нейното управление. Записите по директен път се прилагат само към INSERTS и само в сценариите, описани по-долу.
Ако не направите нищо, опцията по подразбиране е най-безопасната, РЕГИСТРАЦИЯ.
Многото начини за контролиране на записите по директен път
РЕГИСТРИРАНЕ/НЕРЕГИСТРАНЕ е една от няколкото опции за контролиране на записите по директен път. Погледнете тази таблица от AskTom за да разберете как всички различни опции работят заедно:
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
ПРИНУДИТЕЛНОТО РЕГИСТРАЦИЯ може да замени всички тези настройки. Вероятно има други превключватели, за които не знам. И, разбира се, има много ограничения, които предотвратяват директния път - тригери, външни ключове, клъстери, индексни организирани таблици и т.н.
Правилата са още по-рестриктивни за индексите. Индекс ще винаги генерира REDO по време на DML изрази. Само DDL изрази, като CREATE INDEX ... NOLOGGING или ALTER INDEX ... REBUILD на NOLOGGING индекс няма да генерира REDO.
Защо има толкова много начини? Тъй като възможността за възстановяване е невероятно важна и различните роли може да имат различни възгледи по въпроса. И понякога решенията на някои хора трябва да имат предимство пред други.
Програмисти вземете решение на ниво изявление, „Режим на вмъкване“. Много странни неща могат да се случат с /*+ APPEND */ намек и разработчиците трябва да избират внимателно кога да го използват.
Архитекти вземете решение на ниво обект, "Режим на таблица". Някои таблици, независимо от това колко бързо програмист може да иска да вмъкне в тях, винаги трябва да могат да бъдат възстановени.
Администратори на бази данни решете в режим на база данни или таблично пространство, „Архивиране на журнал“ и ПРИНУДИТЕЛНО РЕГИСТРИРАНЕ. Може би организацията просто не се интересува от възстановяването на конкретна база данни, така че я настройте на режим NOARCHIVELOG. Или може би организацията има стриктно правило, че всичко трябва да може да се възстанови, така че задайте табличното пространство на ПРИНУДИТЕЛНО РЕГИСТРИРАНЕ.
