Nologging oracle что это

Обновлено: 06.07.2024

Уменьшение времени пакетной (для olap/dwh) вставки данных:
Отличительная особенность olap: вставка одна, но очень большая.

1. Делаем таблицу не логируемой.
Что уменьшит затраты на вставку в redo log.
* Может не сработать, если в базе включено FORCE_LOGGING = YES

2. Добавляем /*+ append */ в insert операцию
* Данные добавляются в конец таблицы, вместо попытки поиска пустых мест.
* Данные пишутся напрямую в data файлы, минуя буферный кэш.

3. Отключаем constraint, trigger на таблице и явно вставляем значения в default колонки.
Замечу, что если надо ускорить вставку, то надо отключать FK на самой таблице, а если удаление, то FK на других таблицах, которые указывают на нашу.

4. Распараллеливаем запрос хинтом /*+ PARALLEL (8) */
Не забываем включать параллельность для DML, чтобы параллелился и insert, а не только select.

5. Если распаралеллить вставку нельзя, к примеру из-за доступа по dblink.
Можно физически распаралелить вставку через несколько одновременных вставок кусками части данных из источника.
Сделать это можно через dbms_parallel.
Очень хорошо подходит для одновременного копирования нескольких таблиц или если таблица партиционирована.
При вставке в одну таблицу незабываем про ограничения хинта append из п.2

6. Удаляем index и foreign key с внешних таблиц.
Пришлось именно удалять, т.к.
* DISABLE можно делать только у функциональных индексов
* UNUSABLE можно сделать на всех индексах, но DML запросы все равно будут валиться на UNIQUE index
http://docs.oracle.com/cd/B13789_01/server.101/b10755/initparams197.htm
Ничего страшного в этом нет, восстановление индексов заняло 5 минут по 10 млн записей, что все равно лучше 4 часов вставки.
Удаляем все, включая Prmary Key. Но тут не забываем, что каскадно удалятся и все FK. Их надо будет потом восстановить, ну или PK придется пожертвовать и оставить.
7. Делаем кэшируемым Sequence.
Если в insert используется sequence, то делаем его кэшируемым.
С "CACHE 50000" мне удалось сократить время вставки 10 млн записей с 50 минут до 5. Это в 10 раз!
При кэширумом sequence последовательность заранее подготавливает числа и хранит в памяти, а это значит, что накладных расходов обмена становится меньше.

8. IOT таблица
Если на таблице один индекс, который покрывает большую часть столбцов, то ее можно конвертировать в IOT таблицу. Так мы уменьшаем число обслуживаемых объектов до 1. Что уменьшает число буферных чтений с 3 (2 чтения индекса + 1 чтения таблицы) при любых DML/select до 2 (2 чтения индекса).

Уменьшение времени распределенной/многопользовательской (oltp) вставки данных:
отличительной особенности вставок в oltp является то, что их очень много, каждая из них создает микроскопическую нагрузку, но все вместе могут создать большое кол-во событий ожиданий (busy wait). Рассмотрим отдельно как обойти эти ожидания:

1. увеличение числа списка свободных блоков (free_list при создании таблицы)
+ уменьшение конкуренции за поиск свободных блоков за счет распараллеливания вставки
- раздувание таблицы, т.к. когда заканчивается free_list1, то он не будет использовать свободные блоки из free_list2, а выделит новые поверх HWM
- увеличивает фактор кластеризации индексов, т.к. данные физически раскидываются по разным местам таблицы, а не идут последовательно

2. сделать индекс реверсивным, если нет возможности отключить при вставке
+ уменьшение конкуренции за вставку данных в индекс, т.к. последовательные реверсивные данные будут использовать разные блоки индекса
- увеличение фактора кластеризации из-за разброса данных
- нельзя будет использовать range scan (сканирование по диапазону) индекса, т.к. в индексе уже не сами данные, а их инвертированные значения
Стоит заметить о факторе класетризации: чаще всего в oltp системе он не очень важен, т.к. доступ к данным идет по конкретному значению к одному конкретному блоку. Т.е. здесь нет скачков по разным блокам, как при сканировании по диапазону.

3. использование хинта append_values
+ запись данных не будет использовать free_list, а будет просто писаться поверх HWM
- разрастание таблицы

4. секционирование таблицы, таким образом, чтобы параллельные вставки шли в физически разные секции таблицы.
Т.е. секционирование по первичному ключу или по дате не подходит, нужно по какомуто столбцу, которые присутствует во всех вставках ежедневно и имеет одинаковый разброс.

5. Выполнение вставки используя prepared statement
что позволит исключить парсинг SQL перед его выполнением.

6. Вставка строк блоками (executeBatch)
Что позволит снизить задержки на network lookup - время на установку соединения и передачу данных по сети.

7. 7п. из пакетной вставки - кэшируемый индекс

8. остальные способы из пакетной вставки, если они применимы в текущей ситуации

Помогите разобраться какие операции пишутся в оперативный, а затем в архивные реду логи, а какие нет.

В общем по этой ссылке

NOLOGGING can be used to minimize the amount of redo generated by Oracle. Only the following operations can make use of nologging:

* SQL*Loader in direct mode
* INSERT /*+APPEND*/ .
* CTAS
* ALTER TABLE statements (move/add/split/merge partitions)
* CREATE INDEX
* ALTER INDEX statements (move/add/split/merge partitions)

Т.е. NOLOGGING может быть использован для уменьшения количества реду, генерируемых ораклом. Только следующие операции МОГУТ БЫТЬ ИСПОЛЬЗОВАННЫ в NOLOGGING.

Т.е. получается что при использовании этих операций, например INSERT /*+APPEND*/ . данные об операции все-же попадают в логи?

Т.е. получается что при использовании этих операций, например INSERT /*+APPEND*/ . данные об операции все-же попадают в логи?

ну да.. это список операций, для которых кляуза nologging будеть действовать. но ее же не обязательно использовать

а вы посмотрите )) logminer вам поможет )

Вот я и хочу разобраться какие именно операции генерируют реду при ноулоггин, а какие нет.

Ну к примеру INSERT не генерирует реду, а INSERT /*+APPEND*/ генерирует. Ты не понял. Наоборот. INSERT /*+APPEND*/ не генерирует.

АААА вот оно в чем дело, теперь вроде немного понятней.

Т.е. перечисленные операции НЕ логгируются:
* SQL*Loader in direct mode
* INSERT /*+APPEND*/ .
* CTAS
* ALTER TABLE statements (move/add/split/merge partitions)
* CREATE INDEX
* ALTER INDEX statements (move/add/split/merge partitions)

Что произойдет, если не указать LOGGING/NOLOGGING при создании объектов БД?

Точнее, как будут вести себя объекты БД с опцией LOGGING/NOLOGGING и без этой опции?

50.3k 152 152 золотых знака 54 54 серебряных знака 211 211 бронзовых знаков

LOGGING/NOLOGGING помогает управлять опцией Direct path writes (прямой путь записи в файлы данных), чтобы уменьшить генерацию REDO и UNDO. Это один из нескольких способов контролировать деликатный баланс между восстанавливаемостью данных и производительностью.

Немного общей информации по архитектуре

REDO это то, как Oracle обеспечивает прочность (durability), "D" в ACID. Когда транзакция завершается, изменения не обязательно сразу же сохраняются в файлах данных. Это ускоряет процесс и позволяет фоновым процессам справляться с некоторыми задачами. REDO - это описание изменений. Оно сохраняется быстро, на нескольких дисках, как журнал изменений. Если сервер теряет питание через доли секунды после фиксирования изменений, БД может через записи REDO убедиться, что изменения не потеряны, и востановить изменения ещё не записанные в файлы данных.

UNDO помогает обеспечить согласованность (consistency), "C" в ACID. В нем хранится описание того, как отменить изменение. Эта информация используется для отката изменений и другими процессами, которые читают таблицу и должны знать, какое значение соответствовало более раннему периоду времени.

Direct path writes не использует REDO, UNDO, кэш и некоторые другие функции, идёт непосредственная запись в файлы данных. Это быстрая, но потенциально опасная опция во многих средах, вот почему существует так много запутанных опций для управления ею. Direct path writes применяется только к INSERT , и только в сценариях, описанных ниже.

Если ничего не указывать, опция по умолчанию самая безопасная, LOGGING .

Множество способов управления Direct Path Writes

LOGGING/NOLOGGING - один из нескольких вариантов управления Direct path writes.

Посмотрите на эту таблицу из AskTom, чтобы понять, как различные опции работают вместе:

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

Правила в большей степени ограничены для индексов. Индекс всегда будет генерировать REDO во время DML выражений. Только DDL операторы, такие как CREATE INDEX . NOLOGGING или ALTER INDEX . REBUILD по индексу NOLOGGING не будет генерировать REDO.

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

Разработчики решают на уровне запроса - "Вид на вставку". Много странных вещей может произойти с подсказкой /*+ APPEND */ , и разработчики должны тщательно выбирать, когда его использовать.

Архитекторы принимают решение на уровне объекта - "Вид на таблицу". Некоторые таблицы, независимо от того, как разработчик решит их вставить, всегда должны быть восстановлены.

*Администраторы БД" выбирают с видом на БД или табличные пространства, NOARCHIVELOG и FORCE LOGING . Может быть, организация просто не заботится о восстановлении конкретной БД, поэтому установят БД в режим NOARCHIVELOG . А может у организации есть строгое правило, что все должно быть восстанавливаемо, поэтому установят табличное пространство в режим FORCE LOGGING .

вы к ней не относились. Это факт, именно так работает сервер. Однако есть ряд операций, которые иногда можно выполнять, не генерируя данных в журнал повторного выполнения.

Некоторые SQL-операторы поддерживают конструкцию NOLOGGING. Это не означает, что все операции с объектом будут выполняться без генерирования данных в журнал повторного выполнения. Просто некоторые специфические операции будут генерировать намного меньше данных повторного выполнения, чем обычно. Обратите внимание: будут генерировать намного меньше , а не вообще не будут генерировать . Все операции генерируют определенный объем данных повторного выполнения, поскольку все операции со словарем данных журнализируются, независимо от режима. Объем генерируемых данных повторного выполнения может быть намного меньше. Например, я выполнил следующие действия в базе данных, работающей в режиме ARCHIVELOG. Если выполнить их в режиме NOARCHIVELOG, вы не увидите разницы. Оператор CREATE TABLE в базе данных, работающей в режиме NOARCHIVELOG, не будет жур-нализироваться, за исключением изменений в словаре данных. Пользователи сервера Oracle версии 7.3, однако, увидят различия, поскольку такая оптимизация в этой версии сервера еще не выполнялась. Им также придется использовать ключевое слово UNRECOVERABLE вместо NOLOGGING. В прежних версиях Oracle NOLOGGING (без журнализации) означало UNRECOVERABLE (невосстановимо). Если хочется увидеть отличие при работе базы данных в режиме NOARCHIVELOG, замените операторы DROP TABLE и CREATE TABLE операторами DROP INDEX и CREATE INDEX для какой-либо таблицы. Эти операторы всегда журнализируются, независимо от режима работы сервера. Отсюда и ценный совет: тестируйте систему в том режиме, в котором она будет реально работать, поскольку ее поведение может зависеть от режима. Производственная система должна работать в режиме ARCHIVELOG. Если выполняется много операций, которые в этом режиме генерируют данные повторного выполнения, а в режиме NOARCHIVELOG - нет, то это лучше выяснить в ходе тестирования, а не при вводе в промышленную эксплуатацию! Теперь приведу пример использования конструкции NOLOGGING:

tkyte@TKYTE816> column value new value old value tkyte@TKYTE816> select value from redo size; VALUE

tkyte@TKYTE816> create table t

3 select * from all objects

tkyte@TKYTE816> select value-&old value REDO GENERATED from redo size; old 1: select value-Sold value REDO GENERATED from redo size new 1: select value- 5195512 REDO GENERATED from redo size

REDO GENERATED 2515860

В моей базе данных сгенерировано более 2,5 Мбайт данных повторного выполнения. tkyte@TKYTE816> drop table t;

tkyte@TKYTE816> select value from redo size; VALUE 7741248

tkyte@TKYTE816> create table t

4 select * from all objects

tkyte@TKYTE816> select value-Sold value REDO GENERATED from redo size; old 1: select value-&old value REDO GENERATED from redo size new 1: select value- 7741248 REDO GENERATED from redo size

А в этот раз сгенерировано только около 50 Кбайт данных повторного выполнения.

Как видите, различие существенное: 2,5 Мбайт данных повторного выполнения или 50 Кбайт. 2,5 Мбайт - это данные таблицы; они были записаны непосредственно на диск без генерирования данных повторного выполнения. Теперь, конечно, стало понятно, что все операции, для которых это возможно, надо выполнять с опцией NOLOGGING, не так ли? На самом деле, нет. Ее необходимо использовать очень осторожно и только после предварительного согласования с ответственным за резервное копирование и восстановление. Пусть частью приложения является таблица, созданная именно так (например, оператор CREATE TABLE AS SELECT NOLOGGING является частью сценария установки новой версии). Пользователи будут изменять эту таблицу в течение дня. А ночью произойдет сбой диска, на котором находится таблица. Никаких проблем , - скажет администратор базы данных, - мы же работаем в режиме ARCHIVELOG, так что можем восстановить данные . Проблема, однако, в том, что таблица, созданная как нежурнализируемая, не может быть восстановлена из архивного журнала повторного выполнения. Эта таблица не восстановима, и именно в этом основная особенность операций в режиме NOLOGGING - их использование необходимо согласовать с администратором базы данных, отвечающим за систему в целом. Если вы используете их, а другие пользователи об этом не знают, это сделает невозможным

восстановление базы данных в случае сбоя носителя. Такие операции надо использовать разумно и осторожно.

Про операции, выполняемые с опцией NOLOGGING, важно знать следующее.

Определенный объем данных повторного выполнения на самом деле будет генерироваться. Эти данные обеспечивают защиту словаря данных. Избежать их генерации нельзя. Объем генерируемых данных будет значительно меньше, но генерироваться они все равно будут.

Установка опции NOLOGGING не предотвращает генерирования данных повторного выполнения последующими операторами. В представленном выше примере не была создана таблица, действия с которой не регистрируются в журнале. Все последующие обычные действия, выполняемые операторами INSERT, UPDATE и DELETE, будут записываться в журнал. Другие специальные действия, например непосредственная загрузка с помощью утилиты SQLLDR или непосредственные вставки с помощью операторов INSERT /*+ APPEND */, регистрироваться в журнале не будут. В общем случае, однако, действия, выполняемые приложениями с этой таблицей, регистрируются в журнале повторного выполнения.

После выполнения действий с опцией NOLOGGING в базе данных, работающей в режиме ARCHIVELOG, необходимо как можно быстрее создать базовую резервную копию затронутых файлов данных. Это необходимо для предотвращения потери последующих изменений соответствующих объектов при сбое носителя. Мы не потеряем сами изменения, поскольку они записываются в журнал повторного выполнения. Будут потеряны данные, к которым эти изменения относятся.

Есть два способа использования опции NOLOGGING. Один способ уже продемонстрирован: добавить ключевое слово NOLOGGING в соответствующем месте SQL-опе-ратора. Другой способ позволяет неявно выполнять действия в режиме NOLOGGING. Например, можно изменить индекс так, чтобы он по умолчанию работал в режиме NOLOGGING. Это означает, что при последующем выполнении непосредственных загрузок или непосредственных вставок, затрагивающих этот индекс, изменения не будут регистрироваться (при изменении индекса не будут генерироваться данные повторного выполнения; для других индексов и самой таблицы - возможно, но для этого индекса - нет).

В режиме NOLOGGING возможны следующие действия:

создание и изменение (перестройка) индексов;

множественные непосредственные вставки с помощью подсказки /* + APPEND */;

действия с большими объектами (изменения больших объектов регистрировать в журнале необязательно);

Читайте также: