При обслуживании и настройке платформы 1С 7.7 на базе MS SQL Server часто возникают вопросы о правильном расположении файлов данных (.mdf) и журналов транзакций (.ldf), а также о целесообразности перехода обратно на файловый режим (.dbf). Разберем подробнее, как расположение системных файлов влияет на быстродействие, с какими рисками можно столкнуться при возврате на DBF и как правильно оптимизировать работу клиент-серверной 1С 7.7.
Размещение файлов базы данных на сервере напрямую влияет на отказоустойчивость и производительность дисковой подсистемы. Проанализируем основные правила по выравниванию нагрузки:
.mdf) и журнал транзакций (.ldf) рекомендуются к размещению на разных физических дисковых накопителях (или на независимых RAID-массивах). Это снижает конкуренцию за операции ввода-вывода (I/O), так как файл базы подвержен случайному чтению и записи, а журнал транзакций заполняется последовательно.D:\SQLData\ и E:\SQLLogs\) и избегать кириллических символов в именах папок, чтобы исключить ошибки системных служб..mdf и .ldf находятся в одной папке на одном диске, сам по себе их перенос в другое место без модификации дисковой подсистемы или настройки самой 1С 7.7 не даст ощутимого прироста скорости. Если вся база размещена на локальном сервере с единым SSD/NVMe-диском, разница в скорости записи/чтения будет минимальной.Иногда возникает желание вернуть базу 1С 7.7 в файловый формат (.dbf), так как некоторые откладываемые расчеты и выборки стандартным механизмом 1С 7.7 выполняются в DBF быстрее. Однако здесь скрываются серьезные технические ограничения:
.dbf) или индекса (.cdx) — 2 147 483 647 байт (2 ГБ). При превышении этого порога база теряет работоспособность, разрушаются индексы и возникают фатальные ошибки SDBF..cdx из-за наличия сложных составных индексов. Самые уязвимые файлы при активном росте — 1SENTRY.dbf/cdx (проводки), 1SBKTTL.dbf (бухгалтерские итоги), 1SBLOB.dbf (длинные тексты и картинки), а также таблицы регистров накопления RA* и RG*.kernel33.dll) лишь временно отдвигает проблему, но не гарантирует целостность данных при сбоях сети или выключении питания.Медленная работа 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):
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, но работает в стабильном клиент-серверном режиме.