Подготовка к работе

Для стабильной и эффективной работы баз данных 1С в среде IBM DB2 крайне важно не забыть установить переменную DB2_WORKLOAD в значение 1С с помощью команды db2set:

db2set DB2_WORKLOAD=1C

После установки данной настройки необходимо перезапустить DB2, например, командами:

db2stop
db2start

Данная настройка автоматически устанавливает ряд других параметров,  IBM DB2, необходимых для корректного функционирования 1С.

Создание баз данных затем производится из интерфейса 1С путем ввода параметров базы данных и установки признака «Создать базу данных в случае её отсутствия».

В целом первоначальные действия по подготовке к работе хорошо описаны в следующей статье.

 

Автоматическое управление табличными пространствами

Текущие версии 1С не используют функционал IBM DB2 по автоматическому управлению размещением данных. В то же время использование автоматически управляемых табличных пространств обеспечивает более удобное администрирование, а в версиях IBM DB2 начиная с 10.1 — позволяет переносить данные табличных пространств между устройствами хранения без приостановки пользовательского доступа к базе данных.

Существует стандартный документированный процесс перехода на автоматическое управление размещением данных. Этот процесс выполняется в следующем порядке:

1. Табличное пространство помечается как автоматически управляемое
2. Выполняется перенос информации в новый (автоматически управляемый) контейнер через операцию перебалансировки
3. Выполняется ожидание завершения операции перебалансировки, контролируя её выполнение по диагностическому протоколу

Наиболее эффективно перевод базы данных 1С на автоматическое управление размещением данных производится сразу после её создания, до загрузки данных. В этом случае загрузка данных будет выполняться уже в новые (автоматически управляемые) контейнеры, что минимизирует затраты времени и ресурсов на выполнение переноса данных из старых контейнеров в новые.

Для перевода базы данных 1С на автоматическое управление размещением данных может быть использован следующий набор команд:

1. Перенос основных табличных пространств

db2 alter tablespace V81C_INDEXSPACE managed by automatic storage
db2 alter tablespace V81C_INDEXSPACE rebalance
db2 alter tablespace V81C_LARGESPACE managed by automatic storage
db2 alter tablespace V81C_LARGESPACE rebalance
db2 alter tablespace V81C_LOBSPACE managed by automatic storage
db2 alter tablespace V81C_LOBSPACE rebalance
db2 alter tablespace SYSCATSPACE managed by automatic storage
db2 alter tablespace SYSCATSPACE rebalance

2. Перенос временных табличных пространств

db2 drop tablespace V81C_USERTEMP
db2 create user temporary tablespace V81C_USERTEMP pagesize 32 K managed by automatic storage bufferpool V81C_USERTEMPBP no file system caching
db2 create system temporary tablespace V81C_TEMPSPACE2 pagesize 32 K managed by automatic storage bufferpool V81C_SYSTEMPBP
db2 drop tablespace V81C_TEMPSPACE
db2 create system temporary tablespace V81C_TEMPSPACE pagesize 32 K managed by automatic storage bufferpool V81C_SYSTEMPBP no file system caching
db2 drop tablespace V81C_TEMPSPACE2

Обратите внимание, что перечисленные выше команды создают новые временные системное и пользовательское табличные пространства на устройствах, используемых по умолчанию базой данных DB2. Для размещения временных табличных пространств на более быстрых дисках отдельно от остальных данных необходимо либо явно указать пути для хранения данных (см. ниже раздел «Работа с временными таблицами»), либо, при использовании DB2 версии 10.1 и выше, создать дополнительную группу хранения данных (STORAGE GROUP) и разместить временные табличные пространства в ней.

Настройка автоматического управления распределением оперативной памяти 

Распределение оперативной памяти между различными рабочими областями СУБД IBM DB2 целесообразно предоставить Self-Tuning Memory Manager (STMM). В большинстве случаев STMM корректно активируется при создании базы данных средствами 1С.

При проведении экспериментов был выявлен один случай, когда STMM не был корректно активирован, а вместо этого были установлены фиксированные (совершенно недостаточные) размеры буферных пулов и других рабочих областей. При возникновении сомнений в корректной настройке STMM необходимо проверить его настройки в соответствии с процедурой, изложенной ниже в разделе «Дополнительные действия: Проверка настроек STMM».

Настройка объема использования оперативной памяти

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

Вычисленный объем оперативной памяти для работы сервера СУБД пересчитывается в количество страниц по 4096 байт (4 КиБ), и полученное значение устанавливается в значение конфигурационного параметра экземпляра DB2 INSTANCE_MEMORY командой UPDATE DBM CFG. Автоматическое управление параметром INSTANCE_MEMORY не рекомендуется. 

Оптимальный объем оперативной памяти для использования сервером СУБД должен позволять разместить в оперативной памяти все наиболее частые используемые данные (в зависимости от типовой нагрузки), плюс все рабочие области (включая области сортировки данных и временные таблицы). Оценка достаточности объема оперативной памяти может произведена путем наблюдения за эффективностью кэширования данных буферных пулов и сортировками (например, с помощью команды db2pd). 

Использование оперативной памяти отдельными базами данных в рамках экземпляра регулируется параметром DATABASE_MEMORY для каждой из баз данных, устанавливаемого командой UPDATE DB CFG. Сумма значений данных параметров для всех активных в конкретный момент времени баз данных должна быть меньше заданного значения параметра INSTANCE_MEMORY. Рекомендуется включить автоматическую настройку параметра DATABASE_MEMORY для всех баз данных. В случае наличия единственной либо основной постоянно активной базы данных в экземпляре первоначальное значение параметра DATABASE_MEMORY может быть выставлено, например, в 75% значения параметра INSTANCE_MEMORY.

Рекомендуется также установить параметр DB_MEM_THRESH в значение 100 для исключения излишних операций по освобождению и последующему занятию сервером СУБД оперативной памяти. Данная настройка исключает освобождение (возврат операционной системе) временно не используемой памяти сервера СУБД, тем самым снижая фрагментацию памяти и нагрузку на процессоры.

Использование оперативной памяти приложениями

При проведении тестирования с высокими нагрузками, а также в больших производственных конфигурациях иногда наблюдаются сбои, вызванные нехваткой оперативной памяти, используемой для работы приложений (application heap). Внешними признаками сбоев является диагностика об ошибках SQL0954C в журнале СУБД, а также аналогичная диагностика приложений. 

Такие ситуации иногда происходят даже несмотря на наличие достаточного объема свободной оперативной памяти и при активированном и корректно настроенном STMM. Причиной таких ошибок являются задержки срабатывания STMM на фоне интенсивного роста использования соответствующих областей оперативной памяти. 

В случае возникновения соответствующих ошибок рекомендуется увеличить первоначальные значения параметров базы данных APPLHEAPSZ и APPL_MEMORY, например:

db2 update db cfg using appl_memory 65536 automatic
db2 update db cfg using applheapsz 2048 automatic

Указанные в приведенных выше командах значения параметров были использованы в проводившихся тестах и исключили появление соответствующих ошибок.

Работа с временными таблицами

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

Перенос пользовательского и системного временных табличных пространств осуществляется путем удаления существующих (созданных в ходе создания базы данных средствами 1С) временных табличных пространств и создания новых, размещенных на других дисках. Удалить существующее системное временное табличное пространство не удастся до того, как будет создано новое системное временное табличное пространство с аналогичным размером страницы. 

По результатам экспериментов было обнаружено, что временные табличные пространства SMS (System Managed Space) в большинстве случаев обеспечивают более высокую производительность по сравнению с временными табличными пространствами DMS (Database Managed Space), создаваемых по умолчанию средствами 1С. Статус поддержки таких конфигураций со стороны 1С на данный момент до конца не ясен, однако со стороны DB2 никаких функциональных отличий для приложений изменение организации табличных пространств не несёт. 

Пример набора команд для перемещения и изменения организации (DMS => SMS) временных табличных пространств: 

C:> db2
db2 => CONNECT TO pdb2n1
db2 => DROP TABLESPACE "V81C_USERTEMP"
db2 => CREATE USER TEMPORARY TABLESPACE "V81C_USERTEMP" PAGESIZE 32 K MANAGED BY SYSTEM USING ('D:DB2TEMPPDB2N1V81C_USERTEMP_DAT') BUFFERPOOL "V81C_USERTEMPBP" NO FILE SYSTEM CACHING
db2 => CREATE SYSTEM TEMPORARY TABLESPACE "V81C_TEMPSPACE2" PAGESIZE 32 K MANAGED BY AUTOMATIC STORAGE BUFFERPOOL "V81C_SYSTEMPBP" NO FILE SYSTEM CACHING
db2 => DROP TABLESPACE "V81C_TEMPSPACE"
db2 => CREATE SYSTEM TEMPORARY TABLESPACE "V81C_TEMPSPACE" PAGESIZE 32 K MANAGED BY SYSTEM USING ('D:DB2TEMPPDB2N1V81C_TEMPSPACE_DAT') BUFFERPOOL "V81C_SYSTEMPBP" NO FILE SYSTEM CACHING
db2 => DROP TABLESPACE "V81C_TEMPSPACE2"
db2 => TERMINATE
C:>

В приведенных выше командах сперва (временно) создается табличное пространство V81C_TEMPSPACE2, которое необходимо, чтобы можно было пересоздать (удалить, затем создать с нужными параметрами) основное временное системное табличное пространство V81C_TEMPSPACE2.

При наличии большого объема оперативной памяти работа с временными данными может преимущественно осуществляться с использованием соответствующих буферных пулов — временного пользовательского (V81C_USERTEMPBP) и временного системного (V81C_SYSTEMPBP). Размером этих буферных пулов DB2 управляет автоматически, но практика показывает, что на системах с очень большим объемом оперативной памяти эта автоматика работает слишком консервативно. Для ускорения работы многих операций с временными данными даже без использования выделенных быстрых дисков можно (при достаточном объеме оперативной памяти) явно указать желаемый стартовый объем соответствующих буферных пулов:

db2 alter bufferpool V81C_USERTEMPBP size 32768 automatic

db2 alter bufferpool V81C_SYSTEMPBP size 65536 automatic

Размер буферных пулов в приведенных выше командах указан в количестве страниц, каждая из которых имеет размер 32 КиБ. 

 

Размер и размещение транзакционного журнала СУБД

После создания базы данных средствами 1С необходимо скорректировать установленные для базы данных параметры размера транзакционного журнала. Нехватка пространства журнала может проявиться (и проявляется на практике) как при первоначальной загрузке данных, так и при текущей работе пользователей, и приводит к отказам выполнения пользовательских транзакций.

Пример корректировки значений параметров размера транзакционного журнала:

• LOGFILSIZ 8192 – размер одного файла журнала 32 Мбайт;
• LOGPRIMARY 8 – постоянно используется 8 файлов журнала, общий объем 256 Мбайт;
• LOGSECOND 120 – при необходимости может быть создано до 120 дополнительных файлов журнала для обработки возможных разовых пиковых нагрузок (убедитесь в наличии достаточного дискового пространства, для данных значений 4 Гбайт).

Пример команд для корректировки размера транзакционного журнала:

db2 update db cfg using logfilsiz 8192
db2 update db cfg using logprimary 8
db2 update db cfg using logsecond 120

После выполнения приведенных выше команд необходимо закрыть и заново открыть базу данных (например, командами DEACTIVATE DATABASE и ACTIVATE DATABASE).

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

db2 update db cfg using newlogpath D:DB2LOGSPDB2N2

В приведенной выше команде подразумевается наличие SSD-диска D, на котором создан каталог DB2LOGSPDB2N2. Для переноса журналов после выполнения данной команды необходимо закрыть и повторно открыть базу данных.

Автоматическое обслуживание базы данных

Рекомендуемые параметры автоматического обслуживания базы данных соответствуют устанавливаемым по умолчанию при создании базы данных средствами 1С, и предполагают установку в значение ON следующих параметров: AUTO_MAINT, AUTO_TBL_MAINT, AUTO_RUNSTATS, AUTO_STMT_STATS, AUTO_REORG.

На период проведения тестов целесообразно отключить параметр AUTO_REORG, во избежание траты системных ресурсов на выполнение реорганизации таблиц.

Для больших конфигураций, в которых база данных хранит большие объемы информации, необходимо рассмотреть возможность включения параметра AUTO_SAMPLING, использование которого позволяет сократить затраты ресурсов по автоматическому сбору статистик для больших таблиц путем использования сбора статистики на случайно выбранном подмножестве страниц данных.

Также для больших и нагруженных баз данных целесообразно настроить окно выполнения регламентных заданий обслуживания базы данных (реорганизации, сбора статистик) с целью минимизации воздействия этих заданий на работу конечных пользователей. Наиболее просто соответствующие настройки выполнить с помощью IBM Data Studio.

 

Активация используемых баз данных

Во избежание лишних затрат времени на открытие и закрытие используемых баз данных рекомендуется явным образом открыть все используемые базы данных командой ACTIVATE DATABASE. Соответствующие операции можно включить в процедуру запуска системы на сервере СУБД (при использовании ОС Windows Server здесь возможны некоторые сложности, которые, тем не менее, вполне могут быть преодолены).

Если используемая база данных не была открыта предыдущими подключениями либо командой ACTIVATE DATABASE, при первой попытке подключения возможны задержки, вызванные инициализацией базы данных и возможными операциями восстановления целостности данных (например, после аварийного выключения сервера). Явное открытие базы данных позволит избежать соответствующих затрат времени, заметных пользователям.

 

Дополнительные оптимизации СУБД

Основной комплект настроек для оптимального выполнения запросов 1С устанавливается с помощью параметра DB2_WORKLOAD=1C, выставляемого командой db2set. В дополнение к этой обязательной настройке, для некоторых нагруженных систем можно рассмотреть следующие дополнительные параметры:

• DB2_USE_ALTERNATE_PAGE_CLEANING=ON – использовать альтернативный (более агрессивный) алгоритм очистки страниц буферных пулов. Установка этого параметра полезна для систем с интенсивным вводом либо корректировкой данных, в которых активный рабочий набор данных не удается полностью разместить в оперативной памяти. Установка данного параметра может снижать производительность, поскольку DB2 будет более активно (т.е. с большими суммарными затратами ресурсов) записывать на диски изменённые страницы буферных пулов.
• DB2_PARALLEL_IO=* – использовать параллельный ввод-вывод для всех табличных пространств. Установка данного параметра целесообразна при размещении табличных пространств базы данных на RAID-массивах.
• DB2_SQLWORKSPACE_CACHE=200 – использовать увеличенный (по сравнению с применяемым по умолчанию) размер кэша откомпилированных запросов (так называемый SQL Workspace). Увеличение этого параметра со значения по умолчанию (30) до 200 приведет к увеличению потребления оперативной памяти в области общей кучи приложений (application shared heap) и снижению потребления ресурсов процессора. Рекомендуется для систем транзакционного типа (с большим количеством мелких запросов) и числом активно работающих пользователей не менее 200.

 

Дополнительные действия: Проверка настроек STMM

В большинстве случаев необходимость корректировки перечисленных ниже параметров не возникает, так как они корректно устанавливаются при создании базы данных средствами 1С. Тем не менее, при возникновении ошибок выделения оперативной памяти, необходимо выполнить следующие действия:

1. Выполнить команду GET DB CFG и проверить установку параметра конфигурации базы данных SELF_TUNING_MEM в значение ON. При необходимости скорректировать данный параметр командой UPDATE DB CFG.
2. Проверить установку параметра конфигурации базы данных DATABASE_MEMORY в разумное значение по умолчанию (см. ниже раздел про настройку объема использования оперативной памяти) с возможностью автоматической настройки (AUTOMATIC). При необходимости скорректировать данный параметр.
3. Проверить установку параметра конфигурации базы данных MAXLOCKS в разумное значение (95-99) с возможностью автоматической настройки (AUTOMATIC). При необходимости скорректировать данный параметр.
4. Проверить установку параметров конфигурации базы данных LOCKLIST, PCKCACHESZ, SHEAPTHRES_SHR,  SORTHEAP, DBHEAP, STMTHEAP, APPLHEAPSZ, APPL_MEMORY, STAT_HEAP_SZ с возможностью автоматической настройки (AUTOMATIC). При необходимости скорректировать параметры.
5. Проверить наличие включенной автоматической настройки размеров буферных пулов путем выполнения команды «db2pd -db ИмяБД -bufferpool». В начальной части вывода данной команды необходимо проверить, что в колонке «Automatic» указано значение «True» для буферного пула «IBMDEFAULTBP» и всех буферных пулов, имя которых начинается с символов «V81C_». Если для каких-то буферных пулов не активирована автоматическая настройка размера, необходимо это исправить командой ALTER BUFFERPOOL.

 

Заключение

Несмотря на то, что каждая большая система имеет определённую специфику и требует индивидуального подхода, приведённый выше набор рекомендаций может послужить хорошей отправной точкой для оптимизации производительности.