Alexggg99,

это не запрос. Это набор предикатов, демонстрирующий непонятный мне подход. Вы могли бы сменить его:
0. На несколько сохранённых общих отчётов, благо, отчёт у Вас интерактивный. У каждого отчёта выставить соответствующие фильтры, дать отчётам вразумительное название.
1. На PL/SQL function body returning SQL query в Source, возвращая запрос с нужным предикатом в зависимости от значения P2_DATE_FILTER_TYPE.

haXbatПреобразования to_date в where тоже лишние.
Вы уверены?

SvUserВидимо дело в большом количестве соединений и выбираемых данных.

Откуда видимо? Пока ничего не видно. ТС дал нам кусок текста запроса, причём кусок не из лучших. Ни полного запроса из результата отладки, ни трассировки его выполнения, ни объёмов данных, ни логики работы пользователя с отчётом - только "крушение... 37 градусов южной широты...".
SvUser1. По всем столбцам типа cr.ord_date добавить индекс.
Зачем? Давайте для начала определимся с запросом(ами), а потом будем искать проблемы с выполнением. Новые индексы могут не иметь смысла и добавить проблем.
SvUser3. Можно еще ради эксперимента попробовать заменить на:
decode( :P2_DATE_FILTER_TYPE, 1, cr.ord_date, 2, tt.arrival_date, ... ) between to_date(:P2_DATE_FROM, 'dd.mm.yyyy') and to_date(:P2_DATE_TO, 'dd.mm.yyyy')
Думаю, мало что изменится.

haXbatИначе какой смысл вообще выполнять запрос, если пользователь ввел в поле вместо корректной даты "10" или воообще "валера" ?

А что такое "корректная дата"? '01-Jan-11' - это корректная дата? :) Всё зависит от явного формата, указанного в атрибутах поля, и формата по умолчанию, который будет использоваться при отсутствии в to_date / to_char.
SvUser4. Создание Dynamic IR http://www.oracleapplicationexpress.com/tutorials/71
Ссылка показывает работу с коллекциями, но на этом не останавливается. Главное, чтобы ТС вовремя остановился...

Alexggg99 , включите Debug на своей странице с отчётом, возьмите запрос со всеми обёртками APEX и покажите его нам. Отключите Debug, выполните трассировку . В трассе должен быть план выполнения. Мне кажется, среди шагов в этом плане будет MERGE JOIN CARTESIAN. Но лучше не гадать, а увидеть.

Можете обратиться с запросом и планом в основной форум Oracle . Там Вам подкинут идей.

И откажитесь от идеи универсального запроса, ищущего события за период по куче таблиц с датами, которые ещё и соединяются между собой. Используйте несколько запросов (через фильтры и сохранённые отчёты, через процесс и коллекции). Или используйте одну таблицу-журнал, регистрирующую события по сущности (заказ, отправление, ГТД, финансовые расчёты), возможно - материализованное представление; по этому журналу и ищите, а затем выводите всё нужное.

haXbatВот вам истина последней инстанции ).

Тёма, может быть, и хороший дизайнер, но апеллировать к нему здесь - недальновидно. Разработчик приложений APEX, Oracle и вообще БД из него, как из меня балерина.

Во-первых, помните, что удобство использования (usability) и эстетическая красота - величины обратно зависимые. Тёте Гале удобно видеть вначале год, потом месяц, а затем число, а традиции русской типографики (Вы на них ссылаетесь, кстати) и размышления о них матерщинника Татьяныча её не волнуют. Тётя Оля поддерживает её и хочет видеть в поле "Месяц отчётности" значение "Январь 2009", а не "01.01.2009". Если им так работать удобно , и они работу делают за счёт этого быстрее - я их мнение разделяю полностью. Потому что считаю, что в случае конфликта удобство пользователя важнее красоты.

Во-вторых, не указывая явно to_date() и формат, Вы перекладываете эту работу на Oracle. Который пытается преобразовать Вашу строку в дату, используя NLS_DATE_FORMAT и правила преобразования. И у него может получиться. А может и нет. А может и вовсе каша выйти. Не стоит оставлять такие вещи на волю случая, лучше явно указывать to_date и формат. Возможно, в 4.1 этот момент наконец-то изменится, и к переменным, представляющим собой Date Picker, будут привязываться значения-даты с учётом формата из соответствующего атрибута.