В статье рассматриваются некоторые аспекты конфигурирования IBM DB2 при развертиывании на операционной системе Linux
Неколько моментов момента, которые надо знать, при разворачивании IBM DB2 на Ubuntu.
При добавлении нового пользователя в систему, команда useradd по-умолчанию не создает домашний каталог пользователя. Необходимо в командной строке указать ключ -m, чтобы этот каталог создавался при добавлении нового пользователя.
Стандартный автоматический запуск 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 должна запуститься автоматически.
Достаточно часто после попытки соединения с базой данных 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
# here are the per-package modules (the "Primary" block) password [success=1 default=ignore] pam_unix.so obscure md5
После чего надо перегенерировать пароль для пользователя, под которым происходит авторизация при соединении с базой данных.
В статье, посвященной инсталляции 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), либо память занята другими приложениями.