Есть проблема с БД: ни с того, ни с сего на прошлой неделе работа с БД стала проходить крайне долго, то, что выполнялось раньше примерно за 1 секунду, стало выполняться примерно за 15-20 секунд. Что любопытно, глючить в тот момент стал даже поиск по журналу, указываешь номер документа, жмёшь "Найти" и поиск вместо 1 секунды зависает на минуты, при этом сам процесс sqlserver.exe что-то усиленно потребляет на процессоре сервера.
Эта ситуация была на прошлой неделе, я пробовал изменять ТА, удалять помеченные со сжатием БД, прогон всех заданий SQL (очистка истории, обновление статистики + реиндексация, реорганизация) - ничего не помогло.
По итогу перезагрузил сам сервер, и всё резко пришло в норму.
Сегодня история повторилась, и, как и ранее, помог только полный ресет сервера с установленным SQL.
Понимаю, что информация слишком общая, но ранее такого никогда не было, помогите хотя бы с направлением, куда копать.
Спасибо.

(229) теперь понятно... Диридер-бетонщик ;-)

Короче пока есть проблема загрузки 100% ядра, повышение до 2008 нереально, надо думать что-то другое.

(231) еще раз, такой проблемы нет. Есть только проблема в г-коде.

И клюшки, даже на mssql 2019 летают/

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

(232) проблему с прокладкой ещё забыли упомянуть...

(218)
А могли бы посоветовать какие-либо поделки, кроме vk_hook, которые могут помочь с проблемой без переписывания километров кода ?

(235) Ну вот же есть https://infostart.ru/public/83504/ или вы этим и пользуетесь?

(236)
Да, таким и пользуемся.

(205)
Сделал шринк, снова проверил фрагментацию, а там:
https://ibb.co/WzS5KX7

Это так и должно быть ?
Или после шринка снова крутить
EXEC sp_MSforeachtable 'ALTER TABLE ? REBUILD WITH (DATA_COMPRESSION = PAGE)'
EXEC sp_MSforeachtable 'ALTER INDEX ALL ON ? REBUILD WITH (DATA_COMPRESSION = PAGE)'

(238) нет.
но нужно поставить триггер на реструктуризацию табличек, что ежели новая появляется, то она автоматом с компрессией ставится

(239)
Не силён в этом деле. Подскажете, как именно ?

(240) На нимфостарте поищи, по ключевым словам сжатие таблиц SQL, там валялся готовый скрипт

(218)
Искал другие ВК, ничего не нашёл: есть старый Ромиксовый релиз vk_hook, есть наш текущий vk_hook, есть vk_sleepTerminal, но он тоже тестировался только на 7.7.25.
Ничего новее увы нету, чтоб стакалось с секретным 7-м релизом.

Ёпрст, а по (179) могли бы что-то подсказать ?

Подскажите пожалуйста всё же кто-нибудь:
если менять регламентные задания и убрать реорганизацию индекса из ежедневного задания в еженедельное, то
как лучше сделать: сначала реорганизация индекса, а потом перестроение или наоборот ?
Или вообще не принципиально ?

(243) см(186)

Я не совсем то хотел уточнить:
на сегодня у нас ежедневное задание "Обновление статистики + реиндексация" + еженедельное задание "Реорганизация индекса"
если "Реиндексацию" убрать из ежедневных в еженедельные, то сделать "Реиндексация + Реорганизация", "Реорганизация + Реиндексация" или порядок вообще не принципиален ?

Ваш вариант "восстановление индекса (перестроение) надо делать только если индексы фрагментированы >30%, а вот реорганизацию желательно делать всегда планово, раз в неделю." пока не реализуем, т.к. скрипт на проверку фрагментированности в процентах работает только для нативного режима совместимости SQL 2008.

(246) я не понимаю вашего не желания поднять уровень совместимости выше.
Реиндекс последним

(247)
Это не моё нежелание, это попытка избежать блокировочного кошмара без переписывания километров кода записей всех справочников, документов и прочего.
Пока пытался найти альтернативу vk_hook, работающую под 7-й секретный релиз и пока безрезультатно.

(248) а откуда берется этот т.н. "блокировочный кошмар"?
зы. работала достаточно приличная база, с достаточно ощутимым количеством юзверей, и приличным документооборотом - и как-то обходилось и без ромиксовской поделки (хотя она на каком-то раннем этапе использовалась для подмены запросов), и без "кошмаров".

(249)
См. (217)

(247)
Сделал отдельно статистику, ежедневно
https://ibb.co/YbSfQDK + FREEPROCCACHE

и отдельно реорганизацию + перестроение, еженедельно
https://ibb.co/DwT47Lf

Ещё заброшу tempdb на более быстрый RAID и послежу за результатом.

Пока же в субботу снова всё было печально, причём даже не помогло вручную прокрутить задание "Обновление статистики + реиндексация".
Сегодня пришлось её же крутить с утра уже при работающих пользователях, и 1с снова заработала нормально.

(250)
"-доктор, когда я вот так делаю, у меня в ухе стреляет!
-- а вы так не делайте!!!"©
Если создать транзакцию - она тормознет остальное хоть с хуком, хоть без хука.
пользователи и так увидят, а роботы это должны обрабатывать...
впрочем, я не вижу особой надобности перезаписывать роботом "сотни документов"...

(253)
Предприятие торговое, в течение всего дня роботами забрасываются тысячи чеков в БД.

(253)
+ пользователи-то увидят, но пока они будут ждать этого окошка, процессор на терминальном сервере потихоньку наберёт 100% от всех пользователей, и всё станет совсем печально.

(254) Если чеков "тысячи", то надо нормально переписать этот процесс. Значит, предприятие не совсем уж мелкое, и должно смочь это себе позволить. (я не имею ввиду исключительно "код", я имею ввиду весь процесс в целом, от появления чеков до их отражения). Правда, у меня было, емнип, всего лишь не более 9000 доков в день.
(255) про проблему с терминальником слышал, но вот не сталкивался. правда, большинство работало "на клиентах", а не в терминале

Для каких конкретно целей используется vk_hook?

(257)
Чтобы при любой транзакции:
1) не грузились ядра терминального сервера с 1с.
2) пользователь не жмакал постоянно "Повторить транзакцию", а спокойно ждал, пока его документ проведётся в порядке очереди.

Проведение документа - ставить в очередь.
очередь проводить роботом.
колов "транзакций" будет намного ниже.

(259)
Это уже откровенные костыли будут.
Опять же с переписыванием километров кода всех модулей проведения во всех местах.

(259) проще робота написать нормально. А штатное проведение штатных юзверей на штатных доках не должно тормозить. никогда не должно.

(260) это-то как раз нормально. а то что у тебя - костыли.
если у тебя система нагруженная, то проведение должно быть быстрым и не взаимоблокируемым.

(261) угу.

(259)
Т.е. один робот, обрабатывая чеки, создаёт документ и ставит его проведение в очередь к другому роботу, ожидает его отклика, чтобы знать, что делать ему самому.
Это ли не костыли ?

(264) ВСЕ ДОКУМЕНТЫ при проведении становятся в очередь.
еще раз - нагруженная система - а у тебя такая ибо рефакторить ты ее не хочешь - требует других подходов.
если тебе делать лень - так и скажи мне влом.
купите супер-пупер мега сервер и херачьте... без костылей.
если взять 10 тыс доков в день за 9 часов - то за минуту получается 18 документов. вполне некритичная нагрузка.

(248) Покажи ЧТО ты пишешь в транзакции, например. В 96% случаев она не нужна .

Если что, у нас часто пользовались групповыми обработками для записи или перепроведения, более того, часть логики затрагивала несколько доков, НО никаких транзакций не было и никто никого не ждал.
И было фиолетово, что кто-то что-то перепроводит за год, когда остальные колотят и проводят доки

(266)
В основном это глобальные документы типа "Закрытия месяца", есть ещё парочка типа товарных отчётов за месяц по каждой торговой точке.
В момент их формирования не должно быть вообще никаких движений ни по регистрам, ни по счетам.
А формируются они увы не быстро.

(268) закрытие месяца делается за закрытый период. равно как и отчеты за закрытый период. и на формирование отчетов за прошедший период движения текущего периода вообще никак влиять не должны.
и да, отчеты, переписанные на прямые запросы, работают существенно быстрее. кроме того, их можно формировать автоматом в часы наименьшей загрузки...

(268) и..вы эти отчеты в транзакции выполняете что ле?!

(270)
Заполнение их табличных частей со всеми движениями - да, в транзакции.

(271) ТКВ.

(272)
ТКВ — табло котировок валют
ТКВ — Терское казачье войско
ТКВ — термостат для определения кинематической вязкости жидкостей
ТКВ — Теченский каскад водоёмов
ТКВ — точка кипения воды
ТКВ — температурный коэффициент вязкости

Что выбрать ?

(273) ТКВ™ - Традиционный Китайский Вопрос, звучащий примерно так: "анахуа?"

(271) Че за табличные части отчета ?

Ну и да, ТКВ ?

(275) да, ХЗ! (Хотим Знать!)

(265) Но есть же еще всякие программные а порой и интерактивные создания элементов справочников и документов - это же тоже транзакционные процедуры и их тоде в очередь? А потом что значит в очередь? С какого момента она начинаетс? Не может ли быть так что в очереди останутся документы вчерашнего дня например? Обработка такого проведения понятно что в отдельном сеансе. И работает как обработка ожидания?

(267) ---Если что, у нас часто пользовались групповыми обработками для записи или перепроведения, более того, часть логики затрагивала несколько доков, НО никаких транзакций не было и никто никого не ждал.
И было фиолетово, что кто-то что-то перепроводит за год, когда остальные колотят и проводят доки---

А как вы этого добивались?

(220) можно поподробней на тему "А в своих поделках перепроведения втыкай код на количество попыток записи..штук 20, к примеру." - как это в коде выглядит ?

(278) запись самого документа/элемента проста и коротка. А вот проведение документов - уже, как правило, требует вычислений т.е. времени, в течение которого база поддерживается в заблокированном состоянии для сохранения консистентности.
в очередь - значит, "в очередь, $укины дети!". как работает очередь - зависит от реализации. можно тупо в календарно-временной последовательности, а можно с учетом приоритетности документов...

(280) чего уж подробней? попытка-исключение в цикле. если в попытке провелось, значит цикл прерывается. Можно еще в один обернуть, в котором после серии попыток - пауза

Вчера вечером выгнал всех пользователей из 1с, сделал необходимое обновление конфигурации (добавлял реквизиты в ТЧ документа), а потом перенос tempdb на более быстрый RAID.
Запустил пользователей, и 1с ... снова стала глючить напропалую.
Причём непонятно, какое именно действие привело к этому, грешу всё-таки на перенос tempdb.
После прокрутил вручную задание "обновление статистики + FREEPROCCACHE" https://ibb.co/YbSfQDK , уже без переиндексации.
Крутанулось оно минут за 25, и 1с ... взлетела с нормальной скоростью.
Отсюда вопрос: может мы зря грешим на индексы, пытаясь играться с заданиями переиндексации и реорганизации, похоже виновата именно статистика.
Она же теперь апдейтится каждую ночь по расписанию и как вариант, после определённого числа её апдейтов 1с снова ляжет на лопатки (обычно происходило ровно через 7 прогонов, в ночь с субботы на воскресенье).

И может как вариант поставить "обновление статистики + FREEPROCCACHE" в очереди выполнения после "переиндексации и реорганизации" в ночь с субботы на воскресенье, а не до неё ?

(283) "глючат напропалую" одни и те же запросы?
посмотри план запроса при "глюках напропалую", и при "нормальной работе".
Ну и индексы "разваливаются" обычно при весьма, хм, нетрадиционнной работе (например, с кучей заднего числа).
у меня на моей базенке реиндексация делалась раз в неделю, хватало.

(285)
Вообще абсолютно всё, даже банальный поиск по журналу по введённому номеру документа.
Ну и соответственно всё загрузки документов роботами, в нормальном режиме 1 чек проводится за 1 секунду, при глюках - 13-16 секунд.
Реиндексацию теперь и поставил на еженедельное обслуживание по схеме "переиндексация + реорганизация", ранее она была в ежедневном обслуживании вместе с обновлением статистики.

(286)
UPD. Т.е. не "переиндексация + реорганизация", а "реорганизация + переиндексация", перепутал малость.

Наймите Ёпрста. Но имхается, ваши жабы вам бюджета не  дадут.

(286) планы запроса - отличаются?

(289)
Увы, не силён, где именно можно это проверить.

Внесу свою лепту:
1. На старых серверах пристальное внимание необходимо уделить рейд контроллеру
типа LSI MegaRAID или Intel(построенных на этом же железе, но прошитых собственной прошивкой).
Лет пять назад я столкнулся с проблемой, что backplane не поддерживает скорость в 3gb/s.
заниматься модернизацией backplane - неблагодарное занятие, остается использовать
рейд-контроллер pcie, но на нем обязательно должна быть возможность установки в старые платы.
2. Если вы когда-нибудь сталкивались с отвалом дисков в процессе работы, то эта проблема (скорее всего)
перегрева рейд-контроллера. Я решил её с помощью установки в pciе-слот самодельного вентилятора на основе
вентилятора для корпуса Noctua, имеющего высокий ресурс.
https://vk.com/dmrsan?ysclid=l6nb5zu22f507887278&z=photo111663024_457239223%2Fphotos111663024
Помогло капитально, сервер практически перестал отключаться.
Я думаю, что у вас проблема тоже может быть связана с перегревом рейд-контроллера.

(290) отловить - профайлером.  посмотреть на план - https://olegon.ru/google/?q=как%20посмотреть%20план%20выполнения%20запроса%20ms%20sql

(284) Делайте обновление статистики каждую ночь, а разные реиндексации оставьте на выходные

(292)
Так а что именно ловить, там запросов тьма будет.

(293)
Сейчас так и выставлено, ранее было ежедневно кроме статистики ещё и реиндексация.

(294) ну любой запрос который кода-то тормозит, а когда-то не тормозит. если планы разные, значит, зависит от статистики. если планы одинаковые - значит, либо от индексов, либо от железа.

(296)
ок, попробую глянуть при следующих лагах.

(296) В общем-то и с одинаковыми планами может то тормозить, то нет, вне зависимости от индексов и железа. Зависит от того, с какими параметрами закешировалось при первом вызове

В ночь с субботы на воскресенье лаги закономерно повторились, причём в эту ночь делалось только "Обновление статистики", даже не было традиционного "реорганизация + переиндексация".
Взял самые ресурсоёмкие запросы из списка и открыл план одного из них:
https://ibb.co/gZ0tKN0
https://ibb.co/0XXW67k

крутанул вручную "обновление статистики", 1с отпустило, но план этого же запроса не поменялся:
https://ibb.co/wyG2whM
https://ibb.co/YZ70ydK

Что ещё интересно, нашёл 1 запрос с интересным сообщением об отсутствии индекса:
https://ibb.co/dJZZnGs

Всё воскресенье 1с отработала нормально, с утра понедельника - та же песня, снова кручу "Обновление статистики".
Как правило, это помогает до следующей субботы :(

(299) А как вы посмотрели план реально выполненного запроса? Запрос, выполненный в тестовом режиме из утилиты, может выполнится иначе, чем запрос, который вызвала 1с.

(299)
А вот сегодня после ручного "Обновления статистики" план запроса с отсутствующим индексом:
https://ibb.co/C7mcXpr

Изменения всё же есть.

(300)
ПКМ на запросе в списке последних ресурсоёмких запросов и там "Показать план запроса".

(299) 9898 чего за регистр хоть, в котором останки считаются ?
Поди наглухо и незакрыт еще

(303)
#==TABLE no 644    : Регистр ОстаткиТоваров
# Name    |Descr                         |SQLTableNam|RecordLock
T=RG9898  |Регистр ОстаткиТоваров        |RG9898     |          
#-----Fields-------
# Name                  |Descr               |Type|Length|Precision
F=PERIOD                |Period Registr      |D   |0     |0        
F=SP9893                |(P)МестоХранения    |C   |9     |0        
F=SP9894                |(P)Товар            |C   |9     |0        
F=SP9895                |(P)Количество       |N   |14    |3        
F=SP9896                |(P)Сумма            |N   |17    |2        
#----Indexes------
# Name                           |Descr         |Unique|Indexed fields                                              |Type      
I=PK_RG9898                      |PERIOD+PROP   |1     |PERIOD,SP9893,SP9894                                        |1          
I=VIA9894                        |VIA9894       |0     |PERIOD,SP9894                                               |0          
#

Да тут дело не в конкретном регистре.
Ведь баги наблюдаются вообще во всём в эти моменты.

В момент, когда опять появятся тормоза, позапускайте DBCC FREEPROCCACHE, возможно поможет

(305)
Ок, попробую.
DBCC FREEPROCCACHE стоит кстати 2-м шагом в задании "Обновление статистики".

(299) У вас похоже прямые запросы. Тогда можно первый запрос сюда в человеческом виде? Ну тот, который с [пЦена $Число]

+(307) И еще, было бы любопытно
Select count(*) from rg9898
и
select count(*) from ra9898

у регистра, измерения МестоХранения и Товар надо местами поменять
и у измерения Товар установить "Отбор движений"

(307)
Уточните: этот https://imgbb.com/gZ0tKN0 или этот https://imgbb.com/dJZZnGs

(308)
Select count(*) from rg9898
3.074.158

select count(*) from ra9898
19.001.889

(309)
Поясните пожалуйста смысл смены местами измерений.
У измерения Товар "Отбор движений" установлен.

(312) в PK_RG9898 будет первым Товар..хотя, и так VIA9894 задействован в запросе, раз галка стоит

(312) доступ к итогам, с отбором по товарам, был бы сразу по кластерному индексу PK_RG9898 без VIA9894

(313) при использовании VIA9894 все равно будет lookup к кластерному

Товар выше склада - имеет смысл если бывают запросы без указания склада в отборе
Если склад всегда указан, то можно оставить как есть

https://ibb.co/dJZZnGs
https://ibb.co/C7mcXpr

я бы убрал отбор движений по измерению МестоХранения

(315) Слушай, если сделать индекс руками, покрывающий, к примеру,то можно от лукапа избавиться жешь..
Хотя не ясно, как вообще может тормозить получение останка в таком регистре.

(310) Так вроде четко написано: "Тогда можно первый запрос сюда в человеческом виде? Ну тот, который с [пЦена $Число]"
И в ваших картинках он Первый. Но он нужен не из Профайлера, а из 1С-ки. Найти, что за запрос и код здесь показать.

(319)
Я боюсь, что по тексту из профайлера я не смогу найти нужный запрос именно в 1с, их очень много будет схожих.

Но опять же мы сужаем проблему до конкретного запроса и регистра.
Как по мне, пытаемся вылечить симптомы, а не болезнь.
Болезнь похоже гораздо шире, она никак не связана с одним конкретным запросом или регистром.
Самая большая загадка: почему проблема возникает, как по часам, в ночь с субботы на воскресенье и дублируется в ночь с воскресенья на понедельник.
После двойного ручного обновления статистики (в воскресенье и понедельник) проблема никак не проявляется всю рабочую неделю.

сделай это (317)

возможно и в других жирных регистрах есть такие бесполезные индексы которые сбивают планировщик запросов

в выходные производится массовое перепроведение доков?
кажется я вспомнил одну древнюю штуку..

(323) ты про замедление проведения. которое наблюадлось на SQL2000...?

(324) да
Вот только не помню, это было общее замедление сервера или только проводящего сеанса
И не помню как было на sql2k5+ если база в режиме 80

Думаю, коллеги напомнят

(325) реконнект нэйтив был поправлен в 2005

конечно "ошибка" 2000 присутстует. ведь база в режиме 80.
ну и вообще понижение базы - этот режим не должен применяться на продакшен,
режим понижения базы оставлен для отладки чтобы перенести плавно во времени приложения на новую базу.
Основное что при понижении релиза оптимизатор запросов не работает от слова совсем.
Это как бы на каком нибудь крутом мерседесе Вы едете по автобану и у Вас зашито ограничение скорости 60 км/ч

(323)
Нет, всё то же стандартное поступление чеков, как и в рабочие дни, но в меньших количествах.

(327)
Если ничего другого не поможет, будем повышаться до 100 конечно, но только с предварительной подготовкой к корректной работе с транзакциями.
Но это на крайний случай.
Ведь такая конфигурация работала у нас с 2008 года и есть не просила.