DBD :: Informix проблемы с подключением - PullRequest
2 голосов
/ 14 сентября 2011

У меня странная проблема с DBD :: Informix.Если я запускаю простой скрипт вроде этого:

use DBI;
my $dbh = DBI->connect_cached('dbi:Informix:database', '', '');
my $sth = $dbh->prepare('select foo from bar');
...

Все работает нормально.Но если я попытаюсь сделать то же самое из тестового сценария, произойдет сбой со следующим сообщением:

SQL: -25588: The appl process cannot connect to the database server cms_ol.
ISAM: 22: Invalid argument

Единственное различие, которое я вижу, состоит в том, что тестовый сценарий довольно тяжел для использования модуля;он основан на Test :: More и загружает множество подмодулей, которые должны быть протестированы.

Включение трассировки DBI не дает ничего полезного (по крайней мере, для меня).Простой скрипт работает просто отлично:

DBI 1.616-nothread default trace level set to 0x0/1 (pid 9685 pi 0) at test_ifx.pl line 6
Note: perl is running without the recommended perl -w option
-> DBI->connect(dbi:Informix:cms@cms_ol, , ****, HASH(0x13fad0))
-> DBI->install_driver(Informix) for solaris perl=5.008009 pid=9685 ruid=106 euid=106
   install_driver: DBD::Informix version 2011.0612 loaded from /cms/webdash/lib/arch/DBD/Informix.pm
<- install_driver= DBI::dr=HASH(0x1c8070)
!! warn: 0 CLEARED by call to connect method
    -->> DBD::Informix::dbd_ix_db_connect()
CONNECT TO 'cms@cms_ol' - no user info
    -->> DBD::Informix::dbd_ix_db_check_for_autocommit()

... и единственное отличие в трассировке проблемного скрипта, которое я вижу, заключается в том, что он просто не работает:

DBI 1.616-nothread default trace level set to 0x0/1 (pid 9687 pi 0) at 22_report.t line 5 via 22_report.t line 6
Note: perl is running without the recommended perl -w option
-> DBI->connect_cached(dbi:Informix:cms, , ****)
-> DBI->install_driver(Informix) for solaris perl=5.008009 pid=9687 ruid=106 euid=106
   install_driver: DBD::Informix version 2011.0612 loaded from /cms/webdash/lib/arch/DBD/Informix.pm
<- install_driver= DBI::dr=HASH(0xb619bc)
!! warn: 0 CLEARED by call to connect_cached method
    -->> DBD::Informix::dbd_ix_db_connect()
CONNECT TO 'cms' - no user info
***ERROR***
SQL: -25588: The appl process cannot connect to the database server cms_ol.
ISAM: 22: Invalid argument
    <<-- dbd_ix_db_connect (**ERROR-1**)
    <<-- DBD::Informix::dbd_ix_db_connect()

Я работаюпользовательская сборка Perl 5.8.9 в Solaris 9 с последними версиями DBI и DBD :: Informix против Informix IDS 9.40UC.

Обновление : если я попытаюсь быть умным и поставитьнапример, в верхней части сценария тяжелого теста:

use DBI;
BEGIN { my $dbh = DBI->connect_cached( ... ); print "Connected!\n" if $dbh; }

... он печатается так:

Connected!
Out of memory!
Callback called exit.
END failed--call queue aborted at t/22_report.t line 20.
Callback called exit at t/22_report.t line 20.
BEGIN failed--compilation aborted at t/22_report.t line 24.

Я предполагаю, что DBD :: Informix конфликтует с некоторыми измодули, загруженные после установления соединения.Но какой?Вот в чем вопрос ...

Еще одно обновление : Похоже, что вышеупомянутый трюк делает что-то громоздкое.Я попытался явно загрузить все модули, заменив «use Module» на «require Module»;Модуль-> импорт.С чистыми модулями Perl все в порядке, но всякий раз, когда появляется модуль XS, использующий XSLoader, Perl приходит в бум с дружеским сообщением «Недостаточно памяти».И если я переместу соединение Informix ниже инициализации модуля, оно будет работать нормально - кроме DBD :: Informix, происходит сбой с той же ошибкой -25588.Бумер.Я в растерянности.: (

Еще одно обновление : я пытался запустить тот же сценарий со стандартным Perl 5.6.1, поставляемым с Solaris 9, используя DBI 1.601 (последний, который будет компилироваться с Perl 5.6) иDBD :: Informix 2011.0612. То же самое, так что это не пользовательский Perl, доставляющий мне проблемы.

Могу также добавить, что рассматриваемый тестовый модуль был прототипирован с использованием DBD :: SQLite и полностью работает. Это последний тестс DBD :: Informix, который не работает ... Как обычно.: /

Обходной путь : после обсуждения по электронной почте с Джонатаном был найден обходной путь: добавление onipsstr на основе потоков'подключение к серверу Informix позволило подключиться к DBD :: Informix. По-видимому, некоторые модули XS взаимодействуют с методом подключения по умолчанию на основе shmem, хотя виновник на данный момент неизвестен.

1 Ответ

2 голосов
/ 14 сентября 2011

Дальнейшее обсуждение

Собственный Perl, по моему опыту, проще, чем системный Perl. Я никогда не изменяю системную установку Perl (я не хочу ее нарушать), поэтому я всегда строю свою собственную.

У вас, кажется, есть:

  • Solaris 9 (SPARC?)
  • Perl 5.8.9
  • DBI 1.616
  • DBD :: Informix 2011.0612
  • ESQL / C (CSDK) 2,81
  • Informix Dynamic Server 9.40

У нас нет подробной подверсии ESQL / C и IDS (2.81.UC2, 9.40.UC5 или что-то еще). Есть подсказка, что вы используете 32-битную версию IDS, поэтому, вероятно, все 32-битная. Возможно, вы знаете, что 9.40 больше не поддерживается IBM (и, действительно, его преемник 10.00 также не поддерживается). Однако внешне все это не должно иметь большого значения. Сбой t91lvarchar.t не является большой проблемой.

  • Можно ли запустить подключение в рабочем и нерабочем режимах с установленным в среде DBI_TRACE = 9.

Если трассировка для операции подключения слишком обширна, чтобы перейти к обновлению вопроса, лучше перевести это в автономный режим на каналы поддержки DBD :: Informix (это я, но по электронной почте).

Ошибка ISAM 22 (неверный аргумент) вызывает недоумение. Мне интересно, что находится в вашем файле sqlhosts для этого сервера - запись для cms_ol специально. Я не уверен, что это что-то покажет, не в последнюю очередь потому, что вы говорите, что приведенный ниже пример ESQL / C (в разделе «Первая гипотеза») работает нормально, а иногда Perl подключается, а иногда нет.

Интересно, есть ли где-нибудь конфликт имен между функциями в общих библиотеках? Такого рода вещи будут чертовски отслеживать.

Первая гипотеза

Дополнительная информация показывает, что это не было принципиальным отличием.

Разница выглядит так:

  • Работы: CONNECT TO 'cms@cms_ol' - no user info
  • Сбои: CONNECT TO 'cms' - no user info

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

Обходной путь - указать имя сервера в строке подключения:

  • DBI->connect(dbi:Informix:cms@cms_ol, , ****, HASH(0x13fad0))
  • DBI->connect_cached(dbi:Informix:cms, , ****)

Основная проблема более вероятна на уровне ESQL / C, чем что-либо, связанное с другими модулями Perl. То есть, если вы скомпилировали и выполнили эту программу ESQL / C, она не работает на cms и работает на cms@cms_ol:

int main(int argc, char **argv)
{
    $ char *dbs = "cms";
    if (argc > 1)
        dbs = argv[1];
    $ whenever error stop;
    $ connect to :dbs;
    return 0;
}

Вы можете запустить его без явного имени базы данных (или с явным «cms»), и я ожидаю, что это не удастся. Вы можете запустить его с помощью 'cms @ cms_ol', и я ожидаю, что он пройдет. Программа ничего не скажет, если она пройдет; это будет очевидно, когда не получится (хотя сообщения не будут красивыми).

Существует вероятность того, что это как-то связано с connect_cached; это сервис, предоставляемый модулем DBI, а не модулем DBD :: Informix. В целом, скорее всего, что-то происходит на уровне ESQL / C.

...