При росте объема информационной базы 1С:Предприятие 7.7 свыше 30 Гб и увеличении числа активных пользователей компании неизбежно сталкиваются с аппаратными и программными ограничениями 32-разрядных платформ. Разберем архитектурные нюансы модернизации сервера, переход на 64-разрядные СУБД, а также методы устранения деградации производительности при проведении документов.
Проанализируем базовую проблему конфигурации на базе 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 дает следующие преимущества:
Следует учитывать, что официальной 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 6.5, 7.0 и 2000. При попытке штатного подключения к более свежим редакциям СУБД возникают системные ошибки несовместимости. Разберем по шагам, как настроить окружение:
BkEnd.dll зашита проверка версии SQL Server. Для работы с SQL 2005+ администраторы используют пропатченные библиотеки или внешние загрузчики, снимающие данное ограничение.OrdNoChk.prm и помещаем его в каталог информационной базы либо в каталог BIN исполняемых файлов платформы 1С 7.7.80 (SQL Server 2000).Частая проблема в сильно кастомизированных базах 1С 7.7 — резкое замедление работы при массовом проведении документов (например, при восстановлении последовательности или закрытии месяца). Каждый последующий проведенный документ рассчитывает остатки по регистрам все дольше из-за устаревания статистических данных в таблицах итогов.
Выясним причину: оптимизатор запросов СУБД строит неоптимальные планы выполнения, когда в таблицы непрерывно добавляются сотни новых записей, а статистика распределения данных не обновляется. Решим эту проблему следующими методами:
EXEC sp_updatestats;
Во время интенсивных пакетных расчетов или восстановления последовательности запуск пересчета статистики можно выполнять с интервалом раз в 1–2 часа.
ALTER INDEX ALL ON _1SJOURN REBUILD;
Shared Memory кардинально сокращает сетевые задержки.Рассмотрим аппаратные нюансы при выборе серверного железа для 1С 7.7:
.mdf), файл журнала транзакций (.ldf) и системную базу tempdb по разным физическим дисковым массивам. Для базы tempdb следует задать фиксированный начальный размер и отключить частый малый шаг автоувеличения.Если штатных оптимизаций на уровне СУБД недостаточно, а свертка базы невозможна из-за сильной модификации конфигурации, эффективным решением становится внедрение внешних технологических компонент (например, 1С++). Это позволяет переписать проблемные узкие места (тяжелые отчеты, пакетное списание партий) на прямые T-SQL запросы в обход медленного объектного интерфейса 1С 7.7, сокращая время выполнения тяжелых операций в десятки раз.