СЕКРЕТЫ OPENEDGE: УПРАВЛЕНИЕ БАЗАМИ ДАННЫХ OPENEDGE ПРИ ПОМОЩИ OPENEDGE MANAGEMENT

ОБЛАСТИ ХРАНЕНИЯ TYPE I И TYPE II

Области хранения Type II (известны как кластеризуемые области хранения) позволяют группировать данные в кластерах. Размер этих кластеров является настраиваемым для каждой области. Глава «Оптимизация размещения данных» подробнее освещает необходимость использования областей Type II. А этот раздел описывает различия между областями Type I и Type II. Области Type I имеют блок контроля области (Area Control Block), который отслеживает выделенный для области объем и максимальное количество пространства внутри области. Области второго типа имеют кластер контроля области (Area Control Cluster), который содержит блок контроля области и блоки объектов, хранящие цепочки распределения пространства для каждого объекта (таблица, индекс, BLOB, CLOB). Такой кластер является всегда первым в области хранения Type II. Поскольку эти объекты теперь обрабатываются отдельно друг от друга, то существует понятие множественных  цепочек свободных блоков. Каждый объект в области типа II будет иметь достаточно пространства для своего роста в пределах кластера. Если пространства нет — выделяется следующий кластер.  Индивидуальные цепочки свободных блоков дополняют цепочки свободных блоков области. Каждый кластер объединен в цепочку — на его начало указывает предыдущий кластер, а сам он в конце указывает на следующий кластер. Таким образом, только первые и последние блоки кластеров в области Type II физически отличаются друг от друга, так как содержат информацию об указателях. Все остальные блоки остаются такими же, как и в Type I, но их последовательность основана на настройке количества блоков на кластер области.

ИСПОЛЬЗОВАНИЕ ПАМЯТИ

Процесс primary broker выделяет для пользователей разделяемую (shared) память.  Пользователи используют структуры в этой памяти в режиме параллельного доступа к данным. Доступ предоставляется таким образом, что повредить данные невозможно.

К примеру, если бы два пользователя захотели  одновременно обновить одну и ту же область памяти различным содержимым, то в базе данных было бы отражено обновление только одного пользователя. Это неверно и приводит к неполному обновлению памяти. Рассмотрим механизм, который не допускает таких повреждений.

Рассмотрим важное понятие –  блокировка (locking) и то, как она применяется в этой ситуации. Заблокированная запись (locked record) позволяет провести своё обновление в изоляции от других пользователей. Защёлка (Latch) — это блокировка в разделяемой памяти, которая позволяет пользователю модифицировать содержимое блока памяти изолированно от других пользователей. Этот механизм стал развиваться в Progress с версии 6.3. В самом начале этот механизм был сырым и неуклюжим.  Механизм защелок управлял всем пулом разделяемой памяти и заставлял ждать всех пользователей при обновлениях блока памяти. Начиная с версии 8 для каждого ресурса существует свой набор защелок.

Просмотр блокировок и защелок в OpenEdge Management

Вы можете просмотреть эти защелки при помощи OE Management, как показано на иллюстрации

Чтобы увидеть блокировки и защелки в OE Management, необходимо:

1. Выбрать Resources из меню консоли OE Management
2. Выбрать базу данных из списка
3. Выбрать Locks and Latches в секции Operation Views из фрейма детальной информации о БД

РЕСУРСЫ РАЗДЕЛЯЕМОЙ ПАМЯТИ

На иллюстрации ниже можно видеть примерную схему того, какие ресурсы БД находятся в разделяемой памяти. Поскольку это просто пример, в схеме отображены не все ресурсы. Кроме того — схема не в масштабе. Например, буфера БД занимают более 90% от всего пула разделяемой памяти, а структуры защёлок — менее одного процента.

Буферный пул базы данных — жизненно важная структура. Эта область памяти отводится под кэширование часто запрашиваемых данных из базы. Таким образом, эти данные один раз считываются с диска в память и в дальнейшем извлекаются только из памяти. Поскольку память намного быстрее диска, то это обеспечивает заметный прирост производительности (если, конечно, всё правильно настроено). Настройка буферного пула базы данных далее рассматривается в главе «Оптимизация использования памяти».

Как видно на иллюстрации — в разделяемой памяти находится множество ресурсов. Локальные пользователи (процессы конечных пользователей и пакетные (batch) процессы) обновляют эти ресурсы. Если два пользователя базы данных одновременно хотят сделать обновление таблицы блокировки (-L), то первый пользователь запрашивает ресурс просматривая таблицу контроля защёлок (Latch Control Table). Если ресурс доступен, то пользователь устанавливает защелку (Latch) на ресурс таблицы блокировок при помощи вызова операционной системы. Это гарантирует, что ни один другой процесс не сможет сделать то же самое параллельно. Как только защелка взведена, пользователь выполняет необходимые ему обновления ресурса и, в конце, освобождает защелку (release latch). Если в это время другие пользователи хотят получить доступ к ресурсу — они вынуждены ждать и повторять свой запрос на ресурс до тех пор, пока защелка не будет освобождена. Более подробная информация о защелках будет представлена в главе «Оптимизируем использование CPU».

Другие процессы, изображенные на иллюстрации — это «писатели страниц» — Page Writers. Процесс Асинхронный Page Writer ( Acynchronous Page Writer или APW) записывает модифицированные буфера базы данных на диск. Для одной базы данных может быть запущено больше одного APW. Другие процессы-писатели After-image Writer (AIW) и Before-image Writer (BIW) записывают на диск буфера after-image и before-image. Для базы данных иожно запустить только один процесс AIW и только один процесс BIW.

ДОБАВЛЕНИЕ УДАЛЕННЫХ КЛИЕНТОВ

На иллюстрации  изображено как появляются сокеты TCP/IP и процессы серверов при добавлении удаленных клиентов.

Удалённые клиенты шлют сообщение сокету-слушателю, который, в свою очередь, предупреждает процесс брокера. Для того, чтобы определить — может ли пользователь войти и к какому серверному процессу его подключить — процесс брокера просматривает таблицу контроля пользователей (User Control Table) и таблицу контроля серверных процессов (Server Control Table). Если сервер не активен, то он запускается используя параметры сервера для этого брокера (параметры -Mn, -Mi, -Ma итд). Подробнее данные параметры описаны в руководстве «OpenEdge Data Management: Database Administration«. Как только найден подходящий сервер, между этим сервером и удаленным клиентов устанавливается двустороннее соединение. Это соединение остается открытым до момента отсоединения пользователя или до останова брокера.

Вы можете использовать OpenEdge Management  для просмотра подключений к БД. Для этого:

1. Выберите пункт Resources из верхней полоски меню.
2. Из списка выберите базу данных
3. Выберите User Activity в секции Operation Views фрейма деталей. Появится страница Users
4. Чтобы просмотреть информацию о пользователе и о сервере, к которому пользователь присоединен — необходимо выбрать пользователя из фрейма Users
5. Выберите сервер, к которому подсоединен пользователь, чтобы узнать, подключен ли еще кто-нибудь к этому серверу. Ниже, на иллюстрации страница детальной информации о сервере

Эта детальная информация особенно полезна, если в вашей системе наблюдаются проблемы производительности только у части клиентов. Если эти клиенты подсоединены к серверу, который занимается построением отчета или выполняет интенсивные операции чтения, то вы можете определить проблему и принять меры по ликвидации последствий.