В процессе администрирования клиент-серверных баз 1С можно столкнуться с ситуацией, когда при отмене проведения документов или выполнении регламентных операций платформа выдает сообщение о конфликте блокировок, даже если в информационной базе работает всего один пользователь. При этом тестирование и исправление (ТИИ) завершается аварийно, а попытка создания резервной копии средствами SQL Server Management Studio (SSMS) падает с ошибкой вида: «Превышено время ожидания типа кратковременной блокировки буфера 3 для страницы...». Разберем природу этого сбоя, проведем детальную диагностику и рассмотрим эффективные пошаговые методы восстановления работоспособности базы данных.
Проанализируем техническую суть происходящего. Ошибка таймаута защелки буфера (Buffer Latch Timeout, тип 3 — монопольная блокировка LATCH_EX) относится исключительно к уровню СУБД, а не к прикладным механизмам транзакционных блокировок платформы 1С. Поток SQL Server ожидает монопольного доступа к 8-килобайтной странице данных в оперативной памяти более 300 секунд. Когда этот таймер истекает, операция аварийно прерывается, а платформа 1С интерпретирует зависший поток СУБД как обычный конфликт блокировок.
Выясним основные причины возникновения такой неполадки:
Прежде чем приступать к восстановлению, определим конкретный поврежденный объект базы данных. Для этого проанализируем журнал ошибок SQL Server (ERRORLOG):
844 или 845, а также предупреждения о задержках ввода-вывода (requests taking longer than 15 seconds to complete).(1:123456).
DBCC CHECKDB ('ИмяБазы') WITH NO_INFOMSGS, ALL_ERRORMSGS;
Результат команды покажет, где именно локализована ошибка — в некластеризованном индексе или в самих строках таблицы данных.
Если штатное резервное копирование прерывается ошибкой защелки буфера, выполним снятие аварийного дампа с директивой пропуска поврежденных страниц. Это позволит зафиксировать текущее состояние базы для дальнейших экспериментов на тестовом сервере:
BACKUP DATABASE [ИмяБазы]
TO DISK = 'D:\Backup\Emergency_Backup.bak'
WITH CONTINUE_AFTER_ERROR;
После создания копии восстановим ее на отдельном тестовом контуре, чтобы не подвергать риску рабочие данные при аварийных операциях.
Рассмотрим варианты исправления ситуации в зависимости от характера повреждения:
DBCC CHECKDB выявила повреждение только в индексах, выполним их перестроение без потери данных:
USE [ИмяБазы];
ALTER INDEX ALL ON [ИмяПоврежденнойТаблицы] REBUILD;
.dt или перенос данных через универсальную выгрузку/загрузку XML в чистую конфигурацию. Если ошибка возникает при обращении к конкретному регистру или документу, можно добавить временный реквизит в проблемный объект в дереве метаданных 1С и применить изменения — это запустит процедуру реструктуризации таблицы на уровне платформы.
ALTER DATABASE [ИмяБазы] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DBCC CHECKDB ('ИмяБазы', REPAIR_ALLOW_DATA_LOSS);
ALTER DATABASE [ИмяБазы] SET MULTI_USER;
Чтобы исключить повторение подобных конфликтов и сбоев защелок буфера в будущем, выполним комплекс превентивных системных настроек:
Perform volume maintenance tasks («Выполнение задач по обслуживанию томов») в локальных политиках безопасности Windows. Это устранит зависания СУБД при расширении файлов данных.tempdb. Создадим несколько файлов данных tempdb одинакового размера (по количеству физических ядер процессора, но не более 8) и разместим их на отдельном высокоскоростном SSD/NVMe массиве.