При эксплуатации информационных баз 1С:Предприятие объемом более 5–7 Гб на бесплатной редакции MS SQL Server Express системные администраторы и программисты нередко сталкиваются с падением производительности, зависанием сеансов пользователей и периодическими сбоями службы СУБД. Особенно остро проблема проявляется после установки объемных обновлений конфигурации (например, при переходе между релизами «Управление торговлей 11»). Разберем подробно внутренние механизмы СУБД, аппаратные ограничения редакции Express, влияние дисковой подсистемы и порядок действий для восстановления стабильной работы системы.
Аппаратные и лицензионные ограничения MS SQL Server Express
Проанализируем базовые технические лимиты, заложенные разработчиками Microsoft в бесплатную редакцию SQL Server Express, и их влияние на поведение платформы 1С:Предприятие 8.3:
Лимит оперативной памяти для пула буферов (Buffer Pool). Независимо от общего объема ОЗУ на физическом сервере (будь то 32 Гб или 128 Гб), экземпляр SQL Server Express может задействовать под кэш данных строго ограниченный объем: около 1024 Мб (в версиях 2012/2014) или до 1410 Мб (в версиях 2016 и новее). Когда размер активных рабочих данных (индексы, таблицы итогов, временные таблицы) превышает 1 Гб, СУБД вынуждена непрерывно вытеснять страницы из памяти и считывать их заново с физического диска, что вызывает задержки ввода-вывода (I/O) и зависание клиентских сессий.
Лимит размера файла данных. Ограничение в 10 Гб распространяется строго на каждый отдельный файл данных (.mdf/.ndf). Файлы журнала транзакций (.ldf) в этот лимит не входят. При приближении базы к порогу 10 Гб СУБД не может расширить файл и блокирует любые операции записи, выдавая критическую ошибку.
Лимит процессорных ресурсов. Движок Express использует наименьшее из значений: 1 физический сокет или 4 ядра CPU. При одновременной работе нескольких активных пользователей и параллельном выполнении фоновых заданий 1С процессорные очереди переполняются.
Влияние свободного места на системном диске и базы tempdb
Рассмотрим частую системную ошибку: размещение всех служебных файлов на системном разделе C: при критически малом остатке свободного места. Если свободного пространства на диске остается менее 10–15%, возникает каскадный сбой производительности:
Переполнение базы tempdb. В процессе реструктуризации таблиц при обновлении 1С, а также при выполнении сложных запросов с группировками и соединениями платформа активно создает временные таблицы в системной базе tempdb. Если tempdb расположена на диске C:, где осталось всего 1–2 Гб, файл данных временной базы не может увеличиться (Autogrowth завершается ошибкой), и транзакция аварийно прерывается, приводя к падению подключения 1С к СУБД.
Фрагментация и замедление файловой системы NTFS. При падении объема свободного места на томе NTFS снижается эффективность кэширования метаданных и увеличивается фрагментация файла подкачки (pagefile.sys) и файлов СУБД, что многократно увеличивает время отклика диска.
Пошаговый план диагностики и устранения зависаний
Разберем по шагам регламент технических действий, необходимых для стабилизации базы 1С на SQL Server Express:
Проверка целостности базы данных после аварийного завершения обновления. Если в момент обновления произошел разрыв соединения или сбой СУБД, в структуре таблиц могли остаться незафиксированные изменения или разрушенные некластерные индексы. В среде SQL Server Management Studio (SSMS) выполним проверку целостности:
-- Проверка физической и логической целостности базы данных
DBCC CHECKDB ('ИмяВашейБазы') WITH NO_INFOMSGS, ALL_ERRORMSGS;
Если проверка завершилась без ошибок, дополнительно выполним «Тестирование и исправление» информационной базы в режиме 1С:Конфигуратор с установленными флагами проверки логической и ссылочной целостности, а также реиндексации таблиц.
Отключение скрытых параметров AUTO_CLOSE и AUTO_SHRINK. По умолчанию базы, созданные в Express-редакции, часто имеют включенный флаг AUTO_CLOSE. Это приводит к тому, что при отключении последнего пользователя СУБД полностью закрывает файлы базы и выгружает ее из памяти, а при новом подключении тратит несколько секунд на повторную инициализацию. Выполним команду:
ALTER DATABASE [ИмяВашейБазы] SET AUTO_CLOSE OFF;
ALTER DATABASE [ИмяВашейБазы] SET AUTO_SHRINK OFF;
Настройка параметров авторасширения файлов (Autogrowth). Зададим фиксированный прирост файлов вместо процентного, чтобы избежать чрезмерной фрагментации диска при записи новых данных:
Перенос служебных баз tempdb и файлов журнала на отдельный диск. Освободим системный диск C:, перенеся tempdb на более быстрый физический накопитель (например, отдельный SSD D:):
USE master;
GO
ALTER DATABASE tempdb
MODIFY FILE (NAME = tempdev, FILENAME = 'D:\SQLData\tempdb.mdf');
GO
ALTER DATABASE tempdb
MODIFY FILE (NAME = templog, FILENAME = 'D:\SQLData\templog.ldf');
GO
После выполнения скрипта перезапустим службу SQL Server для применения новых путей к файлам.
Организация регламентного обслуживания (обновление статистик). В SQL Server Express отсутствует служба SQL Server Agent, поэтому регламентные операции не выполняются автоматически. Без актуальной статистики оптимизатор SQL строит неоптимальные планы запросов (выполняя Table Scan вместо Index Seek), что перегружает диск и 1 Гб оперативной памяти. Настроим вызов регламентного скрипта через планировщик задач Windows (Task Scheduler) с помощью утилиты sqlcmd:
-- Скрипт обновления статистики для всех таблиц базы
USE [ИмяВашейБазы];
GO
EXEC sp_updatestats;
GO
Контроль процедур отложенного обновления 1С. В современных редакциях «Управление торговлей 11» после обновления метаданных запускаются фоновые задания постобработки данных (раздел «Администрирование» — «Обслуживание» — «Результаты обновления программы»). На ограниченных ресурсах SQL Express эти процедуры могут монополизировать таблицы, вызывая блокировки транзакций и видимость полного зависания программы. Рекомендуется запускать фоновую обработку обновления во внерабочее время при отключенных пользователях.
Рекомендации по дальнейшей эксплуатации
Если размер информационной базы превышает 7–8 Гб, использование SQL Server Express становится рискованным из-за жесткого лимита 10 Гб и нехватки 1 Гб RAM для кэширования индексов УТ 11. Для обеспечения надежности рассмотрим следующие альтернативы:
Переход на СУБД PostgreSQL. Свободно распространяемая СУБД без ограничений по размеру базы данных, объему используемой оперативной памяти и числу ядер процессора, официально поддерживаемая платформой 1С:Предприятие.
Переход на коммерческую редакцию MS SQL Server (Standard). Позволит полноценно использовать аппаратные мощности сервера и встроенный агент регламентных заданий.
Свертка информационной базы. Удаление документов прошлых периодов и ввод начальных остатков штатными средствами 1С для уменьшения объема файлов данных.