Ооп бд объектно-ориентированная база данных
| Вид материала | Документы |
- Программа дисциплины Объектно-ориентированное программирование Рекомендуется для направления, 591.42kb.
- Лекция на тему «Что такое база данных. Реляционная база данных ms access», 67.11kb.
- Абстракции, наследование и полиморфизм, 107.42kb.
- Ms access База данных (БД), 134.51kb.
- Лекция: Методологии моделирования предметной области: Методологии моделирования предметной, 347.91kb.
- Развитие объектно-ориентированных систем управления базами данных, 122.52kb.
- Должна быть конкретной, кратко сформулированной и соответствовать современному уровню, 20.13kb.
- В вычислительной математике, 1443kb.
- Базы данных 2, 398.32kb.
- Лекция на тему: Основы организации баз данных, 393.78kb.
11. Етапи створення бази даних Oracle
Для Oracle характерен механизм многозадачной обработки функций, однако Lite-версии могут этот механизм не поддерживать. Формирование базы данных Oracle является достаточно сложным процессом и можно выделить три этапа:
1. Формирование экземпляра (предустановочная стадия)
2. Установка базы данных экземпляра (установочная стадия)
3. Открытие базы данных (стадия открытия).
- Предустановочная стадия
1. Считывается файл параметров (по умолчанию: init.ora) - важный файл (редактировать только после бэкапа).
2. Запускаются фоновые процессы.
3. Инициализируется GSA.
* Имя экземпляра определяется значением, указанным в init.ora.
- Установочная стадия
1. Определяются значения параметров базы данных в соответствии с init.ora. На этой стадии и далее init.ora определяется как контрольный файл базы данных.
2. При необходимости на второй стадии выполняется модификация данных, хранящихся в init.ora.
3. Экземпляр получает исключительный доступ к файлам базы данных, имена которых хранятся в контрольном файле. Через этот файл они становятся доступными пользователям базы данных.
- Стадия открытия
Если стадия открытия не завершена, то к базе данных также возможен доступ (только для администратора с помощью специальной утилиты Server Manager).
В частности, с помощью утилиты Server Manager можно:
* создать каталог для размещения базы данных
* установить связь с базой данных
* выполнять монтирование и демонтирование базы данных
* выполнять очистку ОЗУ (часть ГСО, используемой базой)
* оценивать объем занимаемой памяти
* завершить работу с экземпляром Oracle
Экземпляр, в котором не установлена база данных, называется незанятым. Он занимает определенную область памяти, но не выполняет никакой работы. В этом случае возникает ситуация, когда экземпляр установлен, но сервис базы данных не установлен.
Каждый экземпляр Oracle состоит из процессов и разделяемой памяти, необходимой для доступа к информации в БД . Основной структурой памяти является GSA (Глобальная системная область, ГСО).
В GSA хранятся структуры памяти, необходимые для манипулирования данными для анализа предложений SQL, для кэширования транзакций. Все операции базы данных в том или ином виде используют информацию, находящуюся в GSA.
GSA состоит из разделяемого пула (Shared Pool), который в свою очередь содержит:
* кэш библиотек,
* кэш словаря,
* управляющие структуры сервера.
Кэш библиотеки используется для:
- хранения текста,
- хранения форматов лексического анализатора,
- хранения плана выполнения предложений SQL,
- хранения заголовков PL/SQL пакетов и процедур, выполнявшихся ранее.
Кэш словаря предназначен для хранения строки словаря данных, которая была использована для анализа предложений SQL. Таких строк может быть несколько.
14.Формирование экземпляра Oracle. Назначение и использование фоновых процессов
БД Oracle производит свое формирование следующим образом. Весь процесс делится примерно на три этапа:
- Формирование экземпляра Oracle (предустановочная стадия)
- Установка БД экземпляром (установочная стадия)
- Открытие БД (стадия открытия)
Далее по порядку. Экземпляр Oracle формируется на предустановочной стадии запуска системы. На этой стадии считывается файл параметров init.ora, запускаются фоновые процессы, и инициализируется ГСО (SGA). При этом имя экземпляра устанавливается в соответствии со значением указанным в init.ora. Следующая стадия - установочная. Значения параметров контрольного файла init.ora определяют параметры БД, устанавливаемой экземпляром. На данном этапе доступ к контрольному файлу открыт и возможна модификация данных, которые в нем хранятся. И на последней стадии собственно открывается сама База данных. Экземпляр получает исключительный доступ к файлам БД, имена которых, хранятся в контрольном файле и через него они становятся доступны пользователям БД. Фактически, если смотреть на открытие как состояние, то это скорее нормальное рабочее состояние БД. Заметим сразу, что до тех пор, пока БД не будет открыта, к ней может получить доступ только администратор БД и только через утилиту Server Manager. (В версии Oracle 9 этой утилиты нет. Её функции полностью переданы SQL*Plus. Так же, схема INTERNAL в Oracle 9 отсутствует.) Наверное, вы немного подустали уже от сухой теории, да и тот парень на галерке, по-моему, уже посапывает! Давайте разбудим его!
Посмотрим, как можно управлять БД, используя утилиту Server Manager. Войдите в каталог ..\Oracle\ora81\Bin вашей учебной БД имеющей SID - proba. Затем создайте в этом каталоге bat файл с именем serverora.bat и таким содержимым:
set nls_lang=russian_cis.ru8pc866
SVRMGRL.EXE
Сразу оговорюсь, делайте это по возможности на самой машине, где установлен сервер Oracle и его экземпляр, а не с клиентской машины, так как может возникнуть ряд нюансов, на которых мы пока не будем акцентироваться. После создания файла запустите его на исполнение, вы должны увидеть примерно следующее:
Oracle Server Manager Release 3.1.5.0.0 - Production
Copyright (c) Oracle Corporation 1994, 1995, 1997. Все права защищены.
Oracle8i Enterprise Edition Release 8.1.5.0.0 - Production
With the Partitioning and Java options
PL/SQL Release 8.1.5.0.0 - Production
SRVMGR>_
Введите в ответ на приглашение - internal/oracle@proba или, если вы все делаете на самом сервере - internal/oracle.
Получите в ответ:
SRVMGR> internal/oracle
Связь установлена.
SRVMGR>_
Затем введите на приглашение:
SRVMGR> SHUTDOWN NORMAL
Через некоторое время увидим следующее:
База данных закрыта
База данных демонтирована.
Экземпляр ORACLE закрыт.
SRVMGR>_
Если сначала вы запустите диспетчер задач и перейдете на его закладку Performance, то будете при этом наблюдать следующую картину:
Это картинка с моего сервера, у меня два процессора и Win2000 Server. Как видно, большая часть ОЗУ очистилась, так как произошло закрытие сервера Oracle. Обратите внимание на последовательность сообщений сначала происходит закрытие БД, а затем БД демонтируется. (подобные сообщения выдавал файл-сервер Novell, только там монтировались и демонтировались тома) и в конце экземпляр БД закрывается. Кстати, если еще остановить сам сервис, занимаемой памяти станет еще меньше. Вот так с помощью Server Manager, можно остановить ваш экземпляр БД. Далее, давайте его запустим, вводим:
SRVMGR> STURTUP FORCE
Получаем после нажатия Enter
Экземпляр ORACLE запущен.
Всего байтов System Global Area 547758028
Fixed Size 65484 байтов
Variable Size 143876096 байтов
Database Buffers 403742720 байтов
Redo Buffers 73728 байтов
База данных смонтирована.
База данных открыта.
Теперь смотрите внимательно, первая строка сообщает, что экземпляр запущен! Далее пять строк дают служебную информацию и БД монтируется и открывается. Вот так ваш сервер Oracle стартует для того, чтобы начать свою работу.
Теперь хорошо видно, что объем занимаемой памяти увеличился! :) К утилите Server Manager мы еще вернемся, так как она выполняет еще ряд полезных функций, а пока еще раз все внимательно разберите. Да и в конце не забудьте дать команду exit:
SRVMGR> exit
Получите:
Server Manager закончил работу.
И в заключении, экземпляр в котором не установлена БД, называется не занятым (idle). Он занимает память но, не выполняет никакой работы. Это как раз примерно то, о чем я говорил выше. Экземпляр остановлен, а сервис еще нет. Хотя в вашем случае сама БД уже есть, просто она остановлена. Надеюсь, теперь понятно, что такое экземпляр, а что такое сервер БД
Основные фоновые процессы Oracle
Для того, чтобы комплекс задач, одновременно решаемых Oracle, был обеспечен стабильным сопровождением и задачи выполнялись без сбоев, работа Oracle делится между вспомогательными программами, называемыми фоновыми процессами. Эти процессы действуют независимо один от другого и позволяют более эффективно использовать память, доступную для системы. Фоновые процессы реализованы по-разному в операционных системах семействаWindows и *nix. В частности, Windows фоновые процессы реализованы как потоки сервиса Oracle.
Процессы мониторов базы данных - это два процесса: SMON (System MONitor), PMON (Process MONitor).
Системный монитор (SMON) - после запуска базы данных выполняет автоматические восстановление экземпляров, следит за сегментами базы данных, фиксирует освобождение пространства во временных сегментах, автоматически объединяет временные сегменты.
Монитор процессов (PMON) - осуществляет контроль над поключениями к базе данных, контролирует потерю контакта пользователя с базой данных. Выполняет автоматические уборку мусора (Garbage Collector) - уборка предусматривает удаление сеанса, закрепленного за завершимся процессом, удаление блокировок, установленных им, и удаление непринятых транзакций. Также в задаче PMON входит слежение за процессами сервера и диспетчеров, их перезапуск в случае остановки.
DataBase WRiter (DBWR) - фоновый процесс переноса данных. Отвечает за перенос обновленных блоков, и производит перезапись в таких случаях:
1) обнаружена контрольная точка;
2) кол-во элементов в грязном списке достигло заданной величины;
3) кол-во использованных буферов достигло заданной величины;
4) по истечению заданного интервала времени (по умолчанию, это три секунды).
Фунционирование DBWR, в целом, происходит по такому алгоритму:
1. Произошло обновление блоков, но каждый блок не сразу записывается на диск после внесения изменений: выполняется ожидание, пока не произойдет одно из вышеперечисленных условий.
2. Просматривается список грязных блоков и все отмеченные в нем блоки перезаписываются в файлы данных на диске.
3. DBWR просматривает значения параметров настройки и в соответствии с ними уточняет детали алгоритма своей работы.
4. Если один процесс не успевает за обновлением данных, то запускаются новые процессы до определенного параметра в конфигурационном файле: значение количественного процесса.
5. При работе процесса DBWR определяется также кол-во блоков, записываемых для каждой контрольной точки.
Резюмируем:
В целом, алгоритм работы DBWR преследует такие основные цели:
1) учитывать все обновления, необходимые для записи в таблицы баз данных;
2) уменьшить влияние скоростных характеристик жестких дисков на производительность системы в целом;
3) максимальное увеличение производительности системы за счет использования механизма создания контрольных точек и отката транзакций;
4) наиболее эффективное использование оперативной памяти;
LoG WRiter (LGWR) - фоновый процесс для перезаписи информации из буфера журнала транзакций в файлы оперативного журнала (проще говоря, ведение журнала).
Такая перезапись происходит при одном из следующих условий:
1) транзакция принимается;
2) буфер журнала транзакций заполняется на одну треть;
3) процесс DBWR завершает перезапись данных из кэш-буфера после обнаружения контрольной точки.
Отметим некоторые важные особенности алгоритма работы LGWR:
1. Oracle не считает транзакцию выполненной, пока процесс LGWR не перезапишет данные о ней из буфера журнала транзакций в файл (пока не зафиксируется запись о ней в журнале).
2. Сообщение о завершении транзакций передается процессу сервера не после изменения данных в файле, а после успешного завершения записи в файл журнала транзакций.
3. Одной из побочных для процесса LGWR задач является обработка контрольных точек,