|
Зависает сеанс 1С при выполнении запроса | ☑ | ||
---|---|---|---|---|
0
denk
01.04.20
✎
17:11
|
Конфигурация БП 3.0.76.67, платформа 8.3.15.1830. Проблема со справочником ВетеринарноСопроводительныйДокументВЕТИС. С какого-то момента при выполнении простейших запросов к этому справочнику сеанс пользователя стал намертво зависать. Пример запроса:
ВЫБРАТЬ РАЗРЕШЕННЫЕ КОЛИЧЕСТВО(РАЗЛИЧНЫЕ ВСД.Ссылка) КАК КоличествоДокументов ИЗ Справочник.ВетеринарноСопроводительныйДокументВЕТИС КАК ВСД ГДЕ ВСД.Статус = ЗНАЧЕНИЕ(Перечисление.СтатусыВетеринарныхДокументовВЕТИС.Оформлен) Причем, если убрать условие ГДЕ, то запрос выполняется нормально, быстро. Перезагружали сервер 1С, делали полную переиндексацию базы средствами SQL Server - не помогло. Подскажите, пожалуйста, что где сломалось, и как это вылечить. |
|||
1
Надо работать
01.04.20
✎
17:17
|
Индекс у поля есть?
|
|||
2
denk
01.04.20
✎
17:20
|
(1) Стоит "Не индексировать"
|
|||
3
H A D G E H O G s
01.04.20
✎
17:32
|
Что говорит план запроса?
|
|||
4
denk
01.04.20
✎
17:43
|
(3) Прошу прощения, я не в теме. Если речь о SQL Server Profiler, то я не могу его запустить, он почему-то зависает при соединении к серверу.
|
|||
5
arsik
гуру
01.04.20
✎
17:49
|
(2) Ну добавь индекс в 1С.
|
|||
6
denk
01.04.20
✎
18:02
|
(5) Там дело не только в поле Статус. Когда делаешь условие по другим полям, тоже все виснет. Да и работало все неделю назад.
|
|||
7
Cyberhawk
01.04.20
✎
18:42
|
А если поменять КОЛИЧЕСТВО(РАЗЛИЧНЫЕ ВСД.Ссылка) на КОЛИЧЕСТВО(1)?
|
|||
8
denk
01.04.20
✎
18:59
|
(7) Тоже виснет
|
|||
9
denk
01.04.20
✎
19:02
|
Более того, если выполнять запрос к этой таблице непосредственно на 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 - выполняется нормально. |
|||
10
H A D G E H O G s
01.04.20
✎
19:12
|
(9) У тебя чето померло
|
|||
11
H A D G E H O G s
01.04.20
✎
19:16
|
Что скажет
DBCC CHECKTABLE('_Reference33631') ? |
|||
12
denk
01.04.20
✎
19:28
|
(10) Догадываюсь((
|
|||
13
denk
01.04.20
✎
19:28
|
(11) Результаты DBCC для "_Reference33631".
Имеется 304737 строк на 43027 страницах для объекта "_Reference33631". Ошибок не обнаружено. |
|||
14
sevod
01.04.20
✎
19:29
|
(6)А размер таблиц на sql сервере смотрел? У вас там количество документов за разумное количество не ушло? Какая нибудь таблица не разрослась?
В MS SQL есть готовый запрос для этого, выводит первые сколько то таблиц с сортировкой по размеру от большей к меньшей. Мышкой из контекстного меню по базе запускается. |
|||
15
rphosts
01.04.20
✎
19:30
|
выгрузи-загрузи обратно БД
|
|||
16
rphosts
01.04.20
✎
19:31
|
с таким планом... заменить запрос на:
ВЫБРАТЬ КОЛИЧЕСТВО(1) КАК КоличествоДокументов ИЗ Справочник.ВетеринарноСопроводительныйДокументВЕТИС КАК ВСД ГДЕ ВСД.Статус = ЗНАЧЕНИЕ(Перечисление.СтатусыВетеринарныхДокументовВЕТИС.Оформлен) |
|||
17
sevod
01.04.20
✎
19:33
|
Если есть место, попробуй стандартное выгрузить в dt загрузить в чистую базу. Какой размер базы?
|
|||
18
rphosts
01.04.20
✎
19:34
|
(17) ну или так, но предварительно сделав бэкап ибо 1-2% dt не загружаются обратно!
|
|||
19
denk
01.04.20
✎
19:35
|
(17) База весит 35 Гб (файл mdf). Дт уже прокатывает.
|
|||
20
rphosts
01.04.20
✎
19:35
|
+ хотя тут конечно индекс решает
|
|||
21
denk
01.04.20
✎
19:35
|
НЕ прокатывает
|
|||
22
rphosts
01.04.20
✎
19:36
|
(19) и чё? База-то небольшая по сути... даже на средненькую не тянет!
|
|||
23
denk
01.04.20
✎
19:38
|
(22) Когда-то и при меньших размерах ругалось на превышение размеров внутренних файлов. Попробую, конечно.
|
|||
24
denk
01.04.20
✎
19:40
|
По идее что-то с какими-то индексами случилось. Но полная реиндексация базы не помогла. Еще делал ALTER INDEX REBUILD по индексам этой таблицы - тоже не помогло.
|
|||
25
rphosts
01.04.20
✎
19:42
|
(24) см (15)
|
|||
26
КнОпка
01.04.20
✎
19:53
|
(24) sql перезагружали?
|
|||
27
denk
01.04.20
✎
19:54
|
(26) Перезагружали. Он на той же машине, где и сервер 1С
|
|||
28
такт
01.04.20
✎
20:09
|
Если убрать Разрешенные тоже виснет?
|
|||
29
denk
01.04.20
✎
20:29
|
(28) Да. Тоже виснет.
|
|||
30
Мимохожий Однако
01.04.20
✎
20:45
|
Убрать РАЗРЕШЕННЫЕ пробовал?
|
|||
31
Йохохо
01.04.20
✎
20:53
|
(23) чего чего? какой размер внутренних файлов на скуле? какая была ошибка?
|
|||
32
Cyberhawk
01.04.20
✎
20:54
|
(31) Он путает создание ДТ с его загрузкой в файловую инфобазу
|
|||
33
Йохохо
01.04.20
✎
20:57
|
(32) тогда (0) делай через дт в копию на скуле
|
|||
34
denk
01.04.20
✎
20:59
|
(31) (32) Да, немного переклинило к вечеру). Тут нет файловой базы. К счастью или нет...
|
|||
35
Йохохо
01.04.20
✎
20:59
|
напомните еще завтра разрядность спросить
|
|||
36
denk
01.04.20
✎
21:00
|
(35) везде 64
|
|||
37
Йохохо
01.04.20
✎
21:05
|
(36) в виндовом мониторе "ошибок отсутствия страниц в памяти как себя ведет?
|
|||
38
H A D G E H O G s
01.04.20
✎
21:09
|
Напиши на [email protected], могу подключиться, глянуть
|
|||
39
Cyberhawk
01.04.20
✎
21:13
|
(36) В консоли скуля проверь io read / write stall
https://www.brentozar.com/blitz/slow-storage-reads-writes/ |
|||
40
sevod
01.04.20
✎
22:07
|
(21) ну я же не в файловую базу тебе ее предлагаю грузить. В новую, чистую sql. Или у тебя выгрузка в dt не работает? Если да, то это не из за размера базы. У dt нет ограничений на размер базы. Если не выгружается, это косяк с базой.
|
|||
41
Sapiens_bru
02.04.20
✎
05:06
|
Скуль сервер не может зависнуть намертво. Его sqlos имеет высший приоритет на исполнение прерываний каждые 4ms. Он может потратить все ресурсы на плохой запрос и часами не отвечать на задания от приложений, но сервисные dmv должны работать и отвечать.
Поставь на сервер процедуру whoisactive и посмотри чем он занимается в висячем состоянии. Раз не запускается профайлер - должна быть ошибка в логах сервера. Возможно и ошибка исполнения твоего запроса тоже там. Для скуля выше чем 2008 есть альтернатива профайлеру - extended events , можно им собрать предварительный план запроса. |
|||
42
arsik
гуру
02.04.20
✎
09:29
|
А статистика на скуле актуальна?
|
|||
43
denk
02.04.20
✎
09:41
|
(39) Выполнил данный скрипт, получил некие результаты. Подскажите, пожалуйста, как их правильно интерпретировать, и что делать дальше.
|
|||
44
Cyberhawk
02.04.20
✎
10:04
|
(43) Покажи столбики
|
|||
45
denk
02.04.20
✎
10:35
|
(44)
Total IO Read Stall Total IO Write Stall 5691 16458 1814030 176769 Первая строка - Лог вторая - ROWS |
|||
46
denk
02.04.20
✎
10:40
|
Пытаюсь загрузить дт в чистую базу, как советовали. Грузится уже 2 часа. Размер базы - 35 Гб, размер дт - 4 Гб.
|
|||
47
arsik
гуру
02.04.20
✎
10:48
|
Кстати, а тип у ВСД.Статус - какой в конфигурации?
|
|||
48
denk
02.04.20
✎
10:57
|
(47) ПеречислениеСсылка.СтатусыВетеринарныхДокументовВЕТИС. Только, как я уже писал, дело не в Статусе. При условии по другим полям тоже все колом встает.
|
|||
49
arsik
гуру
02.04.20
✎
10:59
|
(48) А что по статистике MS SQL (42) ?
|
|||
50
denk
02.04.20
✎
11:04
|
(49) В последний раз план обслуживания ее сделал 31 марта. Сейчас руками не хочется запускать, чтобы дополнительных тормозов не получить. Пользователи и так нервничают...
|
|||
51
denk
02.04.20
✎
11:06
|
Почему план обслуживания перестал работать, это тоже вопрос. "Совпадение - не думаю"
|
|||
52
Йохохо
02.04.20
✎
11:15
|
(45) так не видно где там нули и что в (37) это же проще
|
|||
53
такт
02.04.20
✎
11:28
|
(50) динамическим обновлением часто балуешься ?
|
|||
54
denk
02.04.20
✎
11:40
|
(53) Нет. Под страхом смерти
|
|||
55
denk
02.04.20
✎
11:45
|
Друзья, спасибо всем за участие и отклики. У меня на Мисте такое в первый раз. В данный момент проблема ушла САМА, пока все работает. Никто ничего не делал, ни руками, ни регламентами. Подозреваю, что проблема может вернуться. Тогда и продолжим тему:-)
Ну и если есть гипотезы, что это было, пишите:) |
|||
56
Йохохо
02.04.20
✎
11:50
|
(55) бед блок наконец что уехал, ага
|
|||
57
denk
02.04.20
✎
11:53
|
(56) Вот... Или пользователь выключил комп с глючной сетевой картой и ушел в самоизоляцию.
|
|||
58
sevod
02.04.20
✎
12:43
|
(55) так и запишем. При отсутствии IT бубна, пользоваться мистой.
Помню кто то кота предлагал завести, для дебага. |
|||
59
Йохохо
02.04.20
✎
12:44
|
(57) врятли, но чтобы в след раз отлегло надо бы проверить смарт и свободное место
|
|||
60
Cyberhawk
02.04.20
✎
12:54
|
(45) На картинке
|
|||
61
Cyberhawk
02.04.20
✎
12:55
|
(51) Может не успевает отработать предыдущий шаг в заданное окно, вот и не работает
|
|||
62
denk
02.04.20
✎
15:03
|
(60) вот ссылка на картинку. https://yadi.sk/i/eoEUCSxeEjbkhQ
Не знаю, как тут еще показать картинку |
|||
63
Cyberhawk
02.04.20
✎
15:35
|
(62) Ну вот интересны должны быть столбики Avg read / write io stall. У тебя плохие показатели сами по себе, но это не означает, что проблема именно в дисках. Но это явно повод копнуть в эту сторону.
|
|||
64
Йохохо
02.04.20
✎
15:40
|
(62) лог GB written vs Total IO Write Stall vs Log size 2.83
возможно и диски гг и фрагментация лога в симпл, дайте еще 10-20 Гб логу |
|||
65
Йохохо
02.04.20
✎
15:50
|
+ а вообще снесите касперского и вместо иде дисков поставьте сата)
|
|||
66
Сияющий в темноте
02.04.20
✎
23:03
|
время жизни транзакции?
если где-то повисла транзакция,то остальные ждут,когда она выполнится. |
|||
67
Garykom
гуру
02.04.20
✎
23:19
|
(65) Самый прикол когда sql сервер с hdd (вместо ssd) еще заодно и файловый сервер.
Тут тушите свет, пара юзеров по гигабиту влегкую уложат hdd и sql будет в отрубе. |
|||
68
denk
03.04.20
✎
07:54
|
В общем, проблема вернулась, чего следовало ожидать. Помимо выполнения запросов к тому справочнику она еще проявляется при установке отбора по Складу в списке документов Требование-накладная. Также зависает сеанс пользователя.
|
|||
69
denk
03.04.20
✎
07:57
|
Уже развернули еще один сервер 1С на другой машине, эту базу перенесли туда. Монитор ресурсов показывает ошибки отсутствия страниц в памяти для процесса rphost. Это уже после того, как убрали оттуда эту базу.
|
|||
70
Cyberhawk
03.04.20
✎
09:21
|
(69) Если ты говорил что у тебя и запрос в консоли скуля тормозит то при чем тут перенос сервера 1С и рпхост? Надо было сервер БД перенести на другой хост / другие диски.
|
|||
71
denk
03.04.20
✎
09:32
|
(70) Типа, имелось в виду, что перенос сервера 1С частично освободит ресурсы на данном сервере.
|
|||
72
Йохохо
03.04.20
✎
09:35
|
(69) "Монитор ресурсов показывает ошибки отсутствия страниц в памяти для процесса rphost" оперативки хочет еще
|
|||
73
Cyberhawk
03.04.20
✎
09:35
|
(71) Разгрузка текущего железа вместо задействования доступного нового - неправильное приложение усилий
|
|||
74
denk
03.04.20
✎
09:42
|
"Доступного нового", к сожалению, нет
|
|||
75
Cyberhawk
03.04.20
✎
09:47
|
(74) "развернули еще один сервер 1С на другой машине" - вот про эту другую машину речь
|
|||
76
denk
03.04.20
✎
09:50
|
А... зацепило слово "еще один"?:) Возможно. На той другой машине сисадмин не может запустить SQL Server, что-то мешает.
|
|||
77
Йохохо
03.04.20
✎
09:50
|
(74) 4к на апгрейд зажали?
|
|||
78
denk
03.04.20
✎
09:51
|
(77) Если бы Вы знали, что это за место... Как по локации, так и по финансовым возможностям...
|
|||
79
denk
03.04.20
✎
09:54
|
Тем временем, удалось локализовать проблему, возможно, опять временно. Отдельное спасибо arsik. После обновления статистики вроде что-то оживает. Теперь надо понять, почему перестал выполняться план обслуживания.
|
|||
80
Мимохожий Однако
03.04.20
✎
10:01
|
(76) Использовать прежний SQL на другой машине нет возможности?
|
|||
81
Йохохо
03.04.20
✎
10:02
|
(79) не верится что _такое_ из-за плана обслуживания, 300к строк даже с поломанной статистикой должно быть быстро. лог кстати нарастили? дайте ему хоть треть диска Ф
|
|||
82
denk
03.04.20
✎
10:03
|
(80) Да что-то не поднимается SQL на другой маашине.
|
|||
83
denk
03.04.20
✎
10:04
|
(81) Лог нарастили
|
|||
84
denk
03.04.20
✎
10:08
|
Да и проблема, к сожалению, была не только в запросе к таблице на 300К записей. Это просто яркий пример. Сеансы 1С намертво висли и при других операциях.
|
|||
85
Йохохо
03.04.20
✎
10:08
|
(76) пусть введет в рабочую группу мастером виндовым)
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |