ENG: | DB_BLOCK_CHECKING, DB_BLOCK_CHECKSUM |
В статье рассматриваются механизмы выявления и предупреждения возникновения испорченных данных.
Содержание
Вступление
DB_BLOCK_CHECKING — логическая проверка
DB_BLOCK_CHECKSUM — проверка на основе checksum
DB_ULTRA_SAFE — новый параметр в 11g
DB_LOST_WRITE_PROTECT — проверка для DataGuard
Еще литература
Вступление
Часто возникает ситуация когда в базе данных возникает испорченный блок (bad block). Это обычно происходит из-за порчи хранилища данных (т.е. диска). Так же блок может быть испорчен в памяти (например, баг) или испортиться в момент ввода-вывода.
Проблема здесь в том что этот блок обычно обнаруживается только в момент обращения к нему, т.е. через какое-то время после возникновения такого блока. И это время может быть достаточно продолжительным.
Для выявления и предупреждения возникновения испорченных данных в Oracle есть несколько механизмов. Эти механизмы позволяют не допустить порчу данных или вовремя предупредить об этом.
ВНИМАНИЕ: По умолчанию, эти механизмы выключены или используют минимальный уровень проверки (только для табличного пространства SYSTEM).
ВНИМАНИЕ: DB_BLOCK_CHECKING и DB_BLOCK_CHECKSUM — это два разных механизма!
Итак рассмотрим эти механизмы.
DB_BLOCK_CHECKING
DB_BLOCK_CHECKING — Это логическая проверка блока на целостность. Этот механизм проверяет блоки в памяти по информации в заголовке блоков и выявляет логические ошибки, например, длина поля неправильная и т.п. Блоки с логическими ошибками доступны для доступа и Oracle пытается восстановить целостность блока, если это не получается сделать, то сразу вызывается ошибка ORA-01578: ORACLE data block corrupted.
Накладные расходы для этого механизма 1% — 10%. Чем больше DML операций, тем больше накладные расходы (на время выполнения отдельных операций можно выключить этот механизм, если накладные расходы очень высоки).
В документации написано — Рекомендуется использовать уровень проверки — FULL, если накладные расходы на вашей системе приемлемы. На MOS есть статья — Health Check Alert: Consider setting DB_BLOCK_CHECKING to the recommended value (Doc ID 957453.1) в которой рекомендуется использовать только самый низкий уровень проверки. Хотя статья эта от 2011 года и возможно что она уже устарела. Так же рекомендуется перед включение на промышленной БД — проверить все файлы БД с помощью DBVERIFY.
Команда
ALTER SYSTEM SET DB_BLOCK_CHECKING = { FALSE | OFF | LOW | MEDIUM | TRUE | FULL } SCOPE = { MEMORY | SPFILE | BOTH };
Уровни проверки
(DEFAULT) OFF или FALSE — Проверка блоков не производиться (отключена). (Для табличного пространства SYSTEM этот механизм всегда включен, не взирая на значение параметра DB_BLOCK_CHECKING).
LOW — Минимальные проверки в случае изменения блока в памяти (например, после UPDATE или INSERT, чтения блока с диска, передача блока по interconnect в Oracle RAC).
MEDIUM — Все проверки уровня LOW + полная семантическая проверка блоков для любых объектов БД кроме индексов (в случае порчи данных в индексах, их можно пересоздать через drop+rebuild).
FULL или TRUE — Все проверки уровня LOW и MEDIUM + полная семантическая проверка блоков для любых объектов БД.
Известные баги
Полный список смотрите в — Init.ora Parameter «DB_BLOCK_CHECKING» Reference Note (Doc ID 68483.1). Здесь только интересное мне.
10.1.0.4 (fix 10.2.0.1) — Bug 4622960 — Less resource intensive block checking options needed (Doc ID 4622960.8) — Описание скрытых параметров которые позволяют проводить меньше проверок, а следовательно меньше влиять на производительность.
11.2.0.2 (fix 11.2.03+PSU) — Bug 9350204 — Spurious ORA-600 [kddummy_blkchk] .. [6145] during CR operations on tables with ROWDEPENDENCIES (Doc ID 9350204.8).
DB_BLOCK_CHECKSUM
DB_BLOCK_CHECKSUM — Это проверка блоков на основе проверки контрольной суммы (checksum). Гарантирует что прочитается то что было записано. Вычисляет checksum для грязного блока (dirty) и записывается в его заголовок блока. Блок пишется на диск. Когда в следующий раз блок считывается с диска, снова вычисляется его checksum и сравнивается с checksum записанной в заголовке блока. Если checksum которая вычисляется не совпадает с checksum которая была записана в заголовке блока — вызывается ошибка ORA-01578: ORACLE data block corrupted. На уровне FULL (начиная с 10gR2) проверка checksum делается во время каждого изменения блока во время update/delete — это позволяет выявить испорченный блок в памяти, без его записи на диск. Если используется уровень ниже FULL — механизм не определяет ситуации когда блок уже поврежден в памяти — тут поможет db_block_checking, поэтому лучше использовать сразу два механизма db_block_checking и db_block_checksum одновременно.
Команды
ALTER SESSION SET DB_BLOCK_CHECKSUM = { OFF | FALSE | TYPICAL | TRUE | FULL };
ALTER SYSTEM SET DB_BLOCK_CHECKSUM = { OFF | FALSE | TYPICAL | TRUE | FULL } SCOPE = { MEMORY | SPFILE | BOTH };
Уровни проверки
OFF или FALSE — Проверка блоков не производиться (отключена). (Для табличного пространства SYSTEM этот механизм всегда включен, не взирая на значение параметра DB_BLOCK_CHECKSUM). Checksum для redo logs блоков не считается.
(DEFAULT) TYPICAL или TRUE — Работает проверка блоков на основе проверки контрольной суммы (checksum) для любых блоков данных. Так же считается checksum для redo logs блоков.
FULL — Проверка уровня TYPICAL или TRUE + проверка блоков в памяти во время update/delete.
Накладные расходы для этого механизма для уровня TYPICAL 1% — 2%, для FULL 4% — 5%. Чем больше DML операций, тем больше накладные расходы (на время выполнения отдельных операций можно выключить этот механизм, если накладные расходы очень высоки).
В документации написано — Рекомендуется использовать уровень проверки — TYPICAL.
Известные баги
11.2.0.1 — Если версия 11.2.0.2 и выше и DB_BLOCK_CHECKSUM = FULL, обязательно прочтите, про _verify_fg_log_checksum — Bug 9717227 — Internal fix affecting DB_BLOCK_CHECKSUM = FULL behaviour (Doc ID 9717227.8).
10.2.0.3, 11.1.0.6 — Bug 6814520 — Solaris: Poor performance with DB_BLOCK_CHECKSUM = TRUE (Doc ID 6814520.8).
DB_ULTRA_SAFE
В 11g ввели новый параметр DB_ULTRA_SAFE. В статье — New Parameter DB_ULTRA_SAFE Introduced In 11g (Doc ID 465130.1) говориться об интегрированном механизме защиты. Но на мой взгляд пока это только параметр, с помощью которого можно контролировать другие параметры отвечающие за механизмы защиты от испорченных данных DB_BLOCK_CHECKING, DB_BLOCK_CHECKSUM, и DB_LOST_WRITE_PROTECT и ничего больше.
ВНИМАНИЕ: Это параметр нельзя менять динамически, т.е. требуется перезапуск базы данных. (Я считаю что это серьезный недостаток этого параметра).
На мой взгляд удобнее не использовать этот параметр, а управлять теми параметрами которые были DB_BLOCK_CHECKING, DB_BLOCK_CHECKSUM, и DB_LOST_WRITE_PROTECT.
Команда
ALTER SYSTEM SET DB_ULTRA_SAFE = {OFF | DATA_ONLY | DATA_AND_INDEX} SCOPE = {SPFILE};
Значения параметра
OFF — Если явно установлены параметры DB_BLOCK_CHECKING, DB_BLOCK_CHECKSUM, или DB_LOST_WRITE_PROTECT — никаких изменений не делается. Т.е. параметр DB_ULTRA_SAFE в этом случае никак не влияет на другие параметры.
DATA_ONLY — Устанавливает параметры:
DB_BLOCK_CHECKING = MEDIUM
DB_BLOCK_CHECKSUM = FULL
DB_LOST_WRITE_PROTECT = TYPICAL
DATA_AND_INDEX— Устанавливает параметры:
DB_BLOCK_CHECKING = FULL
DB_BLOCK_CHECKSUM = FULL
DB_LOST_WRITE_PROTECT = TYPICAL
DB_LOST_WRITE_PROTECT
При записи блока, подсистема ввода-вывода может сообщить что запись завершена, хотя на самом деле это не так. Этот механизм используется в конфигурации DataGuard для выявления таких ситуаций.
Подробно по настройке этого механизма лучше почитать — Best Practices for Corruption Detection, Prevention, and Automatic Repair — in a Data Guard Configuration (Doc ID 1302539.1).
Известные баги
11.2.0.2, 11.2.0.3 (fix 11.2.0.4, 12.1.0.1) — Bug 13928657 — ORA-600 [kcbz_zib_simulation_1] when cache is resized or following switchover (Doc ID 13928657.8) — связан с DB_ULTRA_SAFE.
Еще литература:
1. TECH: Database Block Checking Features (Doc ID 32969.1) — Хорошая и полезная статья. Краткий обзор некоторых возможностей Oracle по выявлению испорченных данных.
2. Best Practices for Avoiding and Detecting Corruption (Doc ID 428570.1). Небольшой обзор методов нахождения испорченных данных.
©Bobrovsky Dmitry
3. Performance Impact On Compressed Tables In a DB Utilizing DB_BLOCK_CHECKING and DB_BLOCK_CHECKSUM (Doc ID 1538563.1) — Влияние на производительность включение DB_BLOCK_CHECKING и DB_BLOCK_CHECKSUM для Advanced Compression таблиц.
©Bobrovsky Dmitry
4. Init.ora Parameter «DB_BLOCK_CHECKSUM» Reference Note (Doc ID 30706.1) — Есть связанные баги.
5. Enhanced Block Integrity Checking in Memory Using DB_BLOCK_CHECKSUM (Doc ID 336194.1) — Проверка блоков в памяти в FULL, начиная с 10gR2.
Dmitry Bobrovsky
6. Init.ora Parameter «DB_ULTRA_SAFE» Reference Note (Doc ID 567096.1) — Есть связанные баги.
Dmitry Bobrovsky
7. Init.ora Parameter «DB_BLOCK_CHECKING» Reference Note (Doc ID 68483.1) — Есть связанные баги.
Запись DB_BLOCK_CHECKING, DB_BLOCK_CHECKSUM впервые появилась Dmitry Bobrovsky Blog
— Author: Dmitry Bobrovsky Google