Регулярное создание резервных копий производственной базы данных Oracle является обязательным, но эти резервные копии никак не помогут, если по какой-то причине окажутся непригодными для использования. Этап тестирования резервных копий часто игнорируется в процессах резервного копирования и восстановления. К сожалению, многие администраторы осознают его необходимость, будучи уже в тяжелых обстоятельствах.
Создаваемые резервные копии файлов базы данных могут становиться бесполезными во время восстановления по нескольким причинам: из-за повреждения файлов данных и журналов повторного выполнения, из-за случайного перезаписывания файлов, из-за дефектов на ленте и даже из-за несуществующих файлов. Поэтому лучше обзавестись привычкой регулярно тестировать производственные резервные копии в соответствие с графиком. Это поможет перехватывать любые повреждения данных. Под повреждением подразумевается несоответствие данных тому виду, в котором они должны быть. Здесь интерес главным образом представляет так называемое повреждение блоков (ошибки блоков), которое может быть как логическим, так и физическим.
Обнаружение ошибок в носителях
Повреждения в носителях могут возникать по массе причин, начиная от ошибки пользователя и неполадок в программном обеспечении операционной системы и заканчивая дефектными дисками, ошибками диспетчера логических томов ( Logical Volume Manager — LVM) и неисправными микросхемами памяти. Они могут приводить, в свою очередь, к возникновению повреждений в управляющих файлах, журналах повторного выполнения, словаре данных, табличных данных и данных индексов.
Выявлять повреждения в носителях в любом месте базы данных можно путем применения специальных сценариев для регулярного осуществления мониторинга за журналами предупреждений и с помощью ряда функций Oracle, позволяющих обнаруживать проблемы заблаговременно. Например, применяя функции мультиплексирования как на уровне операционной системы, так и на уровне Oracle, можно практически полностью предотвратить вероятность повреждения управляющих файлов и журналов повторного выполнения. Благодаря просто размеру базы данных и тому факту, что файлы не мультиплексируются сами по себе, администраторам баз данных остается беспокоиться главным образом только о повреждении блоков данных. Им вполне достаточно стараться как можно раньше перехватывать сообщения о повреждениях в журналах предупреждений и устранять любые связанные с повреждениями проблемы в базе данных, выполняя поиск решений в справочных материалах Oracle Worldwide Support.
Обнаружение ошибок в блоках данных
Ошибки блоков данных происходят при появлении несогласованных данных в таблицах или индексах СУБД Oracle. Обычно невозможность устранить поврежденные блоки приводит к потере приличного количества данных. Хотя можно предпринимать несколько мер для предотвращения повреждения, своевременное обнаружение поврежденных файлов данных будет тоже помогать.
- Своевременное обнаружение позволяет отыскивать быстрые способы спасения всех или насколько возможно большей части пострадавших данных.
- Своевременное обнаружение избавляет от сюрпризов при выполнении восстановления после ошибок на уровне носителей, поскольку будет сводить к минимуму проблему, позволяя переводить файлы в автономный режим и тем самым сокращать потенциальный объем ущерба.
Существует несколько методов, которые можно применять для обнаружения повреждений в блоках данных БД Oracle. Во-первых, можно устанавливать несколько специальных параметров инициализации и тем самым обеспечивать возможность перехвата информации о поврежденных блоках. Во-вторых, можно использовать утилиты наподобие DBVERIFY и DBMS_REPAIR или команду ANALYZE и тем самым обеспечивать возможность выявления повреждений в блоках данных. Эти методы не являются взаимоисключающими; напротив, их следует рассматривать как дополнения друг к другу, поскольку каждый обладает своими собственными привлекательными возможностями. В следующих подразделах более подробно рассказывается о том, как применять каждый из этих приемов.
Настройка параметров инициализации
Установив такой параметр инициализации, как DB_BLOCK_CHECKSUM, можно заставить базу данных Oracle вычислять контрольные суммы (check-summing) для каждого блока данных и сохранять их в заголовках блоков. Тогда при чтении данных эти контрольные суммы сравниваются и выявляются поврежденные блоки данных. В Oracle рекомендуют оставить для параметра DB_BLOCK_CHECKSUM принятое для него по умолчанию значение TYPICAL (равнозначное значению TRUE, которое использовалось в предыдущих версиях). Согласно заявлениям Oracle, использование этой функции в режиме TYPICAL приводит к увеличению накладных расходов всего лишь на 1–2%. Применение ее в другом возможном режиме FULL приводит к увеличению накладных расходов уже на 4–5%.
Параметр DB_BLOCK_CHECKING является более сложным и предусматривает выполнение проверки блоков данных и индексов только тогда, когда они действительно изменяются. Он обнаруживает повреждения до присвоения блокам данных статуса поврежденных. По умолчанию для него используется значение OFF. Другие значения, которые он может принимать: LOW, MEDIUM и FULL. Его применение может приводить к увеличению объема накладных расходов на 1–10%; этот объем напрямую зависит от количества выполняемых в базе данных операций обновления и вставки. При наличии возможности справляться с дополнительными накладными расходами, в СУБД Oracle рекомендуют устанавливать для этого параметра значение FULL. Конфигурировать этот параметр можно в файле init.ora, как показано в следующем примере, где для него выбрано значение LOW:
DB_BLOCK_CHECKING=LOW
Его также можно конфигурировать и динамически с помощью оператора ALTER SESSION:
SQL> ALTER SESSION SET DB_BLOCK_CHECKING=LOW;
Еще одним параметром инициализации, который можно устанавливать, является DB_ULTRA_SAFE. Этот параметр применяется для управления значениями параметров DB_BLOCK_CHECKSUM и DB_BLOCK_CHECKING. В случае если для него оставляется принятое по умолчанию значение (OFF), база данных устанавливает для обоих связанных с выявлением повреждений параметров значение TYPICAL, что означает выполнение минимальных проверок и, следовательно, меньшее потребление ресурсов ЦП. В случае же установки для него значения DATA_ONLY или DATA_AND_INDEX, база данных будет устанавливать для двух связанных с выявлением повреждений параметров значение FULL, что будет приводить к выполнению более интенсивных проверок на предмет повреждений и, следовательно, большему потреблению ресурсов.
Применение команды ANALYZE
Команду ANALYZE удобно применять для перехвата поврежденных блоков данных. Например, выполнение показанной ниже команды ANALYZE приведет к проверке каждого блока данных в таблице customer и, в случае обнаружения любых поврежденных блоков — добавлению всех подозрительных строк в таблицу invalid_rows:
SQL> ANALYZE TABLE customer VALIDATE STRUCTURE;
Помимо выполнения проверки на предмет наличия поврежденных блоков, эта команда еще также проверит, соответствуют ли данные индекса данным таблицы.
Применение утилиты DBVERIFY
При возникновении подозрений в повреждении блоков данных еще можно использовать поставляемую Oracle утилиту DBVERIFY. Эта утилита запускается на уровне операционной системы. Она выполняет проверку на предмет повреждения структурной целостности файлов базы данных.
Для иллюстрации применения утилиты DBVERIFY ниже приведен пример выполнения верификации файла на платформе Windows (на платформах UNIX команда будет работать точно так же). Администратор базы данных может легко писать для выполнения верификации файлов данных специальный сценарий и затем настраивать для него график регулярного выполнения с помощью crontab. В листинге 1 показаны результаты применения утилиты DBVERIFY.
$ dbv file=/u01/orcl/oradata/system01.dbf DBVERIFY: Release 11.1.0.6.0 - Production on Sun Mar 30 15:53:46 2008 Copyright (c) 1982, 2007, Oracle. All rights reserved. DBVERIFY - Verification starting : FILE = =/u01/orcl/oradata/system01.dbf DBVERIFY - Verification complete Total Pages Examined : 19200 Total Pages Processed (Data) : 4404 Total Pages Failing (Data) : 0 Total Pages Processed (Index) : 1245 Total Pages Failing (Index) : 0 Total Pages Processed (Other) : 2663 Total Pages Processed (Seg) : 0 Total Pages Failing (Seg) : 0 Total Pages Empty : 10888 Total Pages Marked Corrupt : 0 Total Pages Influx : 0 Highest block SCN : 935681 (0.935681) $
Этот пример иллюстрирует упрощенный вариант применения утилиты DBVERIFY, которая вызывается командой DBV на платформах Windows и UNIX. Ключевое слово FILE указывает, какой файл данных требуется проверить на предмет повреждения. Согласно приведенному здесь выводу, общее количество страниц, помеченных как поврежденные (Total Pages Marked Corrupt), равняется нулю, а это значит, что в базе данных нет никаких проблем со структурной целостностью.
Применение пакета DBMS_REPAIR
Несмотря на то что утилита DBVERIFY очень проста в применении, использовать ее для исправления поврежденных данных нельзя, а это является очень серьезным ограничением. Поэтому еще в версии Oracle8i появился пакет DBMS_REPAIR, позволяющий не только выявлять, но и исправлять поврежденные блоки данных без перевода файлов данных в автономный режим. Прежде чем использовать этот пакет, нужно войти в систему от имени пользователя SYS и создать две специальные таблицы: одну с приставкой repair_ и вторую с именем orphan_key.
После создания таблицы repair_table пакет DBMS_REPAIR можно запускать. В эту таблицу будет заноситься информация обо всех поврежденных данных. Выполнение содержащейся в пакете DBMS_REPAIR процедуры CHECK_OBJECT будет приводить к выявлению поврежденных блоков и отображению рекомендуемых вариантов для их исправления, а выполнение после процедуры CHECK_OBJECT запроса к таким столбцам таблицы repair_table, как OBJECT_NAME и CORRUPT_DESCRIPTION — выяснить, существуют ли повреждения в блоках данных, и если да, то какого типа.
Различные способы исправления поврежденных блоков данных будут рассматриваться в следующей главе, поскольку они подразумевают проведение восстановления базы данных из резервных копий.
Инициатива HARD
Применение RAID обеспечивает избыточность только на уровне устройств хранения данных, чтобы позволить при потере нескольких дисков не терять данные. А что если используется система с зеркальным отображением дисков, но данные, записываемые на зеркальную пару дисков, повреждены? Тогда на обоих дисках в зеркальной паре, конечно же, будут содержаться поврежденные данные. Поэтому в Oracle недавно объявили о новой инициативе для предотвращения повреждения данных еще до его возникновения, которая получила название Hardware Assisted Resilient Data (Обеспечение устойчивости данных на уровне аппаратных средств), или просто HARD. В рамках этой инициативы Oracle будет встраивать в устройства хранения, продаваемые участвующими в этой инициативе производителями, специальные алгоритмы верификации данных и тем самым предотвращать окончательную запись поврежденных данных на диск. В частности, инициатива HARD направлена на решение проблем следующего рода:
- перезаписывание данных Oracle операционной системой;
- частичная запись блоков и потеря блоков при записи;
- запись физически и логически поврежденных блоков;
- запись блоков в неправильное место.
