Где должны находиться файлы базы данных MS SQL (*.mdf и *.ldf) и как оптимизировать производительность 1С 7.7?

Программист 1С v7.7 IT и автоматизация бизнеса
← На главную

При обслуживании и настройке платформы 1С 7.7 на базе MS SQL Server часто возникают вопросы о правильном расположении файлов данных (.mdf) и журналов транзакций (.ldf), а также о целесообразности перехода обратно на файловый режим (.dbf). Разберем подробнее, как расположение системных файлов влияет на быстродействие, с какими рисками можно столкнуться при возврате на DBF и как правильно оптимизировать работу клиент-серверной 1С 7.7.

Правильное расположение файлов базы данных MS SQL

Размещение файлов базы данных на сервере напрямую влияет на отказоустойчивость и производительность дисковой подсистемы. Проанализируем основные правила по выравниванию нагрузки:

  1. Разделение на разные физические диски: Главный файл данных (.mdf) и журнал транзакций (.ldf) рекомендуются к размещению на разных физических дисковых накопителях (или на независимых RAID-массивах). Это снижает конкуренцию за операции ввода-вывода (I/O), так как файл базы подвержен случайному чтению и записи, а журнал транзакций заполняется последовательно.
  2. Пути к файлам и латиница: Файлы базы данных не следует хранить в глубинках файловой структуры или в каталоге самой конфигурации 1С. Лучше располагать их ближе к корню диска (например, D:\SQLData\ и E:\SQLLogs\) и избегать кириллических символов в именах папок, чтобы исключить ошибки системных служб.
  3. Влияние переноса файлов: Если файлы .mdf и .ldf находятся в одной папке на одном диске, сам по себе их перенос в другое место без модификации дисковой подсистемы или настройки самой 1С 7.7 не даст ощутимого прироста скорости. Если вся база размещена на локальном сервере с единым SSD/NVMe-диском, разница в скорости записи/чтения будет минимальной.

Опасности и ограничения при откате на DBF-версию

Иногда возникает желание вернуть базу 1С 7.7 в файловый формат (.dbf), так как некоторые откладываемые расчеты и выборки стандартным механизмом 1С 7.7 выполняются в DBF быстрее. Однако здесь скрываются серьезные технические ограничения:

  1. Предел размера файла в 2 ГБ: Формат DBF и встроенный движок CodeBase в 1С 7.7 имеют жесткий предел на размер одного файла таблицы (.dbf) или индекса (.cdx) — 2 147 483 647 байт (2 ГБ). При превышении этого порога база теряет работоспособность, разрушаются индексы и возникают фатальные ошибки SDBF.
  2. Индексные файлы заполняются быстрее: Часто критическую отметку первой пересекает не сама таблица с данными, а соответствующий ей файл индексов .cdx из-за наличия сложных составных индексов. Самые уязвимые файлы при активном росте — 1SENTRY.dbf/cdx (проводки), 1SBKTTL.dbf (бухгалтерские итоги), 1SBLOB.dbf (длинные тексты и картинки), а также таблицы регистров накопления RA* и RG*.
  3. Порог нестабильности: В реальной эксплуатации проблемы с чтением и индексацией в файловом режиме начинают проявляться уже при достижении файлом объема в 1–1.2 ГБ. Использование сторонних утилит или пропатченных библиотек (вроде kernel33.dll) лишь временно отдвигает проблему, но не гарантирует целостность данных при сбоях сети или выключении питания.

Как оптимизировать быстродействие 1С 7.7 на MS SQL Server

Медленная работа 1С 7.7 на SQL обусловлена тем, что стандартный штатный генератор запросов платформы создает тяжелые и неоптимальные T-SQL конструкции, а также интенсивно использует временные таблицы. Чтобы добиться комфортной работы пользователей без отката на DBF, рассмотрим комплекс проверенных настроек:

1. Настройка базы TempDB

Так как 1С 7.7 генерирует огромное количество временных таблиц, база TempDB становится бутылочным горлышком. Необходимо разбить TempDB на несколько файлов данных одинакового размера (по количеству логических ядер процессора, но не более 8) и перенести их на самый быстрый доступный накопитель.

2. Изменение параметров авторасширения (Autogrowth)

Выясним причину подвисаний при проведении документов: по умолчанию MS SQL увеличивает размер файлов .mdf и .ldf в процентах. В этот момент выполнение любых транзакций замораживается. Необходимо установить фиксированный прирост файлов в мегабайтах (например, по 200–500 МБ) или предварительно выделить файлам базы необходимый объем с запасом.

3. Ограничение степени параллелизма (MAXDOP)

Для 1С 7.7 исполнение запросов в несколько потоков часто приводит к взаимным блокировкам таблиц. На уровне сервера MS SQL Server рекомендуется установить параметр Max Degree of Parallelism (MAXDOP) равным 1.

4. Регулярный пересчет статистики и дефрагментация

Обязательно настройте регламентные обслуживания базы данных в SQL Server Management Studio (SSMS):

  1. Регулярное перестроение и дефрагментация индексов (Rebuild / Reorganize Index).
  2. Обновление статистики с полным сканированием таблиц (UPDATE STATISTICS WITH FULLSCAN). Без актуальной статистики SQL Server выбирает ошибочные планы выполнения запросов.

5. Модель восстановления Simple

Если для базы не требуется посекундное восстановление данных, переведите модель восстановления (Recovery Model) из `FULL` в `SIMPLE`. Это предотвратит непрерывное разрастание файла журнала .ldf и снизит нагрузку на диск при массовом проведении документов.

6. Использование прямого SQL-доступа и альтернатив

Для ускорения тяжелых отчетов и обработки данных в 1С 7.7 рекомендуется переходить на прямые запросы к базе данных (с использованием внешних компонентов 1CPP, DirectDB или ADODB), минуя штатный движок платформы. Если переработка кода невозможна, а файловый режим необходим из-за особенностей конфигурации, отличной альтернативой является перевод базы на Advantage Database Server (ADS), который сохраняет структуру DBF, но работает в стабильном клиент-серверном режиме.

← На главную