Обслуживание баз данных. Не так просто, как кажется

Публикация № 1134515 14.10.19

Администрирование БД - HighLoad оптимизация

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

Считаете, что обслуживание индексов и статистик дело простое? Что ж, это не всегда так.

История начинается

Вы обслуживаете базу данных среднего или большого размера? Имею ввиду размер от 100 ГБ и больше. Если да, то, возможно, с проблемами обслуживания индексов и статистик Вы уже сталкивались, а описание кейса в статье будет Вам знакомо. Если же Вы счастливчик и имеете дело со скромными по размеру системами, то информация ниже может пригодиться Вам в будущем.

В любом случае, добро пожаловать! Рассказанный случай может быть полезен для всех.

Подопытная база

Главным героем сегодня будет "Бухгалтерия предприятия 3". Точный релиз не важен, т.к. структура регистра бухгалтерии редко меняется. Да и любая конфигурация, имеющая в своем составе этот тип регистра, потенциально могла бы быть сегодня в центре внимания.

Интересуемые для нас характеристики подопытного:

  • Размер базы 3 ТБ.
  • Работа с регистром бухгалтерии ведется очень интенсивная. В сутки на основной таблице регистра выполняется порядка 800 тысяч операций записи (вставка и обновление данных), а также 12 млн. операций чтения.
  • Регистр большого размера. Взгляните на состав его таблиц и их размеры (данные получены с помощью этого отчета).
 
 Информация о таблицах регистра бухгалтерии

Ранее мы уже рассматривали общую информацию о структуре регистра бухгалтерии. Сегодня эти знания нам пригодятся.

Плюс ко всему, в базе настроено обслуживание индексов и статистики вне рабочего времени, ночью.

 
 Скрипты обслуживания индексов и статистик

Оба скрипта имеют настройки ограничения выполнения по времени, чтобы работа по обслуживанию не перешла на рабочие часы.

 
 Обслуживание индексов
 
 Обслуживание статистики

Обратите внимание на ту часть скрипта, где информация об обслуженных индексах и объектах статистики может быть записана в служебную базу данных, в том числе и с дополнительной информацией о времени обслуживания каждого объекта. Это может быть очень полезно при расследовании что и как обслуживалось, сколько времени на это было затрачено и так далее.

В основном все работает хорошо и на производительность жалоб не поступает. APDEX в зеленой зоне (ох уж этот APDEX). Но иногда возникают странные проблемы с подвисанием и блокировками во время проведения / отмены проведения документов.

Двойная жизнь

Как это часто бывает, информационная система живет сложной жизнью. Днем она записывает / сохраняет документы при работе пользователей, а также формирует множество вариантов отчетов. Ночью же на сцену выходят "монстры", называемые как "регламентные задания" с массовым изменением данных. Думаю, это обычная ситуация для многих.

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

Сначала обычно начинают разбираться так:

  • Есть ли зависшие сеансы 1С или сессии на SQL-сервер. Если есть, то "убивают" их, предварительно сохранив всю доступную информацию о сеансе или сессии.
  • Зависает конкретное действие в базе или нет. Если конкретное, то уже проще - можно попытаться решить, оптимизировать или, как минимум, собрать информацию.
  • Проверяем отработало ли обслуживание индексов и статистик ночью. Возможно, произошла ошибка при работе job'а и теперь придется разбирать последствия весь оставшийся день, возможно даже обслуживать часть таблиц "на горячую" (обожаю так делать!).
  • Проверяем загрузку оборудования с помощью мониторинга (он же у вас есть, не так ли?).  Если проблема там, то решаем вопрос с администраторами что и как делать. Тут может оказаться что был выпущен новый функционал и 1Сники решили "отопить" всю серверную за счет увеличения нагрузки на железо. Можете уточнить у своих коллег делают ли они так :)
  • В отчаянии перезагружаем сервер.

Но в нашем случае ничего из вышеперечисленного не помогло! Жалобы продолжают поступать. Конечно, есть и другие способы диагностики, но не будем удлинять список, пойдем дальше.

Опять эти блокировки!

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

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

UPDATE T2 SET

    -- Итог по ресурсу "Сумма"
    _Fld9622 = T2._Fld9622 + T9._Fld9622,

    -- Итог по ресурсу "ВалютнаяСуммаДт"
    _Fld9623Dt = T2._Fld9623Dt + T9._Fld9623Dt, _Fld9623Ct = T2._Fld9623Ct 
        + T9._Fld9623Ct, _Fld9624Dt = T2._Fld9624Dt + T9._Fld9624Dt, 

    -- Итог по ресурсу "ВалютнаяСуммаКт"
    _Fld9624Ct = T2._Fld9624Ct + T9._Fld9624Ct, _Fld9625Dt = T2._Fld9625Dt 
        + T9._Fld9625Dt, _Fld9625Ct = T2._Fld9625Ct + T9._Fld9625Ct, 

    -- Итог по ресурсу "СуммаПРДт"
    _Fld9626Dt = T2._Fld9626Dt + T9._Fld9626Dt, _Fld9626Ct = T2._Fld9626Ct 
        + T9._Fld9626Ct, _Fld9627Dt = T2._Fld9627Dt + T9._Fld9627Dt, 

    -- Итог по ресурсу "СуммаВРКт"
    _Fld9627Ct = T2._Fld9627Ct + T9._Fld9627Ct

FROM #tt24 T9 WITH(NOLOCK) -- Таблица с заранее подготовленными данными
    -- Таблица "ИтогиМеждуСчетами", именно в ней обновляются итоги данным запросом
    INNER JOIN dbo._AccRgCT1188 T2
    -- Соединения по:
    -- Периоду
    ON T9._Period = T2._Period 
        -- СчетДТ
        AND T9._AccountDtRRef = T2._AccountDtRRef
        -- Счет КТ
        AND T9._AccountCtRRef = T2._AccountCtRRef AND T9._Fld9679RRef = T2._Fld9679RRef 
        -- Валюта ДТ
        AND ((T9._Fld9620DtRRef = T2._Fld9620DtRRef OR T9._Fld9620DtRRef IS NULL AND T2._Fld9620DtRRef IS NULL))
        -- Валюта КТ
        AND ((T9._Fld9620CtRRef = T2._Fld9620CtRRef OR T9._Fld9620CtRRef IS NULL AND T2._Fld9620CtRRef IS NULL)) 
        -- Подразделение ДТ
        AND ((T9._Fld9629DtRRef = T2._Fld9629DtRRef OR T9._Fld9629DtRRef IS NULL AND T2._Fld9629DtRRef IS NULL)) 
        -- Подразделение КТ
        AND ((T9._Fld9629CtRRef = T2._Fld9629CtRRef OR T9._Fld9629CtRRef IS NULL AND T2._Fld9629CtRRef IS NULL)) 
        -- Служебный разделитель
        AND T2._Splitter = @P9

-- Фильтр по разделителю данных
WHERE (T2._Fld9659 = @P2)

При формировании записей движений платформа 1C выполняет множество запросов, ведь регистр бухгалтерии имеет сложную структуру и логику работы. В будущем мы продолжим серию статей об этом регистре и рассмотрим их, но сегодня остановимся только на этом запросе. 

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

Вроде все хорошо, что же может пойти не так? Но если мы соберем дополнительную статистику, то увидим, что этот запрос выполняется порядка 30-60 секунд. То есть соединение данных двух таблиц выполняется очень долго, а в плане запроса обычно появляется операция "Table scan". О ужас!

Поскольку для базы используется RCSI, то сканирование таблицы для обновления не блокирует всю таблицу. Лишь те записи, которые подходят под указанную аналитику (счет ДТ и КТ, подразделение ДТ и КТ, валюта ДТ и КТ и период (месяц)). Но так как сканирование выполняется до 60 секунд (а иногда и более), то при интенсивной работе есть вероятность появления таймаутов на таких блокировках, особенно если эта аналитика часто используется. Вот если бы RCSI не был бы включен, то блокировок было бы еще больше!

Но почему, почему запрос получился именно такой? Почему появились операции сканирования таблиц, ведь подходящие индексы для таблицы итогов есть? Вчера же все работало! Ох уж эта платформа 1С, она точно во всем виновата!

Почему так

Но почему? Почему так? Первое, что приходит в голову, так это проверить фрагментацию индексов у таблицы итогов регистра, вдруг обслуживание почему-то не отработало и поэтому SQL Server не использует индексы? СУБД считает их использование нецелесообразным, т.к. фрагментация слишком высокая. А если высокая, то затраты ресурсов при их использовании могут быть выше, чем старое доброе сканирование таблицы? Смотрим.

 
 Что там с индексами?

Что ж, проблем с индексами нет. Давайте тогда посмотрим на состояние статистики.

 
 Статистика актуальная?

Бинго! Статистика стала неактуальной и SQL Server перестал использовать индексы в запросе. В начале статьи Вы могли видеть, что всего в таблице итогов между счетами примерно 415 тысяч записей. То есть, в таблице было потенциально изменено больше 30% всех данных, а статистика до сих пор не обновилась, что и не позволило СУБД использовать индексы должным образом. 

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

Да, обслуживание прошло ночью без ошибок, но до таблицы итогов между счетами оно просто не добралось! Сравните сами количество записей в других таблицах регистра и этой: 415 тыс. в таблице итогов и 103 млн. записей в основной таблице регистра.  Разница существенная! Ночью были обслужены статистики больших таблиц, в которых изменения происходят чаще всего, а до мелких очередь просто не дошла. А ведь в базе есть не только регистр бухгалтерии, но и другие таблицы и пообъемнее!

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

Может возникнуть вопрос: "Почему же проблема "плавает" и не возникает каждый день?". Вопрос справедливый и ответ простой: массовые изменения в бухгалтерском регистре происходят не каждый день и зависят от каких-то неизвестных обстоятельств.  Например:

  • Внезапно понадобилось пересчитать итоги.
  • Загрузить очень много документов.
  • Перепровести регламентные операции закрытия.
  • Да что угодно!

Плюс, в некоторых случаях обслуживание все же делает обновление статистики для этой таблицы, если в очереди нет других более тяжелых объектов к обслуживанию.

Как же быть в таких ситуациях?

Как быть

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

 
 Обновляем статистику"на горячую"

Окей, мы стабилизировали ситуацию! Блокировок больше нет, а система летает (и не падает)! Если бы таблица была очень большой, то потребовалось бы больше времени на обновление статистики, во время которого наблюдалось бы снижение производительности. Принимайте взвешенное решение, прежде чем запускать скрипт на продакшене.

Но как предотвратить подобную аварию в будущем?

Работая над обслуживанием базы некоторое время начинаешь собирать информацию об особенностях ее работы. К таким особенностям относится и наш случай. Мы можем создать отдельный план обслуживания для индексов и статистик, актуальное состояние которых критично для функционирования всей системы. Так и поступим в нашем случае: добавим план обслуживания нашей "особенной" таблицы и ее статистик, который будет работать параллельно основному плану обслуживания. Расписание также можно выбрать на свое усмотрение. Конкретно в этом случае был настроен запуск каждые 4 часа, так как таблица небольшая, а изменений по ней много. Основной работе обслуживание никак не мешало и занимало обычно от 5 до 15 секунд на рабочем сервере.

Скрипт для плана обслуживания можно сделать такой же, как и в выше. Правильно было бы также исключить из основного плана обслуживания те объекты, для которых созданы свои процессы обслуживания.

Теперь одной проблемой обслуживания базы данных меньше!

Нет базы - нет проблем

Все, что описано выше, необязательно должно случиться с Вами! Это лишь одна из возможных проблем, которая может поджидать при увеличении размера базы данных и ее чувствительности к качественному обслуживанию индексов и статистики.

Всю статью можно пересказать простыми словами: "Правильно обслуживайте индексы и статистику, тогда и проблем не будет". Вот только не всегда однозначно можно сказать, как это сделать, а очевидные ответы бывают ошибочны. Те скрипты, что можно найти на просторах интернета или стандартные компоненты планов обслуживания SQL Server не являются полностью универсальными, как Вы могли убедиться из примера выше.

Следите за своими базами, держите обслуживание эффективным!

Есть свои истории на этот счет? Добро пожаловать в комментарии!

Другие ссылки

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Region102 14.10.19 12:17 Сейчас в теме
Отличная статья!
dabu-dabu; RickyTickyTok; Summer_13; taiwanchik; geron4; YPermitin; +6 Ответить
2. YPermitin 11214 14.10.19 12:22 Сейчас в теме
(1) спасибо за хороший отзыв! :)
3. geron4 174 14.10.19 15:28 Сейчас в теме
Как-то был у меня на практике случай, 1С ЗУП + MSSQL (версия Standart 2014) перестал использовать индекс, сбор/пересбор статистики не помогали, пришлось новый индекс запилить, оптимизатор его сам подхватил.

Хинты к сожалению в 1С не поставишь, есть вариант перехвата запроса и добавления хинта, точно не помню, но там тоже что не пошло.
Вот в случае, когда в течении дня статистика может стать не актуальной - хинты на индексы бы нормально зашли, только платформа их конечно не поддерживает. :(
Как вариант, можно капнуть, чтобы запретить менять план запроса для некоторых запросов, но это тема для изучения.
YPermitin; acanta; +2 Ответить
4. YPermitin 11214 14.10.19 15:31 Сейчас в теме
(3) интересный случай. Вот бы воспроизвести и изучить.

P.S. Надеюсь в скором времени выпустить небольшую разработку для экспериментов с перехватом запросов от платформы с возможностью их изменения. Можно будет и с хинтами поэкспериментировать. Не для прода, конечно.
klezyk; geron4; +2 Ответить
5. geron4 174 14.10.19 15:38 Сейчас в теме
(4) На счет перехвата запросов - очень интересно, в каких-то версиях MSSQL есть штатные механизмы для отлова и подмены. Вспомнил почему не получилось штатными средствами - там привязка к точному тексту запроса, а если у тебя таблицы соединяются с временными, например #TT800 (или #TT1000), то запрос всегда разный.

На счет номеров временных таблиц это шутка из Терминатора :))), номера всегда разные.
acanta; YPermitin; +2 Ответить
6. YPermitin 11214 14.10.19 15:41 Сейчас в теме
(5) штатный перехват не совсем то, что нужно. Там можно планы запросов свои делать для запроса или триггерами переопределять действия для запроса, но вот прям текст запроса поменять нельзя. В PostgreSQL есть возможность поменять текст запроса через AST-дерево запроса, но задача тоже не тривиальная.

Вообщем, будет публикация :)

P.S. про терминатора Огонь!
7. nicxxx 241 14.10.19 16:14 Сейчас в теме
Включите уже traceflag 2371 и забудьте о ручном обновлении статистики.
Irwin; Ashandy; YPermitin; +3 Ответить
8. YPermitin 11214 14.10.19 16:19 Сейчас в теме
(7) это применимо, но далеко не всегда. Расскажите свой случай, где Вам настройка помогла, если есть такая возможность.
9. nicxxx 241 14.10.19 18:52 Сейчас в теме
(8)
Расскажите свой случай, где Вам настройка помогло

БП 3.0
Размер регистра бухгалтерии точно не скажу, в сумме наверно 200 ГБ
Прирост в день минимум 1 млн проводок
11. Ashandy 21.10.19 16:27 Сейчас в теме
(7)
traceflag 2371

спасибо, не знал о таком
Кстати, там еще написано:

Примечание. Начиная с версии SQL Server 2016 (13.x) и при уровне совместимости базы данных 130 или более высоком эта реакция управляется подсистемой, и флаг трассировки 2371 не оказывает влияния.
YPermitin; +1 Ответить
12. YPermitin 11214 21.10.19 16:36 Сейчас в теме
(11) (9) все никак не успеваю ответить.

Автообновление статистики ни в коем случае не заменяет поаны обслуживания и может привести к серьезным проблемам на высоконагруженных базах из-за порогов обновления статистики и и повышенной нагрузки для асинхронного обновления данных.

Тема обширная. Посмотрите в гугле.
13. nicxxx 241 22.10.19 16:33 Сейчас в теме
(11) Да, все правильно. С этой версии флаг включен по-умолчанию.
10. vihrov_av 16.10.19 08:26 Сейчас в теме
Подобные планы обслуживания нужно периодически актуализировать, так как таблицы в которых вчера статистика обновлялась за 5 секунд, сегодня может обновится целую минуту, а завтра и того больше. Поэтому данная процедура - цепь непрерывных улучшений. Которым нужно удалять время и включать в план работ.
Дмитрий74Чел; YPermitin; +2 Ответить
14. nicxxx 241 22.10.19 16:34 Сейчас в теме
(10)
таблицы в которых вчера статистика обновлялась за 5 секунд
хе-хе. 9 часов :)
YPermitin; +1 Ответить
15. nvv1970 23.10.19 18:34 Сейчас в теме
Объемные таблицы должны быть вынесены в отдельный план обслуживания. При чем при определенных условиях автоапдейт для отдельных таблиц имеет смысл выключать вообще.
YPermitin; +1 Ответить
16. YPermitin 11214 23.10.19 18:42 Сейчас в теме
(15) полностью согласен.
А иногда и не только большие.
17. letarch 29.10.19 15:50 Сейчас в теме
подобные операции по обслуживанию индексов и статистик нужно применять и для postgres баз?
YPermitin; +1 Ответить
18. YPermitin 11214 29.10.19 16:28 Сейчас в теме
(17) у PG тоже есть статистика, но работает несколько иначе.
26. Xershi 1269 02.05.20 10:30 Сейчас в теме
(17) нужно, на днях была статья как это сделать.
27. letarch 03.05.20 11:24 Сейчас в теме
28. Xershi 1269 03.05.20 12:30 Сейчас в теме
(27) вам повезло на днях админу скидывал, быстро нашел:
Держи данные в тепле, транзакции в холоде, а VACUUM в голоде.
Там также чутка и по мс скуль.

Кстати вопрос к автору. У клиента А есть 2012, у Б 2017 мс скуль.
У А 2 плана ежедневный и недельный. У Б ежедневный.
Каким образом проверяете время выполнения плана обслуживания?

У клиента Б мс скуль дает задать процент в частности указали 15%. И вот для таблицы заказы клиента при объеме в 400к документов нужно изменить 60к, чтобы скрипт отработал?
19. user706076_s.travin 30.12.19 17:06 Сейчас в теме
спасибо за статью! очень выручает периодически.

скрипт по обновлению статистики отрабатывает заменив "where" на "and"
AND [o].[is_ms_shipped] = 0
-- Отбор по имени таблицы итогов, у которой мы расследуем проблему
WHERE AND o.name = '_AccRgCT1188'
20. rozer 292 28.04.20 20:52 Сейчас в теме
А процедурный кеш надо же сбрасывать после обновления статистики вроде бы... а то планировщик будет из старого кеша планы брать....
21. DarkAn 998 30.04.20 11:57 Сейчас в теме
(20) вроде как, уже не актуально.
22. rozer 292 30.04.20 13:17 Сейчас в теме
(21) не актуально с какой версии sql server стало?
23. DarkAn 998 30.04.20 13:22 Сейчас в теме
(22) Точно не отвечу. Андрей Бурмисров в курсе по оптимизации об этом говорил.
Одна из проблема с сбросом процедурного кэша в том, что он сбрасывается для ВСЕХ БД, а не отдельно взятой.
24. rozer 292 30.04.20 14:53 Сейчас в теме
странно во всех мануалах нужно процедурный кеш скидывать после статистики и иначе планировщик, который берет инфу из кеша используя старую статистику вместо например index seek фигачит менее оптимальные способы поиска и соединений в данных .... Ну Бурмистров не Гилев конеч но Бурмистрову виднее ))
25. YPermitin 11214 30.04.20 15:51 Сейчас в теме
(24) с 2014 редакции SQL Server помечает планы после обновления статистики как устаревшие. Это если ооооочень кратко.
Очищать кэш каждый раз не лучшая идея. Видел ужас - днем обновляется статистика и тут же сбрасывается процедурный кэш. Все вроде хорошо, но на самом деле нет :) График компиляции планов запросов зашкаливает некоторое время, даже в замера 1С видны замедления операций.

Отсюда вывод: самый главный мануал - это документация к ПО и .... эксперименты.
30. vacony 22.12.20 12:08 Сейчас в теме
(25)
мануал - э


так а как правильно делать ?
Есть довольно большие базы , 1с розница. много данных по чекам, заказам и т.д.
Делается обновление статистики , если штатно, 7 - 12 - 16 часов... скриптом по выборочно таблицам (размеру) часа 2-3. И индексы ( реиндекс или обновление от фрагментации ) . Послед сброс процедурного кеша...

Это является более менее оптимальным планом ?
31. vacony 22.12.20 12:28 Сейчас в теме
(30)


так а как правильно делать ?
Есть довольно большие базы , 1с розница. много данных по чекам, заказам и т.д.
Делается обновление статистики , если штатно, 7 - 12 - 16 часов... скриптом по выборочно таблицам (размеру) часа 2-3. И индексы ( реиндекс или обновление от фрагментации ) . Послед сброс процедурного кеша...

Это является более менее оптимальным планом ?
29. vacony 22.12.20 10:30 Сейчас в теме
Супер статья !
очень помогает в работе.
Но море вопросов рождается -
хотя бы такой - в скуле (Microsoft SQL Server 2016 (SP2-CU12) ) стоит автообновление статистики , но на сейчас (22.12.2020) есть таблицы -
_Document168_VT3333 _WA_Sys_0000001E_2364B165 0 4474349 2020-12-18 07:07:26.113 0 0 NULL NULL NULL
_Document168_VT3333 _WA_Sys_00000013_2364B165 0 4474349 2020-12-18 07:10:34.190 0 0 NULL NULL NULL
_Document168_VT3333 _WA_Sys_00000004_2364B165 0 4474349 2020-12-18 07:21:23.380 0 0 NULL NULL NULL
_Document168_VT3333 _WA_Sys_00000003_2364B165 0 4474349 2020-12-18 07:23:45.840 0 0 NULL NULL NULL
_Document168_VT3333 _WA_Sys_0000000D_2364B165 0 4474349 2020-12-18 07:31:24.540 0 0 NULL NULL NULL
_Document168_VT3333 _WA_Sys_00000005_2364B165 0 3223395 2020-12-19 18:34:48.263 0 0 NULL NULL NULL
_AccumRg5051 _WA_Sys_0000000D_5860F2DB 0 2301412 2020-12-18 02:59:38.200 0 0 NULL NULL NULL
_AccumRg4923 _WA_Sys_00000012_187B77F0 0 2000919 2020-12-18 02:17:35.097 0 0 NULL NULL NULL
_AccumRg4923 _WA_Sys_00000013_187B77F0 0 2000919 2020-12-18 02:20:36.320 0 0 NULL NULL NULL
_Document144_VT2564 _WA_Sys_0000000E_7F1176FF 0 1929736 2020-12-18 05:14:54.590 0 0 NULL NULL NULL
_Document144_VT2564 _WA_Sys_00000007_7F1176FF 0 1929736 2020-12-18 05:16:26.363 0 0 NULL NULL NULL
_Document144_VT2564 _WA_Sys_00000009_7F1176FF 0 1929736 2020-12-18 05:19:00.517 0 0 NULL NULL NULL

Который НЕ обновляли статистику с 18 числа , с учетом что изменилось там 2 - 4 млн строк ! Почему ?

В самой таблице Document168_VT3333 - 259 млн строк ... 4 млн - типа мало изменилось ?
И считается что - строки самой таблицы или строки индекса для изменения ?
Оставьте свое сообщение

См. также

Регламентные операции с индексами в MS SQL Server (Скрипты для SQL-Server - Часть 2) Промо

HighLoad оптимизация Абонемент ($m)

В данном вебинаре я расскажу о том, что такое индексы, зачем они нужны, какие регламентные операции необходимо выполнять с индексами, а также будут приведены соответствующие скрипты (для MS SQL-Server) для обслуживания индексов баз данных.

1 стартмани

22.03.2018    37423    29    Tavalik    10    

Ошибка производительности при проведении этапа 2.2 в ERP 2.4 и ERP 2.5

HighLoad оптимизация v8 ERP2 Россия Бесплатно (free)

Хочется поделиться одним подводным камнем, с которым могут встретиться другие пользователи ERP. Искал решение в интернете, но ничего похожего не нашел. Поэтому решил создать эту тему.

сегодня в 14:00    93    Rokky78    0    

Регламентное задание по завершению сеансов пользователей 1С

Администрирование СУБД v8 1cv8.cf Бесплатно (free)

Завершить работу пользователей в 1С ночью. Регламентное завершение работы.

сегодня в 09:30    97    Swamt    2    

Базовые приемы работы с кластером 1С при помощи БСП

Администрирование СУБД БСП (Библиотека стандартных подсистем) v8 1cv8.cf Бесплатно (free)

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

26.10.2021    3336    quazare    6    

Долго открывается конфигуратор Промо

HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями), чтобы повысить производительность 1С:Предприятие 8 в ряде случаев.

22.04.2015    44072    Gilev.Vyacheslav    1    

Повышение производительности веб-сервисов. Переиспользование сеансов

WEB HighLoad оптимизация v8 Бесплатно (free)

Повышение производительности веб-сервисов. Переиспользование сеансов. Практическая реализация.

20.10.2021    1748    sorter1    2    

Обновление платформы 1С тонкого клиента с вебсервера, когда сервер 1С ПРОФ

Администрирование веб-серверов Администрирование СУБД v8 1cv8.cf Бесплатно (free)

Обновление платформы 1С: тонкого клиента с вебсервера описывается на https://its.1c.ru/db/v8316doc#bookmark:adm:TI000001058, но по факту, следуя точно инструкциям вендора с ИТС, никому не удалось добиться результата. Выражаю благодарность Панюшкину Михаилу Михайловичу за разбор задачи и доведение ее до практического результата.

19.10.2021    1509    ser6702    13    

Клиент-серверный режим базы данных 1С8 для тестирования

Инструменты администратора БД Администрирование СУБД v8 1cv8.cf Бесплатно (free)

В публикации рассматриваются некоторые аспекты настройки базы данных 1С8.3 в серверном режиме, для тестирования обработок или расширений.

30.09.2021    1485    etmarket    3    

Видеодемонстрация применения Теста-центра для нагрузочного тестирования конфигураций Промо

HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

Тест-центр – инструмент автоматизации многопользовательских нагрузочных испытаний информационных систем на платформе 1С:Предприятие 8. С его помощью можно моделировать работу предприятия без участия реальных пользователей, что позволяет оценивать применимость, производительность и масштабируемость информационной системы в реальных условиях. В видео показан пример с внедрением конфигурации Тест-центра в произвольную информационную базу и создание простого сценария нагрузочного теста.

16.09.2012    36471    Aleksey.Bochkov    29    

Зависание базы при создании/редактировании пользователей после конвертации базы с платформы 8.1 на 8.3

Администрирование СУБД v8 УТ10 Россия Бесплатно (free)

При переводе базы с платформы 8.1 на платформу 8.3 возникает проблема - база конвертится замечательно, но при редактировании или создании новых пользователей база напрочь зависает. Речь пойдёт о серверной базе данных.

29.09.2021    456    Kitri    4    

Оптимизация проведения документов списания партий в УПП 1.3

HighLoad оптимизация v8 УТ10 УПП1 Бесплатно (free)

Почти в каждой конфигурации УПП 1.3 (возможно, и в УТ 10.3) есть медленный запрос, тормозящий проведение документа списания. Данная публикация раскрывает места вызова данного запроса и приводит пример оптимизации. Пример показывает результаты проведения документа «Реализация товаров и услуг», но метод работает и для других документов списания партий.

09.09.2021    587    info1i    4    

Смотрим запросы 1С через Microsoft SQL Profiler по следам ошибок разработчиков, приводящих к проблемам производительности

HighLoad оптимизация Рефакторинг и качество кода Технологический журнал v8 Бесплатно (free)

Расскажем про инструменты, рассмотрим планы запросов, увидим, как отслеживать и бороться с проблемами производительности на боевой базе.

07.09.2021    4226    ivanov660    23    

Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С Промо

HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

Описано как из 1С, с помощью безобидной на первый взгляд обработки, можно сделать неработоспособным SQL сервер. Предложены меры, позволяющие избежать этого.

22.01.2014    69205    yuraos    112    

Перекуем Cloud на Oracle. Тестируем размещение 1С в облачной платформе Oracle Cloud.

Администрирование СУБД Облачные сервисы, хостинг v8 1cv8.cf Бесплатно (free)

После цикла публикаций про размещение 1С в облачных сервисах я думал, что все различные варианты рассмотрены и тема для меня закрыта. Однако есть события, мимо которых не пройти. Так вот и сейчас, когда наблюдается аттракцион невиданной щедрости от Oracle, мимо этого просто так не пройти.

02.09.2021    700    capitan    22    

Адекватный параллелизм в 1С

HighLoad оптимизация v8 Бесплатно (free)

Параллелизм ускоряет выполнение тяжелых регламентных операций на СУБД, но может негативно влиять на работу многопользовательских учетных систем. О том, как анализировать влияние параллелизма и настраивать его для MS SQL и PostgreSQL, рассказал ведущий разработчик компании ООО МКК «Ваш Инвестор» Вадим Фоминых.

13.08.2021    3664    Shmell    7    

Распространенные ошибки разработчиков, приводящие к проблемам производительности

HighLoad оптимизация Рефакторинг и качество кода v8 Бесплатно (free)

Рассмотрим примеры ошибок, анализ, исправление и мероприятия по недопущению подобного в будущем. Всего будет 18 примеров.

02.08.2021    9528    ivanov660    77    

Ускоряем списание партий УПП 1.2 / 1.3 / УТ 10.3 Промо

HighLoad оптимизация v8 УТ10 УПП1 Бесплатно (free)

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

21.06.2013    59262    Антон Ширяев    117    

Обновление 1С: Розницы с релиза 2.3.8.27 до 2.3.9.28

Администрирование СУБД v8 Розница Россия Бесплатно (free)

Многие уже столкнулись с тем, что не смогли обновить 1С: Розницу релиз 2.3.8.27 на более поздние релизы. Напомню, релиз 2.3.8.27 - позволял-таки нам работать в ЕГАИС 4. Но а вот с дальнейшими обновлениями...

05.07.2021    6534    13D    25    

Parameter sniffing и генерация планов для разработчиков 1С

HighLoad оптимизация v8 Бесплатно (free)

Особенности генерации планов запросов. Статья написана по мотивам вебинара Виктора Богачева.

01.06.2021    9077    vasilev2015    17    

Как подключиться к хранилищу конфигурации на сервере за NAT, если есть доступ по RDP?

Администрирование СУБД Хранилище v8 Бесплатно (free)

В статье находится инструкция по подключению базы 1С к хранилищу конфигурации, если хранилище не опубликовано в интернет, но опубликовано по TCP в локальной сети клиента.

01.06.2021    2678    Dipod    13    

Сравнение скорости работы 1C+MSSQL и файлового варианта Промо

HighLoad оптимизация v8 1cv8.cf Россия Бесплатно (free)

На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая? Затем обычно идет «флуд» на несколько десятков страниц. Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд. В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнения.

19.02.2013    61385    Gilev.Vyacheslav    46    

Как добыть последнюю версию SQL Server 2012 Native Client

Администрирование СУБД Администрирование ИТ-инфраструктуры v8 Бесплатно (free)

Краткое руководство администраторам 1С по получению свежей версии SQL Server 2012 Native Client, необходимого для работы сервера 1С.

13.05.2021    2581    tedkuban    3    

Ускорение реструктуризации больших таблиц. Мой вариант

HighLoad оптимизация Администрирование СУБД BigData v8 1cv8.cf Бесплатно (free)

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

28.04.2021    1336    buganov    0    

Поиск причин блокировок СУБД

HighLoad оптимизация v8 v8::blocking 1cv8.cf Бесплатно (free)

Расследование блокировок СУБД. Статья написана по мотивам вебинара Виктора Богачева.

28.04.2021    5802    vasilev2015    13    

Параллельные вычисления в 1С 8 Промо

HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

Решение позволяет ускорять выполнение запросов в 1С 8 в отчетах путем их параллельного выполнения в разных потоках.

11.02.2013    38254    gallam99    19    

Тонкости эксплуатации, плюшки и особенности Postgres Pro Enterprise

HighLoad оптимизация v8 1cv8.cf Россия Бесплатно (free)

В ходе онлайн-встречи INFOSTART MEETUP Novosibirsk Руководитель ИТ из компании ИнфоСофт Антон Дорошкевич поделился с коллегами тонкостями и опытом работы с Postgresql для 1С. 

22.04.2021    2511    a.doroshkevich    4    

Xubuntu 20.04 для бухгалтера 1С

Linux Администрирование СУБД v8 БП3.0 Россия Бесплатно (free)

В публикации представлен необходимый минимум для настройки Xubuntu 20.04 в качестве рабочего места бухгалтера, ведущего учёт в программе 1С: Бухгалтерия 3.0 файловый вариант. Кроме этого, настроено подключение и других сотрудников через тонкий клиент 1С к опубликованной на веб-сервере базе бухгалтерии.

12.04.2021    4913    compil7    25    

Режим совместимости конфигурации 1С

Администрирование СУБД v8 1cv8.cf Россия Бесплатно (free)

Приветствую, коллеги! В этой статье будет сделан обзор функции совместимости конфигурации 1С с другими версиями конфигураций 1С, а также рассмотрено, как выбрать и настроить режим совместимости конфигурации с версией 1С 8.3. Во-первых, разберём главное понятие в этой статье: режим совместимости в конфигурации – это устройство, благодаря которому выводится номер версии системы, под которую станет открыто приложение 1С:Предприятие. Данный режим существует на платформе 1С начиная с версий 8.2 и 8.3 (платформа версии 1С:Предприятие 8.3 совместима с платформой версии 1С:Предприятие 8.2).

31.03.2021    6239    Koder_Line    4    

Ubuntu vs CentOS vs Win2k8 vs Debian: производительность PostgreSQL Промо

Статистика базы данных HighLoad оптимизация v8 Бесплатно (free)

Хотя интернет уже переполнен статьями о "правильной" настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самую большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно. Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

03.11.2012    45390    madmpro    32    

Решение нестандартных проблем производительности на реальных примерах

HighLoad оптимизация v8 Бесплатно (free)

На екатеринбургском Infostart Meetup выступил с докладом архитектор ИС центра разработки ФТО Александр Криулин. Он поделился с коллегами кейсами нестандартных проблем производительности и рассказал о способах их решения.

24.03.2021    5063    AlexKriulin    37    

Соединение вложенными циклами

HighLoad оптимизация v8 Бесплатно (free)

Nested loops и отсутствующие индексы. Статья написана по мотивам вебинара Виктора Богачева.

12.03.2021    3634    vasilev2015    22    

Долгое воспроизведение звука по RDP с удаленной машины

HighLoad оптимизация v8 Бесплатно (free)

При воспроизведении короткого звука в 38 Кб, сигнализирующего об успешном сканировании, порою происходило подвисание примерно в 5 секунд.

09.02.2021    978    pashamak    2    

Highload-оптимизация 1С: теория и практика на примере консолидированной отчетности группы "Магнит" и розничной аптечной сети "Магнит"

HighLoad оптимизация BigData v8 Бесплатно (free)

Тема оптимизации 1С на больших данных бесконечная и всеобъемлющая, поскольку на производительность влияет целый ряд факторов – количество пользователей, данных, транзакций, неоптимальные запросы и т.д. Об инструментах для локализации проблем производительности и практических кейсах оптимизации рассказал Алексей Олейник, руководитель сектора автоматизации отчетности МСФО компании «Информационные технологии Магнит».

11.01.2021    26269    user662404_itlexusss    14    

Платформа 8.3.18 Обновление ИБ в пакетном режиме поломалось? Решено

Администрирование СУБД v8 Бесплатно (free)

Уже давно работаем с большим количеством ИБ и обновляем, естественно, в пакетном режиме, но с переходом на новую платформу 8.3.18.1208 этот пакетный режим поломался. Стало появляться окно конфигуратора и спрашивать вопросы, раньше такого не было. Решение найдено.

24.12.2020    6354    VPanin56    14    

Анализ блокировок СУБД: таблица изменений плана обмена 1С

HighLoad оптимизация v8 Бесплатно (free)

Практический пример анализа типичной проблемы ожидания на блокировках СУБД, возникающих при использовании планов обмена 1С. Сервер СУБД: Microsoft SQL Server.

18.12.2020    3620    zhichkin    7    

Анализ проблем производительности по динамике мониторинга RAS 1C

HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

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

07.10.2020    5073    ivanov660    13    

Ускорение медленной работы строк в 1С на примере 1С:Документооборот КОРП

HighLoad оптимизация v8 ДО Бесплатно (free)

Если у вас в 1С:Документооборот КОРП 2.1.11.5 (часть более старых и новых конфигураций): 1) Долго отправляется почта в формате HTML; 2) Медленно открывается документы внутренние / входящие / исходящие; 3) Тормозит область просмотра или открытие задач. Тогда вам сюда.

02.10.2020    5468    Nykyanen    16    

Тест скорости работы мобильной платформы 1С

Мобильная разработка HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

С помощью этого приложения вы можете измерить производительность своего устройства, используя для этого мобильную платформу 1С:Предприятие. Набор действий теста полностью повторяет аналогичный тест для стационарных ПК, поэтому результаты сравнимы.

14.09.2020    1934    capitan    25    

Восстановление полнотекстового поиска в базе данных. Клиент-серверный вариант. Моя практика.

Администрирование СУБД v8 Бесплатно (free)

Восстановление полнотекстового поиска в базе данных. Клиент-серверный вариант.

06.08.2020    1130    premierex    3    

Администрирование списка баз Windows правами.

Администрирование СУБД v8 Бесплатно (free)

Все пользуются, а статьи по администрированию списка баз нет. Непорядок.

03.08.2020    1269    sergey279    0    

Нестандартные блокировки при работе с OLAP-нагрузкой

HighLoad оптимизация v8 Бесплатно (free)

Если выполнение отчета мешает работе других пользователей и провоцирует блокировки, даже с учетом «грязного чтения» – ситуация кажется парадоксальной. О том, как расследовать такие проблемы, на конференции Infostart Event 2019 Inception рассказали ведущий программист торгового дома «Петрович» Станислав Щербаков и специалист по производительности компании «СофтПоинт» Александр Денисов.

20.07.2020    2761    Филин    7    

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

HighLoad оптимизация Администрирование СУБД Технологический журнал Структура метаданных v8::Запросы Бесплатно (free)

Обычно предметом оптимизации являются заранее определенные ключевые операции, т.е. действия, время выполнения которых значимо для пользователей. Причиной недостаточно быстрого выполнения ключевых операций может быть неоптимальный код, неоптимальные запросы либо же проблемы параллельности. Если выясняется, что основная доля времени выполнения ключевой операции приходится на запросы, то осуществляется оптимизация этих запросов. При высоких нагрузках на сервер СУБД в оптимизации нуждаются и те запросы, которые потребляют наибольшие ресурсы. Такие запросы не обязательно связаны с ключевыми операциями и заранее неизвестны. Но их также легко выявить и определить контекст их выполнения, чтобы оптимизировать стандартными методами.

24.05.2020    11588    DataReducer    22    

[SQL Server] Использование trace flag 9592 для сжатия траффика в кластере AlwaysOn

HighLoad оптимизация v8 Бесплатно (free)

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

18.05.2020    2689    Aleksey.Bochkov    4    

Настоящий краудфандинг. Даешь сравнение двух СУБД!

Администрирование СУБД v8 Бесплатно (free)

Первый вариант сравнения двух СУБД. Каждый может внести правку и получить SM. Приветствуются конструктивные комментарии, начинающиеся словами "Автор ничего не понимает".

11.05.2020    3045    vtv74    25    

Эти занимательные временные таблицы

HighLoad оптимизация Администрирование СУБД v8 Бесплатно (free)

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    16699    YPermitin    0    

Оптимизация запросов 1С посредством индексации временных таблиц. Миф? Тестируем, смотрим, считаем

HighLoad оптимизация v8 Бесплатно (free)

Появилось свободное время, решил проверить на работе индексацию таблиц. Решил поделиться с Вами результатами исследования. Давайте порассуждаем на эту тему? Часто ли вы пользуетесь индексацией в запросах? Платформа 8.3.16.1224

03.04.2020    9141    feva    15    

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

HighLoad оптимизация WEB Интеграция с сервисами Мобильная разработка Администрирование веб-серверов v8 Бесплатно (free)

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    16183    informa1555    35    

Многострочный контекст событий

HighLoad оптимизация Технологический журнал v8 Бесплатно (free)

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

31.03.2020    3911    vasilev2015    11