1.     Цель работы

Получение практических навыков администрирования и сопровождения логической и физической структур базы данных.

2. Методические указания

Лабораторная работа направлена на ознакомление с основами администрирования СУБД Oracle: работа с табличными пространствами, файлами данных, резервное копирование и восстановление базы данных.

 Требования к выполнению лабораторного практикума:

-       Выполнять все действия строго в том порядке, указанном в задании;

-       Составить отчет о проделанной работе;

-       В отчете должны содержаться снимки экрана, показывающие процесс выполнения заданий;

-       Отчет должен содержать выводы по результатам каждого выполненного задания;

-       Работа должна быть выполнена согласно требованиям к выполнению лабораторной работы;

-       Особое внимание следует уделить правильности задания переменной окружения ORACLE_SID; перед выполнением лабораторной работы рекомендуется сделать резервную копию файлов, расположенных в каталоге /opt/oracle/OraHome1/oradata/testN, N=1..10.

Перед выполнением упражнений вам предстоит выполнить следующие действия:

1.     Проверьте переменную окружения ORACLE_SID:

                   echo $ORACLE_SID;

2.     Задайте

          ORACLE_SID=testN, N=1..10, выполнив команду

                  #export ORACLE_SID=testN;

3.    Подсоединитесь к БД с помощью программы svrmgrl

            #svrmgrl

            SVRMGRL> connect internal

При составлении и оформлении отчета следует придерживаться «Требований к оформлению дипломных, курсовых, лабораторных работ», расположенных на странице http://unesco.kemsu.ru/student/rule/rule.html.

3. Теоретический материал

Введение

Для небольшой базы данных достаточно создать одно табличное пространство SYSTEM; однако, Oracle рекомендует создавать дополнительные табличные пространства для хранения данных и индексов пользователя, сегментов отмены, временных сегментов отдельно от словаря данных. Это обеспечивает вам большую гибкость в выполнении различных задач администрирования и уменьшает конкуренцию при обращении к объектам словаря и схемы.

Администратор может создавать новые табличные пространства, изменять размер файлов данных, добавлять файлы к табличным пространствам, устанавливать и изменять параметры хранения по умолчанию сегментов в табличном пространстве, переводить табличное пространство в состояние «только чтение» или «чтение-запись», делать табличное пространство временным или постоянным или удалить его.

Табличное пространоство system и другие

1. Табличное пространство system:

-       создается во время создания базы данных

-       содержит словарь данных

-       содержит сегмент отмены system

2. Другие табличные пространства:

-       отделяют сегменты

-       обеспечивают большую гибкость решения задач администрирования пространства

-       дают возможность контролировать выделение
пространства пользователю

Создание табличных пространств

Табличное пространство может быть создано при помощи следующей команды:

 CREATE TABLESPACE табличное_пространство

 [DATAFILE фраза_файла_данных]

 [MINIMUM EXTENT целое[К|М]]

[BLOCKSIZE целое   [К]]

 [LOGGING|NOLOGGING]

 [DEFAULT фраза_хранения ]

 [ONLINE I OFFLINE]

 [PERMANENT I EMPORARY]

 [extent_management_clause]

[autoextend_clause]

Файлы параметров инициализации:

табл_пространство – имя табличного пространства, которое требуется создать.

DATAFILE –задает файл или файлы данных, составляющие это табличное пространство. Для временных табличных пространств можно использовать TEMPFILE.

MINIMUM EXTENT – обеспечивает то, что размер каждого экстента этого табличного пространства кратен целому (используйте К и М для указания размера в килобайтах и мегабайтах).

BLOCKSIZE – указывает размер блока данных, с которым будет создано табличное пространство. Необходимо указать параметр инициализации DB_nK_CACHE_SIZE (n- 2,4,8,16 или 32, размер блока) для этого размера блока. Он устанавливает размер кэша буферов для обслуживания табличных пространств с указанным размером блока. Можно указать до 4 параметров. По умолчанию используется стандартный размер блока и кэш буферов по умолчанию, заданный параметром инициализации DB_CACHE_SIZE.

LOGGING – указывает, что по умолчанию все изменения таблиц, индексов и секций табличного пространства записываются в журнал (режим LOGGIN установлен в команде по умолчанию).

NOLOGGING – указывает, что по умолчанию все изменения таблиц, индексов и секций табличного пространства не записываются в журнал (режим NOLOGGIN затрагивает только некоторые команды DML и DDL, например, использующие прямую загрузку).

DEFAULT – задает  параметры хранения по умолчанию для всех объектов, которые будут созданы в данном табличном пространстве.

ONLINE – делает табличное пространство доступным сразу после создания.

OFFLINE – сразу  после создания табличное пространство будет недоступно.

PERMANENT – указывает на то, что это табличное пространство может быть использовано для хранения постоянных объектов.

TEMPORARY – указывает на то, что данное табличное пространство может хранить только временные объекты, например, сегменты, используемые фразой ORDER BY для неявной сортировки. Используется стандартный размер блока.

SIZE – задаёт размер файла (используйте К и М для задания размера файла).

REUSE – разрешает серверу Oracle повторно использовать существующий файл.

autoextend_clause OFF/ON – разрешает или запрещает автоматическое расширение файла данных: NEXT- какими кусками будет расширяться файл, MAXSIZE/UNLIMITED- до какого максимального размера.

Пример создания нового табличного пространства:

CREATE TABLESPACE userdata

DATAFILE '/u01/oradata/userdata01.dbf 

SIZE 100M

AUTOEXTEND ON NEXT 5M

MAXSIZE 200M; 

Табличные пространства «только для чтения»

Команда alter tablespace...read only.

Перевод табличного пространство в режим только для чтения запрещает последующие операции записи в файлы данных. Табличные пространства «только для чтения» используются для предотвращения каких-либо изменений и для отмены необходимости выполнять резервирование и восстановление больших, статичных областей базы данных. Сервер Oracle никогда не обновляет файлы табличного пространства, используемого только для чтения, и, поэтому эти файлы могут располагаться на носителях, запись на которые невозможна, таких как CD-ROM.

Табличное пространство может быть переведено в режим только для чтения или «чтение-запись» при помощи команды ALTER TABLESPACE:

ALTER TABLESPACE табличное_пространство READ  [ONLY | WRITE]

Перевод табличного пространства в режим
 «только чтение»

-       Команда ALTER TABLESPACE...READ ONLY переводит табличное пространство в режим «только чтение», не дожидаясь завершения всех активных транзакций. В этом режиме не разрешаются никакие последующие операции записи в табличное пространство, за исключением отката текущих транзакций, которые до этого модифицировали блоки табличного пространства. После того, как выполнится фиксация или откат всех текущих транзакций, команда alter tablespace ... read only завершается и табличное пространство переводится в режим «только чтение». 

-       Вы можете удалять из табличного пространства «только чтение» такие объекты, как таблицы и индексы, так как эти команды вносят изменения только в словарь данных, но не в файлы данных табличного пространства. 

-       Перед переводом табличного пространства «только чтение» в режим «чтение-запись», все файлы данных табличного пространства должны быть в оперативном режиме. 

-       Перевод табличного пространства в режим «только чтение»

-       Активизирует контрольную точку для файлов данных табличного пространства.

Автономный режим

Табличное пространство, находящееся в автономном режиме, не разрешает доступа к данным.

 Некоторые табличные пространства должны находиться всегда в оперативном режиме:

-       SYSTEM;

-       табличные пространства, содержащие активные сегменты отмены;

-       временное табличное пространство по умолчанию;

Перевод в автономный режим: ALTER TABLESPACE userdata OFFLINE;

     Перевод в оперативный режим: ALTER TABLESPACE userdata ONLINE;

Перевод табличных пространств в автономный режим (offline)

Пользователи могут получить доступ к табличному пространству, только если оно находится в оперативном режиме. Табличное пространство может быть переведено администратором базы данных в автономный режим для того, чтобы: 

-       сделать недоступной часть базы данных, тогда как оставшаяся ее часть будет работать в нормальном режиме;

-       выполнить резервирование табличного пространства в автономном режиме (хотя можно производить резервирование табличного пространства, которое находится в оперативном режиме и используется);

-       восстановить табличное пространство или файл данных, когда база данных открыта;

-       изменить местоположение файлов данных, когда база данных открыта.

Автономный режим таблиичного пространства

-       Сервер Oracle не позволяет никаким командам SQL выполнять операции над объектами, содержащимися в автономном табличном пространстве. Если пользователи пытаются получить доступ к объектам автономного табличного пространства либо непосредственно, либо при проверке ссылочной целостности, они получают сообщение об ошибке.

-       Информация о переходе табличного пространства в автономный режим или о возвращении в оперативный сохраняется в словаре данных и в управляющих файлах. Если табличное пространство находится в автономном режиме во время остановки базы данных, то оно останется таковым и не будет проверяться при последующем монтировании и открытии базы данных.

-       Экземпляр Oracle автоматически переключает табличное пространство из оперативного режима в автономный, когда возникают ошибки определенного вида (например, когда процесс Database Writer в ходе нескольких попыток не может произвести запись в файл данных табличного пространства).

В следующих командах с помощью фразы AUTOEXTEND включается или отключается автоматическое расширение файла данных:

-       CREATE DATABASE

-       CREATE TABLESPACE ... DATAFILE

-       ALTER TABLESPACE ... ADD DATAFILE

Используйте команду ALTER DATABASE, чтобы изменить файл данных и предоставить возможностью его автоматического расширения:

ALTER DATABASE DATAFILE спецификация_файла [фраза_авторасширения].

Если в табличном пространстве существует несколько файлов, расширяться будет тот, в котором, сервер захочет выделить экстент. Если в файле нет места, и он не может расширяться, будет взят другой файл. Если ни в одном файле нет места, и они не могут расширяться дальше, пользователь, чья команда требует, расширения сегмента получит ошибку.

фраза_авторасширения :== [ AUTOEXTEND { OFF | ON [NEXT целое [К |М]]   [MAXSIZE UNLIMITED | целое[К|М]] } ],

где:  

AUTOEXTEND OFF выключает автоматическое расширение файла данных.

 AUTOEXTEND ON   включает автоматическое расширение файла данных. NEXT устанавливает размер выделяемого дискового пространства, когда требуются дополнительные экстенты.

 MAX SIZE определяет максимальный размер дискового пространства, который может быть выделен файлу данных.

 UNLIMITED       снимает ограничение на максимальный размер дискового пространства для файла данных.

Пример установки автоматического расширения файла данных:

ALTER DATABASE DATAFILE

         '/u01/oradata/app_data_04.dbf‘

         SIZE 200M          AUTOEXTEND ON NEXT 10M    MAXSIZE 500M;

Изменение установки autoextend для существующего файла данных

Для включения или отключения автоматического расширения уществующего файла данных используется команда ALTER DATABASE:

ALTER DATABASE [database] DATAFILE 'имя_файла'[,'имя_файла']...фраза_авторасширения

Определение параметров AUTOEXTEND:

 DBA_DATA_FILES есть столбцы, показывающие параметры Авторасширения. Столбец AUTOEXTENSIBLE показывает включено или нет авторасширение:

 SQL> select tablespace_name,  file_name,  autoextensible from dba_data_files;

Например:

TABLESPACE_NAME  FILE_NAME    AUTOEXTENSIBLE

SYSTEM   /home/dbaOl/ORADATA/uOl/systemOl.dbf  YES

DATA01    /home/dba01/ORADATA/u04/data01.dbf NO

USERS       /home/dba01/ORADATA/u03/users01.dbf        NO

UNDO2      /horae/dba01/ORADATA/u01/UND02.dbf        NO

Изменение размера файлов данных вручную

Команда ALTER DATABASE DATAFILE RESIZE

Администратор может изменить размер существующего файла данных вместо того, чтобы увеличивать пространство базы данных при помощи создания новых файлов. Администратор может исправить ошибки, допущенные при планировании базы данных, и освободить неиспользуемое пространство. Для того чтобы уменьшить или увеличить размер файла данных вручную используется команда ALTER DATABASE следующего вида: 

ALTER DATABASE [база_данных]

DATAFILE 'имя_файла'[, 'имя_файла']...

 RESIZE целое[К|М]

где: целое- требуемый размер файла данных.

Если объекты базы данных располагаются в файле данных за указанным размером, то файл данных уменьшается только до последнего блока последнего объекта базы данных.

Добавление файлов данных к табличному пространству

Команда ALTER TABLESPACE ADD DATAFILE

При помощи следующей команды ALTER TABLESPACE ADD можно добавить к табличному пространству файл данных, чтобы увеличить общее количество дискового пространства, отведенного для этого табличного пространства :

ALTER TABLESPACE табличное_пространство

ADD   [DATAFILE   I   TEMPFILE  ]

спецификация_файла  [фраза_авторасширения]

 [,спецификация_файла  [фраза_авторасширения]]...

Файлы добавляют, если в текущем разделе диска нет места или превышено ограничение на максимальный размер файла в операционной системе.

ALTER TABLESPACE: перемещение файлов данных

Методы перемещение файлов данных.

Администратор базы данных может изменять местоположение файлов данных в зависимости от вида табличного пространства одним из следующих двух способов: при помощи команд ALTER TABLESPACE или ALTER DATABASE.

 Использование команды ALTER TABLESPACE.

Команда ALTER TABLESPACE следующего вида применяется только для файлов данных, не принадлежащих табличному пространству SYSTEM, которое, к тому же, не содержит активных сегментов отмены или временных сегментов. Более того, она работает только в режиме открытой базы данных.

ALTER TABESPACE табличное_пространство RENAME DATAFILE   'имя_файла'[,   'имя_файла']... ТО 'имя_файла'[,   'имя_файла' ]

Для переименования файла данных выполняется следующая последовательность шагов:

1.     Переведите табличное пространство в автономный режим.

2.     Переместите или скопируйте файлы при помощи команд операционной системы.

3.     Выполните команду ALTER TABLESPACE RENAME DATAFILE.

4.     Верните табличное пространство в оперативный режим.

5.     Если требуется, удалите файл при помощи команды операционной системы. Имя исходного файла должно совпадать с именем в управляющем файле.

ALTER DATABASE: перемещение файлов данных

Для перемещения любого вида файла данных может быть использована команда ALTER DATABASE (см. занятие "Сопровождение журнальных файлов"). В отличие от предыдущей команды, она работает как в режиме открытой базы данных, так и в режиме смонтированной базы. 

ALTER DATABASE [база_данных]RENAME FILE

'имя_файла'[, 'имя_файла']... ТО 'имя_файла'[, 'имя_файла']... 

Файлы табличного пространства SYSTEM , которые не могут быть переведены в автономный режим, переименовываются следующим образом:

1.     Остановите экземпляр.

2.     Переместите файлы при помощи команды операционной системы.

3.     Смонтируйте базу данных.

4.     Выполните команду ALTER DATABASE RENAME FILE.

5.     Откройте базу данных.

Удаление табличных пространств

-       Нельзя удалять табличное пространство SYSTEM и содержащее активные сегменты отката.

-       Информация о табличном пространстве удаляется из словаря данных.

-       В команде удаления табличного пространства необходимо указывать режим удаления его содержимого.

-       При помощи команды  DROP TABLESPACE табличные пространства можно удалить из базы данных, когда отпала надобность в них самих и в их содержимом:

DROP TABLESPACE табличное_пространство 

[INCLUDING CONTENTS [AND DATAFILES] [CASCADE CONSTRAINTS]] 

где:

-       табличное_пространство - имя табличного пространства, которое требуется удалить

-       INCLUDING CONTENTS - удаляет все сегменты табличного пространства

-       AND DATAFILES - удаляет соответствующие файлы ОС

-       CASCADE CONSTRAINTS - удаляет те ссылочные правила целостности таблиц из других табличных пространств, которые ссылаются на первичные и уникальные ключи таблиц, принадлежащих удаляемому табличному пространству

Табличное пространство, содержащее данные, не может быть удалено без использования параметра INCLUDING CONTENTS. Использование этого параметра может привести к генерации большого объема информации отмены, если в табличном пространстве находится много объектов.

Данные табличного пространства перестают существовать в базе данных, как только оно удаляется.

При удалении табличного пространства удаляются только файловые указатели из управляющего файла соответствующей базы данных. Файлы базы данных остаются и должны быть удалены явно на уровне операционной системы, если в команде отсутствует фраза AND DATAFILES .

Табличное пространство в режиме только для чтения тоже может быть удалено вместе со своими сегментами. Это возможно потому, что команда DROP обновляет словарь данных (который должен быть в режиме чтение-запись), а не физические файлы, составляющие базу данных.

Для того чтобы во время удаления табличного пространства не существовало транзакций, пытающихся получить доступ к сегментам этого табличного пространства, рекомендуется перевести его в автономный режим.

Получение информации о табличном пространстве

Информация о табличном пространстве:

-       DBA_TABLESPACES

-       V$TABLESPACE

Информация о файле данных:

-       DBA_DATA_PILES

-       V$DATAFILE

Информация о временном файле:

-       DBA_TEMP_FILES

-       V$TEMPFILE

Резервное копирование и восстановление

Восстановление вручную

1.     Выполнить физическое восстановление файла означает заменить его резервной копией.

2.     Восстановлению обычно подлежат следующие файлы:

-       файлы данных;

-       управляющие файлы;

-       архивные журнальные файлы;

-       серверный файл параметров.

3.     В каждом случае потеря основного файла  и восстановление его из резервной копии приводит к следующим последствиям при восстановлении носителя.

Хранение записей для последующего использования в ходе восстановления

Одним из наиболее важных аспектов резервирования и восстановления, управляемого пользователем, является хранение записей обо всех файлах текущей базы данных и резервных копиях этих файлов. Например, у вас должны быть записи о местоположении следующих файлов:

-       Файлы данных;

-       Управляющие файлы;

-       Оперативные журнальные файлы (обратите внимание, что оперативные журналы не резервируются);

-       Архивные журнальные файлы;

-       Файлы параметров инициализации;

-       Файлы паролей;

-       Файлы настроек сетевых компонентов;

Запись местоположения файлов данных, управляющих файлов и оперативных журнальных файлов

Следующий полезный командный файл SQL выводит местоположение всех управляющих файлов, файлов данных и оперативных журнальных файлов базы данных:

SELECT NAME FROM V$DATAFILE

UNION ALL

SELECT MEMBER FROM V$LOGFILE

UNION ALL

SELECT NAME FROM V$CONTROFILE;

Выходные данные могут выглядеть следующим образом:

NAME

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

/oracle/dbs/tbs_01.f

/oracle/dbs/tbs_02.f

/oracle/dbs/tbs_11.f

/oracle/dbs/tbs_12.f

/oracle/dbs/t1_log1.f

/oracle/dbs/t1_log2.f

/oracle/dbs/cf1.f

/oracle/dbs/cf2.f

Запись местоположений резервных копий файлов

Недостаточно просто записывать местоположение резервных копий файлов: необходимо устанавливать соответствие между резервными копиями и исходными файлами. По возможности, присваивайте резервным копиям такие же относительные имена, как и у основных файлов. Независимо от используемой системы именования, храните таблицу с соответствующей информацией. Например, можно хранить следующую таблицу с информацией о местоположении файлов базы данных на случай восстановления.

Определение файлов  данных, требующих восстановления

Динамическое представление производительности V$RECOVER_FILE позволяет определить, какие файлы нужно восстановить из резервных копий при подготовке к восстановлению носителя. В этом представлении содержатся все файлы, требующие восстановления, и даются объяснения, почему они Должны быть восстановлены.

Следующий запрос отображает идентификационные номера файлов данных, требуемых для восстановления носителя, а также причину восстановления (если она известна), а также ЗСК и время, с которых нужно начать восстановление:

SELECT * FROM V$RECOVER_FILE;

FILE#    ONLINE    ERROR CHANGE#   TIME

_ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ __ _ _ _ _ _ _

           14 ONLINE

           15 ONLINE  FILE NOT FIND            0

           21 ONLINE  OFFLINE NORMAL     0

Повторное создание файлов данных при отсутсвии резервных копий

Когда файл данных поврежден, а его резервная копия недоступна, этот файл данных все же можно восстановить, если:

-       доступны все архивные журнальные файлы, сгенерированные после создания исходного файла данных;

-       управляющий файл содержит имя поврежденного файла (это значит, что управляющий файл является текущим или восстановленным из резервной копии, сделанной после того, как поврежденный файл данных был добавлен в базу данных).

Чтобы повторно создать файл данных для восстановления:

1.     Создайте новый, пустой файл данных для замены поврежденного файла данных, у которого нет соответствующей резервной копии. Предположим, например, что поврежден файл данных /disk1/users1.f и его резервная копия недоступна. Следующий оператор повторно создает исходный файл данных (того же размера) на диске disk2:

ALTER DATABASE CREATE DATAFILE ‘/disk1/users1.f’ AS ‘/disk2/users1.f’;

Данный оператор создает пустой файл того же размера, что и потерянный файл. Oracle ищет информацию о размере файла в управляющем файле и словаре данных. Исходному файлу данных присваивается имя нового файла данных.

2.     Выполните восстановление носителя дня пустого файла данных. Например, введите:

RECOVER DATAFILE ‘/disk2/users1.f’

3.     Все архивные журналы, сгенерированные после создания исходного файла данных, должны быть доступны и повторно применены к новой, пустой версии потерянного файла данных во время восстановления.

Восстановление и повторное создание управляющих файлов

Если сбой носителя повредил управляющие файлы базы данных (независимо от того, мультиплексированы они или нет), база данных продолжает работать до тех пор, пока какому-либо процессу сервера Oracle не потребуется получить доступ к управляющим файлам. В этот момент база данных и экземпляр автоматически останавливаются.

Если сбой носителя был временным и база данных до сих пор не остановлена, не допускайте автоматической остановки базы данных – немедленно исправляйте сбой. Однако если остановка базы данных происходит до исправления временного сбоя носителя, ее можно повторно запустить после устранения проблемы и восстановления доступа к управляющим файлам.

Процедура восстановления после сбоя носителя, который делает невозможным доступ к управляющим файлам базы данных, зависит от того, мультиплексированы эти управляющие файлы или нет. Соответствующие процедуры описаны в следующих разделах:

-       Потеря одного из элементов мультиплексированного управляющего файла.

-       Потеря всех элементов мультиплексированного управляющего файла, когда резервная копия доступна.

-       Потеря всех текущих и резервных управляющих файлов.

Потеря одного из элементов мультиплексированного управляющего файла

Следующие процедуры используются для восстановления базы данных после сбоя носителя, который привел к повреждению одного или нескольких управляющих файлов базы данных, но при этом как минимум один управляющий файл остался неповрежденным.

Копирование мультиплексированного управляющего файла в местоположение по умолчанию

Если диск и файловая система, содержавшие потерянный управляющий файл, остались невредимы, можно просто скопировать один из неповрежденных управляющих файлов туда, где находился потерянный управляющий файл. В этом случае вам не придется изменять значение параметра инициализации CONTROL_FILES.

Чтобы заменить поврежденный управляющий файл путем копирования мультиплексированного управляющего файла:

1.     Остановить экземпляр, если он еще работает: SHUTDOWN ABORT.

2.     Устраните аппаратную проблему, которая привела к сбою носителя. Если не удается быстро решить эту проблему, переходите к восстановлению базы данных – восстановите поврежденный управляющий файл на другом запоминающем устройстве, как описано в разделе «Копирование мультиплексированного управляющего файла в местоположение, отличное от используемого по умолчанию ».

3.     Замените поврежденные управляющие файлы неповрежденной мультиплексированной копией текущего управляющего файла базы данных. Например, чтобы заменить файл bad_cf.f файлом good_cf.f введите: % cp /oracle/good_cf.f /oracle/dbs/bad_cf.bad

4.     Запустите новый экземпляр, смонтируйте и откройте базу данных. Например, введите: STARTUP

Потеря всех элементов мультиплексированного запоминающего файла, когда резервная копия доступна

Следующие процедуры для восстановления управляющего файла из резервной копии при сбое носителя, который привел к повреждению всех управляющих файлов базы данных. Если управляющий файл недоступен, можно запустить экземпляр, но не монтировать базу данных. Если попытаться смонтировать базу данных, когда управляющий файл недоступен, появится следующее сообщение об ошибки:

ORA-00205: ошибка определения управляющего файла, дополнительную информацию см. в сигнальном файле ALERT

Нельзя смонтировать и открыть базу данных до тех пор, пока управляющий файл не будет снова доступным. Если управляющий файл восстанавливается из резервной копии, необходимо открыть базу данных с опцией RESETLOGS.

Как видно из Таблицы, процедура восстановления управляющего файла зависит от того, доступны ли журналы.

Таблица 1- Сценарии восстановления потерянных управляющих файлов

ВОССТАНОВЛЕНИЕ УПРАВЛЯЮЩГО ФАЙЛА ИЗ РЕЗЕРВНОЙ КОПИИ В МЕСТОПОЛОЖЕНИИ ПО УМОЛЧАНИЮ

По возможности, восстанавливайте управляющий файл в его исходном местоположении. В этом случае вам не придется указывать новые местоположения управляющего файла в файле параметров инициализации.

Чтобы восстановить управляющий файл в местоположении по умолчанию:

1.     Остановите экземпляр, если он еще работает: SHUTDOWN ABORT

2.     Устраните аппаратную проблему, которая привела к сбою носителя.

3.     Восстановите управляющий файл из резервной копии во всех местоположениях, указанных в параметре инициализации CONTROL_FILES. Например, если в файле параметров сервера указаны местоположения управляющего файла /dsk/oracle/dbs/cf1.f и /dsk/cf2.f, используйте утилиту операционной системы для восстановления управляющего файла в этих местоположениях:

% cp /backup/cf.bak /dsk1 /oracle/dbs/cf1.f

% cp /backup/cf.bak /dsk2/cf2.f

4.     Запустите новый экземпляр и смонтируйте базу данных. Например, введите: STARTUP MOUNT

5.     Начните восстановление выполнением оператора RECOVER с предложением USING BACKUP CONTROLFILE. Укажите предложение UNTIL CANCEL, если вы выполняете неполное восстановление. Например, введите:

 RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL

6.     Примените запрошенные архивные журналы. Если появится сообщение о том, что требуемый архивный журнал отсутствует, значит, необходимая запись, вероятно, находится в оперативном журнале. Эта ситуация может возникнуть, если незаархивированные изменения находились в оперативных журналах, когда произошел сбой экземпляра. Например, предположим, что вы видите следующее сообщение:

ORA-00279: изменение 55636, созданное 06/08/2000 в 16:59:47, необходимое для потока 1

ORA-00289: предложение /oracle/work/arc_dest/arcr_1_111.arc

ORA-00280: изменение 55636 для потока 1 находится в последовательности #111

Задайте журнал: (<RET>=предлагаемое | имя файла | AUTO | CANCEL)

Можно указать имя оперативного журнала и нажать Enter (возможно, придется сделать это несколько раз до тех пор, пока не будет найден нужный журнал):

/oracle/dbs/t1_log1.f

Журнал применен.

Восстановление носителя завершено.

Если по каким-либо причинам оперативные журналы недоступны, можно прекратить восстановление и не применять оперативные журналы. Обратите внимание, что если все файлы данных являются текущими и требуемые для восстановления записи находятся в оперативных журналах, базу данных нельзя открыть без применения оперативных журналов. Если оперативные журналы недоступны, необходимо повторно создать управляющий файл.

7.     Откройте базу данных в режиме RESETLOGS после завершения восстановления:

ALTER DATABASE OPENRESETLOGS;

4. Порядок выполнения работы

1.                            Сопровождение табличных пространств и файлов данных

1.     Создайте постоянные табличные пространства со следующими именами и параметрами хранения:

         DATA01, управляемое с помощью словаря данных.

         DATA02, с экстентами одинакового размера (размер каждого экстента должен быть кратен 100 Кб.) (включите автоматическое расширение с выделением пространства размером 500 Кб и максимальным размером 2 Мб.

         RONLY для таблиц, доступных только на чтение с параметрами хранения по умолчанию.

НЕ СОЗДАВАЙТЕ табличное пространство в режиме «только чтение» в данный момент времени.

2.     Выведите информацию из словаря данных.

3.     Выделите дополнительно 500Кб для табличного пространства DATA02 . Проверьте результат.

4.     Переместите табличное пространство DATA01 в другой каталог (оба способа).

5.     Добавьте файл данных для табличного пространства DATA01.

6.     Измените размер фала данных для DATA01 вручную.

7.     Создайте таблицу в табличном пространстве RONLY. Переведите RONLY в режим «только чтение».

8.     Попытайтесь создать еще одну таблицу. Удалите первую таблицу. Что произошло и почему?

9.     Удалите табличное пространство RONLY и соответствующий файл данных. Проверьте результат.

2.          Резервное копирование и восстановление

1.     Выполните резервное копирование управляющих файлов и файлов данных.

2.     Удалите один из файлов данных.

3.     Выполните восстановление удаленного файла путем создания нового файла данных.

4.     Удалите все управляющие файлы.

5.     Восстановите управляющие файлы из резервной копии.

6.     Проверьте работоспособность БД.

5. Содержание отчета

В отчете следует указать:

-       Цель работы

-       Введение

-       Программно-аппаратные средства, используемые  при выполнении работы.

-       Основную часть (описание самой работы), выполненную согласно требованиям к результатам выполнения лабораторного практикума.

-       Заключение (выводы).

-       Список используемой литературы.

6.  Литература

1. С. В. Глушаков, Ю. В. Третьяков, О. А. Головаш Администрирование Oracle 9i, 2003 г.

2. Марлен Терьо, Рэчел Кармайкл, Джеймс Вискузи Oracle 9i DBA 101. Администрирование баз данных, 2005 г.

3. Том Кайт Oracle для профессионалов, 2003.

4. Oracle Documentation Library, http://oldunesco.kemsu.ru/ora_docs.