Конфигурация БП 3.0.76.67, платформа 8.3.15.1830. Проблема со справочником ВетеринарноСопроводительныйДокументВЕТИС. С какого-то момента при выполнении простейших запросов к этому справочнику сеанс пользователя стал намертво зависать. Пример запроса:

ВЫБРАТЬ РАЗРЕШЕННЫЕ
    КОЛИЧЕСТВО(РАЗЛИЧНЫЕ ВСД.Ссылка) КАК КоличествоДокументов
ИЗ
    Справочник.ВетеринарноСопроводительныйДокументВЕТИС КАК ВСД
ГДЕ
    ВСД.Статус = ЗНАЧЕНИЕ(Перечисление.СтатусыВетеринарныхДокументовВЕТИС.Оформлен)

Причем, если убрать условие ГДЕ, то запрос выполняется нормально, быстро.
Перезагружали сервер 1С, делали полную переиндексацию базы средствами SQL Server - не помогло.
Подскажите, пожалуйста, что где сломалось, и как это вылечить.

Индекс у поля есть?

(1) Стоит "Не индексировать"

Что говорит план запроса?

(3) Прошу прощения, я не в теме. Если речь о SQL Server Profiler, то я не могу его запустить, он почему-то зависает при соединении к серверу.

(2) Ну добавь индекс в 1С.

(5) Там дело не только в поле Статус. Когда делаешь условие по другим полям, тоже все виснет. Да и работало все неделю назад.

А если поменять КОЛИЧЕСТВО(РАЗЛИЧНЫЕ ВСД.Ссылка) на КОЛИЧЕСТВО(1)?

(7) Тоже виснет

Более того, если выполнять запрос к этой таблице непосредственно на SQL Server, то тоже виснет при наличии условия where

SELECT TOP 1000 [_IDRRef]
      ,[_Version]
      ,[_Marked]
      ,[_PredefinedID]
      ,[_Fld33707]
      ,[_Fld33708]
      ,[_Fld35152]
      ,[_Fld33709]
      ,[_Fld33710]
      ,[_Fld33711]
      ,[_Fld33712RRef]
      ,[_Fld33713RRef]
      ,[_Fld33714RRef]
      ,[_Fld33715]
      ,[_Fld33716RRef]
      ,[_Fld33717RRef]
      ,[_Fld33718RRef]
      ,[_Fld33719RRef]
      ,[_Fld33720RRef]
      ,[_Fld33721RRef]
      ,[_Fld38071]
      ,[_Fld33722]
      ,[_Fld33723RRef]
      ,[_Fld33724]
      ,[_Fld33725]
      ,[_Fld33726RRef]
      ,[_Fld33727]
      ,[_Fld33728RRef]
      ,[_Fld33729]
      ,[_Fld33730RRef]
      ,[_Fld33731]
      ,[_Fld33732RRef]
      ,[_Fld33733]
      ,[_Fld33734]
      ,[_Fld33735]
      ,[_Fld33736RRef]
      ,[_Fld33737]
      ,[_Fld33738]
      ,[_Fld33739]
      ,[_Fld33740RRef]
      ,[_Fld33741]
      ,[_Fld33742]
      ,[_Fld33743]
      ,[_Fld33744]
      ,[_Fld33745]
      ,[_Fld33746RRef]
      ,[_Fld33747RRef]
      ,[_Fld36253RRef]
      ,[_Fld39048RRef]
      ,[_Fld39826]
      ,[_Fld39827]
      ,[_Fld14023]
  FROM [bux20shpf].[dbo].[_Reference33631]
   where [_Fld33745]='1959'

Убираешь where - выполняется нормально.

(9) У тебя чето померло

Что скажет
DBCC CHECKTABLE('_Reference33631')
?

(10) Догадываюсь((

(11) Результаты DBCC для "_Reference33631".
Имеется 304737 строк на 43027 страницах для объекта "_Reference33631".

Ошибок не обнаружено.

(6)А размер таблиц на sql сервере смотрел? У вас там количество документов за разумное количество не ушло? Какая нибудь таблица не разрослась?
В MS SQL есть готовый запрос для этого, выводит первые сколько то таблиц с сортировкой по размеру от большей к меньшей. Мышкой из контекстного меню по базе запускается.

выгрузи-загрузи обратно БД

с таким планом... заменить запрос на:
ВЫБРАТЬ КОЛИЧЕСТВО(1) КАК КоличествоДокументов
ИЗ
    Справочник.ВетеринарноСопроводительныйДокументВЕТИС КАК ВСД
ГДЕ
    ВСД.Статус = ЗНАЧЕНИЕ(Перечисление.СтатусыВетеринарныхДокументовВЕТИС.Оформлен)

Если есть место, попробуй стандартное выгрузить в dt загрузить в чистую базу. Какой размер базы?

(17) ну или так, но предварительно сделав бэкап ибо 1-2% dt не загружаются обратно!

(17) База весит 35 Гб (файл mdf). Дт уже прокатывает.

+ хотя тут конечно индекс решает

НЕ прокатывает

(19) и чё? База-то небольшая по сути... даже на средненькую не тянет!

(22) Когда-то и при меньших размерах ругалось на превышение размеров внутренних файлов. Попробую, конечно.

По идее что-то с какими-то индексами случилось. Но полная реиндексация базы не помогла. Еще делал ALTER INDEX REBUILD по индексам этой таблицы - тоже не помогло.

(24) см (15)

(24) sql перезагружали?

(26) Перезагружали. Он на той же машине, где и сервер 1С

Если убрать Разрешенные тоже виснет?

(28) Да. Тоже виснет.

Убрать РАЗРЕШЕННЫЕ пробовал?

(23) чего чего? какой размер внутренних файлов на скуле? какая была ошибка?

(31) Он путает создание ДТ с его загрузкой в файловую инфобазу

(32) тогда (0) делай через дт в копию на скуле

(31) (32) Да, немного переклинило к вечеру). Тут нет файловой базы. К счастью или нет...

напомните еще завтра разрядность спросить

(35) везде 64

(36) в виндовом мониторе "ошибок отсутствия страниц в памяти как себя ведет?

Напиши на [email protected], могу подключиться, глянуть

(36) В консоли скуля проверь io read / write stall
https://www.brentozar.com/blitz/slow-storage-reads-writes/

(21) ну я же не в файловую базу тебе ее предлагаю грузить. В новую, чистую sql. Или у тебя выгрузка в dt не работает? Если да, то это не из за размера базы. У dt нет ограничений на размер базы. Если не выгружается, это косяк с базой.

Скуль сервер не может зависнуть намертво. Его sqlos имеет высший приоритет на исполнение прерываний каждые 4ms. Он может потратить все ресурсы на плохой запрос и часами не отвечать на задания от приложений, но сервисные dmv должны работать и отвечать.
Поставь на сервер процедуру whoisactive и посмотри чем он занимается в висячем состоянии.
Раз не запускается профайлер - должна быть ошибка в логах сервера. Возможно и ошибка исполнения твоего запроса тоже там.
Для скуля выше чем 2008 есть альтернатива профайлеру - extended events , можно им собрать предварительный план запроса.

А статистика на скуле актуальна?

(39) Выполнил данный скрипт, получил некие результаты. Подскажите, пожалуйста, как их правильно интерпретировать, и что делать дальше.

(43) Покажи столбики

(44)
Total IO Read Stall    Total IO Write Stall            
5691                   16458
1814030                176769


Первая строка - Лог
вторая - ROWS

Пытаюсь загрузить дт в чистую базу, как советовали. Грузится уже 2 часа. Размер базы - 35 Гб, размер дт - 4 Гб.

Кстати, а тип у ВСД.Статус - какой в конфигурации?

(47) ПеречислениеСсылка.СтатусыВетеринарныхДокументовВЕТИС. Только, как я уже писал, дело не в Статусе. При условии по другим полям тоже все колом встает.

(48) А что по статистике MS SQL (42) ?

(49) В последний раз план обслуживания ее сделал 31 марта. Сейчас руками не хочется запускать, чтобы дополнительных тормозов не получить. Пользователи и так нервничают...

Почему план обслуживания перестал работать, это тоже вопрос. "Совпадение - не думаю"

(45) так не видно где там нули и что в (37) это же проще

(50) динамическим обновлением часто балуешься ?

(53) Нет. Под страхом смерти

Друзья, спасибо всем за участие и отклики. У меня на Мисте такое в первый раз. В данный момент проблема ушла САМА, пока все работает. Никто ничего не делал, ни руками, ни регламентами. Подозреваю, что проблема может вернуться. Тогда и продолжим тему:-)
Ну и если есть гипотезы, что это было, пишите:)

(55) бед блок наконец что уехал, ага

(56) Вот... Или пользователь выключил комп с глючной сетевой картой и ушел в самоизоляцию.

(55) так и запишем. При отсутствии IT бубна, пользоваться мистой.
Помню кто то кота предлагал завести, для дебага.

(57) врятли, но чтобы в след раз отлегло надо бы проверить смарт и свободное место

(45) На картинке

(51) Может не успевает отработать предыдущий шаг в заданное окно, вот и не работает

(60) вот ссылка на картинку. https://yadi.sk/i/eoEUCSxeEjbkhQ
Не знаю, как тут еще показать картинку

(62) Ну вот интересны должны быть столбики Avg read / write io stall. У тебя плохие показатели сами по себе, но это не означает, что проблема именно в дисках. Но это явно повод копнуть в эту сторону.

(62) лог GB written vs Total IO Write Stall vs Log size 2.83
возможно и диски гг и фрагментация лога в симпл, дайте еще 10-20 Гб логу

+ а вообще снесите касперского и вместо иде дисков поставьте сата)

время жизни транзакции?
если где-то повисла транзакция,то остальные ждут,когда она выполнится.

(65) Самый прикол когда sql сервер с hdd (вместо ssd) еще заодно и файловый сервер.
Тут тушите свет, пара юзеров по гигабиту влегкую уложат hdd и sql будет в отрубе.

В общем, проблема вернулась, чего следовало ожидать. Помимо выполнения запросов к тому справочнику она еще проявляется при установке отбора по Складу в списке документов Требование-накладная. Также зависает сеанс пользователя.

Уже развернули еще один сервер 1С на другой машине, эту базу перенесли туда. Монитор ресурсов показывает ошибки отсутствия страниц в памяти для процесса rphost. Это уже после того, как убрали оттуда эту базу.

(69) Если ты говорил что у тебя и запрос в консоли скуля тормозит то при чем тут перенос сервера 1С и рпхост? Надо было сервер БД перенести на другой хост / другие диски.

(70) Типа, имелось в виду, что перенос сервера 1С частично освободит ресурсы на данном сервере.

(69) "Монитор ресурсов показывает ошибки отсутствия страниц в памяти для процесса rphost" оперативки хочет еще

(71) Разгрузка текущего железа вместо задействования доступного нового - неправильное приложение усилий

"Доступного нового", к сожалению, нет

(74) "развернули еще один сервер 1С на другой машине" - вот про эту другую машину речь

А... зацепило слово "еще один"?:) Возможно. На той другой машине сисадмин не может запустить SQL Server, что-то мешает.

(74) 4к на апгрейд зажали?

(77) Если бы Вы знали, что это за место... Как по локации, так и по финансовым возможностям...

Тем временем, удалось локализовать проблему, возможно, опять временно. Отдельное спасибо arsik. После обновления статистики вроде что-то оживает. Теперь надо понять, почему перестал выполняться план обслуживания.

(76) Использовать прежний SQL на другой машине нет возможности?

(79) не верится что _такое_ из-за плана обслуживания, 300к строк даже с поломанной статистикой должно быть быстро. лог кстати нарастили? дайте ему хоть треть диска Ф

(80) Да что-то не поднимается SQL на другой маашине.

(81) Лог нарастили

Да и проблема, к сожалению, была не только в запросе к таблице на 300К записей. Это просто яркий пример. Сеансы 1С намертво висли и при других операциях.

(76) пусть введет в рабочую группу мастером виндовым)