Стратегия Восстановления Определяет Стратегию Бэкапа Данных
Здравствуйте, уважаемые читатели блога okITgo.ru! Для выбора стратегии бэкапов необходимо начать с требований восстановления данных и с разработки стратегии восстановления. Каждый тип восстановления данных потребует наличия определенных типов бэкапа.
Сбои, произошедшие в результате ошибок пользователей, повреждения блоков данных и выхода из строя носителей, могут привести к разным последствиям, в том числе к полной потере центра данных. Как быстро Вы сможете восстановить нормальную работу базы данных зависит от того, какие методы реставрации и восстановления Вы включили в запланированную Вами стратегию. Каждый метод реставрации и восстановления подразумевает требования к стратегии взятия бэкапов, включая возможности БД Oracle, которые Вы используете для взятия. хранения и управления вашими бэкапами.
Думая о стратегиях восстановления, задайте себе несколько вопросов:
- Если диск выйдет из строя, что приведет к разрушению некоторых файлов базы данных, таких как файлы данных или журналы изменений (redo), как бы Вы восстановили потерянные файлы? Как я говорил в статье о
“Планировании Реакции на Сбой Носителя: Реставрация и Восстановление Носителя”, Вы должны быть способны справиться с потерей файлов данных, контрольных файлов и онлайн журналов изменений. - Если логическая ошибка или ошибка пользователя привели к потере важных данных из одной или нескольких таблиц или табличных простанств, как бы Вы могли восстановить данные, и что бы произошло с обновлениями базы, сделанными после возникновения ошибки? Могли бы Вы определить причину ошибки, чтобы предотвратить ее появление в будущем? Как говорилось в статье о “Планировании Ответных Действий на Ошибки Пользователей: Восстановление на Момент Времени и Ретроспективные Возможности”, методы, доступные Вам, включают восстановление на момент времени целой базы данных или одного или нескольких табличных простарнств, импорт данных из предварительно сделанных логических бэкапов путем экспорта с помощью одной из утилит импорта данных, а также изпользование ретроспективных возможностей БД Oracle.
- Если журнал предупреждений экземпляра указывает на то, что одна или несколько таблиц содержат поврежденные блоки, как Вы можете исправить повреждения? Должно ли табличное пространство оставаться доступным во время исправления? Как я описывал в посте о “Планировании Реакции на Повреждение Блока Файла Данных: Восстановление Носителя Блока”, команда RMAN BLOCKRECOVER может помочь Вам в этой ситуации. Также можно отыскать повреждения с помощью команды SQL*Plus RECOVER … TEST.
- Если центр данных полностью разрушен, можете ли Вы выполнить восстановление после этой катастрофической аварии? Предположим, все что Вы имеете – это архивная лента, содержащая бэкапы. Как бы Вы стали восстанавливать базу данных? Сколько времени бы заняло это восстановление?
- Если бы Вы не были способны восстановить вашу базу данных в виду, например, пребывания в отпуске, смог бы кто-либо другой выполнить восстановление в ваше отсутствие? Достаточно ли хорошо автоматизированы и документированы ваши процедуры восстановления?
Держа эти требования в голове, решайте, как бы Вы могли извлечь пользу из возможностей, связанных с бэкапом и восстановлением, и посмотрите, как каждая из этих возможностей соответствует одному из требований вашей стратегии бэкапов. Например:
- Использование Менеджера Восстановления упрощает большинство операций бэкапа и восстановления по сравнению с пользовательским (ручным, или под управлением пользователя) бэкапом и восстановлением. Он автоматизирует управление большей частью файлов бэкапа, включая удаление бэкапов и архивных журналов изменений с диска или с ленты, которые более не нужны для достижения целей восстановления. Он обеспечивает детальные отчеты о действиях. связанных с
взятием бэкапов, может проверить, могут ли ваши бэкапы использоваться для восстановления базы данных. И Наконец, RMAN делает возможным многие методы восстановления, которые не доступны, если Вы используете пользовательский бэкап и восстановление, такие, например, как инкрементальные бэкапы. - Ретроспективная База Данных поможет Вам реставрировать базу к предыдущему моменту времени гораздо быстрее, чем восстановление носителя. Однако, Вы должны решить заранее, включить ли ведение записей ретроспективных журналов, кроме того,
ведение этих записей требует соответствующей настройки мгновенной области восстановления (FRA). - Восстановление носителя блока может быть более приемлемо, чем восстановление носителя файла данных, если доступность критична. Хотя восстановление носителя блока данных возможно, даже если Вы не основываете вашу стратегию бэкапа и восстановления на RMAN, восстановление носителя блока посредством RMAN может быть выполнено гораздо быстрее и с меньшими усилиями.
Как только Вы определились, какие возможности использовать в вашей стратегии восстановления, Вы можете начать планировать стратегию взятия бэкапов, ответив на следующие вопросы (среди прочих):
- Как и где Вы будете хранить файлы, связанные с восстановлением? Будете ли Вы использовать мгновенную область восстановления (FRA)? Будете ли Вы использовать дисковую группу ASM для обеспечения избыточности? Будете ли Вы хранить бэкапы на ленте или на других оффлайн средствах хранения, либо только на диске?
- Через какие интервалы времени Вы будете делать запланированные бэкапы? И какие формы физических бэкапов Вы будете брать в каждом случае?
- Какие ситуации потребуют создание бэкапа базы данных вне регулярного плана? Иногда Вам потребуется брать незапланированный бэкап для гарантии того, что Вы сможете восстановить ваши данные, например после применения предложения OPEN RESETLOGS или после других изменений в вашей базе, таких как операции NOLOGGING, которые не появляются в журнале изменений. Также могут существовать определенные требования предприятия, предусматривающие бэкапы для целей аудита или по другим причинам, не связанным с восстановлением базы данных.
- Как Вы можете проверить ваши бэкапы для уверенности в том, что при необходимости сможете восстановить вашу БД?
- Как Вы управляете записями ваших бэкапов? Используете ли Вы RMAN с каталогом восстановления?
- Есть ли у Вас детальные планы восстановления, описывающие каждый тип сбоя? Могут ли ваши администраторы (DBAs) реализовать эти планы в случае кризиса? Можно ли написать скрипты для автоматизации выполнения этих планов при аварии?
- Можете ли Вы применить технологии доступности БД Oracle, такие как Защита Данных (англ. Data Guard) или Реальные Кластеры Приложений (англ. Real Application Clusters), чтобы улучшить доступность во время сбоя базы? Как использование этих технологий доступности повлияет на
вашу стратегию бэкапа и восстановления?
Конечно это только несколько вопросов, которые Вам следует принять во внимание. Доступные ресурсы (оборудование, носители, персонал, бюджет и т.д.) также будут факторами, играющими роль в принятии решения. В следующей статье рубрики Oracle мы рассмотрим планирование стратегии бэкапа данных. Спасибо за внимание! До новых встреч на страницах сайта okITgo.ru.
Здравствуйте! у меня возникли проблемы..сделали импорт базы данных, подключили но сайт все равно не работает выдает такую ошибку (MySQL Query Error: SELECT o.SITE_ID, o.MODULE_ID, o.NAME, o.VALUE FROM b_option o[Table 'v_9785_kssa.b_option' doesn't exist]) что это означает?
может быть такое что база не целая когда делали резервное копирование…что можно сделать??? помогите
Добрый день. Ошибка означает что таблица b_option в схеме v_9785_kssa не существует. Импорт делали утилитой импорта imp или импорт через data pump? Надо логи импорта посмотреть – фигурирует ли там эта таблица, если нет – значит ее в дампе нет и она не была зарезервирована при бэкапе.