Для того, чтобы комплекс задач, одновременно решаемых 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 задач является обработка контрольных точек, однако для LGWR работа с контрольными точками возможна только в том случае, если процесс создания контрольных точек активирован.
ChecKPoinT (CKPT) - необязательный фоновый процесс (может быть (не)активирован).
четверг, 10 февраля 2011 г.
Буфер журнала транзакций (Redo Log Buffer)
Redo Log Buffer (RLB) - третья компонента GSA (Global System Area).
RLB представляет собой циклический буфер. Как только буфер заполняется и поступает новая информация, происходит запись в файлы журнала транзакций. Данные о транзакциях хранятся до тех пор, пока не будут переписаны данные оперативного журнала транзакций. С помощью системных средств можно оперативно контролировать процесс записи. Система может посылать специальный запрос для определения как долго пользовательские процессы находились в состоянии ожидания при обращении к буферу журнала транзакций.
Oracle ограничивает кол-во транзакций, данные о которых заносятся в журнал.
Можно также осуществлять мониторинг работы буфера журнала транзакций (RLB) с помощью специальных динамических представлений.
Журнал транзакций показывает свои преимущества при работе с большим количеством пользователей одновременно, запускающих сложные транзакций. При этом, возможны случаи возникновения сбоя в ходе выполнения транзакции. Тогда журнал транзакций является первым (а часто и единственным источником информации) о завершенных транзакциях и состоянии незавершенных транзакций. На основе информации из журнала транзакций возможно восстановление транзакции из контрольной точки и ее последующее завершение. То есть Oracle пытается восстановить состояние баз данных на момент наиболее поздней контрольной точки.
Выполнение одной транзакции может занимать много минут, однако за это время может поменяться важная информация (и видимо, существуют эффективные механизмы отката транзакций в Oracle).
Процесс восстановления данных о транзакциях и их перезапусках с возможных контрольных точек называется откатом транзакций (SAVEPOINT, CHECKPOINT).
RLB представляет собой циклический буфер. Как только буфер заполняется и поступает новая информация, происходит запись в файлы журнала транзакций. Данные о транзакциях хранятся до тех пор, пока не будут переписаны данные оперативного журнала транзакций. С помощью системных средств можно оперативно контролировать процесс записи. Система может посылать специальный запрос для определения как долго пользовательские процессы находились в состоянии ожидания при обращении к буферу журнала транзакций.
Oracle ограничивает кол-во транзакций, данные о которых заносятся в журнал.
Можно также осуществлять мониторинг работы буфера журнала транзакций (RLB) с помощью специальных динамических представлений.
Журнал транзакций показывает свои преимущества при работе с большим количеством пользователей одновременно, запускающих сложные транзакций. При этом, возможны случаи возникновения сбоя в ходе выполнения транзакции. Тогда журнал транзакций является первым (а часто и единственным источником информации) о завершенных транзакциях и состоянии незавершенных транзакций. На основе информации из журнала транзакций возможно восстановление транзакции из контрольной точки и ее последующее завершение. То есть Oracle пытается восстановить состояние баз данных на момент наиболее поздней контрольной точки.
Выполнение одной транзакции может занимать много минут, однако за это время может поменяться важная информация (и видимо, существуют эффективные механизмы отката транзакций в Oracle).
Процесс восстановления данных о транзакциях и их перезапусках с возможных контрольных точек называется откатом транзакций (SAVEPOINT, CHECKPOINT).
Отложенная многоблочная процедура записи на диск
В кэш-буфере выполняется любое обновление данных. Oracle переносит данные на диск, используя при этом подкачку в соответствии с алгоритмом работы файла подкачки.
Когда выполняется обращение к блоку данных, происходит формирование списка.
Модифицированные блоки называются грязными (и помещаются в список грязных блоков): dirty-список. В нем отслеживаются все модификации блоков данных, выполненные за время их нахождения в кэш-буфере и незафиксированных в этом списке. Когда Oracle получает запрос на изменение данных, соотвествующие изменения выполняются в блоках кэш-буфера, сведения об измененных блоках заносятся в dirty-список. При этом одновременно данные о выполненных операциях заносятся в журнал транзакций. В дальнейшем, при обращении к блокам данных, попавшим в список грязных блоков, будут считываться уже модифицированные значения, хотя сами данные при этом могут быть еще не зафиксированы.
Таким образом, реализуется отложенная многоблочная процедура записи на диск.
Отсюда следует, что понятие отложенности означает: обновления данных, выполненные сервером, не фиксируются немедленно, а сервер ждет, пока не возникнут такие события:
1) внесены изменения в некоторое заранее установленное количество блоков данных;
2) обнаружена контрольная точка.
При наступлении любого из этих случаев группа модифицированных блоков переписывается на диск из кэш-буфера в файл. Для наиболее эффективной работы Oracle важно правильно задать размер кэш-буфера. Этот размер задается с помощью двух параметров в файле init.ora:
* dbBlockSize (размер блока)
* dbBlockBuffers (количество блоков)
Общий объем кэш-буфера в байтах определяется как произведение этих двух параметров.
Когда выполняется обращение к блоку данных, происходит формирование списка.
Модифицированные блоки называются грязными (и помещаются в список грязных блоков): dirty-список. В нем отслеживаются все модификации блоков данных, выполненные за время их нахождения в кэш-буфере и незафиксированных в этом списке. Когда Oracle получает запрос на изменение данных, соотвествующие изменения выполняются в блоках кэш-буфера, сведения об измененных блоках заносятся в dirty-список. При этом одновременно данные о выполненных операциях заносятся в журнал транзакций. В дальнейшем, при обращении к блокам данных, попавшим в список грязных блоков, будут считываться уже модифицированные значения, хотя сами данные при этом могут быть еще не зафиксированы.
Таким образом, реализуется отложенная многоблочная процедура записи на диск.
Отсюда следует, что понятие отложенности означает: обновления данных, выполненные сервером, не фиксируются немедленно, а сервер ждет, пока не возникнут такие события:
1) внесены изменения в некоторое заранее установленное количество блоков данных;
2) обнаружена контрольная точка.
При наступлении любого из этих случаев группа модифицированных блоков переписывается на диск из кэш-буфера в файл. Для наиболее эффективной работы Oracle важно правильно задать размер кэш-буфера. Этот размер задается с помощью двух параметров в файле init.ora:
* dbBlockSize (размер блока)
* dbBlockBuffers (количество блоков)
Общий объем кэш-буфера в байтах определяется как произведение этих двух параметров.
среда, 2 февраля 2011 г.
Архитектура базы данных Oracle
В этом курсе мы будем работать с Oracle 10g Lite (Express Edition).
СУБД Oracle обеспечивает высокий уровень сервиса, гибкость и производительность. Это возможно в связи с тем, что клиентам предоставляется сложный комплекс структур памяти и процессов операционной системы. Все эти понятия в совокупности называются экземпляром Oracle.
Любая база данных Oracle имеет связанный с ней экземпляр, который формируется при инсталляции базы. Организация экземпляра позволяет системе обслуживать множество типов транзакций, инициируемых одновременно большим количеством пользователей. При этом обеспечивается высокая производительность, целостность данных и безопасность.
Oracle может называться:
При работе Oracle одновременно присутствует множество процессов, выполняющих специфические задачи. Каждый процесс имеет отдельный блок памяти для хранения локальных переменных, стек адресов и другую информацию. Все эти процессы имеют общую область памяти, называемую разделяемой областью памяти. В этой памяти хранятся данные общего пользования. В англоязычной литературе называется Global System Area (GSA). Доступ к GSA для записи и чтения могут получить одновременно различные процессы и программы. Эта область находится в разделяемом сегменте памяти. Можно считать, что GSA - единый центр для координации и управления всеми процессами обработки информации, происходящими в системе.
Для 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
Экземпляр, в котором не установлена база данных, называется незанятым. Он занимает определенную область памяти, но не выполняет никакой работы. В этом случае возникает ситуация, когда экземпляр установлен, но сервис базы данных не установлен.
GSA (Глобальная системная область)
Назначение и структура ГСО:
В GSA хранятся структуры памяти, необходимые для манипулирования данными для анализа предложений SQL, для кэширования транзакций. Все операции базы данных в том или ином виде используют информацию, находящуюся в GSA.
GSA состоит из таких компонент:
* разделяемый пул (Shared Pool) - содержит кэш библиотек, кэш словаря, управляющие структуры сервера.
Кэш библиотеки используется для хранения текста, хранения форматов лексического анализатора, хранение плана выполнения предложений SQL, хранение заголовки PL/SQL пакетов и процедур, выполнявшихся ранее.
Кэш словаря предназначен для хранения строки словаря данных, которая была использована для анализа предложений SQL. Таких строк может быть несколько.
// Оракл работает со своей версией SQL - называется PL/SQL.
Использование разделяемого пула для обработки SQL-выражений
Сервер Oracle использует кэш библиотеки для повышения производительности и скорости выполнения операций и операторов SQL. Когда передается очередное SQL-выражение, в первую очередь просматривается кэш, и в нем отыскивается выражение подобное выполнявшемуся ранее. Если оно найдено, то выполняется соответствующее дерево лексического анализа (в соответствии с хранящимися форматами лексического анализатора) - это приводит к существенному повышению скорости выполнения операторов SQL. Однако такой механизм работает только в том случае, если SQL-выражение полностью идентичны, включая совпадения регистров символов.
Локальная область формируется для каждой инициируемой транзакции и освобождается после закрытия соответствующего курсора, связанного с соответствующей транзакцией.
Поэтому Oracle может повторно использовать информацию, общую для всех выражений SQL, а информация, специфическая для данного сеанса, выбирается из локальной области предусмотренной в разделяемом пуле.
В общем, для кэша библиотек в разделяемом пуле выделяется две области:
1. Разделяемая область SQL.
2. Локальная область SQL.
Локальная область SQL делится также на две части:
1. Переходящая область SQL - содержит информацию, которая сохраняет свое значение и может быть использована несколькими выражениями SQL.
2. Область времени выполнения (runtime) - содержит только ту информацию, которая нужна для выполняемого в текущий момент выражения.
Кэш словаря содержит информацию содержит, необходимую для лексического анализа SQL-выражений.
Контрольные суммы предназначены для анализа правильности вычисления выражений и выполнения действий, указанных ранее.
Учитывая изложенный механизм работы Oracle, следует отметить, что выполнение одиночных, простых SQL-инструкций на Oracle не будет выполняться быстрее, чем Delphi & FoxPro. Однако, реализация сложной программы выполнится с существенными преимуществами по эффективности и времени.
Однако в целом можно сказать, что производительность системы зависит от функционирования кэш-буфера.
Назначение и функционирование кэш-буфера
Данные загружаются в кэш-буфер. Он состоит из блоков памяти того же размера, что и блоки Oracle. В блоках кэш-буфера выполняется любое обновление данных. Oracle переносит данные между кэш-буфером и диском в соответствии со списочной организацией памяти, в которой учитывается частота обращения к блокам данных. Данные, изменения которых наименее вероятно, располагаются в начале списка и в первую очередь записываются на диск.
Частообновляемые данные остаются в кэше на наиболее длительное время.
Вступление к предмету
FoxPro - это СУБД реляционного типа, которая имеет возможность работать с объектами, поэтому и вот это чудовище - тоже ОР СУБД.
Есть два похода к объектно-ориентированному проектированию БД:
Первый подход: есть сервер и мы работаем с ним на языке, который поддерживает этот сервер.
Второй подход: ставим целостную СУБД и работаем на языке самой СУБД.
Второй подход: ставим целостную СУБД и работаем на языке самой СУБД.
(о связи с системным анализом)
В базах данных можно выделить фазу проектирования и фазу реализации.
На фазе проектирования весьма рационально, если говорить об ООП-проектированию, можно использовать подходы системного анализа.
Rational Rose + UML + Case diagramms + RDBMS = ООПБД
На фазе проектирования весьма рационально, если говорить об ООП-проектированию, можно использовать подходы системного анализа.
Rational Rose + UML + Case diagramms + RDBMS = ООПБД
Подписаться на:
Сообщения (Atom)