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

При росте объема информационной базы 1С 7.7 (от 50 ГБ и выше) и увеличении объема оперативной памяти на сервере возникает вопрос о целесообразности миграции с 32-разрядных версий операционной системы и СУБД (например, Windows Server 2003 x86 и MS SQL Server 2005 x86) на 64-битные платформы (Windows Server x64 и MS SQL Server x64). Рассмотрим подробно, какие преимущества дает такой переход, с какими архитектурными ограничениями сталкивается 32-битный клиент 1С 7.7 и как правильно настроить серверную среду для максимальной производительности.

Преимущества перехода MS SQL Server на платформу x64

Основной выигрыш от перехода на 64-разрядную систему получает сервер баз данных. Проанализируем ключевые изменения в работе СУБД:

1. Отказ от механизма AWE и прямой доступ к RAM: В 32-разрядной архитектуре MS SQL Server для использования более 4 ГБ памяти вынужден задействовать механизм AWE (Address Windowing Extensions). Этот механизм позволяет расширять только буферный пул страниц данных (Buffer Pool). Все остальные структуры памяти СУБД (кэш планов выполнения запросов, память под пользовательские соединения, блокировки, сортировки и процедуры) жестко ограничены виртуальным адресным пространством процесса размером 2–3 ГБ. Переход на MS SQL Server x64 полностью снимает эти ограничения: СУБД адресует весь объем оперативной памяти напрямую без накладных расходов процессора на переключение окон адресации.
2. Кэширование больших баз данных: При наличии 32 ГБ RAM и базе объемом 50 ГБ 64-битный SQL Server сможет удерживать в оперативной памяти практически все активные индексы и часто запрашиваемые таблицы, что многократно снижает нагрузку на дисковую подсистему.
3. Стабильность операционной системы: 64-разрядная Windows не имеет проблем с исчерпанием пула системных дескрипторов (Kernel Memory Pool, Paged/Non-Paged Pool), что нередко приводит к зависаниям 32-разрядных серверов при большом количестве терминальных сессий или сетевых подключений.

Особенности и ограничения работы клиента 1С 7.7 на 64-битной ОС

Исполняемые файлы платформы 1С:Предприятие 7.7 (1cv7s.exe, 1cv7.exe) являются исключительно 32-разрядными приложениями. Выясним, как ведет себя клиентская часть в среде Windows x64:

1. Адресация памяти процессом 1С: По умолчанию 32-битный процесс в 64-битной Windows получает изолированное адресное пространство размером 2 ГБ. Исполняемые файлы 1С 7.7 изначально скомпилированы без поддержки флага IMAGE_FILE_LARGE_ADDRESS_AWARE. Если процесс сталкивается со сложными выборками и тяжелыми отчетами, он падает с ошибкой нехватки памяти при приближении к порогу 2 ГБ.
2. Использование флага Large Address Aware (LAA): Для расширения доступной процессу памяти до 4 ГБ в 64-битной ОС можно модифицировать заголовок исполняемого файла утилитой editbin с параметром /LARGEADDRESSAWARE. Однако при этом следует учитывать, что все используемые внешние компоненты (ВК) и библиотеки также должны корректно работать с адресами памяти выше 2 ГБ.
3. Настройка источников данных ODBC: Конфигурирование системных DSN для подключения к базе должно выполняться исключительно через 32-разрядную оснастку администратора источников данных, расположенную по пути C:\Windows\SysWOW64\odbcad32.exe, так как стандартная 64-битная оснастка не видна для 32-битного движка 1С.
4. Драйверы ключей защиты: На 64-разрядную операционную систему необходимо устанавливать специализированные 64-битные версии драйверов HASP/Sentinel SRM, так как старые 32-битные драйверы не поддерживаются ядром x64.

Совместимость 1С 7.7 с новыми версиями MS SQL Server

Разберем важные нюансы взаимодействия платформы 1С 7.7 с MS SQL Server 2005/2008 x64:

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

Рекомендации по оптимизации дисковой подсистемы и СУБД

Помимо обновления процессоров и оперативной памяти, для базы объемом 50 ГБ критически важно устранить дисковые узкие места:

1. Отказ от RAID 5: Массив RAID 5 создает значительные задержки при операциях записи (штраф на запись — write penalty). Для высоконагруженных баз 1С рекомендуется перевод дисковой подсистемы на массивы RAID 10 или быстрые SSD/SAS-накопители.
2. Разнесение файлов БД: Файл данных (.mdf), файл журнала транзакций (.ldf) и системную базу tempdb необходимо физически разносить по разным дисковым массивам.
3. Настройка tempdb: Базу tempdb следует предварительно расширить до фиксированного размера, чтобы исключить фрагментацию при динамическом росте, а также разделить на несколько файлов данных одинакового размера (по числу физических ядер процессора).
4. Применение прямых запросов: Для баз объемом от 50 ГБ эффективным способом повышения быстродействия является перевод ресурсоемких отчетов и расчетов на механизмы прямых SQL-запросов (минуя стандартный транслятор DB-DMO платформы 7.7), что позволяет максимально загрузить мощности 64-битного SQL Server.