|
|
ЧАСТЬ III ФУНКЦИИ АДМИНИСТРАТОРА БАЗЫ ДАННЫХ
ГЛАВА 13 ПЕРВОНАЧАЛЬНОЕ СОЗДАНИЕ БАЗЫ ДАННЫХ
В этой главе описывается, как создавать базу данных. Перед обращением к
базе ее необходимо "создать". Создание базы означает ее подготовку для
использования системой ORACLE и включает в себя:
* инсталяцию программного обеспечения ORACLE RDBMS (если оно еще не установлено
* создание новых файлов (или очистка существующих от всех предшествующих
данных)
* запись в файлы первоначальной информации
* регистрация начальных пользователей базы.
Замечание: Вследствие того, что содержащаяся в этой главе ин- формация
применима ко всем операционным системам, она будет представлена
достаточно обще. "Руководство пользователя по инс- таляции" является основным
источником информации по этой теме. Если Вы уже реально инсталировали и
создавали базу, то можете проделать это, воспользовавшись указанным
документом.
Кроме того, Вы должны свободно владеть информацией, описанной в Главе 14
"Старт и остановка базы", чтобы хорошо понимать правила и опции запуска и
остановки экземпляра ORACLE, открытия базы, а также использования файла
начальных параметров запуска, обычно называемого INIT.ORA.
Заметьте также, что создание базы совсем не обязательно при переходе от
одной версии ORACLE RDBMS к другой.
Что означает "создание базы" ?
Перед тем, как начать использоваться прикладными программами, база должна
быть создана. При создании подготавливаются некоторые файлы операционной
системы так, чтобы он могли работать как база ORACLE. Независимо от того,
какое количество файлов будет содержаться в базе и сколько экземпляров ORACLE
будет с ними работать, база создается лишь однажды. Если в существующей базе
исполняется оператор CREATE DATABASE, информация, существовавшая в базе до
этого, теряется.
Процесс создания либо создает новые файлы базы, либо удаляет данные,
существовавшие в предыдущем файле (файлах) и записывает туда начальные данные,
необходимые для нормальной работы базы. При создании базы также создаются
управляющие файлы и файлы журнала регистрации изменений.
Реальное создание базы осуществляется по команде CREATE DATABASE,
однако до этого DBA должен выполнить некоторые предварительные действия,
описанные в следующих разделах.
Этапы создания базы
Основные действия по созданию базы следующие. Они зависят от операционной
системы, в среде которой создается база и выполняются специфичными для каждой
операционной системы способами. Процедура инсталяции для данной операционной
системы может выполнит за Вас большинство из этих шагов.
-- 129 --
Заметьте, что создание базы влечет за собой создание и инициализацию нескольких
файлов. В то время как в одних операционных системах создание и инициализация
файлов выполняется автоматически, в других операционных системах DBA первым
шагом по созданию базы должен выполнить создание или распределение этих файлов.
Посмотрите рекомендуемую процедуру в "Руководстве пользователя по инсталяции"
для Вашей операционной системы. Если Вы должны создать файлы вручную, сделайте
это перед выдачей CREATE DATABASE с использованием опции REUSE для управляющих
файлов, файлов базы и файлов журнала.
1. Зарегистрируйтесь в операционной системе с учетным номером, требуемым для
инсталяции ORACLE.
Предполагается, что этот учетный номер принадлежит DBA и имеет достаточные
в данной системе привилегии и права для использования команд утилиты SQL*DBA,
включая привилегированные команды (См. Приложение В). Требуемые привилегии для
операционной системы Вы найдете в "Руководстве пользователя по инсталяции".
2. Проверьте файл INIT.ORA. Проверьте как имена, так и значения используемых
параметров.
Вы можете выбрать между использованием умалчиваемым файлом INIT.ORA,
входящим в комплект поставки, или скопировать его и затем отредактировать в
соответствии с местными требованиями. Если Вы не пользуетесь умалчиваемым
файлом, удостоверьтесь, что его имя правильно указано в необязательном
аргументе PFILE команды STARTUP.
Затем проверьте значения параметров. Некоторые из этих параметров критичны при
создании базы, некоторые - не могут быть изменены без повторного создания
базы. Вам необходимо проверить, что:
* в параметре DB_NAME указано имя базы, состоящее из 8 или менее
символов. Хотя имя базы и не является обязательным, наиболее удобно выбрать
его именно в этом месте. Имя базы используется также в SQL - операторах CREATE
и ALTER DATABASE, а также команде STARTUP утилиты SQL*DBA.
* значения параметров MAXDATAFILES, MAXLOGFILES и MAXINSTANCES отражают
будущие запросы базы.
* параметр DB_BLOCK_SIZE указан правильно. Умалчиваемое значение равно
2048 или 4096 байтов в зависимости от операционной системы. Этот параметр
нельзя менять только вместе с повторным созданием базы.
* параметр CONTROL_FILES указывает имена управляющих файлов. Он может
содержать либо имена вновь создаваемых файлов, либо уже существующих,
информация в которых будет переписана. Во втором случае используйте опцию
CONTROLFILE REUSE оператора CREATE DATABASE.
Oracle Corporation рекомендует использовать как минимум два управляющих
файла, расположенных на разных устройствах.
* INIT_SQL_FILES указывает на файлы, которые будут выполняться для создания
словаря данных и первичных объектов базы. Умалчиваемые значения зависят от
операционной системы и не должны меняться (за исключением добавления
зависящих от местных условий усовершенствований словаря)
Детальное описание параметров файла INIT.ORA приведено в Приложении D.
3. Убедитесь, что умалчиваемый экземпляр ORACLE корректен.
-- 130 --
Если Вы инсталируете свою первую базу, этот шаг наименее критичен.
Однако, если у Вас уже есть работающая система ORACLE, это важно, так как
надо либо опустить оператор CREATE DATABASE, либо данные будут потеряны.
Обратитесь к "Руководству пользовате ля по инсталяции" за справкой, как
идентифицируются экземпляры ORACLE и как они отличаются друг от друга дабы
убедиться, что Ваша база и экземпляр установлены надлежащим образом.
4. Вызовите утилиту SQL*DBA, выдав команду SQLDBA.
В большинстве операционных систем SQL*DBA вызывается именно таким образом.
5. Стартуйте экземпляр ORACLE.
С этой целью используйте команду утилиты SQL*DBA. Полный синтаксис этой команды
приведен в Приложении В.
SQLDBA> STARTUP NOMOUNT PFILE=filename
Заметьте, что в этом месте не применимы значения OPEN и MOUNT.
6. Свяжитесь с базой, используя ключевое слово INTERNAL.
SQLDBA> CONNECT INTERNAL
Ключевое слово INTERNAL используется для связи с базой и при этом обходится
механизм проверки имени пользователя RDBMS. В данный момент база еще не создана
(и, следовательно, словарь данных не содержит имен пользователей), так что
INTERNAL - это возможность соединиться с не готовой еще базой. SQL*DBA
проверяет, что Ваш учетный номер или идентификатор пользователя в операционной
системе имеет достаточные привилегии для регистрации с ключевым словом
INTERNAL. Для более подробной информации по использованию INTERNAL смотрите
Главу 2.
7. Создайте новую базу данных.
Введите SQL - оператор CREATE DATABASE. Если Вам надо создать файлы базы
вручную, сделайте это, а затем выполните создание с использованием опции
REUSE для управляющих файлов, файлов базы и файлов журнала. Полный синтаксис
этого оператора описывается в Приложении G.
CREATE DATABASE имя_базы
[ CONTROLFILE REUSE ]
[ LOGFILE файл [, файл] ...]
[ MAXLOGFILES целое ]
[ DATAFILE файл [, файл] ...]
[ MAXDATAFILES целое ]
[ MAXINTANCES целое ]
[ ARCHIVELOG | NOARCHIVELOG ]
[ SHARED | EXCLUSIVE ]
Все аргумента необязательны и в случае отсутствия применяется умалчиваемое
значение. Для определения значения "файл" обратитесь к руководству по
инсталяции. Возможно Вам покажется более удобным разместить оператор CREATE
DATABASE в файле, например - "CRDB. SQL" и запустить его из SQL*DBA
следующим образом:
SQLDBA> @CRDB
-- 131 --
Этот шаг потребует больше времени, чем предыдущие, так как выполняет
множество операций. После завершения этих шагов можно выйти из SQL*DBA. База
создана, смонтирована, открыта и готова для нормальной работы.
Хотя Вы и можете использовать аргумент ARCHIVELOG в операторе CREATE DATABASE
для создания базы в режиме ARCHIVELOG, это потребует дополнительного заголовка
и места в файле регистрации изменений для регистрации стандартных шагов по
подготовке базы (таких как создание и загрузка словаря данных). Если Вы хотите
пользоваться базой в режиме ARCHIVELOG (См. Главу 15, где описаны оба этих
режима), более эффективно создать базу в режиме NOARCHIVELOG, а
затем использовать оператор ALTER DATABASE для изменения режима на
ARCHIVELOG.
Если Вы все же решили создавать базу в режиме ARCHIVELOG, перед вводом
команды CREATE измените параметр LOG_ARCHIVE_START файла INIT.ORA на значение
"true".
Что делает оператор CREATE DATABASE ?
После того как CREATE DATABASE получит необходимую информацию, он выполняет
следующие шаги по созданию базы (хотя не обязательно - в указанном порядке).
При создании базы создаются следующие файлы операционной системы:
управляющие файлы Создается столько, сколько указано в файле INIT.ORA,
причем все с идентичным содержанием. Эти файлы не
должны ни меняться, ни удаляться. Использование
нескольких файлов предохраняет от потери всех их сразу.
файл(ы) базы Создается столько, сколько указано в операторе CREATE
DATABASE; все они яв- ляются частями табличного
простран- ства SYSTEM. Если не указан их размер,
берется умолчание операционной системы.
файлы журнала по- Создается столько, сколько указано в вторного
выполнения операторе CREATE DATABASE (должно быть как минимум - два ).
Если не указан их размер, берется умолчание
операционной системы. Эти файлы становятся активными
файлами журнала.
Затем выполняется подготовка базы:
* создается сегмент отката SYSTEM в табличном пространстве SYSTEM
* в табличном пространстве SYSTEM создается и загружается словарь
данных. Его владелец - пользователь SYS. Для создания выполняются операторы
SQL, содержащиеся в файлах, указанных в параметре INIT_SQL_FILES файла INIT.ORA.
* монтируется и открывается база как если бы выполнились операторы ALTER
DATABASE ... MOUNT и ALTER DATABASE ... OPEN.
В зависимости от операционной системы эти шаги либо выполняются
автоматически, либо в отдельных шагах процесса инсталяции.
После создания базы ...
После завершения процесса инсталяции экземпляр остается работающим, а база
открытой и доступной для дальнейшего использования. Теперь при работе с
базой Вы должны использовать команды STARTUP и SHUTDOWN утилиты SQL*DBA для
соответственно старта и остановки системы.
-- 132 --
Если Вы планируете инсталировать другие продукты фирмы ORACLE для работы с
этой базой, обратитесь к инсталяционной документации по соответствующим
продуктам. Некоторые из них требуют создания дополнительных таблиц в словаре
данных. Обратитесь к "Руководству пользователя по инсталяции" для ссылок к
данным продуктам. Обычно для создания этих таблиц используются специальные
командные файлы.
Дистрибутивный носитель может содержать различные SQL - файлы, которые можно
выполнить для экспериментов по системе, обучению SQL или для создания
дополнительных таблиц, обзоров и синонимов.
Вновь созданная база имеет только двух пользователей: SYS и SYSTEM. Пароли
для этих пользователей с привилегиями DBA должны быть изменены сразу же по
создании базы (См. Главу 2). В любой момент Вы можете зарегистрировать
новых пользователей как с привилегиями DBA, так и без них.
ГЛАВА 14 СТАРТ И ОСТАНОВКА БАЗЫ
В этой главе описывается использование программы SQL*DBA для запуска и
остановки СУБД ORACLE. В ней предполагается, что база уже создана с помощью
SQL - оператора CREATE DATABASE (если - нет, вернитесь к Главе 13). Информация
этой главы относится толь- ко к администратору базы данных (DBA) и содержит:
* старт и остановку экземпляров
* монтирование и открытие баз
* закрытие и размонтирование баз
* опции, доступные при старте систем
* файл INIT.ORA, его параметры и как они используются для управления и
оптимизации работы системы.
Кроме того, Вам будут полезны следующие разделы этой книги:
* Глава 13 Первоначальное создание базы
* Приложение В Справочник команд SQL*DBA
* Приложение D Справочник параметров файла INIT.ORA
* Руководства пользователя по инсталяции.
Понятия старта и остановки
Система ORACLE не обязательно работает все время, пока работает операционная
система и не стартует автоматически при старте операционной системы, если это
специальным образом не указано. Обычно база запускается и останавливается
DBA. Системой ORACLE можно управлять как в процессе работы, так и указывать
некоторые опции при старте и остановке системы.
Программа SQL*DBA используется для старта и остановки системы ORACLE, а также
для выполнения настройки и мониторинга базы, например - начальное создание
базы, резервное копирование данных и их восстановление. Инструкции по
использованию SQL*DBA и справочник команд SQL*DBA находятся в Приложении В.
Для старта системы ORACLE требуются три шага:
1. Старт экземпляра ORACLE.
2. Монтирование базы данных.
3. Открытие базы данных.
Аналогично и для остановки базы требуется три шага:
1. Закрытие базы данных.
2. Размонтирование базы данных.
3. Остановка экземпляра ORACLE.
-- 133 --
Заметьте, что в системе базы данных скомбинировано два потенциально независимых
элемента: база данных и экземпляр. Эти термины введены в Главе 1.
Каждый раз при старте экземпляра ORACLE последний считывает файл параметров
(обычно называемый INIT.ORA). Затем, основываясь на значениях считанных
параметров, ORACLE создает SGA, которая будет связана с данным экземпляром
столько, сколько он будет существовать. Далее работающий экземпляр может
монтировать и открыть базу данных.
Существует опция, позволяющая Вам стартовать экземпляр в режиме DBA, что дает
возможность работать с базой только пользователям, имеющим соответствующую
привилегию.
Монтированные и открытые базы
Базы данных существуют независимо от экземпляров, но для доступа к данным
должны быть переведены в online экземпляром ORACLE. Для перевода базы в
состояние online требуется два шага: монтирование и открытие. Чтобы быть
открытой, база должна быть смонтирована, но она может быть смонтирована и без от
Размонтированная В данный момент база не связана ни с каким экземпляром.
Она не доступна пользователям или DBA, пока не будет
каким-либо экземпляром ORACLE.
Монтированная, но База связана с экземпляром ORACLE, но дос-
не открытая тупна только DBA для определенных целей, связанных с
настройкой. Она не доступна для обычных пользовательских
операций. База мо- жет быть монтирована в разделяемом или
исключительном режимах; разделяемый режим требуется для
базы, которая будет разделяться между несколькими
экземплярами ORACLE - в системах, разделяющих диск.
База данных должна быть монтирована, но не открыта для
выполнения DBA следующих функций:
* удаление, добавление или переименование файла
регистрации изменений
* включение или выключение архивирования журнала с
целью восстановления носителя (переключение между режимами
ARCHIVELOG и NOARCHIVELOG)
* выполнение восстановления носителя базы (восстановление
содержимого базы с backup - копии)
Открытая Когда база открыта, он также и монтирована. Она доступна
для выполнения нормальных базовых операций. Вопрос о том,
монтирована база или открыта, касается только DBA. Если
пользователь связан с базой, она уже открыта (и,
следовательно, монтирована).
DBA управляет состояниями баз данных с помощью команд
STARTUP и SHUTDOWN программы SQL*DBA, также SQL-оператора
ALTER DATABASE (с опциями OPEN, CLOSE, MOUNT, DISMOUNT).
Программа SQL*DBA
-- 134 --
SQL*DBA - это интерактивное инструментальное средство, используемое DBA
(обычно через учетный номер ORACLE) для выполнения следующих функций:
* старта экземпляра ORACLE
* остановки экземпляра
* открытия базы
* старта экземпляра с возможностью доступа только для DBA
* выполнения любого SQL - оператора
* мониторинга текущей работы базы (См. Главу 12 и Прилож. В)
* выполнения backup данных базы (См. Главу 15)
* выполнения восстановления данных базы (См. Главу 15)
Любая из перечисленных операций может быть выполнена как с локальной,
так и с удаленной базой. Эта глава описывает использование SQL*DBA для старта
и остановки экземпляра ORACLE. Приложение В описывает вызов SQL*DBA и описание
Доступ к SQL*DBA
Так как некоторые функции, вызываемые программой SQL*DBA, при неправильном
обращении могут представлять опасность для базы, к ее использованию должен
быть допущен весьма ограниченный круг лиц. Основным пользователем этой
программы обычно является DBA.
Некоторые команды SQL*DBA являются системными привилегированными и требуют
специального доступа. К ним относятся следующие:
STARTUP
SHUTDOWN
CONNECT INTERNAL
Если пользователь выдал одну из этих команд, SQL*DBA проверяет его системные
привилегии на соответствие и решает вопрос о продолжении работы. Заметьте,
что SQL*DBA не проверяет имя пользователя в системе ORACLE, которое и не
вводится. Вместо этого он проверяет привилегии пользователя, вызвавшего
SQL*DBA.
Обычные пользователи имеют доступ к SQL*DBA постольку, поскольку они имеют
права доступа к привилегированным системным командам. Управление доступом к
SQL*DBA обсуждается в "Руководстве пользователя по инсталяции".
Старт экземпляра ORACLE и базы данных
Команда STARTUP утилиты SQL*DBA удобно объединяет в себе все три шага старта
базы:
SQLDBA> STARTUP OPEN dbname
Однако, иногда желательно выполнить эти шаги отдельно:
1. Старт экземпляра с помощью команды STARTUP программы SQL*DBA.
2. Монтирование базы, используя SQL - оператор ALTER DATABASE.
3. Открытие базы с помощью SQL - оператора ALTER DATABASE.
Ниже описаны различные методы старта.
Старт с открытием базы
Как только что упоминалось, для старта текущего экземпляра, монтирования
и открытия базы можно ввести единственную команду:
-- 135 --
SQLDBA> STARTUP OPEN dbname
где
dbname - имя базы, которая должна быть открыта. Если имя базы указано в
параметре DB_NAME файла INIT.ORA, можно просто ввести:
SQLDBA> STARTUP OPEN
База с указанным именем должна быть уже создана. (Предполагается, что будет
указан идентификатор экземпляра; метод указания варьируется от системы к
системе и описан в "Руководстве пользователя по инсталяции").
Команда STARTUP, использующая опцию OPEN:
1. Стартует экземпляр ORACLE:
* создает и инициализирует SGA, используя параметры текущего файла
INIT.ORA
* стартует фоновые процессы
2. Монтирует поименованную базу:
* находит и открывает управляющие файлы
3. Открывает монтированную базу:
* находит и открывает файлы журнала повторного выполнения и активные
(online) файлы базы
* если требуется, выполняет "откат вперед" (на основании журнала
повторного выполнения)
* включает журнал повторного выполнения
* если требуется, выполняет "откат назад" (транзакции).
Когда восстановление закончится, база будет открыта и готова для работы
пользователей.
Приведем пример:
SQLDBA> STARTUP
ORACLE instance started.
Database mounted.
Database opened.
Total System Global Area 372520 bytes
Fixed Size 12312 bytes
Variable Size 286480 bytes
Database Buffers 65536 bytes
Redo Buffers 8192 bytes
Обратите внимание, что во время старта указывается размер SGA
Монтирование и открытие базы в несколько этапов
Вы можете захотеть стартовать экземпляр ORACLE без монтирования и открытия
базы, чтобы выполнить эти шаги отдельно. Это может потребоваться при выполнении
настроечных функций. Следующая последовательность шагов описывает раздельный
старт. Обычно, в зависимости от намерений, DBA дополнительно выполняет некоторые
1. Сперва стартуем экземпляр:
SQLDBA> STARTUP NOMOUNT
2. Для монтирования базы надо присоединиться как INTERNAL:
SQLDBA> CONNECT INTERNAL
3. Монтируем базу. В этот момент необходимо указать имя базы.
SQLDBA> ALTER DATABASE dbname MOUNT
-- 136 --
4. Открываем базу. Нет необходимости указывать имя базы так как
предполагается монтированная. SQLDBA> ALTER DATABASE OPEN
Старт базы только для работы DBA
Доступ к базе может быть ограничен только DBA. Например, если Вам необходимо
удалить файл регистрации изменений или изменить параметры файла INIT.ORA,
можно остановить базу во время малой ее активности и выполнить требуемые
действия.
Чтобы стартовать базу с доступом только DBA, введите:
SQLDBA> STARTUP DBA OPEN dbname
Если Вам надо вновь разрешить доступ остальным пользователям, остановите базу и
стартуйте ее без опции DBA.
Старт базы с опцией FORCE
Воспользуйтесь этой опцией, если хотите остановить экземпляр аналогично опции
SHUTDOWN ABORT и рестартовать его. Эта опция используется редко, но
применима для быстрого останова и рестарта экземпляра одной командой.
Старт базы с выведенными в offline табличными пространствами
При старте базы все табличные пространства находятся в состояниях online
или offline, в зависимости от их состояния на момент последнего останова базы.
Табличные пространства могут быть переведены в offline и после открытия базы с
помощью SQL - оператора:
ALTER TABLESPACE tablespace OFFLINE [ NORMAL | IMMEDIATE ]
Для более полного описания этой команды обратитесь к Главе 16 и Приложению
В. Для подробной информации о переводе табличных пространств в состояние
offline смотрите Главу 4.
Чтобы вновь перевести пространство в online , введите:
ALTER TABLESPACE tablespace ONLINE
Автоматический старт базы в процессе загрузки операционной системы
Во многих местах используют процедуры автоматического старта одного или
нескольких экземпляров ORACLE в процессе старта операционной системы.
Процедуры зависят от операционной системы. Для детальной информации обратитесь
к своему "Руководству пользователя по инсталяции".
Старт удаленных экземпляров ORACLE
Процедуры старта и остановки удаленных экземпляров очень сильно
зависят от протоколов связи и операционных систем. Далее следуют достаточно
общие правила (базирующиеся на VMS) старта удаленного экземпляра ORACLE.
1. В удаленном узле создайте файл для установки правильной конфигурации
файлов базы (чтобы указать на правильный (е) управляющий файл, файлы базы,
журнала повторного выполнения и INIT.ORA).
-- 137 --
2. В локальном узле определите строку для драйвера для удаленной
регистрации пользователя (login). Удаленный пользователь должен иметь
соответствующие привилегии в локальном узле для старта базы. SQL*Net
зарегистрируется на удаленном узле с помощью этого учетного номера и выполнит
файл, созданный в шаге 1 для указания на правильную базу.
3. Начните сеанс SQL*DBA в локальном узле.
4. Воспользуйтесь командой SET INSTANCE утилиты SQL*DBA с драйвером,
определенном на шаге 2:
SQLDBA> SET INSTANCE driverstring
5. Для старта базы введите команду STARTUP:
SQLDBA> STARTUP ....
Если Вы не укажете удаленный файл INIT.ORA, будет использоваться локальный.
6. Для остановки удаленного экземпляра просто введите команду:
SQLDBA> SHUTDOWN
Файл параметров INIT.ORA
Каждый раз при старте администратором экземпляра ORACLE он использует набор
параметров, определяющих характеристики работы этого экземпляра. Параметры
находятся в файле, обычно называемом INIT.ORA ( или вариацией вроде:
INITdbname.ORA).
Файл INIT.ORA содержит различные типы параметров, наиболее важные из которых
непосредственно влияют на производительность системы ORACLE. К примеру, он
содержит значения параметров, необходимых непосредственно для старта
экземпляра ORACLE ( имена управляющих файлов) или параметры, устанавливающие
размер различных элементов SGA. Модифицируя последние параметры, можно
увеличивать или уменьшать размер SGA (оперативную память) и этим влиять на
производительность системы ORACLE.
Использование альтернативных имен для INIT.ORA
Файл параметров не обязательно должен называться INIT.ORA. Если его
имя отличается от принятого по умолчанию, необходимо указать его при старте
в аргументе PFILE, например:
SQLDBA> STARTUP PFILE=OURPARM.ORA
Ожидаемое местонахождение этого файла зависит от операционной системы
(обратитесь к "Руководству пользователя по инсталяции" для Вашей операционной
системы). В нашем руководстве мы используем имя INIT.ORA, хотя возможно и
другое имя.
Пример файла INIT.ORA
Пример файла INIT.ORA включен в дистрибутивный носитель системы ORACLE. Он
содержит параметры, применимые к большинству первичных инсталяций базы данных
ORACLE. После того, как Ваша система некоторое время поработает и Вы
приобретете некоторый опыт, то возможно захотите поэкспериментировать с
параметрами файла INIT.ORA. Пример INIT.ORA показан на рисунке 14-1.
-- 138 --
db_name=PRODDB
log_checkpoint_interval = 1000
row_coche_enqueues = 200
sessions = 50
calls = 50
processes = 50
ddl_locks = 200
dml_locks = 200
control_files = disk$dev2:[oracle]controll.ora
Рисунок 14-1 Список параметров INIT.ORA для системы DEC VAX/VMS.
Группы параметров INIT.ORA
Каждый параметр файла INIT.ORA индивидуально описывается в Приложении D.
Большинство параметров INIT.ORA попадают в одну из следующих групп:
* параметры, именующие объекты (например - файлы)
* параметры, устанавливающие ограничения ( максимальные зна- чения)
* параметры, влияющие на объем, называемые еще переменными параметрами.
Последние параметры обычно находятся в ведении DBA, так как непосредственно
связаны с производительностью и являются наиболее гибкими.
Зачем надо менять параметры ?
Параметры можно менять с целью увеличения производительности системы ORACLE.
Какой в точности параметр в наибольшей степени влияет на производительность
Вшей системы - зависит от большого числа характеристик базы. Существует
множество методов улучшения схем данных, разработки приложений, параметров
операционной системы. Они описаны в этом и других документах по системе
ORACLE. Как и при настройке операционной системы, перед изменением параметров
необходимо измерить текущую производительность, осмыслить значение изменяемого
параметра, ожидаемый результат, а затем измерить этот результат, чтобы
оценить, что же достигнуто.
Дополнительные предложения по настройке базы ORACLE можно отыскать в Главе
20. Обратитесь также к "Руководству пользователя по инсталяции" за
системозависимыми рекомендациями по настройке.
Остановка экземпляра ORACLE и базы
Остановка системы ORACLE включает в себя следующие шаги:
1. Закрытие базы с помощью SQL - оператора ALTER DATABASE.
2. Размонтирование базы с помощью SQL - оператора ALTER DATABASE.
3. Остановка экземпляра ORACLE командой SHUTDOWN утилиты SQL*DBA.
Используя опции команды SHUTDOWN, можно объединить эти шаги в один.
Нормальная остановка
Наиболее общий метод остановки экземпляра ORACLE - это выдача
SQLDBA> SHUTDOWN [NORMAL]
-- 139 --
Вы дача SHUTDOWN без опций аналогична SHUTDOWN NORMAL. Этот тип останова:
* ожидает отсоединения текущих пользователей
* запрещает новые соединения
* закрывает и размонтирует базу
* останавливает экземпляр ORACLE.
Старт после нормальной остановки не требует восстановления
экземпляра (rollforward - вперед и rollback - назад).
Если SHUTDOWN NORMAL не работает из-за возникших в базе проблем, можно
использовать более жесткую команду SHUTDOWN.
SHUTDOWN IMMEDIATE
Этот вариант останова должен использоваться, если Вы не хотите ждать
отключения пользователей базы:
SQLDBA> SHUTDOWN IMMEDIATE
Ввод этой команды аналогичен SHUTDOWN NORMAL за исключением:
* текущие вызовы завершаются как при системном прерывании
* не ожидается отсоединения текущих пользователей базы.
Фоновый процесс PMON терминирует все текущие сеансы пользователей, выполняя
rollback (откат), а база закрывается и размонтируется. Прикладные программы
получают сообщение об ошибке, которые могут быть обработаны любым
приемлемым для приложения способом.
Старт после SHUTDOWN IMMEDIATE не требует восстановления экземпляра
(rollforward и rollback).
SHUTDOWN ABORT
SHUTDOWN ABORT - наиболее крутой и быстрый из доступных способов остановки.
Он не ожидает завершения текущих вызовов и соединений, но зато останавливает
экземпляр ORACLE так быстро, как только возможно.
SHUTDOWN ABORT должен выполняться, только если все другие способы остановки
не получились и экземпляр работает неправильно. Если SHUTDOWN [NORMAL] не
сработал, обязательно попробуйте выполнить SHUTDOWN IMMEDIATE перед выполнением
ABORT.
Старт системы после выполнения SHUTDOWN ABORT при необходимости будет
выполнять восстановление экземпляра (rollforward и rollback).
ГЛАВА 15 КОПИРОВАНИЕ И ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ
В этой главе описываются следующие вопросы, связанные с резервным
копированием (backup) и восстановлением (recovery):
* типы отказов, требующие восстановления
* возможности ORACLE RDBMS по копированию/восстановлению данных
* подготовка к восстановлению с помощью различных типов копирования
* использование режимов работы базы ARCHIVELOG и NOARCHIVELOG
* восстановление при различных видах отказов
* использование команд SQL*DBA ARCHIVE и RECOVER
* роль утилит Export/Import в стратегии копирования
* советы по выбору стратегии восстановления
-- 140 --
Кроме того, полезную информацию можно найти в следующих документах:
* Главе 3 - Файловая структура, описание журнала повторного выполнения.
* Главе 4 - Табличные пространства и сегменты, описание сег- ментов отката
* Руководство пользователя по инсталяции содержит детальную информацию по
копированию и восстановлению с помощью системных средств файлов
регистрации изменений
* Руководство пользователя по утилтитам ORACLE описывает утилиты Export и
Import.
* В Главе 21 описываются дополнительные требования по восстановлению в
разделяемой дисковой системе.
Различные типы отказов требуют особых мер предосторожности или шагов
восстановления. В этой главе оцениваются преимущества отдельных способов
защиты от возможных отказов и соответствующие трудозатраты по их выполнению.
ORACLE имеет утилиты, специально предназначенные для копирования и восстанов-
ления своих данных. Некоторые из них используют в своей работе стандартные
средства операционной системы или третьих продуктов, например - полное
копирование диска.
Почему восстановление столь важно ?
Основная забота DBA - подготовиться к возможному отказу системы. В случае
возникновения отказа база должна быть восстановлена быстро и с минимально
возможными потерями пользователей.
При любом отказе восстановление требует от DBA :
* определения, какие структуры базы затронуты и требуют восс- тановления
* выполнения соответствующих шагов по восстановлению
* рестарта экземпляра для восстановления его нормальной работоспособности
* убедиться, что никакая работа не пропала или в базе не остались
некорректные данные
Цель этого - вернуться к нормальной работе возможно быстрее и в то же время -
уберечь пользователей базы от любых проблем, связанных с возможными потерями
и дублированием работы.
Процесс восстановления зависит от типа отказа и размеров части базы, на
которую отказ повлиял. Если файлы базы не пострадали, восстановление может
свестись к простому рестарту экземпляра ORACLE.
Вы, как администратор, должны предвидеть любой тип отказа и иметь
наготове стратегию восстановления. При выборе стратегии восстановления
необходимо исходить из альтернативы, связанной с "восстановимостью" и
затратами на защиту. В общем случае, чем большая гарантия защиты, тем
больше затраты на ее реализацию со стороны DBA.
Особенности восстановления системы ORACLE
Система ORACLE предоставляет целый ряд возможностей для обеспечения гибкой
системы восстановления:
* восстановление при отказе системы, аппаратуры или программного обеспечения
* автоматическое восстановление экземпляра ORACLE при старте базы
* неавтономное копирование и восстановление одиночных табличных пространств или
файлов в момент малой загрузки базы
* необязательное средство защиты восстановления
* минимальные дополнительные административные задачи для под- готовки к отказам
-- 141 --
оборудования
* в случае отказа системы - улучшенное управление восстановлением
* экспорт и импорт в целях архивации и восстановления данных
Типы отказов, требующие восстановления
Некоторые обстоятельства могут повлечь остановку экземпляра ORACLE или
помешать записи данных в базу. Примерами могут служить ошибки обращения к
дискам, содержащим файлы базы или ошибки операционной системы при обращении
к файлам, содержащим программы системы ORACLE.
Ниже приводятся некоторые типы отказов. В некоторых случаях восстановление
выполняется автоматически или требует минимальных действий со стороны
пользователей или DBA.
Пользовательские ошибки
Для предупреждения ошибки пользователя администратор может предпринять
минимальные действия, но схема восстановления будет весьма эффективной.
Например, в случае дополнительного копирования в ночное время удаленная днем
таблиц пользователя может быть легко восстановлена. В большинстве случаев
такие ошибки могут быть минимизированы с помощью обучения работы с базой и
прикладными программами.
Ошибка оператора SQL
Такая ошибка возникает при ошибке в логическом применении SQL - оператора.
Система ORACLE или прикладная программа возвратят код ошибки или соответствую-
щее сообщение. Обычно ошибки такого рода не требуют со стороны DBA никаких
действий.
В случае ошибки SQL - оператора его результат автоматически откатывается
еще до возврата управления пользователю или его программе. В зависимости
от ситуации программа пользователя может либо сама обрабатывать определенные
ошибки, либо пользователь сам выполнит команду, исправляющую ошибку.
Иногда однако требуется вмешательство DBA по увеличению системных ресурсов
(модификация параметров файла INIT.ORA) в случае, когда ошибка повторяется.
Ошибка процесса
Ошибка процесса - это ненормальное завершение пользовательского процесса
(например - ошибочное отключение, завершение или ошибка адресации).
Процесс не может продолжать работу, в то время как экземпляр - может.
Фоновый процесс системы ORACLE PMON обнаруживает аварийный процесс и
решает проблему путем отката транзакции этого процесса и освобождения всех
используемых ресурсов. Эти действия выполняются автоматически и не требуют
вмешательства администратора базы.
Ошибка экземпляра ORACLE
Ошибка такого рода возникает, когда некая проблема не позволяет экземпляру
ORACLE продолжать работу. Она может быть связана как с ошибками оборудования,
например - отсутствием питания, или ошибками программного обеспечения, например
- операционной системы. Такая ошибка может также произойти из-за отказов в
системе ORACLE. Наиболее общий признак этой ошибки - ненормальное завершение
одного или нескольких фоновых процессов системы ORACLE (DBWR, LGWR, ARCH,
SMON или PMON).
-- 142 --
Ошибка экземпляра требует его восстановления. Это может потребовать действий
со стороны DBA, но обычно выполняется автоматически с помощью файлов,
находящихся на диске.
Если аварийно завершилась система, не разделяющая диск или для разделяемой
системы - все экземпляры, DBA должен выполнить только остановку и старт
экземпляра. Восстановление экземпляра выполняется автоматически во время старта
Если ошибка произошла в системе, разделяющей диски, оставшиеся работоспособными
экземпляры выполнят восстановление аварийно закончившегося (См. Главу 21).
Ошибка носителяя
Физическая, невосстановимая ошибка может возникнуть при попытки записи
или чтения файла, требующегося для работы базы. Примером того может служить
поломка головки дискового накопителя, приводящая к потере всех файлов на
носителе. Сбой оборудования может повлиять на различные файлы, включая файлы
базы, журнала и управляющие (связанные с табличным пространством SYSTEM
или иным). Стратегия восстановления в этом случае будет зависеть от того,
какой файл пострадал.
Основные стадии восстановления
Восстановление данных требует двух явных типов действий:
откат вперед для проверки, что подтвержденные и изменив-
(rolling forward) шие данные базы транзакции, записаны в базу. При
необходимости действия транзакций выпол- няются заново.
откат назад для проверки, что транзакции, для которых
(rolling back) был выполнен откат, "удалены" из базы данных в случае
необходимости действия этих тран- закций аннулируются.
Если в процессе работы базы выполнилась транзакция, многие блоки данных
могут быть модифицированы. Наряду с реальными данными RDBMS использует
временные рабочие области, называемые буферным пулом базы. Так как буферы
содержат и записанные, и не записанные данные, они дают пользователю
возможность легче выполнить rollback, а базе - поддерживать множество
параллельных согласованных по чтению обзоров одних и тех же таблиц.
Исходя из того, что число буферов базы ограничено, они используются повторно
и, следовательно, требуют записи на диск своего содержания. Для уменьшения
числа буферов они записываются на диск на основании алгоритма "Least
recently used" - "Удаление стариков" (LRU). Буферы, не использовавшиеся
наиболее долго, записываются в базу.
Таким образом, наиболее часто используемые блоки находятся в буферах базы
(независимо от того, выполнена ли для них операция commit). И наоборот,
наименее часто используемые блоки записываются в базу независимо от проведения
операции commit.
При нормальном завершении транзакции (commit) записи журнала повторного
выполнения модифицируются синхронно с основными данными. Это означает, что
пользовательская транзакция становится постоянной только благодаря записи в
журнал. Процесс DBWR записывает данные в базу на основании алгоритма LRU.
Нормальное завершение транзакции означает, что все "откаченные" данные стали
не действительными как в буферах, так и в реальных файлах базы.
-- 143 --
Заметьте, что в каждый момент база может содержать некоторые блоки,
модифицированные не записанной транзакцией; это связано с использованием
процессом DBWR алгоритма LRU. И наоборот, в любой момент времени база может НЕ
содержать данных из записанных транзакций. Это связано с тем, что DBWR
работает асинхронно с выполнением операции commit. В результате возможны две
ситуации:
* База может содержать не подтвержденные данные, так как изменения были
внесены в результате работы алгоритма LRU. В случае теплого старта или
восстановления эти данные должны быть удалены.
* Так как модифицированные блоки могли быть не записаны в базу в момент
выполнения commit, а лишь в журнал повторного выполнения, последний может
содержать данные, не присутствующие в базе, но которые должны быть туда
занесены.
Для разрешения этих проблем ORACLE RDBMS использует два типа структур:
Сегменты rollback Эти сегменты используются для отката назад транзакций (не
записанных данных). Описание этих сегментов Вы найдете в
Гл.4.
Журнал повторного Этот журнал используется для отката вперед
выполнения транзакций (подтвержденные, но еще не за- писанные в базу
данные). Обратитесь к Гл.3 за описанием файлов операционной
системы, составляющих журнал; в ней также со- держится
информация о работе этого журнала.
Откат вперед с использованием журнала повторного выполнения
Журнал повторного выполнения представляет собой внешний по отношению к базе
файл операционной системы, в который заносятся ВСЕ изменения базы (записанные,
откаченные или не записанные). В процессе восстановления все изменения из
журнала применяются к базе данных. Повторное выполнение всех ранее проведенных
изменений и называется "откатом вперед".
Откат вперед может выполняться из элементов файлов журнала, находящихся в
состоянии online, а также может потребовать восстановления более старых файлов,
хранящихся на вторичных запоминающих устройствах, обычно - магнитных лентах.
Откат вперед с помощью журнала повторного выполнения как бы перемещает
базу вперед во времени. После отката вперед блоки базы содержит информацию как
записанных транзакций, так и транзакций, находившихся в момент сбоя в процессе
выполнения.
Откат назад с использованием сегментов отката
Откат вперед - это только часть процедуры восстановления; после этого
необходимо отменить все изменения, которые не были подтверждены (commit). Эта
операция выполняется после проведения изменений, связанных с откатом вперед.
Сегменты отката - это часть базы, содержащая информацию, достаточную для
нейтрализации всех не записанных изменений данных. Сегменты отката
используются для обнаружения и отмены транзакций, бывших активными в момент
отказа. Этот процесс называется откатом назад (rolling back).
-- 144 --
(Заметьте, что поскольку сегменты отката являются частью базы, они также
защищены журналом повторного выполнения от сбоев оборудования и будут
восстанавливаться в процессе отката вперед).
Откат назад - это операция, выполняемая автоматически при старте
экземпляра как часть восстановления экземпляра. ORACLE самостоятельно
определяет , какие сегменты отката содержат неподтвержденные данные и от Вас не
требуется каких-либо дополнительных действий для выполнения отката назад.
После выполнения операций над журналом и сегментами отката база
восстановлена в непротиворечивом состоянии.
Восстановление экземпляра
Восстановление экземпляра (если в этом есть необходимость), выполняется
автоматически в момент старта (обычно после SHUTDOWN ABORT и никогда - после
SHUTDOWN IMMEDIATE или NORMAL). Дополнительных действий помимо старта
экземпляра от DBA не требуется.
Кроме того, восстановление экземпляра ORACLE требуется в случае, если он не
может продолжать работу. Приведем наиболее общие причины отказов экземпляра:
* отказ процессора (CPU)
* ошибка или перезагрузка операционной системы
* выключение питания
* ошибка доступа к требуемому файлу базы
* авария одного из фоновых процессов ORACLE
Если Вы определили, что экземпляр приостановил работу, остановите его с
помощью команды SHUTDOWN утилиты SQL*DBA применив опцию IMMEDIATE и при
необходимости - ABORT. (Нормальный SHUTDOWN предпочтительнее, так как требует
меньше времени на восстановление). Затем рестартуйте экземпляр обычным
образом, используя STARTUP. Рестарт экземпляра начинает процесс его
восстановления.
При восстановлении экземпляра база данных приводится к состоянию,
предшествующему отказу. При этом выполняются следующие операции:
* откат вперед с использованием активных (online) файлов журнала регистрации
изменений. Это делается для восстановления подтвержденных данных, не записанных
в базу; для восстановления не записанных транзакций, чьи изменения были
записаны в журнал; и для восстановления содержимого сегментов отката
* используя сегменты отката, откатываются транзакции, для которых либо явно
была выдана команда rollback, либо они не были записаны
* освобождение ресурсов, задержанных транзакциями
Если на практике отказы экземпляра происходят при отказе одного из фоновых
процессов, необходимо изучить дамп файлов, генерируемых этим процессом. Эти
файлы находятся в месте, указанном параметром BACKGROUND_DUMP_DEST файла
INIT.ORA, и могут помочь в выяснении причин отказа.
Восстановление носителя
Ошибки оборудования означают, что файл или устройство не могут быть
прочитаны так как разрушены или отсутствуют. Ошибки при чтении часто бывают
связаны с временными проблемами общесистемного программного обеспечения или
оборудования. В этих случаях восстановление необходимо.
-- 145 --
Следовательно, если Вы выяснили, что файл, связанный с базой разрушен или
отсутствует, необходимо выполнить либо восстановление при ошибках оборудования
либо восстановить базу с ближайшей полной копии (полного экспорта базы или
копии образа базы).
Для выполнения восстановления при ошибках оборудования необходимо:
* иметь резервные копии разрушенных файлов базы
* использовать журнал повторного выполнения в режиме ARCHIVELOG
* иметь архивированные (offline) файлы журнала, начинающиеся
с момента выполнения backup - копии
Восстановление при ошибках оборудования включает те же шаги, что и
восстановление экземпляра (откат вперед и откат назад). Единственная
разница состоит в том, что оно может начаться с более старого момента
времени и потребовать старые (находящиеся в offline) файлы журнала.
Если Вы хотите подготовиться к восстановлению при отказах оборудования
без потерь информации, необходимо работать в режиме ARCHIVELOG и хранить
неактивные файлы журнала. Если Вы согласны повторить работу, сделанную между
точкой backup и отказом оборудования, необходимо восстановить копию базы,
сделанную в момент, когда экземпляр не работал, а затем уже повторить работу.
Ошибки оборудования могут затронуть четыре различных части системы ORACLE:
* файл базы, не принадлежащий табличному пространству SYSTEM
* файл базы, принадлежащий табличному пространству SYSTEM
* активный файл журнала повторного выполнения
* управляющий файл
Процедуры восстановления в этих ситуациях описаны ниже. В простейшем
случае, при потере управляющего файла, его надо просто скопировать. Для первых
двух случаев восстановление заключается в восстановлении табличного
пространства, содержащего этот файл или всей базы. Для восстановления базы на
основании информации файлов журнала повторного выполнения применяется утилита
SQL*DBA.
Полное восстановление базы
Последний тип восстановления - это простое восстановление базы к ее состоянию
на момент полной архивации. В этом случае создается копия всех файлов базы.
Очень полезно бывает при не работающей базе периодически копировать полный
набор файлов базы. Полный backup, выполняемый при не работающей базе, включает
в себя все файлы базы, активные файлы журнала и все управляющие файлы. Такое
восстановление можно выполнить например - при потере файла журнала повторного
выполнения.
Как работает журнал повторного выполнения
Журнал может использоваться в двух режимах: ARCHIVELOG и NOARCHIVELOG.
Этот режим указывается в команде CREATE DATABASE и может быть в любой момент
изменен командой ALTER DATABASE (база должна быть при этом в состоянии
offline).
Все изменения в базе протоколируются независимо от выбранного режима. В
дальнейшем, опять-таки независимо от выбранного режима, эта информация может
быть использована для восстановления экземпляра.
-- 146 --
Для выбора режима Вам надо ответить на следующие вопросы:
* Хотите ли Вы подготовиться к полному восстановлению при отказе оборудования?
* Хотите ли Вы выполнять периодическое копирование online файлов журнала
для обеспечения их постоянной доступности?
* Хотите ли Вы дополнительно отвечать за работу, связанную с архивацией данных
журнала ( предоставление памяти, сохранение записей и т.д)?
Если Вы хотите использовать дополнительные возможности восстановления,
необходимо прежде рассмотреть и дополнительные затраты по администрированию,
такие как отслеживание файлов и лент, а также - выполнение регулярного
копирования (backup). Выгода от этой работы состоит в том, что Вы всегда
сможете восстановить базу без потери работы при любом типе отказа программного
обеспечения или аппаратуры. Кроме того, Вы сможете выполнять backup в процессе
работы базы (такое копирование требует архивации файлов журнала повторного
выполнения).
Выполнение архивации совершенно не влияет на производительность, так как
запись в журнал повторного выполнения производится системой вне зависимости от
выбранного режима. Дополнительная работа связана лишь с получением копий на
ленте файлов журнала и выполнением периодических полных копий базы.
Использование журнала в режиме ARCHIVELOG
В этом режиме все модификации базы сохраняются, так что она может быть
реконструирована в случае сбоев оборудования. Режим ARCHIVELOG требует
наличия файлов журнала как в состоянии online, так и в offline и выполнения
периодического полного копирования базы.
Лучше если этот backup будет физическим (копия образа диска), а не логическим
(экспорт) и должен включать все файлы, связанные с данным табличным
пространством. Backup может выполняться, когда база открыта для нормального
использования. Частое копирование более предпочтительно, так как при этом для
восстановления требуется меньшее количество файлов журнала.
Таким образом, при нормальной работе базы в журнал повторного выполнения
записываются все транзакции с момента последнего выполнения backup до
следующего. Они записываются в активные (online) файлы журнала и после
заполнения архивируются на лентах.
Активный журнал повторного выполнения (online)
Активный журнал существует независимо от выбранного Вами режима: ARCHIVELOG
или NOARCHIVELOG и представляет из себя набор файлов операционной системы,
используемые ORACLE RDBMS для записи текущих транзакций. Для выполнения
восстановления экземпляра требуются только эти файлы.
При заполнении такого файла перед повторным использованием он должен быть
архивирован (обычно - на ленту). В режиме ARCHIVELOG ORACLE предотвращает
использование этого файла до выполнения архивирования. Архивирование файла
журнала повторного выполнения может быть как автоматическим, так и ручным.
Этот вопрос обсуждается позже.
Неактивный журнал повторного выполнения (offline)
Неактивные файлы журнала повторного выполнения наличествуют только в
режиме ARCHIVELOG и представляют из себя набор архивированных файлов. Обычно
-- 147 --
эти файлы не могут быть доступны немедленно и требуют для перевода в online
некоторых действий. Необходимо иметь достаточное количество памяти для
сохранения информации между точками backup.
Неактивные файлы регистрации изменений идентифицируются последовательными
номерами, назначаемыми при архивировании. Номера начинаются с 1 и уникальны
для каждого файла. DBA отвечает за отслеживание последовательных номеров файлов
журнала так как впоследствии он используются при восстановлении.
Использование журнала в режиме NOARCHIVELOG
В этом режиме файлы записываются точно так же, как и в режиме ARCHIVELOG,
но могут использоваться повторно без архивирования. Активные файлы журнала
используются по "круговому" принципу (когда заполнен последний файл, ORACLE
возвращается к первому и начинает вновь записывать в него информацию), так что
В любой момент доступны только наиболее "свежие" изменения базы. Из
этого вытекают три соображения:
1. Журнал повторного выполнения может быть использован для восстановления,
если отказ произошел в момент, когда необходимые файлы журнала были активны.
Хотя NOARCHIVELOG всегда позволит восстановиться при ошибке экземпляра,
он обычно не спасает от ошибок оборудования, так как не содержит всей
необходимой для отката вперед информации.
2. Если в результате некоторой ошибки табличное пространство стало
недоступным, вы не сможете продолжить эксплуатацию базы, пока пространство
не будет восстановлено или отменено. Это связано с тем, что при дальнейшей
работе будут повторно использоваться файлы регистрации изменений, а они нужны
для восстановления этого пространства.
3. Вы сможете выполнять backup базы только после ее остановки.
Контрольные точки
Всякий раз, когда для транзакции выполняется операция commit, соответствующие
элементы журнала повторного выполнения записываются из соответствующих буферов
в журнал. Иногда такая запись производится и для незавершенных еще транзакций
в случаях, когда буферы журнала переполняются или если эта информация
находится в одном буфере с записанной транзакцией.
При контрольной точке все модифицированные данные из буферов записываются в
базу, что гарантирует запись на диск всех изменений и заодно - что выполненная
до этого времени запись информации в журнал повторного выполнения больше не
потребуется для восстановления экземпляра ORACLE. Контрольные точки
инициируются и выполняются автоматически.
Выполняя периодическое сохранение измененных данных в базе, контрольные точки
выполняют две задачи:
* уменьшают время, требуемое для восстановления экземпляра (если это
необходимо)
* позволяют выполнить архивацию или начать повторное использование активного
файла журнала.
Если во время работы одной контрольной точки инициируется другая,
первая останавливается и начинает работать вторая. Вторая контрольная точка
выполняет работу за двоих.
-- 148 --
Контрольная точка заключается в запоминании адреса следующего элемента,
который будет записываться в файл регистрации, записи буферов данных на диск,
и наконец - записи запомненного адреса в управляющий файл и файлы базы. Теперь,
если через некоторое время после контрольной точки потребуется восстановление,
оно может начаться с запомненного места.
Хотя с выполнением контрольной точки и связаны некоторые затраты, работа
базы не прекращается и это не влияет на текущую транзакцию. Вследствие того,
что процесс DBWR постоянно записывает информацию из буферов базы на диск,
контрольной точке не требуется записывать сразу много блоков. Более того,
выполнение контрольной точки просто означает, что все изменения в данных,
выполненные с предыдущей контрольной точки, записаны на диск.
Хотя контрольные точки и работают одинаково, они могут инициироваться двумя
различными способами, описанными в следующих двух разделах. Вы не можете
непосредственно заставить выполниться контрольной точке, но можете
управлять частотой их выполнения. Чем чаще они возникают, тем меньше
потребуется времени на восстановление экземпляра.
Контрольные точки для ускорения восстановления
Контрольные точки выполняются после записи указанного числа
блоков файла регистрации и служат промежуточными точками для
восстановления. Все изменения, предшествующие контрольной точке
"сохранены" и восстановление может начинаться с изменений, следу-
ющих за контрольной точкой.
Для управления частотой появления контрольных точек установите в файле
INIT.ORA параметре LOG_CHECKPOINT_INTERVAL число блоков журнала, после записи
которых выполняется контрольная точка.
Небольшие значения этого параметра уменьшают время, необходимое для
восстановления при ошибке экземпляра, но увеличивают общее количество
контрольных точек и, тем самым, отрицательно влияют на производительность
(так как каждая контрольная точка требует от DBWR дополнительных затрат
ввода/вывода).
Контрольные точки при переполнении файлов журнала
Контрольные точки используются также и для того, чтобы дать возможность файлу
журнала использоваться заново. Эти контрольные точки выполняются в момент
заполнения очередного файла журнала и начале записи в следующий. Для режима
NOARCHIVEMODE контрольная точка просто должна выполниться до начала
повторной записи в файл. В режиме ARCHIVELOG для повторного использования
кроме контрольной точки должно быть выполнено архивирование файла.
Решение выборе стуктуры для восстановления
DBA имеет возможность выбора вариантов, связанных с подготовкой к
восстановлению, включающие следующие вспомогательные структуры:
* файлы журнала повторного выполнения
* сегменты отката
* управляющие файлы
В последующих разделах обсуждается взаимосвязь этих структур.
За дополнительной информацией обратитесь к Главе 3.
Создание активного журнала повторного выполнения
-- 149 --
Активный журнал повторного выполнения состоит как минимум из двух файлов
операционной системы. При создании журнала повторного выполнения (в процессе
создания базы) с помощью команды CREATE DATABASE, вы можете указать:
* какой режим будет использоваться ARCHIVELOG или NOARCHIVELOG
* количество активных файлов журнала
* размер этих файлов
* местоположение этих файлов.
Кроме того, в любой момент Вы можете назначать и менять следующее:
* размер LOG_CHECKPOINT_INTERVAL
* только для разделяющих диски систем - размер LOG_ALLOCATION
для каждого экземпляра (См. Главу 21)
* спецификации для активных файлов журнала повторного выпол- нения.
Решение этих вопросов влияет на частоту появления контрольных точек и, если
Вы работаете в режиме ARCHIVELOG, гибкость, которую Вы будете иметь при
архивировании. Первоначально файлы журнала повторного выполнения создаются
при выполнении команды CREATE DATABASE. Синтаксис позволяет указывать два или
более файлов:
CREATE DATABASE ... [ LOGFILE filespec [, filespec ] ]
где filespec имеет формат:
filename [ SIZE integer ] [ REUSE ]
Если Вы не указали ни SIZE, ни REUSE, предполагается REUSE, а SIZE - размер
файла в байтах. Например:
SQLDBA> CREATE DATABASE TESTDB
LOGFILE 'ONELOG.RDO' SIZE 50000, 'TWOLOG.RDO' SIZE 50000;
Если Вы опустите необязательный аргумент LOGFILE, автоматически создавшиеся
два маленьких файла журнала позволят начать работу. Имена, размеры и
местоположение созданных в этом случае умалчиваемых файлов журнала зависит от
операционной системы; детали можно найти в "Руководстве пользователя по
инсталяции" для Вашей системы.
Выбор режима работы журнала повторного выполнения
В операторе CREATE DATABASE можно указать одну из двух опций:
ARCHIVELOG или NOARCHIVELOG. Если ничего не указано, подразумевается
NOARCHIVELOG.
Режим можно впоследствии изменить, используя оператор ALTER DATABASE при
монтированной, но не открытой базе.
Выбор количества файлов повторного выполнения
Активный журнал повторного выполнения должен иметь как минимум два файла,
однако их может быть и больше. В действительности этот вопрос имеет две
стороны:
* сколько всего памяти Вам понадобится ?
* каким образом Вы хотите разбить эту память на файлы ?
Хотя минимально возможно иметь два файла, рекомендуется использовать
большее количество. Использование большего числа файлов позволит более гибко
планировать стратегию спуллинга. Например, если Вам необходимо для
-- 150 --
журнала 10000 блоков и Вы предполагаете использовать для спуллинга ленты,
вмещающие по 2000 блоков - разбейте журнал на пять файлов и тогда будете за
один раз записывать одну ленту.
Максимальное количество файлов журнала, которое когда-либо может быть
использовано, указывается параметром MAXLOGFILES оператора CREATE DATABASE. А
максимальное количество файлов определяется параметром LOG_FILES файла
INIT.ORA. Этот параметр может быть временно перекрыт значением MAXLOGFILES,
но только в меньшую сторону и никогда - в большую. Умалчиваемое значение для
обоих параметров равно 16, а максимальное - 256.
Назначение размеров файлов журнала повторного выполнения
Помня об общем количестве требуемой Вам памяти для журнала, далее
необходимо решить вопрос об их количестве и размерах. Далее даны некоторые
правила по выбору размеров активных файлов журнала.
Каждый активный файл журнала должен быть размером минимум - 50
килобайтов; ограничения сверху не существует. Файлы журнала не обязательно
должны быть одинакового размера, но обычно для удобс- тва делают именно так.
Если Вы выбрали большие файлы журнала, то :
* каждый из них будет заполняться дольше
* для переключения файлов потребуется меньше контрольных точек
* архивирование файлов журнала может проводиться менее часто
* восстановление экземпляра будет выполняться несколько дольше, если Вы
уменьшите интервал контрольных точек
Назначение устройств для файлов журнала повторного выполнения
Файлы журнала должны быть помещены на устройства, отличные от содержащих файлы
базы по следующим причинам:
* для уменьшения риска одновременной потери файлов базы и
журнала в случае отказа оборудования
* для снижения конкуренции в использовании диска (во время
большой активности базы увеличивается и активность журнала)
Так как одновременно записывается только один файл журнала, нет смысла
распределять их по разным дискам.
Изменение журнала
Изменить конфигурацию журнала повторного выполнения можно следующими
способами:
* добавлением новых файлов
* удалением файлов
* переименованием файлов
* переключением режима между ARCHIVELOG и NOARCHIVELOG
Изменения в конфигурации и режиме использования журнала повторного выполнения
должно проводиться в базе, монтированной исключительно одним экземпляром, и
не открытой им. Более подробная информация находится в Главе 16.
Смена режима использования журнала
-- 151 --
Используя оператор ALTER DATABASE, Вы можете изменить режим работы
журнала. Для выполнения этой операции база должна быть монтирована, но не
открыта одним экземпляром ORACLE. Присоединение к базе должно выполняться с
параметром INTERNAL, так как необходимо выполнить оператор ALTER DATABASE при
закрытой базе.
Если Вы переключаетесь с режима NOARCHIVELOG в режим ARCHIVELOG,
следует немедленно выполнить backup (не экспорт !) всех файлов базы. Пока
копия не сделана, база будет невосстановимой. Файлы журнала и управляющие
копировать не надо.
Если Вы переключаетесь с режима ARCHIVELOG в режим NOARCHIVELOG, восстановление
при отказе оборудования будет ограничиваться временем переключения и полное
восстановление возможно только для экземпляра.
Выбор интервала для контрольных точек
Интервал контрольных точек - это число блоков файла журнала, служащее
порогом для выполнения контрольной точки. Это значение устанавливается
параметром LOG_CHECKPOINT_INTERVAL файла INIT.ORA. Умалчиваемое значение
зависит от операционной системы и не существует ограничений на минимум и
максимум. Если интервал превышает размер файла журнала, то контрольные точки
будут выполняться только при переключении файлов. При уменьшении интервала:
* контрольные точки будут выполняться более часто
* время, необходимое для восстановления экземпляра, будет сокращаться (так
как чтобы сделать все изменения текущими, надо обработать меньшее количество
блоков журнала).
Создание сегментов отката
При выполнении оператора CREATE DATABASE создается начальный сегмент
отката; при этом используются умалчиваемые назначения. Один сегмент
подходит для небольших систем (с одним табличным пространством) или для
систем с низкой активностью. Однако, большинство DBA захотят для размещения
большего количества пользователей, более активных транзакций, а также для
создания дополнительных табличных пространств или разделения дисков -
добавить дополнительные сегменты отката.
Для добавления сегмента отката используется SQL - оператор:
CREATE ROLLBACK SEGMENT
Инструкции по добавлению сегментов отката приведены в Главе 16. Для начала
использования новых сегментов отката необходимо остановить и вновь стартовать
систему.
Обычно администраторы базы данных принимают следующие решения относительно
сегментов отката:
* сколько сегментов отката использовать ?
* как распределить память для каждого сегмента ?
* должен ли сегмент отката быть личным или общим ?
* в каких табличных пространствах должны находиться сегменты отката ?
Для принятия этих решений Вы должны рассмотреть:
* сколько места из базы данных должно быть отдано под сегменты отката ?
* каково среднее и максимальное количество параллельных транзакций ?
* каковы Ваши требования к производительности ?
* сможете ли Вы распределить сегменты отката по различным устройствам
-- 152 --
ввода/вывода ?
* будете ли Вы запускать один экземпляр ORACLE или работать в
режиме разделения дисков (несколько экземпляров) ?
Выбор количества сегментов отката
Общее количество сегментов отката, требуемое базе, зависит от:
* ожидаемого максимального количества параллельных транзакций
* количества транзакций на один сегмент отката
* количества экземпляров ORACLE (для разделяющих диски систем)
Увеличение числа сегментов отката уменьшает соперничество за блоки сегментов.
Если Вы запустите MONITOR ROLLBACK SEGMENTS и увидите большое число в столбце
"Header Waits/Sec", необходимо увеличить количество сегментов отката.
Сегменты отката поддерживают информацию транзакции для многих целей,
включая согласованность чтения. Сегмент отката может вмещать ограниченное число
транзакций; оно называется количеством "слотов транзакций". Это число -
функция информации об активных транзакциях, запоминаемой в сегменте отката.
При старте транзакции в сегменте отката для нее создается элемент, который не
удаляется, пока транзакция не будет завершена (выполнен commit или rollback).
Память, распределяемая в сегменте отката для каждой транзакции, имеет
фиксированный размер. Ожидаемое количество параллельных транзакций является
функцией количества пользователей базы и активности системы. Таким образом,
общее число сегментов отката должно вмещать ожидаемое количество одновременных
транзакций. Хорошей оценкой для числа сегментов может служить:
# segmrnts = 2 x [max # transactions / ( (block size) / 32 ) ]
Для вычисления сегментов отката можно также пользоваться следующими правилами :
Число параллельных Рекомендуемое количество
транзакций сегментов отката
------------------------------------------------------------
меньше 16 4 сегмента
16 - 32 8 сегментов
32 и более n/4, но не больше 50
Распределение памяти для сегментов отката
Как и индексные сегменты, сегменты отката распределяются группами bлоков,
называемых экстентами. При установке параметров памяти для сегментов отката Вам
необходимо:
* Сделать сегменты одинакового размера
* Использовать большое значение MAXEXTENTS, чтобы избежать нехватки
памяти в сегментах отката
Чтобы вспомнить, как транзакции записываются в сегменты отката, обратитесь к
разделам Главы 4 "Содержание сегмента отката" и "Как распределяются сегменты
для активных транзакций".
Как и другие типы сегментов, сегмент отката должен иметь достаточно места
для хранения данных. Если сегмент отката пытается распределить дополнительный
экстент, но не может (например - если в табличном пространстве нет места для
распределения дополнительного экстента), текущая транзакция завершится с
ошибкой.
-- 153 --
Долго работающие запросы могут увеличивать сумму необходимой памяти, так
как данные отката должны поддерживаться для всех изменений в таблице на всем
протяжении сканирования. Если данные, необходимые для генерирования блока
согласованного чтения будут перекрыты, запрос получит ошибку "snapshot too
old" (снимок памяти слишком стар), описываемую в Главе 12.
Архивирование журнала повторного выполнения в режиме ARCHIVELOG
Если система работает в режиме NOARCHIVELOG, Вы можете не восстановиться от
ошибки оборудования кроме как восстановлением полной копии базы, сделанной
когда она была в offline. Так что если база работает в режиме NOARCHIVELOG,
информация этой главы к Вам не относится.
Если же Вы хотите застраховаться от от ошибок оборудования, необходимо
установить режим ARCHIVELOG и постоянно выполнять смежные операции:
* периодическое полное копирование базы
* архивирование данных online файлов журнала
Архивирование - это процесс записи заполненного активного (online)
файла журнала на вторичное запоминающее устройство (обычно - магнитную
ленту). Архивирование не требует прерывания работы базы. (Однако если вовремя
не архивировать заполненных файл журнала, работа экземпляра будет
приостановлена до завершения процесса архивирования).
Файл журнала повторного выполнения может быть архивирован одним из двух
способов: автоматически или вручную. Оба этих способа описаны описаны в
следующих разделах, а более подробную информацию можно найти в "Руководстве
пользователя по инсталяции", где она представлена конкретно по отношению к
определенной операционной системе.
Последовательные номера файлов журнала
Независимо от способа архивирования (ручное или автоматическое) Вы отвечаете
за ведение учета архивированных файлов. Каждый файл журнала может идентифици-
роваться уникальным последовательным номером. Этот номер назначается во время
архивирования и требуется при последующем восстановлении. Последовательные
номера журнала начинаются с 1 и увеличиваются на 1 при открытии очередного
файла.
В целях восстановления Вы должны хранить и при необходимости - легко
находить нужный файл журнала, основываясь на его последовательном номере.
Обычно активные файлы журнала именуются комбинированием назначенного журналу
имени и последовательного номера. За детальной информацией об именовании и
расположении файлов журнала обратитесь к Приложению В и "Руководству
пользователя по инсталяции".
Статус и последовательный номер файла журнала можно посмотреть с помощью
команды ARCHIVE LOG LIST утилиты SQL*DBA.
Автоматическое архивирование
В некоторых операционных системах возможно автоматическое архивирование
файлов журнала с помощью фонового процесса ARCH. Файлы могут быть архивированы
на диск или непосредственно на ленту. Это возможно в организациях, где
операционные системы позволяют монтировать ленты, как только у процесса
ARCH возникнет в этом необходимость.
-- 154 --
Автоматическое архивирование может быть включено двумя способами:
используя файл INIT.ORA или утилиту SQL*DBA. Запись о каждой автоматической
архивации помещается процессом ARCH в файл трассы. Каждый элемент
показывает время начала и завершения процесса архивации. Несмотря на то, что
включили автоматическую архивацию, заодно можно выполнить и ручную.
Включение автоматического архивирования через INIT.ORA
Для этого надо настроить два параметра файла INIT.ORA. Установите значение
TRUE параметру LOG_ARCHIVE_START и назначьте неактивный (offline) журнал с
помощью параметра LOG_ARCHIVE_DEST. Конкретный вид этого назначения зависит от
операционной системы и детально описан в Вашем "Руководстве пользователя по
инсталяции".
После установки этого параметра автоматическая архивация запустится при
очередном старте экземпляра ORACLE. Эти параметры определяют также опции
архивирования, действующие после очередного старта экземпляра, хотя команда
ARCHIVE LOG может их временно переназначить.
Включение автоматического архивирования через SQL*DBA
Для этого надо выдать команду SQL*DBA:
SQLDBA> ARCHIVE LOG START [ destination ]
Эта операция необходима не для немедленного архивирования файла, а для
включения автоматического архивирования. В этом случае файл будет архивирован
сразу же, как только в этом возникнет необходимость.
Для отключения автоматического архивирования надо указать опцию STOP
вместо START. Независимо от последнего значения, заданного в этой команде,
если в параметре LOG_ARCHIVE_START файла INIT.ORA указано TRUE, при очередном
старте экземпляра начнется автоматическое архивирование.
Назначение адреса архива
При автоматическом архивировании файла журнала повторного выполнения фоновый
процесс ARCH должен знать, где он должен создавать копию. Это местоположение
называется адресом архива и может быть специфицировано как через параметр
LOG_ARCHIVE_DEST файла INIT.ORA, так и как опция в команде ARCHIVE LOG. Адресом
назначения могут быть только диски или ленты. Конкретное специфицирование
опций зависит от операционной системы и детально описано в "Руководстве
пользователя по инсталяции".
Отключение автоматического архивирования
Отключить автоматическое архивирование можно двумя способами. Для временной
остановки автоматического архивирования проще воспользоваться командой
SQL*DBA:
SQLDBA> ARCHIVE LOG STOP
Чтобы автоматическое архивирование было выключено по умолчанию, необходимо
установить параметру LOG_ARCHIVE_START файла INIT.ORA значение FALSE. Чтобы
новое значение стало активным, необходимо рестартовать экземпляр ORACLE.
-- 155 --
В общем случае при старте экземпляра архивирование устанавливается
автоматическим или ручным в зависимости от значения параметра
LOG_ARCHIVE_START.
Ошибка в процессе автоматического архивирования отключит его так же, как
если бы Вы выдали команду ARCHIVE LOG STOP. В некоторых операционных системах
сообщение об ошибке будет выдано на системную консоль и независимо от
системы будет занесено процессом ARCH в файл трассы. После разрешения возникшей
проблемы можно просто возобновить архивирование командой LOG ARCHIVE START.
Архивирование вручную
Ручное архивирование требует от DBA или оператора системы непосредственной
выдачи команд SQL*DBA. Хотя этот метод и дает возможность более гибко управлять
процессом архивирования, он может потребовать явных действий (например -
монтирования ленты).
Ручное архивирование подразумевается по умолчанию (начально параметр
LOG_ARCHIVE_START установлен в FALSE).
При ручном архивировании в первую очередь надо определить, какие файлы
будут архивироваться. Это можно сделать с помощью опции LIST команды
ARCHIVE LOG.
Таким образом,при архивировании применяется следующий синтаксис:
SQLDBA> ARCHIVE LOG [ NEXT | n | ALL ] [ destination ]
Это приведет к немедленной архивации указанного файла(ов). Полное описание
команды дано в Приложении В.
Выполнение BACKUP
Для восстановления от ошибки оборудования Вы должны иметь:
* образы частей базы, подлежащих восстановлению, а также журналы регистрации
изменений (online и offline) или
* согласованную копию всех файлов базы (включая файлы журнала и управляющие)
Копия образа - это копия файла блок-за-блоком, в отличие от экспорта,
представляющего собой логическую копию, записывающую данные независимо от
из физического расположения. Копии образа полезны в двух случаях:
* для восстановления базы на определенный момент времени в прошлом
* для восстановления базы на недавний или текущий момент вре- мени
В первом случае backup должен содержать согласованную базы, журналов и
управляющих файлов, сделанных при закрытой базе. Эта копия используется для
восстановления содержимого базы на определенный момент времени в прошлом.
Никакого восстановления от порчи оборудования не выполняется, файлы базы просто
восстанавливаются.
Во втором случае backup базы (либо части базы) обычно используется для для
восстановления после отказов оборудования. Backup может выполняться и с части
базы в процессе ее работы. Восстановление с backup является первой частью
восстановления от сбоев оборудования. После этого с помощью файлов журнала
база приводится к состоянию, предшествующему сбою.
-- 156 --
Копии образа (backup):
* должны выполняться часто и регулярно
* могут быть сделаны как с открытой, так и закрытой базы
* могут выполняться на основе табличных пространств, а не полностью
всей базы
Более частые копии потенциально уменьшают время, требуемое для восстановления
при отказах оборудования. Копии отдельных табличных пространств помогут
выполнять восстановление более гибко, так как в некоторых случаях нет
необходимости восстанавливать все табличные пространства относительно одного
момента времени.
пpоцедуры копирования/восстановления неодинаковы для различных операционных
систем и конкретно обсуждаются в "Руководстве пользователя по инсталяции".
Копирование закрытой базы
Если база закрыта, можно выполнить полную копию базы. Эта копия называется
согласованной копией и ее впоследствии можно использовать для возврата к
состоянию на момент копирования. Чтобы скопировать закрытую базу, необходимо:
1. Остановить экземпляр ORACLE
2. Воспользоваться утилитой копирования операционной системы для
копирования всех файлов базы, файлов журнала и управляющих.
3. Если нужно, рестартовать экземпляр
Копирование открытой базы
Если используется режим ARCHIVELOG, можно скопировать всю или часть базы в
процессе ее работы; это называется "горячая копия". Это позволит
восстановить Вам табличные пространства в случае ошибки оборудования.
Backup, выполненный на работающей базе, имеет следующие характеристики:
* в момент его выполнения пользователи могут иметь нормальный доступ к базе
(включая модификации). Таким образом, Вы можете работать с копируемым
табличным пространством.
* при использовании для восстановления он поможет вернуться к наиболее свежему
состоянию базы, но не предыдущему
* копируются только файлы базы, связанные с табличными пространствами, но не
управляющие и не журнал
Для копирования табличного пространства открытой базы используются указанные
ниже шаги. Чтобы скопировать всю базу, необходимо повторить эти шаги для
каждого табличного пространства базы (включая и и пространство SYSTEM).
1. Включить режим ARCHIVELOG и архивировать файлы журнала, если они
заполнены.
2. Если табличное пространство, содержащее копируемые файлы, находится в
состоянии online, необходимо выдать команду:
SQLDBA> ALTER TABLESPACE tablespace BEGIN BACKUP
Если база закрыта или табличное пространство выведено в offline, в
предыдущем операторе нет необходимости.
-- 157 --
3. Воспользуйтесь утилитой операционной системы для копирования всех
файлов, связанных с этим табличным пространством. Подробнее это описано в
"Руководстве пользователя по инсталяции". Эта копия может содержать некоторые
изменения, произведенные в момент копирования (если изменения произведены
до перенесения данной части файла в копию).
4. Выполните SQL - оператор:
SQLDBA> ALTER TABLESPACE tablespace END BACKUP
Не забудьте выдать обе эти команды. Хотя эта команда мало влияет на
пользователей, уже имеющих доступ к базе, RDBMS использует эту команду для
идентификации части журнала повторного выполнения, созданной в процессе
выполнения копии.
Если Вы забудете выдать команду ALTER TABLESPACE ... BEGIN BACKUP и
последующая остановка базы будет ненормальной, файлы табличного пространства
могут быть скопированы некорректно и Вы не сможете использовать эти файлы для
восстановления.
Если же Вы забудете выдать команду ALTER TABLESPACE ... END BACKUP и
система будет продолжать работу, а затем стартует новый экземпляр ORACLE,
RDBMS может предположить, что необходимо восстановление и потребовать установку
архивированного журнала повторного выполнения.
Процедуры восстановления носителей
Следующие разделы описывают процедуры восстановления носителей, когда какой-
либо из файлов системы ORACLE недоступен (не может быть записан или прочитан).
Восстановление файлов базы к текущему состоянию требует архивирования файлов
журнала, если они заполнились (журнал используется в режиме ARCHIVELOG).
Замечание: Вы отвечаете за архивирование файлов журнала и нахождение их в
соответствии с идентификатором, называемым последовательным номером журнала.
Вы можете восстановить как всю базу, так и отдельное табличное пространство.
Можно также восстановить отдельный файл табличного пространства с целью
восстановления последнего. Процесс восстановления требует, чтобы все файлы
табличного пространства временно были переведены в состояние offline.
Восстановление файла базы, не принадлежащего табличному пространству SYSTEM
Если система ORACLE определила, что не может прочитать файл, принадлежащий
табличному пространству, отличному от SYSTEM, возникнет ошибка операционной
системы, но база будет продолжать функционировать, выдавая сообщение об
ошибке всякий раз, когда неудачно считывает данные.
Если система ORACLE определила, что не может записать информацию в файл,
не принадлежащий табличному пространству SYSTEM, она выдаст сообщение об
ошибке и выведет соответствующее пространство в offline.
Если возникла ошибка в файле базы, не принадлежащем пространству SYSTEM,
Вы можете:
* восстановить только пострадавшее табличное пространство, оставив
открытой и работоспособной оставшуюся часть базы. В этом случае Вы должны
восстановить к настоящему (теперешнему) состоянию.
-- 158 --
* остановить базу и выполнить ее полное восстановление. В этом случае
пользователи не имеют в процессе восстановления доступа к базе и Вы можете
восстановить к произвольному моменту времени (См. ниже раздел "Точка восстановле
Восстановление табличного пространства
Для восстановления файла в табличном пространстве, отличном
от SYSTEM, проделайте следующие шаги. Вам необходим доступ к двум
терминалам системы (один - для инициирования и выполнения восста-
новления, другой - для копирования в процессе восстановления ар-
хивированных файлов журнала в память, находящуюся в состоянии
online).
1. Необходимо стартовать экземпляр и открыть базу. При этом пользователи
могут работать в системе, а можно стартовать экземпляр в режиме доступа
только DBA.
2. С одного терминала, работающего с утилитой SQL*DBA, присоединитесь к базе
как DBA.
3. Переведите табличное пространство с поврежденным файлом в offline:
SQLDBA> ALTER TABLESPACE tablespace OFFLINE
4. Воспользуйтесь командами операционной системы для восстановления наиболее
свежих копий каждого файла, которые хотите восстановить. Необходимо
восстановить только копии файлов, с которыми возникли проблемы, что возможно
означает восстановление одного файла из многих, составляющих табличное
пространство. (Если хотите, можете восстановить и дополнительные файлы).
Управляющие файлы восстанавливать не надо.
5. Введите следующую команду SQL*DBA (полный синтаксис описан в Приложении В):
SQLDBA> RECOVER TABLESPACE tablespace [, tablespace ... ]
6. Если для выполнения восстановления не требуется offline - файлов журнала
(так как для этого достаточно online - файлов журнала), вскоре Вы увидите
сообщение о том, что восстановление завершено.
Если offline - файлы журнала все-таки необходимы, SQL*DBA запросит их
последовательные номера.
С другого терминала Вы можете с помощью утилиты операционной системы перенести
необходимые файлы с ленты на диск. Вас не должно беспокоить, куда переносить
файлы, SQL*DBA сама будет Вас об этом запрашивать. Имена этих файлов также
запрашиваются SQL*DBA. ORACLE проверяет, те ли это файлы, которые
необходимы, проверяя их последовательные номера.
Альтернативно можно восстанавливать информацию непосредственно с ленты, если
она монтирована и Вы указали ее спецификацию в ответ на запрос утилиты
SQL*DBA.
Далее SQL*DBA будет запрашивать следующие необходимые ей файлы журнала и
восстанавливать с их помощью информацию базы.
Если Вы знаете, какие offline - файлы журнала необходимы, можно избежать
задержки, связанной с запросами очередных файлов. Просто скопируйте их на
диск заранее. Первый нужный Вам файл - тот, который записывался в момент,
-- 159 --
когда делался backup самого старого файла, который Вы восстанавливали.
Последний необходимый Вам файл журнала - который записывался при переводе
табличного пространства в offline.
7. Верните табличное пространство в online:
SQLDBA> ALTER TABLESPACE tablespace ONLINE
Восстановление базы данных
Файл базы из табличного пространства, отличного от SYSTEM, можно восстановить,
восстанавливая всю базу. Выполняемые шаги аналогичны предыдущим, однако
пользователи не могут работать с базой в течение всего времени восстановления.
1. Необходимо стартовать экземпляр, монтировать базу в режиме EXCLUSIVE, но не
открывать.
2. Восстановите необходимые Вам файлы базы с backup - копий. Необходимо
восстанавливать только файлы, с которыми возникли проблемы, даже если
надо восстанавливать один файл из трех. Не восстанавливайте копии
управляющих файлов.
3. Запустите SQL*DBA и введите команду:
SQLDBA> RECOVER DATABASE
4. Если для выполнения восстановления не требуется offline - файлов журнала
(так как для этого достаточно online - файлов журнала), вскоре Вы увидите
сообщение о том, что восстановление завершено. Если offline - файлы
журнала необходимы - смотрите шаг 6 "Восстановления табличного пространства"
5. После появления сообщения о завершении восстановления база данных может быть
открыта (если Вы хотите работать в исключительном режиме). Чтобы позволить
обращаться к базе и другим экземплярам, необходимо выполнить операции:
DISMOUNT, SHUTDOWN, STARTUP, MOUNT SHARED и OPEN.
Прерывание процесса восстановления
Процесс восстановления можно прервать в следующие моменты:
* в ответ на запрос очередного файла журнала ответьте CANCEL
* посередине работы по восстановлению файла можно выдать сигнал прерывания
операционной системы.
Продолжение процесса восстановления
Для продолжения восстановления введите:
SQLDBA> RECOVER TABLESPACE tablespace [, tablespace ...]
или
SQLDBA> RECOVER DATABASE
Восстановление продолжится с того места, на котором было прервано, оно не
начинается заново. Если Вы хотите начать восстановление с более раннего файла,
процесс восстановления надо начать заново.
Восстановление файла базы, принадлежащего табличному пространству SYSTEM
-- 160 --
Если Вы не можете читать или записывать информацию в файл, принадлежащий
табличному пространству SYSTEM, в процессе восстановления база будет не
доступна пользователям. Табличное пространство SYSTEM требуется для открытия
базы и следовательно будет недоступно в процессе восстановления.
В этой ситуации необходимо при восстановлении следовать шагам, приведенным
для восстановления базы (не табличного пространства !).
Восстановление online - файла журнала повторного выполнения
Если при ошибке носителя пострадал online - файл журнала, база остановится
по ошибке чтения/записи операционной системы. Если Вы знаете причину ошибки и
уверены, что данные не потеряны, попытайтесь просто рестартовать экземпляр и
ORACLE его восстановит.
Если же Вы подозреваете, что данные журнала могли быть потеряны, можете
выбрать один из вариантов:
* Восстановить базу с использованием согласованного набора backup -
файлов (включая файлы базы, журнала и управляющие). Согласованный набор
означает, что файлы были записаны одновременно при остановленной базе. После
восстановления база будет полностью отражать состояние на момент выполнения
копирования (backup).
* Восстановить базу, как описано в разделе "Восстановление базы" и в
файле RECOVERY.DOC (через последний читаемый файл регистрации изменений).
Таким образом, будут восстановлены данные, записанные (commit) до данной точки;
изменения, выполненные после этого момента, будут потеряны. См. ниже раздел
"Точка восстановления".
* Создать новую базу и выполнить полный импорт, используя файлы
совокупного и дополнительного экспорта. Это вернет Вас к моменту
последнего дополнительного экспорта.
В некоторых операционных системах можно уменьшить риск потери файла журнала
повторного выполнения, используя возможность дублирования операционной системы.
Если на другом диске сохранилась копия журнала в реальном времени, более
вероятно иметь одну хорошую копию журнала в случае отказа носителя.
Восстановление управляющих файлов
Поскольку управляющие файлы содержат информацию, необходимую для старта и
восстановления экземпляра, они должны быть гарантировано защищены от ошибок.
В общем случае запись, восстановление и защита этих файлов выполняется
автоматически, требуя от DBA минимальных действий по назначению этих файлов на
разные диски.
Признаком разрушения управляющего файла может быть аварийное завершение
экземпляра ORACLE в момент старта.
Если не все управляющие файлы разрушены, просто скопируйте хороший файл.
Рекомендуемый путь копирования управляющего файла следующий:
1. Остановите экземпляр.
2. Скопируйте хороший управляющий файл с новым именем. Проявите осторож-
ность и не используйте имя разрушенного файла из-за риска копирования
плохого файла или перекрытия хорошего.
-- 161 --
3. Исправьте в файле INIT.ORA значение параметра CONTROL_FILES. Удалите имя
старого и добавьте имя нового файла.
4. Выполните рестарт экземпляра.
Если разрушены все управляющие файлы, база должна быть восс-
тановлена полностью одним из следующих способов:
* Восстановите базу, используя полный согласованный backup (копии базы,
журнала и управляющих файлов, сделанный в одно и то же время при закрытой
базе). Это возвратит состояние базы в определенный момент прошлого с backup -
копиями управляющих файлов.
* Выполните восстановление носителя базы, используя backup - копию
управляющего файла. Смотрите файл RECOVERY.DOC. Это вернет Вас в определенный
момент прошлого с backup - копиями управляющих файлов.
* Создайте новую базу и выполните импорт с файла последнего полного
экспорта базы вместе со всеми совокупными и дополнительными файлами экспорта.
Это вернет базу к моменту последнего полного экспорта и сгенерирует новые
управляющие файлы.
Точка восстановления
Нормальное восстановление обычно означает восстановление всей базы к текущему
моменту времени. В исключительных обстоятельствах Вам может понадобиться
восстановление к некоторому моменту в прошлом. Обратитесь к файлу
RECOVERY.DOC, находящемуся на дистрибутивном носителе. В нем содержатся
инструкции и ограничения по восстановлению к определенному моменту. Этот файл
описывает шаги по восстановлению к концу определенного файла журнала или к
указанному моменту времени.
Замечание: Если Вы предполагаете нужду в восстановлении такого типа, необходимо
делать также согласованные копии образа управляющего файла (описано в
RECOVERY.DOC) до и после изменения конфигурации файлов (например -
изменение табличных пространств при добавлении файлов или отмена пространств).
Export/Import
Утилита Export/Import позволяет архивировать и восстанавливать данные ORACLE,
используя файлы операционной системы. Хотя эта утилита и может
использоваться для восстановления данных, ее основные функции несколько иные и
включают в себя:
* выполнение моментальных снимков определений таблиц или данных на некоторый
момент времени (исторический архив)
* сохранение определений таблиц в offline (с данными и без них) с намерением
их восстановления в базу ORACLE в будущем
* перемещение данных системы ORACLE с одной машины на другую
* перемещение данных между различными версиями системы ORACLE.
Однако, экспорт/импорт имеют некоторые ограничения:
* Для выполнения этих операций база должна работать.
* Экспортированные файлы не могут редактироваться и используются только для
импортирования.
* Импорт имеет ограниченную гибкость и работает только с файлами утилиты
Export (например - не может выполняться условный импорт).
-- 162 --
* Экспортированные данные являются логическим представлением данных и могут
использоваться для восстановления носителей только на момент ближайшего
экспорта.
Следующие разделы описывают использование утилит Export/Import относительно
использования в процедурах копирования /восстановления. За более полной
информацией по использованию этих утилит обратитесь к "Руководству
пользователя по инсталяции".
Export
Export - это утилита, перемещающая данные из базы ORACLE в файл операционной
системы. DBA могут экспортировать все данные базы или конкретно указывать,
какие данные должны экспортироваться. К примеру, Вы можете специфицировать:
* только таблицы, чьи данные были изменены с момента последнего импорта
(через совокупный и дополнительный экспорт)
* какие объекты базы надо экспортировать (таблицы и данные, только
определения таблиц, привилегии, обзоры, кластеры, индексы)
* отдельные таблицы
* таблицы одного пользователя
Таким образом, Вы можете достаточно гибко отбирать данные, подлежащие
экспорту. Данные копируются в файл операционной системы в не редактируемом
формате, при этом данные в базе не изменяются.
Экспорт может выполняться только в процессе работы базы и пользователи
могут параллельно обращаться к экспортируемым данным. Данные одиночной
таблицы будут непротиворечивыми, так как экспорт использует согласованный по
чтению обзор данных таблицы.
Однако Вам может потребоваться сделать согласованный экспорт нескольких
(или всех) таблиц, используемых прикладной системой. В этом случае надо
выполнять экспорт в момент, когда пользователи не обращаются к необходимым
таблицам, так что данные находятся в устойчивом состоянии. Простейшим способом
обеспечения этого является выполнение перед экспортом SQL - оператора LOCK
TABLE в режиме SHARED MODE для всех необходимых таблиц. Того же эффекта
можно добиться временной отменой привилегий для таблиц или работая в ORACLE в
режиме DBA.
Полный экспорт базы данных
Регулярное выполнение полного экспорта базы является важной составной
частью хорошей стратегии копирования. Цель полного экспорта базы - сохранение
всех определений таблиц и содержащихся в них данных на определенный момент
времени, так что вся база или отдельные таблицы могут быть при желании или
необходимости реконструированы в будущем.
Экспорт базы отличается от полной копии диска или копии образа базы.
Утилита Export сохраняет данные и определения базы в формате, доступном
только системе ORACLE. Это логическая копия данных системы ORACLE и при
восстановлении данные могут попадать совершенно в другие места диска по
сравнению с исходным состоянием, в то время как backup образа - это физическая
копия данных и данные после восстановления попадут в те же места диска.
-- 163 --
Одним из путей восстановления данных после аварии носителя состоит в
импорте одного из нескольких файлов экспорта. Например, Вы можете восстановить
данные базы, импортировав один полный экспорт базы, один совокупный и два
дополнительных экспорта.
В дополнение к полному копированию базы существует два дополнительных типа
экспорта: совокупный и дополнительный. Оба последних тип экспорта выявляют и
экспортируют таблицы, изменившиеся за указанный промежуток времени. Обычно эти
виды экспорта требуют для выполнения меньше времени и дисковой памяти. Они
могут быть полезны например - при восстановлении ошибочно отмененной таблицы
так как сохранят оставшуюся часть базы в текущем состоянии.
Дополнительный экспорт
Этот тип экспорта берет только объекты, которые были изменены с момента
последнего экспорта любого типа (полного, дополнительного или совокупного).
Дополнительный экспорт обычно выполняется более часто, нежели совокупный или
полный.
Совокупный экспорт
Совокупный экспорт затрагивает только объекты, изменившиеся с момента
последнего полного или совокупного экспорта. Он аналогичен дополнительному,
но обобщает изменившиеся данные за более длительный промежуток времени.
(Если дополнительный и совокупный экспорт выполняются с одинаковой частотой, то
ничем не отличаются друг от друга).
Совокупный экспорт может использоваться для "сжатия" нескольких файлов
дополнительного экспорта в меньшее количество совокупных файлов; нет
необходимости хранить файлы дополнительного экспорта после выполнения
совокупного экспорта.
Import
Import - это утилита, дополнительная утилите Export. Она читает файлы,
созданные программой Export и записывает данные назад в базу. При выполнении
импорта Вы имеет некоторый выбор, какие данные брать из файла.
Использование утилиты Import для полного восстановления данных
Некоторые обстоятельства могут привести к созданию базы заново, например -
при потере файлов, необходимых для работы базы. Конкретным примером может
служить потеря управляющего файла, хотя в этом случае существуют и другие пути
восстановления.
Если вы решили, что полный импорт базы будет лучшим решением возникшей
проблемы, выполните следующие шаги:
1. Определите файлы экспорта, содержащие данные, которые Вы хотите
импортировать. Можно использовать один файл, содержащий все данные базы или
насколько файлов различных типов (полный экспорт, дополнительный, совокупный
или экспорт отдельного пользователя). Импортировать данные можно
непосредственно с ленты.
2. Закройте базу.
3. Остановите все экземпляры, имеющие к ней доступ.
4. Если необходимо, отредактируйте файл INIT.ORA.
5. Выполните шаги по созданию базы, описанные в Гл.13 (Первоначальное
-- 164 --
создание базы). После завершения создания база должна оставаться
открытой.
6. Выполните импорт необходимых файлов.
-- 165 --
|
|