← На главную

Разберем ситуацию, когда база 1С:Бухгалтерия 3.0 значительно выросла в объеме (более 100 Гб), и запуск процедуры перепроведения документов вызывает взаимные блокировки, не позволяя пользователям полноценно работать в системе. Мы проанализируем причины такого поведения и рассмотрим шаги, которые помогут вернуть стабильность в работу предприятия.

Анализ причин возникновения блокировок

Первым делом важно понять, почему параллельная работа становится невозможной. Перепроведение по партиям — это операция, требующая массового изменения записей в регистрах накопления и бухгалтерии. Когда база достигает больших размеров, длительность каждой транзакции возрастает. В момент записи система устанавливает блокировки на таблицы _AccRg (регистры бухгалтерии) и _AccumRg (регистры накопления). Если другие пользователи в это же время пытаются проводить свои документы, возникают конфликты блокировок (Deadlocks) и «неопределенные ошибки».

Диагностика состояния базы данных

Прежде чем принимать радикальные меры, проведем глубокую диагностику. Выполним следующие шаги:

1. Анализ «топа» таблиц: Используя SQL Server Management Studio, определим таблицы, занимающие больше всего места. Если основная нагрузка приходится на _AccRg и _AccumRg, значит, проблема именно в интенсивном пересчете итогов.
2. Проверка фрагментации: При постоянном перепроведении данные в SQL-таблицах фрагментируются (появляется много «дыр»). Обычное обслуживание сервера должно включать регулярную переиндексацию и обновление статистики.
3. Проверка возможности выгрузки в .dt: Если база не выгружается в файл .dt, это тревожный сигнал. Возможно, в базе накоплен «мусор» или существуют логические повреждения, требующие исправления.

Методы оптимизации и решения проблемы

Рассмотрим конкретные шаги, которые мы можем предпринять для улучшения производительности:

1. Регламентное обслуживание SQL Server

Важно убедиться, что на сервере настроен правильный план обслуживания. Простого перестроения индексов недостаточно. Мы должны:

• Выполнить обновление статистики (Update Statistics) с параметром FULLSCAN. Актуальная статистика позволяет планировщику SQL выбирать оптимальные планы запросов.
• Отключить параметр Auto Shrink, так как он вызывает деградацию производительности при попытках системы автоматически сжать файлы базы данных.

2. Обновление платформы и конфигурации

Если используется ветка платформы 8.3.18, рассмотрим переход на более стабильные современные релизы (например, 8.3.22 и выше). Это часто решает скрытые проблемы с управлением транзакциями, характерные для старых версий.

3. Очистка и обслуживание через Конфигуратор

Попробуем выполнить следующие действия в копии базы:

1. Тестирование и исправление (ТиИ): Запустим процедуру с галочками «Пересчет итогов» и «Сжатие таблиц». Это поможет пересобрать индексы на уровне 1С и вернуть место, занятое фрагментацией.
2. Реструктуризация: При обновлении конфигурации важно следить, чтобы процедура реструктуризации завершилась полностью. В некоторых случаях полезно повторно «накатить» файл поставщика .cf для приведения структуры таблиц к эталонному состоянию.

4. Организационные меры

Необходимо признать технический предел системы. Если база достигла объема в 100 Гб и содержит данные за 10+ лет, «волшебной кнопки» для ускорения не существует. Мы можем предложить руководству:

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

В заключение, проанализируем текущие настройки: убедимся, что блокировки регламентных заданий в свойствах базы не установлены, и проверим планы обменов, если используется РИБ, так как разросшаяся таблица изменений также может быть причиной тормозов. Совместными усилиями администрирования и программирования 1С мы сможем стабилизировать работу системы.