Список форумов BOSSForum.RU - Форум. БОСС-Кадровик
Независимый форум, посвященный системе БОСС-Кадровик
и всему, что с ней связано
 FAQFAQ   ПоискПоиск   ПользователиПользователи   ГруппыГруппы   РегистрацияРегистрация 
 ПрофильПрофиль   Войти и проверить личные сообщенияВойти и проверить личные сообщения   ВходВход 

Длительное выполнение операций.

 
Начать новую тему   Ответить на тему    Список форумов BOSSForum.RU - Форум. БОСС-Кадровик -> Общие вопросы
Предыдущая тема :: Следующая тема  
Автор Сообщение
Mikhail



Зарегистрирован: 16.08.2012
Сообщения: 177
Откуда: Москва

СообщениеДобавлено: Чт Фев 19, 2015 13:32    Заголовок сообщения: Длительное выполнение операций. Ответить с цитатой

Всем привет.

После обновления 6.04.01.02 столкнулись с тем, что процедуры расчета зарплаты и фиксирования р/п ведомостей стали занимать заметно больше времени чем ранее. На форуме был найдем комментарий относительно того, что эти операции будут "ускорены" в следующем обновлении 6.04.01.03.

Собственно, обновление установлено, но операции по-прежнему занимают больше времени чем раньше. Особенно странно такое поведение для процедуры фиксирования р/п ведомостей, ведь с начала года прошло не так много времени и при её выполнении приходится подсчитывать меньше данных, чем, например, в декабре 2014, а сейчас операция прерывается по таймауту установленному по-умолчанию.

Может быть кто-то еще уже столкнулся с этой проблемой и у вас имеется готовое решение?

Заранее спасибо.

зы: а пока поищу причину с помощью профайлера.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
DUCKKK
Большой шоколадный орден
Большой шоколадный орден


Зарегистрирован: 16.09.2009
Сообщения: 1681

СообщениеДобавлено: Чт Фев 19, 2015 13:47    Заголовок сообщения: Ответить с цитатой

Найдете - выложите сюда скрипт, на котором "тормоза", если это возможно.

И попутно вопрос - VIEW для ролей в Зарплате нет?
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail
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)
Код:
Select 0


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
Сообщения: 1681

СообщениеДобавлено: Чт Фев 19, 2015 17:40    Заголовок сообщения: Ответить с цитатой

Интересно получить информацию о количестве записей в таблицах
lic_RPVED и lic_RPVED_title
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail
Mikhail



Зарегистрирован: 16.08.2012
Сообщения: 177
Откуда: Москва

СообщениеДобавлено: Чт Фев 19, 2015 17:58    Заголовок сообщения: Ответить с цитатой

Количество записей:
lic_RPVED - 8199185
lic_RPVED_title - 712
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
DUCKKK
Большой шоколадный орден
Большой шоколадный орден


Зарегистрирован: 16.09.2009
Сообщения: 1681

СообщениеДобавлено: Чт Фев 19, 2015 18:02    Заголовок сообщения: Ответить с цитатой

Нехило ....
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail
DUCKKK
Большой шоколадный орден
Большой шоколадный орден


Зарегистрирован: 16.09.2009
Сообщения: 1681

СообщениеДобавлено: Чт Фев 19, 2015 18:03    Заголовок сообщения: Ответить с цитатой

Какая-то архивация напрашивается ....
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail
Mikhail



Зарегистрирован: 16.08.2012
Сообщения: 177
Откуда: Москва

СообщениеДобавлено: Чт Фев 19, 2015 18:14    Заголовок сообщения: Ответить с цитатой

Да, это в планах: секционирование таблицы, сжатие архивной части и перенос актуального раздела на более быстрые диски..

Но для решения сию минутной проблемы могу оперировать по сути лишь индексами. В целом удалось зафиксировать ведомости хоть и со сркипом.

Интересно, чем вызвано такое достаточно резкое "замедление" данной операции по сравнению с аналогичной в декабре 2014 (обновление накатывалось в новогодние праздники) ?
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
rebel25
Большой шоколадный орден
Большой шоколадный орден


Зарегистрирован: 06.10.2008
Сообщения: 578
Откуда: Москва

СообщениеДобавлено: Чт Фев 19, 2015 18:56    Заголовок сообщения: Ответить с цитатой

Можно попробовать запустить программу в режиме отладки и посмотреть что отображается в статусной строке в момент висения, потом найти этот кусок кода и анализировать.
Вообще РП ведомости очень тяжело работают, приходится ждать после каждого клика мышью довольно долго. Для быстрого просмотра я их вынес в произвольные отчеты, но с формированием всё сложнее.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail
Mikhail



Зарегистрирован: 16.08.2012
Сообщения: 177
Откуда: Москва

СообщениеДобавлено: Пт Фев 20, 2015 10:56    Заголовок сообщения: Ответить с цитатой

Как решение в нашем случае убрал из диалога р/п ведомостей нижний запрос с детализацией содержимого ведомости по работнику (ВО, суммы и т.д.).
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Spartak



Зарегистрирован: 18.03.2010
Сообщения: 180

СообщениеДобавлено: Пт Фев 20, 2015 12:30    Заголовок сообщения: Ответить с цитатой

Mikhail писал(а):
Да, это в планах: секционирование таблицы, сжатие архивной части и перенос актуального раздела на более быстрые диски..

Cекционирование, как я понял, только на MSSQL Enterprise Edition.
Интерерсно, а само приложение (БОСС-Кадровик) будет работать с секционированными таблицами?
И для чего нужно сжатие архивной части?
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
RVV
Большой шоколадный орден
Большой шоколадный орден


Зарегистрирован: 14.01.2010
Сообщения: 449

СообщениеДобавлено: Пт Фев 20, 2015 14:09    Заголовок сообщения: Ответить с цитатой

А может стоит почистить таблицу, удалить или перенести в другую данные за период > 3 лет?
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
DUCKKK
Большой шоколадный орден
Большой шоколадный орден


Зарегистрирован: 16.09.2009
Сообщения: 1681

СообщениеДобавлено: Пт Фев 20, 2015 15:01    Заголовок сообщения: Ответить с цитатой

Да как бы не больше года Smile

Чего так сильно умничать-то? Вы же понимаете, что больше 8 миллионов записей ворочаться будут медленно, как ни старайся?

Ваш креатив - это одно. Простая логика - совсем другое.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Отправить e-mail
Mikhail



Зарегистрирован: 16.08.2012
Сообщения: 177
Откуда: Москва

СообщениеДобавлено: Ср Фев 25, 2015 10:21    Заголовок сообщения: Ответить с цитатой

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

RVV, DUCKKK, вполне согласен, что вариант с архивацией тоже приемлем. А кто говорит, что решить задачу можно только одним способом? Smile
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Показать сообщения:   
Начать новую тему   Ответить на тему    Список форумов BOSSForum.RU - Форум. БОСС-Кадровик -> Общие вопросы Часовой пояс: GMT + 4
Страница 1 из 1

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах


Pоwerеd by рhpВB © 2001, 2005 рhpВB Grouр
Русская поддержка phрВB
Rambler's Top100 Рейтинг@Mail.ru Список форумов BOSSForum.RU