Переписал проведение по партиям, оптимизировал запросы, а вот вставка в таблицу итогов регистра накопления "РегистрНакопления.ПартииТоваровНаСкладахБухгалтерскийУчет" и "РегистрНакопления.ПартииТоваровНаСкладах" при проведении документов партионного учета идет 2144 и 542 мс соответственно. Что делать-то, комрады, чтоб было на порядок побыстрее? (Таблица итогов весит 655.08 МБ, индексы 2823.16 МБ).

Всех с пятницей, да!

Индексы убрать, таблицу сократить.

(2) А как индексы убрать? Насколько я понимаю, вставка - дорогая операция (так даже говорит план запроса). Но вот как его убрать и какие (тем более, индексы платформенные); и таблицу, соответственно, как шринкануть?

(3) а не боисся 1С поломать прямыми инъекциями в базу?

Кроме вставку в регистр накопления надо еще вставлять в таблицу оборотов, в таблицу остатков, в таблицу регистрации изменений, если есть узлы планов обмена

(4) Уот я и спрашиваю. Думаю, итоги отключить, чтоб при проведении не писались, а потом фоном пересчитывать. Норм же?

(0) Проведение одного дока 2144?

Или всех за 21144?

Или ...

(5) Вот это глупость ты сморозил!!!!!

(0) Собери статистику, посмотри блокировки. В обещм проанализируй проблему, а потом уже решай что делать.

Решений может быть много:
1. Убрать свои доработки, которые будто бы должны помочь, а на самом деле рождают неоптимальности
2. Настроить задания для сервера.

(10) Точняк, таблица остатков:) (7) Одного, конечно. Комплектации, так как она больше всего работает с этим регистром.

(12) Что точняк, нет такой таблицы, как таблица остатков.

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

(13) Потому и стоит смайлик, я понял твою критику оратору  (5). Есть таблица итогов.

(15) Тогда почет и уважение )))

(14) Время указано для dev-базы, то есть, она не под нагрузкой. На рабочей базе показатели еще печальнее. Проверял wait lock, очень часто в пик больше 1000мс.

(0) Оптимизировал по-пятничному, что тут скажешь.

>Что делать-то, комрады
Ты сейчас какой ответ хочешь? Вопрос у тебя сейчас, как у блондинки: "у меня не получается, что делать". Информации для ответа 0.

(17) Ну значит смотрим блокировки. Хотя если один сеанс, то блокировок избыточных не должно быть.

Какие рег процедуры на сервере настроены? (очистка кеша, реиндексация и т.п.)

(18) Хочу а) физически решить проблему - мощнее сервер; б) программно - устранить самые длительные операции. В данном случае - запись в таблицу итогов регистра накопления. Такой пока диагноз. Таблица объмная, индекс в 4 раза больше. Очевидно, ее гадо оптимизировать.

(19) Блокировки - это отдельный разговор. Да, с ними система еще больше тормозит. Планы обслуживание по статистике и обновлению индекса - ежедневные. Я думаю, индекс избыточен и при вставке каждой записи он перестраивается. То есть, при чтении получаем выигрыш, при записи - тормоза...

(20) Давай начнем с того, где было узкое место до твоей оптимизациии. Ты его отследил профайлером?

Размер таблицы или индекса ничего не говорит о необходимости оптимизации.

(21) Что такое "обновление индекса"? REBUILD?

(22) +1

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

Версия это (релиз конфигурации, доработки, ОС, версия СУБД ну и подобное)

(22) >>вставка в таблицу итогов регистра накопления "РегистрНакопления.ПартииТоваровНаСкладахБухгалтерскийУчет" и "РегистрНакопления.ПартииТоваровНаСкладах" при проведении документов партионного учета идет 2144 и 542 мс соответственно.

В теме ОП-поста написано.

(25) Это из профайлера, если что. Самые долгие операции проведения документа.

(24) Версия платформы 8.2.19.83, конфа - УПП релиз 1.3.48.1, снятый с поддержки. SQL2K8 R2, такой же MS Win Server, х64. Но сервер 1С и скуль на одной виртуальной машине с 32 Гб РАМ.
Думаю, еще затык в памяти (как RAM так и HDD), так как стабильно чтение более 10 страниц в секунду.

Физический сравнительный анализ сложно провести, так как нет свободных ресурсов.

(21) Тогда увеличь филл-фактор для индекса. Если уж такие сомнения.
Обслуживание индексов и статистики при вставке данных в таблицу ни пр чем, ты же не запросы делаешь. Уменьшать количество индексов(или данных в индексе) с ходу не рекомендуется, так как индексы могут поддерживать уникальность на записях. Узких мест здесь 2 - ожидание получения исключительной блокировки - ты же пишешь, не читаешь, и обслуживание(т.е. запись) в  нескластерные индексы. Проверяй.

(28) В умной книге по SQL-серверу прочитал, что при большом некластеризованном индексе операции INSERT, UPDATE и DELETE становятся ресурсозатратными (так как надо перестраивать B-дерево индекса). Кстати, именно из-за этого происходит дефрагментация. Про филл-фактор понял, думаю, можно поэкспериментировать.