Как уже упоминалось в заметках блогов, Oracle предлагает несколько средств для обнаружения повреждений в блоках данных Oracle. В число этих средств входит команда ANALYZE, утилита DBVERIFY и параметр инициализации DB_BLOCK_CHECKING. Вдобавок Oracle поставляет замечательный пакет DBMS_REPAIR, который не только позволяет обнаруживать повреждения, но и помогает исправлять их. С помощью этого пакета очень удобно анализировать и устранять повреждения блоков в таблицах и индексах Oracle.
Восстановление носителя на уровне блоков
Даже в случае повреждения лишь нескольких блоков в файле данных он становится полностью недоступным для пользователей при выполнении обычного процесса восстановления как посредством RMAN, так и с помощью пользовательских процедур.
Утилита RMAN может облегчить восстановление после повреждения блоков данных в базе данных Oracle, позволяя выполнять восстановление носителя на уровне блоков (block media recovery — BMR). При восстановлении носителя на уровне блоков самой меньшей восстанавливаемой единицей данных считается блок данных, а не целый файл данных. В отличие от процесса восстановления файлов данных, который делает один или несколько файлов данных недоступными для пользователей на все время восстановления данных, при выполнении восстановления носителя на уровне блоков пользователям остается доступной вся база данных, пока восстанавливаются поврежденные блоки. Поэтому при обнаружении физического повреждения, охватывающего известный набор блоков данных, лучше применять для устранения проблемы процедуру восстановления носителя на уровне блоков. Тогда пользователям будут недоступны лишь те блоки данных, которые подвергаются восстановлению. Поддерживаемая в RMAN команда BLOCKRECOVER выполняет восстановление те блоков, которые числятся поврежденными в представлениях V$BACKUP_CORRUPTION и V$COPY_CORRUPTION.
Во время операции восстановления носителя на уровне блоков RMAN восстанавливает из резервных копий только блоки данных, нуждающиеся в восстановлении. Время применения журналов повторного выполнения значительно сокращается, поскольку восстанавливать требуется только определенные блоки, а не целые файлы данных.
Таким образом, применение подхода с восстановлением носителя на уровне блоков помогает добиваться следующего:
- ускорять процесс восстановления;
- увеличивать степень доступности базы данных.
Повреждение блоков данных может приводить к появлению в журнале предупреждений сообщения следующего вида:
ORA-11578: ORACLE data block corrupted (file# 9, block# 21) поврежден блок данных Oracle (файл #9, блок #21) ORA-01110: data file 9: /u01/app/oracle/oradata/remorse/users_01.dbf' файл данных 9: /u01/app/oracle/oradata/remorse/users_01.dbf'
Зная, как выглядит номер файла данных и номер поврежденного блока в нем, можно использовать следующую команду RECOVER ... BLOCK для восстановления поврежденного блока:
RMAN> RECOVER DATAFILE 9 BLOCK 21;
По умолчанию утилита RMAN сначала выполняет поиск исправных блоков в журналах ретроспективного отката для замены тех, что были повреждены. После этого она ищет файлы резервных копий (полных и инкрементных) для этих исправных блоков. Поскольку получение доступа к журналам ретроспективного отката не представляет проблем, по сравнению резервными копиями базы данных, которые иногда могут даже храниться вне организации, утилите RMAN удается быстро отыскивать необходимые блоки в области пакетного восстановления. Конечно, для того чтобы журналы ретроспективного отката можно было использовать, в базе данных должна быть включена функция Flashback Database. Утилита RMAN самостоятельно определяет резервные копии, из которых ей нужно получить необходимые блоки данных для выполнения восстановления. Затем она считывает эти резервные копии и собирает необходимые блоки данных в буферах памяти; она может даже использовать более старую резервную копию, если обнаружит, что в последней резервной копии содержатся поврежденные блоки данных. Потом RMAN запускает и проводит сеанс восстановления носителя на уровне блоков (BMR), считывая все необходимые архивные журналы повторного выполнения из резервных копий архивных журналов. Команда RECOVER...BLOCK всегда приводит к осуществлению неполного восстановления; выполнять с ее помощью восстановление до состояния на определенный момент в прошлом (PITR) нельзя.
При всяком выполнении команды наподобие ANALYZE или DBVERIFY (dbv), например, база данных добавляет в представление V$DATABASE_BLOCK_CORRUPTION строки касательно любых блоков, которые помечаются как поврежденные. Повреждение блоков бывает двух видов: физическое и логическое. Поврежденный физически блок остается для базы данных нераспознанным, в то время как поврежденный логический блок данных ей распознать удается, но просто его содержимое является для нее несогласованным с логической точки зрения. Процедура восстановления носителя на уровне блоков (BMR) позволяет восстанавливать только физически поврежденные блоки, но не те, которые были повреждены на логическом уровне.
Предыдущий пример показал, как применять RMAN для восстановления одного поврежденного блока. Восстанавливать несколько поврежденных блоков можно с помощью точно такой же команды, однако если таких блоков много и требуется восстановить их все, лучше использовать немного другой подход, а именно — разрешить RMAN автоматически восстанавливать все блоки, которые перечислены в представлении V$DATABASE_BLOCK_CORRUPTION.
Необходимые для этого шаги перечислены ниже.
1. Выполните следующий SQL-оператор, чтобы выяснить, сколько поврежденных блоков присутствует в базе данных:
SQL> SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;
2. Запустите утилиту RMAN, подключитесь к целевой базе данных и выполните такую команду:
RMAN> RECOVER CORRUPTION LIST;
Утилита RMAN автоматически восстановит в целевой базе данных все блоки, помеченные как поврежденные, а также удалит их из представления V$DATABASE_BLOCK_CORRUPTION. Следовательно, для проверки того, успешно ли прошло восстановление, достаточно будет по завершении RMAN процесса восстановления выдать запрос к этому представлению.
При наличии подозрений в обширном повреждении блоков данных и отсутствии уверенности в том, что описанный выше метод поможет успешно восстановить все данные, лучше сначала связаться с сотрудниками службы поддержки Oracle Worldwide Support, у которых есть доступ к специальным средствам, способным помочь извлечь данные из поврежденных блоков. За предоставление этих услуг Oracle может потребовать дополнительную плату, но если данные являются критически важным, оно вполне того стоит.
Пробное восстановление
При восстановлении баз данных поврежденные блоки данных могут обнаруживаться где-то в ходе процесса восстановления. В случае возникновения подобной ситуации процесс восстановления будет останавливаться, оставляя базу данных в несогласованном состоянии. Хотя существует возможность выполнения восстановления базы данных до состояния, в котором она находилась непосредственно перед возникновением повреждения, этот процесс может оказаться очень длительным.
Для определения масштабов повреждения перед началом восстановления можно применять так называемую процедуру пробного восстановления (trial recovery). В зависимости от обнаруживаемого объема повреждения, далее можно принимать решение о том, что будет лучше — использовать процедуру неполного восстановления или продолжить восстановление с обходом поврежденных блоков за счет применения такого параметра, как ALLOW n CORRUPTION. Например, если объем повреждения незначителен и проще его проигнорировать, можно воспользоваться следующей командой, которая допускает обнаружение одного поврежденного блока данных без прерывания процесса восстановления:
SQL> RECOVER DATABASE ALLOW 1 CORRUPTION;
Процедура пробного восстановления позволяет имитировать процесс восстановления — никакого реального восстановления и исправления повреждений данных во время ее выполнения не происходит. Она просто позволяет узнать о том, имеются ли повреждения, и если да, то каковы их масштабы. Далее, как и настоящая процедура восстановления данных, она продолжается применением изменений из журналов повторного выполнения. Однако во время пробного восстановления блоки данных изменяются только в памяти, а не на самом диске. По завершении проверки все произведенные изменения откатываются обратно, кроме возможных сообщений об ошибках, которые остаются в файле журнала предупреждений.
Ниже приведен пример типичной процедуры пробного восстановления:
SQL> RECOVER DATABASE UNTIL CANCEL TEST; ORA-10574: Test recovery did not corrupt any data block в ходе пробного восстановления не было обнаружено ни одного поврежденного блока данных ORA-10573: Test recovery tested redo from change 9948095 to 9948095 в ходе пробного восстановления были проверены данные повторного выполнения, начиная с изменения 9948095 и заканчивая изменением 9948095 ORA-10570: Test recovery complete процедура пробного восстановления завершена /* Следующий оператор привел бы к восстановлению табличного пространства */ SQL> RECOVER TABLESPACE users TEST;
