Работа с базами данных 1С:Предприятие 7.7 на платформе SQL Server 2005 иногда преподносит неприятные сюрпризы в виде зависания штатных процедур обслуживания. Одной из самых трудоемких проблем является остановка процесса "Тестирование и исправление" (ТиИ) на этапе проверки логической целостности. Рассмотрим детально, почему это происходит и как реанимировать базу данных без потери критически важной информации.
Типичная ситуация: при запуске ТиИ на этапе проверки справочников (например, Справочник.Сотрудники) процесс замирает на определенной отметке. Утилиты мониторинга, такие как ConfStat, могут показывать, что обработано, к примеру, ровно 100 элементов, после чего активность прекращается. При этом в логах тестирования могут фигурировать пугающие номера элементов — например, "Элемент 60601", хотя в самом справочнике физически всего 400 строк.
Проанализируем природу этих чисел. В 1С 7.7 номер элемента в протоколе ТиИ — это не код объекта и не его порядковый номер в списке, а физический номер записи (RECNO) в таблице базы данных. Если это число значительно превышает количество живых записей, значит, таблица "раздута" из-за обилия помеченных на удаление объектов или некорректных записей-фантомов. Зависание на отметке "100" или любой другой часто свидетельствует о том, что алгоритм 1С наткнулся на циклическую ссылку (когда объект ссылается сам на себя или через цепочку других объектов) либо на поврежденную запись в таблице периодических реквизитов.
Для эффективного исправления ошибок нам необходимо понимать, где именно 1С хранит проблемные данные. В версии 7.7 ключевыми являются следующие таблицы:
1SCONST — здесь хранятся значения констант, а также периодических реквизитов справочников и бухгалтерских счетов.1SBLOB — таблица для хранения неограниченных строк и шаблонов типовых операций._1SUIDCTL — системная таблица, управляющая генерацией новых идентификаторов объектов (ID).SC* (например, SC123) — таблицы конкретных справочников.Выясним причину ошибки duplicate key, которая часто предшествует зависаниям ТиИ. Она возникает из-за рассинхронизации таблицы _1SUIDCTL и реального максимального ID в таблице справочника. Если в _1SUIDCTL записано значение меньше, чем уже существующий максимальный ID в справочнике, 1С пытается создать объект с дублирующим ключом.
Если вы столкнулись с ошибкой дублирования ключей, первым делом необходимо проверить соответствие счетчиков. Посмотрим на пример логики исправления для справочника с кодом SC30881:
-- Находим максимальный ID, который уже есть в справочнике
SELECT MAX(ID) FROM SC30881;
-- Проверяем, что записано в таблице управления идентификаторами
SELECT MAXID FROM _1SUIDCTL WHERE TYPEID = (SELECT ID FROM [метаданные_справочника]);
Если значение в справочнике больше, необходимо вручную обновить _1SUIDCTL, установив значение MAXID на единицу больше текущего максимума. Это предотвратит конфликты при записи новых элементов.
Зависание на проверке логической целостности чаще всего связано с таблицей 1SCONST. Когда 1С проверяет справочник, она для каждого элемента анализирует историю его периодических реквизитов. Если в 1SCONST есть записи, ссылающиеся на несуществующие объекты (битые ссылки), или записи с некорректными датами, ТиИ может войти в бесконечный цикл.
Проанализируем ситуацию с неразрешенными ссылками в периодике. Если вы видите ошибки типа "Реквизит Подразделение. Значение на 01.04.02. Неразрешенная ссылка", это означает, что в таблице истории есть запись, но сам объект (Подразделение) был удален напрямую из SQL или пропал при неудачной реиндексации.
Для исправления можно воспользоваться прямым SQL-запросом для поиска "сирот" в периодике:
SELECT * FROM 1SCONST
WHERE OBJID = ' 2IV ' -- ID вашего элемента справочника
AND ID = (SELECT ID FROM [ID_реквизита_Подразделение]);
Если записей много и они не несут ценности (например, старая история за 2002 год), самым эффективным способом будет очистка истории этого реквизита для проблемных элементов. Это можно сделать как программно через объект Периодический, так и прямым удалением записей из 1SCONST по условию OBJID.
Еще одна причина зависания — нарушение иерархии или подчиненности. Рассмотрим ситуацию, когда элемент справочника считается подчиненным, но его владелец (PARENTEXT) указывает в "пустоту" или на объект другого типа. Проанализируем состояние подчиненного справочника КомплектацияМ с помощью 1С++ или прямого запроса:
SELECT
СпрПодчиненный.ID as [Элемент_ID],
СпрПодчиненный.PARENTEXT as [Владелец_ID]
FROM
$Справочник.КомплектацияМ As СпрПодчиненный
WHERE
СпрПодчиненный.PARENTEXT NOT IN (SELECT ID FROM $Справочник.Материалы);
Этот запрос выявит все записи, у которых владелец не существует в главной таблице (Материалы). Найденные битые записи необходимо либо удалить, либо назначить им корректного владельца.
Часто в старых базах, мигрировавших с типовой "Бухгалтерии", остаются хвосты в виде типовых операций, которыми никто не пользуется. ТиИ тратит огромное время на проверку их шаблонов в таблице 1SBLOB. Если в логах вы видите массу сообщений "Изменен шаблон типовой операции...", а сами операции вам не нужны, их проще полностью удалить через интерфейс программы. Это существенно ускорит процесс проверки логической целостности.
Рассмотрим рекомендации, которые помогут избежать подобных проблем в будущем:
1С++, которые выполняют прямые запросы. Это в десятки раз быстрее и не вызывает зависания всей системы.1Cv7.md без использования конфигуратора). Всегда выполняйте объединение конфигураций только штатными средствами.DBCC CHECKDB для проверки физической целостности таблиц и индексов на уровне сервера.Таким образом, мы выяснили, что зависание ТиИ в 1С 7.7 — это почти всегда следствие "грязных" данных в системных таблицах 1SCONST и _1SUIDCTL. Сочетая ручную очистку битых ссылок через SQL и программное исправление иерархии, можно восстановить работоспособность базы без радикальных мер.