Доброго дня!
Пытаюсь запускать процедуру из задания, используя DBMS_JOB.
Если процедура не выполняет никаких действий с таблицами (ничего не меняет и не вставляет), то задание срабатывает многократно с указанным интервалом.
Если же процедура вставляет запись в табличку, то задание срабатывает только первый раз!
Никакие действия по изменению времени запуска, интервала срабатывания , пересоздания задания - не помогают!
Грохаю базу и создаю все с нуля - повторяется та же ситуация.


Создал простейшую процедуру, которая вставляет запись в табличку (вместо сложной, которая должна выгружать xml).


db2set DB2_ATS_ENABLE=1
db2stop force
db2start




"NAME""TASKID""OWNER""OWNERTYPE""BEGIN_TIME""END_TIME""MAX_INVOCATIONS""SCHEDULE""PROCEDURE_SCHEMA""PROCEDURE_NAME""PROCEDURE_INPUT""OPTIONS""UPDATE_TIME""REMARKS""DBMS_JOB_TASK_1"2"DB2ADMIN""U""2009-12-01 15:54:44"1"DBMS_JOB""EXECUTE_TASK""VALUES('DBMS_JOB_TASK_1'.'SYSDATE + 5 minutes'.'CALL REPL.sp_unloadXML()')""2009-12-01 15:49:44""16"

"NAME""TASKID""STATUS""AGENT_ID""INVOCATION""BEGIN_TIME""END_TIME""SQLCODE""SQLSTATE""SQLERRMC""RC""DBMS_JOB_TASK_1"2"COMPLETE"521"2009-12-01 15:39:44""2009-12-01 15:39:50"0" "0"DBMS_JOB_TASK_1"2"COMPLETE"741"2009-12-01 15:44:44""2009-12-01 15:44:48"0" "0"DBMS_JOB_TASK_1"2"COMPLETE"1091"2009-12-01 15:49:44""2009-12-01 15:49:44"0" "0

"TS""2009-12-01 15:49:44"


PS Первые 2 запуска соответствуют пустой процедуре


После второго запуска поменял код процедуры


Она выполнилась, о чем свидетельствует 3-я запись статуса и запись в выходной табличке, и после этого - тишина.

Mark Barinstein,

Написал пост и только потом увидел Ваше сообщение о появлении фикса. Качаю.
Надеюсь, положение исправится. Отпишу.

Спасибо.
Алексей.

Mark Barinstein
У меня на 9.7.1 работает.


Поставил. Работает, как часы (уже настоящий вариант с выгрузкой xml). Я уж не знал, что и делать, хорошо фикс подогнали вовремя. Все равно очень удивился, хотя надежда была.

ЗЫ Кстати, и другие проблемы, которые были - тоже поправлены (например с jdbc-драйвером - получением автосгенеренного значения).

Обязательно нужно ставить фикс.

Спасибо, Марк, не первый раз выручаете!

Проблема все-таки имеет продолжение.
Через некоторое время после запуска планировщика, непонятно при каких условиях и по какой причине, зависает процесс db2fmp.exe. Памяти не жрет сильно, но процессор занимает на 100%.
После этого следующие запуски задания по планировщику не срабатывают.
Приходится грохать процесс через Task Manager, и возобновлять работу заданий через запрос
CALL DBMS_JOB.CHANGE(1,NULL,NULL,'SYSDATE + 5 minutes') ;
Несколько дней все работает нормально, потом опять.

А вообще, в задачах висит 9 штук db2fmp.exe, съедающих по 20-40 мегов памяти каждый. Наверное, это тоже не совсем нормально.
Запускается в задании java-процедура, которая в свою очередь выполняет PL/SQL-ные процедуры.

Не знаю, как выявить проблему, видимо она является результатом каких-то определенных обрабатываемых данных. Проверял код процедуры, которая вызывается по заданию, вроде не должна она циклиться ни при каких условиях.

Mark BarinsteinДа, я у себя на 9.7.1 на винде такое тоже вижу, приходится убивать...
Советую завести PMR по этому поводу.

Марк, а Вы на какой версии наблюдаете, DB2ESE или DB2WSE?
Я просто точно не знаю, на Workgroup Edition есть планировщик?
А то я у себя на Enterprise экспериментирую, а у заказчика официальный контракт вроде как на Workgroup.
А DB2ESE для экспериментов у меня по партнерской программе, не знаю пока что в форме для PMR писать, нужно выяснять.

Mark Barinstein,

спасибо, дождусь зацикливания и посмотрю. В db2diag ничего подозрительного не находил пока.

Проблема в другом.
Для открытия PMR IBM предлагает заполнить IBM EEA problem report, и отправить его на swsupport@ru.ibm.com
Там обязательны к заполнению поля, идентифицирующие заказчика, который купил продукт (Customer number, Site number, etc). Но дело в том, что наш заказчик пока не купил DB2. А там надо указать информацию по контракту заказчика.
Мы же пользуемся DB2, скачанной по Value Package, являясь бизнес-партнерами IBM.
А те перенаправляют в саппорт. А саппорт к Partner World. Замкнутый круг.
Получается, если купили продукт и в нем обнаружились проблемы - будут разбираться.
А если пытаемся показать заказчику систему на этом продукте, чтобы те купили, и находим при этом проблемы - то это наши проблемы.
Не знаю, что и делать.

Anton DemidovCommit забыли. Блокировка небось висит.


Блокировки нет, проверено.


Mark Barinstein
Это db2acd ( DB2 Process Model ).
команда:
db2pd -edu | find "db2acd"
даст его PID.


Это действительно db2acd
Сегодня утром обнаружил его зациклившимся.

C:\Documents and Settings\db2admin>db2pd -edus | find "db2acd"
db2acd PID: 1484

Но что интересно, сегодня db2diag.log разросся до огромных размеров из-за того, что как раз с момента запуска последней задачи по плану, этот процесс (pid 1484) стал писать безостановочно (а не раз в 5 минут) следующие сообщения:

2010-02-18-18.53.21.796000+180 E154630H483 LEVEL: Event
PID : 5848 TID : 3224 PROC : db2syscs.exe
INSTANCE: DB2 NODE : 000 DB : NEXUSTST
APPHDL : 0-69 APPID: 192.168.10.8.2010.100218104406
AUTHID : DB2ADMIN
EDUID : 3224 EDUNAME: db2agent (idle) 0
FUNCTION: DB2 UDB, base sys utilities, sqeLocalDatabase::TermDbConnect, probe:2000
STOP : DATABASE: NEXUSTST : DEACTIVATED: NO

2010-02-18-18.55.36.000000+180 E155115H459 LEVEL: Error
PID : 1484 TID : 4532 PROC : db2fmp.exe
INSTANCE: DB2 NODE : 000
EDUID : 4532
FUNCTION: DB2 UDB, Administrative Task Scheduler, AtsTask::run, probe:200
MESSAGE : ADM15502W The administrative task scheduler could not execute task
"DBMS_JOB_TASK_4" because the database is inactive.
DATA #1 : ZRC, PD_TYPE_ZRC, 4 bytes
0x82BA00FD

2010-02-18-18.55.36.015000+180 E155576H423 LEVEL: Error
PID : 1484 TID : 4532 PROC : db2fmp.exe
INSTANCE: DB2 NODE : 000
EDUID : 4532
FUNCTION: DB2 UDB, Administrative Task Scheduler, AtsTask::run, probe:201
MESSAGE : ZRC=0xFFFFFBDC=-1060
DATA #1 : <preformatted>
[IBM][CLI Driver] SQL1060N Пользователь "DB2ATS" не имеет привилегии CONNECT. SQLSTATE=08004


2010-02-18-18.55.36.046000+180 E156001H459 LEVEL: Error
PID : 1484 TID : 4540 PROC : db2fmp.exe
INSTANCE: DB2 NODE : 000
EDUID : 4540
FUNCTION: DB2 UDB, Administrative Task Scheduler, AtsTask::run, probe:200
MESSAGE : ADM15502W The administrative task scheduler could not execute task
"DBMS_JOB_TASK_4" because the database is inactive.
DATA #1 : ZRC, PD_TYPE_ZRC, 4 bytes
0x82BA00FD

2010-02-18-18.55.36.046000+180 E156462H423 LEVEL: Error
PID : 1484 TID : 4540 PROC : db2fmp.exe
INSTANCE: DB2 NODE : 000
EDUID : 4540
FUNCTION: DB2 UDB, Administrative Task Scheduler, AtsTask::run, probe:201
MESSAGE : ZRC=0xFFFFFBDC=-1060
DATA #1 : <preformatted>
[IBM][CLI Driver] SQL1060N Пользователь "DB2ATS" не имеет привилегии CONNECT. SQLSTATE=08004



.....


И где-то в 21.30 перестал писать в лог (успев к тому времени записать 150 М), и теперь я его вижу как жрущий процессор и ничего не делающий.
Что самое интересное, в прошлые разы никакой подобной информации в db2diag.log я не находил.

Что такое "база не активна" и почему вдруг кончились права, не понятно.

Вот, прочитал в документации:

Для своевременного выполнения задач необходимо , чтобы ваша база данных была активна . Лучше всего активировать базу данных командой ACTIVATE DATABASE. Другой вариант - можно удерживать базу данных постоянно активной, сохраняя хотя бы одно соединение с ней.


В результате проверки выяснилось: процесс зависает, если к очередному моменту запуска задачи нет ни одного соединения с базой. Причем ему ничего уже не поможет, только прибивать процесс или рестартовать db2. Плюс потом сабмитить задание по новой.

Опять же интересно, что в db2diag.log ничего не пишется (сегодня было единственное исключение :).

Mark BarinsteinОно не активирует неактивную (нет ни одного пользователя в ней) базу, так задумано.
Пока попробуйте активировать базу явно командой
db2 activate db NEXUSTST
Замечания:
- эту команду надо делать после каждого запуска инстанса
- в момент запуска команды сессия не должна иметь соединений с любой базой

Я заметил, что оно у меня именно после деактивации (выхода последнего пользователя) базы начинается.

Да-да, все это я уже тоже понял.
Однако это не совсем удобно получается - инстанс запускается службой (в виндах), нужно подумать, куда прилепить activate.

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

Вариант с помещением команды в автозапуск виндов после запуска служб (SOFTWARE\Microsoft\Windows\CurrentVersion\ Run) - некрасив.

Как сделать, чтобы именно после запуска экземпляра DB2 в виндах всегда выполнялась определенная команда (в данном случае принудительной активации одной из баз). Ну то есть вроде триггера на запуск инстанса?

Пока вышел из положения следующим образом.
Есть служба, которая держит коннект к db2 - это apache tomcat. У него в context.xml прописан ресурс, используемый нашим web-приложением, для которого определена строка соединения с базой, и Томкат автоматически устанавливает это соединение после своего запуска.
Я прописал в реестре через DependOnService, что служба Томкат зависит от службы инстанса DB2 (DB2-0).
Для DB2 указал тип запуска manual, а для Tomcat - авто. Это приводит к тому, что Tomcat перед своим запуском автоматически поднимает DB2, и устанавливает соединение. То есть при загрузке сервера этот порядок обеспечен.

Правда, если остановить вручную Томкат, оставив DB2 и ее базу без соединений - получаем зависание планировщика, когда тот соберется очередной раз запустить задание. Но в рабочей системе Томкат будет всегда запущен для работы интерфейсов.