Взаимодействие компонент архитектуры

Теперь вы знаете, какие существуют компоненты архитектуры СУБД OpenEdge. Но для эффективного администрирования баз данных также важно понимать, как эти компоненты работают вместе.

В этой части урока мы сначала расмотрим, как эти компоненты работают совместно во время старта базы данных, а затем – как они взаимодействуют на работающей базе данных, когда пользователи запрашивают доступ и изменяют данные.

Во время старта базы данных

В момент старта базы данных в многопользовательском режиме стартуют и выполняют свои задачи различные компоненты архитектуры СУБД OpenEdge. Процесс старта базы данных можно описать следующим упрощённым алгоритмом:

1. В момент старта базы данных в многопользовательском режиме СУБД стартует процесс брокера.
2. Брокер выполняет алгоритм автоматического восстановления после сбоя (crash recovery), что гарантирует согласованность и целостность данных.
3. После этого брокер, основываясь на полученных при старте параметрах запуска, создаёт экземпляр разделяемой памяти.
4. После успешного создания экземпляра разделяемой памяти брокер создаёт файл локировки (.lk).
5. При условии успешного выполнения предыдущих пунктов брокер приступает к ожиданию клиентских запросов на подключение от дистанционных клиентов.

После старта базы данных вы должны вручную стартовать все дополнительные фоновые процессы. Например, для лицензии Enterprise вы стартуете процессы BIW, AIW, APW и WATCHDOG.

Таким образом, после старта базы данных и фоновых процессов:

• Брокер находится в ожидании запросов на подключение от дистанционных клиентов.
• Разделяемая память инициализирована и доступна для новых данных, данных получаемых с диска и/или манипуляции с данными.
• Фоновые процессы выполняют свои задачи в фоновом режиме.

Во время подключения к базе и просмотра данных

Стартованная база данных для обработки пользовательских запросов к данным использует все компоненты архитектуры СУБД OpenEdge (базу данных на диске, разделяемую память, брокеров, серверы и фоновые процессы).

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

1. Когда Пользователь А подключается к базе данных, Брокер сначала определяет тип клиента. В данном примере это дистанционный клиент.
2. Для дистанционного клиента Брокер проверяет наличие Сервера. Если серверов нет, то Брокер стартует Сервер А и закрепляет Пользователя А за этим сервером. В результате Пользователь А подключается к базе данных через Сервер А.
3. Аналогично, когда Пользователь Б подключается, Брокер определяет, что пользователь дистанционный и стартует другой сервер – Сервер Б.

В этом примере для наглядности приведено подключение к двум серверам. На практике у брокера есть параметры, определяющие минимальное и максимальное количество пользователей, которые может обрабатывать сервер одновременно прежде, чем будет стартован дополнительный сервер, это параметры старта базы данных -Mi и -Ma.

4. Брокер закрепляет Пользователя Б за Сервером Б. После этого пользователь считается подключённым к базе данных через сервер дистанционных клиентов.
5. Представьте, что Пользователю А необходимо сформировать отчёт. Для этого он запрашивает данные через свой сервер (Сервер А).
6. В свою очередь Сервер А отправляет пользовательский запрос в базу данных.
7. СУБД использует Хэш-таблицу для поиска записей с необходимыми данными в Буферном пуле базы данных.
8. Поскольку Пользователь А – это первый подключившийся к базе данных пользователь, то в Буферном пуле не будет обнаружено записей. Поэтому СУБД выполнит чтение блоков с необходимыми записями с диска и сохранит их в Буферном пуле.
9. После этого СУБД возвратит данные из буферного пула Серверу А.
10. Сервер А, получив запрошенные данные, вернёт их Пользователю А.
11. Теперь представьте, что Пользователь Б тоже формирует отчёт, отправив запрос в базу данных через Сервер Б.
12. Сервер Б отправляет пользовательский запрос в базу данных.
13. СУБД использует Хэш-таблицу для поиска записей с необходимыми данными в Буферном пуле базы данных.
14. Допустим, что некоторые из запрошенных записей обнаружены в Буферном пуле, так как ранее были считаны с диска для Пользователя А. Тем не менее другие записи обнаружены не были. В этом случае СУБД выполняет чтение с диска недостающих блоков с данными и сохраняет их в буферном пуле.
15. После того как СУБД имеет все данные в буферном пуле, происходит их передача Серверу Б.
16. В свою очередь Сервер Б передаёт полученные данные Пользователю Б.

Из этого примера видно, что чем больше данных будет считано в буферный пул и находится в памяти, тем быстрее эти данные будут предоставлены для последующих пользовательских запросов.

Во время изменения данных пользователями

Теперь посмотрим на взаимодействие компонентов архитектуры СУБД OpenEdge, когда пользователи изменяют данные. Следующий алгоритм показывает, как два подключённых к базе данных пользователя пытаются изменить одну и ту же запись с данными:

1. Представьте, что Пользователь А собирается изменить Запись А.
2. Сервер А, который обслуживает Пользователя А, отправляет запрос на поиск записи в Буферном пуле с помощью Хэш-таблицы.
3. Как только Запись А будет найдена в Буферном пуле, СУБД проверяет в Таблице локировок наличие отметки о локировании Записи А, а именно локировки SHARE-LOCK или EXCLUSIVE-LOCK.
4. Так как Пользователь А это первый пользователь, который пытается изменить Запись А, то эта запись не локирована.
5. Сервер А запрашивает эксклюзивную локировку на Запись А.
6. СУБД предоставляет Пользователю А эксклюзивную локировку (EXCLUSIVE-LOCK) на Запись А и добавляет информацию об этом в Таблицу локировок с указанием статуса CURRENT.
7. После этого Сервер А возвращает Запись А для Пользователя А.
8. Пользователь А приступает к изменению Записи А.
9. В этой точке Сервер А:
   • Получает изменённую запись.
   • Записывает транзакционные заметки в BI- и AI-буферы.
   • Обновляет содержащий Запись А буфер в буферном пуле.
10. Представьте, что пока Пользователь А изменяет Запись А, к базе данных подключился Пользователь Б с намерением изменить ту же Запись А.
11. Сервер Б, который обслуживает Пользователя Б, с помощью Хэш-таблицы выполняет поиск Записи А в Буферном пуле и находит её.
12. Далее Сервер Б проверяет Таблицу локировок и обнаруживает, что Пользователь А уже имеет эксклюзивную локировку на Запись А.
13. Сервер Б запрашивает эксклюзивную локировку на эту запись.
14. СУБД добавляет в Таблицу локировок запись об EXLUSIVE-LOCK Записи А, но устанавливает статус PENDING. Пользователь Б теперь будет ожидать освобождения записи Пользователем А.
15. Когда Пользователь А завершает изменение Записи А, СУБД OpenEdge снимает с записи эксклюзивную локировку Пользователем А и сразу устанавливает запрошенную локировку для Пользователя Б, одновременно делая соответствующие изменения в Таблице локировок.
16. После этого Сервер Б возвращает Запись А ожидающему Пользователю Б.
17. Пользователь Б выполняет изменение Записи А.
18. Затем Сервер Б получает изменённую Запись А и помещает её в соответствующий буфер в Буферном пуле.
19. На этом этапе Сервер Б:
    • Получает изменённую запись.
    • Записывает транзакционные заметки в BI- и AI-буферы.
    • Обновляет содержащий Запись А буфер в буферном пуле.
20. После того, как Пользователь Б завершил изменение записи, СУБД освобождает локировку, удаляя соответствующую информацию из Таблицы локировок.
21. В процессе формирования всех этих транзакций, Серверы А и Б записывали транзакционные заметки в BI- и AI-буферы.
22. Когда BI-буфер заполнится, процесс BIW запишет BI-заметки из BI-буфера в BI-файл на диске.
23. Когда AI-буфер заполнится, процесс AIW запишет AI-заметки из AI-буфера в AI-файл на диске.
24. Изменённые буферы в буферном пуле записываются процессами APW в базу данных на диске.
25. После завершения работы с данными пользователи отключаются от базы данных.
26. Оба сервера остаются ожидать новых клиентов.
27. Брокер продолжает ожидать входящие запросы на подключение дистанционных пользователей с готовностью направить их к существующим серверам.

Во время останова базы данных

В идеале останавливать работу базы данных требуется достаточно редко. Однако, если это все же понадобится, то необходимо выбрать время, когда в базе данных будет небольшая пользовательская активность или её вообще не будет. Что же происходит, когда мы выполняем штатный останов базы данных?

1. Брокер получает запрос на останов и инициирует его.
2. Все незавершённые транзакции, которые существуют в этот момент в базе данных, прерываются и отменяются.
3. Процесс BIW сохраняет оставшиеся BI-заметки из BI-буфера на диск в BI-файл.
4. Процесс AIW сохраняет оставшиеся AI-заметки из AI-буфера на диск в AI-файл.
5. Процесс APW сохраняет все изменённые буферы из буферного пула в файлы базы данных на диске.
6. Брокер:
   • Останавливает работу и отключает от базы данных всех дистанционных и самообслуживающихся клиентов.
   • Освобождает структуры разделяемой памяти (буферный пул, BI- и AI-буферы, таблицы разделяемой памяти).
   • Закрывает все файлы базы данных.
   • Удаляет файл локировки базы данных (.lk).
7. База данных остановлена.

О том, как останавливать базу данных средствами СУБД OpenEdge вы узнаете на уроке «Старт и останов базы данных».