Компания Oracle рекомендует применять для резервного копирования и восстановления баз данных утилиту RMAN, поскольку она изначально учитывает особенности используемых в Oracle структур блоков и потому способна обеспечивать замечательную производительность; кроме того, она оснащена возможностями вроде сжатия, возобновления операций резервного копирования и восстановления, отслеживания изменений в блоках и интеграции с ПО уровня управления носителями (MML). Однако делать полностью действительные резервные копии вполне можно и самостоятельно, без помощи RMAN или Oracle Secure Backup, за счет применения предлагаемых в операционной системе команд копирования, наподобие cp и dd в UNIX и copy в Windows. При желании делать предназначенные для хранения на ленте резервные копии можно также подключаться к диспетчеру носителей. В случае такого подхода необходимо самостоятельно отслеживать все резервные копии, проверять их действительность, а также принимать решение о том, какие из них использовать во время сеанса восстановления. Именно поэтому Oracle и называет подобные методы создания резервных копий пользовательскими (user-managed backups).
При наличии простой базы данных Oracle и не слишком обременительных требований по резервному копированию, тратить время и силы на изучение утилиты RMAN может быть невыгодно. В таком случае пользовательские методы резервного копирования, пожалуй, являются идеальным решением, даже несмотря на утрату всех специальных возможностей, встроенных в RMAN.
Резервное копирование всей базы данных Oracle
Делать резервную копию всей базы данных можно как при открытой, так и при закрытой базе данных, если используется режим ARCHIVELOG. В случае режима NOARCHIVELOG делать резервную копию можно только при закрытой базе данных.
Резервное копирование всей закрытой базы данных
Для выполнения резервного копирования при закрытой базе данных, также называемого холодным резервным копированием (cold backup), нужно, чтобы база данных была закрыта аккуратным образом посредством обычной, немедленной или транзакционной остановки.
Подвергать резервному копированию необходимо все файлы, которые требуются для восстановления базы данных Oracle: файлы данных, файлы оперативных журналов повторного выполнения и управляющие файлы. С технической точки зрения, для восстановления базы данных требуется только один управляющий файл, но если файл init.ora или SPFILE ссылается на несколько управляющих файлов, может также потребоваться выполнять резервное копирование и всех мультиплексированных копий управляющих файлов. Сначала получается перечень файлов каждой категории, а потом производится их копирование в целевое место. Ниже в этом блоге более подробно рассказывается о том, как выполняется резервное копирование трех основных видов файлов в процессе резервного копирования всей закрытой базы данных.
Резервное копирование файлов данных
Получить список всех файлов данных, которые имеются в базе данных, можно посредством следующего запроса:
SQL> SELECT file_name FROM dba_data_files;
После этого с помощью команды cp, если дело происходит в системе UNIX (или copy, если в Windows) эти файлы данных можно скопировать в любое желаемое место. Для начала их можно копировать в файл операционной системы, а позже — переносить на ленточное устройство, чтобы иметь возможность хранить их за пределами сайта (offsite). Например, в UNIX для выполнения резервного копирования файлов данных служит такая команда:
$ cp /u01/orcl/oradata/data_01.dbf /u09/orcl/oradata/data_01.dbf
Резервное копирование файлов оперативных журналов повторного выполнения
Получать список файлов оперативных журналов повторного выполнения можно с помощью показанного ниже запроса:
SQL> SELECT member FROM v$logfile; MEMBER -------------------------------------------------- C:\ORACLENT\ORADATA\HELPME\REDO03.LOG C:\ORACLENT\ORADATA\HELPME\REDO02.LOG C:\ORACLENT\ORADATA\HELPME\REDO01.LOG SQL>
Поскольку здесь подразумевается, что выполняется резервное копирование всей закрытой базы данных, резервные копии будут иметь согласованный вид, т.е. при остановке базы данных все файлы будут иметь согласованный вид, и не будут нуждаться в выполнении восстановления при запуске. Таким образом, резервные копии оперативных журналов не особо полезны при восстановлении, потому выполнять их резервное копирование не обязательно. Тем не менее, файлы журналов повторного выполнения могут потребоваться для запуска восстановленного экземпляра, а это значит, что иногда их копирование имеет смысл.
Резервное копирование управляющих файлов
Выяснить имена управляющих файлов и место их размещения можно путем выполнения запроса к представлению V$CONTROLFILE:
SQL> SELECT name FROM v$controlfile; NAME --------------------------------------------------- C:\ORACLENT\ORADATA\HELPME\CONTROL01.CTL C:\ORACLENT\ORADATA\HELPME\CONTROL02.CTL C:\ORACLENT\ORADATA\HELPME\CONTROL03.CTL SQL>
Простой скрипт холодного резервного копирования
Скрипт для холодного резервного копирования выглядят довольно просто. Из-за того, что резервное копирование осуществляется при закрытой базе данных, весь процесс сводится к копированию всех необходимых файлов соответствующими утилитами операционной системы. В листинге ниже показан пример скрипта холодного резервного копирования.
#!/bin/ksh
ORACLE_SID=$1
export ORACLE_SID
export ORAENV_ASK=NO
BACKUP_DIR=/test01/app/oracle
. oraenv
sqlplus -s system/remorse1 << EOF
SET HEAD OFF FEED OFF ECHO OFF TRIMSPOOL ON LINESIZE 200
SPOOL /u01/app/oracle/dba/cold_backup.ksh
SELECT 'cp ' ||file_name|| ' ${BACKUP_DIR}' from sys.dba_data_files;
SELECT 'cp ' ||name || ' ${BACKUP_DIR}' from V$controlfile;
SELECT 'cp ' ||member|| ' ${BACKUP_DIR}' from V$logfile;
SPOOL OFF;
EXIT;
EOF
Выполнение приведенных выше команд приведет к созданию файла cold_backup.ksh, который затем легко превратить в исполняемый скрипт и запланировать его на регулярное выполнение.
Резервное копирование всей открытой базы данных
Между резервным копированием закрытой и открытой базы данных (также называемым горячим резервным копированием) существует большая разница. Процедуры резервного копирования открытой базы данных не исключают вероятность внесения пользователями изменений в данные во время резервного копирования файлов, что требует применения более сложных механизмов на стороне сервера Oracle.
Для полного резервного копирования открытой базы данных необходимо делать резервные копии всех файлов данных, управляющих файлов и архивных журналов повторного выполнения. Для этого можно применять обычные поддерживаемые в операционной системе команды копирования, но из-за того, что база данных фактически находится в рабочем состоянии, помимо них требуется также использовать и дополнительные команды, чтобы резервные копии получались действительными и согласованными. Чтобы разобраться в этом, необходимо понять, что происходит внутри самой базы данных при ее резервном копировании в оперативном режиме.
При первоначальной подготовке табличного пространства к резервному копированию за счет выполнения команды BEGIN BACKUP, Oracle обращает внимание на SCN-номера в заголовках файлов данных и фиксирует (“замораживает”) их. Другими словами, SCN-номера контрольных точек в заголовках файлов данных будут оставаться со своими прежними значениями до самого завершения резервного копирования и выполнения команды END BACKUP. Oracle будет продолжать записывать все изменения в файлы данных и файлы журналов повторного выполнения, но файлы журналов повторного выполнения будут заполнятся довольно быстро в большинстве случаев, поскольку Oracle будет записывать весь блок данных, а не только изменения, которые были внесены в него в результате отдельных транзакций, как это делается во время обычного резервного копирования. При внесении пользователями изменений во время оперативного резервного копирования, создание контрольных точек и запись блоков данных на диск будет продолжать происходить обычным образом. По завершении резервного копирования всего табличного пространства Oracle будет увеличивать SCN-номер контрольной точки каждого файла до самого последнего фактического значения SCN.
Важный момент в процессе горячего резервного копирования состоит в том, чтобы в случае, если до завершения резервного копирования возникнет какая-нибудь авария, всегда можно было выполнить восстановление на основе контрольной точки, которая была зафиксирована при первоначальном переводе табличного пространства в режим резервного копирования. Номер SCN, который замораживается в заголовках файлов, размещается там сразу же после контрольной точки, что приводит к сбрасыванию всех измененных записей из буфера в файлы данных. Во время процедур горячего резервного копирования в журналах повторного выполнения наблюдается приличный объем активности, большая часть которой связана с обработкой проблемы так называемых раздробленных блоков (fractured block). На момент оперативного резервного копирования определенного блока Oracle, этот блок может находиться в процессе выполнения в него записи. А это значит, что данные в создаваемой для него резервной копии могут получаться несогласованными, из-за записывания одной их части до, а второй — уже после внесения изменения. Генерируемый подобным образом несогласованный блок и называется раздробленным. Oracle приходится копировать весь такой блок в файл журнала повторного выполнения для обеспечения возможности создания его согласованной версии позже в будущем, если окажется, что он действительно был разбит во время процесса горячего резервного копирования.
Ниже перечислены шаги типичного процесса горячего резервного копирования.
- Выполните следующую команду:
SQL> ALTER DATABASE BEGIN BACKUP;
- Скопируйте все файлы данных, которые являются частью всех имеющихся в базе данных табличных пространств:
SQL> host cp /u10/app/oracle/oradata/remorse/users01.dbf /u01/app/oracle/remorse/backup
- После создания резервной копии всех файлов данных завершите процесс оперативного резервного копирования с помощью следующей команды:
SQL> ALTER DATABASE END BACKUP;
Команда END BACKUP заставляет Oracle вывести все табличные пространства из режима резервного копирования.
На заметку! Утилита RMAN не переводит табличные пространства ни в режим начала резервного копирования (BEGIN BACKUP), ни в режим завершения резервного копирования (END BACKUP). Сеанс сервера Oracle выполняет проверку заголовков и нижних колонтитулов в блоке данных для выяснения, не был ли тот раздроблен. Если был, тогда сервер RMAN просто считывает блок данных снова, чтобы получить его в согласованном виде.
При выполнении полного оперативного резервного копирования базы данных, функционирующей в режиме ARCHIVELOG, нужно обязательно делать резервную копию ее управляющего файла посредством специальной команды BACKUP CONTROLFILE TO 'имя_файла', как показано ниже:
SQL> ALTER DATABASE BACKUP CONTROLFILE TO '/u01/app/oracle/oradata/backup/cntlbkp.ctl';
Во время восстановления следует обязательно использовать сделанную подобным образом резервную копию управляющего файла во избежание проблем, которые могут возникнуть при попытке использовать обычную копию этого файла, сгенерированную операционной системой.
Как не трудно было заметить, переводить отдельно каждое табличное пространства в режим горячего резервного копирования не требуется. Начиная с Oracle Database 10g, переводить сразу все файлы данных в режим оперативного резервного копирования можно единственной командой. При этом, однако, нужно обязательно проверять, что база данных функционирует в режиме архивации журналов (ARCHIVELOG), смонтирована и открыта.
Теперь вам известно, как работает механизм оперативного резервного копирования. В листинге ниже приведен пример скрипта полного оперативного резервного копирования, который будет динамически делать резервную копию на диске для всех табличных пространства в базе данных, которую позже, при желании, можно легко скопировать на ленту.
#!/bin/ksh
ORACLE_SID=$1
export ORACLE_SID
export ORACLE_ASK=NO
BACKUP_DIR=/u01/app/oracle/backup
export BACKUP_DIR
sqlplus -s "sys/sys_password as sysdba" << EOF
set linesize 200
set head off
set feed off
SPOOL /u01/app/oracle/dba/hot_backup.ksh
BEGIN
dbms_output.put_line ('alter database begin backup;');
for f1 in (select file_name fn from sys.dba_data_files)
loop
dbms_output.put_line( 'host cp '||f1.fn|| ' $BACKUP_DIR');
end loop;
dbms_output.put_line ('alter database end backup;');
dbms_output.put_line('alter database backup
controlfile to '|| ' $BACKUP_DIR/control'|| ';');
dbms_output.put_line('alter system switch logfile;');
END;
/
SPOOL OFF;
EXIT
EOF
Генерируемый в буферном файле скрипт hot_backup.sh будет выглядеть следующим образом:
ALTER DATABASE BEGIN BACKUP; HOST cp /u05/oradata/nicko/system01.dbf $BACKUP_DIR HOST cp /u05/oradata/nicko/undotbs01.dbf $BACKUP_DIR . . . ALTER DATABASE END BACKUP; ALTER DATABASE BACKUP CONTROLFILE TO $BACKUP_DIR/control; ALTER SYSTEM SWITCH LOGFILE;
Как и скрипт холодного резервного копирования базы данных Oracle, скрипт горячего резервного копирования тоже может делаться частью скрипта оболочки и запускаться в заранее определенное время.
Частичное резервное копирование базы данных
Выполнять резервное копирование сразу всей базы данных вовсе не обязательно. Можно провести резервное копирование только какой-нибудь ее части, например, табличного пространства или вообще одного файла данных. Обычно частичное резервное копирование базы данных допускается выполнять только тогда, когда база данных функционирует в режиме ARCHIVELOG, однако существует и пара исключений из этого правила. В частности, если база данных функционирует в режиме NOARCHIVELOG и содержит какие-то доступные только для чтения или доступные обычно лишь в автономном режиме табличные пространства, разрешается выполнять резервное копирование только этих табличных пространств.
Выполнять резервное копирование табличного пространства можно как в оперативном, так и в автономном режиме, в зависимости от существующих потребностей. Для начала давайте рассмотрим пример выполнения резервного копирования табличного пространства в автономном режиме. В таком случае сначала понадобится перевести табличное пространство в автономный режим, а затем выполнить резервное копирование файлов, из которых оно состоит:
SQL> SELECT file_name FROM dba_data_files WHERE tablespace_name = 'USERS'; /u05/oradata/nicko/users01.dbf SQL>
Здесь видно, что в данном примере табличному пространству USERS принадлежит только один файл данных. Следовательно, для того, чтобы выполнить резервное копирование этого табличного пространства, достаточно выполнить резервное копирование просто этого файла данных. Но сначала потребуется перевести табличное пространство в автономный режим, исключив на время резервного копирования всякую вероятность получения пользователями доступа к любому из его файлов данных:
SQL> ALTER TABLESPACE users OFFLINE;
Теперь можно спокойно использовать утилиту операционной системы наподобие cp (или copy, если дело происходит в системе Window) для выполнения резервного копирования принадлежащего табличному пространству USERS файла данных:
SQL> host copy/u05/oradata/nicko /users01/dbf /u10/oradata/nicko/users01.dbf
Закончив копировать все файлы данных, которые принадлежат табличному пространству (в данном примере имеется только один файл данных), нужно снова перевести табличное пространство в оперативный режим:
SQL> ALTER TABLESPACE users ONLINE;
Для того чтобы выполнить резервное копирование табличного пространства без его перевода в автономный режим, сначала необходимо перевести его в режим резервного копирования, чтобы уведомить базу данных о начале процесса оперативного резервного копирования:
SQL> ALTER TABLESPACE sysaux BEGIN BACKUP; Tablespace altered. SQL>
Далее нужно скопировать принадлежащий этому табличному пространству файл или файлы данных:
SQL> HOST copy /u01/oradata/nicko/sysaux01.dbf /u05/oradata/nicko/sysaux01.dbf SQL>
И, наконец, напоследок необходимо выполнить следующую команду, уведомив базу данных о завершении процесса оперативного резервного копирования:
SQL> ALTER TABLESPACE sysaux END BACKUP; Tablespace altered. SQL>
Мониторинг выполнения пользовательских операций оперативного резервного копирования
Следить за выполнением операций оперативного резервного копирования и устранять возникающие в них неполадки помогают несколько динамических представлений производительности. Операции оперативного резервного копирования могут занимать приличное количество времени, в зависимости от размера базы данных. Иногда бывает так, что процесс резервного копирования останавливается или зависает до завершения. Поэтому администратору баз данных обязательно следует знать о тех шагах, которые необходимо выполнять в подобных случаях. В табл. 15.1 перечислены все наиболее важные представления V$, которые помогают проводить мониторинг и диагностику проблем в операциях резервного копирования.
| Представление | Описание |
| V$BACKUP | Это представление замечательно помогает определять, не находятся ли какие-то файлы данных все еще в режиме резервного копирования. Операции горячего резервного копирования иногда зависают, а с помощью запроса к содержащемуся в этом представлении столбцу состояния можно легко выяснить, не указано ли в нем для каких-нибудь файлов значение ACTIVE.Если для какого-то файла действительно имеется такое значение, а согласно графику операция резервного копирования должна была завершиться, очевидно, что-то пошло не так и, следовательно, теперь этот файл (или файлы) необходимо вывести из режима горячего резервного копирования. |
| V$DATAFILE | Это представление отображает список всех файлов данных, которые принадлежат всем подлежащим резервному копированию табличным пространствам. |
| V$LOG | Это представление отображает все оперативные журналы повторного выполнения, которые имеются у базы данных. |
| V$ARCHIVED_LOG | Это представление отображает накопленную в управляющем файле информацию об архивных журналах. |
| V$LOG_HISTORY | Это представление отображает перечень тех журналов повторного выполнения, которые были заархивированы. |
