Создать резервную копию данных базы oracle можно двумя способами:
- Используя средства операционной системы.
- Используя утилиты самой базы данных.
У каждого из этих способов есть преимущества и недостатки. В случае создания резервной копии средствами операционной системы необходимо, что бы на всём протяжении процесса создания резервной копии экземпляр был остановлен во избежание рассогласования данных, что недопустимо в случае необходимости функционирования системы в режиме 24/7. Второй основной недостаток это сложность администрирования большого количества резервных и трудоёмкость их проверки на ошибки.
Используя утилиты базы данных этих недостатков можно избежать, но появляются другие недостатки, сложность настройки и собственный синтаксис команд.
Встроенные утилиты базы данных для создания резервных копий – это прежде всего exp и expdp, позволяющие создавать логическую резервную копию (то есть копию объекта базы данных). Такой способ создания резервной копии прост, а основной его недостаток это время восстановления из копии в случае необходимости переустановки экземпляра и возможность восстановить объект только на конкретный момент осуществления бэкапа.
Самой же мощной, созданной компанией oracle специально для создания резервных копий баз данных, является утилита RMAN. Которая позволяет создавать полную копию базы данных без остановки экземпляра и восстанавливать её на любой момент в прошлом, сама следит за устаревшими копиями и удаляет их при необходимости, а так же проверяет их на наличие ошибок. Но при этом имеет серьёзный недостаток сложна в настройке и администрировании. Познакомимся поближе с настройкой и администрированием этой утилиты.
Утилита RMAN появилась в версии 8g и совершенствовалась в последующих. Настроим эту утилиту для регулярного создания резервных копий нашей базы данных.
Прежде всего нужно понять из чего состоит база данных и решить с какой периодичностью необходимо делать резервную копию. В нашем случае это база данных oracle и состоит она из следующих файлов:
- табличные пространства;
- управляющие файлы;
- журналы повторного выполнения;
- файлы данных (init.ora, spfile, tnsnames.ora, listener.ora, orapwd);
Выбрав данные для сохранения определяемся со стратегией копирования, а именно выбраем периодичность, тип создаваемых резервных копий и время их хранения. Резервные копии бывают инкрементными полными – то есть полностью скопированный файл, инкрементными кумулятивными – когда копия содержит лишь разницу данных между текущим состоянием и состоянием на время последнего инкрементного бэкапа и инкрементными дифференциальными – такие копии содержат в себе разницу между текущим состоянием и состоянием на момент любого последнего бэкапа. Выбор стратегии определяется режимом работы базы данных, если это база данных с частым внесением изменений, то желательно чаще делать инкрементальные полные копии это позволит быстрее восстановить работу базы после сбоя, т.к. не придётся выполнять большое количество транзакций. Если же эта база данных используется в основном для хранения и чтения, то инкрементальные копии можно делать редко и ограничиться регулярными кумулятивными.
Наша база данных используется в основном для хранения и мало изменяется во времени поэтому выберем следующую стратегию: создание инкрементной копии раз в неделю 3 ночи в воскресение, и создание кумулятивных копий каждую ночь в 3 часа, это позволит не занимая много дискового пространства быстро восстановить базу используя максимум 2 копии.
После того как мы определились с тем что копировать и с какой периодичностью можем переходить к настройке экземпляра базы данных. В первую очередь следует убедиться, что база данных функционирует в режиме архивирования журналов повторного выполнения (archivelog) проверить это можно запросом:
select log_mode from v$database;от любого пользователя с правами sysdba. Если запрос вернул archivelog то всё в порядке переходим к следующему пункту, если noarchivelog то нужно перезапустить базу в режиме archivelog. Для этого нужно перезапустить базу в режиме mount командой:
startup mount immediateи выполнить команду
alter database archivelog;она активирует режим archivelog, после этого остаётся только открыть базу данных командой:
alter database open;
Сохранение копий журналов повторного выполнения необходимо для создания согласованных инкрементных горячих копий базы данных, а так же для возможности восстановления состояния базы данных на любой момент в прошлом.
После того как мы перевели базу данных в режим archivelog необходимо задать ей параметры области пакетного восстановления. Проверим не заданы ли они уже запросом:
select name, value from v$parameter where name like 'db_recovery_file_dest%';если не заданы то задаём командами:
alter system set db_recovery_file_dest_size=50G scope=both;задаёт максимальный размер области пакетного восстановления и
alter system set db_recovery_file_dest='/storage/recovery_area' scope=both;задаёт расположение области пакетного восстановления в файловой системе. Создание области пакетного восстановления необходимо для того что бы rman мог самостоятельно удалять устаревшие копии, а так же отслеживать оставшееся свободное дисковое пространство и предупреждать если его остаётся мало.
После настройки экземпляра можно переходить к настройке самой утилиты rman, для этого подключившись к rman последовательностью команд
rman connect target user/pass@sidвыполняем команду
show all;
первым делом конфигурируем параметры сохранности резервных копий это делается либо параметром CONFIGURE RETENTION POLICY либо устанавливается количество копий которые одновременно хранятся, либо указывается период в который копия считается актуальной. Установим параметр recovery window равный 7 дням командой:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;включим автобэкап контрл файла при каждом создании резервной копии будет создаваться копия контрл файла:
CONFIGURE CONTROLFILE AUTOBACKUP ON;активируем оптимизацию что бы rman не создавал копии файлов уже существуют резервные копии идентичные существующей:
CONFIGURE BACKUP OPTIMIZATION ON;и распараллелим на 2 канала процесс создания резервной копии:
CONFIGURE DEVICE TYPE DISK PARALLELISM 2;Параметры устройства на которое сохраняется информация, шифрования, сжатия, формат автобэкапа контрл файла и максимальный размер файла копии мы менять не будем.
После этой настройки остаётся только создать в операционной системе файлы выполнения для rman и добавить их в планировщик задач.
Для воскресения:
#!/bin/bash export ORACLE_HOME=/u01/11g/ export NLS_LANG=american_america.AL32UTF8 export ORACLE_SID=kagu1251 rman connect target user/pass BACKUP INCREMENTAL LEVEL 0 DATABASE; BACKUP DATAFILE '/oradata/db/admin/kagu/pfile/ init.ora.6302012163819'; BACKUP DATAFILE '/u01/11g/network/admin/ listener.ora'; BACKUP DATAFILE '/u01/11g/network/admin/ tnsnames.ora'; BACKUP DATAFILE '/u01/11g/dbs/spfilekagu.ora'; BACKUP DATAFILE '/u01/11g/dbs/orapwkagu1251';
Для остальных дней:
#!/bin/bash export ORACLE_HOME=/u01/11g/ export NLS_LANG=american_america.AL32UTF8 export ORACLE_SID=kagu1251 rman connect target user/pass BACKUP INCREMENTAL LEVEL 1 DATABASE; BACKUP DATAFILE '/oradata/db/admin/kagu/pfile/ init.ora.6302012163819'; BACKUP DATAFILE '/u01/11g/network/admin/ listener.ora'; BACKUP DATAFILE '/u01/11g/network/admin/ tnsnames.ora'; BACKUP DATAFILE '/u01/11g/dbs/spfilekagu.ora'; BACKUP DATAFILE '/u01/11g/dbs/orapwkagu1251';
Для восстановления всей базы данных после полного их изчезновения применяется команда RESTORE DATABASE, после её выполнения необходимо синхронизировать данные с помощью архивных журналов командой RECOVER DATABASE, восстановление происходит в режиме mount.
Для восстановления конкретного табличного пространства необходимо сначало перевести его в режим OFFLINE командой:
ALTER TABLESPACE user OFFLINE;
После этого выполнить его восстановление и синхронизацию:
RESTORE TABLESPACE user; RECOVER TABLESPACE user;По завершении перевести его в режим online командой:
ALTER TABLESPACE user ONLINE;
Так же можно откатить базу данных на определённым момент времени назад для этого выполняется команда:
SET UNTIL TIME 'Jan 29 2013 20:00:00';
Это восстановление нужно делать когда база данных находится в режиме mount, а при открытии указать опцию RESETLOGS, что бы не выполнялись изменения сохранённые в журналах повторного выполнения созданные после точки восстановления.
Для наблюдения за созданными резервными копиями удобна команда CROSSCHEK которая позволяет проверить наличие резервных копий в области пакетного восстановления и возможность доступа к ним. Для тестирования файлов резервных копий на логические или физические ошибки используется команда VALIDATE.
