суббота, 31 мая 2014 г.

Коммуникации между сеансами в СУБД Oracle

В любой среде, где выполняются параллельные процессы, актуальны вопросы совместного использования общих ресурсов и обмена сообщениями между процессами. Одновременно открытые сеансы СУБД Oracle - именно такие параллельные процессы. Я уже рассматривал конкурентный доступ к общим ресурсам с помощью пакета DBMS_LOCK, а теперь поэкспериментирую со средствами обмена сигналами и данными между сеансами СУБД Oracle 11gR2 - пакетами DBMS_ALERT и DBMS_PIPE.

воскресенье, 25 мая 2014 г.

Конкурентный доступ к ресурсам и DBMS_LOCK

Сеансы работы с СУБД Oracle есть параллельно выполняющиеся процессы, работающие как с собственными, так и с общими ресурсами. Объекты БД, такие как таблицы, индексы, являются общими ресурсами. CУБД Oracle делает все возможное для того, чтобы конкурентный доступ к табличным данным был эффективным и максимально незаметным - прозрачным - для сеансов. Однако, в ряде случаев от программиста требуется явная блокировка ресурса на время работы с ним, и освобождение ресурса по окончании работы.

Таким ресурсом может быть, например, экземпляр некоторой сущности предметной области (сотрудник, элемент орг. структуры, и т.д.) Строки одной таблицы сеанс может зарезервировать для исключительного использования при помощи SELECT ... FOR UPDATE. Но в случае, когда необходимо заблокировать данные, распределенные по нескольким таблицам, лучшим решением будет специальное соглашение между конкурирующими процессами о доступе к ресурсу. А реализовать такое соглашение поможет пакет DBMS_LOCK.

воскресенье, 18 мая 2014 г.

Прогресс длительных операций в СУБД Oracle

Если вам приходилось иметь дело с "долгоиграющими" PL/SQL процедурами, которые выполняются от десятков минут до многих часов, то перед вами вставал вопрос, сколько работы уже сделано на данный момент и сколько еще осталось. Как заглянуть внутрь выполняющейся PL/SQL процедуры?

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

В этом случае нужно предусмотреть механизм, который обеспечит видимость прогресса работы процедуры из другого сеанса работы с БД. Это может быть специальная таблица, в которую PL/SQL процедура будет вставлять записи о завершении отдельных этапов работы и о прогрессе каждого этапа. Как вариант, записи могут добавляться и обновляться в рамках автономных транзакций. Тогда, делая запрос к этой таблице в отдельном сеансе, можно видеть текущий прогресс выполнения PL/SQL процедуры.

В большинстве случаев нет необходимости изобретать велосипед и реализовавать собственное решение для отслеживания прогресса "долгоиграющих" операций. СУБД Oracle предоставляет несколько средств, которыми можно вопользоваться для этой цели (а также для целей отладки, профилирования, и других, которые подскажет ваша фантазия) - это пакеты DBMS_APPLICATION_INFO, DBMS_ALERT и DBMS_PIPE. Все эти средства позволяют тем или иным образом организовать передачу данных из одного сеанса работы с СУБД Oracle в другой.