Базы данных Oracle - статьи
Стратегия восстановления
АБД должны моделировать сценарии потери данных и тестировать свои планы восстановления. К сожалению, большинство АБД не тестируют свои стратегии резервирования и восстановления. Проведение испытаний плана восстановления помогает проверить процессы на месте, а также держит администраторов в курсе проблем и ловушек восстановления. Четыре основные причины потери данных: сбои носителя, человеческие ошибки, повреждение блоков данных и стихийные бедствия. План восстановления необходимо разрабатывать с учетом каждого случая.
- Сбой носителя.
- Человеческая ошибка.
- Повреждение блоков данных.
- Стихийные бедствия.
Обычный пример сбоя носителя – разрушение дисковых головок, которое приводит к потере всех файлов базы данных, размещенных на диске. Для полного отказа диска уязвимы все файлы, связанные с базой данных, включая файлы данных, управляющие файлы, оперативные и архивные журнальные файлы. Восстановление после сбоя носителя включает в себя копирование всех неисправных файлов из резервной копии, а затем их восстановление. В наихудшем случае может потребоваться копирование и восстановление всей базы данных. Сбой носителя – первостепенная задача стратегии резервирования и восстановления, поскольку во время восстановления обычно требуется копировать некоторые или все файлы базы данных, а затем применять для их восстановления журнальные файлы.
Пользователи могут непредумышленно удалять данные или уничтожать таблицы. Хороший способ минимизации последствий таких ситуаций – предоставлять пользователям только такие привилегии базы данных, которые им безусловно необходимы. Но человеческие ошибки будут по-прежнему возникать и АБД должны быть готовы к работе над ними. Создание логических резервных копий или экспорт таблиц – хороший способ справляться со случайными уничтожениями таблиц. Ретроспективный запрос (Flashback Query), новое средство, введенное в СУБД Oracle9i, очень хорошо подходит для восстановления после случайных удалений или вставок. Последним средством, к которому можно прибегнуть, является копирование из резервной копии и восстановление всего табличного пространства, содержащее объекты, на которые подействовала человеческая ошибка. Существуют различные методы восстановления после человеческих ошибок, и все они должны быть протестированы.
Неисправная аппаратура или ошибка операционной системы могут быть причиной повреждения блоков данных, в результате которого их формат не будет распознаваться СУБД Oracle или их содержимое будет внутренне несогласованным. В СУБД Oracle имеется средство восстановления носителя на уровне блоков (Block Media Recovery), которое копирует и восстанавливает только поврежденные блоки, и не требует восстановления всего файла данных. Это уменьшает среднее время восстановления (MTTR, Mean Time to Recovery), так как копируются и восстанавливаются только те блоки, которые требуется восстановить, а испорченные файлы данных остаются в оперативном режиме.
Землетрясения и наводнения могут привести к полному разрушению оборудования информационного центра. В таких случаях требуется копирование из резервных копий и восстановление на альтернативных установках. Это неизбежно влечет за собой необходимость поддержки резервных копий не только на основной установке, но и на альтернативной. "Внешнее" копирование и восстановление следует тщательно тестировать и планировать по времени, чтобы бизнес мог выдержать такие стихийные бедствия без компрометирования своих соглашений об уровнях сервиса.
Тщательно тестируя и документируя свой план восстановления, АБД могут существенно ограничить неожидаемые перерывы в работе и повысить доступность систем баз данных.
