1С:Предприятие 8.3 (8.3.21.1895)
Розница, редакция 2.3 (2.3.9.42)
Режим: Серверный (сжатие: усиленное)
РИБ 6 магазинов
MS SQL 2019
Я обычный пользователь, и статья для таких же, как я. Рассказываю в силу своего понимания ситуации, потому что потрачено много времени и, если кому-то будет полезно, то буду рад.
История как в сказке про репку. Появилась проблема, которая потянула за собой решение обновиться. Обновили центральную базу до последнего релиза, поставили делать первый РИБ, с 12 ночи до 9 утра не сдвинулось с 0% (железо не топ, но I7, 64гб оперативы, ssd самсунг 970), около 6кк объектов к выгрузке. Пришлось откатываться назад и разбираться. База велась с 2016, соответственно накопилось всякого.
Далее сделал копию базы и проводил все манипуляции с ней, после в основной базе.
1. Выпилил неудачный опыт интеграции Ветис Меркурий в 1С. За несколько месяцев работы (пока не перестал этим пользоваться) в базу залетело более 5гигов файлов по ВСД(!) и несколько сотен тысяч записей по разным регистрам.
Файлы увидел через Администрирование-Обслуживание-отчеты администратора-объем ненужных. Выгрузил их в папку на диск (администрирование-работа с файлами) и снес. Регистры вычищал обработкой СДР: Редактор объекта ИБ (1.1.0.71 от 07.05.2023). Далее шлифанул тестированием и исправлением без реструктуризации.
2. Сделал свертку базы на 1 год, поудалял все помеченное, сделал ТиИ с реструктуризацией, которое неожиданно заняло 1.5 дня
3. Сделал свертку еще на 2 года, реструктуризация быстрее не стала. Проблема была на моменте реструктуризации РегистрНакопления. ТоварыНаСкладах. Таблица регистрации изменений (около 35кк записей). 99.9% времени занимала обработка этого регистра.
Обработкой СДР: Консоль запросов (1.1.0.45 от 07.02.2020) выяснил, что... одно из подключаемых оборудований, а именно весы с печатью этикетов Штрих-М, воспринималось системой как узел обмена (открыть "регистрация изменений для обмена данными") и на них все это время пытался выгружаться регистр накопления - товары на складах!!! При этом было 29 узлов обмена этих весов (не смогу складно объяснить, но этих весов в подключаемом оборудовании висело несколько неиспользуемых, плюс узлы обмена по всем этим настройкам каким-то образом были продублированы пятикратно) и почти на каждом висело по 1.6кк регистраций к выгрузке. Собственно эти абсолютно ненужные записи комп сутки и переваривал на реструктуризации. Сняв регистрацию объектов с них и удалив лишние узлы обмена, все тестирование и исправление базы заняло меньше часа. Задача весов получать PLU и цены. Зачем так сделано, для меня загадка.
4. Ну и когда процесс ТиИ пошел быстро, не смог не обратить внимание на притормаживание на регистре Замеры времени. Тоже подлянка оказалась, но простая. Материал по ней здесь же и читал. Если коротко, то в центре мониторинга запрещаем отправку сообщений и в оценке производительности отключаем ее ведение. Чем раньше это сделаете, тем больше времени себе сэкономите в будущем, вычищая миллионы бесполезных записей о том, за сколько миллисекунд делался чек в 2017 году. Регистров по замерам несколько. В регламентных заданиях есть очистка только одного, нужно только время изменить, у меня стоял час с 4 до 5 утра)) Остальное обработкой удалял.
5. Итого: ТиИ с полутора суток сократилось до часа. Создание файла риба с 6кк объектами (неопределенного конечного времени создания) сократилось до 2кк за 2часа с минутами.
Если вдруг кто-то, разбирающийся в теме, прочитает и не сильно будет хейтить за эту историю (я понимаю, что на взгляд профи простые пользователи как дауны выглядят, когда рот открывают), то просьба ответить, почему, удалив столько мусора, база в sql как была 68гб, так и осталась?
Вступайте в нашу телеграмм-группу Инфостарт