Каждый системный администратор и разработчик 1С рано или поздно сталкивается с ситуацией, когда после аварийного завершения обновления, скачка напряжения или сбоя СУБД база данных перестает запускаться. При попытке войти в Конфигуратор система выдает критическую ошибку: «Ошибка формата потока». При этом традиционная очистка локального кэша пользователя не приносит никаких результатов, а сама база данных может оказаться заблокированной на сервере СУБД.
В этой статье мы подробно разберем природу возникновения этой ошибки, рассмотрим эффективные методы ее устранения на уровне сервера приложений 1С и СУБД MS SQL Server, а также выясним, как правильно администрировать информационные базы в консоли кластера 1С, чтобы не терять журнал регистрации и не сталкиваться с сопутствующими ошибками файлового хранилища.
Прежде чем переходить к практическим действиям, давайте разберем физический смысл этой неполадки. Платформа «1С:Предприятие» хранит метаданные конфигурации в СУБД в виде структурированных бинарных и XML-данных (потоков). В процессе применения изменений (при нажатии кнопки «Принять изменения» или клавиши F7) платформа считывает, преобразует и записывает эти потоки обратно в базу.
Если в этот момент происходит сбой — отключается питание сервера, прерывается сетевое соединение с SQL-сервером или переполняется транзакционный лог СУБД, — процесс записи обрывается на середине. В результате структура потока данных оказывается нарушенной (незакрытые XML-теги, битые бинарные заголовки). При следующей попытке запуска Конфигуратор пытается десериализовать эти данные, не может распознать структуру и выдает ошибку формата потока, аварийно завершая работу.
Рассмотрим по шагам все возможные способы решения этой проблемы — от простых к продвинутым.
Прежде чем приступать к операциям на SQL-сервере, нам необходимо полностью исключить влияние поврежденного кэша метаданных. Кэш может сохранять битые структуры конфигурации, даже если сама СУБД уже исправна.
Для очистки локального кэша пользователя выполним следующие действия:
1cv8.exe и 1cv8c.exe через Диспетчер задач.%userprofile%\AppData\Local\1C\1cv8%userprofile%\AppData\Roaming\1C\1cv82a4b56c7-890d-123e-4f56-7890abcdef12). Это временные файлы метаданных конфигураций.Если локальная очистка не помогла, велика вероятность, что битый кэш зафиксировался на стороне сервера приложений 1С. Выполним очистку серверного кэша:
1C:Enterprise 8.3 Server Agent (или имя службы ragent).C:\Program Files\1cv8\srvinfo.reg_1541) найдем каталог с уникальным идентификатором (UUID) нашей проблемной базы данных.snccntry.db, v8system.db и т.д.). Внимание: ни в коем случае не удаляйте папку 1Cv8Log, так как именно в ней хранится журнал регистрации вашей информационной базы!Если очистка кэша не дала результатов, значит, повреждены сами таблицы конфигурации в базе данных SQL. В большинстве случаев сбой происходит в момент сохранения динамического обновления или во время подготовки к принятию изменений, когда данные записываются во временные таблицы СУБД.
Для восстановления работоспособности Конфигуратора мы можем очистить эти таблицы, заставив систему откатиться к последней стабильной версии конфигурации. Выполним следующие шаги в среде SQL Server Management Studio (SSMS):
USE [Имя_Вашей_Базы];
GO
-- Удаляем данные из таблицы сохраненной временной конфигурации
DELETE FROM [dbo].[configsave];
-- Очищаем таблицу конфигурации базы данных, подготовленной к обновлению
DELETE FROM [dbo].[dbcfgsave];
GO
После успешного выполнения этого запроса закроем SSMS и попробуем запустить Конфигуратор 1С. В подавляющем большинстве случаев после очистки таблицы configsave система успешно открывается, так как она игнорирует незавершенное битое обновление и загружает стабильную конфигурацию из основной таблицы config.
Что делать, если повреждение затронуло основную таблицу config, и предыдущий шаг не помог запустить Конфигуратор? В такой ситуации стандартные средства тестирования и исправления запустить невозможно. Однако у нас есть возможность перенести «здоровую» конфигурацию из вчерашней резервной копии (бэкапа) прямо на уровне СУБД, сохранив при этом все данные пользователей, которые они успели ввести за текущий день.
Разберем этот алгоритм подробно:
Base_Backup).Base_Work) нам необходимо полностью заменить поврежденную таблицу конфигурации аналогичной таблицей из резервной копии.
USE [Base_Work];
GO
-- Удаляем поврежденную таблицу основной конфигурации в рабочей базе
DROP TABLE [dbo].[config];
-- Копируем чистую таблицу конфигурации из восстановленной копии базы данных
SELECT * INTO [Base_Work].[dbo].[config] FROM [Base_Backup].[dbo].[config];
GO
Если после этого при запуске Конфигуратора платформа выдаст ошибку о несоответствии схемы базы данных, нам потребуется аналогичным образом обновить системную таблицу DBSchema:
USE [Base_Work];
GO
-- Удаляем старую схему данных
DROP TABLE [dbo].[DBSchema];
-- Копируем корректную схему данных из резервной копии
SELECT * INTO [Base_Work].[dbo].[DBSchema] FROM [Base_Backup].[dbo].[DBSchema];
GO
Этот метод позволяет полностью восстановить работоспособность Конфигуратора, не теряя ни единого документа или справочника, созданного пользователями в течение рабочего дня.
Платформа «1С:Предприятие» имеет встроенные механизмы командной строки для работы с конфигурацией в обход графического интерфейса. Мы можем попытаться выполнить принудительный откат к конфигурации базы данных (аналог команды «Вернуть к конфигурации БД» в меню Конфигуратора).
Для этого откроем командную строку Windows (cmd) от имени администратора и выполним следующую команду, подставив свои параметры подключения:
"C:\Program Files\1cv8\8.3.22.1709\bin\1cv8.exe" DESIGNER /S"ИмяСервера1С\ИмяИнформационнойБазы" /N"ИмяАдминистратора" /P"Пароль" /RollbackCfg
Параметр /RollbackCfg инициирует процедуру автоматического отката измененной конфигурации к последней работоспособной версии, сохраненной в таблице конфигурации базы данных. Если операция пройдет успешно, ошибка формата потока исчезнет.
В процессе восстановления баз данных администраторы часто сталкиваются с сопутствующими техническими трудностями, которые были упомянуты в обсуждении на форуме. Разберем их, чтобы не допускать критических ошибок в будущем.
Если после перезапуска SQL-сервера или аварийного сбоя вы видите в консоли SQL Server Management Studio, что рядом с именем базы данных отображается надпись (In Recovery), это означает, что СУБД выполняет автоматическую процедуру восстановления целостности транзакций (Crash Recovery).
В этот момент SQL-сервер считывает лог транзакций (файл формата .ldf):
.mdf), накатываются повторно (процесс Roll Forward).Важное правило: в процессе нахождения базы в статусе «In Recovery» она полностью заблокирована для любых подключений. Попытки запустить 1С или Конфигуратор будут завершаться ошибками соединения. Администратору необходимо просто дождаться окончания процесса. Время восстановления напрямую зависит от объема файла транзакций и производительности дисковой подсистемы.
Эта ошибка часто возникает при попытке удалить или очистить информационную базу через консоль администрирования серверов 1С. Она появляется из-за нарушения последовательности действий администратора:
Если вы сначала физически удалили базу данных непосредственно на SQL-сервере, а затем зашли в консоль администрирования 1С и попытались нажать «Удалить базу данных» или «Очистить базу данных», сервер 1С попытается обратиться к SQL-серверу для выполнения деинсталляции таблиц. Не найдя целевой базы данных на сервере СУБД, консоль 1С выдает ошибку синхронизации.
Проанализируем три режима удаления базы в консоли 1С, чтобы понимать разницу:
Правильное действие: если база данных уже удалена на стороне SQL-сервера, в консоли кластера 1С необходимо выбирать исключительно вариант «Оставить без изменений». Только в этом случае регистрационная запись сотрется корректно и без ошибок.
Журнал регистрации (ЖР) содержит всю историю действий пользователей и критически важен для аудита системы. При удалении информационной базы из кластера 1С и ее последующем пересоздании (даже под тем же именем) платформа генерирует для новой базы новый уникальный идентификатор (UUID).
Поскольку файлы журнала регистрации хранятся в каталоге сервера приложений 1С в папках, названных по UUID баз (C:\Program Files\1cv8\srvinfo\reg_1541\<UUID_базы>\1Cv8Log), при смене идентификатора старый журнал регистрации просто «теряется», и система начинает вести историю в новой пустой папке.
Выясним, как сохранить и перенести старый журнал регистрации на новую базу:
srvinfo\reg_1541.1Cv8Log (в котором содержатся файлы 1Cv8.lgd или файлы старого формата *.elf) в надежное временное место.ragent).1Cv8Log на наш ранее скопированный старый каталог журнала регистрации.После запуска вся история действий пользователей за предыдущие периоды будет полностью доступна в новой информационной базе.