Оракул без регистрации, что это такое
Обновлено: 28.06.2024
Предложение logging_clause позволяет указать, будет ли создание объекта базы данных регистрироваться в файле журнала повторов ( LOGGING ) или нет ( NOLOGGING ).
Вы можете указать logging_clause в следующих операторах:
CREATE TABLE и ALTER TABLE : для регистрации таблицы, раздела таблицы, сегмента больших объектов или сегмента переполнения индексно-организованной таблицы (см. CREATE TABLE и ALTER TABLE).
CREATE INDEX и ALTER INDEX : для регистрации индекса или раздела индекса (см. CREATE INDEX и ALTER INDEX).
CREATE MATERIALIZED VIEW и ALTER MATERIALIZED VIEW: для регистрации материализованного представления, одного из его разделов или сегмента LOB (см. CREATE MATERIALIZED VIEW и ALTER MATERIALIZED VIEW).
CREATE MATERIALIZED VIEW LOG и ALTER MATERIALIZED VIEW LOG: для регистрации журнала материализованного представления или одного из его разделов (см. CREATE MATERIALIZED VIEW LOG и ALTER MATERIALIZED VIEW LOG).
CREATE TABLESPACE и ALTER TABLESPACE : чтобы установить или изменить характеристики регистрации по умолчанию для всех объектов, созданных в табличном пространстве (см. CREATE TABLESPACE и ALTER TABLESPACE).
Вы также можете указать LOGGING или NOLOGGING для следующих операций:
Перестроение индекса (используя CREATE INDEX .REBUILD )
Перемещение таблицы (используя ALTER TABLE .MOVE )
В этом разделе описывается семантика logging_clause . Для получения дополнительной информации обратитесь к оператору SQL, в котором вы задаете или сбрасываете характеристики ведения журнала для определенного объекта базы данных.
Укажите LOGGING, если вы хотите, чтобы создание объекта базы данных, а также последующие вставки в объект регистрировались в файле журнала повторов.
Укажите NOLOGGING, если вы не хотите, чтобы эти операции регистрировались.
Для неразделенного объекта значение, указанное в этом предложении, является фактическим физическим атрибутом сегмента, связанного с объектом.
Для многораздельных объектов значение, указанное для этого предложения, является физическим атрибутом по умолчанию сегментов, связанных со всеми разделами, указанными в инструкции CREATE (и в последующих инструкциях ALTER .ADD PARTITION), если вы не укажете атрибут ведения журнала в PARTITION. описание.
Если объект, для которого вы указываете атрибуты ведения журнала, находится в базе данных или табличном пространстве в режиме принудительного ведения журнала, то Oracle Database игнорирует любой параметр NOLOGGING до тех пор, пока база данных или табличное пространство не будет выведено из режима принудительного ведения журнала.
Если база данных работает в режиме архивного журнала, восстановление носителя из резервной копии, сделанной до того, как операция LOGGING повторно создаст объект. Однако при восстановлении носителя из резервной копии, сделанной до операции NOLOGGING, объект не создается повторно.
Размер журнала повторов, созданного для операции в режиме NOLOGGING, значительно меньше, чем журнал, созданный в режиме LOGGING.
В режиме NOLOGGING данные изменяются с минимальной записью в журнал (для пометки новых экстентов INVALID и для записи изменений словаря). При применении во время восстановления носителя записи об аннулировании экстента помечают диапазон блоков как логически поврежденные, поскольку данные повторного выполнения не полностью регистрируются. Поэтому, если вы не можете позволить себе потерять объект базы данных, вам следует сделать резервную копию после операции NOLOGGING.
NOLOGGING поддерживается только в подмножестве местоположений, поддерживающих LOGGING . Только следующие операции поддерживают режим NOLOGGING:
Вставка прямого пути (последовательная или параллельная), являющаяся результатом оператора INSERT или MERGE. NOLOGGING неприменим к любым операциям UPDATE, возникающим в результате оператора MERGE.
Прямой загрузчик (SQL*Loader)
СОЗДАТЬ ТАБЛИЦУ . КАК ВЫБРАТЬ
СОЗДАТЬ ТАБЛИЦУ . LOB_storage_clause . LOB_параметры . НОКАШ | ЧТЕНИЕ КЭША
ИЗМЕНИТЬ ТАБЛИЦУ . LOB_storage_clause . LOB_параметры . НОКАШ | CACHE READS (чтобы указать ведение журнала вновь созданных столбцов LOB)
ИЗМЕНИТЬ ТАБЛИЦУ . изменить_LOB_storage_clause . изменить_LOB_параметры. НОКАШ | CACHE READS (для изменения регистрации существующих столбцов LOB)
ИЗМЕНИТЬ ТАБЛИЦУ . ПЕРЕМЕЩАТЬ
ИЗМЕНИТЬ ТАБЛИЦУ . (все операции с разделами, связанные с перемещением данных)
ИЗМЕНИТЬ ТАБЛИЦУ . ДОБАВИТЬ РАЗДЕЛ (только хеш-раздел)
ИЗМЕНИТЬ ТАБЛИЦУ . ОБЪЕДИНИТЬ РАЗДЕЛЫ
ИЗМЕНИТЬ ТАБЛИЦУ . РАЗДЕЛИТЬ РАЗДЕЛ
ИЗМЕНИТЬ ТАБЛИЦУ . ПЕРЕМЕСТИТЬ РАЗДЕЛ
ИЗМЕНИТЬ ТАБЛИЦУ . ИЗМЕНИТЬ РАЗДЕЛ. ДОБАВИТЬ ПОДРАЗДЕЛ
ИЗМЕНИТЬ ТАБЛИЦУ . ИЗМЕНИТЬ РАЗДЕЛ. ОБЪЕДИНИТЬ ПОДРАЗДЕЛ
ИЗМЕНИТЬ ИНДЕКС . ВОССТАНОВИТЬ
ИЗМЕНИТЬ ИНДЕКС . ВОССТАНОВИТЬ [ПОД]РАЗДЕЛ
ИЗМЕНИТЬ ИНДЕКС . РАЗДЕЛИТЬ РАЗДЕЛ
Для объектов, отличных от LOB , если вы опустите это предложение, атрибут ведения журнала объекта по умолчанию будет равен атрибуту ведения журнала табличного пространства, в котором он находится.
Для больших объектов, если вы опустите это предложение:
Если вы укажете CACHE , будет использоваться LOGGING (поскольку вы не можете использовать CACHE NOLOGGING ).
Если вы укажете NOCACHE или CACHE READS , атрибут ведения журнала по умолчанию будет равен атрибуту ведения журнала табличного пространства, в котором он находится.
NOLOGGING не применяется к LOB, которые хранятся вместе с данными строк. То есть, если вы укажете NOLOGGING для LOB со значениями менее 4000 байт и не отключите STORAGE IN ROW , Oracle проигнорирует спецификацию NOLOGGING и будет обрабатывать данные LOB так же, как и другие табличные данные.
Концепции базы данных Oracle и руководство администратора базы данных Oracle для получения дополнительной информации о ведении журналов и параллельном DML
Что произойдет, если я не укажу ведение журнала или отсутствие ведения журнала в объектах базы данных в Oracle? Что я хотел сказать, как будет вести себя с ведением/отсутствием ведения журнала в объектах базы данных и без ведения/отсутствия ведения журнала в объектах базы данных?
Спасибо всем, всего один вопрос Джону Хеллеру; Вы упомянули ниже диаграммы «Опция NOLOGGING помогает только для индексов во время перестроений». что подразумеваешь под этим? я не понял, я был бы очень признателен за вашу поддержку
3 ответа 3
ВЕДЕНИЕ РЕГИСТРАЦИИ/БЕЗ РЕГИСТРАЦИИ помогает управлять записью по прямому пути, чтобы сократить количество операций REDO и UNDO. Это один из нескольких способов контролировать тонкий баланс между возможностью восстановления и производительностью.
Основная информация об архитектуре Oracle
REDO — это то, как Oracle обеспечивает надежность, "D" в ACID. Когда транзакция зафиксирована, изменения не обязательно аккуратно сохраняются в файлах данных. Это ускоряет работу и позволяет фоновым процессам выполнять некоторую работу. REDO — это описание изменения. Он хранится быстро, на нескольких дисках, в «тупом» журнале. Изменения вносятся быстро, и если сервер теряет питание через одну микросекунду после возврата фиксации, Oracle может просмотреть журналы REDO, чтобы убедиться, что изменение не потеряно.
UNDO помогает Oracle обеспечить согласованность, букву "C" в ACID. В нем хранится описание того, как отменить изменение. Эта информация может понадобиться другому процессу, который читает таблицу и должен знать, какое значение использовалось в более ранний момент времени.
Прямая запись пути пропускает REDO, UNDO, кэш и некоторые другие функции и напрямую изменяет файлы данных. Это быстрый, но потенциально опасный вариант во многих средах, поэтому существует так много запутанных вариантов его управления. Запись прямого пути применяется только к INSERTS и только в сценариях, описанных ниже.
Если вы ничего не делаете, самым безопасным вариантом по умолчанию является РЕГИСТРАЦИЯ.
Множество способов управления записью прямого пути
ВЕДЕНИЕ РЕГИСТРАЦИИ/НЕТ РЕГИСТРАЦИИ — это один из нескольких вариантов управления записью по прямому пути. Посмотрите на эту таблицу от AskTom, чтобы понять, как различные варианты работают вместе:
ПРИНУДИТЕЛЬНОЕ РЕГИСТРИРОВАНИЕ может переопределить все эти настройки. Возможно, есть еще какие-то переключатели, о которых я не знаю. И, конечно же, существует множество ограничений, препятствующих прямому пути — триггеры, внешние ключи, кластеры, индексированные таблицы и т. д.
Для индексов правила еще более строгие. Индекс будет всегда генерировать REDO во время операторов DML. Только операторы DDL, такие как CREATE INDEX . NOLOGGING или ALTER INDEX . REBUILD для индекса NOLOGGING не будет генерировать REDO.
Почему так много способов? Потому что возможность восстановления невероятно важна, и разные роли могут иметь разные взгляды на этот вопрос. А иногда решения одних людей должны превалировать над другими.
Разработчики выбирают "Режим вставки" на уровне оператора. С подсказкой /*+ APPEND */ может произойти много странных вещей, и разработчикам нужно тщательно выбирать, когда ее использовать.
Архитекторы решают на уровне объекта "Режим таблицы". Некоторые таблицы, независимо от того, как быстро разработчик захочет вставить в них данные, всегда должны быть восстанавливаемыми.
Администраторы базы данных выбирают режим базы данных или табличного пространства, "Архивировать журнал" и ПРИНУДИТЕЛЬНО РЕГИСТРИРОВАТЬ. Возможно, организация просто не заботится о восстановлении конкретной базы данных, поэтому установите для нее режим NOARCHIVELOG. Или, может быть, в организации есть строгое правило, согласно которому все должно быть восстанавливаемым, поэтому установите для табличного пространства FORCE LOGGING.
Вообще, производительность хранилища данных имеет первостепенное значение. Хранилище данных должно не только обеспечивать хорошую производительность запросов для онлайн-пользователей, но и быть эффективным в процессе извлечения, преобразования и загрузки (ETL), чтобы можно было загружать большие объемы данных в кратчайшие сроки.
Одной из распространенных оптимизаций, используемых хранилищами данных, является выполнение операций с массовыми данными с использованием режима NOLOGGING. Операции базы данных, которые поддерживают режимы NOLOGGING, — это операции загрузки и вставки прямого пути, создание индекса и создание таблицы. Когда операция выполняется в режиме NOLOGGING, данные не записываются в журнал повторов (точнее, в журнал повторов записывается только небольшой набор метаданных). Этот режим широко используется в хранилищах данных и может повысить производительность операций с массовыми данными до 50%.
Однако компромисс заключается в том, что операция NOLOGGING не может быть восстановлена с использованием обычных механизмов восстановления, поскольку данные, необходимые для поддержки восстановления, никогда не записывались в файл журнала. Более того, последующие операции с данными, для которых была выполнена операция NOLOGGING, также не могут быть восстановлены, даже если эти операции не использовали режим NOLOGGING. Из-за прироста производительности, обеспечиваемого операциями NOLOGGING, обычно рекомендуется, чтобы хранилища данных использовали режим NOLOGGING в процессе ETL.
При разработке стратегии резервного копирования и восстановления необходимо учитывать наличие операций NOLOGGING. Когда база данных использует операции NOLOGGING, обычная стратегия восстановления (восстановление из последней резервной копии на ленте и применение архивных файлов журналов) больше не применима, поскольку файлы журналов не могут восстановить операцию NOLOGGING.
Первый принцип, который следует помнить, — не делать резервную копию во время операции NOLOGGING. Oracle Database в настоящее время не применяет это правило, поэтому администраторы баз данных должны планировать задания резервного копирования и задания ETL таким образом, чтобы операции NOLOGGING не пересекались с операциями резервного копирования.
Существует два подхода к резервному копированию и восстановлению при наличии операций NOLOGGING: ETL или добавочное резервное копирование. Если вы не используете операции NOLOGGING в своем хранилище данных, вам не нужно выбирать ни один из вариантов: вы можете восстановить свое хранилище данных с помощью архивных журналов. Однако эти варианты могут обеспечить некоторые преимущества в производительности по сравнению с подходом к восстановлению на основе архивного журнала. Вы также можете использовать ретроспективные журналы и гарантированные точки восстановления, чтобы вернуть базу данных к предыдущему моменту времени.
Этот раздел содержит следующие темы:
Извлечение, преобразование и загрузка
В процессе ETL используются несколько функций Oracle и комбинация методов для загрузки (повторной загрузки) данных в хранилище данных. Эти функции состоят из:
Переносимые табличные пространства позволяют пользователям быстро перемещать табличное пространство между базами данных Oracle. Это наиболее эффективный способ перемещения больших объемов данных между базами данных. Oracle Database предоставляет возможность переноса табличных пространств между платформами. Если исходная и целевая платформы имеют разный порядок следования байтов, то RMAN преобразует транспортируемое табличное пространство в целевой формат.
SQL*Loader загружает данные из внешних плоских файлов в таблицы базы данных Oracle. Он имеет мощный механизм анализа данных, который практически не ограничивает формат данных в файле данных.
Перекачка данных (экспорт/импорт)
Oracle Data Pump обеспечивает высокоскоростное перемещение данных и метаданных из одной базы данных в другую. Эта технология лежит в основе утилит Oracle Data Pump Export и Data Pump Import.
Функция внешних таблиц является дополнением к существующим функциям SQL*Loader. Это позволяет вам получать доступ к данным во внешних источниках, как если бы они находились в таблице в базе данных. Внешние таблицы также можно использовать с драйвером Data Pump для экспорта данных из базы данных с помощью CREATE TABLE AS SELECT * FROM , а затем импортировать данные в базу данных Oracle.
Стратегия извлечения, преобразования и загрузки
Один из подходов заключается в регулярном резервном копировании базы данных, а также в сохранении необходимых файлов данных для воссоздания процесса ETL на всю неделю. В случае необходимости восстановления хранилище данных может быть восстановлено из самой последней резервной копии. Затем вместо повторного транзакций с применением архивных журналов повторного выполнения (как это делается в обычном сценарии восстановления) можно выполнить повторный транзакцию хранилища данных путем повторного запуска процессов ETL. Эта парадигма предполагает, что процессы ETL можно легко воспроизвести, что обычно требует сохранения набора файлов извлечения для каждого процесса ETL.
Примером реализации этого подхода является создание резервной копии хранилища данных каждые выходные, а затем каждую ночь сохранение необходимых файлов для поддержки процесса ETL. Максимум 7 дней обработки ETL необходимо повторно применить для восстановления базы данных. Администратор хранилища данных может легко спрогнозировать продолжительность восстановления хранилища данных, основываясь на скорости восстановления с ленты и данных о производительности из предыдущих запусков ETL.
По сути, администратор хранилища данных получает более высокую производительность в процессе ETL с операциями NOLOGGING за счет немного более сложного и менее автоматизированного процесса восстановления. Многие администраторы хранилищ данных считают, что это желательный компромисс.
Одним недостатком этого подхода является то, что администратор хранилища данных должен отслеживать все соответствующие изменения, произошедшие в хранилище данных. Этот подход не фиксирует изменения, выходящие за рамки процесса ETL. Например, в некоторых хранилищах данных пользователи могут создавать свои собственные таблицы и структуры данных. Эти изменения теряются во время восстановления.
Это ограничение должно быть доведено до конечных пользователей.В качестве альтернативы можно также указать, что конечные пользователи должны создавать все частные объекты базы данных в отдельном табличном пространстве, и во время восстановления администратор базы данных может восстановить это табличное пространство, используя обычное восстановление, а остальную часть базы данных восстанавливая, используя подход повторного запуска процесса ETL.< /p>
Инкрементное резервное копирование
Более автоматизированная стратегия резервного копирования и восстановления при наличии операций NOLOGGING использует возможности инкрементного резервного копирования RMAN. Инкрементное резервное копирование позволяет создавать резервные копии только тех блоков, которые были изменены с момента предыдущего резервного копирования. Инкрементальные резервные копии файлов данных фиксируют изменения данных поблочно, вместо того чтобы требовать резервного копирования всех используемых блоков в файле данных. Результирующие наборы резервных копий обычно меньше по размеру и более эффективны, чем полные резервные копии файлов данных, если не изменяется каждый блок в файле данных.
Когда вы включаете отслеживание изменений блоков, Oracle Database отслеживает физическое местоположение всех изменений в базе данных. RMAN автоматически использует файл отслеживания изменений, чтобы определить, какие блоки должны быть прочитаны во время инкрементного резервного копирования. Файл отслеживания изменений блоков составляет примерно 1/30000 от общего размера базы данных.
Руководство пользователя Oracle Database Backup and Recovery для получения дополнительной информации об отслеживании изменений блоков и о том, как его включить
Поэтапный подход
Типичная стратегия резервного копирования и восстановления, использующая этот подход, заключается в создании резервной копии хранилища данных каждые выходные, а затем создании добавочных резервных копий хранилища данных каждую ночь после завершения процесса ETL. Инкрементное резервное копирование, как и обычное резервное копирование, не должно выполняться одновременно с операциями NOLOGGING. Для восстановления хранилища данных восстанавливалась резервная копия базы данных, а затем повторно применялись добавочные резервные копии каждую ночь.
Несмотря на то, что операции NOLOGGING не были зафиксированы в архивных журналах, данные операций NOLOGGING присутствуют в инкрементных резервных копиях. Кроме того, в отличие от предыдущего подхода, этой стратегией резервного копирования и восстановления можно управлять с помощью RMAN.
База данных Flashback и гарантированные точки восстановления
База данных Flashback — это быстрый и непрерывный метод восстановления на определенный момент времени для устранения широко распространенных логических ошибок. База данных Flashback опирается на дополнительные журналы, называемые журналами flashback, которые создаются в области быстрого восстановления и сохраняются в течение заданного пользователем интервала времени в соответствии с потребностями восстановления. Эти журналы отслеживают исходные изображения блоков при их обновлении.
При выполнении операции базы данных Flashback восстанавливаются и восстанавливаются только образы блоков, соответствующие измененным данным, в отличие от традиционного восстановления файлов данных, когда перед началом восстановления необходимо восстановить все блоки из резервной копии. Журналы Flashback создаются пропорционально журналам повторов.
Для очень больших и активных баз данных может оказаться невозможным вести все необходимые ретроспективные журналы для непрерывного восстановления на определенный момент времени. Однако может потребоваться создание моментального снимка на конкретный момент времени (например, непосредственно перед ночным пакетным заданием) для логических ошибок во время пакетного выполнения. Для этого сценария гарантированные точки восстановления могут быть созданы без включения ведения ретроспективного журнала.
Когда создаются гарантированные точки восстановления, журналы ретроспективных обзоров ведутся только для того, чтобы обеспечить базу данных Flashback гарантированными точками восстановления и никаким другим моментом времени, что позволяет сэкономить место. Например, можно создать гарантированные точки восстановления, а затем выполнить пакетное задание без ведения журнала. Если в течение последнего часа времени создания гарантированных точек восстановления нет предыдущих операций без ведения журнала, Flashback Database для гарантированных точек восстановления отменяет пакетное задание без ведения журнала. Чтобы вернуться к моменту после завершения пакетного задания без ведения журнала, создайте гарантированные точки восстановления как минимум за час до окончания пакетного задания.
Оценка места в журнале флэшбэка для гарантированных точек восстановления в этом сценарии зависит от того, сколько изменений в базе данных произойдет за количество дней, в течение которых вы планируете сохранять гарантированные точки восстановления. Например, чтобы сохранить гарантированные точки восстановления в течение 2 дней и вы ожидаете изменения 100 ГБ базы данных, запланируйте 100 ГБ для журналов ретроспективного анализа. 100 ГБ относятся к части базы данных, измененной после создания гарантированных точек восстановления, а не к частоте изменений.
Я размышлял, какова практическая цель использования предложения NOLOGGING для таблиц и индексов.
Насколько я знаю из документации Oracle, мы можем запретить базе данных создавать журналы повторов только при ВСТАВКЕ в режиме прямого пути. Нет возможности избежать создания журнала повторов при ОБНОВЛЕНИИ или УДАЛЕНИИ.
Итак, мы обычно пишем
чтобы предотвратить создание журнала повторов.
Я совершенно не понимаю практического преимущества использования предложения NOLOGGING при создании TABLE или INDEX, а также использования предложения NOLOGGING при создании TABLESPACES, чтобы установить значение по умолчанию для объектов, которые будут созданы в этом табличном пространстве.
Кто-нибудь может описать практический сценарий, в котором установка этого предложения для объектов базы данных может дать преимущества?
2 ответа 2
Нет такой подсказки, как NOLOGGING .
Конечно, операции UPDATE и DELETE не могут использовать преимущества NOLOGGING , но есть и другие операции, которые могут:
NOLOGGING поддерживается только в подмножестве местоположений, которые поддерживают LOGGING. Только следующие операции поддерживают режим NOLOGGING:
DML:
ВСТАВКА прямого пути (последовательная или параллельная), являющаяся результатом оператора INSERT или MERGE. NOLOGGING неприменим к любым операциям UPDATE, возникающим в результате оператора MERGE.
Прямой загрузчик (SQL*Loader)
DDL:
CREATE TABLE . AS SELECT (В режиме NOLOGGING протоколируется создание таблицы, но вставки прямого пути не регистрируются.)
CREATE TABLE . LOB_storage_clause . LOB_параметры . КЭШ | НОКАШ | ЧТЕНИЕ КЭША
ИЗМЕНИТЬ ТАБЛИЦУ . LOB_storage_clause . LOB_параметры . КЭШ | НОКАШ | CACHE READS (чтобы указать протоколирование вновь созданных столбцов LOB)
ALTER TABLE . изменить_LOB_storage_clause . изменить_LOB_параметры. КЭШ | НОКАШ | CACHE READS (для изменения регистрации существующих столбцов больших объектов)
ALTER TABLE . ПЕРЕМЕСТИТЬ
ИЗМЕНИТЬ ТАБЛИЦУ . (все операции с разделами, связанные с перемещением данных)
ALTER TABLE . ДОБАВИТЬ РАЗДЕЛ (только хеш-раздел)
ALTER TABLE . ОБЪЕДИНИТЬ РАЗДЕЛЫ
ИЗМЕНИТЬ ТАБЛИЦУ . РАЗДЕЛИТЬ РАЗДЕЛ
ИЗМЕНИТЬ ТАБЛИЦУ . ПЕРЕМЕСТИТЬ РАЗДЕЛ
ИЗМЕНИТЬ ТАБЛИЦУ . ИЗМЕНИТЬ РАЗДЕЛ. ДОБАВИТЬ ПОДРАЗДЕЛ
ИЗМЕНИТЬ ТАБЛИЦУ . ИЗМЕНИТЬ РАЗДЕЛ. ОБЪЕДИНИТЬ ПОДРАЗДЕЛ
СОЗДАТЬ ИНДЕКС
ИЗМЕНИТЬ ИНДЕКС . ВОССТАНОВИТЬ
ИЗМЕНИТЬ ИНДЕКС . ВОССТАНОВИТЬ [ПОД]РАЗДЕЛ
ИЗМЕНИТЬ ИНДЕКС . РАЗДЕЛИТЬ РАЗДЕЛ
Читайте также: