Реферат: Системная архитектура и структура RDBMS ORACLE
--PAGE_BREAK--Системная архитектура ORACLE
В этом разделе обсуждаются структуры памяти и процессов, которые
используются ORACLE для управления базой данных. Среди прочего,
архитектурные особенности, описываемые здесь, помогут вам
понять, как ORACLE поддерживает многопользовательский доступ к
базе данных, и как обеспечивается высокая производительность,
требующаяся в многопользовательских, многозадачных системах баз
данных.
Структуры памяти и процессы
---------------------------
Механизмы ORACLE работают через использование структур памяти и
процессов. Все структуры памяти располагаются в основной памяти
(иногда называемой виртуальной памятью или памятью произвольного
доступа) компьютеров, составляющих систему базы данных.
ПРОЦЕССЫ - это задания или задачи, работающие в памяти этих
компьютеров.
Рис.1-3 показывает типичный вариант структур памяти и процессов
ORACLE. Все структуры памяти и процессы, изображенные на этой
схеме, обсуждаются ниже.
Рис.1-3
Структуры памяти и процессы ORACLE
<img width=«60» height=«40» src=«ref-1_1950294192-188.coolpic» v:shapes="_x0000_s1044"><img width=«59» height=«40» src=«ref-1_1950294380-188.coolpic» v:shapes="_x0000_s1043"><img width=«60» height=«40» src=«ref-1_1950294568-184.coolpic» v:shapes="_x0000_s1042">
<img width=«60» height=«31» src=«ref-1_1950294752-165.coolpic» v:shapes="_x0000_s1040"> RECO PMON SMON
<img width=«2» height=«21» src=«ref-1_1950294917-75.coolpic» v:shapes="_x0000_s1050"><img width=«2» height=«21» src=«ref-1_1950294992-75.coolpic» v:shapes="_x0000_s1049"><img width=«2» height=«21» src=«ref-1_1950294917-75.coolpic» v:shapes="_x0000_s1048"><img width=«59» height=«31» src=«ref-1_1950295142-169.coolpic» v:shapes="_x0000_s1039"><img width=«60» height=«31» src=«ref-1_1950295311-167.coolpic» v:shapes="_x0000_s1038">
LCK0
<img width=«2» height=«22» src=«ref-1_1950295478-75.coolpic» v:shapes="_x0000_s1051"><img width=«405» height=«117» src=«ref-1_1950295553-601.coolpic» v:shapes="_x0000_s1047">
<img width=«98» height=«2» src=«ref-1_1950296154-79.coolpic» v:shapes="_x0000_s1052"> Глобальная область системы (SGA)
<img width=«108» height=«60» src=«ref-1_1950296233-258.coolpic» v:shapes="_x0000_s1046"><img width=«223» height=«60» src=«ref-1_1950296491-320.coolpic» v:shapes="_x0000_s1045">
Буфер
Буферный кэш базы данных журнала
Пользова- повторения
<img width=«2» height=«98» src=«ref-1_1950296811-79.coolpic» v:shapes="_x0000_s1085"><img width=«2» height=«79» src=«ref-1_1950296890-78.coolpic» v:shapes="_x0000_s1075"><img width=«2» height=«50» src=«ref-1_1950296968-77.coolpic» v:shapes="_x0000_s1073"><img width=«2» height=«50» src=«ref-1_1950297045-77.coolpic» v:shapes="_x0000_s1069">тельские
процессы
<img width=«50» height=«22» src=«ref-1_1950297122-138.coolpic» v:shapes="_x0000_s1064"><img width=«41» height=«22» src=«ref-1_1950297260-132.coolpic» v:shapes="_x0000_s1063">
<img width=«30» height=«2» src=«ref-1_1950297392-75.coolpic» v:shapes="_x0000_s1094"><img width=«2» height=«232» src=«ref-1_1950297467-84.coolpic» v:shapes="_x0000_s1093"><img width=«98» height=«60» src=«ref-1_1950297551-253.coolpic» v:shapes="_x0000_s1058"><img width=«108» height=«60» src=«ref-1_1950297804-263.coolpic» v:shapes="_x0000_s1057"><img width=«89» height=«60» src=«ref-1_1950298067-243.coolpic» v:shapes="_x0000_s1055"> CKPT ARCH
<img width=«2» height=«166» src=«ref-1_1950298310-82.coolpic» v:shapes="_x0000_s1097"><img width=«2» height=«98» src=«ref-1_1950296811-79.coolpic» v:shapes="_x0000_s1096"><img width=«2» height=«127» src=«ref-1_1950298471-81.coolpic» v:shapes="_x0000_s1086"><img width=«2» height=«41» src=«ref-1_1950298552-76.coolpic» v:shapes="_x0000_s1084"><img width=«88» height=«60» src=«ref-1_1950298628-241.coolpic» v:shapes="_x0000_s1054"><img width=«88» height=«60» src=«ref-1_1950298869-245.coolpic» v:shapes="_x0000_s1053"> Разделяемый Выделенный
<img width=«2» height=«21» src=«ref-1_1950294917-75.coolpic» v:shapes="_x0000_s1077"><img width=«21» height=«2» src=«ref-1_1950299189-75.coolpic» v:shapes="_x0000_s1076"> пользова- серверный серверный
<img width=«60» height=«30» src=«ref-1_1950299264-165.coolpic» v:shapes="_x0000_s1062"><img width=«50» height=«30» src=«ref-1_1950299429-161.coolpic» v:shapes="_x0000_s1061"> тельский процесс процесс
<img width=«11» height=«2» src=«ref-1_1950299590-74.coolpic» v:shapes="_x0000_s1090"><img width=«2» height=«127» src=«ref-1_1950299664-81.coolpic» v:shapes="_x0000_s1089"><img width=«2» height=«60» src=«ref-1_1950291119-77.coolpic» v:shapes="_x0000_s1082"><img width=«2» height=«108» src=«ref-1_1950299822-80.coolpic» v:shapes="_x0000_s1078"><img width=«2» height=«41» src=«ref-1_1950298552-76.coolpic» v:shapes="_x0000_s1074"><img width=«2» height=«41» src=«ref-1_1950298552-76.coolpic» v:shapes="_x0000_s1072"> процесс DBWR LGWR
<img width=«2» height=«31» src=«ref-1_1950300054-76.coolpic» v:shapes="_x0000_s1095"><img width=«2» height=«31» src=«ref-1_1950300130-76.coolpic» v:shapes="_x0000_s1070">
<img width=«98» height=«60» src=«ref-1_1950300206-250.coolpic» v:shapes="_x0000_s1060"><img width=«50» height=«22» src=«ref-1_1950300456-138.coolpic» v:shapes="_x0000_s1059">
<img width=«98» height=«2» src=«ref-1_1950300594-79.coolpic» v:shapes="_x0000_s1071"><img width=«79» height=«50» src=«ref-1_1950300673-214.coolpic» v:shapes="_x0000_s1066"><img width=«60» height=«50» src=«ref-1_1950300887-202.coolpic» v:shapes="_x0000_s1065"> D000 пользова-
<img width=«31» height=«2» src=«ref-1_1950301089-76.coolpic» v:shapes="_x0000_s1083"><img width=«31» height=«2» src=«ref-1_1950301165-76.coolpic» v:shapes="_x0000_s1081"><img width=«2» height=«40» src=«ref-1_1950301241-76.coolpic» v:shapes="_x0000_s1080"> тельский Файлы Файлы
<img width=«11» height=«2» src=«ref-1_1950301317-74.coolpic» v:shapes="_x0000_s1087"> процесс данных журнала
<img width=«136» height=«2» src=«ref-1_1950301391-81.coolpic» v:shapes="_x0000_s1079"><img width=«98» height=«40» src=«ref-1_1950301472-211.coolpic» v:shapes="_x0000_s1068"><img width=«69» height=«40» src=«ref-1_1950301683-188.coolpic» v:shapes="_x0000_s1067">
Управл. Офлайновые
<img width=«12» height=«2» src=«ref-1_1950301871-74.coolpic» v:shapes="_x0000_s1088"> файлы устройства
<img width=«2» height=«21» src=«ref-1_1950301945-75.coolpic» v:shapes="_x0000_s1091">
<img width=«174» height=«2» src=«ref-1_1950302020-83.coolpic» v:shapes="_x0000_s1092">
Структуры памяти
----------------
ORACLE создает и использует свои структуры памяти для выполнения
некоторых задач. Например, память используется для размещения
исполняемого программного кода и данных, разделяемых между
пользователями. С ORACLE ассоциируются несколько базовых
структур памяти: глобальная область системы (которая включает
буфера базы данных и журнала повторения, а также разделяемый
пул) и глобальные области программ. Следующие секции подробно
объясняют каждую из этих видов областей.
Глобальная область системы (SGA)
ГЛОБАЛЬНАЯ ОБЛАСТЬ СИСТЕМЫ (SGA) - это область разделяемой
памяти, распределяемая ORACLE, которая содержит данные и
управляющую информацию для одной инстанции ORACLE. Область SGA
и фоновые процессы ORACLE составляют инстанцию ORACLE.
SGA распределяется при запуске инстанции и освобождается при
закрытии инстанции. Каждая запускающаяся инстанция имеет свою
собственную область SGA.
Данные в SGA разделяются (т.е. совместно используются) всеми
пользователями, присоединенными к базе данных. Для оптимальной
производительности SGA должна быть максимально большой (пока
позволяет реальная память), чтобы держать как можно больше
данных в памяти и минимизировать дисковые операции. Информация,
хранящаяся в SGA, подразделяется на несколько типов структур
памяти, включая буфера базы данных, буфера журнала повторения и
разделяемый пул. Эти области имеют фиксированные размеры и
создаются при запуске инстанции.
Буферный кэш базы данных
БУФЕРА БАЗЫ ДАННЫХ в SGA хранят наиболее недавно
использовавшиеся блоки данных из базы данных; все множество
буферов базы данных в инстанции составляет БУФЕРНЫЙ КЭШ БАЗЫ
ДАННЫХ. Эти буфера могут содержать модифицированные данные,
которые еще не записаны на диск для постоянного хранения.
Поскольку последние использовавшиеся (в том числе и наиболее
часто использующиеся) данные поддерживаются в памяти, требуется
меньше дисковых операций, и производительность увеличивается.
Буфер журнала повторения
БУФЕР ЖУРНАЛА ПОВТОРЕНИЯ в SGA хранит ЗАПИСИ ПОВТОРЕНИЯ — журнал
изменений, осуществленных в базе данных. Записи повторения,
хранящиеся в буферах журнала повторения, записываются в
онлайновый файл журнала, который используется при необходимости
восстановления базы данных. Его размер статичен.
Разделяемый пул
Разделяемый пул - это часть SGA, содержащая конструкты
разделяемой памяти, такие как разделяемые области SQL.
Разделяемая область SQL требуется для обработки каждого
уникального предложения SQL, выданного базе данных. Разделяемая
область SGA содержит такую информацию, как дерево разбора и план
исполнения для соответствующего предложения. Единственная
разделяемая область SGA используется всеми приложениями, которые
выдают то же самое предложение. Это позволяет оставлять
больше разделяемой памяти для других целей.
Курсоры
КУРСОР - это описатель (имя или указатель) области памяти,
ассоциированной с конкретным предложением. Хотя большинство
пользователей ORACLE полагаются на автоматическую обработку
курсоров, обеспечиваемую утилитами ORACLE, программные
интерфейсы предлагают разработчикам приложений большую степень
контроля над курсорами. Например, при разработке приложений
прекомпиляторов курсор является именованным ресурсом, доступным
программе, и может специально использоваться для разбора
предложений SQL, встроенных в приложение. Разработчик может
написать приложение так, чтобы оно контролировало фазы
исполнения предложения SQL и за счет этого повышало свою
производительность.
Глобальная область программы (PGA)
ГЛОБАЛЬНАЯ ОБЛАСТЬ ПРОГРАММЫ (PGA) - это буфер памяти,
содержащий данные и управляющую информацию для процесса сервера.
PGA создается ORACLE при запуске процесса сервера. Информация в
области PGA зависит от конфигурации ORACLE.
Процессы
--------
ПРОЦЕСС - это «канал управления», механизм в операционной
системе, который исполняет последовательность шагов. Некоторые
операционные системы используют термины ЗАДАНИЕ или ЗАДАЧА.
Процесс обычно имеет собственную область личной памяти, в
которой он работает.
СУБД ORACLE имеет два общих типа процессов: пользовательские
процессы и процессы ORACLE.
Пользовательские процессы (клиенты)
ПОЛЬЗОВАТЕЛЬСКИЙ ПРОЦЕСС создается и поддерживается для
исполнения программного кода прикладной программы (такой как
программа Pro*C) или инструмента ORACLE (такого как SQL*DBA).
Пользовательский процесс также управляет взаимодействием с
процессами сервера. Это взаимодействие осуществляется через
программный интерфейс, описываемый ниже в этом разделе.
Процессы ORACLE
ПРОЦЕССЫ ORACLE вызываются другими процессами для того, чтобы
выполнять функции от имени вызывающего процесса. Ниже
обсуждаются различные типы процессов ORACLE и их специфические
функции.
Процессы сервера
ORACLE создает ПРОЦЕССЫ СЕРВЕРА, чтобы обрабатывать запросы от
присоединенных пользовательских процессов. Процесс сервера
отвечает за связь с пользовательским процессом и за
взаимодействие с ORACLE для выполнения запросов ассоциированного
пользовательского процесса. Например, если пользователь
запрашивает данные, которых еще нет в буферах базы данных в SGA,
то ассоциированный процесс сервера считывает соответствующие
блоки данных из файлов данных в SGA.
ORACLE можно конфигурировать на различное число пользовательских
процессов на один процесс сервера. В КОНФИГУРАЦИИ ВЫДЕЛЕННОГО
СЕРВЕРА каждый процесс сервера обрабатывет запросы для одного
пользовательского процесса. КОНФИГУРАЦИЯ МНОГОКАНАЛЬНОГО
СЕРВЕРА позволяет многим пользовательским процессам совместно
использовать небольшое число процессов сервера, минимизируя
количество процессов сервера и максимизируя утилизацию доступных
системных ресурсов.
В некоторых системах пользовательский и серверный процессы
разделены, тогда как в других системах они объединены в единый
процесс. Если система конфигурирована на многоканальный сервер,
или если пользовательские и серверные процессы работают на
разных машинах, то пользовательский процесс и процесс сервера
должны быть раздельными.
Фоновые процессы
ORACLE создает множество ФОНОВЫХ ПРОЦЕССОВ для каждой инстанции.
В фоновых процессах сосредоточены те функции, которые иначе
пришлось бы выполнять множеством программ ORACLE, запускаемых
для каждого пользовательского процесса. Фоновые процессы
асинхронно выполняют операции ввода-вывода и отслеживают другие
процессы ORACLE, обеспечивая лучший параллелизм и улучшая
производительность и надежность.
Область SGA и фоновые процессы ORACLE в совокупности составляют
инстанцию ORACLE.
Каждая инстанция ORACLE может использовать несколько фоновых
процессов. Эти процессы имеют следующие имена: DBWR, LGWR,
CKPT, SMON, PMON, ARCH, RECO, Dnnn и LCKn. Каждый из этих
фоновых процессов описан ниже.
Писатель базы данных (DBWR)
ПИСАТЕЛЬ БАЗЫ ДАННЫХ записывает модифицированные блоки из
буферного кэша базы данных в файлы данных. Благодаря способу,
которым ORACLE осуществляет журнализацию, процессу DBWR не
требуется записывать эти блоки при завершении транзакции
Вместо этого DBWR оптимизирован
так, чтобы минимизировать обращения к диску. В общем случае,
DBWR выполняет запись лишь тогда, когда в SGA требуется
прочитать очередную порцию данных, а в буферном кэше недостает
свободных буферов. Первыми записываются те данные, к которым
было самое давнее обращение.
Писатель журнала (LGWR)
ПИСАТЕЛЬ ЖУРНАЛА записывает на диск записи журнала повторения.
Эти записи генерируются в буфере журнала повторения в SGA. Когда
транзакция завершается и буфер журнала заполняется, LGWR
переписывает записи журнала повторения в файл журнала
повторения.
Контрольная точка (CKPT)
В специфические моменты времени все модифицированные буфера в
SGA записываются процессом DBWR в файлы данных; это событие
называется контрольной точкой. Процесс КОНТРОЛЬНОЙ ТОЧКИ
отвечает за своевременную сигнализацию процессу DBWR о
контрольных точках и обновление всех файлов данных и управляющих
файлов базы данных, чтобы отразить последнюю контрольную точку.
Процесс CKPT не обязателен; если он отсутствует, его функции
берет на себя процесс LGWR.
Монитор системы (SMON)
МОНИТОР СИСТЕМЫ осуществляет восстановление инстанции во время
запуска инстанции. В системе с несколькими инстанциями (при
использовании Параллельного сервера), процесс SMON одной
инстанции может также осуществлять восстановление других
сбившихся инстанций. SMON также очищает временные сегменты,
которые больше не используются, и восстанавливает мертвые
транзакции, пропущенные после сбоя и восстановления инстанции в
результате сбоев файлов или офлайновых ошибок. Процесс SMON в
конечном счете восстанавливает такие транзакции, когда табличное
пространство или файл переводится в онлайн. SMON также сжимает
свободные экстенты в базе данных, чтобы сделать свободное
пространство непрерывным и более доступным для распределения.
Монитор процессов (PMON)
МОНИТОР ПРОЦЕССОВ осуществляет восстановление процесса после
сбоя пользовательского процесса. PMON отвечает за очистку кэша
и освобождение ресурсов, использовавшихся процессом. PMON также
контролирует диспетчерские и серверные процессы, и
рестартует их, если они сбиваются.
Архиватор (ARCH)
АРХИВАТОР копирует онлайновые файлы журнала повторения в
архивную память, когда они переполняются. ARCH активен лишь
тогда, когда журнал повторения используется в режиме ARCHIVELOG.
Восстановитель (RECO)
ВОССТАНОВИТЕЛЬ используется для разрешения распределенных
транзакций, зависших в результате сетевого или системного сбоя в
распределенной базе данных. В моменты, определяемые таймером,
локальный RECO пытается соединиться с удаленными базами данных и
автоматически подтвердить или отменить локальную порцию каждой
висящей распределенной транзакции.
Диспетчер (Dnnn)
ДИСПЕТЧЕРЫ — это необязательные фоновые процессы, существующие
лишь в конфигурации многоканального сервера. По меньшей мере
один диспетчерский процесс создается для каждого используемого
коммуникационного протокола (D000, ..., Dnnn). Каждый
диспетчерский процесс отвечает за маршрутизацию запросов от
присоединенных пользовательских процессов к доступным
разделяемым серверным процессам, и за возвращение ответов
обратно в ассоциированные пользовательские процессы.
Блокировка (LCKn)
До десяти процессов БЛОКИРОВКИ (LCK0, ..., LCK9) используются
для межинстанционных блокировок в среде Параллельного сервера
ORACLE.
Программный интерфейс
---------------------
ПРОГРАММНЫЙ ИНТЕРФЕЙС - это механизм, посредством которого
пользовательский процесс общается с процессом сервера. Он
выступает как метод стандартной коммуникации между любым
инструментом или приложением клиента (таким как SQL*Forms) и
программным обеспечением ORACLE. Программный интерфейс должен:
* действовать как механизм коммуникации, форматируя запросы
на данные, передавая данные, перехватывая и возвращая
ошибки
* выполнять преобразование и трансляцию данных, в
частности, между разными типами компьютеров, или во
внешние типы данных программы пользователя
продолжение
--PAGE_BREAK--
еще рефераты
Еще работы по информатике
Реферат по информатике
Объектно-ориентированные СУБД
2 Сентября 2013
Реферат по информатике
Информационные технологии управления 2 Реляционные базы
2 Сентября 2013
Реферат по информатике
Автоматизированная система документационного обеспечения управления
2 Сентября 2013
Реферат по информатике
Эскизное проектирование
18 Июня 2015