Формирование ведомостей в банк - зависание

[rebel25]

C недавнего времени, при формировании ведомостей в банк, босс навсегда зависает - висят песочные часы и в строке выполнения светится INSERT INTO GL_DOCS....
Закрываю принудительно босс, открываю и формирую ту же ведомость, она формируется быстро. Это повторяется время от времени.
Проверил вроде не тиражных объектов нет, в GL_DOCS примерно 5000 строк.
Не подскажите как выявить и устранить причину зависания формирования ведомостей в банк?

[RVV]

Нужно создать индексы.

CREATE NONCLUSTERED INDEX [IDX_Gl_Docs__id_acc_group] ON [dbo].[Gl_Docs]
(
[id_acc_group] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO
CREATE NONCLUSTERED INDEX [IDX_Gl_Docs_1] ON [dbo].[Gl_Docs]
(
[id_hr_status] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO
CREATE NONCLUSTERED INDEX [IDX_Gl_Docs_2] ON [dbo].[Gl_Docs]
(
[idDocType] ASC,
[idFirm] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO
CREATE NONCLUSTERED INDEX [IDX_Gl_Docs_3] ON [dbo].[Gl_Docs]
(
[role_code] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO

[Mikhail]

Аналогичная проблема.

Зависает выполнение инструкции:

[DUCKKK]

Индексы помогли?

[Mikhail]

Дополнение: вышеуказанные индексы созданы, трассировку получил после их создания.

[DUCKKK]

А протоколирование на эти таблицы не настроено?

[Mikhail]

DUCKKK, проверил - в протоколировании данная таблица не участвует.

[DUCKKK]

Под sysadmin тоже виснет? А для роли, под которой заходим, VIEW есть?

[Mikhail]

Пробовал формировать ведомости пару раз под sa - проблем не возникало, но не берусь утверждать, что отсутствие зависаний является следствием именно этой причины.

Для пользовательской роли view не созданы. Да, есть интересный момент, что зависание под пользовательской ролью происходит не каждый раз. Соотношение между успешными попытками сформировать ведомость и неудачными примерно 1:2.

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

[DUCKKK]

Ну вот что здесь сказать ... Возможно, и сервер как-то глючит, строит такие планы запросов ....

[Volod]

А какая у Вас версия sql ?

[Spartak]

мне помогло убрать вставку в поле id_acc_group из инструкции
INSERT INTO GL_DOCS (...).
А чтобы записывать чего-то в id_acc_group добавил отдельной строкой
update gl_docs set id_acc_group=@sel:id_acc_group where id=identity_;

[Mikhail]

Версия SQL:
Microsoft SQL Server 2012 - 11.0.5058.0 (X64)
May 14 2014 18:34:29
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: )

Spartak, ваше решение вполне логично, поскольку упомянутый выше триггер tI_Gl_Docs_id_acc_group_adtb_acc_group настроен на срабатывание при условии if update(id_acc_group).

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

[rebel25]

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

[DUCKKK]

Можем только предположить, что произошли какие-то изменения в системных библиотеках операционной системы, которые "приехали" с каким-то из последних обновлений от Microsoft.

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

SELECT @@identity INTO identity_;

Если ее переписать вот так:

Let identity_ = @@identity as integer
или
SELECT convert(integer, @@identity) INTO identity_;

зависания исчезают.

Поскольку понятно, что переменная @@identity в нашем случае и так имеет тип INTEGER, то преобразование ее к целому типу – это получается «масло масляное». Но это, судя по всему, работает ...

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