Бэкап БД Oracle с помощью RMAN Backup Database. Настройка создания резервных копий БД Oracle с помощью утилиты RMAN

Здравствуйте, уважаемые читатели блога сайт! Представляю вашему вниманию статью о бэкапе и воссатновлении бд Oracle. Думаю, этот материал будет полезен для админов, выполняющих бэкапы и восстановление на сервере Оракл посредством Менеджера Восстановления (RMAN).

Бэкап и Восстановление

Для понимания статьи желательно иметь представление в следующих областях:

Концепции реляционных баз данных и основы администрирования.
Среда ОС, под которой запущена база Оракл.

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

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

Итак, что же такое бэкап и восстановление? Бэкап и восстановление подразумевает под собой различные стратегии и процедуры, связанные с защитой вашей бд от потери информации и восстановления бд после какой-либо разновидности потери данных.

Физические и Логические Бэкапы

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

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

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

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

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

Ошибки и Сбои, требующие Восстановление из Бэкапа

Тогда как существует несколько типов проблем, которые могут прервать нормальное функционирование бд Oracle или операции ввода-вывода, обычно только две из них требуют вмешательства админа (DBA) и восстановления носителей: собственно сбои носителей (жестких дисков и т.п.), и ошибки пользователей.

Другие сбои могут потребовать вмешательства DBA для перезагрузки базы (после сбоя экземпляра) или выделения дополнительного дискового пространства (после сбоя при выполнении sql предложения из-за, например, переполненного файла данных), но эти ситуайции не приведут, вообще говоря, к потере данных и не потребуют восстановления из бэкапа.

Ошибки пользователей

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

Выход из строя носителей информации

Сбой носителя – это сбой при чтении или записи файла на диске, который требуется для работы базы, из-за физической проблемы с диском. например выъод из строя головки. Любой файл БД может быть поврежден из-за сбоя носителя.

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

Решения Oracle для Бэкапа и Восстановления: RMAN и Пользовательские Бэкапы

Для выполнения бэкапа и восстановления, основанных на физическом резервном копировании, в вашем распоряжении есть два решения:

Менеджер Восстановления – инструмент (работает из командной строки, либо из графического интерфейса Enterprise Manager), который интегрируется с сессиями, запущенными на сервере Oracle для выполнения ряда действий, связанных с бэкапом и восстановлением, а также для поддержания хранения истории о ваших бэкапах
Традиционный пользовательский бэкап и восстановление (т.е. осуществляемый и контролируемый самим пользователем), когда Вы напрямую управляете файлами, составляющими вашу бд, используя при этом команды ОС и возможности SQL*Plus, связанные с бэкапом и восстановлением

Оба метода поддерживаются корпорацией Oracle и полностью документированы. Менеджер Восстановления, однако, является предпочтительным решением для бэкапа и восстановления БД. Он может выполнять те же типы бэкапа и восстановления, доступные при пользовательском бэкапе и восстановлении, но гораздо проще, кроме того RMAN обеспечивает общий интерфейс для задач бэкапа в различных ОС, а также предлагает ряд технологий бэкапа, не доступных в методах ручного бэкапа.

Большая часть статьи будет фокусироваться на бэкапе и восстановлении посредством RMAN. Пользовательские методы бэкапа и восстановления я планирую описать в будущих статьях о бэкапе и восстановлении.

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

Спасибо за внимание! Не пропустите продолжение темы о бэкапе и восстановлении в будущих статьях, которые я постараюсь написать в ближайшем будущем. Удачи!.

Oracle Database хранит все файлы созданной базы в файлах данных. Несмотря на то, что все данные логически содержатся в табличных пространствах, фактически они являются содержимым файлов на жестком диске компьютера. Так, каждая таблица базы данных хранится в виде строк конкретного файла данных. Часто, для восстановления данных определённой базы, достаточно восстановить её файлы данных и импортировать их в Oracle Database.

Структура базы данных Oracle Database

В процессе работы экземпляр базы данных Oracle Database использует несколько групп файлов, которые следует архивировать для последующего восстановления. Это:

Файлы данных и табличных пространств (*.DBF) .

Название файлов данных и табличных пространств, а также пути к ним можно посмотреть с помощью SQL Plus если выполнить следующий запрос:

SELECT t.name “Tablespace”, f.name “Datafile” FROM v$tablespace t, v$datafile f WHERE t.ts# = f.ts# ORDER BY t.name;

Файлы конфигурации базы данных (*.ora) .

Конфигурационные файлы базы данных Oracle имеют расширение *.ora и расположены в папке:

Управляющие файлы базы данных (*.DBF) .

Самый простой способ определить путь и названия управляющих файлов, это найти в конфигурационном файле *.ORA строку control_files , в которой будут перечислены используемые этим экземпляром управляющие файлы.

Также, чтобы определить названия и пути к управляющим файлам в SQL*Plus необходимо выполнить запрос:

SELECT value FROM v$parameter WHERE name = ‘control_files’;

Файлы журналов транзакций (*.LOG) .

Чтобы узнать имена онлайновых журналов транзакций и пути к ним, необходимо в SQL Plus выполнить следующий запрос:

SELECT member FROM v$logfile;

В результате работы этого запроса получится подобный отчет:

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

SELECT destination FROM v$archive_dest where status=’VALID’;

В результате работы этого запроса получится отчет:

Файл паролей (*.ora) .
Как правило, это файлы с расширением *.ora, имя которых начинается с символов PWD.
Например: PWDXE.ora

Итак, для сохранения, архивирования или бэкапа базы данных Oracle Database, копии именно указанных групп файлов следует создавать, а это:

*.DBF – файлы данных, табличных пространств и управляющие файлы базы данных. Расположены:
C:\oraclexe\app\oracle\oradata\XE
*.ora – файлы конфигурации базы данных и файлы паролей.
Файлы конфигурации:
C:\oraclexe\app\oracle\product\11.2.0\server\dbs
Файлы паролей (PW…ora):
C:\oraclexe\app\oracle\product\11.2.0\server\database
*.LOG – файлы журналов транзакций:
C:\oraclexe\app\oracle\fast_recovery_area\XE\ONLINELOG

где, ХЕ – это название базы данных в нашем случае.

Резервная копия базы данных Oracle Database

Резервную копию базы данных Oracle Database (backup) можно сделать двумя способами:

Архивация средствами операционной системы

Архивация средствами операционной системы подразумевает «ручное» копирование всех рабочих файлов базы данных Oracle , таких как:

Файлы табличных пространств.
Управляющие файлы.
Файлы журналов транзакций.
Файлы конфигурации.

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

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

Архивация и восстановление при помощи инструментов Export / Import

Архивацию и восстановление базы данных Oracle Database можно производить с помощью стандартных механизмов Экспорта и Импорта в Oracle. Для повышения надежности сохранности данных необходимо периодически, в зависимости от интенсивности работы с базой, производить полный экспорт. При достаточно интенсивном внесении изменений в данные, необходимо делать экспорт один раз в неделю.

Для этого:

Импорт файла, созданного раннее архива, осуществляется аналогичным образом:

Восстановление утерянной базы данных Oracle Database

В случае удаления или утери по какой-то из причин базы данных Oracle Database, её можно восстановить, восстановив файлы с помощью Hetman Partition Recovery и восстановить их способом, описанном в разделе «Архивация средствами операционной системы» .

Для этого:

Для примера, восстановления файлов базы данных описан процесс восстановления файлов *.DBF. Но учтите, что для восстановления всех данных работоспособной базы, также необходимо восстановить соответствующие *.ORA и *.LOG файлы.

Резервирование и восстановление базы данных с помощью Oracle Recovery Manager (RMAN)

Oracle Recovery Manager (RMAN) – это ещё один инструмент создания резервной копии базы данных Oracle Database. Отличается он от других инструментов тем, что с его помощью создаётся полная копия всей базы данных, а не только данных из неё. А также, что немаловажно, Oracle Recovery Manager совмещает в себе функциональность SQL Command Line одновременно освобождая пользователя от полной зависимости от её команд. Устанавливается данный инструмент на компьютер одновременно и вместе с установкой Oracle Database.

Чтобы создать резервную копию базы с помощью RMAN:

Чтобы восстановить базу данных из резервной копии базы с помощью Oracle Recovery Manager (RMAN):

К слову, в случае утери или удаления файла бэкапа базы данных Oracle Database, *.BKP файл бэкапа можно также восстановить с помощью Hetman Partition Recovery , после чего восстановить описанным выше способом в базе данных используя Oracle Recovery Manager (RMAN).

Основные характеристики:

Образ Диска, Бэкап на NAS, Бэкап Открытых Файлов (VSS), Бессрочная Лицензия
Starting from € 29

FREE BACKUP SOFTWARE FOR SERVER AND WORKSTATIONS

BACKUP FREE AND PROFESSIONAL SOLUTIONS

Iperius is a complete Windows utility for data backup. You can use the Freeware version (also for Windows Server) to back up files to NAS, external disks, RDX drives, etc. without any time limitation - or choose an enterprise version, with plenty of backup functions and advanced features: copy of open files (VSS), Drive Image for disaster recovery, backup of ESXi and Hyper-V virtual machines, SQL Server and MySQL database backup, Exchange Server backup, backup to LTO Tape, backup to Cloud (Google Drive, Amazon S3, etc.), backup to FTP/SFTP . Starting from Iperius Free, a trial of the Full version can be activated to test all the features of the software.

Iperius Console

KEEP UNDER CONTROL ALL THE BACKUPS IN A SHOT

Iperius Console is the advanced tool for centralized management and monitoring of your computers and backup. Using either the dedicated desktop application or just the web portal, you can view the results of your backup operations, examine the details of any errors, set and customize the backup schedulings and also run backup jobs remotely. The console integrates perfectly with all the products of Iperius Suite, allowing also to remotely update Iperius Backup to the latest version. The large amount of information provided keeps users updated about the status of every PC and Server where Iperius is installed, making Iperius Console an extremely useful IT Monitoring tool, both for your customers and your company.

В данном документе описаны правила и процедуры, которые необходимо соблюдать для резервного копирования Oracle на уровне предприятий с помощью ПО Bacula Enterprise Edition. Документ также включает различные сценарии восстановления бэкапа Oracle.

Обзор резервного копирования Oracle

Bacula Enterprise Edition использует уникальный плагин бэкапа Oracle, который позволяет упростить резервное копирование Oracle и его восстановление. Плагин позволяет использовать передовые методы для «горячего» и «холодного» резервного копирования Oracle и восстановления данных и конфигураций, хранимых на серверах 10 и 11 поколений. Плагин бэкапа базы Oracle позволяет восстанавливать Oracle на конкретный момент времени (до контрольной точки), фильтровать объекты во время резервного копирования Oracle и их восстановления. Он также позволяет создавать бэкапы Oracle с информацией о конфигурации, например параметров. Плагин бэкапа БД Oracle поддерживается платформами Linux 32/64 бит, поддерживаемыми Oracle, а также БД Oracle 10.x, 11.x.

Прочие преимущества резервного копирования Oracle с помощью Bacula:

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

В данном документе представлены различные способы и стратегии резервного копирования Oracle с использованием ПО Bacula Enterprise Edition и соответствующего плагина.

Глоссарий бэкапа Oracle

В документе используются следующие термины:

ARC (Архивный журнал регистраций) – стандартные метод, используемый для обеспечения целостности данных. Основная идея ARC заключается в том, что изменения, вносимые в файлы данных (в которых находятся таблицы и индексы), будут записаны только после того, как изменения будут зарегистрированы в журнале, то есть после того как записи в журнале, описывающие изменения, будут перенесены в постоянное хранилище.
PITR Восстановление Oracle до заданной контрольной точки (PITR) восстанавливает БД до конкретного момента времени, а затем использует инкрементальные бэкапы и откаты для восстановления БД до указанной точки. PITR восстановление иногда называют неполным, так как в результате PITR восстановления БД восстанавливается до конкретного момента, а сама процедура не использует все файлы журнала резервного копирования Oracle.
RMAN Диспетчер восстановления Oracle или утилита RMAN, командная строка и инструмент на базе Oracle Enterprise Manager – метод резервного копирования и восстановления БД, рекомендуемый компанией Oracle. Утилита RMAN создана для работы непосредственно с сервером. Утилита позволяет определять поврежденные блоки данных во время резервного копирования и восстановления БД. Утилита RMAN оптимизирует производительность и потребление памяти во время создания бэкапа путем уплотнения файлов и сжатия набора резервных копий.
http://docs.oracle.com/cd/B28359_01/backup.111/b28270/toc.htm
EXP /IMP Утилиты экспорта (exp) /импорта (imp) Oracle используются для выполнения логического резервного копирования/восстановления БД. При экспорте, создается дамп объектов БД в виде бинарного файла, который потом может быть импортирован в другую БД Oracle.
Data Pump Технология Oracle Data Pump – это более современная, быстрая и гибкая альтернатива утилитам “exp” и “imp”, которые использовались в предыдущих версиях Oracle. К сожалению, этот новый метод не поддерживает вывод данных непосредственно в файл FIFO. Поэтому использование инструментов Data Pump требует, чтобы вы сначала создали дамп данных на диске, а затем считали эти данные с помощью Bacula Enterprise File Daemon. Текущая версия плагина бэкапа Oracle не поддерживает технологию Data Pump.
SBT По умолчанию RMAN посылает все бэкапы Oracle в особый системный каталог на диске. Вы также можете сконфигурировать RMAN таким образом, чтобы бэкапы создавались на других носителях, например, магнитных лентах, с помощью SBT модуля. Bacula в этом случае будет выступать в качестве Диспетчера носителей (Media Manager), а данные будут передаваться напрямую от RMAN в Bacula.
libobk Интерфейс SBT реализован на базе файла библиотеки libobk.
Tablespace БД разделена на логические хранилища называемые табличными пространствами, которые группируются на основе логической структуры. Например, табличные пространства, как правило, группируют все прикладные объекты с целью упрощения администрирования.
Схема – это совокупность объектов БД. Схемой владеет пользователь БД. Схема имеет то же имя, что и ее пользователь. Объекты схемы – это логические структуры, которые напрямую связаны с данными БД. Объекты схемы включают такие структуры, как таблицы, виды, индексы. (Между табличным пространством и схемой нет связи. Объекты одной схемы, могут находиться в различных табличных пространствах, а табличные пространства могут содержать объекты их различных схем.)
Инстанс Сервер БД Oracle состоит из БД Oracle и инстанса БД Oracle. Каждый раз при запуске БД выделяется системная глобальная область (SGA) и запускаются фоновые процессы Oracle. Комбинация фоновых процессов и буферов памяти называется инстансом Oracle.
SID Системный ID Oracle (SID) используется для идентификации БД в системе. По этой причине в одной системе не может существовать больше одной БД с уникальным SID. Как правило SID задается переменной “ORACLE_SID”. Как вариант, вы можете найти этот идентификатор в первом поле (before 🙂 конфигурационного файла /etc/oratab.
Копия Каждый раз при открытии БД с помощью команды ALTER DATABASE OPEN RESETLOGS создается такая копия.
SCN Системный номер изменения (SCN) — номер в Oracle, который увеличивается последовательно с каждым изменением, вносимым в БД: вставкой, обновлением, удалением. Номер SCN также увеличивается в результате взаимодействия БД.
Восстановление Oracle – действие, приводящее к извлечению данных из бэкапа. После восстановления БД, возможно, потребуется вернуть ее к исходному состоянию, то есть откатить вперед до определенной контрольной точки.
Возвращение к исходному состоянию – это процедура обновления восстановленного файла данных с использованием архивных журналов регистрации операций «redo» и текущих журналов регистраций, то есть с применением изменений, внесенных в БД после создания бэкапа.
Функция Proxy Copy – это функция утилиты RMAN, которая не поддерживается текущей реализацией интерфейса SBT ПО Bacula Enterprise.

Условные обозначения

Значения, заключенные в скобки < > вводятся пользователями, например, необходимо заменить на текущий номер ORACLE_SID. Если ваш номер ORACLE_SID является тестовым TEST, файл, записанный как init.ora будет выглядеть как initTEST.ora.
% означает, что команда должна быть запущена обычным пользователем.
# означает, что команда должна быть запущена через учётную запись привилегированного пользователя.
RMAN> означает, что команда должна быть запущена внутри сессии rman.
SQL> означает, что команда должна быть запущена внутри сессии sqlplus.

Бэкап Oracle с плагином

Выбор метода бэкапа Oracle: Дамп или утилита RMAN

В таблице ниже показаны преимущества методов восстановления бэкапов, поддерживаемые плагином Bacula Enterprise для Oracle. Чтобы выбрать тот или иной метод, руководствуйтесь такими возможностями, как возможность восстановления бэкапа Oracle до заданной контрольной точки, возможность фильтрации объектов во время резервного копирования или восстановления. Также пользователь может комбинировать методы создания дампа и использования утилиты RMAN PITR для одного кластера.

Утилита RMAN также позволяет использовать современные методы, благодаря которым вы можете посылать данные через SBT интерфейс Bacula Enterprise, например, на магнитную ленту и на диск одновременно для более быстрого восстановления.

Функция	Дамп		RMAN	RMAN SBT
Возможность восстановления одного объекта (таблица, схема…)	Да		Нет	Нет
Возможность восстановления одного файла (индекс, БД, таблица…)	Нет		Да	Да
Скорость создания бэкапа Oracle	Низкая		Высокая	Высокая
Скорость восстановления	Низкая	Высокая		Высокая *
Размер бэкапа Oracle	Малый	Большой		Большой
Размер на локальном диске при создании бэкапа	Ничего	Весь бэкап		Ничего
Размер на локальном диске при восстановлении	Ничего	Весь бэкап		Необходимые объекты
Возможность восстановления до контрольной точки	Нет	Да		Да
Поддержка инкрементального/дифференциального бэкапа Oracle	Нет	Да		Да
Параллельное восстановление	Да	Да		Да
Онлайн бэкап Oracle	Да	Да		Да
Согласованность	Да	Да		Да
Возможность восстановления до предыдущей основной версии Oracle	Нет	Нет		Нет

Таблица 1. Способы восстановления Oracle

* При использовании интерфейса RMAN SBT скорость восстановления будет зависеть от различных элементов, таких как тип носителя (магнитная лента или диск), скорость передачи по сети, доступность устройства с демоном-хранителем, и т.д… В ПО Bacula Enterprise версии 6.4 и выше устройство с демоном-хранителем может использовать тот же том диска для множества параллельных восстановлений. Таким образом, существует возможность одновременного выполнения нескольких задач по восстановлению и резервному копированию Oracle.

Конфигурирование RMAN SBT

В данном разделе руководства пользователя описывается правильная установка и конфигурирование SBT интерфейса Bacula Enterprise с помощью Oracle и RMAN.

При создании бэкапа Oracle или запуске резервного копирования из RMAN, RMAN потребуется связаться с централизованным директором Bacula Enterprise Director для получения информации о файлах и томах, или для запуска резервного копирования или восстановления Oracle. Для установления связи потребуются общие командные файлы FIFO и b-консоль.

При использовании плагина oracle-sbt-fd, директор не сможет запустить резервное копирование Oracle из b-консоли или из расписания. Только утилита RMAN сможет инициировать сессию и запустить резервное копирование. Примите во внимание тот факт, что вы по-прежнему запускаете стандартное системное резервное копирование Oracle, а затем используйте RunScript для автоматического вызова RMAN.

Конфигурирование Bacula. При использовании интерфейса SBT необходимо установить b-консоль (консоль Bacula). Консоль должна позволять подключаться к централизованному директору и получать доступ к локальному клиенту, задаче резервного копирования Oracle и прочим характеристикам пула.

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

Рисунок 1. Бэкап Oracle при взаимодействии между RMAN и Bacula

Пользователь “oracle” ОС Unix должен иметь возможность отобразить b-консоль и считать соответствующий конфигурационной файл bconsole.conf , который не является конфигурацией по умолчанию . Вы можете скопировать бинарный и конфигурационный файл в папку /opt/bacula/oracle с помощью следующих команд Unix:

Важно: Возможно, после каждого обновления Bacula Enterprise вам потребуется копия бинарной b-консоли.

Выполнение параллельных задач при бэкапе БД Oracle

Чтобы запустить резервное копирование Oracle или восстановление с помощью нескольких каналов, вам необходимо гарантировать, что все необходимые ресурсы плагина бэкапа БД Oracle правильно сконфигурированы с помощью команды Maximum Concurrent Jobs, чтобы позволить выполнение параллельных задач.

Director: Director (ex: 100)
Director: Client (ex: 10)
Director: Job (ex: 10)
Director: Storage (ex: 10)
Storage: Storage (ex: 100)
Storage: Device (ex: 10 или 10 устройств, сгруппированных в виртуальный переключатель Virtual Changer)
Client: FileDaemon (ex: 10)

Чтобы обеспечить параллельное выполнение задач резервного копирования и восстановления с помощью одного и того же ресурса Director Storage, конфигурация должна использовать дисковод Virtual Changer. Информация об особой конфигурации изложена в технической документации Disk Backup .

Ограничения, связанные с носителями

Oracle требует, чтобы Диспетчер носителей (Media Manager) Bacula Enterprise не объединял потоки данных от двух параллельных API сессий в одном и том же последовательном устройстве. Это значит, что, если вы используете накопитель на основе магнитной ленты для бэкапа БД Oracle, вы должны использовать различные ленточные накопители для каждой параллельной задачи резервного копирования. Данное ограничение не относится к дисковым накопителям. Данное ограничение предполагает особо длительное восстановление.

Конфигурирование Bacula SBT

libobk можно сконфигурировать с помощью файла /opt/bacula/oracle/sbt.conf или /opt/ bacula/etc/sbt.conf или с помощью команды RMAN SEND . В таблице 2 приведены используемые дескрипторы:

Параметр	Описание	Пример
client	Имя клиента Bacula	client=oracle-fd
restoreclient	Имя клиента Bacula, используемое для восстановления	restoreclient=oracle-fd
job	Команда b-консоли с аргументами	bconsole=»/tmp/bconsole -n»
restorejob	Имя задачи восстановления Bacula. Если задано несколько задач восстановления в вашей конфигурации, а данный параметр не используется, плагин SBT автоматические выберет первую заданную задачу восстановления.	restorejob=RestoreFiles
waitjobcompletion	Ожидание завершения задачи в конце SBT сессии. По умолчанию сессия завершается как можно быстрее. Примите во внимание тот факт, что данный параметр нужно использовать только при запуске резервного копирования из утилиты RMAN.	waitjobcompletion
update	Тип обновления (локальный каталог). Если имя файла присутствует в локальном каталоге, плагин отвечает непосредственно RMAN не связываясь я директором Bacula Director. Используйте команду update=force, чтобы принудительно задать проверку Bacula Director.	update=force
jobopt	Дополнительный параметр задачи	jobopt=»spooldata=no»
backupdir	Папка локального каталога	backupdir=/opt/bacula/oracle
ctrlfile	Основной путь к управляющему файлу	ctrlfile=/tmp/oracle
ctrltimeout	Пауза при подключении к Bacula	ctrltimeout=300
retry	Количество попыток при подключении к Bacula
localdir	Локальная папка файла данных, который проверит SBT плагин до вызова задачи восстановления Bacula.	Localdir=/tmp/@ORACLE/sbt
catalog	Имя каталога Bacula	catalog=»MyCatalog 2»
trace	Путь к файлу файл трассировки	trace=/tmp/log.txt
debug	Уровень отладки

Таблица 2. Конфигурация SBT libobk

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

Эти настройки можно перезаписать с помощью команды RMAN SEND.

Команда SEND ограничена 512 байтами, поэтому, можно использовать несколько команд SEND, чтобы задать все параметры. Будет лучше избегать длинные пути при использовании SBT интерфейса.

Конфигурирование FileSet

Плагин бэкапа базы Oracle SBT (oracle-sbt) принимает параметры в Job FileSet, как описано в таблице 3.

Таблица 3. Параметры плагина Oracle SBT

Тестирование конфигурации sbt.conf

Чтобы протестировать конфигурацию плагина Bacula Enterprise Oracle SBT, привилегированный пользователь может использовать следующие команды:

При возникновении ошибки подключения, появится сообщение. Пока вы не сконфигурируете правильно настройки подключения, нет смысла запускать резервное копирование Oracle RMAN.

Внутренний каталог Bacula SBT

Файл libobk ПО Bacula Enterprise использует локальный каталог для хранения информации обо всех файлах. Эта информация может устаревать. Поэтому вы можете использовать параметр update=force в файле sbt.conf или команду SEND для принудительного поиска каталога Bacula.

Каталог по умолчанию хранится в /opt/bacula/oracle/bacula-sbt.cat и может быть частью обычного бэкапа системы.

Способность сохранения бэкапа Oracle RMAN

При использовании плагина RMAN SBT Bacula Enterprise, способность сохранения бэкапа Oracle, заданная утилитой RMAN, должна соответствовать тому Bacula или сохранению задания в памяти. Когда RMAN пошлет команды на удаление файлов бэкапа, Bacula не будет пытаться что-либо очищать или удалять.

Примеры бэкапов Oracle

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

В этом примере RMAN использует 3 задачи Bacula для восстановления 3 файлов.

Конфигурация режима RMAN

В данном разделе руководства пользователя описывается процедура конфигурирования утилиты RMAN для правильной работы с той частью плагина бэкапа базы Oracle, которая не использует SBT интерфейс.

Текущая версия плагина бэкапа БД Oracle поддерживает только БД, запущенные с активным режимом ARCHIVELOG.

Конфигурация ARCHIVELOG в Oracle

Чтобы использовать режим создания бэкапов Oracle с RMAN, БД необходимо запустить в режиме ARCHIVELOG. Чтобы проверить, как сконфигурирована ваша БД, вы можете использовать следующую команду SQL.

Чтобы активировать режим архивирования для БД, вы можете использовать команду ALTER DATABASE ARCHIVELOG в состоянии SYSDBA.

Остановите работу БД с помощью команды SHUTDOWN
Создайте бэкап БД
Отредактируйте файл init.ora, чтобы сконфигурировать местоположение архивного журнала регистрации
Запустите БД не открывая с помощью команды STARTUP MOUNT
Измените режим архивирования с помощью команды ALTER DATABASE ARCHIVELOG; и откройте ее с помощью команды ALTER DATABASE OPEN;
Остановите работу БД с помощью команды SHUTDOWN IMMEDIATE
Еще раз создайте бэкап БД, так как изменение ARCHIVELOG обновит управляющие файлы и превратит старые бэкапы в непригодные для использования. Плагин Bacula Enterprise для Oracle создаст RMAN бэкап, помещенный во вложенную папку в месте, где находится архивный журнал регистрации, указанном в файле init.ora.

Оптимизация инкрементального бэкапа Oracle

Функция отслеживания изменений утилиты RMAN для создания инкрементальных бэкапов Oracle повышает эффективность таких бэкапов путем записи изменённых блоков в каждом файле данных в файл отслеживания изменений. Если функция отслеживания изменений активна, утилита RMAN использует файл отслеживания изменений для определения измененных блоков для создания инкрементальных бэкапов. Таким образом, отпадает необходимость в сканировании каждого блока в файле данных.

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

Следующая команда SQL, запущенная как sysdba, позволяет активировать функцию отслеживания изменений и использовать местоположение “/path/to/file” в качестве местоположения архивного журнала регистрации. (Примите во внимание тот факт, что файл должен находиться в действующей папке, в которую пользователь Oracle может записывать данные).

Способность сохранения бэкапа RMAN

При использовании режима RMAN вместе с плагином Bacula Enterprise для Oracle, каждая задача Bacula будет запускать RMAN для создания набора резервных копий. Мы рекомендуем сконфигурировать утилиту RMAN, чтобы удалять старые файлы спустя определенное время. Несмотря на то, что данную операцию можно выполнять сразу после завершения создания бэкапа, мы рекомендуем хранить данные на диске дольше, чтобы не возникали затруднения с возможностью восстановления Oracle до контрольных точек. Следующая команда поможет задать период хранения файлов Oracle равный 7 дням. Этого времени должно хватить при условии, что вы выполняете резервное копирование Oracle по меньшей мере раз в 7 дней.

Более подробную информацию вы найдете в руководстве к утилите RMAN

docs.oracle.com/cd/B28359_01/backup.111/b28270/rcmconfb.htm#i1019318

Конфигурирование плагина Oracle для RMAN

В случае использования функции PITR восстановления утилиты RMAN, плагин Bacula для Oracle потребует активации режима Accurate. Вы должны активировать режим Accurate в ресурсе задачи. Примите во внимание факт, что в сочетании с плагином, функция Accurate используется для того, чтобы гарантировать, что все новые файлы, будут сохраняться плагином Bacula, но не будут помечаться как удаленные, поскольку, скорее всего, они могут еще пригодиться.

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

Параметр	Описание	По умолчанию	Пример
mode	Необходимо активировать PITR бэкап в режиме RMAN	Дамп	mode=rman
Oracle_user	Привилегированный пользователь Unix Oracle	oracle	oracle_user=oracle10
sid	Oracle SID		SID=XE
Oracle_SID	Oracle SID		Oracle_SID=XE
Oracle_HOME	Oracle HOME		ORACLE_HOME=/opt/oracle/…
verbose	Вывод RMAN отображается как 0 в задаче		verbose=1
sbt	Использование SBT в RMAN		sbt
ctrlfile	Основной путь к управляющим файлам при использовании SBT		ctrlfile=/tmp/oracle

Таблица 4. Параметры плагина для Oracle в режиме RMAN

Затем, используя where=/ или where= плагин загрузит этот SQL файл в вашу БД. Если некоторые роли уже существуют, появится сообщение об ошибке в журнале регистрации заданий. Также можно восстановить файл users.sql file в локальный каталог, отредактировать и загрузить его с помощью sqlplus, чтобы восстановить любую выбранную часть файла.

Восстановление одной БД Oracle. Чтобы восстановить одну схему с помощью плагина Bacula Enterprise для Oracle, вам необходимо выбрать схему каталога во время команды восстановления, выбор должен содержать файл данных (data.dmp) и скрипт создания схемы (user.sql).

Рис. 3 Содержимое БД с дампом в BWeb

Как только будет выбран каталог БД, вы сможете использовать параметр where для восстановления схемы в новую схему с другим именем. Чтобы создать новое имя схемы, вам нужно приравнять параметр where к одному слову, которое содержит символы A..Z, 0-9, и _. Затем плагин Bacula создаст указанную схему и восстановит в нее данные.

Мы рекомендуем вам всегда использовать в названии схем заглавные буквы. Плагин Bacula Enterprise для Oracle воссоздаст новую схему, используя имя, которое вы указали в параметре where=. Если вы будете использовать заглавные и строчные буквы в имени, может возникнуть ситуация, при которой вам придется заключить имя схемы в кавычки, чтобы получить к ней доступ.

После восстановления, вам, возможно, потребуется сбросить пароль схемы, которую вы только что создали, используя те же параметры, что и в исходной схеме. Чтобы сделать это, выполните:

Если вы зададите параметр, равный never, плагин Bacula проверит список схем и прервет задачу, если текущая восстанавливаемая схема уже существует.

Если параметр where – это каталог (содержащий /), плагин Bacula восстановит все файлы в этот каталог. Таким образом вы сможете использовать каталог imp и восстановить только триггеры, таблицы, индексы и т.д.

Восстановление одной таблицы Oracle. Чтобы восстановить один объект, например, таблицу из созданного вами дампа, вам необходимо сначала восстановить дамп файл в локальный каталог. Затем с помощью инструмента imp импортировать нужный объект. Более подробную информацию вы найдете в документации по импорту объектов в Oracle.

Восстановление дамп файлов Oracle в каталог. Чтобы восстановить SQL дампы в каталог, вы можете назначить параметру where любой действующий каталог.

Процесс восстановления Oracle с плагином Bacula создаст следующие папки при восстановлении схемы SYS в Oracle SID XE, и восстановит в нее выбранные файлы.

Восстановление всей БД Oracle. Чтобы восстановить все БД и конфигурации БД, просто восстановите все файлы, расположенные в /@ORACLE/, используте replace=always и where=/.

Ограничения бэкапа и восстановления Oracle

Плагины по умолчанию не совместимы с задачами Copy/Migration/VirtualFull.

Бла, бла, бла. Всегда нужно делать бекапы, иначе будет как на картинке “Он дропнул базу и не делал бэкапы”.

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

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

Резервное копирование баз данных Oracle подразумевает создание резервных копий файлов данных, управляющих файлов и файлов архивных журналов. Вдобавок в состав запасного набора могут включать файлы spfile, init.ora, listener.ora и tnsnames.ora

Резервное копирование выполняеся:

Средствами операционной системы.
Средствами RMAN (Recovery Manager).

Для централизованного хранения бекапов большого количества баз данных, Oracle предлагает использовать Oracle Catalog - еще одна база, созданная специально для бекапов (Что в ней хранится пока сказать не могу. Не использовал никогда). Почему-то я думал, что в ней хранятся бекапы. Но чего-то стал сомневаться в этом.

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

Режимы ARCHIVELOG и NOARCHIVELOG

Oracle записывает все изменения, которые вносятся в находящиеся в памяти блоки данных, в оперативные журналы повторного выполнения (online redo logs), и делает это, как правило, перед их записью в файлы базы данных. Во время процесса восстановления Oracle использует зафиксированные в файлах этих журналов изменения для приведения базы данных в актуальное состояние. Oracle поддерживает два режима для управления такими файлами.

Режим архивирования журналов (ARCHIVELOG). В этом режиме Oracle сохраняет (архивирует) заполненные журналы повторного выполнения. Следовательно, на сколько давно бы не выполнялось резервное копирование, если используется режим ARCHIVELOG, базу данных всегда можно будет восстановить до любой точки во времени с помощью архивных журналов.
Режим без архивирования журналов (NOARCHIVELOG). В этом режиме заполненные журналы повторного выполнения перезаписываются, а не сохраняются. Это, следовательно, означает, что в случае использования режима NOARCHIVELOG выполнять восстановление можно будет только из резервной копии и что все остальные изменения, которые были внесены в базу данных после выполнения резервного копирования, будут утрачиваться. Этот режим обеспечивает возможность выполнения восстановления только после отказа экземляра базы данных. В случае возникновения неполадок с носителем (например, потеря диска), функционирующую в режиме NOARCHIVELOG базу данных можно будет восстановить только из резервной копии и, естественно, с потерей всех изменений, которые были внесены в нее после создания этой резервной копии.

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

Резервное копирование всей или части базы данных

Подвергать резервному копированию можно как всю базу данных так и только ее часть, вроде входящего в ее состав табличного пространства или файла данных. Обратите внимание, что в случае, когда база данных функционирует в режиме NOARCHIVELOG, осуществлять резервное копирование лишь части базы данных, также называемое частичным резервным копированием (partial database backup), нельзя, если только все те табличные пространства и файлы, которые подлежат резервному копированию, не явлются доступными только для чтения. Выполнять резервное копирование всей базы данных, также называемое полным резервным копированием (whole database backup), можно как в режиме ARCHIVELOG, так и в режиме NOARCHIVELOG.

Чаще всего выполняется полное резервное копирование. Оно предполагает копирование не только всех файлов данных, но и еще одного важного файла – управляющего. Без управляющего файла Oracle не будет открывать базу данных, поэтому для восстановления помимо резервных копий всех файлов данных, необходимо также обязательно обладать и новейшей резервной копией управляющего файла.

Согласованное (consistent) и несогласованное (inconsistent) резервное копирование

Согласованное резервное копирование (consistent backup) приводит к созданию согласованных резервных копий и не требует проводить процесс восстановления. При применении резервной копии для восстановления базы данных или ее части (например, табличного пространства или файла данных), сначала обычно требуется проветси восстановление данных из резервной копии (т.е. процедуру RESOTRE), а затем – восстановление работоспособности базы данных (т.е. процедуру RECOVER). В случае согласованного резервного копирования ни один из этих восстановительных шагов выполнять не требуется. В случае несогласованного резервного копирования (inconsistent backup) выполнение этих восстановительных шагов всегда является обязательным.

Oracle присваивает каждой транзакции уникальный системный номер изменения (System Change Number - SCN). Каждая фиксация, к примеру, будет проводить к увеличению этого номера. Всякий раз, когда Oracle устанавливает контрольную точку, все изменившиеся данные в оперативных файла данных записываются на диск. И всякий раз, когда это происходит. Oracle выполняет обновление контрольной точки потока (thread checkpoint) в управляющем файле. Во время этого обновления Orale делает так, чтобы все доступные для чтения и записи файлы данных и управляющие файлы согласовались с одним и тем же SCN-номером. База данных считается согласованной тогда, когда SCN-номера, хранимые в заголовках всех файлов данных, являются идентичными и совпадают с информацией о заголовках файлов данных, которая содержится в управляющих файлах. Главное запомнить, что один и тот же SCN-номер должен обязательно присутствовать во всех файлах данных и управляющем файле (или файлах). Пристутствие идентичного SCN- номера, означает, что в файлах данных содержатся данные за один и тот же промежуток времени. Если данные являются согласованными, никакие шаги по восстановлению после возврата (или копирования) набора фалов резервных копий на прежнее место не понадобятся.

Для создания согласованной резервной копии базы данных необходимо либо закрывать (обычной командой SHUTDOWN или SHUTDOWN TRANSACTIONAL, но не командой SHUTDOWN ABORT), либо останавливать (с помощью команды аккуратного завершения работы) и запускать снова в режиме монтирования.

При выполнении несогласованного резервного копирования получается, что в файлах резервной копии содержатся данные за разные промежутки времени. Дело в том, что работу большинства производственных систем не допускается прерывать для проведения согласованного резервного копирования. Вместо этого необходимо, чтобы эти базы данных работали 24 часа в сутки 7 дней в неделю. Это, следоватлеьно, означает, что резервное копирование этих баз данных должно выполняться в оперативном режиме, т.е. пока они остаются открытыми для транзакций. Изменение файлов данных пользователями во время проведения резервного копирования как раз и приводит к получению несогласованных резервных копий. Выполнение несогласованного резервного копирования не означает получения каких-то неправильных резервных копий. Однако во время восстановления одного только возврата таких резервных копий на прежнее место недостаточно. Помимо возврата их на прежнее место требуется также обязательно применить все архивные и оперативные журналы повторного выполенния, которые были созданы в промежутке с момента выполнения резервного копирования и до момента, до которого необходимо восстановить базу данных. Oracle будет считывать эти файлы и автоматически применять к файлам этих резервнх копий все необходимые изменения.

Поскольку при отрытой базе данных можно осуществлять только несогласованное резервное копирование, для большинства производственных баз данных применяются стратегии именно с процедурами несогласованного резервного копироваиня в основе.

Резервное копирование открытой и закрытой базы данных

Резервное копировние открытой базы данных (open backup), также называемое оперативным (online backup) или горячим резервным копировние (hot/warm backup), подразумевает создание резервных копий при открытой и доступной для пользователей базе данных. Выполнять оперативное резервное копирование всей базы данных (равно как и только принадлежащего ей табличного пространства или файла данных) можно только в том случае, если база данных функционирует в режиме ARCHIVELOG. Проводить его, когда база данных функционирует в режиме NOARCHIVELOG, нельзя.

Резервное копирование закрытой базы данных (closed backup), также называемое холодным резервным копированием (cold backup), подразумевает создание резервных копий при закрытой (остановленной) базе данных. Такое резервное копирование всегда приводит к созданию согласованных резервных копий, если только база данных не была остановлена командой SHUTDOWN ABORT.

Физическое и логическое резервное копирование

С технической точки зрения процедуры резервного копирования Oracle можно поделить на логические и физические. Под логическим резервным копированием (logical backup) подразумевается создание резервных копий с помощью утилиты Data Pump Export, которые содержат логические объекты наподобие таблиц и процедур. Эти резервные копии сохраняются в особом двоичном формате, и данные из них могу извлекаться только посредством утилиты Data Pump Import.

Под физическим резервным копирование (physical backup) подразумевается создание резервных копий ключевых файлов базы данных Oracle, т.е. файлов данных, файлов архивных журналов повторного выполнения и управляющих файлов. Эти резервные копии могут сохраняться как на дисковых, так и на ленточных накопителях

Уровни резервного копирования

Ниже перечислены уровни, на которых допускается выполнять резервное копирование баз данных Oracle:

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