УПРАВЛЕНИЕ УПРАВЛЯЮЩИМИ ФАЙЛАМИ
ГЛАВА 6
----------------------------------------------------------------
УПРАВЛЕНИЕ УПРАВЛЯЮЩИМИ ФАЙЛАМИ
Эта глава объясняет, как создавать и поддерживать управляющие
файлы для вашей базы данных. Темы этой главы включают
обсуждение следующих вопросов:
* указания по сопровождению управляющими файлами
* первоначальное создание управляющих файлов
* добавление, переименование и перемещение управляющих
файлов
* удаление управляющих файлов
Управление управляющими файлами 6-1
----------------
Указания по сопровождению управляющих файлов
Рассмотрите следующие вопросы по ведению управляющих файлов для
базы данных.
Имена управляющих файлов
------------------------
Параметр CONTROL_FILES в файле параметров базы данных указывает
одно или несколько имен управляющих файлов. Процедура запуска
инстанции распознает и открывает все перечисленные файлы;
инстанция поддерживает все указанные управляющие файлы во время
работы базы данных.
Сервер ORACLE осуществляет необходимую запись во все управляющие
файлы, указанные в параметре CONTROL_FILES.
Зеркализуйте управляющие файлы на разных дисках
-----------------------------------------------
Каждая база данных ORACLE должна иметь по меньшей мере два
управляющих файла, разнесенных на разные диски. Если
управляющий файл повреждается сбоем диска, ассоциированная
инстанция должна быть остановлена. После исправления сбившегося
диска поврежденный управляющий файл может быть восстановлен с
помощью неповрежденной копии, после чего можно перезапустить
[!] инстанцию; никакого восстановления носителя не требуется.
Используя зеркальные управляющие файлы, вы избежите лишних
проблем, если случится сбой диска на сервере базы данных.
Следующий перечень описывает поведение зеркальных управляющих
файлов:
* Параметр CONTROL_FILES в файле параметров базы данных
указывает по меньшей мере два имени управляющих файлов.
* Первый из файлов, перечисленных в параметре
CONTROL_FILES, является единственным файлом, который
читается сервером ORACLE во время работы базы данных.
* Если любой из управляющих файлов становится недоступным
во время работы базы данных, инстанция становится
неработоспособной и должна быть остановлена.
Единственным недостатком зеркальных управляющих файлов является
то, что любая операция, требующая обновления управляющего файла
(например, добавление нового файла данных, или взятие
контрольной точки по базе данных) требует несколько большего
времени. Однако эти накладные расходы обычно незначительны
(особенно для тех операционных систем, которые способны
выполнять множественные одновременные операции записи), и ими
нельзя оправдывать использование единственного управляющего
файла.
Корпорация Oracle настоятельно рекомендует вашей базе данных
иметь МО МЕНЬШЕЙ МЕРЕ ДВА УПРАВЛЯЮЩИХ ФАЙЛА НА РАЗНЫХ ДИСКАХ.
6-2 Руководство администратора
Правильно размещайте управляющие файлы
--------------------------------------
Каждая копия управляющего файла должна размещаться на отдельном
дисковом устройстве. Более того, если онлайновый журнал
зеркальный, то отдельную копию управляющего файла следует
размещать на каждом диске, хранящем члены групп журнала. Таким
способом вы минимизируете риск потери всех управляющих файлов и
всех групп журнала в результате одиночного сбоя диска.
Размер управляющего файла
-------------------------
Обычно управляющие файлы невелики. Основными вкладчиками в
размер управляющего файла являются значения, установленные для
параметров MAXDATAFILES, MAXLOGFILES, MAXLOGMEMBERS,
MAXLOGHISTORY и MAXINSTANCES в предложении CREATE DATABASE,
использовавшемся для создания ассоциированной базы данных. Чем
больше значения этих параметров, тем больше размер управляющего
файла базы данных. Максимальный размер управляющего файла
зависит от операционной системы; обратитесь к вашему руководству
по инсталляции [IUG].
----------------
Создание управляющих файлов
Управляющий файл базы данных ORACLE создается одновременно с
самой базой данных. По умолчанию, при создании базы данных
должна быть создана по меньшей мере одна копия управляющего
файла. В некоторых операционных системах создаются несколько
копий. Однако вы ДОЛЖНЫ создать по меньшей мере две копии
управляющего файла во время создания базы данных. Вам может
также потребоваться создать управляющие файлы позже, если вы
потеряете управляющие файлы или захотите изменить в них
некоторые характеристики. Способы создания управляющих файлов
объясняются ниже.
Создание начальных управляющих файлов
-------------------------------------
Вы создаете начальные управляющие файлы базы данных ORACLE,
специфицируя одно или несколько имен управляющих файлов в
параметре CONTROL_FILES в файле параметров, используемом при
создании базы данных. Имена файлов, специфицируемые в параметре
CONTROL_FILES, должны задаваться полностью; спецификация полного
[IUG] имени файла зависит от операционной системы. Если файлы с
заданными именами уже существуют в момент создания базы данных,
то вы должны задать параметр CONTROLFILE REUSE в команде CREATE
DATABASE; в противном случае возникнет ошибка. (Кроме того,
если размер старого файла отличается от размера создаваемого
управляющего файла, то вы не можете использовать опцию REUSE.
Размер управляющего файла различается для разных версий ORACLE;
этот размер зависит также от числа файлов базы данных,
специфицированных в управляющем файле, и от значений параметров
MAXDATAFILES, MAXLOGFILES, MAXLOGMEMBERS, MAXLOGHISTORY и
MAXINSTANCES.) Если параметр CONTROL_FILES опущен при создании
Управление управляющими файлами 6-3
базы данных, то используется умалчиваемое имя управляющего
файла, которое зависит от операционной системы.
Вы можете позднее изменить значение параметра CONTROL_FILES,
чтобы добавить дополнительные управляющие файлы, или изменить
имена или местоположения существующих управляющих файлов;
подробности описаны ниже.
Создание дополнительных копий управляющих файлов,
переименование и перемещение управляющих файлов
-------------------------------------------------
Чтобы добавить новый управляющий файл, скопируйте существующий
файл в новое место и добавьте имя новой копии в список
управляющих файлов. Аналогично, вы переименовываете управляющий
файл путем изменения его имени или перемещения его в новое
место, после чего соответственно исправляете его имя в списке
управляющих файлов. В обоих случаях, чтобы гарантировать, что
управляющие файлы не изменятся во время этой процедуры,
остановите инстанцию, прежде чем копировать управляющий файл.
Чтобы создать дополнительную копию или переместить существующую
копию управляющего файла, используйте следующие шаги:
1. Остановите базу данных.
2. Выйдите из SQL*DBA.
3. Скопируйте существующий управляющий файл на новое место,
используя команды операционной системы.
4. Отредактируйте параметр CONTROL_FILES в файле параметров базы
данных, добавив в него новое имя управляющего файла или
изменив старое имя.
5. Вызовите SQL*DBA.
6. Перезапустите базу данных.
Создание нового управляющего файла
----------------------------------
Вы можете создать новый управляющий файл для базы данных с
помощью команды CREATE CONTROLFILE. Это полезно в следующих
ситуациях:
* Все управляющие файлы базы данных необратимо запортились,
а у вас нет резервной копии управляющего файла.
* Вы хотите изменить одну из постоянных характеристик базы
данных, первоначально специфицированных в предложении
CREATE DATABASE, - например, имя базы данных, или
значения MAXDATAFILES, MAXLOGFILES, MAXLOGMEMBERS,
MAXLOGHISTORY либо MAXINSTANCES. (Например, вам может
потребоваться изменить имя базы данных, конфликтующее с
именем другой базы данных в распределенной базе данных.
Или вы хотите увеличить слишком низкое значение одного из
параметров, перечисленных выше.)
6-4 Руководство администратора
Вы создаете новый управляющий файл, используя команду CREATE
CONTROLFILE. Используйте следующую процедуру для создания
нового управляющего файла.
Замечание: Команда CREATE CONTROLFILE может потенциально
повредить специфицированные в ней файлы данных и файлы
онлайнового журнала; если вы опустите имя какого-либо из файлов,
это приведет к потере всех данных в этом файле, или даже всей
базы данных. Будьте осторожны, используя эту команду, и
тщательно следуйте описанной ниже процедуре:
1. Составьте список всех файлов данных и файлов онлайнового
журнала базы данных (см. "Получение списка файлов базы
данных перед копированием" на странице 18-6). Если вы
следовали рекомендациям по копированию базы данных, то у вас
уже есть список всех файлов данных и файлов журнала,
отражающий текущую структуру базы данных. Если у вас нет
такого списка, а ваш управляющий файл поврежден, и база
данных не открывается, то вам лучше всего вручную найти все
файлы данных и файлы журнала, составляющие базу данных. (Все
файлы, которые не будут специфицированы на шаге 5, нельзя
будет восстановить после создания нового управляющего файла;
более того, если вы забудете указать один из файлов,
составляющих табличное пространство SYSTEM, то вы вообще не
сможете восстановить базу данных.)
2. Если база данных открыта, остановите ее в нормальном режиме,
если возможно. Прибегайте к опциям IMMEDIATE или ABORT лишь
как к последней возможности.
3. Сделайте копии всех файлов данных и файлов онлайнового
журнала с помощью процедуры, описанной в секции "Выполнение
полного копирования" на странице 18-7.
4. Запустите новую инстанцию, но не монтируйте и не открывайте
базу данных.
Создайте новый управляющий файл для базы данных с помощью
команды CREATE CONTROLFILE. Например, следующее предложение
создает новый управляющий файл для базы данных PROD (которая
раньше имела иное имя):
CREATE CONTROLFILE
SET DATABASE prod
LOGFILE GROUP 1 ('logfile1A', 'logfile1B') SIZE 50K,
GROUP 2 ('logfile2A', 'logfile2B') SIZE 50K
NORESETLOGS
DATAFILE 'datafile1' SIZE 3M, 'datafile2' SIZE 5M
MAXLOGFILES 50
MAXLOGMEMBERS 3
MAXDATAFILES 200
MAXINSTANCES 6
ARCHIVELOG;
При создании нового управляющего файла выбирайте опцию
RESETLOGS, если вы, кроме управляющих файлов, потеряли и одну
Управление управляющими файлами 6-5
из групп онлайнового журнала повторения. В этом случае вам
потребуется восстанавливаться от потери журнала на шаге 8.
В противном случае выбирайте опцию NORESETLOGS.
6. Сделайте копию нового управляющего файла на резервное
устройство.
7. Отредактируйте файлы параметров базы данных, чтобы отразить в
параметре CONTROL_FILES новые управляющие файлы.
8. Если требуется, выполните восстановление базы данных. Если
новый управляющий файл был создан с опцией NORESETLOGS, то вы
можете осуществить полное восстановление закрытой базы данных
(см. страницу 19-18). Однако, если новый управляющий файл
был создан с опцией RESETLOGS, то вы должны при
восстановлении специфицировать USING BACKUP CONTROL FILE (см.
страницу 19-23); если вы потеряли файлы онлайнового или
архивированного журнала либо файлы данных, используйте
процедуры восстановления для этих файлов (см. "Потеря файлов
онлайнового журнала" на странице 19-29 и "Потеря файлов
данных" на странице 19-28).
9. Откройте базу данных, используя один из следующих методов:
* ЕСЛИ ВЫ НЕ ВЫПОЛНЯЛИ ВОССТАНОВЛЕНИЯ, откройте базу
данных нормально.
* ЕСЛИ ВЫ ВЫПОЛНЯЛИ ПОЛНОЕ ВОССТАНОВЛЕНИЕ ЗАКРЫТОЙ БАЗЫ
ДАННЫХ на шаге 8, используйте опцию Open Database в меню
Instance SQL*DBA.
* ЕСЛИ ВЫ ИСПОЛЬЗОВАЛИ ОПЦИЮ RESETLOGS ПРИ СОЗДАНИИ НОВОГО
УПРАВЛЯЮЩЕГО ФАЙЛА, используйте команду ALTER DATABASE с
опцией RESETLOGS.
Теперь база данных открыта и готова к работе.
Проверка потерянных или лишних файлов
После создания нового управляющего файла и открытия с ним базы
данных, проверьте файл ALERT, чтобы выяснить, не обнаружил ли
ORACLE несоответствий между словарем данных и управляющим
файлом, например, таких, когда файлы данных, перечисленные в
управляющем файле, отсутствуют в словаре данных.
Если файл данных, указанный в словаре данных, отсутствует в
новом управляющем файле, то ORACLE добавляет этот файл в
управляющий файл и переименовывает его в словаре данных в
MISSINGnnnn; вы сами должны переименовать этот файл должным
образом. Наоборот, если файл данных, указанный в управляющем
файле, отсутствует в словаре данных, то ORACLE удаляет ссылку на
него из нового управляющего файла. В обоих случаях ORACLE
записывает в файл ALERT поясняющее сообщение, так что вы можете
выяснить, что произошло.
Обработка ошибок во время CREATE CONTROLFILE
Если ORACLE посылает вам ошибку (обычно ORA-01173, ORA-01176,
ORA-01177, ORA-01215 или ORA-01216), когда вы пытаетесь
6-6 Руководство администратора
смонтировать и открыть базу данных после создания нового
управляющего файла, то наиболее вероятная причина - то, что вы
опустили какой-нибудь нужный файл в предложении CREATE
CONTROLFILE, или наоборот, включили ненужный файл. В этом
случае вы должны реставрировать файлы, которые вы скопировали на
шаге 3, и повторить процедуру с шага 4, используя корректные
имена файлов.
Замечание: Для дополнительной информации о команде CREATE
CONTROLFILE обратитесь к документу ORACLE7 Server SQL Language
Reference Manual.
----------------
Удаление управляющих файлов
Вы можете удалять управляющие файлы из базы данных; например,
вам может потребоваться это, если для управляющего файла было
выбрано неподходящее место. Однако в базе данных всегда должно
оставаться по меньшей мере два управляющих файла.
Чтобы удалить управляющий файл из базы данных, сделайте
следующее:
1. Остановите базу данных.
2. Выйдите из SQL*DBA.
3. Отредактируйте параметр CONTROL_FILES в файле параметров базы
данных, удалив из него старое имя управляющего файла.
4. Вызовите SQL*DBA.
5. Перезапустите базу данных.
Эта операция не выполняет физического удаления ненужного
управляющего файла с диска; закончив ее, вы можете удалить файл
средствами операционной системы. (См. ваше руководство по
инсталляции [IUG]).