Опишу буквально вот вчерашние эксперименты.
Для чистоты, выбрал все пользовательские (не системные) процедуры в БД:
1.
2.
3.
4.
UNLOAD TO user_proc.unl
SELECT procname FROM sysprocedures
WHERE MODE NOT IN ('P','p','o','r','d') {no system procedures}
ORDER BY 1;
Подчистил файл
user_proc.unl убрав разделитель полей. В этом файле в каждой строке - имя процедуры. Все.
Сформировал запрос и удалил все процедуры из БД:
1.
cat user_proc.unl | awk '{print "echo \"DROP PROCEDURE "$1"\" | dbaccess invest98"}' | sh
Зачем я это сделал? От безысходности. Я предполагал, что у меня процедуры были загружены в БД с установленной PDQPRIORITY=100. Естественно, что у меня все процедуры и grant exec есть.
Дальше, остановил сервер СУБД. Выставил PDQPRIORITY=0 и запустил СУБД.
Загрузил процедуры.
Остановил СУБД. Разименовал переменную, просто сделав unset PDQPRIORITY. Запустил СУБД.
Для чистоты эксперимента, сделал полный UPDATE STATISTICS для таблиц БД. По скрипту от Shulzhenko.
Сформировал строку для исполнения UPDATE STATISTICS для процедур, чтоб в единицу времени исполнялась одна процедура (
немного поправлю её для того чтобы влезла, т.е. сделаю её многострочной ):
1.
2.
3.
4.
time cat user_proc.unl | \
awk '{print "echo \"Procedure: "$1"\"; echo \"SET PDQPRIORITY 0; \
UPDATE STATISTICS FOR PROCEDURE "$1";\" | dbaccess invest98"}' | \
tee upgr_proc.log | sh > >(tee stdout.log) 2> >(tee stderr.log >&2)
Сделал 4 эксперимента. Все 4-е стабильных подвисания, снять которые по
onmode -ky удалось один раз, остальные - только через
pkill -9 oninit .
До этого эксперимента, висло на разных процедурах, однако вот вчера устойчиво наблюдал три раза повисание на одной процедуре, посмотрю её сегодня отдельно, но кажется, что это не причина.
Да и прошлые разы у меня два раза из 6 таки прошел UPDATE STATISTICS... С чем было связано, я не нашел.
