Ситуация, когда после аварийного отключения электричества и последующей переустановки MS SQL Server привычные операции (такие как пересчет итогов через "Тестирование и исправление") начинают занимать часы вместо минут, является классическим индикатором проблем на уровне инфраструктуры или конфигурации СУБД. В данной статье мы подробно разберем, почему перенос базы на другой сервер решает проблему и как вернуть былую производительность основному серверу.
Первым делом проанализируем состояние аппаратной части. При внезапном отключении питания RAID-контроллер сервера может переключиться в режим безопасности. Если контроллер обнаруживает, что батарея (BBU) разряжена, повреждена или произошел некорректный сброс питания, он автоматически меняет политику кэширования записи с Write-back (запись с использованием кэша) на Write-through (запись непосредственно на диски).
Разница в производительности между этими режимами при массовых операциях записи (которыми и является пересчет итогов) может достигать 10–50 раз. Рассмотрим подробнее: в режиме Write-back подтверждение об успешной записи отправляется операционной системе сразу, как только данные попали в быстрый кэш контроллера. В режиме Write-through система ждет физического подтверждения от пластин жесткого диска. Выясним состояние контроллера через специализированные утилиты управления (например, HP Smart Storage Administrator или MegaRAID Storage Manager) и убедимся, что кэширование включено.
Пересчет итогов в 1С активно задействует временные таблицы. После переустановки MS SQL Server параметры базы tempdb часто сбрасываются к значениям по умолчанию, что создает "узкое горлышко". Разберем по шагам, как правильно настроить tempdb для работы с 1С:
tempdb равного размера. Рекомендуется устанавливать количество файлов равным количеству логических ядер процессора (но не более 8, если ядер больше).tempdb на самый быстрый доступный диск (желательно NVMe или SSD), отдельный от файлов основной базы данных.После аварийного завершения работы и "вылета" SQL Server статистика распределения данных в таблицах становится неактуальной. Оптимизатор запросов начинает строить неэффективные планы, что приводит к колоссальным задержкам. Проанализируем ситуацию: если SQL считает, что в таблице 100 строк, а на самом деле их миллион, он может выбрать метод сканирования вместо поиска по индексу.
Для исправления ситуации выполним принудительное обновление статистики для всей базы данных. Воспользуемся встроенной системной процедурой:
USE [Имя_Вашей_Базы];
GO
EXEC sp_updatestats;
Также крайне важно проверить уровень фрагментации индексов. После сбоев индексы могут быть повреждены или сильно фрагментированы, что замедляет чтение данных. Рекомендуется выполнить REBUILD или REORGANIZE основных таблиц итогов (таблицы с префиксами _AccumRegTotals).
По умолчанию после установки MS SQL Server параметр Max Degree of Parallelism установлен в значение 0. Это означает, что сервер пытается использовать все доступные ядра для выполнения одного тяжелого запроса. В архитектуре 1С это часто приводит к возникновению ожиданий типа CXPACKET — ситуации, когда одни потоки ждут завершения работы других, что фактически парализует работу.
Посмотрим на рекомендации: для систем, работающих с 1С, оптимальным значением MAXDOP является диапазон от 1 до 8 (в зависимости от общего количества ядер). Установка MAXDOP = 1 полностью отключает параллелизм для одного запроса, что часто делает работу 1С более стабильной и предсказуемой при выполнении регламентных операций.
Если автор темы заметил, что "логи перестали изменяться", это тревожный сигнал. Разберем возможные причины:
Для ускорения массовых операций, таких как пересчет итогов или тестирование и исправление, рекомендуется временно перевести базу в режим Simple. Это сократит объем записываемой в лог информации и предотвратит его бесконтрольный рост.
Часто упускаемый из виду момент — профиль электропитания Windows Server после переустановки. По умолчанию часто устанавливается режим "Сбалансированный". В этом режиме операционная система может снижать тактовую частоту процессора при отсутствии мгновенной пиковой нагрузки. Рассмотрим влияние: 1С выполняет многие операции последовательно (в один поток), и низкая частота процессора напрямую замедляет пересчет итогов.
Проанализируем настройки: перейдем в "Панель управления" -> "Электропитание" и выберем схему "Высокая производительность" (High Performance). Это гарантирует, что процессор всегда будет работать на максимальной частоте.
Если перенос базы через выгрузку/загрузку (файл .dt) помогает, значит, проблема могла быть в логической структуре. При выгрузке в .dt 1С переупорядочивает данные и не берет "лишний мусор" из таблиц итогов. Если же перенос осуществлялся через Detach/Attach файлов SQL, то проблема однозначно в настройках самого сервера SQL или операционной системы.
Рассмотрим использование команды DBCC CHECKDB для проверки физической целостности базы данных SQL. Это позволит исключить наличие битых страниц данных, которые могли появиться в момент резкого отключения питания:
DBCC CHECKDB ('Имя_Вашей_Базы') WITH NO_INFOMSGS, ALL_ERRORMSGS;
Если команда вернет ошибки, необходимо приступать к процедуре восстановления данных (например, REPAIR_ALLOW_DATA_LOSS), хотя лучшим вариантом будет восстановление из последнего исправного бэкапа перед сбоем.