Как создать базу 1с на db2

Обновлено: 02.07.2024

Довелось работать с 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 но, возможно, требуются некоторые пояснения для тех, кому работа с этой СУБД в новинку, например

выполнять оффлайн и онлайн проверки исправности базы данных
@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, выводящий список потенциально проблемных объектов, который, скорее всего, должен быть небольшим, если окна обслуживания правильно установлены:

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

UPD (2021-05-08): Опять на сайте IBM ссылки поменялись (как периодически бывает). Старые пока работали, но решил всё же поменять.

Ссылки на упомянутые ресурсы/файлы

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

Многое уже подзабылось, но ссылку на сохранённый когда-то документ pdf «Best practices. Tuning and monitoring database system performance» удалось найти (ссылка теперь новая, старая wiki прекращает существование с 2020-01-01, а здесь пока всё не совсем стабильно).

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

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

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

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

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

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

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

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

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

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

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

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

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

Обратите внимание, что перечисленные выше команды создают новые временные системное и пользовательское табличные пространства на устройствах, используемых по умолчанию базой данных 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, например:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендуемые параметры автоматического обслуживания базы данных соответствуют устанавливаемым по умолчанию при создании базы данных средствами 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.

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

Заключение

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

При этом версия Express-C 10.1 уже официально поддерживается платформой 1С 8.2.

а значит можно применять на практике и полнофункциональную версию DB2 10.1.

Если сравнивать бесплатные версии DB2 Express-C 9.7 и 10, то очевидно преимущество – теперь объем используемой оперативной памяти увеличен с 2 до 4 Гб, что не может не радовать.
При этом MS SQL Express 2012 все также поддерживает лишь 1Гб оперативной памяти.

Посмотрим, как выглядит процесс установки и настройки на примере бесплатной версии.

Скачиваем дистрибутив, распаковываем его и запускаем файл setup.exe, появляется приветственное окно.


Переходим на закладку «Установить продукт» и нажимаем «Установить новую копию» напротив единственного предлагаемого варианта (в коммерческой версии есть возможность выбора редакции СУБД)



Принимаем лицензионное соглашение


Оставляем обычную установку и продолжаем. Для 1С этого будет достаточно.



Указываем каталог установки. Если у вас выделен отдельный дисковый массив на базы DB2 – можно выполнять установку сразу туда, это позволит по умолчанию создавать новые базы на том же диске, но параметр, отвечающий за это, можно всегда поменять.


От SSH я отказался. Это дополнительная возможность администрирования сервера, которую желательно использовать при управлении серверами через публичные сети по незащищенному каналу. В локальной сети особого смысла от этого нет.


Создаем новую учетную запись для запуска процессов сервера


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



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

Открываем командное окно


И выполняем команду
db2set DB2_WORKLOAD=1C
если запустить просто db2set, то система покажет список установленных параметров


Затем перезапускаем СУБД:
db2stop
db2start


Создаем новую информационную базу в 1С, при этом в качестве пользователя сервера БД необходимо указать db2admin, которого вы создали в процессе установки


Не забываем проверить, что в каталоге с сервером приложений 1С размещен файл-семафор db2loadapion, что позволит ускорить процесс загрузки базы данных из dt-файла.


На этом все. Осталось загрузить в созданную базу dt-файла или файл конфигурации и работу можно начинать.

"Центра управления" в DB2 10.1 больше нет, но, кроме командной строки можно установить бесплатный инструмент для администрирования DB2 - IBM Data Studio.

Особенности работы с СУБД IBM DB2

Особенности установки компоненты 1С:Предприятия 8.1 для работы с IBM DB2

  • Операционная система Windows.
    Если сервер 1С:Предприятия запущен как сервис, необходимо выполнить следующие действия:
    • включить пользователя, от имени которого запускается сервер 1С:Предприятия (по умолчанию USR1CV81) в группу DB2ADMNS;
    • для используемой копии DB2 установить параметр SYSADM_GROUP в значение DB2ADMNS. Для этого:
      • запустить центр управления ( Старт - Программы - IBM DB2 - DB2COPY1 (По умолчанию) - Общие инструменты управления - Центр управления );
      • открыть диалог изменения параметров текущего экземпляра DB2. Для этого в дереве объектов выбрать текущий экземпляр ( Центр управления - Все системы - <имя сервера баз данных> - Экземпляры - <имя используемого экземпляра> ) и выполнить команду контекстного меню Конфигурировать параметры ;
      • установить необходимое значение параметра SYSADM_GROUP (в категории Управление );
      • перезпустить используемый экземпляр DB2 (в контекстном меню команды Остановка и Запуск ).

      Администрирование

      При создании информационной базы необходимо выбрать в качестве типа СУБД - IBM DB2.


      Имя базы данных в IBM DB2 должно содержать только английские буквы и цифры и не должно быть длиннее 8 символов.

      В качестве имени сервера баз данных необходимо указать имя компьютера, а если на нем имеются экземпляры сервера баз данных, отличные от установленного по умолчанию, то и имя установленного экземпляра IBM DB2, заданное при его установке через "/". Например, computer/db2name.

      Длина имени пользователя базы данных не должна превышать 8 символов.

      В остальном, администрирование работы 1С:Предприятия 8.1 с IBM DB2 не отличается от работы с другими СУБД.

      Установка и настройка DB2 под Windows для работы с 1С:Предприятием 8.1

      Установка и настройка DB2 под Windows для работы с 1С:Предприятием 8.1 Начните установку с запуска файла setup.exe. В открывшейся панели запуска установки DB2 перейдите на закладку «Установить продукт» и для установки DB2 нажмите «Установить новый».


      В открывшейся панели запуска установки DB 2 перейдите на закладку «Установить продукт» и для установки DB 2 нажмите «Установить новый».


      Дождитесь появления приглашающего окна мастера установки и нажмите «далее».


      Далее необходимо принять лицензионное соглашение.


      Выбирайте пользовательский тип установки для управления устанавливаемыми компонентами. У Вас будет возможность убедиться, что процесс установки прост.


      Уточните, что вы выполняете только установку.


      Если вы сомневаетесь, какие компоненты надо установить, то можно установить все компоненты. Но основными для работы 1С:Предприятие будут разделы «поддержка сервера» и «поддержка клиента».


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


      Имя экземпляра DB 2 оставьте по умолчанию.


      Далее укажите использование справки по DB 2 на сайте IBM .


      Укажите учетную запись Windows , которая будет использована для службы DB 2.


      Параметры подключения можно оставить по умолчанию.


      Включите пункт «подготовка каталога инструментов DB 2».


      Администрирование уведомлений по почте можно отложить «на потом».


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


      Следующее окно показывает выбранные настройки и кнопка «Установить» выполняет установку DB 2.


      Завершение установки обозначается соответствующим диалоговым окном.


      Первым делом после установки сконфигурируйте параметр DB 2_ WORKLOAD .

      Для этого откройте Пуск-Все программы- IBM DB 2- DB 2 COPY 1(по умолчанию)-Инструменты командной строки- командное окно.

      Выполните следующие команды:

      db 2 stop
      db 2 set DB 2_ WORKLOAD =1 C
      db 2 start

      Чтобы корректно отображался русский шрифт, используйте шрифты как на рисунке.


      Учтите, что если кластер серверов не расположен на сервере СУБД, то на нем также должна быть установлена клиентская часть СУБД. Если вы забудете это сделать, то при работе с 1С:Предприятия 8.1 c IBM DB2 может возникать ошибка.

      Необходимо разместить учетную запись USR 1 CV 8 в группе DB 2 ADMINS .


      При создании информационной базы в 1С:Предприятие 8.1 необходимо выбрать в качестве типа СУБД - IBM DB2.


      Имя базы данных в IBM DB2 должно содержать только английские буквы и цифры и не должно быть длиннее 8 символов.

      В качестве имени сервера баз данных необходимо указать имя компьютера, а если на нем имеются экземпляры сервера баз данных, отличные от установленного по умолчанию, то и имя установленного экземпляра IBM DB2, заданное при его установке через "/". Например, computer/db2name.

      Не используйте IP -адресацию для сервера СУБД IBM DB2.

      Длина имени пользователя базы данных не должна превышать 8 символов.

      В остальном, администрирование работы 1С:Предприятия 8.1 с IBM DB2 не отличается от работы с другими СУБД.

      Читайте также: