Довелось работать с 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-битным.
UPD: Возможно, был не внимателен, когда перед публикацией проверял поддерживаемые 1С: Предприятием версии DB2. В оригинале этого текста 2015 года о 10.5fp4 было сказано: при использовании с 1С: Предприятием «ошибок пока не обнаружено». То есть на настоящий момент из новых Express-C возможно только применение 10.1 (с её особенностями и ограничениями). Из современных платных официально поддерживается только 11.1. Не исключено, что кому-то будет достаточно Developer-C с размером базы до 100 Гб. Ссылку на документацию менять не стал — там легко переключаться.
UPD: Перечитал всё, наверно, должно быть понятно тому, кто имел дело с DB2 но, возможно, требуются некоторые пояснения для тех, кому работа с этой СУБД в новинку, например
А вот то, что
Надеюсь, ничего не напутал, поднял архив скриптов пятилетней, наверно, давности. Не знаю, будет ли полезно кому это дополнение.
UPD (2021-05-08): Опять на сайте IBM ссылки поменялись (как периодически бывает). Старые пока работали, но решил всё же поменять.
Основную информацию, кроме той, что была получена на уже не существующих курсах, можно найти здесь (тогда ссылка была другая).
Многое уже подзабылось, но ссылку на сохранённый когда-то документ pdf «Best practices. Tuning and monitoring database system performance» удалось найти (ссылка теперь новая, уже от 2023-01-20, старая wiki прекращает существование с 2020-01-01, а здесь пока всё не совсем стабильно).
В интернете много инструкций как организовать работу 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-битным.
UPD: Возможно, был не внимателен, когда перед публикацией проверял поддерживаемые 1С: Предприятием версии DB2. В оригинале этого текста 2015 года о 10.5fp4 было сказано: при использовании с 1С: Предприятием «ошибок пока не обнаружено». То есть на настоящий момент из новых Express-C возможно только применение 10.1 (с её особенностями и ограничениями). Из современных платных официально поддерживается только 11.1. Не исключено, что кому-то будет достаточно Developer-C с размером базы до 100 Гб. Ссылку на документацию менять не стал — там легко переключаться.
UPD: Перечитал всё, наверно, должно быть понятно тому, кто имел дело с DB2 но, возможно, требуются некоторые пояснения для тех, кому работа с этой СУБД в новинку, например
следует просматривать историю базыдолжно привести сюда, а
выполнять оффлайн и онлайн проверки исправности базы данныхсюда, сюда и сюда, но в последнем случае уже может потребоваться
вот такой пакетный файл
@echo off
setlocal
db2 list applications for db %1 && exit /b
set active=no
db2 list active databases | findstr /i /r "=\ %1$" >nul && set active=yes
if %active%==yes db2 deactivate db %1 || (db2 activate db %1 & exit /b)
db2 CONNECT TO %1
db2 QUIESCE DATABASE IMMEDIATE FORCE CONNECTIONS
db2 CONNECT RESET
::db2set DB2_DIRECT_IO=OFF
db2dart %1 /RPT . /ERR E
::db2set DB2_DIRECT_IO=
db2 CONNECT TO %1
db2 UNQUIESCE DATABASE
db2 CONNECT RESET
if %active%==yes db2 activate db %1
А вот то, что
Анализ легко ускоряется простым фильтром (на .js, например) с использованием регэкспов.может вызвать затруднение, не уверен, что вообще это кто-нибудь делает, полагается на автоматику, максимум ограничивается таким запросом:
db2 "SELECT substr(TABSCHEMA,1,20), substr(TABNAME,1,20) FROM SYSIBMADM.ADMINTABINFO WHERE REORG_PENDING = 'Y'" Тем не менее
получить нужную информацию легко
Дальше, анализ по описанию и запуск реорганизации выбранных объектов или увеличение окна оффлайн обслуживания. После нескольких итераций станет ясно, реорганизацию каких объектов делать не имеет смысла.Для этого сначала запускается вот такая команда
db2 -x "select 'reorgchk update statistics on table',substr(rtrim(tabschema)||'.'||rtrim(tabname),1,50),';' from syscat.tables where type = 'T' " > reorgchk.out а затем db2 -tvf reorgchk.out > reorgchk.txt и, наконец reorg_filter.js reorgchk.txt Вот сам WSH скрипт reorg_filter.js, выводящий список потенциально проблемных объектов, который, скорее всего, должен быть небольшим, если окна обслуживания правильно установлены: var block = "", include = false, fso = new ActiveXObject("Scripting.FileSystemObject");
var input = fso.OpenTextFile(WScript.Arguments.Item(0), 1, false);
var output = fso.CreateTextFile(WScript.ScriptFullName.replace(/\.js/i, ".txt"), true);
while(!input.AtEndOfStream){
line = input.ReadLine();
if(/^reorgchk\s/i.test(line)){
if(include)output.WriteLine(block);
block = "";
include = false;
}
block += line + "\n";
if(/\s([-*]{3}|[-*]{5})\s+$/.test(line))if(/\*/.test(RegExp.$1))include = true;
}
if(include)output.WriteLine(block);
Надеюсь, ничего не напутал, поднял архив скриптов пятилетней, наверно, давности. Не знаю, будет ли полезно кому это дополнение.
UPD (2021-05-08): Опять на сайте IBM ссылки поменялись (как периодически бывает). Старые пока работали, но решил всё же поменять.
Ссылки на упомянутые ресурсы/файлы
Основную информацию, кроме той, что была получена на уже не существующих курсах, можно найти здесь (тогда ссылка была другая).
Многое уже подзабылось, но ссылку на сохранённый когда-то документ pdf «Best practices. Tuning and monitoring database system performance» удалось найти (ссылка теперь новая, уже от 2023-01-20, старая wiki прекращает существование с 2020-01-01, а здесь пока всё не совсем стабильно).
Если ссылка перестанет работать, название и хеши файла:
Name: DB2BP_System_Performance_0813.pdf
SHA384: 180E EF56 DB7F 70DE A514 981C 2718 ADD1 5702 D142 ABFD 090C A2B1 529C E918 B7AE DD08 7C7E B36C 3466 C843 C808 D4DA DE66
SHA256: A1B3 C600 B28A 8B9F 25ED 4AC3 F6C2 C6BB F884 BDA5 4121 DA1A 9C05 D0B0 F5CF D84E
MD5: F086 F0DD 6CFC 4DAB 4723 FBE4 A2BE AB41
SHA512: 6C86 B044 7F60 1DDA AFA5 D726 A6C2 9B29 68DD 3A90 1606 DA17 0464 5213 C0B0 B3C8 E636 221A 316D 151F 7E05 2B6D 55EB 95FC 09E7 B1AD 8CFE 0848 AB9F 9408 D214 35EE
SHA1: 7911 0741 2E6C FD6B 4B5B F639 5C0D 48D8 3528 A64D
SHA384: 180E EF56 DB7F 70DE A514 981C 2718 ADD1 5702 D142 ABFD 090C A2B1 529C E918 B7AE DD08 7C7E B36C 3466 C843 C808 D4DA DE66
SHA256: A1B3 C600 B28A 8B9F 25ED 4AC3 F6C2 C6BB F884 BDA5 4121 DA1A 9C05 D0B0 F5CF D84E
MD5: F086 F0DD 6CFC 4DAB 4723 FBE4 A2BE AB41
SHA512: 6C86 B044 7F60 1DDA AFA5 D726 A6C2 9B29 68DD 3A90 1606 DA17 0464 5213 C0B0 B3C8 E636 221A 316D 151F 7E05 2B6D 55EB 95FC 09E7 B1AD 8CFE 0848 AB9F 9408 D214 35EE
SHA1: 7911 0741 2E6C FD6B 4B5B F639 5C0D 48D8 3528 A64D
