[Из песочницы] Мой опыт администрирования IBM DB2 Express-C при использовании с 1C: Предприятием
Довелось работать с IBM DB2. И на 1С, и сервер на Django использовал эту СУБД одно время, OLAP запросы довольно шустро обрабатывал (правда, требовалась ручная настройка индексов, ну и веб-сервера, конечно, чтобы отклик был в пределах 2 секунд). Году в 2015 подготовил эту небольшую инструкцию себе, чтоб не забыть. И как дополнение к резюме, возможно кто-то прочитал на бумаге, оставшиеся годы без дела пролежала. Некоторое обобщение моего опыта работы с DB2. Немного поправил и предлагаю прочесть здесь для расширения кругозора. Может кого-то заинтересует. Сразу скажу, что с тех пор с DB2 не работал, подзабылось всё, но кое-что ещё помню. Критика и уточнения приветствуются, но, поскольку уже не работаю, может, не мне, а кому-то ещё будут полезны.
В интернете много инструкций как организовать работу 1С: Предприятия с СУБД IBM DB2. Для начала это совсем не плохо, но для использования в производстве не достаточно. Я раньше рекомендовал начинать знакомство с IBM DB2 с тренировочного курса Big Data University DB101RU. Сам прошел этот курс, сдал экзамен в 2012 году, считаю его очень полезным. Жаль, что ресурс прекратил своё существование. На новой платформе ничего подобного не нашёл. В производстве IBM DB2 требует дополнительных настроек и обслуживания, самые необходимые из которых будут здесь кратко описаны. Рассматривается бесплатная редакция IBM DB2 Express-C для Windows версии 10.1fp2 и 10.5fp4 (первая поддерживается фирмой »1С» для работы в тестовом режиме, вторая — поддерживается официально, жаль, что более новые версии только платные). Имеет смысл установить 64-битную 10.5 там, где высоки требования к оперативной памяти (размерам буферпулов для скорости работы) или размеру записи (EXTENDED_ROW_SZ = ENABLE) при использовании составных типов, содержащих длинные строки фиксированного размера.
Самое первое, что следует сделать — перейти к использованию архивных журналов с тем, чтобы делать бэкапы, не прерывая работы »1С: Предприятия», и иметь возможность восстановить базу данных на любой момент времени (восстановление в 10.1fp2 имеет свои особенности из-за неисправленного бага в бесплатной версии — требуется ручное перемещение файлов журналов). В отличие от MS SQL архивирование журналов выполняется не в определенные заранее заданные моменты времени (в MS SQL не силён, возможно, что-то ещё есть), а по достижении файлом журнала определенного, заранее заданного размера, не требуется бэкапирование журнала перед операцией восстановления, достаточно деактивировать базу. Легко настраивается архивирование журналов в два направления, одно из которых — на сетевом диске, например. При этом в случае непродолжительных сбоев в сети увеличение занятого активными журналами места — не значительно. Для активных журналов необходимо предусмотреть достаточно свободного места, чтобы иметь возможность восстановления базы данных на любой момент времени. Если в процессе работы программиста с базой 1С требуются частые возвраты в различные близкие моменты времени, для восстановления достаточно одного бэкапа, выбор файлов журнала для восстановления весьма прост. Обязательно следует активировать базу при старте инстанса, иначе получим большое количество мелких файлов журналов при неявной активации. Очевидно, следует установить время хранения бэкапов (мне кажется, необходимо хранить журналы не менее двух месяцев) и настроить автоматическое удаление. База и бэкапы (логи) должны находиться на разных физических дисках, в крайнем случае можно делать бэкапы на другой компьютер локальной сети.
Активация базы нужна и по другой причине. Для нормальной работы следует установить окна онлайн и оффлайн обслуживания. В это время база должна быть активна. Периодически следует просматривать историю базы для выяснения какие действия выполнялись во время оффлайн окна. Окно оффлайн обслуживания, скорее всего, следует установить в промежутке времени 22:00 — 0:00, так как в это время нет тяжелых регламентных заданий 1С. Возможно, для небольших баз достаточно окна продолжительностью 1 час.
Периодически требуется запускать проверку необходимости реорганизации в ручном режиме и, после анализа состояния таблиц и индексов, выполнять реорганизацию отдельных объектов. Ручная реорганизация нескольких тысяч таблиц и индексов может занять продолжительное время. Анализ легко ускоряется простым фильтром (на .js, например) с использованием регэкспов.
AUTOCONFIGURE, конечно, необходимо периодически делать, исправляя вручную отдельные настройки, например, устанавливая свой размер файлов журнала.
Через день, возможно и чаще выполнять онлайн бэкапирование базы (не требует остановки работы и присутствия DBA), частота зависит от требуемого времени восстановления, зависящего в свою очередь от количества файлов архивных журналов после последнего бэкапа, то есть нагрузки на базу. Для средних, больших и высоконагруженных баз данных имеет смысл применение различных видов инкрементного бэкапа с целью уменьшения занимаемого бэкапами места и сокращения времени восстановления из резервных копий. После каждого бэкапа и перед восстановлением проверять исправность резервных копий. Время хранения бэкапов на усмотрение DBA, но не меньше времени хранения журналов.
Не реже, чем раз в месяц выполнять оффлайн и онлайн проверки исправности базы данных (в оффлайн режиме работа с базой приостанавливается на несколько минут) и при необходимости — выполнить ремонт (наиболее актуально для «серверов» без ИБП). Ежемесячно выполнять оффлайн бэкап базы данных, хранить долго только оффлайн бэкапы, поскольку при смене версии DB2 онлайн бэкап развернуть не удастся. Если »1С: Предприятие» не допускает даже кратковременного перевода базы в оффлайн для проверки или бэкапа, возможно выполнение указанных действий в развернутой копии базы. База данных без особых проблем восстанавливается из бэкапа в другое расположение, например на другой диск на другом сервере. Следует отметить, что как бэкапы, так и архивные журналы могут быть сжаты средствами DB2 (при этом остается работоспособным средство проверки бэкапов и не работает средство проверки архивных журналов).
Перед оффлайн проверкой базы данных и оффлайн бэкапом следует установить блокировку базы и регламентных заданий. В экстренном случае можно обойтись стабилизацией базы данных, но, поскольку, пользователь, под которым запущен сервер »1С: Предприятия» входит в группу SYSADM_GROUP, это не отменит возможности подключения 1С к базе данных в неподходящий момент времени и, как следствие, вызовет необходимость повторного запуска задания.
Если база данных работает не быстро, следует, после обновления статистики, получить планы наиболее тяжелых запросов, в копии базы поэкспериментировать с индексами в 1С, отслеживая изменения плана запроса в IBM Data Studio (в этом случае оправдано применение eclipse, в других достаточно обойтись интерфейсом командной строки), или воспользоваться рекомендациями DB2 Design Advisor и, при необходимости, создать индексы вручную вне 1С. Одновременно с этим запустить сбор детальной информации о производительности средствами DB2 (более десятка SQL скриптов) и проанализировать нагрузку системным монитором. Для уменьшения нагрузки на дисковую систему база данных должна устанавливаться на отдельный высокооборотный диск достаточного объема (если, конечно, отсутствует нормальный серверный дисковый массив RAID 10), возможно размещение активных логов на SSD вместе с ОС. Вероятно, также потребуется изменение места расположения темпов сервера »1С: Предприятия». В случае, если покупка диска только планируется, для небольших организаций допустимо временное использование под базы данных единственного физического диска.
Ежедневно просматривать db2diag.log на предмет ошибок, а также по результатам действий с базой данных. Архивировать по достижении размера в несколько десятков мегабайт. Удобным средством просмотра журнала может быть Far Manager (предполагается, что ошибок в процессе работы базы данных мало), он же поможет в случае необходимости ручного перемещения архивных логов для восстановления на момент времени.
Одним из конкурентных преимуществ IBM DB2, как мне кажется, можно считать то, что в случаях, когда для нормальной работы MS SQL Server требуется 64-битный сервер »1С: Предприятия», для IBM DB2 можно обойтись 32-битным.
Ссылки на упомянутые ресурсы/файлы
Основную информацию, кроме той, что была получена на уже не существующих курсах, можно найти здесь (тогда ссылка была другая).
Многое уже подзабылось, но ссылку на сохранённый когда-то документ pdf «Best practices. Tuning and monitoring database system performance» удалось найти.
