РЕЗЕРВНОЕ КОПИРОВАНИЕ БАЗЫ ДАННЫХ
ГЛАВА 18
----------------------------------------------------------------
РЕЗЕРВНОЕ КОПИРОВАНИЕ БАЗЫ ДАННЫХ
Эта глава объясняет, как осуществлять резервное копирование
данных в базе данных ORACLE. Темы этой главы включают
обсуждение следующих вопросов:
* рекомендации по копированию
* выработка стратегии копирования
* выполнение полных и частичных копирований базы данных
* копирование управляющего файла
* обработка сбоев во время копирования
* использование утилит экспорта и импорта для копирования
Резервное копирование базы данных ORACLE 18-1
----------------
Рекомендации по копированию базы данных
Следующие секции предоставляют соображения, которые следует
учитывать при копировании базы данных ORACLE.
Спланируйте стратегии копирования и восстановления
перед созданием базы данных
--------------------------------------------------
Прежде чем создавать базу данных, вы должны решить, как вы
собираетесь защищать эту базу данных от возможных сбоев диска и
т.п. Если такое планирование не проводится до создания базы
данных, то может оказаться невозможным восстановление базы
данных, если сбой диска разрушит файлы данных, файлы онлайнового
журнала повторения или управляющие файлы базы данных. См.
секцию "Выработка стратегии копирования" на странице 18-4, если
вы не знакомы с типовыми стратегиями копирования базы данных.
Отладьте стратегии копирования и восстановления
-----------------------------------------------
Вы должны отладить ваши стратегии копирования и восстановления
на тестовом окружении как до, так и после перехода на
производственную систему. В процессе этой отладки вы можете
проверить, насколько тщательно проработаны ваши стратегии, и
свести к минимуму проблемы, прежде чем столкнетесь с ними в
реальной ситуации. Регулярное выполнение тестовых
восстановлений поможет гарантировать, что ваши процедуры
архивирования и копирования работоспособны. Оно также поможет
вам лучше познакомиться с процедурами восстановления, так что вы
с меньшей вероятностью будете ошибаться в критических ситуациях.
Выполняйте копирования средствами операционной системы
часто и регулярно
------------------------------------------------------
Частые и регулярные полные и частичные копирования базы данных
важны для любой схемы восстановления. Частота копирования
должна базироваться на объеме изменений, вносимых в базу данных
(таких как вставки, обновления и удаления строк в существующих
таблицах, добавление новых таблиц и т.п.). Если данные в базе
данных изменяются с высокой частотой, то частота копирования
базы данных должна быть пропорционально высокой. И наоборот,
если база данных мало изменяется, ее можно копировать не так
часто.
Создавайте соответствующую копию базы данных
перед и после модификации ее структуры
--------------------------------------------
Если вы выполняете любое из перечисленных ниже структурных
изменений базы данных, делайте соответствующее копирование вашей
базы данных непосредственно перед такими изменениями и после
них:
* Создание или удаление табличного пространства
* Добавление или переименование (перемещение) файла данных
в существующем табличном пространстве
* Добавление, переименование (перемещение) или удаление
группы или члена онлайнового журнала повторения
Соответствующий тип копирования зависит от режима архивирования
базы данных, как описано ниже:
18-2 Руководство администратора
* Если база данных работает в режиме ARCHIVELOG, то до и
после структурного изменения базы данных требуется лишь
резервное копирование управляющего файла базы данных (с
помощью команды ALTER DATABASE с опцией BACKUP
CONTROLFILE). Конечно, вы можете скопировать и другие
части базы данных.
* Если база данных работает в режиме NOARCHIVELOG, то
непосредственно перед и после структурного изменения базы
данных требуется сделать полное копирование файла базы
данных, включая все файлы данных, файлы журнала
повторения и управляющие файлы.
Часто копируйте интенсивно используемые табличные пространства
--------------------------------------------------------------
Если база данных работает в режиме ARCHIVELOG, то приемлемо
копировать индивидуальное табличное пространство или даже
индивидуальный файл. Эта возможность полезна, если одна часть
базы данных используется более интенсивно, чем другие, -
например, табличное пространство SYSTEM или табличные
пространства, содержащие сегменты отката. Путем более частого
копирования интенсивно используемых файлов данных базы данных вы
получаете более свежие копии этих файлов данных. Как следствие,
если сбой диска повреждает один из таких файлов данных, для его
реставрации может быть использована более недавняя копия, и
меньшее число изменений необходимо применить при прокрутке
вперед, чтобы восстановить файл к состоянию на момент сбоя, т.е.
время, затрачиваемое на восстановление, сокращается.
Сохраняйте старые копии
-----------------------
Время, в течение которого вы должны хранить старую копию базы
данных, зависит от того, как вы хотите восстанавливать базу
данных. Если вам требуется восстановление к прошлому моменту
времени, то вам нужна копия базы данных, взятая перед этим
моментом времени. Для базы данных, работающей в режиме
NOARCHIVELOG, это означает полную копию базы данных; для базы
данных, работающей в режиме ARCHIVELOG, это означает копию
каждого файла данных, полученную индивидуально или вместе с
остальными в любой момент, предшествующий требуемому, плюс копию
ассоциированного управляющего файла, отражающую структуру базы
данных на требуемый момент восстановления.
Как дополнительную меру защиты, рассмотрите возможность
поддержания двух или более копий, предшествующих текущей копии,
на случай потери или повреждения текущей копии базы данных.
Экспортируйте данные базы данных
для дополнительной страховки и гибкости
---------------------------------------
Так как утилита экспорта ORACLE может выборочно экспортировать
отдельные объекты, вы можете рассмотреть вариант экспортирования
всей или части базы данных, чтобы обеспечить дополнительную
защиту и гибкость для стратегии копирования. Однако экспорт
базы данных не заменяет ее копирования средствами операционной
системы, и не может обеспечить таких же преимуществ полноты
восстановления, которые предоставляются встроенными средствами
ORACLE.
Резервное копирование базы данных ORACLE 18-3
Копирование распределенной базы данных
--------------------------------------
Если ваша база данных является узлом в распределенной базе
данных, рассмотрите следующие рекомендации:
* Все базы данных в распределенной базе данных должны
работать в одном и том же режиме архивирования.
* Если базы данных в распределенной базе данных работают в
режиме ARCHIVELOG, то копирования на каждом узле могут
выполняться автономно (индивидуально, без согласования с
другими узлами).
* Если базы данных в распределенной базе данных работают в
режиме NOARCHIVELOG, то полные копирования на каждом узле
должны выполняться в один и тот же (глобальный) момент,
чтобы можно было планировать восстановление глобальной
распределенной базы данных. Например, если база данных в
Нью-Йорке копируется в полночь по восточному времени, то
база данных в Сан-Франциско должна копироваться в 9 утра
по тихоокеанскому времени. Для дополнительной информации
о восстановлении распределенной базы данных, когда узлы
работают в режиме NOARCHIVELOG, см. секцию "Координируйте
распределенное восстановление" на странице 19-3.
----------------
Выработка стратегии копирования
Прежде, чем создавать базу данных ORACLE, решите, как вы будете
защищать ее от потенциальных сбоев. Перед тем, как вырабатывать
стратегию копирования базы данных, необходимо задать два главных
вопроса:
* Может ли считаться приемлемой потеря каких-либо данных,
если сбой диска повредит часть файлов, составляющих базу
данных? Если потеря данных при сбоях считается
неприемлемой, то база данных должна работать в режиме
ARCHIVELOG, и - в идеале - с зеркальным журналом
повторения. Если потеря части данных при сбоях считается
приемлемой, то вы можете работать в режиме NOARCHIVELOG и
избежать лишней работы, связанной с архивированием
заполняемых групп журнала повторения.
* Должна ли база данных быть в работе все время (т.е. 24
часа в сутки, семь дней в неделю)? Если да, то режим
NOARCHIVELOG вам не подходит, потому что обязательные
полные копирования базы данных (которые делаются при
закрытой базе данных) можно будет выполнять не часто
(если вообще возможно). Поэтому базы данных с высокой
доступностью всегда работают в режиме ARCHIVELOG,
используя преимущества копирований онлайновых файлов
данных.
Следующие секции объясняют некоторые типовые стратегии
копирования, основанные на режиме архивирования базы данных.
18-4 Руководство администратора
Стратегии копирования в режиме NOARCHIVELOG
-------------------------------------------
Если база данных работает в режиме NOARCHIVELOG, то заполненные
группы файлов онлайнового журнала повторения не архивируются.
Поэтому единственной защитой от сбоя диска служит наиболее
свежая полная копия базы данных. Следующий список объясняет,
когда необходимо выполнять полные копирования базы данных,
работающей в режиме NOARCHIVELOG:
* Приготовьтесь делать полные копии регулярно, согласно
тому количеству работы, потеря которой для вас приемлема.
Например, если вы можете себе позволить потерять работу,
сделанную за неделю, делайте полную копию один раз в
неделю; если для вас приемлема лишь потеря работы,
сделанной за день, делайте полную копию ежедневно. Для
больших баз данных с высокой активностью, обычно
считается неприемлемой потеря любого количества работы.
Такие базы данных должны работать в режиме ARCHIVELOG и
использовать соответствующие стратегии копирования.
* Каждый раз, когда вы изменяете физическую структуру базы
данных, работающей в режиме NOARCHIVELOG, немедленно
берите полную копию базы данных. Эта копия защитит новую
структуру базы данных, которая не отражена в предыдущей
(регулярной) полной копии.
Стратегии копирования в режиме ARCHIVELOG
-----------------------------------------
Если база данных работает в режиме ARCHIVELOG, то заполненные
группы файлов онлайнового журнала повторения архивируются.
Поэтому архивированный журнал в сочетании с онлайновым журналом
повторения могут защитить базу данных от сбоя диска, обеспечивая
полное восстановление от такого сбоя к состоянию на момент сбоя.
Следующий список описывает общую стратегию копирования базы
данных, работающей в режиме ARCHIVELOG:
* После первоначального создания базы данных выполните
полное копирование всей базы данных. Эта начальная
полная копия составляет основу ваших последующих копий,
так как она содержит копии всех файлов данных и
управляющего файла ассоциированной базы данных.
[!] Замечание: Выполняя это начальное полное копирование,
сначала убедитесь, что база данных работает в режиме
ARCHIVELOG. В противном случае скопированные файлы базы
данных будут хранить характеристику режима NOARCHIVELOG.
* Последующие полные копирования не обязательны, а если
база данных работает в непрерывном режиме, то и
невозможны. Вместо этого вы можете делать частичные
копии, чтобы обновлять ваши копии базы данных.
* Выполняйте копирования онлайновых или офлайновых файлов
данных, чтобы обновлять поддерживаемые вами копии базы
Резервное копирование базы данных ORACLE 18-5
данных (дополняющие полную начальную копию). В
частности, файлы данных из интенсивно используемых
табличных пространств должны копироваться часто, чтобы
сократить время потенциального восстановления. Когда для
реставрации поврежденного файла данных используется более
свежая копия, меньшее число архивированных журналов
останется применить при прокрутке вперед, чтобы
восстановить файл к состоянию на момент сбоя.
Выполнять ли вам копирования онлайновых или офлайновых
файлов данных - зависит от требований к доступности
данных; онлайновые копирования являются единственной
возможностью, если копируемые данные всегда должны быть
доступными для нормальной работы.
* Каждый раз, когда вы делаете структурные изменения в базе
данных, берите копию управляющего файла, используя
команду ALTER DATABASE с опцией BACKUP CONTROLFILE.
[!] Замечание: Если управляющий файл не содержит имени файла
данных, и вы не имеете копии этого файла данных, то вы не
сможете восстановить его в случае его потери. Кроме
того, НЕ используйте утилит операционной системы для
копирования управляющего файла в режиме ARCHIVELOG, если
вы только не выполняете полное офлайновое копирование
базы данных.
* Файлы онлайнового журнала обычно никогда не требуют
резервного копирования, если база данных работает в
режиме ARCHIVELOG; они и так архивируются. (Однако, вы
должны копировать файлы онлайнового журнала, когда
делаете полное офлайновое копирование базы данных.)
Зеркальный онлайновый журнал еще более предохраняет от
вероятности потерять журнал в результате одиночного сбоя.
----------------
Взятие копий
Следующие секции описывают процедуры, необходимые для выполнения
полных и частичных копирований.
Вывод файлов базы данных перед копированием
-------------------------------------------
Перед полным или частичным копированием базы данных,
идентифицируйте файлы для копирования. Получите список файлов
базы данных, опросив обзор V$DATAFILE:
SELECT name FROM sys.v$datafile;
Получите список файлов онлайнового журнала повторения базы
данных, опросив обзор V$LOGFILE:
SELECT name FROM sys.v$logfile;
18-6 Руководство администратора
Эти запросы выдают файлы данных и файлы онлайнового журнала базы
данных, соответственно, согласно информации в текущем
управляющем файле базы данных.
Чтобы получить имена текущих управляющих файлов базы данных,
выдайте следующее предложение из SQL*DBA:
SHOW PARAMETER control_files;
Замечание: Для дополнительной информации о команде SQL*DBA SHOW
обратитесь к документу ORACLE7 Server Utilities User's Guide.
Каждый раз, когда вы берете копию управляющего файла, сохраняйте
вместе с этой копией полный список файлов данных и файлов
онлайнового журнала базы данных; так вы всегда будете иметь под
рукой физическую структуру базы данных на момент получения копии
управляющего файла.
Полное копирование базы данных
------------------------------
Выполняйте полное копирование всех файлов, составляющих базу
данных, после того, как база данных остановлена с нормальным
приоритетом. НЕЛЬЗЯ ВЫПОЛНЯТЬ ПОЛНОЕ КОПИРОВАНИЕ ПОСЛЕ ТОГО,
КАК БАЗА ДАННЫХ БЫЛА ОСТАНОВЛЕНА ИЗ-ЗА СБОЯ ИЛИ СНЯТИЯ
ИНСТАНЦИИ; в таких случаях копия не будет полной, так как файлы
не согласованы по отношению к текущему моменту времени. (Файлы,
составляющие базу данных, - это файлы данных, файлы онлайнового
журнала и управляющие файлы.)
Полное копирование не требует, чтобы база данных использовалась
в каком-либо конкретном режиме архивирования; полное копирование
не зависит от режимов ARCHIVELOG или NOARCHIVELOG.
Комплект копий файлов, полученных в результате полного
копирования, согласован; все файлы соответствуют одному и тому
же моменту времени. Если потребуется восстановление базы
данных, то эти файлы помогут реставрировать базу данных в
состояние на точный момент времени. После реставрации
скопированных файлов могут понадобиться дополнительные шаги для
восстановления базы данных в более позднее состояние, если база
данных работала в режиме ARCHIVELOG, а файлы онлайнового журнала
НЕ были реставрированы.
[!] Замечание: Копия управляющего файла, взятая при полном
копировании базы данных, должна использоваться только вместе с
копиями остальных файлов, взятыми тогда же, т.е. для полной
РЕСТАВРАЦИИ базы данных. Эта копия не должна применяться для
полного или частичного ВОССТАНОВЛЕНИЯ базы данных. Когда вы не
делаете полное резервное копирование базы данных, вы должны
делать копии вашего управляющего файла с помощью команды ALTER
DATABASE с опцией BACKUP CONTROLFILE; см. "Копирование
управляющего файла" на странице 18-15.
Подготовка к полному копированию
Чтобы гарантировать согласованность файлов базы данных, всегда
останавливайте базу данных с НОРМАЛЬНЫМ приоритетом, перед тем
Резервное копирование базы данных ORACLE 18-7
как делать ее полную копию; никогда не делайте полную копию
после того, как база данных остановлена предложениями SHUTDOWN
IMMEDIATE или SHUTDOWN ABORT. В обоих последних случаях файлы
данных могут быть несогласованными по отношению к моменту
времени.
Шаги полного копирования
Чтобы взять полную копию базы данных, выполните следующие шаги:
1. Остановите базу данных с нормальным приоритетом.
Для того, чтобы взять полную копию, все файлы базы данных
должны быть закрыты путем останова базы данных. Не делайте
полное копирование, если инстанция снята или остановлена в
результате сбоя; снова откройте базу данных и чисто
остановите ее, перед тем как выполнять полное копирование.
См. главу 3 для информации об останове базы данных.
2. Скопируйте все файлы, составляющие базу данных.
С помощью команд или утилит операционной системы сделайте
копии всех файлов данных, файлов онлайнового журнала
повторения и одного управляющего файла базы данных. Если вы
используете зеркальный журнал повторения, сделайте копии всех
членов каждой группы, так как не гарантирована полнота
каждого отдельного члена группы. Кроме того, скопируйте файл
параметров, ассоциированный с базой данных.
Копирование можно осуществлять:
* не выходя из SQL*DBA - через диалоговое окно HOST или
команду HOST
* вне SQL*DBA - непосредственно с помощью команд или утилит
операционной системы
Обратитесь к вашему руководству по инсталляции [IUG] для
дополнительной информации о средствах копирования, присущих
вашей операционной системе.
3. Перезапустите базу данных.
Закончив копирование всех файлов данных, файлов онлайнового
журнала повторения и одного управляющего файла базы данных,
вы можете снова запустить базу данных. (См. главу 3 для
дополнительной информации о запуске базы данных.)
Частичное копирование
---------------------
Следующие секции объясняют процедуры, необходимые для
осуществления различных типов частичного копирования базы
данных:
* копирование онлайновых табличных пространств и файлов
данных
* копирование офлайновых табличных пространств и файлов
данных
18-8 Руководство администратора
Частичное копирование должно предприниматься (а в ряде случаев и
может выполняться) только при работе базы данных в режиме
ARCHIVELOG; нельзя использовать частичные копии для реставрации
базы данных, работающей в режиме NOARCHIVELOG.
Замечание: Для полной информации о диалоговых окнах SQL*DBA и о
командах SQL ALTER TABLESPACE и ALTER DATABASE, которые
используются в следующих секциях, обратитесь к документам
ORACLE7 Server Utilities User's Guide и ORACLE7 Server SQL
Language Reference Manual, соответственно.
Копирование онлайновых табличных пространств
и онлайновых файлов данных
Все или часть файлов индивидуального табличного пространства,
находящегося в состоянии онлайн, могут быть скопированы
одновременно с продолжением нормальной работы базы данных.
Чтобы сделать онлайновую копию полного онлайнового табличного
пространства или отдельного файла данных онлайнового табличного
пространства, используйте следующие шаги:
1. Идентифицируйте файлы данных.
Если вы хотите копировать конкретный файл данных, определите
его полное имя.
Если вы хотите копировать полное табличное пространство,
определите полные имена всех составляющих его файлов с
помощью обзора словаря данных DBA_DATA_FILES. Например,
предположим, что вы хотите скопировать табличное пространство
USERS. Чтобы идентифицировать файлы данных табличного
пространства USERS, опросите обзор DBA_DATA_FILES:
SELECT tablespace_name, file_name
FROM sys.dba_data_files
WHERE tablespace_name = 'USERS';
TABLESPACE_NAME FILE_NAME
--------------- ---------
USERS filename1
USERS filename2
Здесь filename1 и filename2 - полностью специфицированные
имена файлов данных, составляющих табличное пространство
USERS. Для дополнительной информации об обзоре словаря
данных DBA_DATA_FILES обратитесь к приложению B.
2. Отметьте факт начала копирования онлайнового табличного
пространства.
Чтобы подготовить файлы данных онлайнового табличного
пространства к резервному копированию, используйте либо
диалоговое окно Begin Online Tablespace Backup SQL*DBA, либо
команду SQL ALTER TABLESPACE с опцией BEGIN BACKUP. Рис.18-1
показывает диалоговое окно Begin Online Tablespace Backup.
Резервное копирование базы данных ORACLE 18-9
Рис.18-1
Диалог Begin Online Tablespace Backup
---------------------------------------------------------------¬
¦ File Edit Session Instance Storage Log Backup Security¦
¦--------------------------------------------------------------+
¦¦ ¦
¦¦ г====== Begin Online Tablespace Backup =====¬ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦ Online Tablespace: ¦ ¦
¦¦ ¦ ----------------------------------------¬ ¦ ¦
¦¦ ¦ ¦ SYSTEM ¦ ¦ ¦
¦¦ ¦ ¦ TEMP ¦ ¦ ¦
¦¦ ¦ ¦ USERS---------------------------------¦ ¦ ¦
¦¦ ¦ ¦ ¦ ¦ ¦
¦¦ ¦ L---------------------------------------- ¦ ¦
¦¦ ¦-------------------------------------------¦ ¦
¦¦ ¦ Mandatory (OK) (Cancel) ¦ ¦
¦¦ L===========================================- ¦
¦¦ ¦
¦L-------------------------------------------------------------+
¦--------------------------------------------------------------+
¦¦ ¦
¦¦ ¦
¦L-------------------------------------------------------------+
L---------------------------------------------------------------
Следующее предложение является командным эквивалентом
диалогового окна Begin Online Tablespace Backup, показанного
на рис.18-1:
ALTER TABLESPACE users BEGIN BACKUP;
Замечание: Если вы забудете отметить начало копирования
онлайнового табличного пространства (любым из описанных
способов), то сделанные вами копии файлов будут непригодны
для последующих операций восстановления. Попытка
восстановления из такой копии может не возвратить ошибок, но
результирующие данные могут впоследствии оказаться
несогласованными.
3. Сделайте копии онлайновых файлов данных.
В этот момент вы можете скопировать онлайновые файлы данных
онлайнового табличного пространства:
* не выходя из SQL*DBA - через диалоговое окно HOST или
команду HOST
* вне SQL*DBA - непосредственно с помощью команд или утилит
операционной системы
Обратитесь к документу ORACLE7 Server Utilities User's Guide
и к вашему руководству по инсталляции [IUG] для
дополнительной информации о средствах копирования, присущих
вашей операционной системе.
4. Отметьте факт окончания копирования онлайнового табличного
пространства.
Чтобы сообщить ORACLE об окончании копирования файлов данных
онлайнового табличного пространства, используйте либо
диалоговое окно End Online Tablespace Backup SQL*DBA, либо
18-10 Руководство администратора
команду SQL ALTER TABLESPACE с опцией END BACKUP. Рис.18-2
показывает диалоговое окно End Online Tablespace Backup.
Рис.18-2
Диалог End Online Tablespace Backup
---------------------------------------------------------------¬
¦ File Edit Session Instance Storage Log Backup Security¦
¦--------------------------------------------------------------+
¦¦ г====== End Online Tablespace Backup =======¬ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦ Online Tablespace: ¦ ¦
¦¦ ¦ ----------------------------------------¬ ¦ ¦
¦¦ ¦ ¦ SYSTEM ¦ ¦ ¦
¦¦ ¦ ¦ USERS---------------------------------¦ ¦ ¦
¦¦ ¦ L---------------------------------------- ¦ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦-------------------------------------------¦ ¦
¦¦ ¦ (OK) (Cancel) ¦ ¦
¦¦ L===========================================- ¦
¦¦ ¦
¦L-------------------------------------------------------------+
¦--------------------------------------------------------------+
¦¦ ¦
¦L-------------------------------------------------------------+
L---------------------------------------------------------------
Следующее предложение является командным эквивалентом
диалогового окна End Online Tablespace Backup, показанного на
рис.18-2:
ALTER TABLESPACE users END BACKUP;
Замечание: Если вы забудете отметить окончание копирования
онлайнового табличного пространства (любым из описанных
способов), и база данных впоследствии будет закрыта, то
ORACLE потребует восстановления носителя при очередном
запуске инстанции. Это восстановление может потребовать
применения архивированного журнала повторения.
Определение состояния копирования файлов данных
Для определения состояния копирования файлов данных (т.е. было
ли закончено копирование) часто можно использовать таблицу
словаря данных V$BACKUP. Эта таблица выдает все онлайновые
файлы данных и сообщает их статус копирования. Эта таблица
наиболее полезна при открытой базе данных; она также полезна
сразу после сбоя, так как она показывает состояние копирования
каждого файла на момент сбоя. Вы можете использовать эту
информацию для определения, не оставили ли вы какие-либо
табличные пространства в состоянии незаконченного копирования.
Замечание: Таблица V$BACKUP бесполезна, если используемый в
данный момент управляющий файл был реставрирован из резервной
копии или заново создан после сбоя носителя; реставрированный
или пересозданный управляющий файл не содержит информации,
позволяющей ORACLE правильно заполнить таблицу V$BACKUP. Кроме
того, если вы реставрировали файл данных из резервной копии,
статус этого файла в таблице V$BACKUP отражает состояние старой
версии этого файла, а не текущей версии. Поэтому для
реставрированных файлов обзор V$BACKUP может содержать неверную
информацию.
Резервное копирование базы данных ORACLE 18-11
Например, следующий запрос выдает текущее состояние копирования
файлов данных:
SELECT file#, status
FROM v$backup;
FILE# STATUS
---------------------
0011 INACTIVE
0012 INACTIVE
0013 ACTIVE
...
В столбце STATUS, "INACTIVE" означает, что файл не копируется, а
"ACTIVE" - что файл в настоящий момент отмечен как копируемый.
Привилегии, требуемые для копирования
онлайновых табличных пространств
Для резервного копирования онлайновых табличных пространств вы
должны иметь системную привилегию MANAGE TABLESPACE.
Резервное копирование нескольких онлайновых табличных пространств
Если вы должны выполнить копирование нескольких онлайновых
табличных пространств, используйте любую из следующих процедур:
* Скопируйте все онлайновые табличные пространства
параллельно. Например, сначала подготовьте все нужные
онлайновые табличные пространства для копирования:
ALTER TABLESPACE ts1 BEGIN BACKUP;
ALTER TABLESPACE ts2 BEGIN BACKUP;
ALTER TABLESPACE ts3 BEGIN BACKUP;
Затем скопируйте все файлы этих онлайновых табличных
пространств и укажите, что копирование закончено:
ALTER TABLESPACE ts1 END BACKUP;
ALTER TABLESPACE ts2 END BACKUP;
ALTER TABLESPACE ts3 END BACKUP;
* Скопируйте все онлайновые табличные пространства друг за
другом. Например, индивидуально подготовьте, скопируйте
и закончите копирование каждого онлайнового табличного
пространства:
18-12 Руководство администратора
ALTER TABLESPACE ts1 BEGIN BACKUP;
скопировать файлы
ALTER TABLESPACE ts1 END BACKUP;
ALTER TABLESPACE ts2 BEGIN BACKUP;
скопировать файлы
ALTER TABLESPACE ts2 END BACKUP;
ALTER TABLESPACE ts3 BEGIN BACKUP;
скопировать файлы
ALTER TABLESPACE ts3 END BACKUP;
Второй вариант минимизирует время между командами ALTER
TABLESPACE ... BEGIN BACKUP и ALTER TABLESPACE ... END BACKUP,
и потому является более предпочтительным:
* Во время онлайновых копирований для табличного
пространства генерируется больше информации повторения.
* Если во время онлайнового копирования произойдет сбой
инстанции, а файл онлайнового журнала, который
записывался в момент выдачи команды BEGIN BACKUP, уже
перекрыт, то для восстановления потребуются
архивированные файлы журнала.
Поэтому фирма Oracle рекомендует вам осуществлять резервное
копирование онлайновых табличных пространств последовательно.
Проблемы, прерывающие онлайновое копирование
Если резервное копирование онлайнового табличного пространства
прерывается сбоем системы или инстанции (после того, как выдана
команда ALTER TABLESPACE ... BEGIN BACKUP, но до того, как
выдана команда ALTER TABLESPACE ... END BACKUP), то для базы
данные требуется полное восстановление носителя. Для
дополнительной информации см. "Полное восстановление носителя"
на странице 19-17.
Копирование офлайновых табличных пространств
и офлайновых файлов данных
Все или часть файлов индивидуального табличного пространства,
находящегося в состоянии офлайн, могут быть скопированы. Все
прочие табличные пространства базы данных могут оставаться
открытыми и доступными для нормальной работы базы данных.
Замечание: Нельзя перевести в офлайн табличное пространство
SYSTEM или любое табличное пространство, содержащее активные
сегменты отката. Поэтому описанная ниже процедура не может быть
применена к таким табличным пространствам.
Чтобы сделать резервную копию файлов данных офлайнового
табличного пространства, используйте следующие шаги:
1. Идентифицируйте файлы данных офлайнового табличного
пространства.
Используйте полностью специфицированные имена файлов данных.
Перед тем, как переводить табличное пространство в офлайн,
определите полные имена всех составляющих его файлов с
помощью обзора словаря данных DBA_DATA_FILES. (См. шаг 1 в
предыдущей секции на странице 18-9.)
2. Переведите табличное пространство в состояние офлайн,
используя нормальный приоритет, если возможно.
Резервное копирование базы данных ORACLE 18-13
Если можно, переведите табличное пространство в офлайн в
нормальном режиме (не TEMPORARY и не IMMEDIATE), чтобы
гарантировать, что это табличное пространство не потребует
впоследствии восстановления после его возвращения в онлайн.
Чтобы перевести табличное пространство (и все ассоциированные
файлы данных) в офлайн с нормальным приоритетом, используйте
либо диалоговое окно Set Tablespace Offline SQL*DBA, либо
команду SQL ALTER TABLESPACE с параметром OFFLINE. Например,
следующее предложение переводит в офлайн табличное
пространство USERS в нормальном режиме:
ALTER TABLEPACE users OFFLINE;
После перевода табличного пространства в офлайн в нормальном
режиме, все файлы данных этого табличного пространства будут
закрыты. См. страницу 7-9 для дополнительной информации об
онлайновых и офлайновых табличных пространствах.
3. Сделайте копии офлайновых файлов данных.
В этот момент вы можете скопировать файлы данных офлайнового
табличного пространства:
* не выходя из SQL*DBA - через диалоговое окно HOST или
команду HOST
* вне SQL*DBA - непосредственно с помощью команд или утилит
операционной системы
Обратитесь к вашему руководству по инсталляции [IUG] для
дополнительной информации о средствах копирования, присущих
вашей операционной системе.
4. Переведите табличное пространство в онлайн. (Необязательно)
Чтобы перевести табличное пространство в онлайн, используйте
либо диалоговое окно Set Tablespace Online SQL*DBA, либо
команду SQL ALTER TABLESPACE с параметром ONLINE. Например,
следующее предложение переводит в онлайн табличное
пространство USERS:
ALTER TABLEPACE users ONLINE;
Замечание: Если табличное пространство было переведено в
офлайн с приоритетом TEMPORARY или IMMEDIATE, то может
оказаться невозможным вернуть его в состояние онлайн, не
выполняя восстановления табличного пространства. Для
дополнительной информации о восстановлении табличного
пространства обратитесь к главе 19.
После перевода табличного пространства в онлайн все файлы
этого табличного пространства открыты и доступны для
использования.
Привилегии, требуемые для копирования
офлайновых табличных пространств
Для перевода табличных пространств в офлайн и онлайн вы должны
иметь системную привилегию MANAGE TABLESPACE.
18-14 Руководство администратора
Копирование управляющего файла
------------------------------
Делайте резервное копирование управляющего файла базы данных
после структурной модификации базы данных, работающей в режиме
ARCHIVELOG.
Для выполнения копирования управляющего файла базы данных
используйте команду SQL ALTER DATABASE с параметром BACKUP
CONTROLFILE. Например, следующее предложение создает резервную
копию управляющего файла:
ALTER DATABASE BACKUP CONTROLFILE TO 'filename' REUSE;
Здесь filename - полностью специфицированное имя файла для новой
резервной копии управляющего файла.
Опция REUSE позволяет новой резервной копии управляющего файла
перекрывать уже существующий файл с тем же именем. Нельзя
специфицировать эту опцию, если вы одновременно специфицируете
одну из следующих опций в команде ALTER DATABASE BACKUP
CONTROLFILE:
* MAXLOGFILES
* MAXDATAFILES
* MAXINSTANCES
* MAXLOGMEMBERS
* MAXLOGHISTORY
Отображение управляющего файла в журнал трассировки
Команда ALTER DATABASE BACKUP CONTROLFILE имеет опцию TRACE,
которая может помочь вам поддерживать ваш управляющий файл и
выполнять восстановление с ним. Эта опция заставляет ORACLE,
вместо создания физической копии управляющего файла, записать в
файл трассировки базы данных серию команд SQL. Эти команды
запускают базу данных, пересоздают управляющий файл, а затем
выполняют соответствующую реставрацию и восстановление базы
данных, опираясь на текущий управляющий файл; все эти команды
прокомментированы. Это позволяет вам скопировать эти команды из
файла трассировки в скрипт, отредактировать их, как нужно, и
использовать этот скрипт для восстановления базы данных в случае
потери всех копий управляющего файла.
Например, предположим, что база данных SALES имеет три
включенных потока, из которых поток 2 - общий, а поток 3 -
личный; она также использует мультиплексируемые файлы журнала
повторения и имеет одно офлайновое и одно онлайновое табличные
пространства. Эта команда может использоваться следующим
образом:
ALTER DATABASE
BACKUP CONTROLFILE TO TRACE NORESETLOGS;
3-JUN-1992 17:54:47.27:
# The following commands will create a new control file and use
# it to open the database.
# No data other than log history will be lost. Additional logs
# may be required for media recovery of offline data files.
Резервное копирование базы данных ORACLE 18-15
# Use this only if the current version of all online logs are
# available.
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE SALES NORESETLOGS ARCHIVELOG
MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXDATAFILES 32
MAXINSTANCES 16
MAXLOGHISTORY 1600
LOGFILE
GROUP 1 'DISK$A:[PROD.SALES.DB]LOG1T1.ORA' SIZE 100K,
GROUP 2
'DISK$A:[PROD.SALES.DB]LOG2T1.ORA',
'DISK$A:[PROD.SALES.DB]G2.ORA'
) SIZE 100K,
GROUP 3 'DISK$A:[PROD.SALES.DB]LOG1T2.ORA' SIZE 100K,
GROUP 4 'DISK$A:[PROD.SALES.DB]LOG2T2.ORA' SIZE 100K,
GROUP 5
'DISK$A:[PROD.SALES.DB]LOG1T3.ORA',
'DISK$A:[PROD.SALES.DB]G5.ORA'
) SIZE 100K,
GROUP 6 'DISK$A:[PROD.SALES.DB]LOG2T3.ORA' SIZE 100K
DATAFILE
'DISK$A:[PROD.SALES.DB]DATABASE1.ORA' SIZE 2M,
'DISK$A:[PROD.SALES.DB]FILEA.ORA' SIZE 200K
;
# Take files offline to match current control file.
ALTER DATABASE
DATAFILE 'DISK$A:[PROD.SALES.DB]FILEA.ORA' OFFLINE;
# Recovery is required if any data files are restored backups,
# or if the last shutdown was not normal or immediate.
RECOVER DATABASE;
# All logs need archiving and a log switch is needed.
ALTER SYSTEM ARCHIVE LOG ALL;
# Database can now be opened normally.
ALTER DATABASE OPEN;
# Files in normal offline tablespaces are now named.
ALTER DATABASE RENAME FILE 'MISSING0002'
TO 'DISK$A:[PROD.SALES.DB]FILEB.ORA';
Использование этой команды с опцией RESETLOGS вместо NORESETLOGS
генерирует аналогичный скрипт с включением команд, которые
восстанавливают и открывают базу данных, но со сбросом журнала
повторения при запуске.
18-16 Руководство администратора
Привилегии, требуемые для копирования управляющего файла
Для копирования управляющего файла вы должны иметь системную
привилегию ALTER DATABASE.
----------------
Восстановление от сбоя во время резервного копирования
Если вы собъетесь во время онлайнового копирования, то вы должны
восстановить базу данных при ее очередном запуске. (Вы не
обязаны выдавать команду END BACKUP после перезапуска базы
данных.)
Для этого восстановления вам не требуется реставрация из
предыдущих копий файлов данных. Вам могут понадобиться
архивированные файлы журнала повторения.
Чтобы определить, какие файлы находились в процессе резервного
копирования на момент сбоя, вы можете опросить таблицу V$BACKUP.
См. "Определение состояния копирования файлов данных" на
странице 18-11.
Выполняйте восстановление одним из двух способов:
* Используйте диалоговое окно SQL*DBA Start Up Instance с
опцией Recover или команду SQL STARTUP RECOVER, чтобы
запустить и автоматически восстановить базу данных.
* Запустите базу данных, смонтируйте и откройте базу данных
и выдайте предложение RECOVER DATABASE.
Первый метод проще, потому что он заставляет ORACLE выполнять
восстановление лишь тогда, когда оно необходимо.
Для информации о запуске базы данных обратитесь к главе 3. Для
информации о восстановлении базы данных обратитесь к главе 19.
----------------
Применение утилит Export и Import для дополнительной защиты базы данных
Export и Import - это утилиты, которые перемещают данные ORACLE
из базы данных и в базу данных, соответственно. Экспорт пишет
данные из базы данных ORACLE в файл операционной системы в
специальном формате. Импорт читает файлы, созданные утилитой
экспорта ("экспортные файлы") и восстанавливает соответствующую
информацию в существующей базе данных. Хотя экспорт и импорт
предназначены для перемещения данных ORACLE, вы можете также
использовать их в дополнение к резервным копиям данных.
Замечание: Обе эти утититы более детально обсуждаются в
документе ORACLE7 Server Utilities User's Guide.
Использование экспорта
----------------------
Экспорт позволяет вам создать копию данных вашей базы данных,
когда она открыта и доступна для использования. Эта утилита
записывает согласованное по чтению представление объектов базы
данных в файл операционной системы.
Резервное копирование базы данных ORACLE 18-17
Замечание: Если вы используете экспорт для создания копии, то
все данные должны экспортироваться логически согласованным
образом, чтобы результирующая копия соответствовала состоянию на
единый момент времени. Никто не должен вносить изменения в базу
данных, пока она экспортируется. В идеале, вы должны запустить
базу данных в ограниченном режиме, чтобы обычные пользователи не
имели доступа к данным на время экспорта.
Есть три режима экспорта:
User экспортирует все объекты, принадлежащие
пользователю
Table экспортирует все или заданные таблицы,
принадлежащие пользователю
Full Database экспортирует все объекты базы данных
Эта секция обсуждает лишь режим полного экспорта базы данных.
Есть также три типа экспорта:
* Инкрементальный
* Кумулятивный
* Полный
Инкрементальный экспорт
ЭКСПОРТИРУЮТСЯ ЛИШЬ ТЕ ДАННЫЕ, КОТОРЫЕ ИЗМЕНИЛИСЬ СО ВРЕМЕНИ
ПОСЛЕДНЕГО ИНКРЕМЕНТАЛЬНОГО ЭКСПОРТА.
Например, если существуют таблицы A, B и C, и после последнего
инкрементального экспорта была модифицирована лишь информация в
таблице A, то экспортируются только изменения таблицы A.
Кумулятивный экспорт
ЭКСПОРТИРУЮТСЯ ЛИШЬ ТЕ ДАННЫЕ, КОТОРЫЕ ИЗМЕНИЛИСЬ СО ВРЕМЕНИ
ПОСЛЕДНЕГО КУМУЛЯТИВНОГО ЭКСПОРТА. Выполняйте этот тип экспорта
реже, например, раз в неделю, чтобы суммировать информацию,
содержащуюся в нескольких инкрементальных экспортах.
Например, если существуют таблицы A, B и C, и после последнего
инкрементального экспорта были модифицированы лишь данные в
таблицах A и B, то экспортируются только изменения в таблицах A
и B.
Полный экспорт
ЭКСПОРТИРУЕТСЯ ВСЯ БАЗА ДАННЫХ. Выполняйте этот тип экспорта
наиболее редко, например, раз в месяц, чтобы получить копию всей
информации базы данных.
Использование импорта
---------------------
Утилита импорта позволяет вам восстанавливать информацию базы
данных, хранящуюся в ранее созданных экспортных файлах. Она
выступает как дополнение к утилите экспорта.
Для восстановления базы данных с помощью экспортных файлов и
утилиты импорта требуются следующие операции:
1. Создайте заново структуру базы данных, включая:
18-18 Руководство администратора
* все табличные пространства
* всех пользователей
Замечание: Эти вновь созданные структуры не должны содержать
никаких объектов.
2. Импортируйте соответствующие экспортные файлы, чтобы
реставрировать базу данных в максимально последнее состояние.
В зависимости от того, какой график экспорта у вас был
принят, для реставрации базы данных может потребоваться
импорт различных типов экспортных файлов.
Например, предположим, что для экспорта данных из базы данных
ORACLE используется график, показанный на рис.18-3.
Рис.18-3
Типичный график экспорта
День
1 2 3 4 5 6 7 8 9 10
+----+----+----+----+----+----+----+----+----+-------
F I I I I I C I I I
Тип
экспорта
I = инкрементальный
C = кумулятивный
F = полный
Полный экспорт был выполнен в день 1, кумулятивный экспорт
выполнялся каждую неделю, а инкрементальный экспорт - каждый
день.
Чтобы восстановиться после сбоя диска, который произошел (после
регулярного ежедневного экспорта) в день 10, выполните следующие
шаги:
1. Пересоздайте базу данных, включая все табличные пространства
и всех пользователей.
2. Импортируйте полный экспортный файл, созданный в день 1.
3. Импортируйте кумулятивный экспортный файл, созданный в день
7.
4. Импортируйте инерементальные экспортные файлы, созданные в
дни 8, 9 и 10.