Стоит ли переносить базу 1С 7.7 на 64-битный сервер и как оптимизировать работу с MS SQL Server?

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

При росте объема информационной базы 1С:Предприятие 7.7 свыше 30 Гб и увеличении числа активных пользователей компании неизбежно сталкиваются с аппаратными и программными ограничениями 32-разрядных платформ. Разберем архитектурные нюансы модернизации сервера, переход на 64-разрядные СУБД, а также методы устранения деградации производительности при проведении документов.

Архитектурные ограничения 32-битной платформы и преимущества перехода на x64

Проанализируем базовую проблему конфигурации на базе 32-битной операционной системы (например, Windows Server 2003 32-bit) и СУБД MS SQL Server 2000. В 32-разрядном адресном пространстве операционная система не способна эффективно адресовать более 4 Гб физической памяти, а на один процесс (включая процесс СУБД) по умолчанию выделяется не более 2 Гб виртуального адресного пространства. При объеме базы данных в несколько десятков гигабайт СУБД не может кэшировать активные таблицы и индексы в оперативной памяти, что приводит к постоянному чтению с медленных накопителей и образованию очередей дисковой подсистемы.

Переход на 64-разрядную операционную систему (Windows Server 2003 R2 x64, Windows Server 2008 R2 x64 или новее) и MS SQL Server 2005/2008 x64 дает следующие преимущества:

  1. Снятие ограничений по памяти: 64-битный процесс СУБД может задействовать весь объем доступной серверной памяти (ECC RAM), удерживая в буферном пуле (Buffer Pool) рабочие таблицы и часто используемые индексы.
  2. Ускорение обработки тяжелых отчетов: Сложные расчеты, выборки и группировки перестают упираться в лимит 2 Гб на процесс.
  3. Стабильность при конкурентной работе: При одновременной работе 20–30 пользователей СУБД эффективнее распределяет потоки и кэширует планы выполнения запросов.

Следует учитывать, что официальной 64-битной версии MS SQL Server 2000 для архитектуры x86-64 (AMD64/Intel 64) не существовало (выпускалась только редакция под архитектуру IA-64 Itanium). Поэтому для перехода на платформу x64 минимальным решением является использование MS SQL Server 2005 Standard/Enterprise x64.

Особенности подключения 1С 7.7 к MS SQL Server 2005 и выше

Платформа 1С 7.7 изначально разрабатывалась для работы с СУБД MS SQL Server 6.5, 7.0 и 2000. При попытке штатного подключения к более свежим редакциям СУБД возникают системные ошибки несовместимости. Разберем по шагам, как настроить окружение:

  1. Обход встроенной проверки версии СУБД: В библиотеке платформы BkEnd.dll зашита проверка версии SQL Server. Для работы с SQL 2005+ администраторы используют пропатченные библиотеки или внешние загрузчики, снимающие данное ограничение.
  2. Отключение проверки порядка сортировки: При подключении к базам на SQL 2005+ платформа выдает критическую ошибку: «Порядок сортировки, установленный для базы данных, отличается от системного». Для ее подавления создаем пустой текстовый файл-маркер с именем OrdNoChk.prm и помещаем его в каталог информационной базы либо в каталог BIN исполняемых файлов платформы 1С 7.7.
  3. Уровень совместимости базы данных: В свойствах базы данных на сервере MS SQL Server необходимо установить параметр Compatibility Level (уровень совместимости) в значение 80 (SQL Server 2000).

Борьба с деградацией производительности при проведении документов

Частая проблема в сильно кастомизированных базах 1С 7.7 — резкое замедление работы при массовом проведении документов (например, при восстановлении последовательности или закрытии месяца). Каждый последующий проведенный документ рассчитывает остатки по регистрам все дольше из-за устаревания статистических данных в таблицах итогов.

Выясним причину: оптимизатор запросов СУБД строит неоптимальные планы выполнения, когда в таблицы непрерывно добавляются сотни новых записей, а статистика распределения данных не обновляется. Решим эту проблему следующими методами:

  1. Регулярное обновление статистики: В среде MS SQL Server необходимо настроить выполнение регламентной процедуры обновления статистики. Запускаем процедуру обновления командой: EXEC sp_updatestats; Во время интенсивных пакетных расчетов или восстановления последовательности запуск пересчета статистики можно выполнять с интервалом раз в 1–2 часа.
  2. Перестроение и дефрагментация индексов: Таблицы регистров и документов при постоянной вставке подвержены высокой фрагментации. Регулярный запуск обслуживания индексов восстанавливает их производительность: ALTER INDEX ALL ON _1SJOURN REBUILD;
  3. Разгрузка сетевого трафика через терминальный сервер (RDP): Запуск 1С 7.7 в файлово-сетевом режиме по локальной сети порождает паразитный трафик при чтении служебных файлов метаданных. Перевод пользователей в терминальный режим на серверной ОС с обменом данными через Shared Memory кардинально сокращает сетевые задержки.

Аппаратные требования: процессорная частота и дисковая подсистема

Рассмотрим аппаратные нюансы при выборе серверного железа для 1С 7.7:

  1. Производительность на одно ядро: Движок 1С 7.7 выполняет пользовательские расчеты строго в один поток на клиенте. Многоядерные серверные процессоры с низкой базовой частотой (например, старые Xeon с частотой 2.0–2.3 ГГц) могут показать скорость проведения отдельных документов ниже, чем десктопные процессоры с высокой частотой на ядро. Поэтому при выборе оборудования критически важна высокая тактовая частота и современная микроархитектура процессора.
  2. Организация дисков: Базы данных SQL крайне чувствительны к скорости случайного чтения и записи (IOPS). Массив RAID 10 из классических SAS/SATA HDD обеспечивает отказоустойчивость, однако твердотельные накопители (SSD) серверного класса дают многократный прирост за счет минимального времени отклика.
  3. Разделение файлов СУБД: Рекомендуется физически разделять файл данных базы (.mdf), файл журнала транзакций (.ldf) и системную базу tempdb по разным физическим дисковым массивам. Для базы tempdb следует задать фиксированный начальный размер и отключить частый малый шаг автоувеличения.

Использование прямых запросов для тяжелых участков

Если штатных оптимизаций на уровне СУБД недостаточно, а свертка базы невозможна из-за сильной модификации конфигурации, эффективным решением становится внедрение внешних технологических компонент (например, 1С++). Это позволяет переписать проблемные узкие места (тяжелые отчеты, пакетное списание партий) на прямые T-SQL запросы в обход медленного объектного интерфейса 1С 7.7, сокращая время выполнения тяжелых операций в десятки раз.

← На главную