Oracle для профессионалов
Избегайте длительных транзакций в среде MTS
Решение использовать транзакции продолжительностью более 45 секунд в среде MTS выдало недостаточное понимание назначения режима MTS и особенностей его работы в Oracle. Если коротко, в режиме MTS используется общий пул серверных процессов, обслуживающий намного больший пул конечных пользователей. Это похоже на пул подключений. Поскольку создание и управление процессом — наиболее дорогостоящие операции, выполняемые операционной системой, режим MTS дает большие преимущества для крупномасштабной системы. Можно обслуживать 100 пользователей всего пятью или десятью разделяемыми серверными процессами.
Когда разделяемый серверный процесс получает запрос на изменение данных или выполнение хранимой процедуры, он привязывается к этой задаче до ее завершения. Ни одна другая задача не будет использовать разделяемый серверный процесс, пока не будет закончено изменение или не завершится выполнение хранимой процедуры. Поэтому при использовании режима MTS надо использовать как можно быстрее выполняющиеся операторы. Режим MTS создан для обеспечения масштабируемости систем оперативной обработки транзакций (OLTP), для которых характерны операторы, выполняющиеся за доли секунды. Речь идет об изменениях отдельных строк, вставке нескольких строк и запросах записей по первичному ключу. Не стоит в этом режиме выполнять пакетные процессы, для завершения которых требуются десятки секунд или минуты.
Если все операторы выполняются быстро, архитектура MTS работает отлично. Можно эффективно обслуживать небольшим количеством процессов большое сообщество пользователей. Если же имеются сеансы, монополизирующие разделяемый сервер надолго, то кажется, что СУБД "зависает". Пусть сконфигурировано десять разделяемых серверов для поддержки 100 пользователей. Если в некоторый момент времени десять пользователей одновременно введут оператор, выполняющийся более 45 секунд, то всем остальным транзакциям (и новым подключениям) придется ждать. Если некоторым из ожидающих в очереди сеансов необходимо выполнять оператор такой же продолжительности, возникает большая проблема — "зависание" будет продолжаться не 45 секунд, а намного дольше. Даже если желающих выполнить подобный оператор одновременно будет не десять, а лишь несколько, все равно будет наблюдаться существенное падение производительности сервера. Мы отберем на длительное время совместно используемый ресурс, и это плохо. Вместо десяти серверных процессов, выполняющих быстрые запросы в очереди, остается пять или шесть (или еще меньше). Со временем система станет работать с производительностью, заметно меньше предполагаемой, исключительно из-за нехватки этого ресурса.
Простое решение "в лоб" состоит в запуске большего количества разделяемых серверов, но в конечном итоге придется запускать разделяемый сервер для каждого пользователя, а это неприемлемо для системы с тысячами пользователей (как та, что создавалась в рассматриваемом проекте). Это не только создает узкие места в самой системе (чем большим количеством процессов приходится управлять, тем больше процессорного времени на это уходит), но и просто не соответствует целям создания режима MTS.
Реальное решение этой проблемы оказалось простым: не выполнять продолжительные транзакции на сервере, работающем в режиме MTS. А вот реализация этого решения оказалась сложнее. Это можно было сделать несколькими способами, но все они требовали существенных изменений архитектуры. Самым подходящим способом, требующим минимальных изменений, оказалось использование средств расширенной поддержки очередей (Advanced Queues — AQ).
AQ — это промежуточное программное обеспечения для обмена сообщениями, реализованное на базе СУБД Oracle и позволяющее клиентскому сеансу добавлять сообщения в таблицу очереди базы данных. Это сообщение в дальнейшем (обычно сразу после фиксации транзакции) выбирается из очереди другим сеансом, проверяющим содержимое сообщения. Сообщение содержит информацию для обработки другим сеансом. Оно может использоваться для эмуляции мгновенного выполнения за счет вынесения продолжительного процесса за пределы интерактивного клиента.
Итак, вместо выполнения 45-секундного процесса, компонент должен помещать запрос со всеми необходимыми входными данными в очередь и выполнять его асинхронно, а не синхронно. В этом случае пользователю не придется ждать ответа 45 секунд, то есть система становится более динамичной.
Хотя, судя по описанию, этот подход прост (подключение механизма AQ полностью решает проблему), потребовалось сделать намного больше. Этот 45-секундный процесс генерировал идентификатор транзакции, необходимый на следующем шаге в интерфейсе для соединения таблиц — по проекту интерфейс без этого не работал. Используя механизм AQ, мы не ждем генерации идентификатора транзакции, — мы обращаемся к системе с просьбой сделать это когда-нибудь. Поэтому приложение опять оказалось в тупике. С одной стороны, мы не можем ждать завершения процесса 45 секунд, но, с другой стороны, для перехода к следующему экрану необходим сгенерированный идентификатор, а получить его можно только спустя 45 секунд. Для того чтобы решить эту проблему, пришлось синтезировать собственный поддельный идентификатор транзакции, изменить продолжительный процесс так, чтобы он принимал этот сгенерированный поддельный идентификатор и обновлял таблицу, записывая его по завершении работы, благодаря чему реальный идентификатор транзакции связывался с поддельным. То есть, вместо получения реального идентификатора в результате длительного процесса, этот идентификатор становится для процесса входными данными. Во всех "подчиненных" таблицах использовался этот поддельный идентификатор транзакции, а не реальный (поскольку генерации реального надо ждать определенное время). Нам также пришлось пересмотреть использование этого идентификатора транзакции, чтобы понять, как это изменение повлияет на другие модули, и так далее.
Еще одна проблема состояла в том, что при синхронной работе, если 45-секундный процесс завершался неудачно, пользователь узнавал об этом сразу. Он мог устранить причину ошибки (обычно путем изменения входных данных) и повторно выполнить запрос. Теперь, когда транзакции выполняются асинхронно с помощью механизма AQ, сделать это невозможно. Для поддержки отсроченного уведомления об ошибке пришлось добавить новые средства. В частности, понадобилось реализовать механизм потоков заданий для отправки информации о неудавшихся транзакциях соответствующему лицу.
В результате пришлось существенно пересмотреть структуру базы данных. Пришлось добавить новое программное обеспечение (AQ). Пришлось также создать новые процессы (управление потоками заданий и другие служебные процессы). К положительным последствиям этих изменений можно отнести не только решение проблемы с архитектурой MTS, но и удобство для пользователя (создавалась видимость более быстрой реакции системы). С другой стороны, все эти изменения существенно задержали завершение проекта, поскольку проблемы были выявлены лишь непосредственно перед внедрением, на этапе тестирования масштабируемости. Очень жаль, что приложение сразу не был правильно спроектировано. Если бы разработчики знали, как физически реализован механизм MTS, было бы ясно, что исходный проект не обеспечивает требуемой масштабируемости.
