Nologging индекс

Имеем nologging индекс. По сравнению с logging изменения идут на 10% быстрее. Время восстановления абсолютно не критично, при сбое есть возможность пересоздать индекс (пересоздания итак периодически производятся).

Не смог найти ответа на следующий вопрос. Есть ли 100% гарантия, что при сбое Oracle поймет, что индекс поломался и не будует его использовать? Или все же возможна плохая ситуация, когда он станет возвращать неверные данные?

Больше всего хотелось бы увидеть ссылку на документацию, где об этом...

Oracle9i SQL Reference Release 2 (9.2) Part Number A96540-02 logging_clause Specify whether the creation of the index will be logged (LOGGING) or not logged (NOLOGGING) in the redo log file. This setting also determines whether subsequent Direct Loader (SQL*Loader) and direct-path INSERT operations against the index are logged or not logged. LOGGING is the default. If index is nonpartitioned, this clause specifies the logging attribute of the index. If index is partitioned, this clause determines: The default value of all partitions specified in the CREATE statement (unless you specify the logging_clause in the PARTITION description clause) The default value for the segments associated with the index partitions The default value for local index partitions or subpartitions added implicitly during subsequent ALTER TABLE ... ADD PARTITION operations

Nologging действует только на операцию создания индекса и на direct-path insert. У Вас эти операции идут на 10% быстрее?

Ненавижу регистрацию

Имеем nologging индекс. По сравнению с logging изменения идут на 10% быстрее. Время восстановления абсолютно не критично, при сбое есть возможность пересоздать индекс (пересоздания итак периодически производятся). Не смог найти ответа на следующий вопрос. Есть ли 100% гарантия, что при сбое Oracle поймет, что индекс поломался и не будует его использовать? Или все же возможна плохая ситуация, когда он станет возвращать неверные данные? Больше всего хотелось бы увидеть ссылку на документацию, где об этом...

Скажите, а Вы не перепутали случайно "nologging" и "unusable" - индекс ?

И то, и другое используется для повышения скорости direct load ...
В противном случае, я не совсем понимаю термин "индекс поломался"

raw_

У Вас эти операции идут на 10% быстрее?

Это по словам тех, кто производит загрузку данных, и честно говоря, я измерения не проводил. Наксолько мне удалось узнать, речь идет об обычных одиночных insert'ах и delet'ах. Но предлагаю вопрос скорости не затрагивать, возможно намеряли неверно.

raw_

Nologging действует только на операцию создания индекса и на direct-path insert.

Видимо, у меня здесь имеет место быть недопонимание. Действительно, в документации прочитал то, о чем вы говорите. Получается, в обычной жизни (conventional DML) логи для индексов не пишутся?

dmidek

В противном случае, я не совсем понимаю термин "индекс поломался"

Под "поломался" я имею ввиду некорректное состояние индекса (не соответствующее данным таблицы). Меня интересует, что может произойти с индексом при падении инстанса. Например, что будет в ситуации, когда при insert'е данные в блоки таблицы записались, после этого упал инстанс, а индекс не обновился? Я вижу такие варианты после рестарта:
1) оракл обновил индекс (на основе какой информации?);
2) оракл сделал индекс unusable/disable/invalid/что-угодно, требуется перестройка индекса;
3) оракл ничего не заметил, индекс остался не обновленным.
Какой вариант имеет место быть? Зависит ли здесь что-то от logging/nologging индекса/таблицы?

raw_

Nologging действует только на операцию создания индекса и на direct-path insert

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

автор

В обычной жизни (conventional DML)

логи для индексов пишутся.

raw_

raw_ Nologging действует только на операцию создания индекса и на direct-path insert . При всех остальных операциях логи для индексов пишутся. автор В обычной жизни (conventional DML) логи для индексов пишутся.

Понял, спасибо.
Если не трудно, подскажите, где об этом можно увидеть в документации.

Ненавижу регистрацию

Понял, спасибо. Если не трудно, подскажите, где об этом можно увидеть в документации.

Oracle9i SQL Reference Release 2 (9.2) CREATE INDEX

logging_clause Specify whether the creation of the index will be logged (LOGGING) or not logged (NOLOGGING) in the redo log file. This setting also determines whether subsequent Direct Loader (SQL*Loader) and direct-path INSERT operations against the index are logged or not logged. LOGGING is the default.

Apex

Ненавижу регистрацию Понял, спасибо. Если не трудно, подскажите, где об этом можно увидеть в документации. Oracle9i SQL Reference Release 2 (9.2) CREATE INDEX logging_clause Specify whether the creation of the index will be logged (LOGGING) or not logged (NOLOGGING) in the redo log file. This setting also determines whether subsequent Direct Loader (SQL*Loader) and direct-path INSERT operations against the index are logged or not logged. LOGGING is the default.

Это уже понятно...
Я хотел увидеть про то, что "При всех остальных операциях логи для индексов пишутся".

Мне не понятно, зачем писать логи при всех остальных операциях, если, например, индекс создавался в nologging.
С другой стороны, понятно, что в логи можно писать только изменения строк данных (самой таблицы), по которым ораклу (при восстановлении) нетрудно понять, какие изменения должны произойти в индексе. А если на таблице nologging:)...кто-нибудь разъяснит?

Ненавижу регистрацию

Я хотел увидеть про то, что "При всех остальных операциях логи для индексов пишутся".

Вы увидели при каких операциях он НЕ пишутся:)

Ненавижу регистрацию

Мне не понятно, зачем писать логи при всех остальных операциях, если, например, индекс создавался в nologging. С другой стороны, понятно, что в логи можно писать только изменения строк данных (самой таблицы), по которым ораклу (при восстановлении) нетрудно понять, какие изменения должны произойти в индексе. А если на таблице nologging:)...кто-нибудь разъяснит?

Я думаю, что рассчет был на то, что прямая загрузка или пересозданиеиндекса - процедура нештатная, следовательно редкая, а вот время восстановления БД - вещь достаточно критичная. Отсюда и защита повседневных операций с индексом журналами транзакций и "не защита" их в редких случаях:)

Ненавижу регистрацию

С другой стороны, понятно, что в логи можно писать только изменения строк данных (самой таблицы), по которым ораклу (при восстановлении) нетрудно понять, какие изменения должны произойти в индексе. А если на таблице nologging:)

Кхе-кхе... То ли в вас говорит однопользовательский подход, то ли недостаток опыта траблошутинга... Оракл же в многопользовательской среде поступает тупо и надежно, по умолчанию регистрируя все изменения на уровне блоков и еще кое-что и в том порядке, в котором это все попало в журнал. (Идея проста - если это один раз точно получилось, должно получиться и в следующий раз). Ибо после сбоя ему не так уж и понятно, кто и что делал с каким блоком, с какими временными интервалами и в какой последовательности. И сколько времени займет разбор полетов и накат журналов. И будет ли открыта база в момент восстановления, чтобы почитать словарь и узнать, что там за индексы на этой таблице... И при накате отслеживать изменения словаря (а вдруг индекс добавили/удалили). Блин, и сам словарь - тоже таблицы и тоже с индексами... Так что "нетрудно понять" и "нетрудно реализовать" - две большие зад... уппсс.. разницы ;-).

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

Всего