Всем доброй ночи.
База 800 гб КА 1.0 релиз от 2010 года. Пиленая.
Проблема при массовой проведении ООрП начала зависать на простом запросе к регистру цен АТТ, это один из запросов в модуле проведения документа. Модуль типовой.
Причем виснет не стабильно, то нормально запрос проходит то зависает.
В SQL  нашел отчетом "Самые продолжительные транзакции" вот такой запрос https://disk.yandex.ru/d/ZuuajG4eW-p4nw
Вижу что таблица InfoRg19056 как Р/С Цены АТТ.
В чем может быть дело как продиагностировать проблему?

(0) Попробуйте трассировку. Возможно надо кэш запросов почистить. Попробуйте удалить позиции которые не нужные уже и цены по ним

>от 2010 года. Пиленая.... Проблема при массовой проведении

СУБД предлагается угадать? База обслуживается?
Чарли, что с блокировками, что с длительными запросами согласно ТЖ?

(0) Размер таблицы регистра и его фрагментация?

(3) фрагментация индексов ничем не лучше... и это всё про обслуживание

(1) как почистить КЭШ запросов? это же не пользовательский и не серверный кэш?

(2) СУБД MS SQL 2012  https://disk.yandex.ru/d/ieG5oQJRyQ3mbQ

"База обслуживается?" - да, админ делает планы по обновлению статистики, дефрагментации (вроде ) и т.д.
база без свертки работает с 2019 года. и проблемы начались года 2 назад и шли по нарастающей. сейчас сильно начали проявляться.
ТЖ еще не настроил.
Но блокировки идут по регистру Цены АТТ скрин с отчетом из СУБД в первом скрине.

(3)  размер: строк  16 364 961
размер 4,9 гб  данные 1,6 гб индексы 3.2 гб

база растёт, тормоза будут накапливаться, сейчас 800GБ , скоро станет пара терабайт, всё встанет колом. а какой выход?

свёртка базы и переход на КА2 , либо пустую КА1.
не может база расти бесконечно, и при этом летать. особенно это касается старой платформы, либо новой с установленной совместимостью со старой версией.

(7) 16 млн строк многовато. Обрезать регистр надо, ИМХО.

(9) это не самый большой регистр
Например
РегистрНакопления.ТоварыВРознице    AccumRg20853    
строк 131 007 957    
объем 31 916 мб

РегистрНакопления.Продажи    AccumRgTn20583    
строк 115 264 130    
объем 196 505 мб

надо сворачивать

(10) Как посмотреть. В (7) Гб, а в (10) Мб.
Вот может это для Вас: https://infostart.ru/marketplace/292573/

(10) Ну и степень фрагментации таблицы не озвучена.

(12) новая вводная . Админ сказал что дефрагментация не делается и реиндексация тоже, только обновление статистики. И я понял это уже давно так.
А не делается потому что это занимает несколько часов, а техокна такого нет.
На сколько это может влиять на мою проблему?

(11) это давно решено. У нас в ПТиУ есть механизм авторасчета наценок для всех форматов магазинов+ автоматическое формирование Установки цен и переоценок по всем магазинам и складам.
Отчасти этот механизм добавил объема в этот регистр.

Ой, нахрена вам цены с 10 года. Сделайте срез на начало года. Внесите в регистр, а все остальное отдайте сирым и убогим.
(12) и для каких целей техноокно нужно. Ну будет у вас пару раз в месяц ночью чуть медленнее работать 1с.
Ну и для ускорения можно же только эту таблицу обработать, а не всю базу

(15)я выше написал что "база без свертки работает с 2019 года"
мы ее резали 2 раза уже в 2014 и в 2019
сейчас уже 5.5 лет без свертки летим.

(13) Попросите сисадмина выполнить запрос на сервере:
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// запрос для определения степени фрагментации индексов текущей базы (быстрый), первые 100 по степени фрагментации (убывание)

USE NAME_DB
GO
SELECT TOP 100
       DatbaseName = DB_NAME(),
       TableName = OBJECT_NAME(s.[object_id]),
       IndexName = i.name,
       i.type_desc,
       [Fragmentation %] = ROUND(avg_fragmentation_in_percent,2),
       page_count,
       partition_number,
       'alter index [' + i.name + '] on [' + sh.name + '].['+ OBJECT_NAME(s.[object_id]) + '] REBUILD' + case
                                                                                                           when p.data_space_id is not null then ' PARTITION = '+convert(varchar(100),partition_number)
                                                                                                           else ''
                                                                                                         end + ' with(maxdop = 4,  SORT_IN_TEMPDB = on)' [sql]
  FROM sys.dm_db_index_physical_stats(db_id(),null, null, null, null) s
  INNER JOIN sys.indexes as i ON s.[object_id] = i.[object_id] AND
                                 s.index_id = i.index_id
  left join sys.partition_schemes as p on i.data_space_id = p.data_space_id
  left join sys.objects o on  s.[object_id] = o.[object_id]
  left join sys.schemas as sh on sh.[schema_id] = o.[schema_id]
  WHERE s.database_id = DB_ID() AND
        i.name IS NOT NULL AND
        OBJECTPROPERTY(s.[object_id], 'IsMsShipped') = 0 and
        page_count > 100 and
        avg_fragmentation_in_percent > 10
  ORDER BY avg_fragmentation_in_percent desc

(16) Так не обязательно всю базу сворачивать. Можно только регистр цены резануть.

(18) согласен, но у нас и партии уже моросят и Р/С списанные товары.

так же отключил версионирование, чтобы поднять скорость.
просится общая свертка

(17) запустил. SQL задумался. сколько может висеть?

(17) Спасибо. запрос показал большое количество дефрагментированных таблиц.
https://disk.yandex.ru/d/iZI-4Sv6cciH7A

(21) можно
SELECT TOP 50
или
SELECT TOP 20
попробовать, если быстро хочется.

спасибо всем.
будем делать свертку. и админу тоже на подумать почву дали.

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

(22) это ерунда, таблицы маленькие и индексы маленькие. Количество страниц page_count мало, 1 страница 8 Kb. Поставь  page_count > 10000

(0) покажи этот "простой запрос" в виде запроса 1С

(27)

Функция СформироватьЗапросПоПродажнымЦенам(ДатаЦен, СписокСкладов, СписокНоменклатуры) Экспорт

    Запрос = Новый Запрос;
    Запрос.УстановитьПараметр("Дата", ДатаЦен);
    Запрос.УстановитьПараметр("СписокСкладов", СписокСкладов);
    Запрос.УстановитьПараметр("СписокНоменклатуры", СписокНоменклатуры);

    ТекстЗапроса = "
    |ВЫБРАТЬ
    |    ЦеныПродажные.Склад КАК Склад,
    |    ЦеныПродажные.Номенклатура КАК Номенклатура,
    |    ЦеныПродажные.ХарактеристикаНоменклатуры КАК ХарактеристикаНоменклатуры,
    |    ЦеныПродажные.Цена КАК Цена
    |ИЗ
    |    РегистрСведений.ЦеныАТТ.СрезПоследних(&Дата, Склад В (&СписокСкладов)
    |       И Номенклатура В (&СписокНоменклатуры)) КАК ЦеныПродажные
    |";

    Запрос.Текст = ТекстЗапроса;

    Возврат Запрос.Выполнить();

КонецФункции // СформироватьЗапросПоПродажнымЦенам()

(25) согласен. спасибо, коллеги!

Сталкивался на практике -база примерно терабайт. MS SQL стал "резко" тормозить запросах к регистрам, где был составной тип данных.

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

(30) зависит о того сколько типов в составе... ну и да, от запроса зависит