А зачем? Здесь вам не петухон. Один терминатор забудешь и весь код превращается в макароны. Часто достаточно исправить одну ошибку, как сразу уходит всё остальное.

*одну ошибку = самую верхнюю

А запрос непосредственно в sqlplus тоже около 20сек выполняется?

Я думал, что уже никому не интересно тратить на меня время, поэтому не стал отписывать. Но сегодня тестировал этот момент.

В sqlplus все быстрее. В крайний раз вот так вышло по времени:
- 2.507s - sqlplus
- 22.094412s - DBI

Причем я для sqlplus заведомо не честно время замерял (не знаю нужных флагов, замерял время  через time sqlplus и это real показатель) т.е. сам запрос еще быстрее выполняться должен. А у DBI я цифры беру из вывода профилировщика, и там только на саму операцию fetchall уходит эти волшебные 22 секунды.

А вот так вышло когда сделал запрос с сервера максимально близкого к БД:
- 0.143s - sqlplus
- 0.109958s - DBI

Собственно здесь и видна разница между честным выводом времени у DBI и нечестным как я сделал для sqlplus. Если через time проверить время выполнения перлового скрипта, то справедливость восстанавливается и у test.pl время 0.168s, что чуть дольше чем у вызова sqlplus.

У DBI почему-то такой разрыв огромный именно когда БД далеко от самого приложения (у sqlplus все в этом плане лучше).

Ощущение, что DBI порционно забирает данные, т.е. ходим много раз до БД и теряем из-за этого много времени. Перманентно изучаю доку по dbi, но пока не нашел этот момент (или проглядел).

пробовал менять RowCacheSize в DBI->connect() ? у меня когда-то получилось заметное ускорение при явном добавлении RowCacheSize => 1000 хотя в DBD::Oracle написано что "Most of the time one can just let DBD::Oracle figure out the best optimization"

запустить скрипт с DBI_TRACE=5 или выше

Да это пробовал здесь: https://t.me/modernperl/182038. Там всего 438 записей возвращается, поэтому RowCacheSize выше 500 не выставлял (изначально 50 стояло), но существенного прироста скорости не заметил, скорее все списать можно на погрешность измерений.

С DBI_TRACE не пробовал играться, теперь уже после выходных попробую, спасибо!

вообще, странно это. дби изначально создавался человеком из оракла, дбд::оракл один из самых поддерживаемых. для селекталл там даже спец оптимизация на иксесе. я профилировал постгресс — 50% времени уходит на преобразование из "родных" типов дб в перловые, всё происходит внутри модуля на иксесе, хз что там можно оптимизировать.

А explain запроса что говорит?

А при чем здесь explain если запрос на сервере рядом с БД выполняется 0.1 секунды? Только только когда БД дальше уезжает то DBI  начинает дико медленно забирать данные в отличие от sqlplus который хоть и проседает но не так масштабно.

Профилировщик dbi говорит, что практически все время уходит на fetchall операцию.

вопрос в том что там внутри — время на сеть или на преобразование данных

можешь запустить этот скрипт "рядом с бд"?

Да, выше делал.
Рядом с БД 0.1 сек. Увожу от БД сразу 22 сек. При этом у sqlplus просадки сильно меньше.

А пинг до сервера нормальный?

Я не пойму пока как fetchall под капотом работает. Судя по изменению времени запроса как будто бы много раз ходит до БД и кусочками эти несчастные 400+ строк забирает.

еденичный и ортогональный?

запросто, там есть какой-то флаг у дбд-оракла, насколько я помню

вообще, есть две глобальных стратегии: запрашивать всё сразу, ложить в память и оттуда потом кусочками возвращать; хранить результаты запроса на сервере и оттуда их доставать по мере надобности

Вот этого момента не знал. Если так, то все проясняется. В этом частном случае мне как раз выгодно было бы все сразу забрать.
Попробую еще dbd покопать, спасибо!