Crosscheck oracle что это

Обновлено: 03.07.2024

Доступа к Netbackup'у не именю и к его инженерам - тоже.

Второй вопрос:
когда ленты руками достают из летночной библиотеки и загружают новые, какие при этом прерации администратор выполняет?

А если нет подходящей (нужного пула) ленточки в магазинах (ячейки в библиотеке) -- выбрасывается EVENT на консоль (можно дублировать на почту/SMS), оператор вставляет нужную ленту в MAIL-слот магазина -- дальше библиотека все делает сама (название определяется по штрих-коду)

Но теперь что там администратор творит с Netbackup'ои мне непонятно, иногда все предыдущие бэкапы разом становятся EXPIRED, иногда часть из бэкапов EXPIRED, иногда не одного EXPIRED нет.
Но не один бэкап не может дожить до состояния OBSOLETE за 90 дней. :)

Они договорились :
RETENTION POLICY на пул НАМНОГО БОЛЬШЕ recovery windows=90 дней.

Но иногда ручками переводят определенные ленты в EXPIRED, например, когда количество лент в пуле ограничено (видимо, это не твой случай) и есть подозрение, что на предстоящий бэкап их просто не хватит (на выходные обычно запускается много полных бэкапов с разных систем)
Сам так делал

У нас просто. Netbackup админы сказали что им не нужна rman retention и они сами будут рулить как долго что хранить.

Поэтому мы поставили RETENTION POLICY TO REDUNDANCY 0 и не паримся. Тем более rman каталога все равно нет и историю за 2 года хранить в контрольниках не получается.

У нас просто. Netbackup админы сказали что им не нужна rman retention и они сами будут рулить как долго что хранить.

Ну не так все страшно. Мы рулим скриптами и сами запускаем с серваков. Они рулят за сохранность. Разграничение полномочий. Если бэкапа не будет, то с них и спросят. Все таки и не мы и не они не дети.

Пока проблем не было, востанавливали бэкапы 6 месячной давности без проблем.

Кстати, если почитаешь Netbackup Admin Guide для Oracle, там как раз эта ситуация описывается.

Без каталога главное иметь все логи бэкапов и очень удобно иметь бэкап контрольника на диск. Тогда востановление очень простое

1. Берешь бэкап контрольника созданного после бэкапа базы
2. Востанавливаешь контрольник
3. В нем будет вся информация про backup piece на ленте
4. Востанавливаешь базу

На крайний случай смотришь логи, находишь backup piece и каталогизируешь.

RMAN> CATALOG DEVICE TYPE 'SBT_TAPE' BACKUPPIECE '0pivagf8_1_1';

В Netbackup'e есть команды чтобы прочитать все названия файлов на ленте?

Это просто теоретическая задачка от скуки, тем более что она не только меня интересует, как видно из ссылки выше.

Я просто слышала такую "ужасную историю", как спецы с лентой поехали в командировку и не смогли там БД развернуть.

Владимир Пржиялковский,
координатор Евро-Азиатской Группы Пользователей Oracle,
преподаватель УКЦ Interface Ltd.

Введение

Программа RMAN появилась в версии 8 СУБД Oracle как единое для всех платформ средство организации резервного копирования и восстановления данных на физическом уровне. По отношению к традиционным базовым возможностям резервирования и восстановления в Oracle, у программы RMAN есть некоторые преимущества, делающие ее в некоторых ситуациях (например, при больших объемах данных) практически незаменимой. К сожалению, наличие этих преимуществ не лишает RMAN и ряда существенных недостатков: собственной системы понятий, собственного командного языка и интерфейса общения с администратором. И то, и другое, и третье выполнено в плохих традициях разработчиков Oracle – не вполне логично, запутано и непоследовательно, – что затрудняет освоение этой программы. Назначение этой статьи – помочь перешагнуть через эти недостатки ради выгод, которые можно извлечь из RMAN.

Возможности RMAN

Возможности RMAN включают следующее:

-	выполнение полного резервирования и резервирования изменений
-	выполнение холодного/горячего резервирования, причем во втором случае табличные пространства не переводятся в режим backup, что позволяет избежать дополнительной нагрузки на журнал
-	обнаружение поврежденных блоков
-	параллельное выполнения операций ввода/вывода
-	автоматическое протоколирование операций копирования и восстановления

Уровни выполнения резервного копирования/восстановления с помощью RMAN:

база данных
табличные пространства
файлы табличных пространств
служебные файлы БД (контрольные, архивные)

В число основных понятий RMAN входят следующие:

-	Канал (channel). Серверный процесс, возникающий при установлении связи с устройством ввода/вывода (диск или магнитная лента) для записи или чтения файлов резервирования
-	Целевая БД (target database). БД, для которой снимается резервная копия, или которая восстанавливается по ранее снятой копии
-	Каталог (recovery catalog). Отдельная схема в БД (чаще в отдельной БД), которую можно заводить для хранения служебная информации о целевых базах, снятых копиях и процедурах восстановления. Альтернативой каталогу является индивидуальная работа с каждой целевой БД, когда служебная информация помещается в контрольный файл этой БД.
-	Копия (RMAN backup). Резервная копия какого-нибудь элемента БД, получаемая командой RMAN backup.
-	Резервный набор (backup set). Логически именует набор файлов, сформированных во время резервного копирования.
-	Резервный файл (backup piece). Двоичный файл с резервной информацией.

Синтаксис командного языка RMAN в версии 9 имеет определенные отличия от версии 8, но все основные конструкции сохранены. Кроме этого, в RMAN для версии 9 допускается целый ряд упрощений записи команд.

Возможность работы с RMAN включена также в последние версии OEM без необходимости знания командного языка.

В тексте ниже для лаконичности предпочтение будет отдаваться синтаксису версии 9. Кроме этого для простоты рассматривается работа без каталога RMAN.

Пример копирования и восстановления базы данных

Простейший пример снятия резервной копии (холодное копирование – вся БД – работа без каталога) иллюстрируется следующей последовательностью команд (здесь команда CONNECT TARGET соединяет RMAN с СУБД версии 8):

RMAN NOCATALOG
RMAN> CONNECT TARGET internal/oracle
RMAN> SHUTDOWN IMMEDIATE
RMAN> STARTUP MOUNT
RMAN> RUN 2> ALLOCATE CHANNEL d1 TYPE DISK;
3> BACKUP FULL FORMAT 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%U.bus'
4> DATABASE;
4> >
RMAN>

В каталоге D:\ORACLE\ORADATA\TEACHER\RMAN-BACKUP появился файл RMAN_ TEACHER _02DGA6F0_1_1.BUS (реальное имя может варьироваться). Теперь можно удалить файлы с табличными пространствами и выполнить восстановление:

RMAN> RUN 2> ALLOCATE CHANNEL d1 TYPE DISK;
3> RESTORE DATABASE;
4> RECOVER DATABASE;
5> ALTER DATABASE OPEN;
6> >

База восстановлена и открыта.

Упрощения в версии 9

В версии RMAN для версии 9 описанное выше резервирование можно было бы выполнить так:

RMAN> BACKUP DATABASE FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%U.bus';

а восстановление так:

RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN;

Здесь подразумевается использование неявного канала по умолчанию, так что объявлять его стало необязательно.

Кроме этого в версии 9 появилась команда CONFIGURE, с помощью которой (помимо прочего) можно связать с каналом направление и маску имени файлов для резервного набора:

RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%U.bus';

В этом случае команда снятия резервной копии может выглядеть еще проще:

RMAN> BACKUP DATABASE;

Резервирование файлов базы данных

Горячее полное резервирование БД

-	может выполняться в состоянии СУБД OPEN
-	может выполняться только при включенном режиме архивирования журналов

Если выполнено и то, и другое, сами действия по резервированию выглядят как обычно. Пример в синтаксисе версии 9.0:

RMAN> BACKUP DATABASE FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%t_%U.bus';

Полное резервирование табличного пространства

Пример в синтаксисе версии 9.0:

RMAN> BACKUP TABLESPACE system, users FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%t_%U.bus';

Полное резервирование отдельных файлов табличного пространства

Пример в синтаксисе версии 9.0:

RMAN> BACKUP DATAFILE 1, 2;

RMAN> BACKUP FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%t_%U.bus'
3> 'd:\oracle\oradata\teacher\system01.dbf’,
4> 'd:\oracle\oradata\teacher\users01.dbf’;

Резервирование временного табличного пространства

Если временное табличное пространство локально управляемо, оно автоматически не резервируется. Восстанавливать (воссоздавать) при необходимости его придется самостоятельно.

Резервирование контрольного файла

Обычное резервирование контрольного файла приходится выполнять отдельно. Пример явного резервирования в синтаксисе версии 9.0:

RMAN> BACKUP CURRENT CONTROLFILE;

В версии 9 можно, однако, перевести RMAN в режим, когда копии контрольного файла будут сниматься автоматически при всякой выдаче команд BACKUP или COPY:

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

Резервирование оперативных файлов журнала

Оперативные (онлайновые) файлы журнала автоматически не резервируются. Для сохранения либо следует их

а) копировать отдельно, либо
б) перед полным резервированием БД отправлять в архив.

Резервирование архивных копий журнала

Файлы архивных копий журнала резервируются всегда в отдельные от прочих файлы резервного набора и в общем случае их нужно резервировать отдельной командой. Пример в синтаксисе версии 9.0:

RMAN> BACKUP ARCHIVELOG ALL;

Пример того, как в версии 9.0 архивные файлы можно включить в состав резервного набора БД:

RMAN> BACKUP DATABASE FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%U.bus' PLUS ARCHIVELOG;

Резервирование изменений (неполное резервирование)

Для резервирования изменений в Oracle используется традиционная многоуровневая модель с конкретным числом уровней копии 5 (от 0 до 4). Точкой отсчета для копирования изменений обязана стать снятая ранее полная копия БД уровня 0.

Пример резервирования блоков, изменившихся со времени резервирования на уровнях 3, 2, 1 и 0 (разностное, «дифференциального» резервирование) в синтаксисе версии 9:

RMAN> BACKUP INCREMENTAL LEVEL 3 DATABASE;

Пример резервирования блоков, изменившихся со времени последнего резервирования на уровнях 2, 1 и 0 (разностно-накопительное, «кумулятивное» резервирование) с пропуском табличных пространств, закрытых для записи (синтаксис версии 9):

RMAN> BACKUP INCREMENTAL LEVEL 3 CUMULATIVE DATABASE
2> SKIP READONLY;

Разностно-накопительное (кумулятивное) резервирование уровня N отличается от разностного (дифференциального) тем, что резервирует изменения произошедшие после выполнения резервирования всех уровней < N, в то время как просто разностное – изменения, произошедшие после резервирования уровней <= N.

Выдача справочной информации

Выполняется специальными командами LIST и REPORT, а также разновидностью команды RESTORE. Примеры приводятся ниже.

Выдача подробного списка всех снятых копий:

RMAN> LIST BACKUP;

Выдача списка резервных наборов, содержащих табличное пространство SYSTEM:

RMAN> LIST BACKUP OF TABLESPACE system;

Вариант выдачи того же самого, но в обобщенном виде (версия 9):

RMAN> LIST BACKUP OF TABLESPACE system SUMMARY;

Выдача информации о копиях, снятых с архивов журналов:

RMAN> LIST BACKUP OF ARCHIVELOG ALL;

Выдача резервных копий, оказавшихся устаревшими:

RMAN> REPORT OBSOLETE;

Выдача файлов с данными БД, для восстановления которых потребуются архивы журналов 2-х дневной давности и более:

RMAN> REPORT NEED BACKUP DAYS 2 DATABASE;

Те же сведения, но только для пространства SYSTEM:

RMAN> REPORT NEED BACKUP DAYS 2 TABLESPACE system;

Выдача информации о том, годны ли файлы резервного набора для восстановления:

Удаление резервных копий

Выполняется командой DELETE. В простейшем варианте удаление устаревших копий может выглядеть так:

RMAN> DELETE OBSOLETE;

Обратите внимание, что RMAN удалил ненужные файлы резервных наборов. Вам не нужно автоматизировать удаление старых файлов, как раньше!

Файлы резервных наборов могут оказаться испорченными или поврежденными. Это можно отметить в справочнике (в контрольном файле или в каталоге RMAN) с помощью команды CROSSCHECK, в результате чего они будут помечены там как EXPIRED. Последующая команда DELETE EXPIRED удалит ставшие ненужными из-за этого файлы:

RMAN> CROSSCHECK BACKUP;
…
RMAN> DELETE EXPIRED BACKUP OF DATABASE;
…
RMAN> DELETE BACKUP OF DATABASE;

Более сложный пример удаления устаревших резервных копий:

RMAN> DELETE OBSOLETE RECOVERY WINDOW OF 14 DAYS;

Восстановление данных

NOMOUNT: для восстановления контрольных файлов БД (фактически – СУБД)

MOUNT: для восстановления БД целиком или табличного пространства SYSTEM

OPEN: для восстановление табличных пространств, помимо SYSTEM (в этом случае перед процедурой восстановления само табличное пространство потребуется перевести в состояние OFFLINE).

Восстановление до момента сбоя («последнего момента»)

Некоторые примеры восстановления:

RMAN> RECOVER DATABASE;

RMAN> RECOVER TABLESPACE users;

RMAN> RECOVER DATAFILE 'd:\oracle\oradata\teacher\users01.dbf’;

RMAN> RESTORE CONTROLFILE;

RMAN> RUN 2> SET ARCHIVELOG DESTINATION TO ‘d:\oracle\oradata\archive’;
3> RESTORE ARCHIVELOG ALL; >

Восстановление пространств, закрытых на запись:

RMAN> SQL "ALTER TABLESPACE lookup_data OFFLINE";
RMAN> RECOVER TABLESPACE lookup_data;
RMAN> SQL "ALTER TABLESPACE lookup_data ONLINE";

Восстановление до указанного момента в прошлом

БД, работающую в режиме архивирования журнала, можно восстанавливать до определенного указанного момента с помощью фраз UNTIL . Пример:

Восстановление БД (вторая и третья строчки выше) можно выполнить и в SQL*Plus:

SQL > RECOVER DATABASE UNTIL CANCEL;
SQL> ALTER DATABASE OPEN RESETLOGS;

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

Автоматизация задач

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

Пусть в файле listbackup.rcm находятся строки:

CONNECT TARGET /
LIST BACKUP;
EXIT

Тогда следующие два эквивалентные по результату обращения в ОС приведут ко входу в RMAN, выполнению этого сценария и выходу:

RMAN CMDFILE=listback.rcm NOCATALOG

RMAN @listback.rcm NOCATALOG

При использовании каталога RMAN возможно к тому же использование хранимого сценария:

Архивный журнал - это неактивная резервная копия журнала повторов. Используя архивный журнал, можно сохранить все записи истории повторов. Когда база данных находится в режиме ARCHIVELOG и выполняется режим переключения журналов, фоновый процесс ARCH сохранит содержимое журнала повторов в Архивный журнал. Если в базе данных произошел сбой носителя, используйте резервное копирование файлов данных, архивный журнал и журнал повторов, чтобы полностью восстановить базу данных.

Как включить режим архива

Как видно из вышесказанного, база данных не открыта для архивирования.

Снова посмотреть архив

Архив уже открыт

Часто встречающиеся проблемы

Код ошибки: ORA-00257

В проекте часто можно столкнуться с ситуацией, что архив ORA-00257 переполнен, сначала посмотрите официальное описание:

Другими словами, будет сообщено об ошибке, когда запись в архивный журнал невозможна из-за проблем с пространством, и в настоящее время разрешены только внутренние ссылки.
В этом случае архивный журнал может быть очищен только самым быстрым способом.

Чистый архивный журнал

Посмотрите на значения этих трех предложений по отдельности

crosscheck archivelog all

Проверено, что архивный журнал БД - это файл в месте, указанном параметром log_archive_dest.Когда архивный журнал удаляется вручную, Rman Backup обнаружит потерю журнала и не сможет продолжить выполнение.
Таким образом, вам нужно вручную выполнить процесс перекрестной проверки в это время, после чего резервную копию Rman можно будет восстановить до нормального состояния.
То есть, когда вы не можете ввести rman, вы можете напрямую удалить архивный файл журнала, а затем выполнить этот оператор!

delete archivelog until time 'sysdate-1'

Это предложение - удалить архивный журнал текущего времени-1 день

-3 означает хранить архивные логи в течение 3 дней

delete expired archivelog all

Удалить просроченные или недействительные архивные журналы
Настоятельно рекомендуется: сделайте физическую резервную копию после удаления архивного журнала.

Почему возникает вышеуказанная проблема

Когда большое количество архивных журналов создается каждый день, это означает, что в базе данных имеется большое количество операторов DML, и архивный журнал записывает эти операции, поэтому мы должны подумать, можем ли мы избежать этих операций, таких как:

Является ли конструкция базы данных необоснованной и частые операции не требуются
Большое количество операций может быть данными журнала (журналы, записи операций и т. Д.), Поэтому вы думаете о размещении таблицы журнала в нереляционной базе данных?

Оператор DML: в языке SQL - набор инструкций, отвечающий за выполнение доступа к данным к объектам базы данных, с INSERT, UPDATE и DELETE в качестве ядра.
Нереляционные базы данных, такие как данные документов MongoDB, база данных "ключ-значение" Redis и т. д.

<b style = "color: red"> Узнав о побочных эффектах архивных журналов, считаете ли вы, что вам не нужно включать режим архивирования, который более безопасен? </b>

Давайте посмотрим на преимущества и недостатки режима архива (взято из Интернета)

Преимущества и недостатки архивного режима и неархивного режима

Преимущества режима архивирования

Возможно полное и неполное восстановление: все изменения, внесенные в базу данных, записываются в файл журнала. Если файл данных потерян из-за сбоя жесткого диска, вы можете использовать физические резервные копии и архивные журналы для полного восстановления базы данных без каких-либо потерь. данные.
Возможно оперативное горячее резервное копирование: так называемое оперативное горячее резервное копирование - это резервное копирование базы данных во время работы базы данных. Во время резервного копирования использование базы данных пользователем никоим образом не затрагивается.
Можно реализовать Data Guard: можно развернуть одну или несколько резервных баз данных для максимальной защиты от сбоев.
Возможна реализация потока: технология Stream может использоваться для реализации от простейшей односторонней репликации до сложной двусторонней репликации и многонаправленной репликации, а также для обеспечения более гибкой схемы резервирования данных.
Табличное пространство может быть в автономном режиме: вы можете создать резервную копию некоторых баз данных, например важных табличных пространств.
Возможность инкрементного резервного копирования: необходимо сделать полное резервное копирование только один раз, и резервное копирование только измененных данных в будущем, что может увеличить скорость резервного копирования.
Дополнительные варианты оптимизации: с обновлением версии Oracle новые стратегии оптимизации продолжают появляться в оперативном «горячем» резервном копировании.

Недостатки архивного режима

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

Недостатки неархивного режима

Может быть выполнено только автономное резервное копирование, которое является так называемым «холодным резервным копированием», которое соответствует «горячему резервному копированию» оперативного резервного копирования. База данных должна быть полностью закрыта, а затем выполнено резервное копирование. База данных недоступна во время процесса резервного копирования;
Необходимо создать резервную копию всей базы данных, а не только ее части;
Инкрементное резервное копирование невозможно, что является очень большим недостатком для баз данных уровня TB (VLDB);
Его можно восстановить только частично.Если файл данных утерян и его необходимо восстановить, администратор базы данных может восстановить только последнюю полную резервную копию, а все последующие изменения базы данных будут потеряны.

Преимущества неархивного режима

Объем работы администратора базы данных сокращается, поскольку в неархивном режиме не создаются архивные журналы, поэтому администратору базы данных не нужно учитывать управление архивами;
Производительность улучшится.

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

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

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

Список тем:

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

Резервное копирование логов
Просматривайте лог файлы, сканируйте на ошибки и успешное завершение
Устанавливайте 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

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

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

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

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

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

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

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

Это 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

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

Читайте также: