Использует ли NOLOGGING в Oracle ACID?особенно во время отключения электроэнергии - PullRequest
2 голосов
/ 29 марта 2012

При использовании NOLOGGING в Oracle, скажем, для вставки новых записей.Сможет ли моя база данных корректно восстановиться после отключения электроэнергии?если он случайно упал во время вставки.

Правильно ли я заявляю, что журналы UNDO будут использоваться для таких восстановлений ... в отличие от использования журнала REDO, которое будет использоваться для восстановления, если основные файлы данных были физически повреждены.

Ответы [ 3 ]

5 голосов
/ 30 марта 2012

Мне кажется, вы здесь путаете некоторые понятия.

Сначала давайте поговорим о восстановлении экземпляра.Восстановление экземпляра - это то, что происходит после сбоя базы данных, уничтожена ли она, отключен ли сервер и т. Д. При запуске экземпляра Oracle будет считывать данные из журналов повторов и выполнять откат, записывая все ожидающие изменения в файлы данных.Затем он считывает отмены, определяет, какие транзакции не были зафиксированы, и использует данные отмены для отката любых изменений, которые не были зафиксированы до момента сбоя.Таким образом, Oracle гарантирует восстановление до последней совершенной транзакции.

Теперь, что касается прямых нагрузок и NOLOGGING.Важно отметить, что NOLOGGING только действителен для прямых нагрузок.Это означает, что обновления и удаления никогда NOLOGGING, и что INSERT используется только при указании подсказки APPEND.

Важно понимать, что когда вы выполняете прямую загрузку, вы буквально«прямая загрузка» данных в файлы данных.Поэтому не нужно беспокоиться о проблемах, связанных с восстановлением экземпляра и т. Д. Когда вы выполняете прямую загрузку NOLOGGING, данные по-прежнему записываются непосредственно в файлы данных.

Это происходит примерно так.Вы выполняете прямую загрузку (пока оставим в стороне проблему NOLOGGING), и данные загружаются непосредственно в файлы данных.То, как это происходит, заключается в том, что Oracle выделит хранилище выше максимальной отметки (HWM), отформатирует и загрузит эти совершенно новые блоки напрямую.Когда это распределение блоков выполнено, те обновления словаря данных, которые описывают распределение пространства, записываются и защищаются повтором.Затем, когда ваша транзакция фиксируется, изменения становятся постоянными.

Теперь, в случае сбоя экземпляра, либо транзакция была зафиксирована (в этом случае данные находятся в файлах данных, а словарь данных отражает эти новые экстенты).были выделены) или не были зафиксированы, и таблица выглядит точно так же, как и до начала прямой загрузки.Итак, опять данные до последней зафиксированной транзакции включительно.

Теперь, NOLOGGING.Регистрируется ли прямая загрузка или нет, не имеет значения для целей восстановления экземпляра. только вступит в игру в случае сбоя носителя и восстановления носителя.

Если у вас возникнет сбой носителя, вам необходимо будет выполнить восстановление из резервной копии.Таким образом, вы восстановите поврежденный файл данных, а затем примените повтор из архивированных журналов повторов, чтобы «воспроизвести» транзакции, которые произошли с момента резервного копирования до текущего момента времени.Пока все изменения были зарегистрированы, это не проблема, так как все данные есть в журналах повторов.Однако, что произойдет в случае сбоя носителя после прямой загрузки NOLOGGING?

Хорошо, когда повтор применяется к вашим сегментам, которые были загружены с помощью NOLOGGING, необходимые данные not в повтор.Итак, те транзакции со словарем данных, о которых я упоминал, создали новые экстенты, в которые были загружены данные, которые находятся в состоянии повтора, но не для заполнения этих блоков.Таким образом, экстенты выделяются сегменту, но затем также помечаются как недействительные.Таким образом, если / когда вы попытаетесь выбрать из таблицы и нажмете эти недопустимые блоки, вы получите ORA-26040 «данные были загружены с использованием опции NOLOGGING».Это Oracle, сообщающий вам, что у вас есть повреждение данных, вызванное восстановлением через операцию NOLOGGING.

Итак, что делать?Ну, во-первых, каждый раз, когда вы загружаете данные с помощью NOLOGGING, убедитесь, что вы можете повторно запустить загрузку, если это необходимо.Таким образом, если вы испытываете сбой экземпляра во время загрузки, вы можете перезапустить загрузку или если у вас произошел сбой носителя между временем загрузки NOLOGGING и следующей резервной копией, вы можете перезапустить загрузку.

Обратите внимание, что в случае прямой загрузки NOLOGGING вы потеряете данные только до следующей резервной копии файлов данных / табличных пространств, содержащих сегменты, которые имели прямую загрузку. Как только он будет защищен резервной копией, вы в безопасности.

Надеюсь, что это поможет прояснить идеи относительно прямых нагрузок, NOLOGGING, восстановления экземпляров и восстановления носителей.

1 голос
/ 30 марта 2012

Если вы используете NOLOGGING, вам нет дела до данных. Операции Nologging должны быть восстановлены с помощью других процедур, чем обычные процедуры восстановления баз данных. Много раз восстановление будет происходить без проблем. Проблема в том, что у вас сбой питания в хранилище. В этом случае вы можете повредить онлайн-повтор, который был активным, и из-за этого также возникли проблемы с поврежденными сегментами отмены.

Итак, конкретно в вашем случае: я бы не стал на это ставить. Да, большая часть восстановления будет выполнена путем чтения отмены, которая может застрять из-за точно описанной вами ситуации. Это одна из самых неприятных проблем для восстановления.

0 голосов
/ 03 июня 2015

Поскольку СУБД должна быть на 100% совместимой с ACID, она должна быть сериализуемой, что очень редко встречается даже среди крупных поставщиков. Чтобы сериализованные блокировки чтения, записи и диапазона должны быть сняты в конце транзакции. В Oracle нет блокировок чтения, поэтому Oracle не на 100% совместим с ACID.

...