Некоторые аспекты конфигурирования IBM DB2 на Linux

Краткое содержание:

В статье рассматриваются некоторые аспекты конфигурирования IBM DB2 при развертиывании на операционной системе Linux

Инсталляция IBM DB2 на дистрибутиве Ubuntu

Неколько моментов момента, которые надо знать, при разворачивании IBM DB2 на Ubuntu.

1. Добавление новых пользователей

При добавлении нового пользователя в систему, команда useradd по-умолчанию не создает домашний каталог пользователя. Необходимо в командной строке указать ключ -m, чтобы этот каталог создавался при добавлении нового пользователя.

2. Автоматический запуск DB2 при старте системы

Стандартный автоматический запуск DB2 для UNIX-систем не работает под Ubuntu. Связано это с тем, что механизм автозапуска процессов в Ubuntu отличается от наиболее распространенного подхода, через конфигурирование файла /etc/inittab.

Ниже приведен самый простой способ автоматического запуска DB2 для Ubuntu.

После установки DB2 и создания инстанса, создайте файл /etc/init.d/db2 следующего содержания: (название приведено для пример, вы можете выбрать самостоятельно, например db2_95)

Копировать в буфер обмена
#!/bin/sh
#
# Script to start DB2 instance on bootup.
#
set -e
. /lib/lsb/init-functions
case "$1" in
start)
su - db2inst -c "db2start";;
stop)
su - db2inst -c "db2stop force";;
restart)
su - db2inst -c "db2stop force"
su - db2inst -c "db2start";;
esac
exit 0

В приведенном выше файле, db2inst - это имя пользователя инстанса. Если оно у вас отличается, измените его соотвествующим образом.

Внимание!
если вы будете копировать текст из этой статьи, то убедитесь, что у вас в файле сохраняются UNIX-интепретация окончания строк (CR), в случае Windows (CRLF) скрипт работать не будет!

Теперь необходимо изменить права на исполнение данного файла

Копировать в буфер обмена
chmod 755 /etc/init.d/db2

Все, что осталось нам сделать - это добавить соотвествующие ссылки на запуск и остановку db2 при изменнии уровня запуска Linux. По умолчанию Ubuntu выставляет уровень 2 (запустите команду runlevel и убедитесь в этом).

Для того, чтобы наш созданный скрипт автоматически запускался с параметром start при переходе на 2 уровень, просто добавим ссылку на него в каталог /etc/rc2.d/

Копировать в буфер обмена
cd /etc/rc2.d
ln -s ../init.d/db2 S95db2

А теперь укажем, что при переходе на уровени 0,1,6 необходимо останавливать DB2, т.е. запускать наш скрипт с паратмером стоп

Копировать в буфер обмена
cd /etc/rc0.d 
ln -s ../init.d/db2 K09db2
cd /etc/rc1.d 
ln -s ../init.d/db2 K09db2
cd /etc/rc6.d 
ln -s ../init.d/db2 K09db2

Попробуйте перезагрузиться. DB2 должна запуститься автоматически.

3. Алгоритм шифрования паролей.

Достаточно часто после попытки соединения с базой данных DB2 на Ubuntu, пользователи получают примерно следующую диагностику:

SQL30082N: Security processing failed with reason "15" ("PROCESSING FALURE")

SQLSTATE 08001

Вроде и пользователь/пароль верно указаны, а ошибка остается.

Дело в том, что Ubuntu использует по-умолчанию иной алгоритм шифрование паролей (sha512) и DB2 считает пароль очень длинным. Для устранения проблемы надо изменить алгоритм на md5. Для этого надо поправить файл /etc/pam.d/common-password
По умолчанию строчка, отвечающая за генерацию пароля, выглядит так

# here are the per-package modules (the "Primary" block)
password        [success=1 default=ignore]      pam_unix.so obscure sha512

надо sha512 поменять на md5
# here are the per-package modules (the "Primary" block)
password        [success=1 default=ignore]      pam_unix.so obscure md5

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

Конфигурирование параметров ядра Linux

В статье, посвященной инсталляции DB2 на Linux были даны рекомендации по конфигурированию параметров ядра, необходимые для функционирования конфигураций 1С развернутых поверх DB2. Вкратце напомним их. Необходимо сконфигурировать параметр kernel.shmmax=2147483648, т.е. 2 Гигабайтам. Этот параметр отвечает за максимальный размер сегмента выделяемой памяти. Практика показала, что для приложений на базе платформы 1С:Предприятие критичным является размер оперативной памяти, использьзуемый в качестве кэша базы данных, т.е. занимаемый буферпулами. (Об устройстве и табличных пространств и буферпулов см. статью на developerWorks. Также рекомендуется прочитать статью о модели памяти DB2). В свою очередь, рост буферпулов приводит к тому, что при перезапуске базы данных DB2 для размещения буферпулов может запрашивать сегмент памяти большого объема, что значительно превосходит параметры конфигурации, указанные в документации. Также данные ошибки возникают, когда память физически недоступна, т.е., например, занята другими процессами.

К чему приводят данные ошибки.

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

2. Пользователи видят сообщение об ошибке с диагностикой: SQL1220N The database manager shared memory set cannot be allocated 

Данную проблему также можно диагностировать на основе логов DB2.

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

Копировать в буфер обмена
db2diag -g "MESSAGE:=DIA8305C" -l Severe,Warning

Что мы видим в результате.

Копировать в буфер обмена
2009-10-24-16.24.09.203620+180 E198176G757        LEVEL: Warning
PID     : 6143                 TID  : 3083594656  PROC : db2sysc
INSTANCE: db2inst              NODE : 000         DB   : T2
APPHDL  : 0-14                 APPID: 127.0.0.1.15746.091024132410
AUTHID  : USR1CV81
EDUID   : 21                   EDUNAME: db2agent (T2)
FUNCTION: DB2 UDB, SQO Memory Management, sqloGetSharedMemoryFromOs, probe:2028
MESSAGE : ZRC=0x850F0005=-2062614523=SQLO_NOSEG
          "No Storage Available for allocation"
          DIA8305C Memory allocation failure occurred.
DATA #1 : <preformatted>
Unable to attach 2 segments totalling 377290752 bytes starting at address
0x00000000.  One possible cause may be an improper setting for the
shmmax Linux kernel tuneable.
2009-10-24-16.24.09.203752+180 E198934G839        LEVEL: Severe
PID     : 6143                 TID  : 3083594656  PROC : db2sysc
INSTANCE: db2inst              NODE : 000         DB   : T2
APPHDL  : 0-14                 APPID: 127.0.0.1.15746.091024132410
AUTHID  : USR1CV81
EDUID   : 21                   EDUNAME: db2agent (T2)
FUNCTION: DB2 UDB, base sys utilities, sqeLocalDatabase::FirstConnect, probe:120
MESSAGE : ZRC=0x850F0005=-2062614523=SQLO_NOSEG
          "No Storage Available for allocation"
          DIA8305C Memory allocation failure occurred.
DATA #1 : String, 203 bytes
Failed to allocate the minimum possible database shared memory set.
There are insufficient system resources to allocate the database shared memory set.
Minimum database shared memory set size is (bytes):
DATA #2 : unsigned integer, 4 bytes
431095808

Исходя из сообщений можно увидеть, сколько памяти не удалось выделить DB2 для работы.

Например, при работе на коммерческих редакциях DB2, где размер доступной памяти для использования базой более 2Гб (Ограничения бесплатной редакции DB2 Express-C), возможна ситуация, когда будет запрошен сегмент размером более 2Гб. В данном случае анализ диагностики, получаемой командой выше, может показать в чем проблема - то ли размер сегмента надо увеличивать (править /etc/sysctl.conf), либо память занята другими приложениями.