Независимый форум, посвященный системе БОСС-Кадровик
и всему, что с ней связано
|
|
| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
Mikhail
Зарегистрирован: 16.08.2012
Сообщения: 177
Откуда: Москва
|
 Добавлено: Чт Фев 19, 2015 13:32 Заголовок сообщения: Длительное выполнение операций. |
 |
|
Всем привет.
После обновления 6.04.01.02 столкнулись с тем, что процедуры расчета зарплаты и фиксирования р/п ведомостей стали занимать заметно больше времени чем ранее. На форуме был найдем комментарий относительно того, что эти операции будут "ускорены" в следующем обновлении 6.04.01.03.
Собственно, обновление установлено, но операции по-прежнему занимают больше времени чем раньше. Особенно странно такое поведение для процедуры фиксирования р/п ведомостей, ведь с начала года прошло не так много времени и при её выполнении приходится подсчитывать меньше данных, чем, например, в декабре 2014, а сейчас операция прерывается по таймауту установленному по-умолчанию.
Может быть кто-то еще уже столкнулся с этой проблемой и у вас имеется готовое решение?
Заранее спасибо.
зы: а пока поищу причину с помощью профайлера. |
|
| Вернуться к началу |
|
 |
DUCKKK
Большой шоколадный орден
Зарегистрирован: 16.09.2009
Сообщения: 1690
|
| Добавлено: Чт Фев 19, 2015 13:47 Заголовок сообщения: |
|
|
Найдете - выложите сюда скрипт, на котором "тормоза", если это возможно.
И попутно вопрос - VIEW для ролей в Зарплате нет? |
|
| Вернуться к началу |
|
|
Mikhail
Зарегистрирован: 16.08.2012
Сообщения: 177
Откуда: Москва
|
| Добавлено: Чт Фев 19, 2015 17:17 Заголовок сообщения: |
|
|
DUCKKK, приветствую Вас.
Получил уточнения от пользователей: большая задержка возникает при открытии списка р/п ведомостей (Документы - Ведомости - Расчетно-платежные ведомости).
Так как эта проблема на текущий момент является наиболее насущной, то начал с нее.
Удалось выяснить, что наибольшее время ожидания занимает выполнение курсора:
| Код: | | FETCH API_CURSOR0000000001838D2A |
Далее более подробно содержимое курсора:
1)
| Код: | | SELECT 0 as byFirm, 0 AS operat, (convert(varchar(40),'38')) AS nd, doc_date as dd, 1 as zero, 0 as docum, 0 as id, 0 as id_hr_status FROM lic_RPVED_title WITH(NOLOCK) OPTION(FAST 25) |
2)
3)
| Код: | | (@0 int,@1 int)select Emps . emps_id , Emps . Num_Tab , Emps . fName , Emps . Code_struct_name , Emps . st , vpr_wk_type . work_type , Emps . auto_card , Emps . prId , S . Struct_Name , ( case when people . out_date < '2015-02-28' then char ( 4 ) + 'icw95mbx01' when people . out_date < > '2099-01-01' and people . out_date > = '2015-02-28' then char ( 4 ) + 'icw95mbx03' else '' end ) , Emps . pId , ( case when Emps . check_ON > 0 then '>' else '' end ) from emps with ( NOLOCK ) inner join structs S with ( NOLOCK ) on Emps . Code_struct_name = S . Struct_Code inner join vpr_wk_type with ( NOLOCK ) on Emps . work_code = vpr_wk_type . work_code inner join people with ( NOLOCK ) on Emps . pId = people . pId and people . id_firm = @0 where Emps . st = @1 option ( FAST 25 ) |
4)
| Код: | | SELECT 91299 as auto_card1, 145 as code_app1, 71409 as auto_card2, 456 as code_app2, 0 as auto_card3, 0 as code_app3, 0 as auto_card4, 0 as code_app4, 0 as auto_card5, 0 as code_app5, 0 as auto_card6, 0 as code_app6, 0 as auto_card7, 0 as code_app7, 0 as auto_card8, 0 as code_app8, 0 as auto_card9, 0 as code_app9, 0 as auto_card10, 0 as code_app10, 0 as contact1, 0 as contact2, 0 as contact3, 0 as contact4, 0 as contact5, 0 as contact6, 0 as contact7, 0 as contact8, 0 as contact9, 0 as contact10 |
5)
| Код: | | (@0 int,@1 int)select lic_RPVED . pId , lic_RPVED . tMonth , lic_RPVED . cDays , lic_RPVED . Hours , typ_Pay . Name_Pay , lic_RPVED . Summa , lic_RPVED . Code_Pay , lic_RPVED . "Percent" , ' ' + lic_RPVED . acc + '.' + lic_RPVED . sub , S . struct_name , T . Work_type , C . Work_Categ_Name , HR_CUSTOMER . NAME , PC_ExpensesObj . Name as ExpensesObjName , typ_pay . user_Code_Pay , '' from lic_RPVED with ( NOLOCK ) left outer join typ_Pay on lic_RPVED . Code_Pay = typ_Pay . Code_Pay join structs S on lic_RPVED . shop = S . struct_code left outer join vpr_wk_categ C on lic_RPVED . bcateg = C . Work_Categ left outer join vpr_wk_type T on lic_RPVED . bstatus = T . Work_Code left join hrvw_expobj_look PC_ExpensesObj on lic_RPVED . theme = PC_ExpensesObj . ID_expobj left outer join HR_CUSTOMER on lic_RPVED . CUST_ID = HR_CUSTOMER . ID where lic_RPVED . ID_Lic_RPVED_Title = @0 and lic_RPVED . pid = @1 order by lic_RPVED . Code_Pay option ( FAST 25 ) |
Выполнив запросы отдельно определил что "замедление" вызывает последний запрос (5) и последовав предложенному решению (Execution Plan) создал дополнительный индекс на таблице lic_rpved
| Код: |
CREATE NONCLUSTERED INDEX IDX_lic_rpved6_user
ON [dbo].[Lic_RPVED] ([shop])
INCLUDE ([pId],[tMonth],[Hours],[Code_Pay],[Summa],[Acc],[Sub],[theme],[bCateg],[bStatus],[percent],[CUST_ID],[CDays])
GO |
Показатель Estimated Subtree Cost уменьшился с 472 до 370, но радикально это проблему не решило, т.к. после этого пользователи по-прежнему вылетают после таймаута.
View для данной роли не созданы.
Процедуру расчета зарплаты, пока, отложил до решения текущей проблемы.
Спасибо! |
|
| Вернуться к началу |
|
|
DUCKKK
Большой шоколадный орден
Зарегистрирован: 16.09.2009
Сообщения: 1690
|
| Добавлено: Чт Фев 19, 2015 17:40 Заголовок сообщения: |
|
|
Интересно получить информацию о количестве записей в таблицах
lic_RPVED и lic_RPVED_title |
|
| Вернуться к началу |
|
|
Mikhail
Зарегистрирован: 16.08.2012
Сообщения: 177
Откуда: Москва
|
| Добавлено: Чт Фев 19, 2015 17:58 Заголовок сообщения: |
|
|
Количество записей:
lic_RPVED - 8199185
lic_RPVED_title - 712 |
|
| Вернуться к началу |
|
|
DUCKKK
Большой шоколадный орден
Зарегистрирован: 16.09.2009
Сообщения: 1690
|
| Добавлено: Чт Фев 19, 2015 18:02 Заголовок сообщения: |
|
|
| Нехило .... |
|
| Вернуться к началу |
|
|
DUCKKK
Большой шоколадный орден
Зарегистрирован: 16.09.2009
Сообщения: 1690
|
| Добавлено: Чт Фев 19, 2015 18:03 Заголовок сообщения: |
|
|
| Какая-то архивация напрашивается .... |
|
| Вернуться к началу |
|
|
Mikhail
Зарегистрирован: 16.08.2012
Сообщения: 177
Откуда: Москва
|
| Добавлено: Чт Фев 19, 2015 18:14 Заголовок сообщения: |
|
|
Да, это в планах: секционирование таблицы, сжатие архивной части и перенос актуального раздела на более быстрые диски..
Но для решения сию минутной проблемы могу оперировать по сути лишь индексами. В целом удалось зафиксировать ведомости хоть и со сркипом.
Интересно, чем вызвано такое достаточно резкое "замедление" данной операции по сравнению с аналогичной в декабре 2014 (обновление накатывалось в новогодние праздники) ? |
|
| Вернуться к началу |
|
|
rebel25
Большой шоколадный орден
Зарегистрирован: 06.10.2008
Сообщения: 580
Откуда: Москва
|
| Добавлено: Чт Фев 19, 2015 18:56 Заголовок сообщения: |
|
|
Можно попробовать запустить программу в режиме отладки и посмотреть что отображается в статусной строке в момент висения, потом найти этот кусок кода и анализировать.
Вообще РП ведомости очень тяжело работают, приходится ждать после каждого клика мышью довольно долго. Для быстрого просмотра я их вынес в произвольные отчеты, но с формированием всё сложнее. |
|
| Вернуться к началу |
|
|
Mikhail
Зарегистрирован: 16.08.2012
Сообщения: 177
Откуда: Москва
|
| Добавлено: Пт Фев 20, 2015 10:56 Заголовок сообщения: |
|
|
| Как решение в нашем случае убрал из диалога р/п ведомостей нижний запрос с детализацией содержимого ведомости по работнику (ВО, суммы и т.д.). |
|
| Вернуться к началу |
|
|
Spartak
Зарегистрирован: 18.03.2010
Сообщения: 185
|
| Добавлено: Пт Фев 20, 2015 12:30 Заголовок сообщения: |
|
|
| Mikhail писал(а): | | Да, это в планах: секционирование таблицы, сжатие архивной части и перенос актуального раздела на более быстрые диски.. |
Cекционирование, как я понял, только на MSSQL Enterprise Edition.
Интерерсно, а само приложение (БОСС-Кадровик) будет работать с секционированными таблицами?
И для чего нужно сжатие архивной части? |
|
| Вернуться к началу |
|
|
RVV
Большой шоколадный орден
Зарегистрирован: 14.01.2010
Сообщения: 449
|
| Добавлено: Пт Фев 20, 2015 14:09 Заголовок сообщения: |
|
|
| А может стоит почистить таблицу, удалить или перенести в другую данные за период > 3 лет? |
|
| Вернуться к началу |
|
|
DUCKKK
Большой шоколадный орден
Зарегистрирован: 16.09.2009
Сообщения: 1690
|
| Добавлено: Пт Фев 20, 2015 15:01 Заголовок сообщения: |
|
|
Да как бы не больше года 
Чего так сильно умничать-то? Вы же понимаете, что больше 8 миллионов записей ворочаться будут медленно, как ни старайся?
Ваш креатив - это одно. Простая логика - совсем другое. |
|
| Вернуться к началу |
|
|
Mikhail
Зарегистрирован: 16.08.2012
Сообщения: 177
Откуда: Москва
|
| Добавлено: Ср Фев 25, 2015 10:21 Заголовок сообщения: |
|
|
Spartak, сжатие таблицы приводит к уменьшению занимаемой ею области на диске, а это в свою очередь уменьшает время поиска данных, если пользователю понадобится выбрать какие-то данные из этого раздела.
RVV, DUCKKK, вполне согласен, что вариант с архивацией тоже приемлем. А кто говорит, что решить задачу можно только одним способом? |
|
| Вернуться к началу |
|
|
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
|
FAQ
Поиск
Пользователи
Группы
Регистрация
Профиль
Войти и проверить личные сообщения
Вход
