Важнейшая задача компьютерных систем управления - хранение и обработка данных. Для ее решения было создано специализированное программное обеспечение - системы управления базами данных (СУБД), которые позволяют структурировать, систематизировать и организовывать данные для их компьютерного хранения и обработки. Невозможно представить себе деятельность современного предприятия или учреждения без использования профессиональных СУБД. Они составляют фундамент информационной деятельности во всех сферах - начиная с производства и заканчивая финансами и телекоммуникациями.
Качество работы складывается как из аппаратного уровня, так и из программного уровня оснащения. Одним из способов обеспечения эффективности работы СУБД является оснащение ее профессиональной системой мониторинга.
Наиболее эффективными на сегодняшний день являются реляционные БД. Самой популярной в мировом масштабе является система управления реляционными БД (СУБД) - Oracle, которая предназначена для одновременного доступа к большим объемам хранимой информации. Ее используют крупные предприятия, занимающиеся информационными технологиями.
СУБД складывается из двух составляющих: БД (информация) и экземпляр или инстанция (конкретная реализация системы). База данных состоит из физических файлов, хранящихся в системе, и из логических частей.
Исследования проведенные над возможными структурами систем мониторинга инстанций СУБД определили на сегодняшний день представленную на рисунке 1 блок-схему.
Рассмотрим необходимые структурные компоненты и связи, приминительно к СУБД Oracle.
Дисковый массив (компонент физического уровня) Oracle:
реляционная БД (database files) - один или более файлов данных, в которых хранится информация в БД (можно иметь как один файл данных, так и сотни таких файлов), информация из одной таблицы может быть разбросана по нескольким файлам данных (а несколько таблиц могут делить между собой пространство файлов данных), таблицы распределяются по нескольким файлам данных, что может значительно увеличить производительность системы;
логирование операций (redo log files) - два или более файлов журналирования операций, которые содержат информацию, необходимую для процесса восстановления системы. Эти файлы хранят все изменения, которые произошли в БД. С помощью этого восстанавливаются те изменения, которые были произведены, но не зафиксированы перед сбоем системы. Файлы журналирования должны быть хорошо защищены против аппаратных сбоев (как на программном, так и на аппаратном уровне);
архив логов (archive log) - точная копия файлов журналирования операций.
Фоновыепроцессы (background processes) Oracle:
драйвер записи данных в БД (Database writer) - запись измененных (грязных) блоков из блоков буферов БД на диск. Когда транзакция изменяет информацию в блоке данных, этот блок данных не обязан быть немедленно записан на диск. Значит можно записывать данные на диск способом более эффективным, чем запись всех изменений по отдельности. Обычно записываются данные тогда, когда они уже нужны для чтения. Записываются также те данные, которые были недавно использованы. Для систем с асинхронным вводом-выводом достаточно одного процесса. Для остальных можно значительно увеличить производительность, создав несколько процессов;
драйвер записи логов (redo log writer) - записывает данные из журнального буфера в журнал изменений;
драйвер архивирующего устройства (archiver) - копирует файлы журнала изменений при их заполнении. Он активен лишь в том случае, если СУБРД работает в режиме ARCHIVELOG.
Системная глобальная область (system global are или SGA) - это область разделяемой памяти, которую Oracle использует для хранения данных и управляющей информации одного конкретного экземпляра Oracle. SGA размещается в памяти при запуске инстанции Oracle и освобождает память при останове. Каждый запущенный экземпляр Oracle имеет свою собственную SGA. Составляющие SGA (каждый из которых создается в памяти при запуске инстанции):
кэш-буфер БД - хранит последние открытые блоки данных. Эти блоки могут содержать данные, которые изменились, но еще не были записаны на диск (грязные блоки); данные, которые не изменялись либо были записаны на диск после изменения (чистые блоки). Так как кэш-буфер БД хранит блоки данных на основе алгоритма последних используемых блоков, то наиболее активно используемые блоки постоянно остаются в памяти (снижая дисковый ввод-вывод и увеличивая производительность системы);
буфер журнала изменений - хранит данные об изменениях БД. Буфер журнала изменений записывается в файл журнала изменений настолько быстро и эффективно насколько это возможно;
разделяемый пул - это область SGA, в которой хранятся такие структуры разделяемой памяти, как разделяемые SQL-области в библиотечном кэше и внутренняя информация словаря данных. Недостаточный объем разделяемого пула может привести к деградации производительности всей системы. Он состоит из библиотечного кэша и кэша словаря данных. Библиотечный кэш представляет собой область памяти, где сохраняются все операторы SQL и PL/SQL. Процессор БД понимает только команды SQL. Независимо от того, какие средства применяются для обеспечения взаимодействия пользователя с БД, лишь операторы SQL посылаются программному обеспечению для обработки.
Серверные процессы - это механизмы выполнения программного кода. Несколько процессов могут работать одновременно. СУБД работает с двумя видами процессов: пользовательские процессы и процессы Oracle.
пользовательские (клиентские) процессы - соединения пользователей с СУБД (управляет вводом и взаимодействует с серверными процессами Oracle через программный интерфейс Oracle). Они могут быть как однопользовательские (dedicated), так и многопользовательские (shared).
диспетчеры (dispatcher) - процесс, ответственный за каждый протокол связи. Они организуют взаимодействие между пользовательскими и разделяемыми серверными процессами.
SQL*Net - это клиентские сетевые компоненты и административные утилиты.
На предлагаемой схеме показаны необходимые структурные компоненты и связи, мониторинг которых необходимо осуществлять.
На компонентах дискового массива - реляционная БД - в процентном соотношении занятость файлами с данными от общего количества дискового пространства; логирование операций - занятость файлами с журналированием операций; архив логов - процент занятости на устройстве по резервированию (backup) файлов.
Стрелками обозначены связи между компонентами СУБД, мониторинг которых также обязателен.
Производительность всей системы в целом зависит от функционирования кэш-буфера БД, он состоит из блоков памяти того же размера, что и блоки Oracle. Все данные загружаются в кэш-буфер. В них же выполняется и любое обновление данных, поэтому очень важно правильно устанавливать размер буфера. Oracle переносит данные на диск (используется подкачку swap-данных) в соответствии с порядком их размещения в списке LRU (least recently used - наиболее давно использовавшиеся). Этот список отслеживает обращение к блокам данных и учитывает частоту обращения к ним. Когда выполняется обращение к блоку данных, хранящемуся в кэш-буфере, он помещается в тот конец списка - MRU (most recently used - недавно использованные). При этом, если серверу требуется место в кэш-буфере для загрузки нового блока с диска он обращается к списку LRU и решает какой из блоков перенести на диск, для того чтобы освободить место для нового блока. У блоков наиболее удаленных в списке от MRU самая большая вероятность удаления из кэш-буфера. Дольше всего остаются в кэш-буфере те блоки, обращение к которым производится наиболее часто. Анализ функционирования кэш-буфера выявил следующую блок-схему его работы.
Таблица X$BH содержит информацию о блоках в кэш-буфере. В ней можно увидеть, как "счетчик обращений" увеличивается при каждом обращении к блоку. Сначала находится блок. Используем блок таблицы DUAL - специальной таблицы, состоящей из одной строки и одного столбца (присутствует во всех БД Oracle). Найдем соответствующий номер файла и номер блока в файле:
select file_id, block_id
from dba_extents
where segment_name = 'DUAL' and owner = 'SYS';
FILE_ID BLOCK_ID
---------- ----------
1 870
Теперь можно использовать полученную информацию для получения "счетчика обращений" для этого блока:
select tch from x$bh where file#=1 and dbablk=870;
TCH
----------
2
select * from dual;
D
-
X
select tch from x$bh where file#=1 and dbablk=870;
TCH
----------
3
При каждом обращении увеличивается значение счетчика. Блоки со временем перемещаются по списку естественным путем, т.к. измененные блоки переносятся в список "грязных" (для записи на диск процессом DBWn). Если несмотря на повторное использование блоков кэш-буфер заполнился, и блок с небольшим значением "счетчика обращений" удаляется из списка, он возвращается с новыми данными примерно в середину списка. Интенсивно используемые блоки кэшируются надолго, а редко используемые - долго там не задерживаются.
Размер кэш-буфера определяется двумя параметрами настройки DB_BLOCK_SIZE и DB_BLOCK_BUFFERS (располагаются в файле init.ora). Общий объем кэш-буфера определяется, как произведение этих двух параметров DB_BLOCK_SIZE*DB_BLOCK_BUFFERS.
Включение sub-системы - детализированный мониторинг работы кэш-буфера БД в общую систему позволит оптимально определять размер кэш-буфера, что в свою очередь увеличит эффективность работы системного администратора СУБД и предотвратит возможность появления сбоев в работе процедур клиентских и системных приложений и увеличит производительность в целом.
Список литературы
Грин Джо и др. Oracle 8/8i Server. Энциклопедия пользователя: Пер. с англ./Джо Грин и др. - К.: Издательство "ДиаСофт", 2000. - 576 c.
Кайт Том Oracle для профессионалов. Книга 1. Архитектура и основные особенности: Пер. с англ./Том Кайт - СПб.: ООО "ДиаСофтЮП", 2003. - 672 c.
Новик Владимир Справочник. SQL, PL/SQL, SQL*Plus - Израиль: 2001. - 126 с.
Эбби Майкл, Кори Майкл, Абрамсон Йен Oracle9i: Первое знакомство - М.: Издательство "Лори", 2003. - 517 c.
Biju Thomas, Bryla Bob Oracle 9i DBA Fundamentals I: Study Guide - San Francisco: SYBEX Inc., 2002.
Biju Thomas, Bryla Bob Oracle 9i DBA Fundamentals II: Study Guide - San Francisco: SYBEX Inc., 2002.
Bobrowski Steven ORACLE7 Server Administrator's Guide - Ireland: 1992.
Prise Jason Oracle Database 10g SQL - McGraw-Hill/Osborne: 2004.
|
