|
Арап Нанда
Арап Нанда: быстрое восстановление
(Recover in a Flash, by Arup Nanda)
Источник: журнал Oracle Magazine, January-February 2007
http://www.oracle.com/technology/oramag/oracle/07-jan/o17recovery.html.
Уменьшайте время восстановления базы данных, используя область для быстрого восстановления – Oracle flash recovery area (FRA).
Если вы для резервирования базы данных используете утилиту Oracle Recovery Manager (RMAN), вы, наверное, помните, что можете создавать резервные копии на диске или ленте. Если вы выбрали диск, то для резервного копирования вы можете использовать любой диск, который доступен серверу, лишь бы там было достаточно места. Для освобождения места для новых резервных копий вы также должны удалять старые избыточные копии, кроме того, вы должны обеспечивать доступность резервных копий и архивного журнала.
|
Технология Oracle Data Guard и область FRA
Если вы знакомы с технологией Oracle Data Guard, вы можете удивиться, как отличается от нее использование метода восстановления с использованием области FRA. Средства Oracle Data Guard поддерживают физическую или логическую резервную базу данных, синхронизуемую с основной базой данных посредством передачи и применения журнальных данных. Эта резервная база данных предназначена для аварийного восстановления и ни в коем случае не заменяет необходимость выполнения операций резервного копирования и восстановления. Например, если вы теряете файл, вы можете скопировать его из физической резервной базы данных, но на это может потребоваться время, которое зависит от состояния и местонахождения этой резервной базы данных. То есть, это то же самое, что и традиционное решение по резервному копированию и восстановлению.
Однако, если сервер основной базы данных по каким-то причинам "упал", технология Oracle Data Guard обеспечивает возможность быстрого аварийного перехода на резервную базу данных (смена ролей), которая может находиться на другом сервере и дисках, отделенных, возможно, от сервера основной базы географически. С другой стороны, область FRA находится на локальном сервере, поэтому она, хотя и обеспечивает быстрое восстановление, подвержена тем же самым сбоям, что и этот локальный сервер. В среде Oracle Data Guard в случае смены ролей приложения, которые используют базу данных, должны снова подключаться к серверу, чтобы использовать новую основную базу данных. Область FRA находится на локальном сервере, поэтому никакого повторного подключения приложений не требуется. Технология Oracle Data Guard обеспечивает предсказуемое время восстановления (время, необходимое для смены ролей), тогда как время восстановления копий-изображений в области FRA зависит от объема журнальных данных, которые нужно применить для синхронизации с оставшейся частью базы данных. |
Область для быстрого восстановления
Для облегчения управления дисковым резервированием вы можете в сервере Oracle Database 10g Release 1 и более поздних версиях определить специальную дисковую область, которая будет использоваться для всех типов резервирования. Она называется областью для быстрого восстановления – flash recovery area (FRA). Сервер Oracle Database управляет пространством внутри этой области; отслеживает нужные резервные копии; при необходимости освобождения места для новых резервных копий удаляет старые копии. По умолчанию в области FRA создаются резервные файлы (как обычные резервные копии, так и копии-отображения), записываемые утилитой Oracle RMAN, оперативные журнальные файлы, архивные журнальные файлы, управляющие файлы и журналы ретроспективных данных. Когда для новых резервных копий или файлов потребуется дополнительное место, сервер Oracle Database автоматически удалит несущественные резервные копии, освобождая администратора базы данных от этой рутинной работы. Файлы в области FRA считаются несущественными, когда они становятся устаревшими в соответствии с политикой сохранения резервных копий или когда они уже скопированы на ленту утилитой Oracle RMAN.
Настройка
Сначала нужно определить местоположение области FRA и ее размер. Если, например, местоположение – /home/oracle/FRA, а размер – 2GB, то под пользователем SYS выполните следующее:
alter system set
db_recovery_file_dest_size = 2G;
alter system set
db_recovery_file_dest = '/home/oracle/FRA';
Чтобы эти значения устанавливались и после перезапуска экземпляра сервера базы данных, вставьте в файл параметров инициализации следующие строки:
db_recovery_file_dest_size = 2G
db_recovery_file_dest = '/home/oracle/FRA'
Если вы настраиваете область FRA в среде кластера Oracle Real Application Clusters (Oracle RAC), она должна быть доступна всем узлам кластера. Так что, она может находиться в разделяемой файловой системе, сетевой файловой системе NFS или дисковой группе технологии автоматического управления хранением данных – Automatic Storage Management (ASM). Если вы используете технологию ASM, нужно установить:
db_recovery_file_dest = '+DISKGROUP1'
Для проверки установленных параметров можно выполнить запрос к представлению словаря данных V$RECOVERY_FILE_DEST:
select *
from v$recovery_file_dest;
В моем примере результат показывает, что в области FRA содержится 51 файл (столбец NUMBER_OF_FILES). Для определения типов файлов можно проверить представление V$FLASH_RECOVERY_AREA_USAGE. Оно показывает для каждого типа файлов размеры (в процентах от общего размера) используемого пространства (used) и пространства, освобождаемое при удалении несущественных файлов (reclaimable). Для получения более полезной картины можно в одном запросе соединить эти два представления (см. листинг 1) и показывать не проценты, а общий размер файлов. Листинг показывает, что имеется 34 архивных журнальных файлов (ARCHIVELOG), 16 резервных файлов, созданных утилитой Oracle RMAN, (BACKUPPIECE) и 1 журнал ретроспективных данных (FLASHBACKLOG). Размер несущественных резервных копий, которые можно удалять, показан в столбце RECLAIMABLE. В случае недостаточности пространства при резервировании утилитой Oracle RMAN выдается ошибка:
|
ЛИСТИНГ 1: потребление пространства в области FRA по типам файлов. |
select file_type, space_used*percent_space_used/100/1024/1024 used,
space_reclaimable*percent_space_reclaimable/100/1024/1024 reclaimable, frau.number_of_files
from v$recovery_file_dest rfd, v$flash_recovery_area_usage frau;
FILE_TYPE USED RECLAIMABLE NUMBER_OF_FILES
----------- ---- ----------- ---------------
CONTROLFILE .00 .00 0
ONLINELOG .00 .00 0
ARCHIVELOG 664.86 547.20 34
BACKUPPIECE 573.23 520.73 16
IMAGECOPY .00 .00 0
FLASHBACKLOG 6.07 .00 1 |
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 104857600 bytes disk space from 1073741824 limit
В этом случае для успешного завершения резервирования нужно либо вручную удалить какие-то резервные копии, либо увеличить размер области FRA. Для получения списка копий-отображений файлов данных (image copies), которые утилита Oracle RMAN создала в области FRA, можно использовать команду list copy of database, как это показано на листинге 2.
|
ЛИСТИНГ 2: список копий-отображений в области FRA. |
RMAN> list copy of database;
List of Datafile Copies
Key File S Completion Time Ckp SCN Ckp Time Name
---- ---- - --------------- ------- --------- -------------------------------------------------------------
4404 1 A 26-SEP-06 1607862 26-SEP-06 /home/oracle/FRA/PRODB2/datafile/o1_mf_system_2kmqnygd_.dbf
4407 2 A 26-SEP-06 1607935 26-SEP-06 /home/oracle/FRA/PRODB2/datafile/o1_mf_undotbs1_2kmqqy2b_.dbf
4405 3 A 26-SEP-06 1607907 26-SEP-06 /home/oracle/FRA/PRODB2/datafile/o1_mf_sysaux_2kmqpcnz_.dbf
4408 4 A 26-SEP-06 1607939 26-SEP-06 /home/oracle/FRA/PRODB2/datafile/o1_mf_users_2kmqr57t_.dbf
4406 5 A 26-SEP-06 1607926 26-SEP-06 /home/oracle/FRA/PRODB2/datafile/o1_mf_example_2kmqqgto_.dbf
|
В дополнение к хранению резервных копий файлов данных и журналов ретроспективных данных область FRA может быть также сконфигурирована для хранения архивных журнальных файлов, управляющих файлов и оперативных журнальных файлов. Эти опции хранения описаны в "Configuring the Flash Recovery Area: Advanced Topics".
Копия-отображение
По умолчанию утилита Oracle RMAN создает комплекты резервных копий (backup sets), в которых собираются только использованные блоки файлов данных. Утилита Oracle RMAN может также создавать копии-отображения – точные копии файлов данных, в которых содержатся все блоки, как использованные, так и неиспользованные. Утилита Oracle RMAN создает такую копию-отображение во время работы экземпляра сервера базы данных, и его не требуется переводить в какой-то специальный режим. Для создания резервной копии-отображения всей базы данных используется следующая команда утилиты Oracle RMAN:
run {
backup as copy
database;
}
Копии файлов данных создаются в области FRA с именами, генерируемыми сервером базы данных Oracle, такими как o1_mf_users_2kmqr57t_.dbf.
Быстрое восстановление
Копии-отображения в области FRA становятся по-настоящему полезными, когда вам потребуется "мгновенное восстановление". Помните, что эти копии-отображения – копии файлов данных, и этот факт регистрируется в каталоге утилиты Oracle RMAN и управляющем файле. В случае аварийной ситуации вам не нужно копировать резервную копию файла; вы можете сразу же использовать ее как основной файл данных.
Предположим, один из ваших файлов данных поврежден и нужно его восстановить. Обычно вы следуете общему подходу:
Переводите табличное пространство в автономный режим.
Копируете резервную копию файла данных.
Восстанавливаете состояние файла данных на момент сбоя.
Переводите табличное пространство в оперативный режим.
Шаг 2 может быть очень продолжительным, это зависит от размеров файла, пропускной способности используемых дисков, скорости переноса резервной копии с внешнего носителя в исходный файл данных, а также от нагрузки на систему других процессов. Предположим, в вашей системе для выполнения этого шага требуется больше двух часов, все это время данные восстанавливаемого табличного пространства будут недоступными. Это побуждает вас задуматься о минимизации времени восстановления. Для убыстрения восстановления вы рассматриваете возможность использования копий-отображений.
В этом случае шаг 2 заменяется на: "Даете указание серверу об использовании копии файла данных вместо исходного файла". Это позволяет уменьшить время выполнения этого шага с часов до секунд. Опишем процесс восстановления, предполагая, что повреждено табличное пространство USERS.
Сначала проверьте идентификатор (номер) и имя файла данных этого табличного пространства (результат показан в вертикальном формате):
select file_id, file_name
from dba_data_files
where tablespace_name = 'USERS';
FILE_ID : 4
NAME : /home/oracle/oradata/PRODB2/
users01.dbf
Подключитесь к утилите Oracle RMAN и выполните оставшиеся действия по восстановлению, которые подобны вышеперечисленным шагам, исключая шаг 2, который теперь будет выглядеть так: "Переключите файл данных номер 4 на копию в области FRA". Все операции показаны на листинге 3.
|
ЛИСТИНГ 3: операции утилиты RMAN по переключению на область FRA. |
RMAN> sql 'alter tablespace users offline';
sql statement: alter tablespace users offline
RMAN> switch datafile 4 to copy;
datafile 4 switched to datafile copy "/home/oracle/FRA/PRODB2/datafile/o1_mf_users_2kmqr57t_.dbf"
RMAN> recover datafile 4;
Starting recover at 26-SEP-06
using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:03
Finished recover at 26-SEP-06
RMAN> sql 'alter tablespace users online';
sql statement: alter tablespace users online |
После перевода табличного пространства в оперативный режим проверьте имя файла:
select name from v$datafile
where file# = 4;
NAME
----------------------------------
/home/oracle/FRA/PRODB2/datafile/
o1_mf_users_2kmqr57t_.dbf
Обратите внимание, теперь имя исходного файла данных показывается не как имя /home/oracle/oradata/PRODB2/users01.dbf, а как имя его копии в области FRA. Табличное пространство становится пригодным к использованию очень быстро (операция копирования не выполняется). Состояние исходных файлов данных и их копий до и после переключения с поврежденного файла данных 4 показано на рис. 1.
|
|
|
Рисунок 1. Использование копии файла данных |
Надписи на рисунке:
- Normal Operation – нормальная работа;
- Database – баз данных;
- FRA – область для быстрого восстановления;
- Datafile – файл данных;
- Datafile Copy – копия файла данных;
- After Switching to FRA for Datafile 4 – после переключения файла данных номер 4 на копию в области FRA;
- Live Datafile – активный файл данных;
- Copy of Datafile – копия файла данных;
- Damaged Datafile (not useful) – поврежденный файл данных (не пригодный).
Переключение в обратном направлении
Файл данных был быстро переведен в оперативный режим, что минимизирует время простоя, но теперь он находится на резервных дисках, которые могут быть медленнее основных дисков базы данных. Вы можете не захотеть оставлять сервер в таком состоянии на долгое время и при первой возможности вернуть файл данных на старое место –/home/oracle/oradata/PRODB2/, что обычно и делается. Для этого вы можете использовать утилиту Oracle RMAN. Нужно выполнить следующие шаги:
Создаете копию-отображение файла данных в исходном месте.
Переводите табличное пространство в автономный режим.
Переключаете файл данных на "копию" (в данном случае, однако, это будет "копией" в исходном месте).
Восстанавливаете табличное пространство.
Переводите табличное пространство в оперативный режим.
Эти шаги представлены на листинге 4. После этого переключения вы можете убедиться, что файл данных вновь находится на исходном месте:
select name from v$datafile
where file# = 4;
NAME
---------------------------------------
/home/oracle/oradata/PRODB2/users01.dbf
|
ЛИСТИНГ 4: переключение из области FRA обратно в исходное место. |
RMAN> backup as copy datafile 4 format '/home/oracle/oradata/PRODB2/users01.dbf';
Starting backup at 27-SEP-06
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile copy
input datafile fno=00004
name=/home/oracle/FRA/PRODB2/datafile/o1_mf_users_2kmqr57t_.dbf
output filename=/home/oracle/oradata/PRODB2/users01.dbf
tag=TAG20060927T103710 recid=45 stamp=602246230
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
Finished backup at 27-SEP-06
Starting Control File Autobackup at 27-SEP-06
piece handle=/home/oracle/FRA/PRODB2/autobackup/2006_09_27/
o1_mf_n_602246232_2ko34s42_.bkp comment=NONE
Finished Control File Autobackup at 27-SEP-06
RMAN> sql 'alter tablespace users offline';
...
RMAN> switch datafile 4 to copy;
datafile 4 switched to datafile copy "/home/oracle/oradata/PRODB2/users01.dbf"
RMAN> recover datafile 4;
...
RMAN> sql 'alter tablespace users online';
... |
В случае сбоя вы сберегаете полезное время, быстро переключаясь на копию-отображение файла данных в области FRA, для этого не требуется никакого копирования. Этот же механизм может быть также применен и ко всей базе данных. Если повреждены все файлы данных, вы легко можете переключить всю базу данных на ее копию, хранимую в области FRA. Для этого используется команда:
RMAN> switch database to copy;
Обратите внимание, вы можете выполнять эти операции с копиями-отображениями в любом месте без использования области FRA. Однако в этом случае все бремя по управлению пространством ляжет не на сервер базы данных, а на ваши плечи.
Резервное копирование на ленту
Резервное копирование в область FRA имеет много преимуществ, но оно все же не обеспечивает достаточной аварийной защиты. Диски могут ломаться, что может приводить к потере резервных копий в области FRA. К тому же, диски, в отличие от лент, не так легко перемещать и хранить в другом месте. Следовательно, вам все же нужно резервировать область FRA на ленту. Следующая команда создает резервную копию всего содержимого области FRA, включая архивные журнальные файлы:
run {
allocate channel c1 type sbt_tape;
backup recovery area;
}
Заключение
Основная цель любого проекта резервирования – усовершенствование процесса восстановления, чтобы сделать его более быстрым и надежным. Используя область FRA, администратор базы данных может направить все резервные копии в одно место, которым управляет сервер Oracle Database. Используя копии-отображения в области FRA, администратор может очень быстро справиться с повреждением файла данных, не используя традиционные операции "копирование-восстановление".
===================================================================
Арап Нанда (Arup Nanda) (arup@proligence.com) – администратор баз данных Oracle с двенадцатилетним стажем. Он занимается всеми аспектами администрирования – от оптимизации производительности до информационной безопасности и аварийного восстановления. Арап – соавтор книги "Oracle PL/SQL for DBAs" (O'Reilly Media, 2005). В 2003 г. он был удостоен награды журнала Oracle Magazine "Oracle's DBA of the Year" (администратор года баз данных Oracle). |
