Исходники
Статьи
Языки программирования
.NET Delphi Visual C++ Borland C++ Builder C/С++ и C# Базы Данных MySQL MSSQL Oracle PostgreSQL Interbase VisualFoxPro Веб-Мастеру PHP HTML Perl Java JavaScript Протоколы AJAX Технология Ajax Освоение Ajax Сети Беспроводные сети Локальные сети Сети хранения данных TCP/IP xDSL ATM Операционные системы Windows Linux Wap Книги и учебники
Скрипты
Магазин программиста
|
Некоторые аспекты обеспечения эффективности работы системы управления базами данныхВажнейшая задача компьютерных систем управления - хранение и обработка данных. Для ее решения было создано специализированное программное обеспечение - системы управления базами данных (СУБД), которые позволяют структурировать, систематизировать и организовывать данные для их компьютерного хранения и обработки. Невозможно представить себе деятельность современного предприятия или учреждения без использования профессиональных СУБД. Они составляют фундамент информационной деятельности во всех сферах - начиная с производства и заканчивая финансами и телекоммуникациями. Качество работы складывается как из аппаратного уровня, так и из программного уровня оснащения. Одним из способов обеспечения эффективности работы СУБД является оснащение ее профессиональной системой мониторинга. Наиболее эффективными на сегодняшний день являются реляционные БД. Самой популярной в мировом масштабе является система управления реляционными БД (СУБД) - Oracle, которая предназначена для одновременного доступа к большим объемам хранимой информации. Ее используют крупные предприятия, занимающиеся информационными технологиями. СУБД складывается из двух составляющих: БД (информация) и экземпляр или инстанция (конкретная реализация системы). База данных состоит из физических файлов, хранящихся в системе, и из логических частей. Исследования проведенные над возможными структурами систем мониторинга инстанций СУБД определили на сегодняшний день представленную на рисунке 1 блок-схему. Рассмотрим необходимые структурные компоненты и связи, приминительно к СУБД Oracle, представленные на рисунке 1. Рисунок 1. Блок-схема управления БД Дисковый массив (компонент физического уровня) Oracle:
Фоновые процессы (background processes) Oracle:
Системная глобальная область (system global are или SGA) - это область разделяемой памяти, которую Oracle использует для хранения данных и управляющей информации одного конкретного экземпляра Oracle. SGA размещается в памяти при запуске инстанции Oracle и освобождает память при останове. Каждый запущенный экземпляр Oracle имеет свою собственную SGA. Составляющие SGA (каждый из которых создается в памяти при запуске инстанции):
Серверные процессы - это механизмы выполнения программного кода. Несколько процессов могут работать одновременно. СУБД работает с двумя видами процессов: пользовательские процессы и процессы Oracle.
SQL*Net - это клиентские сетевые компоненты и административные утилиты. На предлагаемой схеме показаны необходимые структурные компоненты и связи, мониторинг которых необходимо осуществлять. На компонентах дискового массива - реляционная БД - в процентном соотношении занятость файлами с данными от общего количества дискового пространства; логирование операций - занятость файлами с журналированием операций; архив логов - процент занятости на устройстве по резервированию (backup) файлов. Стрелками обозначены связи между компонентами СУБД, мониторинг которых также обязателен. Производительность всей системы в целом зависит от функционирования кэш-буфера БД, он состоит из блоков памяти того же размера, что и блоки Oracle. Все данные загружаются в кэш-буфер. В них же выполняется и любое обновление данных, поэтому очень важно правильно устанавливать размер буфера. Oracle переносит данные на диск (используется подкачку swap-данных) в соответствии с порядком их размещения в списке LRU (least recently used - наиболее давно использовавшиеся). Этот список отслеживает обращение к блокам данных и учитывает частоту обращения к ним. Когда выполняется обращение к блоку данных, хранящемуся в кэш-буфере, он помещается в тот конец списка - MRU (most recently used - недавно использованные). При этом, если серверу требуется место в кэш-буфере для загрузки нового блока с диска он обращается к списку LRU и решает какой из блоков перенести на диск, для того чтобы освободить место для нового блока. У блоков наиболее удаленных в списке от MRU самая большая вероятность удаления из кэш-буфера. Дольше всего остаются в кэш-буфере те блоки, обращение к которым производится наиболее часто. Анализ функционирования кэш-буфера выявил следующую блок-схему его работы, представленную на рисунке 2. Эта схема приминима только для версий Oracle не младше 8i. Рисунок 2. Блок-схема работы кэш-буфера БД Таблица 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-системы - детализированный мониторинг работы кэш-буфера БД в общую систему позволит оптимально определять размер кэш-буфера, что в свою очередь увеличит эффективность работы системного администратора СУБД и предотвратит возможность появления сбоев в работе процедур клиентских и системных приложений и увеличит производительность в целом. Список литературы
|
Форум Программиста
Новости Обзоры Магазин Программиста Каталог ссылок Поиск Добавить файл Обратная связь Рейтинги
|