CC BY
252
Проблемы производительности СУБД ORACLE под управлением сетевой ОС WINDOWS
Ключевые слова Огас1е, 'М'тбсмь, производительность, сетевая архитектура СУБД, метрики производительности, параметры физического проектирования.
Актуальность данной темы связана с широким использованием сетевой СУБД Огасіе во многих отраслях деятельности. Это связано с тем, что данная СУБД обладает коммерческой доступностью и гибким функционалом для разработки. Огасіе нашел широкое применение в частности в банковской сфере, где объемы данных чрезвмайно велики, в силу чего необходима также высокая производительность системы, и в то же время специфика сферы требует высокой надежности и отказоустойчивости при работе с транзакциями. Рассматривается такой вариант построения информационной системы, коїда все ее участники (сервер базы данных, сервер СУБД и рабочие станции пользователей) взаимодействуют через сеть, как самый распространенный на сегодняшний день в бизнесе. Разбираются такие вопросы, как архитектура ОС Мп^№ и сетевая архитектура СУБД Огасіе. Рассматриваются возникающие проблемы производительности при использовании данных ОС и СУБД. Анализируются методики измерения производительности СУБД и метрики, по которым эти измерения проводятся. Дается обзор параметров физического проектирования, влияющих на производительность системы, а также возможных решений по оптимизации производительности, с ними связанных.
Корогодова А.О.,
магистрант факультета Информационных
Технологий МТУСИ
Беленькая М.Н.
доцент кафедры "Мультимедийные Сети
и Услуги Связи"МТУСИ
Производительность системы — крайне актуальная сегодня проблема. Недостаточно, чтобы система просто работала, необходимо обеспечить высокую скорость ее работы. В свою очередь производительность в значительной степени определяется архитектурой системы. Архитектура любого программного продукта включает в себя программные модули и их взаимодействие между собой.
Архитектура Windows
"Сердцем" операционной системы Windows NT, работающим в тесной взаимосвязи с HAL, является ядро (или микроядро — microkernel). Ядро осуществляет диспетчеризацию процессов (трэдов) или их цепочек, обработку прерываний и исключительных ситуаций. Если компьютер имеет многопроцессорную архитектуру, ядро повышает производительность системы, синхронизируя работу процессоров. В мультипроцессорной конфигурации ядро может одновременно выполняться на всех процессорах.
Роль ядра заключается в том, чтобы обеспечить разделение ресурсов (в основном это память) для оптимальной загрузки всех процессоров и наилучшей производительности системы. Для этого ядро осуществляет диспетчеризацию трэдов в соответствии с их приоритетами, реализуемую модулем Windows NT Executive. Кроме того, ядро вытесняет (preempt) трэды с низким приоритетом в пользу более высокоприоритетных трэдов. Оно может принудительным образом выполнять переключения контекста (context switches), давая процессору инструкции прекратить выполнение одной задачи и взяться за другую. Таким образом, код, выполняющийся в такой системе, должен быть реентерабельным (reentrant). Под реентерабельностью кода понимается способность прервать выполнение и быть выгруженным, а также возобновить выполнение без потери информации. Кроме того, реентерабельный код может совместно использоваться несколькими различными трэдами, выполняющими различные строки одного и того же кода на различных процессорах.
Ядро является единственной неперемещаемой в памяти (non-pageable) и невыгружаемой (nonpreemptible) частью операционной системы. За редким исключением все остальные трэды, работающие в Windows NT 4.G, в том числе и в составе модуля Executive, являются выгружаемыми (preemptible) и полностью реентерабельными. За счет этого достигается максимальная эффективность системы.
Архитектура СУБД Oracle
• Ядро — модуль, который запускает все остальные процессы, передает им параметры и занимается поддержкой системы целостности.
• Data dictionary — хранит данные о данных (метаданные).
• Оптимизатор SQL-запросов.
• Набор модулей для самодиагностики.
• Совокупность утилит.
Основным компонентом СУБД является ядро. Когда говорят про запуск СУБД, имеют в виду запуск ядра, которое в свою очередь загружает другие необходимые компоненты.
Схема ядра сервера Oracle изображена на рис. 1.
Процессы ядра ORACLE
• DBWn — процесс записи в БД, отвечает за запись измененных блоков на диск;
• LGWR отвечает за сброс на диск содержимого буфера журнала повторного выполнения, находящегося в области SGA;
• PMON — монитор процессов, осуществляет управление процессами, отвечает за очистку после нештатного прекращения подключений, регистрирует запущенные экземпляры в процессе прослушивания;
• SMON — системный монитор, инициализирует структуры, осуществляет дефрагментацию таблиц, осуществляет восстановление экземпляра после сбоев и так далее;
• CKPT — процесс контрольной точки, осуществляет сброс грязных блоков на диск с пометкой синхронизации в момент времени (блок — грязный, если был изменен после подъема с диска);
• Listener — серверный процесс прослушивания, обеспечивающий физическое подключение к базе данных, выполняет запросы, читает данные с диска. На диск данные пишет фоновый процесс;
• ARCn копирует в redo log активный файл журнала повторного выполнения, когда он заполняется процессом LGWR. Эти архивные файлы журнала повторного выполнения затем можно использовать для восстановления носителя;
Рис. 1. Схема ядра сервера Oracle
• RECO восстанавливает транзакции, оставшиеся в готовом состоянии из-за сбоя или потери связи в ходе изменения данных на нескольких удаленных базах;
• Dn отвечает за обслуживание разделяемым сервером клиентов.
Словарь данных Oracle (data dictionary)
Словарь данных — центральное хранилище в каждой базе данных под управлением СУБД Oracle. Это также важный инструмент для всех пользователей, от конечных пользователей до разработчиков приложений и администраторов базы данных. Словарь данных — это набор множеств, который предоставляет информацию об ассоциированных с ними объектах базы данных. Например, словарь данных может предоставлять следующую информацию:
• имена пользователей Oracle;
• привилегии и роли, которые были предоставлены каждому пользователю;
• имена объектов схем (таблиц, обзоров, снимков, индексов, кластеров, синонимов, последовательностей, процедур, функций, пакетов, триггеров и т.д.);
• информацию об ограничениях целостности;
• умалчиваемые значения для столбцов;
• сколько пространства было распределено и в настоящее время используется объектами в базе данных;
• информацию аудитинга, например, кто обращался к различным объектам и обновлял их.
Словарь данных структурирован через таблицы и представления, как и любые другие данные в базе данных. Для обращения к словарю данных используется SQL. Так как словарь данных можно только читать, пользователи могут выдавать лишь запросы (предложения SELECT) по таблицам и представлениям словаря данных.
В состав словаря данных базы данных входят:
• базовые таблицы — совокупность, составляющая основу словаря. Читаются и пишутся только самим Oracle. Большая их часть закодирована;
• доступные пользователю представления — суммируют и отображают в удобном для пользователя виде полезную информацию из базовых таблиц.
Модуль оптимизации SQL-запросов
Оптимизация — важный шаг в обработке любого предложения языка манипулирования данными (SELECT, INSERT, UPDATE или DELETE). Когда выдается такой запрос, Oracle должен определить, как его выполнять. Oracle может иметь много различных способов выполнения одного и того же SQL-запроса. Выбор одного из этих способов осуществляет часть Oracle, называемая оптимизатором. Цель оптимизатора — выбрать наиболее эффективный способ для
выполнения SQL-запроса. Чтобы сделать лучший выбор из всех альтернатив, оптимизатор рассматривает ряд факторов.
Набор модулей для самодиагностики и автоматического принятия решений на основе результатов диагностики включает в себя:
• Монитор самодиагностики (ADDM).
• Модуль автоматического управления памятью (AMM).
• Модуль автоматического управления общей памятью (ASMM).
• Модуль автоматического сбора статистики (ASC).
• Модуль автоматического сбора статистики для оптимизации (AOSC).
Основные утилиты Oracle
• LogMiner — для восстановления транзакций и отмены изменений;
• DBMS_Repair — поиск и исправление поврежденных блоков данных;
• exp, expdp — для экспорта данных;
• imp, impdp — для импорта данных;
• RMAN — для резервирования и восстановления базы данных;
• SQL*Loader (SQLLDR) -средство массовой загрузки данных в СУБД Oracle
Запуск ядра СУБД Oracle происходит с определенными параметрами. Из них на производительность системы влияют следующие:
1. Способ ведения журнала транзакций
В СУБД Oracle используется журнал транзакций фиксированного размера, называемый также оперативным журналом повтора (online redo log). Рабочий объем журнала определяется при конфигурировании базы путем указания количества файлов журнала (не менее двух) и их размера. Выделение свободного места для записи генерируемого системой потока транзакций осуществляется по циклической схеме. Записи последовательно помещаются в один из файлов журнала (активный файл), по достижении конца которого производится переключение (logfile switching) на следующий по порядку файл либо на начало первого файла, если был заполнен последний из файлов журнала.
2. Размер блока
Размер блока системы управления базами данных лучше всего выбрать равным размеру блока сетевой операционной системы, который в свою очередь устанавливается равным размеру блока контроллера жесткого диска.
3. Соотношение буферов
К данным в оперативной памяти можно обратиться гораздо быстрее, чем к данным на диске. Поэтому большинство данных, необходимых прикладной программе, СУБД помещает в буферный пул. Администратору необходимо определить число буферов и задать максимально возможное. Часть буферов используется под операции записи в БД. Администратор должен задать процент буферного пространства, предназначенного для операций чтения и записи. Соотношение необходимой памяти для операций чтения и операций записи обычно составляет 80/20.
4. Очистка буферного пула (buffer flush)
До записи в журнал транзакций записи попадают в буферный пул. Транзакции из буферного пула должны переписываться на диск, иначе буфер будет переполняться. Как часто следует переписывать данные из буфера на диск, определяется ядром СУБД. После выдачи команды окончания транзакции записи не сразу попадают в журнал транзакций, потому что переписывание произойдет после заполнения буфера и его очистки ядром СУБД. Необходимо синхронизировать окончание транзакции и очистку буферного пула.
Необходимо предусмотреть, чтобы записи из буферного пула переносились в область данных и журнал транзакций СУБД либо в определенное время, либо по специальным командам.
5. Fill factor для данных и индексов
Коэффициенты свободного пространства (FILL FACTOR) для данных и для индексов определяют процент свободного пространства в блоках данных и блоках индексов. Эти коэффициенты используются для помещения новых записей и минимизации областей переполнения, могут повлиять на производительность операций ввода.
6. Параметры сортировки
Администратору базы данных следует ввести ограничение на область, выделяемую для сортировки данных, и ограничение на число индексов, иначе возможно ухудшение производительности ИС на операциях модификации (update) и ввода (insert).
7. Параметры ввода/вывода
Параметры операций ввода-вывода влияют на производительность всей системы и должны быть ответственно определены администратором базы данных. Они тесно связаны с проблемой физического проектирования базы данных.
• Параметры, определяющие место хранения индексных файлов. Файлы индексов должны храниться на самых быстрых устройствах.
•Параметры, определяющие кластеризацию. Данные, которые часто выбираются вместе, храниться должны также вместе. Поэтому необходимо задать соответствующие параметры расположения совместно используемой информации.
Метрики производительности
Эффективное управление информационной системой сложно представить без мониторинга и управления производительностью (Performance Management). Главной проблемой производительности является сложность ее оценки. Параметры, по которым оценивается производительность, называются метриками.
Метрики можно разделить на бизнес-метрики и технические метрики. Первые задаются бизнесом как критерии безошибочной работы информационной системы, вторые определяются аппаратными и программными средствами. В задаче оптимизации производительности СУБД важны технические метрики, к ним относятся:
•загрузка CPU;
•время загрузки приложения;
•время отклика на запрос;
•время записи информации на диск;
•число операций ввода-вывода в единицу времени;
•число взаимолокировок при локировании записей БД;
•число транзакций в единицу времени.
Для начала нужно определиться, какую метрику выбрать для измерений в данной конкретной системе. Процесс мониторинга производительности заключается в сборе различных показателей производительности со всевозможных компонент инфраструктуры (серверы, приложения, сетевое оборудование и др). Измерения нужно производить в течение определенного промежутка времени, длительность этого промежутка не стандартизирована, но обычно измерения проводят в течение месяца в дневное время, когда наблюдается пиковая нагрузка. К сожалению, в реальности возможность производить измерения в течение месяца предоставляется редко.
Затем нужно сравнить текущее состояние и производительность базовых компонентов с рекомендуемыми значениями (базовым уровнем).
Если измеренные метрики производительности не удовлетворяют рекомендованным значениям, возникает задача коррекции данных показателей и возвращения их значений к базовым. Основной способ коррекции — правильное физическое проектирование.
Литература
1. Oracle Database 2 Day DBA, 10g Release 2 // Colin McGregor — Oracle, 2012. — 210 с.;
2. Oracle. Оптимизация производительности. // Миллсап К., Хольт Д.
— СПб: Символ Плюс, 2006. — 464 с.;
3. Проектирование структур баз данных // Тиори Т., Фрай Дж. — М.: Мир, 1985. — 287 с.
4. Введение в операционные системы: учебное пособие для студентов высших учебных заведений // Д. В. Иртегов — СПб.: БХВ-Петербург, 2008.
— 1040 с.;
5. Администрирование в информационных системах // М.Н. Беленькая, С.Т. Малиновский, Н.В. Яковенко — М.: Горячая линия — Телеком, 2011.
— 400 с..
PERFORMANCE PROBLEMS OF ORACLE DBMS MANAGED BY NETWORK OPERATING SYSTEM WINDOWS Korogodova A.O., Belenkaya M.N. Abstract
Relevance of the topic is related to the extensive use of Oracle network DBMS in many fields of activity. This is due to the fact that this DBMS has the commercial availability and flexible functionality for development. Oracle is widely used in particular in the banking sector, where data volumes are very large, so it's necessary to have the high system performance, and at the same time, specificity of this sector requires high reliability and fault tolerance when dealing with transactions. The report considers way of developing the information system where all the participants (the database server, the DBMS server and users1 workstations) interact through the network, as the most common by far in the business. Windows OS1 architecture and Oracle DBMS network architecture are discussed, emerging performance problems of using these operating systems and database are too. Methods for measuring DBMS performance and metrics for these measurements are analyzed. Overview of physical design parameters that affect the performance of the system, as well as possible solutions to optimize the performance, associated with them, are given.
Keywords: Oracle, Windows, performance, DBMS network architecture, performance metrics, physical design parameters.
