nologging oracle что это

Nologging oracle что это

The logging_clause lets you specify whether certain DML operations will be logged in the redo log file ( LOGGING ) or not ( NOLOGGING ).

You can specify the logging_clause in the following statements:

CREATE TABLE and ALTER TABLE : for logging of the table, a table partition, a LOB segment, or the overflow segment of an index-organized table (see CREATE TABLE and ALTER TABLE).

Logging specified for a LOB column can differ from logging set at the table level. If you specify LOGGING at the table level and NOLOGGING for a LOB column, then DML changes to the base table row are logged, but DML changes to the LOB data are not logged.

CREATE INDEX and ALTER INDEX : for logging of the index or an index partition (see CREATE INDEX and ALTER INDEX).

CREATE MATERIALIZED VIEW and ALTER MATERIALIZED VIEW : for logging of the materialized view, one of its partitions, or a LOB segment (see CREATE MATERIALIZED VIEW and ALTER MATERIALIZED VIEW).

CREATE MATERIALIZED VIEW LOG and ALTER MATERIALIZED VIEW LOG : for logging of the materialized view log or one of its partitions (see CREATE MATERIALIZED VIEW LOG and ALTER MATERIALIZED VIEW LOG).

CREATE TABLESPACE and ALTER TABLESPACE : to set or modify the default logging characteristics for all objects created in the tablespace (see CREATE TABLESPACE and ALTER TABLESPACE).

CREATE PLUGGABLE DATABASE and ALTER PLUGGABLE DATABASE : to set or modify the default logging characteristics for all tablespaces created in the pluggable database (PDB) (see CREATE PLUGGABLE DATABASE and ALTER PLUGGABLE DATABASE).

You can also specify LOGGING or NOLOGGING for the following operations:

CACHE NOLOGGING is not allowed for BasicFiles LOBs.

The FILESYSTEM_LIKE_LOGGING clause is valid only for logging of SecureFiles LOB segments. You cannot specify this setting for BasicFiles LOBs. Specify this setting if you want to log only metadata changes. This setting is similar to the metadata journaling of file systems, which reduces mean time to recovery from failures. The LOGGING setting, for SecureFiles LOBs, is similar to the data journaling of file systems. Both the LOGGING and FILESYSTEM_LIKE_LOGGING settings provide a complete transactional file system by way of SecureFiles.

For LOB segments, with the NOLOGGING and FILESYSTEM_LIKE_LOGGING settings it is possible for data to be changed on disk during a backup operation, resulting in an inconsistent backup. To avoid this situation, ensure that changes to LOB segments are saved in the redo log file by setting LOGGING for LOB storage. Alternatively, change the database to FORCE LOGGING mode so that changes to all LOB segments are saved in the redo.

If the object for which you are specifying the logging attributes resides in a database or tablespace in force logging mode, then Oracle Database ignores any NOLOGGING setting until the database or tablespace is taken out of force logging mode.

If the database is running in ARCHIVELOG mode, then media recovery from a backup made before the LOGGING operation re-creates the object. However, media recovery from a backup made before the NOLOGGING operation does not re-create the object.

The size of a redo log generated for an operation in NOLOGGING mode is significantly smaller than the log generated in LOGGING mode.

In NOLOGGING mode, data is modified with minimal logging (to mark new extents INVALID and to record dictionary changes). When applied during media recovery, the extent invalidation records mark a range of blocks as logically corrupt, because the redo data is not fully logged. Therefore, if you cannot afford to lose the database object, then you should take a backup after the NOLOGGING operation.

Direct-path INSERT (serial or parallel) resulting either from an INSERT or a MERGE statement. NOLOGGING is not applicable to any UPDATE operations resulting from the MERGE statement.

Direct Loader (SQL*Loader)

Источник

Jakub Wartak’s blog

Oracle’s NOLOGGING

This is collected information about NOLOGGING mainly from oracle forums (I’m not the author of it, pasting it only for my private reference):

Redo generation is a vital part of the Oracle recovery mechanism. Without it crashed instances will not recover and will not start in a consistent state. Excessive LOGGING is the result of excessive work on the database.

The Oracle® Database Administrator’s Guide 10g Release 2 say regarding the main benefits of the NOLOGGING option:
• Space is saved in the redo log files
• The time it takes to create the table is decreased
• Performance improves for parallel creation of large tables

“A very important rule with respect to data is to never put yourselft into an unrecoverable situation. The importance of this guideline cannot be stressed enough, but it does not mean that you can never use time saving or performance enhancing options. “

Oracle gave the user the ability to limit redo generation on tables and indexes by setting them in NOLOGGING mode. NOLOGGING affect the recoverability and before going into how to limit the redo generation it is important to clear the misunderstanding that NOLOGGING is the way out of redo generation, this are some points regarding it:

Disabling Logging (NOLOGGING)

Logging can be disabled at the table level or the tablespace level. If it is done at the tablespace level then every newly created index or table in this tablespace will be in NOLOGGING mode you can have logging tables inside a NOLOGGING tablespace). A table or an index can be created with NOLOGGING mode or it can be altered using ALTER TABLE/INDEX NOLOGGING. It is important to note that just because an index or a table was created with NOLOGGING does not mean that redo generation has been stopped for this table or index. NOLOGGING is active in the following situations and while running one of the following commands but not after that. This is not a full list:

• DIRECT LOAD (SQL*Loader)
• DIRECT LOAD INSERT (using APPEND hint)
• CREATE TABLE … AS SELECT
• CREATE INDEX
• ALTER TABLE MOVE
• ALTER TABLE … MOVE PARTITION
• ALTER TABLE … SPLIT PARTITION
• ALTER TABLE … ADD PARTITION (if HASH partition)
• ALTER TABLE … MERGE PARTITION
• ALTER TABLE … MODIFY PARTITION
o ADD SUBPARTITON
o COALESCE SUBPARTITON
o REBUILD UNUSABLE INDEXES
• ALTER INDEX … SPLIT PARTITION
• ALTER INDEX … REBUILD
• ALTER INDEX … REBUILD PARTITION

Logging is stopped only while one of the commands above is running, so if a user runs this:

• ALTER INDEX new_index NOLOGGING.

The actual rebuild of the index does not generate redo (all data dictionary changes associated with the rebuild will do) but after that any DML on the index will generate redo this includes direct load insert on the table which the index belongs to.

Here is another example to make this point more clear:

• CREATE TABLE new_table_nolog_test NOLOGGING(….);

All the following statements will generate redo despite the fact the table is in NOLOGGING mode:

The following will not generate redo (except from dictionary changes and indexes):

• INSERT /*+APPEND+/ …
• ALTER TABLE new_table_nolog_test MOVE …
• ALTER TABLE new_table_nolog_test MOVE PARTITION …

To activate the NOLOGGING for one of the ALTER commands above add the NOLOGGING clause after the end of the ALTER command.

• ALTER TABLE new_table_nolog_test MOVE PARTITION parti_001 TABLESPACE new_ts_001 NOLOGGING;

The same applies for CREATE INDEX but for CREATE TABLE the NOLOGGING should come after the table name.

• CREATE TABLE new_table_nolog_test NOLOGGING AS SELECT * FROM big_table;

“It is a common mistake to add the NOLOGGING option at the end of the SQL (Because oracle will consider it an alias and the table will generate a lot of logging).”

Note: Even though direct path load reduces the generation of redo, it is not totally eliminated. That’s because those inserts still generate undo which in turn generates redo.

If there is an index on the table, and an +APPEND INSERT is made on the table, the indexes will produce redo. This can be circumvented by setting the index to unusable and altering the session’s (before 10g you only can set this at session level, after 10g you also can set this parameter at instance level) skip_unusable_indexes to true (This doesn’t apply to UNIQUE indexes.).

Tanel Poder note (found somewhere):
Regards to caching/nocaching I have been dealing with a huge challenge in
one project – when you’d cache your LOBs, they’d be are always logged – with
incoming data feeds hundreds of megabytes per second the logging overhead
gets too large – “luckily” we can tolerate small data loss in case of
disaster – we are planning to use NOCACHE NOLOGGING LOBs, storage snapshots,
and incremental RMAN backups.

Источник

DBAORA

oracle expert presents

NOLOGGING and recovery in Oracle

In Oracle Database NOLOGGING option used together with DIRECT mode speeds up transactions executed in a database because it limits information that Oracle writes about such transactions into redo logs and finally impacts size of generated archivelogs.

That’s because Oracle just writes basic information about executed transaction without modified data to redo logs. Such transactions are called UNRECOVERABLE because in case of database recovery archivelogs don’t have real data only informations about executed transactions.

It can impact later restores and this article shows it.

New tablespace TEST_TBLSP is created

and table TEST_TBL with LOGGING option in the tablespace

let’s backup the tablespace

Transaction executed in DIRECT mode for table with LOGGING generates a lot of redo logs

Following command in RMAN doesn’t report any unrecoverable transactions in the tablespace yet

Now it’s time to set NOLOGGING for table

so similar transaction in DIRECT mode but with NOLOGGING generates much smaller redo than previous transaction

However this time unrecoverable transaction is reported by RMAN

so if you would try to restore the tablespace restore will finish without error. DBA is happy man 🙂 and reports full success.

but selecting data from table TEST_TBL will rise error

To avoid this problem you can force to LOGGING data to archivelogs on one of the level

once force logging is turned on it’s recommended to make backups for unrecoverable datafiles

use following command to turn it off on database level

use following command to turn it off on tablespace level

NOTE – turning off FORCE LOGGING on a tablespace level has no impact when DATABASE level is still turned on.

Источник

Скахин Алексей / pihel

Личный блог. Заметки о программировании и не только

Страницы

четверг, 5 февраля 2015 г.

Oracle: быстрая вставка данных в таблицу

Уменьшение времени пакетной (для 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 перед его выполнением.

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

Источник

Nologging oracle что это

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

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 Кбайт данных повторного выполнения.

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

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

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

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

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

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

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

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

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

О создание таблиц с помощью операторов CREATE TABLE AS SELECT;

изменение таблиц с помощью ALTER TABLE, такие как MOVE и SPLIT;

Источник