Лучшая практика и мифы Oracle RMAN.

Перевод незавершенной статьи Oracle RMAN Best Practices and Myths, Caleb Small (http://www.caleb.com/rman/) которая возможно будет завершенной.

Включая пример скрипта и логфайла.

Вне всякого сомнения RMAN — это лучший вариант для резервного копирования баз данных Oracle. Он прост настолько, что можно ввести BACKUP DATABASE и позволить RMAN-у сделать всё самому. Однако, RMAN это мощный и сложный инструмент, иногда даже ненадёжный, где требования к производственному резервированию сильно рознятся. Есть несколько хороших статей, касающихся наилучших практик, в дополнение к официальной документации Oracle, см. мою ссылку ниже.

Цель данной статьи- собрать все хорошие (и плохие) идеи и представить некоторые практические советы, основанные на многолетнем производственном опыте. Я также включил образцы скрипта и лога, которые демонстрирует некоторые из представленных здесь идей. В целях улучшения практического применения этого продукта на производстве, комментарии и отзывы приветствуются.

Ниже приводится растущее собрание тем, а также некоторые детальные обсуждения, количество которых будут увеличиваться с течением времени.

Список тем:

Бекап базы данных
Проверка блока/Контрольная сумма
Включайте ‘check logical’ когда резервируете базу данных
Block Change Tracking – только для инкрементальных бекапов
Имейте каждый файл данных в отдельном резервном файле (backup piece)

Бекап арклогов
Дублирование групп арклогов – имейте больше чем один archive log dest
Не удаляйте арклоги основываясь на времени – используйте archivelog deletion policy!
Не используйте ‘DELETE ALL INPUT’ когда резервируете арклоги

Резервирование управляющего файла/серверного файла параметров (SPfile)
Резервируйте управляющий файл последним – что бы включить запись об этом бекапе
Используйте контролфайл только если каталог БД недоступен
Поддерживайте свой RMAN каталог/контролфайл (controlfile_record_keep_time, delete obsolete, resync)

Подготовка к восстановлению
Подготовьтесь к потере управляющего файла – храните много копий, знайте свой DBID
Повторная каталогизация резервных копий
Тестируйте свой бекап
Тестируйте восстановление
Альтернативные технологии — Flashback Database, Flashback Table & Query, DataGuard standby DB

Резервное копирование логов
Просматривайте лог файлы, сканируйте на ошибки и успешное завершение
Устанавливайте NLS_DATE_FORMAT, NLS_LANGUAGE для читабельного вывода
Отображайте фактические команды и их вывод в файл лога
SHOW ALL – какие параметры используются для бекапа
Отображайте время на каждом этапе скрипта и всего скрипта в целом
Не перезаписывайте файл лога, используйте уникальную временную метку в имени файла
Сменяйте файлы журналов, но держите текущий доступным

Производительность резервоного копирования
Распараллеливайте каналы на узлах RAC
Сжимать или не сжимать
Регулирование бекапов
Особенности требований к удалению дубликатов

Архитектура резервного копирования
Использование FRA (область мгновенного восстановления)
Near-line vs far-line backups (or both)
Резервирование базы данных в FRA, FRA на ленту
The advent of de-duplication Появление де-дублирования
Зеркалирование данных
Особенности требований к лентам
Сторонние агенты RMAN

Рассмотрение ленточного бекапа
Прохождение проверки бекапа
Использование Media Management Layer (уровень управления носителем) (от Yuri)
— не используйте delete obsolete для лент (или смотрите метод Калеба)
— устанавливайте высокий retention policy , не оставляйте по умолчанию
— удаляйте старый бекап перед тем как делать свежий бекап
— half way backed up system files (FRA to tape) ???

Подроброе обсуждение

Control File Auto Backup. Почему же, почему?
Все эксперты, в том числе и статьи компании Oracle, согласны, что функция autobackup controlfile должна быть включена. Так почему, ну почему, после стольких версий и релизов RMAN эта опция до сих пор по умолчанию OFF?!?? Назначение controlfile autobackup — это автоматическое резервное копирование управляющего файла, который содержит RMAN-овский репозиторий, после каких-либо структурных изменений в базе данных (напр. добавление файла данных или REDO файлов, перемещение, удаление и т.д.). Храня точное описание файловой структуры базы данных он критически важен для выполнения восстановления.

Поэтому, когда вы вносите изменения в базу данных и намеренно забывая забекапить контролфайл, в RMAN будет делать это за вас.

Сейчас, я могу понять некоторые сетуации когда действительно можно отключить автобекап – по крайней мере временно. Например, изменение размера redo файлов или любые другие действия которые требуют многократных alter database команд. Автобекап можем внести очень значительную задержку выполнения команд, потребляя системные ресурсы и создавая суматоху в FRA и репозитории, даже потенциально негативно сказаться на политику хранения (retention policy) основанную на избыточности (об этом позже).

Однако, даже эта проблема решенная в 11g создаёт некоторую путаницу в процессе. Начиная с 11g, автобекап контролфайла больше не запускается немедленно, а так же не ждём завершения команды. После произведения структурных изменений RMAN запускает таймер на случай если вы всё же собираетесь сделать дополнительные структурные изменения. Если по истечении нескольких минут не было произведено изменений – происходит автобекап управляющего файла. Это значительное изменение в поведении 11g застало больше чем одного матёрого DBA (включая меня) врасплох!

Рассмотреть расположение autobackup и разницу между controlfile autobackup и расположением snapshot controlfile — который должен быть изменен со значения по умолчанию на RAC.

Crosscheck или не crosscheck?
Вот в чем вопрос. Статья Топ 10 Лучших Практик Oracle говорит – делайте кроссчек бекапа, 10 Проблем Pythian – не делайте кроссчек. Кто прав и почему?

Обе статьи правы, капнём глубже.

В RMAN больше чем один тип объекта. Кроссчек бекапа – это ХОРОШАЯ идея, и он должен быть выполнен до удаления устаревшего. Если бекап сет или кусок (piece) пропали, то мы бы не захотели удалять то, что может быть последней оставшейся хорошей резервной копией. Кроссчек всего лишь помечает потерянные наборы и куски (set/piece) как истёкшие (expired). Эти просроченные бекап сеты и писы не будут учитываться политикой хранения при использовании delete obsolete команды. Теперь о других типах объектов RMAN. Кроссчекать арклоги – это ПЛОХАЯ идея, только если это не делается интерактивно под пристальным контролем DBA. Арклоги помеченные как expired будут молча игнорироваться во время всех последующих бекапов арклогов. Это подвергает риску восстанавливаемость базы данных без каких-либо предупреждающих сообщений. Я бы предпочёл, что бы бекап не удался, вываливая повсюду сообщения об ошибках, чем молча делал вид, что он рабочий.
После любого crosscheck, хорошая идея – это сделать соответствующий отчёт и вывести его в лог файл. Если что-то отсутствует, нам нужно знать. Когда я сканирую свой лог на ошибки, я также делаю поиск по слову «expired». В заключении, команда delete expired удалит все записи помеченные как истекшие (expired) из репозитория RMAN. Она не удалит ничего с диска, так как весь смысл expired подразумевает, что файлы не существуют для RMAN. Но наоборот, хорошая идея если DBA выполнит всё это вручную. Если истёкшие объекты не удалены из репозитория, они будут появляться в последующих отчётах команд expired.

Обнаружение плохих блоков
Лучший способ восстановления плохих блоков, что в конечном итоге случится, это в первую очередь избежать их появления. Это не может быть абсолютно возможно, но есть несколько упреждающих действий, которые будут выявлять плохие блоки на ранних стадиях. Чем раньше битый блок будет обнаружен, тем больше шансов на его восстановление. У базы данных есть два параметра инициализации которые отвечают за уровень проверки блока когда он считывается. Проверка затрагивает весь ввод-вывод блоков, не только бекап. Она не вызывает дополнительный ввод-вывод, но оказывает влияние на дополнительную нагрузку ЦПУ, сколько – неизвестно, это тема для спора экспертов. Лучшая стратегия: есть доп. нагрузка ЦПУ не мешает применению параметров проверки, используйте эти обе функции.

Это DB_BLOCK_CHECKING и DB_BLOCK_CHECKSUM. Диапазон возможных значений меняется между 10g и 11g, и в 11g был введён новый параметр DB_ULTRA_SAFE который влияет на значение по умолчанию для двух вышеуказанных параметром. Это может быть немного запутанным, так что лучше прочитать соответствующую документацию для вашей версии. Если совсем сомневаетесь, просто установите значение этих двух параметров в TRUE.

RMAN так же имеет опцию CHECK LOGICAL, которая может быть использована для дополнительной проверки того, как был записан бекап. Эта опция применяется к BACKUP DATABASE (а так же к другим командам).
Не будет вредным применить старую добрую утилиту dbverfiy к вашим файлам данных. Если есть какие-либо вопросы о возможности повреждения блока, dbverify будет сканировать и проверять блоки физически в файле данных.

Появился новый, более простой способ, вызова эквивалента dbverify.
Перейдём к «физические повреждения vs. логические повреждения»

Отслеживание изменения блока.
Мелочь, важна только если делается инкрементальный бекап. Эта функция может значительно увеличить скорость инкрементального бекапа храня журнал изменений блоков с момента последнего бекапа, таким образом избегая полного сканирования файла данных. Однако, это добавляет некоторые накладные расходы к повседневным операциям, которые не обязательны, если не использовать инкрементальный бекап.

Хранить множество бекапов (в разным местах)
Oracle Suggested Backup (изображенный в DB Console) может быть полезен для начальной базы данных в тестовой среде, а так же отличным примером того, что неприемлемо в промышленном окружении. Он делает базовый бекап в самый первый день и затем вечно делает инкрементальные бекапы после. Здесь мы сталкиваемся с двумя проблемами: первая – у нас только один актуальный бекап в одном расположении. Вторая – инкрементальный бекап просто берёт изменённые блоки из базы данных и заменяет ими оригинальные блоки данных из самого первого бекапа, но базовый бекап никогда не повторяется. В итоге, как может оказаться, плохой блок может пробраться в бекап и никогда не будет обнаружен (до дня когда вы попытаетесь восстановиться из вашего единственного бекапа).

Даже если не требуется восстанавливаться на определённый момент времени, лучше иметь множество автономных бекапов на случай если один из них будет повреждён. Они должны существовать, или продублированы, на более чем одном физическом носителе, особенно если одна из локаций бекапа это FRA в серверной. Что произойдёт, если на этаже выше сработают разбрызгиватели и почему люди настаивают на расположении серверных в подвалах (вода имеет склонность следовать законам гравитации)? Ехидный комментарий – компания просто прекратит своё существование когда из физическая серверная будет уничтожена и не будет никакого стороннего бекапа.

Существует множество вариантов поддержки сторонних бекапов включая DataGuard (мой любимый по ряду причин), репликация на уровне хранилища (например Snap Mirror), удаленные архивы, и простое старомодное стороннее ленточное (или дисковое) хранилище.

Не полагайтесь на хранимую конфигурацию в RMAN
Приятно, что RMAN может хранить набор параметров по умолчанию, которые будут применены ко всем последующих операциях, и в первые дни моей карьеры я обычно запускал скрипт настройки один раз, считая затем, что установленные параметры остаются стабильными. Это была ошибкой. В конечном счете кому-нибудь ещё может понадобится внести изменения и резервные копии производственной БД начнут делаться в неправильное место, возможны и гораздо большие ошибки.

Как минимум, выводите хранимую конфигурацию в лог резервного копирования, что бы была абсолютная определенность какие настройки были на самом деле, когда был запущен бекап (или восстановление). Ещё лучше, явно установить все требуемые параметры в начале скрипта для бекапа. А ещё лучше, использовать запуск команды {} и переписать все требуемые параметры для текущего задания.

Храните/восстанавливайте конфигурацию RMAN в начале/конце вашего скрипта
Хорошая идея – SHOW ALL; команда даётся только чтобы вывести точный синтаксис для того, что бы сбросить конфигурацию всех хранимых параметров на их текущее значение. Это позволяет легко запечатлеть оригинальную конфигурацию до каких-либо изменений, и затем восстановить и в конце скрипта.

Уведомление о проблемах
Это кажется здравым смыслом, но так много бекап скриптов запускаются по расписанию, делают «что-то» и пишут логи в которые даже никто не смотрит.

Все мои производственные бекапы журналируются в файлы помеченные датой и временем, которые проверяются на наличия ошибок и затем высылаются письма – успешно или нет прошел бекап. Тема письма включает слова «SUCCESS» или «FAIL», за которыми следуют идентификационная информация о БД, позволяющая легко и быстро сканировать несколько писем на наличие слова «FAIL». Отсутствие письма указывает, что скрипт не был запущен или не выполнен. Это немного сложно, и поднимает тему о написании наблюдателя наблюдающего за наблюдателем (я видел как это делается!).
Отходя от темы: я также применяю месячную ротацию логов, что бы удалять старые логи (и не только RMAN логи, но и такие, как логи слушателя и OEM), ежедневное сканирование alertlog, и ежечасную проверку здоровья DataGuard. Добрым утро мои «входящие» выглядят примерно вот так:

Отдельные бекапписы для каждого файла данных
Несомненно, есть смысл устанавливать лимит на количество файлов данных и арклогов в одном бекапписе бекапсета. Если база данных имеет сотни или тысячи датафайлов, а нам нужно восстановить только один или два, то будет гораздо быстрее прочитать только тот бекапсет, который нам нужен. В случае де-дубликации данных (наприм. Data Domain), это может быть даже требованием для того, что бы дедубликация действительно проводилась.
Обратная сторона медали – такой подход может осложнить управление (например. list backup). Добавление уникального тега на каждый бекаппис может помочь. Моя точка отправления в целом – компромисс: 5 датафайлов или 20 арклогов на бекаппис с уникальным тегом для каждого бекапа. Это позволяет обеспечить некоторую оптимизацию восстановлению, не делая бекап слишком сложным в управлении.

Backup Optimization (Оптимизация резервного копирования)
Разве не все хотят, что бы их бекапы был оптимизирован? Не дайте себя одурачить по названию. Эта функция заставляет RMAN пропускать файлы, которые уже были зарезервированы. Если это нормально и вы желаете полагаться на одну (будем надеяться хорошую) копию файла данных или арклога, тогда дерзайте. В других случаях, оставьте эту функцию выключенной, что бы каждый бекап включал в себя все дубликаты каждый раз.

Дублирование групп арклогов
Из книги DBA 101 мы все научились дублировать онлайн redo логи, а что касательно арклогов? Они могут быть большими и многочисленными и занимать много места. Они также абсолютно критичны для восстановления ваше базы данных и целостности любого standby. Повреждённый или пропущенный арклог может привести к катастрофе. Oracle engineered systems и сторонники ASM доказывают, что записанный один раз на двойное или тройное зеркальное хранилище так же хорошо, но я на это не покупаюсь. Слишком много раз я видел как одна копия лога была испорчена и была очень благодарен за оставшиеся хорошие копии.
Когда дублируете файлы журналов, будь они архивными или онлайн, располагайте их на разных носителях! Не очень много смысла в дублировании файлов на одном носителе, когда он подведёт или окажется испорченным. БУДЬТЕ ВНИМАТЕЛЬНЫ к скоростью записи на носитель, так как она имеет непосредственное влияние на производительность базы данных, особенно в случае в онлайн redo.
/ Include diagram and go into storage layout for +DATA, +FRA, +ARCH and +REDO

Используйте политику удаления арклогов (Archivelog Deletion Policy)
Арклоги должны управляться, периодически. Словно машина для пончиков которая не останавливается («The Doughnuts»,1963г Weston Woods Studios), они будут производиться непрерывно и без автоматического удаления. Если оставить это дело без присмотра, они заполнят всё доступное место и остановят работу базы данных.
Некоторые DBA удаляют арклоги вручную или при помощи заданий по расписанию. Проблема такого подхода в том, что не способа сказать наверняка, что удаленные арклоги больше не нужны для возможного восстановления или для синхронизации standby базы данных. Невосстанавливаемый пропуск – это бесполезный бекап или повреждённый standby.
Хорошие новости в том, что RMAN предоставляет превосходный способ управления арклогами. Просто сконфигурируйте политику удаления арклогов, включая опцию DELETE INPUT когда резервируются арклоги и позвольте RMAN-у делать своё дело.DBA, держите руки прочь! Например, при следующей политике, RMAN будет удалять арклоги только после того как она будут зарезервированы и применены на standby БД:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY BACKED UP 1 TIMES TO DEVICE TYPE DISK;
Заметьте, что такая политика подходит при дублировании арклогов. Для каждой копии арклога будет сделана резервная копия до того, как он будет подходящим для удаления. Другая опция избыточности — каждая копия будет в различных backup set. Если арклоги не дублируются (например engineered system), тогда измените политику на …BACKED UP 2 TIMES… , чтобы быть уверенными, что каждый арклог включен в два различных бекапсета.

Не используйте DELETE ALL INPUT
Это касается случая когда арклоги дублированы. Между …DELETE INPUT; и …DELETE ALL INPUT; существенная разница.
Использование ключевое слово ALL означает после резервного копирования любой копии арклога – все копии будут удалены, что не обеспечит избыточность в бекапе. Если единственный бекап критического арклога будет потерян или повреждён, второго шанса не будет. Бед ключевого слова ALL, будет удалена только та копия арклога, который был только что зарезервирован, остальные копии остануться для последующих бекапов.

Добавить комментарий Отменить ответ