Мониторинг баз данных

Оценить
(0 голоса)

Возможны случаи, когда базы данных становятся самоконтролируемыми и даже сами себя настраивают. В некоторых базах данных уже предприняты шаги в этом направлении, однако полностью автоматизированная настройка все еще далека от реальности. Вместо этого большинство баз данных связывает в узел изощренные инструменты мониторинга, часто с простыми в использовании GUIs, которые обеспечивают наблюдение за "здоровьем и поведением" базы данных. Попадания в буферный кэш БД, частота и продолжительность событий ожидания в системе, а также распределение операций чтения и записи среди различных файлов базы данных - это все примеры разновидностей мониторинга, обычно реализуемых либо интерактивно, либо автоматически в сценариях.

Модели процессов

Несмотря на то, что система базы данных кажется пользователю единым целым, на самом деле она создана из ряда различных компонентов. Отображение различных подсистем РСУБД в процессы операционной системы называется моделью процессов системы базы данных. Для СУБД, работающих в Solaris, используются две главные модели процессов; их наиболее распространенные названия - двухпроцессные и многопотоковые архитектуры.

Двухпроцессные архитектуры

Термин двухпроцессные (2п) отражает тот факт, что каждое соединение пользователя с базой данных поддерживается двумя процессами:

1.            Прикладной процесс, запускающий логику приложения.

2.            Процесс агента (shadow process - теневой процесс в терминологии Oracle), который

связывается с памятью совместного доступа базы данных и обращается к месту хранения информации от имени пользовательского процесса.

Процесс агента запускается в системе сервера БД. Прикладной процесс может быть запущен на сервере БД, отдельном сервере приложений или на рабочей станции пользователя. Если процесс агента и прикладной процесс принадлежат серверу базы данных, то они связываются с помощью механизмов IPC, если же они принадлежат различным системам, то связываются собственным протоколом обычно поверх TCP/IP. Доступ к базе данных осуществляется с помощью следующих механизмов:

1.            Прикладной процесс передает SQL-запросы процессу агента.

2.            Процесс агента проверяет синтаксис SQL-запросов и выполняет их.

3.            Процесс агента возвращает прикладному процессу ответный набор.

На самом деле модель SQL в части входных и выходных данных несколько упрощена, поскольку доступны еще и другие механизмы.

•             Хранимые процедуры. Stored procedure (хранимая процедура) - это функция или процедура, содержащая код SQL и логический код, которая компилируется и становится частью механизма базы данных. Программист может вызвать хранимую процедуру вместо индивидуального выполнения операторов SQL, сокращая при этом как количество взаимодействий приложение-агент, так и общее время выполнения. Чтобы выполнить хранимую процедуру и фиксировать статус возврата, языку программирования обычно доступно некоторое подобие вызова интерфейса API. Часто для пересылки данных хранимой процедуре и получения результатов ее запросов используются структуры.

•             Собственные программные интерфейсы. Некоторые СУБД предлагают программный интерфейс, отличный от SQL, для баз данных. Примером является OCI фирмы Oracle.

Базы данных, основанные на двухпроцессных архитектурах (Oracle и DB2 для Solaris), также используют отдельные процессы для других ключевых функций наподобие регистратора, очистителей страниц, монитора процессов.

Многопотоковые архитектуры
Параллельная обработка
Репликационные (тиражируемые) базы данных
Мониторы транзакций
Мультиплексирование пользователей

Добавить комментарий


Защитный код
Обновить