При обновлении крупных информационных баз «1С:Предприятие», особенно когда объем данных исчисляется терабайтами, стандартные процедуры могут приводить к трудноустранимым ошибкам. Типичная ситуация: при переходе с режима совместимости 8.3.14 на 8.3.17 (и выше) процесс прерывается сообщением о нарушении логической целостности регистра бухгалтерии. Рассмотрим подробно, почему это происходит и как решить проблему, не запуская полное «Тестирование и исправление» на несколько суток.
Для начала проанализируем, что именно меняется в платформе при смене режима совместимости. Начиная с версии 8.3.15, разработчики 1С существенно оптимизировали работу с регистрами бухгалтерии. Если раньше данные о субконто хранились преимущественно в отдельной таблице, то в новых версиях в основную таблицу движений регистра было добавлено порядка 23 новых полей (их количество может варьироваться). Эти поля, часто называемые «плоскими субконто» (_ExtraDimension), позволяют платформе быстрее строить отчеты без лишних соединений таблиц (JOIN).
Во время реструктуризации платформа пытается перенести данные из вспомогательной таблицы _AccRgED (значения субконто) в основную таблицу _AccRg. Если в базе существуют записи-сироты (записи в таблице субконто, для которых нет соответствующих записей в основной таблице) или нарушены ссылочные связи, механизм реструктуризации завершается аварией. На базах объемом 1,5 Тб этот процесс становится критическим, так как любая ошибка откатывает транзакцию, занимавшую многие часы.
Первое, что мы должны сделать — отказаться от старого механизма реструктуризации. В современных версиях платформы реализован механизм «Реструктуризация информационной базы версии 2». Рассмотрим, как его включить и почему это важно:
В отличие от классического метода, который выполняет ALTER TABLE непосредственно над существующими данными, оптимизированный режим создает новые временные таблицы, переносит в них данные, строит индексы и только в конце заменяет старые таблицы новыми. Для базы в 1,5 Тб это потребует наличия свободного места на дисковом массиве SQL-сервера (еще минимум 1,5 Тб), но это единственный способ гарантировать завершение процесса при наличии мелких логических нестыковок.
Поскольку стандартное ТИИ (Тестирование и исправление) будет проверять всю базу, включая огромные справочники и неактуальные регистры сведений, мы можем прибегнуть к помощи SQL-сервера для локализации ошибки в конкретном регистре. Разберем, как получить структуру хранения.
Для начала выполним в 1С команду, которая покажет нам имена физических таблиц SQL:
Структура = ПолучитьСтруктуруХраненияБазыДанных("РегистрБухгалтерии.Хозрасчетный", Истина);
Для Каждого СтрокаТаблицы Из Структура Цикл
Сообщить("Имя таблицы: " + СтрокаТаблицы.ИмяТаблицыХранения + " | Назначение: " + СтрокаТаблицы.Назначение);
КонецЦикла;
Получив имена таблиц (обычно это _AccRgXX и _AccRgEDXX), мы можем запустить проверку физической целостности конкретной таблицы средствами SQL Server, как советовали участники обсуждения:
DBCC CHECKTABLE ('_AccRg12345');
GO
Важный нюанс: DBCC CHECKTABLE проверяет только физическую сохранность страниц на диске. Ошибку «логической целостности» 1С он не исправит, но поможет убедиться, что проблема не в битых секторах диска или памяти сервера.
Чаще всего логическая целостность нарушается из-за того, что в таблице субконто _AccRgED присутствуют записи, ссылающиеся на несуществующие строки основной таблицы. Проанализируем ситуацию с помощью SQL-запроса (замените имена таблиц на свои):
SELECT COUNT(*)
FROM _AccRgED6789 sub
LEFT JOIN _AccRg6789 main ON sub._Period = main._Period AND sub._RecorderRRef = main._RecorderRRef
WHERE main._Period IS NULL
Если запрос возвращает результат больше нуля, значит, у вас есть «мусорные» записи субконто. Их удаление через SQL (после создания бэкапа!) часто позволяет реструктуризации пройти успешно без запуска полного ТИИ.
Если мы хотим остаться в рамках штатных средств 1С, но не проверять всю базу, можно использовать встроенный язык. Хотя в интерфейсе ТИИ нельзя выбрать один объект, программно это реализуемо через ПроверитьЛогическуюЦелостность(). Рассмотрим пример кода для внешней обработки:
МассивПроверки = Новый Массив;
МассивПроверки.Добавить(Метаданные.РегистрыБухгалтерии.Хозрасчетный);
ПараметрыПроверки = Новый Структура;
ПараметрыПроверки.Вставить("ПроверкаЛогическойЦелостности", Истина);
ПараметрыПроверки.Вставить("ИсправлятьОшибки", Истина);
// Внимание: Данный метод может потребовать монопольного режима
// и специфических прав доступа.
// Результаты будут выведены в окно сообщений или лог.
Такой подход позволит существенно сэкономить время, сосредоточившись только на проблемном объекте.
Для баз объемом более 1 Тб критически важно состояние индексов и статистики. Перед запуском обновления выполните следующие действия:
UPDATE STATISTICS для всех таблиц регистра бухгалтерии. Это поможет оптимизатору SQL правильно распределить нагрузку при создании новых полей.LDF файл имеет достаточно места для роста, либо переведите базу в режим Simple Recovery Model на время реструктуризации.8.3.18 были замечены утечки памяти при работе с очень большими таблицами. Убедитесь, что лимит памяти на один рабочий процесс в настройках кластера 1С установлен с запасом (не менее 4-8 Гб), либо временно снимите ограничения.Проблема «логической целостности» при переходе на новые режимы совместимости в БП 3.0 — это системное следствие изменения структуры данных. Для баз в 1,5 Тб мы рекомендуем следующий алгоритм:
1. Никогда не используйте выгрузку в .dt для таких объемов — вероятность успешно загрузить его обратно крайне мала, а время ожидания составит дни.
2. Обязательно включите оптимизированную реструктуризацию v2 в свойствах конфигурации.
3. Если ошибка сохраняется, используйте SQL-запросы для поиска некорректных записей в таблицах _AccRgED и их точечного удаления.
4. Выполняйте обновление только после полной реиндексации и обновления статистики в SQL Management Studio.
Такой комплексный подход позволит вам успешно обновить даже самую тяжелую базу данных, минимизировав время простоя системы.