В продолжение топика про "зависание" баз.

ASE 12.5, под ним крутится некая "учетная система".
После ее полного внедрения в несколько раз выросло число пользователей, выполняющих обычные операции, в основном по выборкам данных.
И периодически стало наблюдаться скачкообразное зависание базы, с увеличением загрузки процессоров до 99% (сервер двухпроцессорный).
Сейчас предлагается практически один вариант - проапгрейдить сервак до 4-х процессоров.
Я не админ, просьба не пинать - мне нужно просто понять, каким образом можно выявить причину ситуации.

То есть, для начала, какую информацию и как нужно собрать при "зависании"?

Процессов в статусе lock sleep нет.

Запускал sp_sysmon '00:01:00' - результат во вложении.

Запускал процедуру sp__wholocks - что это может значить?
Кстати, можно ли как-то в результаты вытащить имя компьютера?

44(58) billing running [0/0/29] WORKER PROCESS #101 @529
45(58) billing runnable [0/0/29] WORKER PROCESS #101 @529
46(58) billing runnable [0/0/29] WORKER PROCESS #101 @529
47(58) billing runnable [0/0/29] WORKER PROCESS #101 @529
48(58) billing runnable [0/0/29] WORKER PROCESS #101 @529
49(58) billing runnable [0/0/29] WORKER PROCESS #101 @529
50(58) billing runnable [0/0/29] WORKER PROCESS #101 @529
51(58) billing runnable [0/0/29] WORKER PROCESS #101 @529
58(58) billing sync sleep [201/1/32] GETRTSBILLDETAIL SELECT #101 @529 1*Fam dur/Sh_intent(billing.OPERREQUEST)
58(58) billing sync sleep [201/1/32] GETRTSBILLDETAIL SELECT #101 @529 1*Fam dur/Sh_intent(billing.PLANPAY)
58(58) billing sync sleep [201/1/32] GETRTSBILLDETAIL SELECT #101 @529 1*Fam dur/Sh_intent(billing.BILL)
58(58) billing sync sleep [201/1/32] GETRTSBILLDETAIL SELECT #101 @529 1*Fam dur/Sh_intent(billing.NUMLOG)
58(58) billing sync sleep [201/1/32] GETRTSBILLDETAIL SELECT #101 @529 1*Fam dur/Sh_intent(billing.REQREGISTRY)
58(58) billing sync sleep [201/1/32] GETRTSBILLDETAIL SELECT #101 @529 1*Fam dur/Sh_intent(billing.NUMVOLUME)
58(58) billing sync sleep [201/1/32] GETRTSBILLDETAIL SELECT #101 @529 2*Fam dur/Sh_intent(billing.REQUEST)

С помощью sp__wholocks (респект автору) удалось установить процедуру, при запуске которой происходит "зависание" базы.
Будем искать дальше.

MasterZiv
если врубается парралельное выполнение запроса, то как правило это очень плохой запрос. Потому что парралельно выполняются такие операции как сканирование таблицы или индекса.

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



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

MasterZivРекомендую :
0) выключить парралелизм. (max parralel degrie , max scan parralel degrie)
1) Обратить внимание на план именно этого конкретного запроса. Если будут еще такие же - и на них.

При ОЭ насколько я помню пробовали выключать параллелизм, к лучшему быстродействию это не приводило. Хотя тогда тестировались всякие критичные функции, и проверить работу при множестве пользователей не было возможности.
На план запроса - отправил инфо разработчикам, но особой надежды нет.

То есть в принципе, если я правильно понял, увеличение числа процессоров может и помочь?