|
|
ГЛАВА 1 ЧТО ТАКОЕ ORACLE ?
I am Sir Oracle,
And when I ope my lips, let no dog bark !
Shakespeare: The Merchant of Venice
В этой главе дается введение в Систему Управления Реляционной
базой данных ORACLE (RDBMS). В ней определяются основные термины
и понятия, лежащие в основе последующих глав этого руководства.
Эта глава описывает:
* различие между ORACLE Version 6 с опцией обработки транзак-
ций и без опции обработки транзакций
* язык SQL, на котором базируются инструментальные средства
ORACLE
* как идентифицировать версии программного обеспечения ORACLE
* определение терминов базы данных, экземпляра, системы баз и
их компонентов.
Почему реляционная ?
В течение последних нескольких лет системы управления реляционными базами
данных стали наиболее широко распространенным способом управления данными.
Реляционные системы имеют следующие преимущества:
* простота доступа к любым данным
* гибкость моделирования данных
* уменьшение памяти под данные и снижение избыточности
* независимость физических данных от их логической структуры
* язык манипулирования данными высокого уровня (SQL).
Так как технология, связанная с управлением реляционными базами данных, в
последние годы развивалась очень быстро, обращение к реляционным базам данных
стало более популярным в широких кругах пользователей.
Феноменальное развитие реляционной технологии позволило разработать СУБД
для широкого диапазона оборудования от персональных компьютеров до больших,
высокоскоростных процессоров и для пользователей от случайных до наиболее
искушенных.
Почему выбрана СУБД ORACLE ?
Oracle Corporation была первой компанией, представившей коомерческую
версию реляционной СУБД, и продолжающей вносить новое в области систем
управления базами данных. Стратегия Oracle Corporation, заключающаяся в
предложении переносимости, совместимости и взаимосвязи в области СУБД дала в
результате пользователям очень мощный инструмент для работы. Сперва Вы изучаете
базоые концепции, а затем можете применять их для широкого диапазона аппаратуры
и программного обеспечения.
Что такое Опция Обработки Транзакции ?
В этом руководстве описываются две версии программного продукта ORACLE:
* ORACLE RDBMS Version 6.0 с опцией обработки транзакций
* ORACLE RDBMS Version 6.0 без опции обработки транзакций
-- 19 --
СУБД ORACLE - это высокопроизводительная, защищенная от сбоев система
управления базой данных, разработанная специально для обработки транзакций в
режиме on-line и больших баз данных.
ORACLE RDBMS V6 содержит множество изменений как в самой базе данных, так и в
языке SQL, что делает ее гораздо более мощной по сравнению с более ранними
версиями. Эти улучшения включают в себя:
* косвенную запись при операции commit для улучшения обработки транзакций
* усовершенствованное управление использованием внешней памяти для DBA и
обычного пользователя
* откат и восстановление в режиме on-line, а также улучшенное протоколирование
* дополнительные возможности восстановления при сбоях
* контрольные точки и откат (rollback) на уровне операторов
* новый инструмент для администрации базы данных - SQL*DBA
* нарастающий экспорт.
Опция обработки транзакций представляет две дополнительные возможности,
которые способствуют более высокому уровню обработки транзакций:
* обработчик блокировок на уровне строк
* PL/SQL - процедурное расширение языка SQL.
ORACLE V6 как с опцией обработки транзакций, так и без нее содержит все
вышеперечисленные возможности за исключением последних двух (блокировки данных
на уровне строк и PL/SQL). В данном руководстве специально отмечаются различия
в версиях с опцией обработки транзакций и без нее, если это может быть
существенно для пользователей.
Язык SQL
В основе ORACLE RDBMS лежит язык манипулирования данными SQL (произносится -
"сикюэл") - это англо-подобный язык, использующийся в большинстве действий с
базой данных. SQL достаточно прост для того, чтобы даже начинающие пользователи
могли просто и быстро обращаться к данным, в то же время он достаточно мощный,
чтобы предоставить программистам те возможности и гибкость, которые им
требуются.
SQL был разработан и определен в исследовательском центре IBM, а затем
окончательно доработан в Американском Национальном Институте Стандартов (ANSI)
в качестве стандартного языка для реляционных систем управления базами данных.
Реализованный Oracle Corporation SQL является подмножеством стандартного
языка SQL. Все команды, встречающиеся в этой книге, либо операторы языка SQL,
либо команды SQL*DBA.
Операторы SQL
Эти операторы разработаны специально для данных, хранимых в реляционной
базе. Операторы SQL (называемые также командами) могут быть использованы во
многих средах, включающих продукты ORACLE (такие как SQL*Forms), утилиты
(например - SQL*DBA), а также пользовательские программы (например -
SQL*COBOL).
В оставшейся части этой главы обсуждаются основные категории операторов SQL.
За полным описанием SQL обратитесь ко "Справочному руководству по языку SQL".
В Приложении G содержится список операторов SQL, обычно используемых DBA.
Команды SQL*DBA
-- 20 --
Не надо путать команды SQL*DBA с операторами SQL. Эти команды помогают DBA
выполнять функции по поддержанию базы данных и могут быть использованы лишь в
утилите SQL*DBA. Эта книга - основное руководство по указанным командам;
справочник по ним находится в Приложении В.
Язык SQL предполагает, что данные в базе хранятся в таблицах (например - в
таблице EMP). Каждая таблица определяется своим именем и набором колонок.
Каждая колонка характеризуется именем (например - EMPNO, ENAME, JOB) и типом
данных (например - CHAR для символьных, или NUMBER). В случае, если не
указано NOT NULL, колонки могут содержать пустые значения. Иногда колонки
называют полями или атрибутами.
Реальные значения данных находятся в строках таблиц (называемых также
записями или кортежами). Следующий пример строк взят из таблицы, обычно
используемой в документации по ORACLE: таблица с записями о служащих,
называемая EMP.
EMPNO ENAME JOB MGR HIREDATE SALARY COMM DEPTNO
----- ------- ------- ----- --------- ------- ----- ------
7329 SMITH CLERK 7902 17-DEC-80 800 300 20
7499 ALLEN SALESMAN 7698 20-FEB-81 1600 300 30
7521 WARD SALESMAN 7698 22-FEB-81 1250 500 30
7566 JONES MANAGER 7839 02-APR-81 2975 20
Операторы языка SQL обычно подразделяются на четыре категории:
* Запросы
* Операторы манипулирования данными (DML)
* Операторы определения данных (DDL)
* Операторы управления данными (DCL).
Для простоты эти категории обычно сводятся к двум (комбинируя первые две
как DML и вторые две как DDL). Иногда эти категории имеют различное
назначение в операциях с базой данных. В этой книге подразумевается, что Вы
понимаете, какой оператор SQL относится к какой категории. Каждая категория
вкратце описывается ниже.
Запросы
Запросами называются операторы, выбирающие данные в любой комбинации,
представлении или порядке. Обычно запросы начинаются с зарезервированного
слова SQL - SELECT с необходимыми последующими данными и таблицами (TABLE) или
обзорами (VIEW), содержащими исходные данные. Например:
SELECT ENAME, MGR
FROM EMP;
Запросы не меняют никаких данных, а только выбирают их. Обычно их относят к
операторам DML.
Операторы манипулирования с данными (DML)
Операторы DML используются для изменения данных одним из трех способов:
* вставка новых строк в таблицу (INSERT)
* изменение значений столбцов в существующих строках (UPDATE)
* удаление строк из таблиц (DELETE).
Приведем некоторые примеры операторов DML:
-- 21 --
INSERT INTO EMP VALUES (1234, 'DAVIS', 'SALESMAN', 7698,
'14-FEB-1988', 1600, 500, 30)
DELETE FROM EMP WHERE NAME IN ('WARD','JONES')
Наряду с запросами операторы DML являются обычно наиболее часто
используемыми. К операторам DML относятся также операторы LOCK, COMMIT WORK и
ROLLBACK WORK.
Операторы определения данных (DDL)
Операторы DDL используются для определения и поддержки объектов базы данных
(включая и таблицы базы), а также их отмены в случае, когда в них отпала
необходимость. Операторы DDL включают в себя все операторы CREATE (такие как
CREATE TABLE и CREATE VIEW) и соответствующие операторы CREATE и DROP.
Например:
CREATE TABLE PLANTS (COM_NAME CHAR 15, LAST_NAME CHAR 20)
DROP TABLE PLANTS
Операторы управления данными (DCL)
Операторы DCL используются для управления следующими двумя типами доступа:
* доступ к базе данных (используя, например, GRANT CONNECT)
* доступ к данным в базе (используя, например, GRANT SELECT или REVOKE DELETE).
Операторы DCL дают пользователю возможность позволить другим пользователям
просматривать, изменять данные в его таблицах, а также передавать его
привилегии другим пользователям (GRANT SELECT ... WITH GRANT OPTION).
Операторы управления данными также включают в себя операторы AUDIT.
Операторы DCL и DDL обычно объединяются вместе; реально ORACLE RDBMS
трактует их идентично.
PL/SQL: Расширение SQL
ORACLE с опцией обработки транзакций в ключает в себя процедурную
надстройку языка SQL, называемую PL/SQL. PL/SQL расширяет язык SQL,
представляя блочно структурированные процедурные конструкции в комбинации с
непроцедурными возможностями SQL. Особенности PL/SQL включают в себя:
* определение и назначение переменных
* управление по условию (IF, THEN, ELSE)
* организация циклов (FOR, WHILE, EXIT WHEN)
* реакции на особые ситуации.
Принципиальная улучшение PL/SQL состоит в том, что ORACLE с опцией
обработки транзакций может выполнить за один запрос вместо одного оператора SQL
- целую процедуру. Пользователи поставляемых приложений ORACLE получат
особенные преимущества благодаря улучшенному сетевому обмену.
Документация по PL/SQL содержится в "Руководстве пользователя и справочнике
по PL/SQL".
Система управления реляционной базой данных ORACLE
ORACLE RDBMS - это основной продукт фирмы системы ORACLE. Он включает в
себя систему для работы с базой данных и дополнительный набор функций,
помогающих пользователям и DBA поддерживать, отслеживать и использовать данные.
-- 22 --
В памяти RDBMS находится ядро. Ядро выполняет следующие функции:
* управляет определением и размещением данных
* управляет и разграничивает доступ и параллельную обработку
* позволяет откатывать и восстанавливать данные
* интерпретирует операторы SQL и PL/SQL.
Одной из частей ядра является оптимизатор. Он исследует альтернативные
пути доступа к данным с целью выполнения заданного запроса по оптимальному
пути. Например, он просматривает слова в запросе, пытаясь определить индекс,
который будет наиболее полезен для данного случая. Сам оптимизатор запроса не
выполняет.
В продукт ORACLE RDBMS включено несколько утилит. В данном руководстве
описаны утилиты, используемые преимущественно DBA.
SQL*DBA
Утилита DBA имеет несколько применений, включая старт и остановку базы данных,
отслеживание ее использования, а также выполнение отката и восстановления.
Полный справочник по командам SQL* DBA приведен в Приложении В.
CRT
Это утилита для определения характеристик экрана для полноэкранных
продуктов ( например - SQL*Forms), а также для назначения и модификации
функциональной клавиатуры. Эта утилита описана в "Руководстве пользователя
по утилитам ORACLE".
Export/Import
Это утилита для перемещения данных ORACLE из базы данных в файлы и
обратно. Операция Export может быть использована для архивации данных или для
переноса данных между базами ORACLE, работающими под управлением различных
операционных систем. Некоторая информация по экспорту/импорту может быть
найдена в Главе 15, более полно она описана в "Руководстве пользователя по
утилитам ORACLE".
SQL*Loader
Это пользовательская утилита для загрузки данных в таблицы базы данных
ORACLE из стандартных файлов операционной системы. Основное описание по
SQL*Loader находится в "Руководстве пользователя по утилитам ORACLE".
Другие продукты ORACLE
Ряд продуктов ORACLE предоставляет пользователям широкий диапазон возможностей
и инструментальных средств. Начинающие пользователи могут использовать полноэк-
ранные или управляемые через меню прикладные продукты. Искушенные пользователи
могут использовать для доступа к данным различные инструментальные средства.
Эти средства включают в себя крупномасштабные таблицы, интерактивные интерфейсы
или программные интерфейсы, доступные для различных языков программирования.
Идентификация версий программных продуктов ORACLE
Так как программные продукты претерпевают изменения и развиваются, в одно
и то же время могут использоваться несколько их различных версий. Для полной
идентификации версии программного продукта может потребоваться не менее пяти
чисел.
-- 23 --
Номер версии
Номер версии, например - Version 6, является наиболее общим идентификатором.
Новые версии появляются в случае значительного расширения функциональных
возможностей продукта.
Версия сопровождения
Номер версии сопровождения обозначает различные реализации основной
версии, начиная с нуля, например Version 6.0 или Version 6.1. Уровень версии
сопровождения повышается при исправлении ошибок или появлении у существующих
программ новых возможностей.
Уровень редакции
Уровень редакции обозначает специфический уровень объектных кодов. Это
число служит в Oracle Corporation для полной идентификации системы ORACLE.
Обычно продукт получает один уровень редакции для каждой версии сопровождения (н
Системнозависимая версия сопровождения
В некоторых операционных систем может потребоваться четвертое число для
идентификации версии сопровождения применительно к программному продукту для
данной системы. Это число может отличаться от номера версии сопровождения.
Сиситемнозависимый уровень редакции
В некоторых операционных системах может потребоваться пятое число для
идентификации особого уровня редакции применительно к операционной системе.
Например, дистрибутивная лента может быть помечена следующим образом:
6.0.20/1.3, что означает:
номер версии номер версии номер /системный номер
сопровождения редакции номер версии редакции
6 .0 .20 /1 .3
Если Oracle Corporation представляет новый продукт и заменяет существующие,
номер версии отдельных продуктов увеличивается неависимо от других. Например,
Вы можете иметь RDBMS V5.1.12.2, работающую с SQL*Forms V2.0.3, SQL*Plus V1.0.9
и PRO*FORTRAN V1.1.2 (эти числа даны только для иллюстрации).
Что такое система управления базой данных ORACLE ?
Система управления базой данных ORACLE может быть конфигурирована на
обеспечение широкого диапазона возможностей. Во всех конфигурациях пользо-
ватель обращается к базе данных (совокупность собственно базы данных и файлов
отката (см. Глоссарий)) через экземпляр ORACLE (программное обеспечение,
работающее с базой данных).
Рисунок 1-1 иллюстрирует многопользовательскую базу данных (разработанную
для параллельного доступа многих пользователей). Однопользовательские базы
данных несколько проще.
Ъ----------------------------------------------Дї
і SYSTEM GLOBAL AREA (SGA) і
А----------------------------------------------ДЩ
Разделяемые коды ORACLE
Ъ--Дї Ъ--Дї Ъ--Дї Ъ--Дї Ъ--Дї Ъ--Дї Ъ--Дї Ъ--Дї
-- 24 --
і S і і P і і D і і L і і A і іU і іU і іU і
і M і і M і і B і і G і і R і іS і іS і іS і
і O і і O і і W і і W і і C і іE і іE і іE і
і N і і N і і R і і R і і H і іR-1і іR-2і іR-3і
А--ДЩ А--ДЩ АДВДЩ АДВДЩ АДВДЩ А--ВЩ АДВДЩ АВ--Щ
Фоновые і і ^ ^ ^ ^
процедуры А----ДЕ----ДЕ----------ДЕДї і і
v і і v і і
Ъ--------------ї ЪБ----ДБ------ї ЪБДБ--Б----БДї
і і і Файлы і і і
і Управляющий і і журнала пов-і і Файлы і
і файл і і торного і ібазы данных і
і і і выполнения і і і
А--------------Щ А------------ДЩ А------------Щ
Рисунок 1-1 База данных ORACLE
Экземпляры системы и база данных взаимонезависимы. Экземпляр системы может
быть присоединен только к одной базе данных, хотя он может быть связан с
другими вазами данных через SQL*Net. Установление связи называется открытием
базы данных. База данных закрыта, когда экземпляр системы больше не требует
связи.
Когда экземпляр системы работает и связан с базой данных говорят, что экземпляр
системы стартован. Когда экземпляр системы остановлен (shut down), некоторая
база данных недоступна для использования. При каждом старте читается файл
конфигурации базы данных, обычно называемый INIT.ORA. Этот файл содержит
различные параметры, используемые для старта базы данных.
Администраторы базы данных (DBA) ответственны за старт и остановку экземпляров
системы. Они делают это с помощью утилиты SQL *DBA. Часто экземпляр системы
используется с одной базой данных, так что старт экземпляра системы может
автоматически открывать одну и ту же базу данных.
Что такое база данных ORACLE
База данных - это упорядоченный набор данных, с которым обращаются как с
единым целым. База данных состоит из файлов операционной системы. Физически
это собственно файл базы данных и файлы журнала повторного выполнения (redo log
files). Логически файлы базы данных содержат набор словарей и пользователь-
ских таблиц, а файлы журнала повторного выполнения содержат данные для
восстановления. Дополнительно базе данных требуется одна или несколько копий
управляющего файла. Это файл просто содержит информацию, которая
идентифицирует и определяет базу данных в покое.
Рисунок 1-2 показывает необходимые части базы данных ORACLE.
Файлы Журнал повтора Управляющий файл
базы данных (минимально (один или более
(один или много) два активных небольших файлов)
файла)
Ъ------------Дї Ъ------------Дї Ъ------------Дї
і і і і і і
і і і і і і
і і і і і і
А------------ДЩ А------------ДЩ А------------ДЩ
Рисунок 1-2 Компоненты базы данных ORACLE
-- 25 --
Перед тем, как использовать базу данных для хранения информации, она должна
пройти процесс, называемый созданием базы данных. Нет необходимости создавать
базу данных в случае, когда Вы переходите к другой версии программного
обеспечения ORACLE к другой.
Если все же создание базы данных необходимо, обычно оно производится последним
шагом процедуры инсталляции нового программного обеспечения ORACLE. Глава 13
описывает процесс создания базы данных и должна использоваться совместно с
Руководством по инсталляции и Руководством пользователя.
База данных идентифицируется именем базы данных, которое дается в момент
ее создания. Имя указывается в операторе CREATE DATABASE и должно быть
уникальным для каждого процессора. Некоторые операторы SQL и SQL*DBA при
использовании администратором базыы данных требуют указания имени базы
данных, большинство же пользователей это имя заботить не должно.
Базу данных можно определить на многих уровнях. Последующие главы описывают
логические и физические структуры, которые и составляют базу данных.
Глава 3 описывает файлы операционной системы, требуемые базе данных.
В Главе 4 описываются логические структуры высокого уровня базы данных:
память для таблиц (tablespaces) и сегменты.
Глава 5 описывает логические структуры пользовательского уровня
(таблицы, кластеры, индексы и образы ).
Глава 6 описывает типы данных ORACLE.
Глава 7 описывает словарь данных и как он отражает использование базы
данных.
Для того, чтобы база данных была доступна, она должна быть открыта
экземпляром системы ORACLE.
Что такое экземпляр ORACLE
Экземпляр ORACLE обеспечивает программный механизм для доступа к базе
данных и управления ею. Экземпляр может быть запущен независимо от какой-либо
базы данных (то есть без монтирования и открытия базы данных). Экземпляр может
быть открыт максимально для одной базы данных (хотя в некоторых операционных
системах единственная база данных может быть открыта для нескольких
экземпляров).
Экземпляр состоит из:
* одной разделяемой области памяти (называемой system global area или SGA),
которая обеспечивает связь между процессами. Более детально SGA обсуждается в
Главе 8.
* до пяти фоновых процессов (обозначаемых DBWR, LGWR, SMON, PMON и ARCH),
которые разделяются всеми пользователями. Фоновые процессы описываются в Главе9
Глава 14 обсуждает старт и завершение экземпляра ORACLE а также
монтирование, открытие, закрытие и размонтирование баз дан- ных.
Каждый экземпляр нуждается в доступе к кодам ORACLE RDBMS. Программные
коды RDBMS называются ядром. Эти коды могут разделяться между несколькими
экземплярами. Подробности разделения можно найти в Руководстве по
инсталляции и Руководстве пользователя.
Рисунок 1-3 показывает компоненты экземпляра ORACLE.
Ъ----------------------------------------------Дї
і і Оператив-
-- 26 --
і SYSTEM GLOBAL AREA (SGA) і ная
і і память
і Буфер базы данных Буфер журнала і
А------В------------------------------В--------ДЩ
і Разделяемые коды ORACLE і
А----------------ї Ъ--ДЩ
Ъ--Дї Ъ--Дї ЪДБДї ЪДБДї Ъ--Дї
і S і і P і і D і і L і і A і Фоновые
і M і і M і і B і і G і і R і процессы
і O і і O і і W і і W і і C і
і N і і N і і R і і R і і H і
А--ДЩ А--ДЩ А--ДЩ А--ДЩ А--ДЩ
Рисунок 1-3 Компоненты экземпляра ORACLE
Как и базы данных, экземпляры также имеют идентификаторы. Все экземпляры,
работающие на одном процессоре, должны иметь различные имена. Экземпляры
получают имена в процессе инсталляции программного обеспечения ORACLE;
конкретные правила именования зависят от операционной системы. Для более
детальной информации об именовании экземпляров и установке текущего
экземпляра обратитесь к Руководству пользователя и Руководству по инсталляции.
Базы данных с разделяемыми дисками
К базе данных может иметь доступ единственный экземпляр ORACLE или, в
некоторых операционных системах, несколькоэкземпляров одновременно. База
данных, к которой имеют доступ более одного экземпляра ORACLE, называется
базой с разделяемыми дисками. Глава 21 содержит специфические требования баз
данных с разделяемыми дисками.
Заметьте, что база с разделяемыми дисками адресует одну базу данных,
разделяемую между многими экземплярами ORACLE, тогда как распределенная база
требует несколько баз данных и несколько экземпляров ORACLE, связанных с
помощью сетевого программного обеспечения.
Рисунок 1-4 иллюстрирует базу данных с разделяемыми дисками.
ЭКЗЕМПЛЯР - А і ЭКЗЕМПЛЯР - В
Ъ--Дї Ъ--Дї Ъ--Дї Ъ--Дї Ъ--Дї і Ъ--Дї Ъ--Дї Ъ--Дї Ъ--Дї Ъ--Дї
і S і і P і і D і і L і і A і і і S і і P і і D і і L і і A і
і M і і M і і B і і G і і R і і і M і і M і і B і і G і і R і
і O і і O і і W і і W і і C і і і O і і O і і W і і W і і C і
і N і і N і і R і і R і і H і і і N і і N і і R і і R і і H і
А--ДЩ А--ДЩ А--ВЩ А--ВЩ А--ДЩ і А--ДЩ А--ДЩ А--ВЩ АДВДЩ А--ДЩ
--------------------Е----ДЕ--------ДБ----------------Е----Е----------Д
Ъ----------------Е----ДЕ------ї Ъ--------------ДЕ----Е--------ї
і і і і і і і і
іSYSTEM GLOBAL і AREAі(SGA) і іSYSTEM GLOBALі ARіA (SGA) і
і і Ъ--ДЕ------Е--ДЕ--------------ДЩ і і
А----------------ЕДЕ--ДЕ------Щ А--------------------Е--------Щ
v v А---->--ї Ъ--Д<----------------Щ
Ъ--------ДБДБ--ї Ъ--ДБ--Б------ї Ъ------------ї
і і іФайлы журналаі і і
і Файлы і і повторного і і Управляющиеі
ібазы данных і і выполнения і і файлы і
і і і і і і
-- 27 --
А--------------Щ А------------ДЩ А------------Щ
Одна база данных разделяется двумя экземплярами ORACLE
Рисунок 1-4 База данных с разделяемыми дисками
Распределенные базы данных
База данных ORACLE может связываться через сеть с другими базами данных.
Таким образом, пользователи одной базы данных могут обращаться к данным другой
базы данных. Глава 22 содержит полезную информацию для DBA, ответственного за
одну или более баз данных, связанных через SQL*Net.
ГЛАВА 2 РОЛЬ АДМИНИСТРАТОРА БАЗЫ ДАННЫХ (DBA).
Thow dost preserve the stars from wrong; And the most ancient
heavents, through Thee, are fresh and strong.
Wordsworth:Ode to Duty
O Duty,
Why hast thou not the visage of sweetie or a cutie?
Why glitter thy spectacles so ominously?
Why art thow clad so abominously?
Why art thou so different from Venus?
And why do thou and I have so few interests mutually
in common between us?
Ogden Nash:Kind of an Ode to Duty
В этой главе описывается роль и круг обязанностей Администратора Базы
Данных (DBA). В общем случае для каждой базы данных должен быть хотя бы
один человек, выполняющий обязанности DBA. Если же база большая и
поддерживает много приложений, желательно иметь несколько DBA.
В этой главе описываются:
* основные обязанности DBA
* два автоматически регистрируемые имени пользователя для DBA: SYS и SYSTEM
* привилегии, имеющие только DBA
* утилита DBA SQL*DBA.
В этой главе кратко изложен круг обязанностей DBA. Оставшаяся часть этого
руководства представляет техническую информацию и детальные инструкции по
выполнению DBA этих обязанностей.
Кто такой администратор базы данных?
DBA играет очень важную роль в успешной эксплуатации RDBMS. Как основной
"управляющий" базой данных он несет ответственность за техническое и
программное обеспечение, формирующее базу данных, а также за помощь
пользователям системы. Таким образом, DBA должен заботиться об:
* инсталяции и сопровождении программного обеспечения
* настройке базы данных на оптимальное использование
* планировании базы данных
* правильности данных
* целостности данных
* обеспечении защиты данных
* сохранности данных
* доступности данных
* восстановлении данных
-- 28 --
Обычно DBA является основным связующим звеном с Oracle Corporation и
главным источником информации об ORACLE для пользователей базы данных.
DBA не обязательно инсталирует ORACLE. Однако обычно DBA либо контролирует,
либо сам выполняет инсталяцию и дополнение программного обеспечения.
В идеальном случае DBA знает все о базе данных: например, кто пользуется
базой данных, какие данные они хранят и как часто используют, какие имеются
виды транзакций и как можно увеличить производительность.
Строго говоря, администратором базы данных может быть любой пользователь,
имеющий в базе данных привилегии DBA (см. Главу 17). Каждая система ORACLE
инсталируется с двумя пользователями, имеющими имена SYS и SYSTEM. Они обсуж-
даются в этой главе. К базе данных могут быть добавлены и другие пользователи,
имеющие привилегии DBA.
В этом документе под DBA подразумевается лицо, выполняющее основные
обязанности администратора базы данных и имеющее в системе ORACLE имя
пользователя с привилегиями DBA.
Основные обязанности DBA
К обязанностям DBA относятся:
* гарантирование целостности и сохранности данных (см. Главы 11 и 12)
* планирование и настройка системы ORACLE (см. Главы 19 и 20)
* снижение неиспользуемой дисковой памяти (см. Главу 16)
* эффективное разделение данных между пользователями (см. Главу 12)
* гарантирование секретности данных (см. Главы 17 и 18)
* выполнение регулярного резервного копирования базы данных (см. Главу 15)
* при необходимости - восстановление данных (см. Главу 15).
Учетный номер DBA в операционной системе
DBA нуждается в учетном номере или идентификаторе в операционной системе,
дающем ему доступ к системе, в среде которой работает ORACLE. Учетный номер
DBA может иметь большие по сравнению с обычным пользователем базы данных права
доступа (например - для выполнения определенных действий по инсталяции
программного обеспечения ORACLE). Хотя DBA может и не требоваться пересылать
файлы на распределенное оборудование, он должен иметь к ним доступ.
В дополнение к сказанному, программа SQL*DBA требует, чтобы учетный номер DBA
в операционной системе имел расширенные возможности для выполнения привилеги-
рованных системных команд SQL*DBA. Метод расширения возможностей учетного
номера, который имеет DBA, спецефичен для операционных систем; за деталями
обратитесь, пожалуйста, к "Руководству пользователя по инсталяции" для
Вашей операционной системы.
Доступ к учетному номеру DBA в операционной системе (и, таким образом, к
привилегированным командам SQL*DBA) должен тщательно контролироваться.
Стандартные имена пользователей для DBA
Каждая система ORACLE автоматически инсталируется с двумя пользователями
ORACLE, имеющими привилегии DBA. Разница между ними описывается в следующих разд
-- 29 --
Если предполагается, что несколько лиц будут выполнять функции DBA,
предпочтительнее иметь несколько имен пользователей, нежели многократно
регистрироваться как SYS или SYSTEM. Это снизит вероятность непреднамеренного
изменения таблиц или обзоров, принадлежащих SYS или SYSTEM.
Некоторым утилитам системы ORACLE требуется обращаться к таблицам или
обзорам, принадлежащим SYS или SYSTEM. Например, программа CRT и SQL*Forms
пользуется таблицами SYSTEM. Эти таблицы создаются при инсталяции и не
должны меняться.
Пользователь SYS
Пользователь SYS регистрируется с паролем CHANGE_ON_INSTALL. Этот пароль
необходимо сменить сразу же после создания базы данных. Изменение пароля
пользователя SYS выполняется в одном из последних шагов процесса инсталяции.
Оно описано в "Руководстве пользователя по инсталяции" для каждой конкретной
операционной системы.
Синтаксис команды следующий:
GRANT CONNECT TO SYS IDENTIFIED BY newpassword
Обычные пользователи базы данных ORACLE никогда не должны регистрироваться с
именем пользователя SYS, да и DBA должен делать это как можно реже. SYS
владеет базовыми таблицами словаря, а эти таблицы критичны для работы системы
ORACLE. Кроме того, SYS владеет обзорами, базирующимися на этих таблицах.
С информацией таблиц пользователя SYS работает ORACLE RDBMS в результате исполь
зования базы данных. Работа с данными словаря критична для работы базы данных.
Никто и никогда, за исключением случаев, описанных в разделе "Удаление
элементов словаря данных" Главы 7, не должен ни изменять существующие таблицы,
ни добавлять новые к пользователю SYS.
Замечание: Отступление от этих правил может привести к потере данных,
необходимых DBA для восстановления информации базы.
По умолчанию только пользователь SYS имеет доступ ко внутренним таблицам,
используемым средством SQL*DBA MONITOR. Для более подробной информации о
средстве MONITOR и предоставлении другим пользователям прав доступа к этим табли
Пользователь SYSTEM
Пользователь SYSTEM регистрируется с паролем MANAGER и по аналогии с
SYS, его надо сменить его сразу же после создания базы данных. Заметьте,
что инсталяция некоторых продуктов, например - SQL*Forms, подразумевает
пароль MANAGER у пользователя SYSTEM.
Пользователем SYSTEM могут быть созданы дополнительные таблицы и обзоры.
Например, DBA, зарегистрированный как SYSTEM, может по своему усмотрению
создать дополнительные таблицы и обзоры, содержащие общие системные или
пользовательские данные. Однако нельзя создавать у пользователя SYSTEM
таблицы, интересующие лишь отдельных пользователей.
Регистрация как INTERNAL
-- 30 --
В определенных ситуациях DBA может потребоваться зарегистрироваться с ключевым
словом INTERNAL. Регистрация как INTERNAL эквивалентна регистрации SYS, но
при этом не требуется введение пароля. В этом случае может быть опущена
стандартная проверка имени пользователя.
Присоединение как INTERNAL - это привилегированная операция SQL*DBA.
Таким образом, ORACLE RDBMS проверит, имеет ли пользователь операционной
системы, пытающийся присоединиться как INTERNAL, разрешение на выполнение
привилегированных команд SQL*DBA. Для более подробной информации о
привилегированных командах SQL*DBA обратитесь к Приложению В.
Присоединение как INTERNAL может потребоваться в случае, когда база данных
монтирована, но не открыта (это редкая операция, но она может потребоваться
при обслуживании базы данных). Присоединение как INTERNAL требуется в следующих
ситуациях:
* при создании базы данных (так как для выполнения команды CREATE DATABASE
администратор должен быть присоединен к базе, а отсутствие словаря данных не
позволит провести проверку пользователя)
* при изменении базы данных с целью добавления или отмены файл журнала
повторного выполнения, используя команду ALTER DATABASE.
Замечание: Присоединение как INTERNAL во всех остальных случаях оговаривается
специально. Использовать присоединение как INTERNAL может только DBA.
Привилегии DBA
Пользователи SYS и SYSTEM имеют в системе ORACLE специальные привилегии,
которые даются любому другому пользователю лишь при явном указании доступа как
DBA. За описанием этих привилегий обратитесь к разделу "Пользователи с
привилегиями DBA" Главы 17 этого документа.
Инструментальные средства DBA и программа SQL*DBA
Программа SQL*DBA - это наиболее полезный инструмент DBA. SQL *DBA можно
использовать для решения многих задач, включая следующие:
* создание новой базы данных
* запуск и остановка экземпляра ORACLE
* присоединение в случае необходимости как пользователь INTERNAL
* изменение текущего главного процессора для выполнения опе-
раций в системах с различными базами данных.
* выполнение операторов SQL
* отслеживание реального времени использования базы данных
* активизация файлов журнала повторного выполнения
* архивация файлов повторного выполнения
* восстановление данных при возникновении отказов оборудования
Для получения информации об использовании SQL*DBA по запуску и остановке
баз данных обратитесь к Главе 13, а в Приложении В описана утилита SQL*DBA и
приведен полный синтаксис ее команд.
Не менее важным инструментом DBA является словарь данных. Использование и
интерпретация данных таблиц и обзоров словаря данных очень удобны в работе
DBA. Администратор к тому же может легко "расширить" получаемую информацию
путем создания дополнительных обзоров или таблиц, приведя ее к более удобной
для себя форме. Как и другие пользователи, DBA имеет некоторые ограничения по
изменению словаря данных. Подробнее смотрите Главу 7.
-- 31 --
Администратора касаются также такие утилиты ORACLE как SQL*Loader, CRT,
Export/Import. Эти утилиты описаны в "Руководстве пользователя по утилитам
ORACLE".
ЧАСТЬ II КОНЦЕПЦИИ ORACLE RDBMS
ГЛАВА 3 ФАЙЛОВАЯ СТРУКТУРА ORACLE RDBMS
В этой главе описываются файлы операционной системы, необходимые для
функционирования системы управления реляционной базой данных (RDBMS).
Обсуждаемая тема включает в себя назначение и сопровождение четырех типов
файлов, требующихся базе данных ORACLE:
* программы ORACLE RDBMS
* файлы базы данных
* управляющие файлы
* файлы журнала повторного выполнения.
Обычно только DBA работает с физическими файлами, простым пользователям в
этом нет необходимости. ORACLE RDBMS V6 предоставляет администратору широкие
возможности управления физической памятью. Например, DBA может распределить
ввод/вывод по различным устройствам, или перевести часть базы данных в
неактивное состояние, или же восстанавливать часть базы данных, в то время как
оставшаяся часть базы данных остается активной.
Эти возможности особенно важны для DBA, управляющего большой базой данных: в
то время как администратор работает с частью базы (например - выполняет резерв-
ное копирование или разрешает возникую проблему), пользователи могут
продолжать работать с активной частью базы данных.
Дополнительную информацию, относящаяся к обсуждаемому в этой главе
предмету, можно найти в :
* Главе 4 Табличные пространства и сегменты
* Главе 15 Резервное копирование и восстановление базы данных
* Главе 16 Управление памятью
* Руководстве пользователя по инсталяции - описание, создание и
использование этих файлов в конкретных операционных системах.
Рисунок 3-1 иллюстрирует минимальный набор файлов, требуемых для работы
базы данных. Как Вы видите, базе данных помимо программ RDBMS требуется как
минимум четыре файла. Во многих базах данных могут быть дополнительные файлы
указанных типов.
Тип файла Минимальное Минимальный
количество размер
Файл базы данных 1 500 Кбайт
Активный журнал повторного 2 50 Кбайт
выполнения Управляющий файл 1 Определяется при
инсталяции (небольшой)
Файлы с выполнимыми (много) Полный размер
программами RDBMS зависит от операционной
сист. (около 17400 К)
Рисунок 3-1 Минимальный набор файлов для базы данных
-- 32 --
ORACLE RDBMS требует фиксированный объем памяти для программ и данных.
Непросто распределить больше дисковой памяти, чем это необходимо. Кроме того,
такие ресурсы, как дисковые файлы, предназначаются также для хранения данных
базы и RDBMS знает, сколько памяти можно использовать.
Физические и логические структуры
Физические структуры, такие как файлы операционной системы, хранятся на
реальных носителях (например - магнитных лентах, флоппи-дисках или твердых
дисках). Файл связан с памятью, распределяемой операционной системой. Системе
ORACLE требуются для работы несколько файлов.
Обычно только DBA имеет дело с физическими элементами памяти (например,
удостовериться, что файлы базы данных могут хранить все данные базы и при
необходимости добавить файл). Изредка и обычный пользователь может
работать с физическими структурами например - чтобы минимизировать ввод/вывод
или информацию на диске.
Логические структуры также соответствуют элементам дисковой памяти, но их
границы не зависят от физического размещения файлов. Например - логическая
таблица может перекрывать физические файлы. Примером логических структур ORACLE
могут служить таблицы и табличное пространство (tablespace).
Пользователи чаще имеют дело с логическими структурами базы данных, нежели
чем с физическими так как логические структуры лучшее соотносятся с данными.
Например - скорость выборки данных из таблицы зависит от того, в каком таблич-
ном пространстве находится таблица и существуют ли индексы у этой таблицы.
Программные файлы ORACLE RDBMS
Вы получите программные продукты ORACLE Corporation на какомлибо дистрибутивном
носителе, обычно на магнитной ленте или дискете. В "Руководстве пользователя
по инсталяции" Вы найдете инструкции для инсталяции системы ORACLE, включая
рекомендации, куда поместить дистрибутивные файлы и сколько памяти потребуется.
Дистрибутивный носитель содержит множество файлов различных типов, таких как
объектные библиотеки, выполнимые и командные файлы. Обычно дистрибутивный
набор файлов ORACLE принадлежит DBA, системному программисту или менеджеру.
Если же за инсталяцию и модификацию программного обеспечения ORACLE
отвечает не DBA, иногда ему для справки или выполнения могут потребоваться
файлы с дистрибутивного носителя.
На случай возможной перезагрузки в будущем дистрибутивный носитель должен
храниться в защищенном месте. Если дисковая память критична, после линковки
файлы могут быть сброшены на магнитную ленту (обычно они больше не нужны).
Файлы базы данных
База данных ORACLE состоит из одного или нескольких файлов базы данных.
Эти файлы содержат всю информацию базы. Ниже даны характеристики файлов базы:
* Файл может быть связан с одной и только одной базой данных
* Один или несколько файлов из логической единицы памяти базы
называются табличным пространством
* Все файлы из активного табличного пространства при старте
экземпляра ORACLE должны быть доступны
* Работа базы данных улучшается, если каждый файл базы данных занимает на
диске непрерывное пространство, однако это не обязательное требование
* Однажды созданный файл не должен менять размер
-- 33 --
Первый файл в б.д. - это первый файл из табличного пространства с именем
SYSTEM. Табличное пространство может включать в себя несколько файлов, но
файл может принадлежать только одному пространству. Для дальнейшей информации о
том, как табличные пространства используют файлы, обратитесь к Главе 4.
Действия, предпринимаемые DBA для подготовки и отождествления файлов
зависят от операционной системы; для детальной информации обратитесь к
"Руководству пользователя по инсталяции" по Вашей операционной системе. Во
многих операционных системах Вам надо только поименовать файлы, ORACLE
автоматически их распределит и отформатирует. В некоторых операционных
системах лицо, ответственное за инсталяцию базы, должно создать файлы базы
данных до инсталяции.
Количество файлов базы данных
Обязателен только один файл базы данных. Маленькие системы могут иметь
единственный файл базы данных. Дополнительные файлы могут создаваться с
учетом двух мало отличающихся ограничений. Немного файлов большего размера
предпочтительнее большого числа маленьких файлов.
Максимальное число файлов базы данных может быть установлено с помощью
MAXDATAFILES ( необязательного параметра оператора CREATE DATABASE).
Установка параметра MAXDATAFILES незначительно влияет на размер управляющего
файла. Этот максимум не должен превышать лимита ORACLE, равного 255, но
зависит от каждой конкретной операционной системы.
Текущее максимальное количество файлов базы данных устанавливается в параметре
DB_FILES файла INIT.ORA. Этот лимит используется каждый раз, когда экземпляр
ORACLE открывает базу данных и сохраняется до ее закрытия. Умалчиваемое
значение 32. Параметр DB_FILES может на время снижать лимит, установленный с
помощью MAXDATAFILES, но не может его увеличивать.
Использование параметров DB_FILES и MAXDATAFILES необязательно. Если ни
один из них не указан, предполагается максимальое для ORACLE число 255 файлов.
За детальными инструкциями по добавлению файлов к новым или существующим
табличным пространствам обратитесь к Главе 16.
Размер файлов базы данных
Первый файл базы данных (начало табличного пространства SYSTEM)
должен иметь размер как минимум 500К байтов чтобы содержать:
* начальный словарь данных (см. Главу 7)
* начальный сегмент отката (rollback)
Файл базы данных, создаваемый по умолчанию (см. Главу 13) имеет
размер, достаточный для начального использования базы. Впоследствии легко
можно добавить файлы любого размера (см. Главу 16).
Если Вы хотите инсталировать другие продукты ORACLE (например HELP), они
могут потребовать память в табличном пространстве SYSTEM. При планировании
таких инсталяций обратитесь к инструкциям по соответствующим продуктам.
Размер блока файлов базы данных
-- 34 --
ORACLE RDBMS использует при работе с файлами базы данных единицы информации,
называемые блоками (иногда их называют страницами). Размеры блока базы данных
соответствуют размеру блока ORACLE (block size). Он может отличаться от
стандартного размера, принятого в операционной системе.
Для каждой операционной системы, в которой работает ORACLE RDBMS, существует
подразумеваемый размер блока ORACLE. Обычно он имеет размер 2 или 4 К байта.
Независимо от того, большие Ваши записи или маленькие, размер блока не
меняется. Чтобы узнать размер блока ORACLE для Вашей операционной системы,
обратитесь к "Руководству пользователя по инсталяции".
Размер блока ORACLE устанавливается при создании базы данных необязательным
параметром DB_BLOCK_SIZE в файле INIT.ORA. Размер блока не может быть изменен
без нового создания базы данных. Если Вы используете размер блока, отличный от
размера блока операционной системы, он должен быть кратен блоку операционной
системы.
Параметр DB_BLOCK_SIZE определяет также размер буферов в System Global Area
(SGA), а количество этих буферов определяет параметр DB_BLOCK_BUFFERS. Этот
параметр очень сильно влияет на производительность системы ORACLE.
Файлы базы данных в состояниях Online и Offline
Табличные пространства могут быть в любое время переведены в состояние offline
(недоступны для RDBMS) и наоборот. Таким образом, все файлы, принадлежащие
табличному пространству, одновременно переводятся в состояния online или
offline. Если файл принадлежит табличному пространству, он не может быть
отдельно переведен в состояние offline.
Любое табличное пространство может быть переведено в состояие offline, за
двумя исключениями:
* Табличное пространство SYSTEM (а значит и входящие в него файлы) должно
быть всегда в состоянии online
* Любое табличное пространство, содержащее активный сегмент rollback
(используемый активным или приостановленным экземпляром ORACLE), должно
оставаться в состоянии online.
Для перевода табличных пространств в состояние offline необходимо использовать
команду ALTER TABLESPACE (см. Главу 16).
Удаление файлов базы данных
Все файлы базы данных могут временно стать недоступными путем перевода в
offline соответствующего табличного пространства.
Файлы табличного пространства могут быть удалены из базы данных с помощью
SQL - оператора DROP TABLESPACE (см. Главу 16). После успешного завершения
этого оператора можно удалить соответствующие файлы командами операционной
системы.
Управляющие файлы
Каждый раз при открытии базы данных проверяются один или несколько управляющих
файлов. Управляющий файл - это небольшой двоичный файл, обычно именуемый
подобно ORACLE.DCF. Управляющий файл связан только с одной базой данных.
-- 35 --
Управляющие файлы создаются в процессе создания базы данных. Текущий
управляющий файл должен быть всегда доступен, так как он требуется при старте
экземпляра ORACLE для открытия базы данных.
По отношению к управляющему файлу Вам необходимо решить:
* сколько управляющих файлов надо поддерживать
* на каких устройствах их разместить.
Содержание управляющих файлов
Управляющие файлы содержат информацию о базе данных, необходимую для
доступа к базе экземпляра ORACLE. Он содержит информацию следующих типов:
* физические имена файлов базы и журнала повторного выполнения
* время создания базы данных
* имя базы данных
Имя базы данных инициируется во время ее создания либо в параметре DB_NAME в
файле INIT.ORA, либо в операторе CREATE DATABASE.
Управляющие файлы ORACLE модифицирует автоматически, Вы не можете их
редактировать. На том основании, что эти файлы модифицируются в процессе
работы базы данных, они должны быть доступны для записи все время, когда
работает база.
Количество управляющих файлов
Настоятельно рекомендуется иметь несколько идентичных копий управляющего файла.
Расположив несколько управляющих файлов на различных дисках, Вы снижаете риск
их потери при отказе устройства. Один незначительный недостаток нескольких
управляющих файлов состоит в том, что некоторые операции (например -
контрольные точки) требуют обновления управляющих файлов, а значит - снижение
производительности (незначительное).
Рекомендуемая конфигурация - как минимум два управляющих файла на разных
дисках.
Названия управляющих файлов
Названия управляющих файлов указываются в файле INIT.ORA в параметре
CONTROL_FILES. Этот параметр может содержать список из одного или нескольких
имен управляющих файлов (по умолчанию - одно имя). Значение этого параметра
можно менять, когда база остановлена. Можно добавлять новые имена файлов,
изменять их, менять местонахождение файлов.
Процедура старта экземпляра ORACLE будет распознавать и поддерживать все
указанные файлы, но она не может создавать новые. Чтобы добавить новый
управляющий файл, необходимо скопировать текущий управляющий файл в новый и
затем добавить его имя к списку значений переменной CONTROL_FILES (при этом
база должна быть остановлена).
Размеры управляющих файлов
Обычный управляющий файл очень мал. Его размер определяют в основном два
параметра из INIT.ORA: LOG_FILES и DB_FILES.
Файлы журнала повторного выполнения
-- 36 --
Каждой базе данных ORACLE требуется журнал повторного выполнения. Основное
назначение журнала - защита базы данных в случае фатальной ошибки системы или
поломки носителя. Он содержит измененные записи базы данных, которые необ-
ходимо занести, если они туда не попали по какой-либо причине (программная
или аппаратная ошибка). Процесс перезаписи изменений называется откатом
вперед или, более обще, восстановлением.
Журнал регистрации состоит из двух или более файлов операционной системы,
внешних по отношению к базе. Необходимость иметь как минимум два таких файла
вызвана тем, что в то время как один всегда доступен для записи, другой в это
время архивируется. Точка, в которой система заканчивает писать в один файл и
начинает писать в другой, называется "ключ журнала".
Работающая база данных должна все время иметь возможность записывать
информацию в активный (online) файл журнала, так как пользователи все время
проводят изменения в базе. Если ORACLE RDBMS по какой-либо причине не
может писать в файл журнала повторного выполнения, база остановится по ошибке.
Замечание: Файл журнала повторного выполнения критичен для работы базы
данных. Отсутствие журнала может стать причиной необходимости приведения базы
к предшествующему состоянию с резервной копии или полного экспорта базы.
Файл журнала повторного выполнения может использоваться в двух режимах:
ARCHIVELOG или NOARCHIVELOG в зависимости от того, будут или нет эти данные
архивироваться. Заметьте, что все изменения в базе будут протоколироваться,
так что использование online журналов отката необязательно. DBA решает, будет
ли он архивировать (сохранять) или нет файлы журнала, используя режимы
ARCHIVELOG или NOARCHIVELOG.
Процесс записи информации в журнал повторного выполнения
В любой момент времени информация пишется только в один файл журнала вне
зависимости от количества экземпляров ORACLE, работающих с базой. В текущий
активный файл журнала повторного выполнения информацию записывает фоновый
процесс LGWR (см. Главу 9). Информация буферизуется в SGA и затем LGWR
последовательно записывает ее в файл журнала. Вне зависимости от выбранного
режима активные файлы журнала записываются по "круговому" принципу. Если
установлен режим ARCHIVELOG, файлы журнала , находящиеся в состоянии online,
используются для записи данных. Ни один файл журнала не может быть записан
заново, пока не будет архивирован. Если же установлен режим NOARCHIVELOG, то
после заполнения последнего файла журнала, находящегося в online,
информация будет записываться в первый, перекрывая старую.
Содержание файла журнала повторного выполнения
Основным содержанием файла журнала являются данные, которые необходимо
занести в базу для восстановления всех изменений. Так как данные отката назад
(rollback) хранятся в базе (см. Главу 4) в сегментах rollback, они также будут
защищены журналом повторного выполнения. В дополнение к этим элементам данных
журнал содержит административную информацию о состоянии файла базы вместе с
экземпляром ORACLE, записавшем информацию и о последней контрольной точке.
Вследствие того, что файле журнала хранится информация "низкого уровня",
она не может быть соотнесена с действиями пользователя, проводившим изменения и
поэтому не может редактироваться, меняться или использоваться прикладными
программами (например - с целью ревизии).
-- 37 --
Каждый файл журнала идентифицируется "последовательным номером журнала",
используемом при восстановлении.
Выбор режима записи в журнал
Журнал повторного выполнения может использоваться в двух режимах. Режим
выбирается при задании команды CREATE DATABASE и может быть переключен в
любой момент SQL - оператором ALTER DATABASE (при закрытой базе).
NOARCHIVELOG этот режим используется только при восстановлении экземпляра
ORACLE (а не сбое оборудования). При этом восстанавливаются только самые
последние изменения базы. При переполнении журнал не сохраняется.
ARCHIVELOG этот режим помимо ошибок экземпляра ORACLE защищает и от
сбоев оборудования так как все изменения базы сохраняются. Каждый файл журнала
повторного выполнения перед повторным использованием должен быть архивирован
(обычно на ленту).
Независимо от выбранного режиме протоколирования все изменения в базе
данных регистрируются в журнале. Информация для восстановления экземпляра
ORACLE (зависание системы или программные ошибки) имеется в журнале независимо
от выбранного режима.
Если Вы предусмотрите дополнительные возможности, связанные с архивацией
данных журнала повторного выполнения (такие как запись на ленту, регулярное
копирование и сохранение измененных записей), то дополнительно обезопаситесь,
так как будете знать, каким образом восстановить данные с испорченного диска
без потерь транзакций и с минимальными усилиями.
Использование журнала повторного выполнения в режиме NOARCHIVELOG
NOARCHIVELOG - это метод минимальной защиты целостности данных. Он защищает от
сбоев системы и программного обеспечения, но не предотвращает потерь от
поломки оборудования. В режиме NOARCHIVELOG информация записывается точно
так же, как и в режиме ARCHIVELOG, но отдельный архивный файл может начать
записываться повторно без сохранения его содержимого в режиме offline.
Таким образом, в любой момент доступны только самые последние изменения данных.
Из этого следует, что:
1. Журнал регистрации изменений м.б. использован для восстановления от
ошибок, произошедших когда он был в online. Ошибка экземпляра ORACLE может
быть восстановлена только с используемого файла журнала. В то же время
ошибка, связанная с отказом оборудования, не может быть с него восстановлена,
так как сохранены не все данные для прямого отката.
2. Если табличное пространство стало недоступным в результате некоторой
ошибки, данные базы будут недоступны, пока пространство не будет восстановлено.
Однако, если при этом база данных продолжает работать, информация, необходимая
для восстановления пространства может быть испорчена при повторном
использовании этого файла журнала.
Использование журнала повторного выполнения в режиме ARCHIVELOG
В режиме ARCHIVELOG все изменения базы архивируются, поэтому они могут
быть восстановлены даже в случае порчи оборудования. Также как и для режима
NOARCHIVELOG информация файлов регистрации изменений может быть использована
для восстановления от программных ошибок. Архивация требует использования
файлов журнала в режимах online и offline:
-- 38 --
online журнал - это набор текущих файлов журнала, содержащих самую новую
информацию и доступен RDBMS для записи
offline журнал - это более старые журнальные файлы, которые архивируются
(обычно на ленту)
Если в режиме ARCHIVELOG некоторый файл заполнен, он не может повторно
использоваться, пока его содержание не будет архивировано. (В режиме
NOARCHIVELOG не требуется архивация файла перед его повторным использованием).
Чтобы использовать режим ARCHIVELOG для педохранения от отказов оборудования,
необходимо дополнительно выполнять регулярный физический откат базы, используя
утилиты операционной системы. Эту операцию можно проводить и при активной
базе (когда пользователи проводят изменения), так как транзакции, выполненные
в процессе дампа сохранятся в журнале повторного выполнения.
За дополнительной информацией об использовании ARCHIVELOG обратитесь к Гл. 15.
Конфигурирование файлов журнала повторного выполнения
При конфигурировании файлов журнала повторного выполнения необходимо принять во
внимание:
* Сколько всего памяти под журнал Вам потребуется ?
* Сколько потребуется online файлов ?
* Будете ли Вы использовать режим ARCHIVELOG ?
* Если - да, хотите ли Вы копировать часто небольшие файлы или большие,
но реже ?
* Сколько файлов журнала может быть записано на архивную лену ?
* На какие устройства предполагается поместить журнальные файлы ?
Эти соображения детально обсуждаются Главе 15.
Размер файлов журнала повторного выполнения
Файлы журнала не обязательно должны быть одного размера. Минимальный объем
файла журнала повторного выполнения 50К байтов. Размер файлов указывается в
блоках операционной системы, а не ORACLE. Размер блока важен в основном
если Вы решили изменить в INIT.ORA параметр LOG_CHECKPOINT_INTERVAL, так как он
указывается в блоках операционной системы, а не ORACLE.
Количество файлов журнала повторного выполнения
Необходимо как минимум два файла журнала. Дополнительные файлы можно добавлять
с учетом двух простых ограничений:
Абсолютный максимум файлов журнала может быть установлен с помощью
необязательного параметра оператора CREATE DATABASE: MAXLOGFILES.
Установка этого параметра немного влияет на размер управляющего файла.
Максимальное число таких файлов в ORACLE - 255.
Текущее максимальное число файлов журнала повторного выполнения устанавливается
в INIT.ORA параметром LOG_FILES. Это ограничение действует с момента открытия
базы экземпляром ORACLE до остановки базы. По умолчанию принимается 16
файлов. Параметр LOG_FILES может временно уменьшать значение,
установленное в MAXLOGFILES, но не может превышать его.
Использование параметров LOG_FILES и MAXLOGFILES не является обязательным.
В случае их отсутствия принимается максимальное значение ORACLE (255).
-- 39 --
Контрольные точки
Когда online журнал повторного выполнения заполняется, выполняется действие,
называемое "контрольная точка". Контрольная точка работает как в режиме
ARCHIVELOG, так и NOARCHIVELOG. После выполнения контрольной точки все
модифицированные буфера записываются в базу, чтобы быть уверенным, что все
изменения записаны на диск. Контрольные точки не влияют на пользователей базы
данных и их транзакции, а лишь гарантируют, что более ранние элементы
журнала больше не нужны, так как измененные блоки базы записаны на диск.
Контрольные точки делаются при заполнении файла журнала повторного выполнения
а также могут выполняться и через определенные интервалы времени в процессе
заполнения файла журнала. Периодическое сохранение изменений в базе данных с
помощью контрольных точек преследует две цели:
* уменьшить время восстановления экземпляра ORACLE, если это потребуется
* пометить online файл журнала, как готовый к архивации или повторной записи
Для более подробной информации о контрольных точках обратитесь к Главе 15.
ГЛАВА 4 ТАБЛИЧНЫЕ ПРОСТРАНСТВА И СЕГМЕНТЫ
"Contrariwise", continued Tweedledee, "if it might be; and if
it were so, it would be; but as it isn't. That's logic"
Lewis Carrol: Through the Looking-Glass IV
В этой главе содержится информация, заинтересующая как квалифицированных
пользователей ORACLE и разработчиков приложений, так и администраторов базы.
Описание концентрируется на логических структурах базы данных ORACLE и
включает в себя:
* табличные пространства
* пять типов сегментов:
* сегменты данных
* индексные сегменты
* сегменты отката
* временные сегменты
* сегмент первоначальной загрузки
* параметры, используемые для определения элементов памяти, называемых
экстентами.
Родственную информацию можно получить в следующих местах:
* Глава 5 Структура таблиц ORACLE
* Глава 14 Запуск и остановка базы данных
* Глава 16 Управление внешней памятью
Рисунок 4-1 иллюстрирует взаимосвязь логических структур, обсуждаемых в этой
главе. Ъ------------------------------------------------ї
і і
БАЗА і DB_TEST і
Г----------------------------------ДВ------------ґ
ТАБЛИЧНЫЕ і і і
ПРОСТРАНСТВАі TS_ONE і SYSTEM і
Г------ДВ------ДВ----------ДВ------ДЕ--В--ДВ----Дґ
ТАБЛИЦЫ, ИНДЕКСЫі EMP і DEPT і PRODUCTS іEMP_INDі і...і і
ИЛИ КЛАСТЕРЫ і і і і і і і і
Г------ДЕ------ДЕ----------ДЕ------ДЕ--Е--ДЕ----Дґ
СЕГМЕНТЫ і DATA і DATA і DATA і INDEX і і...і і
-- 40 --
ГДВВ--ВВЕДВДВДВДЕДВВ--ВДВДВВЕДВДВДВДЕВВЕДВДЕДВДВДґ
і іі ііі і і і і іі і і ііі і і і іііі і і і і і
ЭКСТЕНТЫ і іі ііі і і і і іі і і ііі і і і іііі і і і і і
АДББ--БББДБДБДБДБДББ--БДБДБББДБДБДБДББББДБДБДБДБДЩ
Рисунок 4-1 Логические структуры, образующие базу
Каждая база идентифицируется именем, указываемом в операторе CREATE DATABASE.
Обсуждение логических структур базы данных будет продолжено в Главе 5, где
описываются таблицы, кластеры, обзоры и индексы.
Табличные пространства
База данных подразделяется на логические элементы, именуемые табличными
пространствами. База может содержать одно или несколько табличных пространств;
первичное табличное пространство называется SYSTEM. Каждое табличное
пространство соответствует одному или нескольким физическим файлам базы.
Как базовый логический элемент системы ORACLE, табличное пространство
касается прежде всего DBA. Администратор использует табличные пространства
для:
* управления распределением памяти для объектов базы, таких как таблицы,
индексы, и временные сегменты
* установления квот памяти для пользователей базы
* управления доступностью данных путем перевода отдельных табличных
пространств в состояния online или offline
* копирования и восстановления данных
* распределения данных по устройствам для повышения производительности.
Каждое табличное пространство имеет набор подразумеваемых характеристик памяти
(описанных ниже в этой главе), которые применяются для таблиц и индексов,
создаваемых в этом табличном пространстве. При создании таблицы или индекса
Вы можете перекрыть умалчиваемые параметры памяти, заменив их на нужные.
Взаимосвязь между файлами базы и табличными пространствами
Каждому логическому табличному пространству соответствует один или более
физический файл базы данных. К примеру, простейшая база будет иметь одно
табличное пространство с одним файлом базы. Для увеличения базы можно к
пространству добавить еще один файл или создать совершенно новое табличное
пространство (и файл). Таким образом, один или более файлов базы обеспечивают
память для табличного пространства. Для добавления новых табличных пространств
и файлов используются операторы SQL (см. ADD TABLESPACE или ALTER TABLESPACE).
Табличное пространство SYSTEM
Табличное пространство SYSTEM присутствует в любой базе. Оно создается
автоматически при выполнении оператора CREATE DATABASE. Небольшая база может
содержать только одно табличное пространство SYSTEM. Табличное пространство
SYSTEM всегда содержит словарь данных базы с именами и местоположениями
объектов базы (пользовательские таблицы, индексы, другие табличные пространст-
ва). Табличное пространство SYSTEM должно всегда находиться в online.
Попытка перевести его в offline закончится неудачей. Также как и другие
табличные пространства, SYSTEM может быть увеличено за счет добавления к нему
файлов базы.
-- 41 --
Если табличное пространство SYSTEM единственное в базе данных, оно должно
иметь размер, достаточный для включения:
* словаря данных
* всех сегментов отката, начальной загрузки и временных
* online HELP (если он загружен)
* таблиц, необходимых для других инсталируемых продуктов ORACLE
* всех объектов, создаваемых пользователем
Использование нескольких табличных пространств
Многие DBA находят, что использование нескольких табличных пространств
(в дополнение к SYSTEM) позволяет более гибко использовать базу. Например,
имея несколько табличных пространств, Вы сможете:
* распределять ввод/вывод по табличным пространствам (файламбазы), исходя из
потребностей приложений
* отделять данные таблиц от индексов, снижая конкуренцию при доступе к данным
* приводить схемы распределения памяти в соответствие нуждам пользователей и
приложений
* выводить отдельные табличные пространства в offline, когда другие остаются в
online
* резервировать различные табличные пространства для различных режимов
использования базы (например - с высокой частотой обновления, с доступом
только по чтению или для временных рабочих областей)
Примером такой дополнительной гибкости может быть база с двумя или тремя
табличными пространствами, причем одно содержит дополнительные сегменты
отката. Такая конфигурация позволяет переводить в offline табличное пространст
во, в то время как оставшаяся часть базы останется в online. Если же
используется только одно пространство SYSTEM, вся база данных может
находиться либо в online, либо в offline. Другими словами, если Вы имеете
только одно табличное пространств SYSTEM, частичное использование базы
невозможно.
Соответствие пользователей и табличных пространств
Для создания объектов базы в определенных табличных пространствах
пользователи ORACLE должны иметь на это права. DBA может предоставлять любому
пользователю следующие права:
* предоставлять привилегию RESOURCE ( способность создавать и сохранять
объекты) для одного или нескольких табличных пространств
* назначать умалчиваемое табличное пространство (для таблиц и других объектов)
* назначать квоты для каждого пространства (сколько памяти пользователь
может использовать под таблицы и индексы в указанном пространстве)
* назначать умалчиваемое временное табличное пространство (для любых
временных сегментов, которые создает ORACLE для пользовательских запросов).
За описанием SQL - операторов GRANT и ALTER USER обратитесь к Главе 17.
Направление таблиц в табличные пространства
Если у Вас есть привилегия RESOURCE для нескольких табличных пространств,
Вы можете при создании таблицы или индекса указывать, в каком пространстве
будут находиться данные или индекс.
Выбирая, какие табличные пространства будут содержать данные и индексы, Вы
сможете:
* выбрать, какие таблицы будут совместно помещаться в отдельные файлы базы (если
-- 42 --
* уменьшать количество данных на диске путем разнесения данных таблиц и
индексов по различным табличным пространствам
* выбирать, на каком физическом устройстве (с соответствующей скоростью
доступа) и какие данные будут храниться
* использовать для сегментов индексов и данных умалчиваемые параметры памяти
(размеры таблиц и т.д.)
* группировать таблицы с высокой активностью изменений так, чтобы можно было
чаще выполнять резервное копирование соответс- твующих файлов операционной
системы
* группировать таблицы, относящиеся к одному приложению, с тем, чтобы они
могли вместе работать и вместе копироваться
* снижать активность головок чтения/записи для нескольких таблиц
Табличное пространство может содержать множество таблиц и индексов. Таблица
или индекс не может распространяться на несколько табличных пространств, но
может распространяться на несколько файлов, составляющих табличное
пространство.
Рисунок 4-2 показывает размещение нескольких таблиц и индексов внутри одного
пространства.
Ъ----------------В--------------В--------------В----------Дї
і ТАБЛИЧНОЕ ПРО- і і і і
іСТРАНСТВО SYSTEMі PAYROLL_TS і RESEARCH_TS і MISC_TS і
Г----------------Е--------------Е--------------Е----------Дґ
і іЪ------------їі іЪ--------Дїі
і іі таблица іі іі индекс іі
і іі EMP ГЕ--------------ЕЕ> іі
і іі іі іі EMP_IND іі
і іА------------Щі іА--------ДЩі
і іЪ------------їі і і
і іі таблица ГЕ----ї і і
і ііACC_TEST іі Ъ--v------Дї і і
і іА------------Щі і индекс і і і
і іЪ------------їі іACC_NO_INDі і і
і іі индекс іі А----------Щ і і
іЪ------------Дї ііACC_TEST_INDііЪ------------їі і
іі индекс і іА------------Щіі таблица іі і
іі PROJ ГДЕ--------------ЕЕ> PROJ іі і
іА------------ДЩ і іА------------Щі і
А----------------Б--------------Б--------------Б----------ДЩ
Рисунок 4-2 Использование табличных пространств для хранения таблиц и индексов.
Дополнительные советы по выбору табличных пространств при создании таблиц и
индексов даны в Главе 16.
Табличные пространства в состояниях online и offline
Всякий раз, когда база открыта, DBA может с помощью оператора SQL: ALTER SPACE
перевести любое табличное пространство в online или offline. Единственное
исключение состоит в том, что пространство SYSTEM всегда должно быть в
online.
Вам может потребоваться перевести табличное пространство в offline по одной
из следующих причин:
* в основном, чтобы сделать часть базы недоступной при сохранении доступа к
оставшейся части
* для выполнения резервного копирования табличного пространства (backup) (хотя
-- 43 --
это можно сделать и без перевода пространства в offline)
* чтобы сделать приложение (и связанные с нам таблицы) временно недоступными,
* чтобы лучше использовать доступные в настоящий момент устройства внешней памя
Возможность перевода табличного пространства в online или offline позволяет
Вам более гибко работать с редко используемыми данными или временной памятью на
запоминающих устройствах.
В словаре данных (в пространстве SYSTEM) отмечается, переведено ли
пространство в online или в offline. Если табличное пространство было в
состоянии offline в момент размонтирования базы, оно будет в том же
состоянии и при последующем монтировании.
Табличные пространства в состоянии offline
Когда табличное пространство находится в offline, файлы, его
составляющие закрыты и данные в пространстве недоступны.
Табличное пространство может быть переведено в online только той базой,
которой оно переводилось в offline, так как необходимая информация находится
в словаре данных этой базы. Табличное пространство в состоянии offline не
может читаться и редактироваться никакой другой утилитой, как ORACLE. Таким
образом, табличные пространства не могут передаваться из базы в базу. Для переда
При возникновении некоторых ошибок табличное пространство может автоматически
переводиться в состояние offline (например, если системный процесс DBWR не
сумел записать данные с нескольких попыток). Пользователи, пытающиеся работать
с таблицами этого пространства, получат сообщение об ошибке. Обычно эти
проблемы решаются при рестарте экземпляра ORACLE.
Доступ к данным, находящимся в offline
Когда данные таблиц и индексов разбросаны по различным табличным пространствам,
некоторые из которых находятся в offline, Вас может удивить, что Вы имеете
доступ к данным, находящимся в offline. Хотя операторы SQL, обращающиеся к
offline данным, завершаются аварийно, некоторые из них несмотря на ошибки
могут работать в зависимости о того, какие данные находятся в offline и какие
данные доступны через SGA.
Вообще говоря, если табличное пространство в offline, а таблица имеет в
нем индекс, многие операторы вероятно не могут быть выполнены. Например,
модификация данных, требующая изменения индекса, завершится аварийно.
Однако некоторые SQL - операторы могут быть выполнены, если оптимизатор решит,
что индекс (находящийся в offline) не потребуется. Например, если оптимизатор
определит, что для поиска данных полный просмотр таблицы предпочтительнее
поиска в индексе, запрос выполнится успешно. Всегда можно переписать запрос
так, чтобы не использовать индекс.
И наоборот, если таблица в offline, а индекс - online и в запросе
используются только индексированные столбцы, он также м.б. успешно выполнен.
Другими словами, если оптимизатор решает, что для выполнения запроса данных
достаточно, он выполняет оператор SQL. Если же данные, находящиеся в
offline необходимы, оператор завершится аварийно.
Восстановление табличных пространств, находящихся в offline.
-- 44 --
Для находящихся в offline табличных пространств могут проводиться процедуры
восстановления. Таким образом, база данных с разрушенным файлом может
оставаться работоспособной тогда как другие файлы (в других табличных
пространствах) могут быть доступны (в то время как разрушенное пространство
выведено в offline и восстанавливается).
Например, если в процессе нормальной работы возникли ошибки на диске, Вы
можете перевести соответствующее табличное пространство в offline, выполнив
rollback для активных транзакций, связанных с этим пространством. Затем Вы
можете восстановить резервную копию этого табличного пространства (допустим -
на другой диск) и воспользоваться утилитой SQL*DBA для восстановления, а по
завершении перевести это пространство в online.
Раздельное восстановление полезно также при восстановлении экземпляра
ORACLE, так как отдельные части базы могут быть доступны до того как
восстановится вся база,а именно: экземпляр может быть запущен , база
монтирована и открыта как только будет восстановлено пространство SYSTEM, но
до восстановления оставшейся части базы.
Добавление новых файлов к табличному пространству
Вы можете добавлять файлы базы для увеличения существующих табличных
пространств и создания новых, чтобы расширить базу или распределить память
некоторым приложениям. Для добавления дополнительного файла базы к
существующему табличному пространству используется SQL - оператор ALTER TABLESP
Для создания нового табличного пространства применяется оператор CREATE
TABLESPACE. За дополнительными инструкциями по обоим операторам обратитесь к
Главе 16.
Сегменты и экстенты
Все данные в табличных пространствах запоминаются в элементах пространства
базы, называемых сегментами. Сегмент - это набор блоков базы, распределенных
для хранения данных базы. Эти данные могут быть таблицей, индексом или
временными данными, необходимыми для работы RDBMS. Сегменты являются следующим
логическим уровнем памяти после табличных пространств. Сегмент не может
перекрывать табличное пространство, но может перекрывать файлы внутри
табличного пространства.
Базе требуется до пяти типов экстентов:
* сегменты данных
* индексные сегменты
* сегменты отката (rollback)
* временные сегменты
* сегмент первоначальной загрузки.
Сегменты в зависимости от типа создаются различными способами. Большинство
пользователей имеют дело только с сегментами данных и индексными сегментами. Эт
Вообще говоря, только DBA работает с сегментами отката, временными и сегментом
первоначальной загрузки. DBA работает с сегментами отката напрямую, используя
SQL - операторы, RDBMS же автоматически создает временные сегменты и сегмент
первоначальной загрузки. Все сегменты имеют сходную структуру и состоят из
экстентов. Вначале большинство сегментов имеют некоторый указанный размер
(количество экстентов);впоследствии они динамически растут (добавляются
-- 45 --
экстенты) по мере необходимости. Следующий раздел описывает параметры памяти,
общие для всех сегментов.
Память детально обсуждается для каждого из пяти типов экстентов.
Параметры памяти сегментов
Каждый сегмент определяется с помощью нескольких параметров памяти. Эти
параметры связаны с каждым табличным пространством (через CREATE TABLESPACE)
и определяют умалчиваемые значения распределения памяти для всех сегментов,
создаваемых в данном табличном пространстве. Хотя параметры памяти применимы
ко всем типам сегментов, для примера описываются только сегменты данных и
индексов. Параметры памяти используются для управления процессом получения
памяти для таблицы (индекса). Например Вы можете указать, сколько памяти
отведется таблице первоначально или суммарный объем памяти для таблицы.
Параметры памяти выражаются в терминах экстентов данных. Экстент - это
распределение последовательного пространства базы, выраженное количеством
байтов данных.
Например в момент создания таблица содержит только начальный экстент
указанного размера. Несмотря на то, что в таблицу не занесено ни одной строки,
это количество байтов (в блоках ORACLE) зарезервировано под таблицу.
При наполнении таблицы данными он растет, пока не заполнит начальный
экстент. Если для данных требуется дополнительная паять, распределяется
дополнительный экстент так что теперь сегмент данных будет состоять из двух
экстентов. На рисунке 4-3 показан набор экстентов таблицы EMP.
Сегмент данных Сегмент индексов Сегмент индексов
для таблицы EMP для первого индек- для второго индек-
(используются умал- са, созданного в са, созданного в
чиваемые параметры таблице EMP таблице EMP
памяти) (используются умал- (используются назна-
чиваемые параметры ченные параметры
памяти) памяти)
Ъ----------------ї Ъ----------------ї Ъ----------------ї
і INITAL EXTENT і і INITAL EXTENT і і INITAL EXTENT і
і 10240 байтов і і 10240 байтов і і 10240 байтов і
А----------------Щ А----------------Щ А----------------Щ
Ъ----------------ї Ъ----------------ї Ъ----------------ї
і NEXT EXTENT і і NEXT EXTENT і і NEXT EXTENT і
і(первый)=10240б і і(первый)=10240б і і(первый)=10240б і
і1.5=15360 б і і1.5=15360 б і іPCTINCREASE=0% і
іPCTINCREASE=50% і іPCTINCREASE=50% і А----------------Щ
А----------------Щ А----------------Щ Ъ----------------ї
і NEXT EXTENT і
Ъ----------------ї і(второй)=10240б і
і NEXT EXTENT і іPCTINCREASE=0% і
і(второй)=15360б і А----------------Щ
і1.5=23040 б і
іPCTINCREASE=50% і
А----------------
Рисунок 4-3 Экстенты таблицы EMP (используются умалчиваемые параметры)
-- 46 --
Параметры памяти применимы ко всем типам сегментов или объектов, создаваемых в
табличном пространстве (в основном - к таблицам и индексам). Для указания
памяти в INITIAL и NEXT можно применять сокращения "К" и "М" - для
Килобайтов и Мегабайтов. Указанные значения приводятся к величине, кратной
целым блокам (DB_BLOCK_SIZE). Далее описываются используемые параметры памяти.
INITIAL - размер в байтах первого экстента, распределяемого при создании
таблицы, иначе - начальное значение памяти, доступной для данных
таблицы. По умолчанию начальный размер экстента 10240 байтов.
NEXT размер в байтах следующего экстента. Это базовое значение,
которое возможно будет увеличено на процент, указанный в
PCTINCREASE. По умолчанию 10240 байтов.
MAXEXTENTS общее количество экстентов, включая первый, которые могут быть
распределены. По умолчанию 99 экстентов. Абсолютный максимум
варьируется в зависимости от операционной системы.
MINEXTENTS общее количество экстентов, которые могут быть распределены при
создании сегмента. Это позволяет распределить в момент создания
большую память, даже если нет одного сплошного участка. По
умолчанию - 1 экстент.
Если MINEXTENTS больше 1, тогда указанное число экс- тентов
распределяется в момент выполнения CREATE с использованием
значений, указанных в INITIAL, NEXT и PCTINCREASE.
Возможно Вам потребуется увеличить значение MINEXTENT при создании
сегмента отката или если база фрагментирована и Вы хотите
гарантировать, что памяти для загрузки данных в таблицу будет
достаточно.
PCTINCREASE Процент, на который будет увеличиваться каждый следу- ющий экстент
по сравнению с предыдущим. Если значение PCTINCREASE равно 0,
каждый следующий дополнительный экстент будет иметь постоянный
размер. Однако, если PCTINCREASE имеет положительное значение,
размер каж- дого следующего экстента увеличивается на PCTINCREASE.
Этот параметр не может быть отрицательным.
В результате PCTINCREASE, умноженный на размер последнего
экстента, округляется до ближайшей большей величины, кратной
размеру блока. Умолчание - 50.
Замечание: Не путайте PCTINCREASE с PCTFREE и PCTUSED,
обсуждаемыми в Главе 5.
Какие параметры памяти действуют в каждый момент ?
Параметры памяти, действующие для определенного сегмента могут
определяться на нескольких уровнях. Параметры могут определяться следующим
образом, начиная c частного к более общему:
* в операторе ALTER (для любых объектов - TABLE, INDEX, CLUSTER или
ROLLBACK SEGMENT)
* в операторе CREATE (для тех же объектов)
* в операторе ALTER TABLESPACE
* в операторе CREATE TABLESPACE
-- 47 --
Таким образом, любой параметр памяти, указанный на уровне объекта,
перекрывает соответствующий параметр, указанный на уровне табличного
пространства. Если параметры изменены, они будут действовать на экстенты,
еще не распределенные. Если параметры памяти полностью не определены на всех
уровнях, будет действовать умолчание ORACLE.
Примеры задания и изменения этих параметров в командах CREATE TABLE и ALTER
TABLE даны в Главе 16.
Как распределяются экстенты ?
Каждый сегмент содержит блок управления сегментом (segment control block),
который описывает характеристики этого сегмента, а также содержит справочник
экстентов данного сегмента. Подобная информация содержится в словаре данных в
обзоре DBA_EXTENTS, который показывает все экстенты базы вне зависимости от
принадлежности табличному пространству. (Словарь данных показывает свободную
память и используется для поиска новых экстентов).
Когда ORACLE RDBMS необходимо распределить следующий экстент для сегмента,
она просматривает "свободную память" в табличном пространстве и распределяет
первый сплошной участок блоков требуемого размера. Заголовок сегмента и словарь
данных затем обновляются, чтобы отметить появление нового экстента и уменьшение
Когда освобождаются экстенты ?
Экстенты данных и индекса не освобождаются, пока не освободится
соответствующий сегмент. Пока таблица существует, остаются распределенными все
принадлежащие ей блоки памяти. Новая строка может быть добавлена в существую-
щий блок памяти, если там есть достаточно места. Даже если удалены все строки
таблицы, блоки данных не освобождаются для дальнейшего использования в
табличном пространстве.
Если же удалена вся таблица (drop table), сегменты индекса и данных
освобождаются для данного табличного пространства, а экстенты становятся
доступны другим объектам этого пространства.
Аналогично для индексного сегмента все блоки распределенных экстентов
остаются распределенными пока существует индекс. Когда индекс отменяется, все
блоки освобождаются для использования в данном табличном пространстве.
Как только в результате отмены сегмента освобождаются экстенты, модифицируется
словарь данных.
Сегменты данных и индекса.
Наиболее интересными для пользователей являются сегменты данных и индексов.
сегменты данных Сегмент данных содержит все данные одной таблицы (или
кластера). Таблица (кластер) всегда имеют только один
сегмент данных.
сегменты индексов Сегмент индекса содержит все данные по одному индексу
таблицы (или кластера). Одна таблица может иметь один,
несколько или не иметь вовсе сегментов индекса в
зависимости от того, сколько она имеет индексов. Кластер
должен иметь по край- ней мере один индексный сегмент -
для ин- декса кластера, созданного на ключе кла- стера.
На рис. 4-3 показано, как таблица EMP и связанные с ней индексы могут
располагаться в различных сегментах и табличных пространствах.
-- 48 --
Если у Вас есть привилегия RESOURCE для нескольких табличных пространств,
Вы можете создавать индекс в пространстве, отличном от того, в котором создана
таблица. Подобным образом можно управлять созданием индексов для кластеров.
Сегменты отката (rollback)
Каждая база содержит один или несколько сегментов отката. Сегмент
отката - это часть базы, куда записываются действия, которые необходимо
выполнить при определенных обстоятельствах. Сегменты отката используются для
обеспечения:
* отмены транзакции
* согласованного чтения
* восстановления
Сегмент отката содержит соответствующие данные для транзакций одного экземпляра
ORACLE, которые (транзакции) могут быть связаны с любым табличным пространством
базы.
Экземпляр ORACLE не может стартовать, пока не имеет доступа хотя бы к одному
сегменту отката. Если несколько экземпляров разделяют одну базу, каждый должен
иметь соответствующий набор сегментов отката.
Сегменты отката за исключением SYSTEM не могут разделяться между
экземплярами ORACLE.
DBA использует SQL - операторы для создания, отмены и увеличения размеров
сегментов отката:
CREATE ROLLBACK SEGMENT .......
ALTER ROLLBACK SEGMENT ......
DROP ROLLBACK SEGMENT ......
Эти операции описаны в Главе 16.
Сегмент отката SYSTEM
Начальный сегмент отката, называемый SYSTEM, создается в процессе создания
базы. Начальный сегмент создается в табличном пространстве SYSTEM с
использованием умалчиваемых параметров памяти этого пространства. Этот размер
достаточен для небольших баз и многие DBA хотели увеличить размер сегмента
отката или добавить новые сегменты в соответствии с ожидаемым количеством
пользователей и транзакций.
Экземпляр ORACLE обращается к сегменту отката SYSTEM помимо всех сегментов,
ему принадлежащих. Однако, RDBMS использует сегмент SYSTEM только для некоторых
системных транзакций и распределяет пользовательские транзакции только в другие
сегменты отката.
Несколько сегментов отката
В целях увеличения производительности несколько сегментов отката
предпочтительнее одного. Несколько сегментов необходимо в случае, когда:
* база имеет несколько табличных пространств
* несколько экземпляров ORACLE обращаются к базе в режиме разделения
диска
* к базе одновременно обращаются несколько пользователей
Если в базе несколько табличных пространств, она должна иметь два или более
сегмента отката, однако каждое пространство не нуждается в отдельном сегменте
отката. Например, если в базе три табличных пространства, то пространство
-- 49 --
SYSTEM может содержать как собственный сегмент отката, так и общий сегмент с
именем R_SEG1, в то время как только одно из двух оставшихся пространств будет
содержать R_SEG2.
Если база работает в режиме разделения диска, то для старта каждый экземпляр
нуждается в собственном сегменте отката. Дополнительные детали см. в Главах 15
и 21.
Содержание сегмента отката
Сегмент отката состоит из нескольких элементов отката. Помимо другой
информации элемент отката включает в себя идентификатор транзакции (ID),
информацию блока и описание данных до выполнения транзакции. Реально там
содержится информация об обратной транзакции. Элементы отката для
отдельных транзакций связаны через идентификатор транзакции, так что при
необходимости отката элементы могут легко быть найдены.
Сегменты отката не могут быть прочитаны или изменены пользователями базы
или DBA. Он пишутся и читаются исключительно RDBMS.
Элементы отката реально записываются дважды. Первый раз они пишутся в
сегмент отката, а затем (так как он тоже элементы данных) записываются в
журнал повторного выполнения. Таким образом, данные сегментов отката защищены
журналом повтора . Это гарантирует, что откат для активных сегментов может
быть выполнен даже если блоки сегмента отката еще не записаны на диск.
Как и другие сегменты, сегмент отката состоит из групп блоков, называемых
экстентами. В отличие от экстентов данных и индексов экстенты сегмента
отката содержат относительно временную информацию. Это позволяет трактовать
сегменты отката как "кольцо экстентов" и использовать их повторно по круговому
принципу.
Экстенты сегмента отката освобождаются и становятся доступными в табличном
пространстве только после отмены (drop) сегмента.
Как распределяются сегменты активным транзакциям
Каждый сегмент отката может обработать определенное количество транзакций
одного экземпляра ORACLE. Это количество приближенное и является
функцией размера блока ORACLE. RDBMS распределяет активные транзакции по
доступным сегментам, так что чем больше существует сегментов отката, тем
меньше информации будет в каждом.
Для дальнейшего рассмотрения предположим, что у нас есть три транзакции Т1, Т2
и Т3 а также один сегмент отката с двумя распределенными экстентами Е1 и Е2.
Все транзакции последовательно записываются в один сегмент, причем в
каждый момент транзакция пишет информацию только в один экстент. Допустим
транзакции Т1, Т2 и Т3 пишут сейчас в экстент Е2.
Когда транзакция исчерпала место в текущем экстенте и требует записи в
другой, RDBMS должна найти доступный для записи экстент. RDBMS может либо
повторно использовать уже распределенный экстент, либо запросить новый.
Если в следующем экстенте сегмента отката нет активных элементов отката,
уже распределенных в кольцо, RDBMS будет использовать этот экстент.
-- 50 --
Информация в экстентах называется активной, если относится к транзакциям,
которые еще активны, не выполнен commit и не выполнен откат.
RDBMS всегда будет пытаться повторно использовать следующий экстент
циклически. Однако если этот экстент еще содержит активные данные, RDBMS
будет распределять новый экстент пока не будет достигнуто количество экстентов,
заданное MAXEXTENTS.
Следовательно, если транзакции Т1 требуется дополнительное пространство
для элементов отката, она будет повторно использовать экстент Е1 (если в нем
нет активных элементов), иначе распределит экстент Е3.
Когда требуется информация отката
Каждый сегмент отката поддерживает таблицу всех активных в настоящий
момент транзакций для каждого изменения в базе, выполненного этой транзакцией.
Сегменты отката записывают данные, предшествующие изменению в виде
транзакций. Для каждой транзакции каждое новое изменение связывается с
предыдущим. Если транзакция нуждается в откате, изменения цепочкой применяются
к блокам базы в таком порядке, чтобы данные восстановились в прежнем виде.
Аналогично, когда ORACLE требуется выполнить снимок непротиворечивого
чтения, он использует сегменты отката для создания старших версий блоков
индексов и данных. (В Главе 12 обсуждается согласованное чтение).
Все типы откатов используют одинаковые процедуры:
* откат на уровне операторов ( при взаимной блокировке или ошибке
выполнения оператора)
* откат к точке сохранения
* откат транзакции по запросу пользователя
* откат транзакции по аварийному завершению процесса
* откат всех ожидающих обработки транзакций при аварийном завершении
экземпляра ORACLE.
В Главе 11 обсуждается вопросы, связанные с выполнением отката.
Размер сегментов отката
Если в системе работают только короткие транзакции, сегменты отката м.б.
невелики, так что всегда кешируются в основной памяти. Основной недостаток
небольших сегментов состоит в том, что увеличивается вероятность
возникновения ошибки " снимок памяти слишком старый" при работе длинных
запросов, обрабатывающих записи, которые параллельно изменяются другими
транзакциями. Эта ошибка возникает из-за того, что элементы отката, необходимые
для согласованного чтения перекрываются, когда другие записи циклически
записываются в сегмент отката.
Для одного экземпляра ORACLE сегменты отката должны быть примерно одинакового
размера; не очень удобно иметь несколько больших и несколько маленьких
сегментов так как RDBMS распределяет транзакции равномерно независимо от
размеров сегментов.
Вообще говоря, для сегментов отката надо устанавливать низкое значение
MAXEXTENTS.
Личные и общие сегменты отката
-- 51 --
Сегмент отката может быть либо личным, либо общим. Любое количество
сегментов обоих типов может присутствовать в базе пока экземпляры,
открывающие базу, имеют доступ хотя бы к одному сегменту отката.
Если Ваша база не будет монтироваться как SHARED (разделяемая) (что в
общем случае верно для всех систем, кроме VAX), можно создать общий сегмент
отката (PUBLIC) и игнорировать то, что ниже говорится о личных (PRIVATE)
сегментах.
В системах, разделяющих диск, может быть полезным создание личных
сегментов отката. О личных и общих сегментах рассказывается ниже и в Главе 21.
Чтобы начать использовать сегмент отката, DBA должен его сперва создать,
а экземпляр ORACLE при старте его затребовать. Работающие экземпляры не
смогут использовать вновь созданные сегменты отката без остановки и повторного
старта.
В процессе старта экземпляр после определения количества требуемых сегментов
пытается ими завладеть. Сперва он захватывает все личные сегменты,
указанные в INIT.ORA параметром ROLLBACK_SEGMENTS и затем, если
потребуется, некоторым количеством общих сегментов, которые не используются
другими экземплярами.
Общие сегменты отката
Общий сегмент отката - это сегмент, общедоступный любому экземпляру ORACLE,
обращающемуся к базе. DBA может создавать в базе общие сегменты с помощью
необязательного параметра PUBLIC оператора CREATE ROLLBACK SEGMENT.
Если экземпляр ORACLE, нуждающийся в сегменте отката, уже использовал личные
сегменты, он будет подыскивать общий сегмент. Если общий сегмент захвачен
экземпляром ORACLE, то до его остановки и закрытия базы ни один другой
экземпляр не может им завладеть. После остановки экземпляра общий сегмент
освобождается и становится доступным.
Разделяемая база может иметь только общие сегменты и пока их количество
больше достаточного для каждого вновь стартующего экземпляра, они могут
стартовать с необходимым им количеством сегментов отката.
Личные сегменты отката
Личные сегменты могут быть полезны для удовлетворения локальных требований, так
например сегменты, которые должны быть особенно большими или маленькими или
быть расположены на отдельных дисках. Личный сегмент отката создается без
ключевого слова PUBLIC и используется, если он поименован в параметре
ROLLBACK_SEGMENTS файла INIT.ORA.
Если сегмент отката создан без ключевого слова PUBLIC, но указан в
файле INIT.ORA для какого-либо экземпляра, сегмент не будет задействован.
Если один экземпляр пытается завладеть сегментом отката, указав его имя в
файле INIT.ORA, но другой, уже работающий экземпляр уже завладел им, первый
во время запуска получит сообщение об ошибке.
Косвенные сегменты отката
-- 52 --
Когда табличное пространство переводится в offline, так что транзакции не
могут откатиться немедленно, записывается косвенный сегмент отката. Он
содержит элементы отката, которые не могут быть применены к табличному
пространству, так чтобы применить их после обратного перехода пространства в
online. Эти сегменты исчезают, когда табличные пространства восстанавливаются.
Косвенные сегменты отката создаются автоматически в табличном пространстве
SYSTEM. Формат косвенного сегмента отката аналогичен обычному сегменту за
исключением того, что он содержит элементы отката только для определенного
табличного пространства (из многих транзакций и экземпляров), в то время как
стандартные сегменты содержат только элементы отката для указанного
экземпляра (для многих транзакций и табличных пространств).
Чтобы посмотреть существующие косвенные сегменты отката, запросите обзор
DBA_SEGMENTS словаря данных для которых SEGMENT_TYPE равен DEFFERED ROLLBACK.
Временные сегменты
При обработке запросов системе ORACLE обычно бывает необходима временная
память на промежуточных стадиях обработки операторов. Эти области называются
временными сегментами. Типично временный сегмент требуется как рабочая
область для сортировки. Сегмент не создается, если сортировка может быть
выполнена в оперативной памяти или ORACLE RDBMS найдет другой путь
сортировки, используя индексы.
Операции, нуждающиеся во временных сегментах
Следующие SQL - операторы могут нуждаться в использовании временных сегментов:
* CREATE INDEX
* SELECT ... ORDER BY
* SELECT DISTINCT ...
* SELECT ... GROUP BY
* SELECT ... UNION
* SELECT ... INTERSECT
* SELECT ... MINUS
* неиндексированные объединения
* некоторые коррелированные подзапросы
Например, если запрос содержит фразы DISTINCT, GROUP BY и ORDER BY,
потребуется не менее трех временных сегментов.
Как распределяются временные сегменты
Временные сегменты распределяются во время сеанса проьзоватея по мере
необходимости. Например, если у пользователя параллельно работают три
запроса, требующие временных сегментов, они и распределяются. Временные
сегменты отменяются после завершения обработки оператора.
Временные сегменты распределяются в табличном пространстве, указанном
либо через ALTER USER, либо в SYSTEM, если ничего не указано. Характеристики
памяти определяются обычным путем, используя умолчания для SYSTEM или других
табличных пространств.
Так как распределение и отмена временных сегментов производится часто,
имеет смысл создать специальное табличное пространство для временных сегментов.
Сделав это, Вы сможете распределить ввод/вывод по дисковым устройствам и
избежать фрагментации табличных пространств.
-- 53 --
Журнал регистрации изменений не содержит элементов для регистрации
изменений во временных сегментах.
Сегмент первоначальной загрузки
Сегмент первоначальной загрузки создается в табличном пространстве SYSTEM в
момент создания базы. Он содержит определения для таблиц словаря,
загружаемых при открытии базы. Сегмент первоначальной загрузки не требует
никаких действий со стороны DBA.
Этот сегмент небольшой (обычно меньше 50 блоков базы). Хотя он всегда
присутствует в базе (недоступный для пользователей), он не изменяется в
размерах. DBA может увидеть этот сегмент в базе путем выдачи запроса обзора
DBA_SEGMENTS, где SEGMENT_TYPE равен CACHE.
|
|