Оракловский Database Control (web-интерфейс) при действиях, связанных с важными параметрами базы, требует ввести т.н. Host Credentials – имя и пароль пользователя системы, от имени которого будут вносится изменения.
Соответствующий юзер должен входить в группу Администраторы и у него должны быть права для входа в качестве службы
Выставляем тут: Панель управления – Администрирование – Локальные политики – Назначение прав пользователей – добавить «Вход в качестве службы»

Для полной локализации требуется заменить кнопки Next и Previous в регионе отчета. Они появляются при включении опции Partial Page Refresh – эта штука разбивает полученные запросом данные на несколько страниц и позволяет AJAXовое перемещение между этими страничками.

Ну так вот, лезем в Application>Shared Components>Templates
там выбираем установленный для отчета (Report) шаблон, переходим во вкладку Pagination, и вставляем в поле «Next Page Template» след. код:

<a href="#LINK#" style="margin-left:5px;"><img src="#IMAGE_PREFIX#jtfunexe.gif" alt="" /></a>

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

В дополнение к мерам, приведенным в статье «Оценка производительности» и обязательной оптимизации SQL запросов:

есть в БД Oracle такой параметр SHARED_SERVERS (постоянно поддерживаемое количество сервер-процессов в базе).  А APEX использует для запросов к базе connection pool (набор сессий), причем даже в рамках одной сессии Апекса запросы могут идти к базе по разным сессиям connection pool’а . Не зная остальных тонкостей, предположу, что на одну сессию к базе приходится один сервер-процесс.

Для нас это означает, что первый запрос в рамках сессии апекса, а также запросы после длительного простоя пользователся апекса (определяемого таймаутом сессий)  будут происходить дольше обычного. Сервер процессы еще не запущены/уже остановлены по таймауту.
Смотрим количество процессов:

select * from V$SHARED_SERVER;

Так вот выставляем постоянный уровень готовых сервер-процессов и радуемся приросту скорости Апекса)

ALTER SYSTEM SET SHARED_SERVERS=20 SCOPE=BOTH;

Милисекунды я не замерял, но улучшение есть.

Обсуждение вопроса с производительностью апекса на офиц. форумах

Имеем:

• Oracle DB 11g – 2 штуки (головная «MASTER_DB» и дочерняя «SLAVE11″)
• Oracle DB 10g R2 – 1 штука (дочерняя «SLAVE10″)

Во всех базах есть пользователь ANALYTICS с таблицей TT2.

Задача: настроить автоматическое обновление данных в головной базе при внесении изменений в дочерние.

Решение:

Для репликации будем использовать потоки данных (Oracle Streams). Суть технологии такова:

в базе создаются т.н. очереди сообщений (queues)  и процессы записи, передачи и считывания данных из этих очередей (Capture, Propagation и Apply соответственно). Все это взаимодействие называется Oracle Stream. Физически очереди сообщений – это записи в соответствующей таблице очередей.

Процесс Capture следит за обновлениями архивного журнала БД (archive log) и считывает все обновления, относящиеся к указанной таблице/табличному пространству/схеме/всей базе. Таким образом, процесс не мешает обычным транзакциям. Но при этом БД должна работать в режиме ведения журнала ARCHIVELOG.

В Enterprise Manager’е есть визард создания репликации, но мне не удалось заставить его сделать хоть что-нибудь вменяемое, поэтому действуем в основном через консоль

1. Проверяем, находится ли база в режиме ведения журнала через Enterprise Manager

Availability->Recovery Settings

через консоль включаем так:

shutdown immediate;
startup mount;
alter database archivelog;
alter database open;

2. Все потоки будут располагаться в отдельной схеме администратора потоков (Streams Admininstator). Создаем схему и юзера strmadmin во всех базах. Подробный мануал с картинками из документации к 11g
Обязательно даем ему роль DBA и дополнительно под юзером с DBA выполняем следующий код:

BEGIN
  DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE(
    grantee          => 'strmadmin',
    grant_privileges => TRUE);
END;

3. Создаем очередь. Заходим под strmadmin (все дальнейшие действия во всех базах тоже от имени strmadmin) и в каждой базе выполняем:

EXEC DBMS_STREAMS_ADM.SET_UP_QUEUE();

вкратце – процедура создает таблицу с именем STREAMS_QUEUE_TABLE и очередь STREAMS_QUEUE. В дочерних БД будем записывать изменения в эту очередь, а в головной – считывать из нее.
4. Для передачи данных из одной базы в другую, используется DB Link, причем со стороны дочерней базы.
Создаем ДБлинк к головной базе

CREATE DATABASE LINK MASTER_DB CONNECT TO strmadmin
  IDENTIFIED BY &password USING 'MASTER_DB';

В параметрах лисенера дочерних баз должно быть прописано соединение «MASTER_DB» с головной базой.

5. Под strmadmin’ом в SLAVE11 создаем процесс передачи данных  (propagation) из очереди в дочерней в очередь в головной базе

BEGIN
  DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES(
    table_name              => 'analytics.tt2',
    streams_name            => 'str1_to_str2',
    source_queue_name       => 'strmadmin.streams_queue',
    destination_queue_name  => 'strmadmin.streams_queue@MASTER_DB',
    include_dml             => TRUE,
    include_ddl             => TRUE,
    source_database         => 'SLAVE11',
    inclusion_rule          => TRUE,
    queue_to_queue          => TRUE);
END;

streams_name – произвольное название для потока передачи данных

source_queue_name – имя очереди из которой берутся данные
destination_queue_name – имя очереди на головной базе, куда все передается. Обязательно с указанием ДБлинка

6. Настраиваем процесс сбора изменений в SLAVE11 под strmadmin (capture)

BEGIN
  DBMS_STREAMS_ADM.ADD_TABLE_RULES(
    table_name     => 'analytics.tt2',
    streams_type   => 'capture',
    streams_name   => 'capture_simp',
    queue_name     => 'strmadmin.streams_queue',
    include_dml    => TRUE,
    include_ddl    => TRUE,
    inclusion_rule => TRUE);
END;

queue_name – название очереди, в которую записываются изменения

7.  Не очень понятная процедура, которая делает типа слепок с текущего состояния таблиц в обоих базах и устанавливает какие изменения будут реплицироваться, а какие нет. Выполняется в SLAVE11 (дочерней базе)

DECLARE
  iscn  NUMBER;
BEGIN
  iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER();
  DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN@MASTER_DB(
    source_object_name    => 'analytics.tt2',
    source_database_name  => 'SLAVE11',
    instantiation_scn     => iscn);
END;

8. В MASTER_DB, под strmadmin включаем процесс считывания и записи изменений (apply)

BEGIN
  DBMS_STREAMS_ADM.ADD_TABLE_RULES(
    table_name      => 'analytics.tt2',
    streams_type    => 'apply',
    streams_name    => 'apply_simp',
    queue_name      => 'strmadmin.streams_queue',
    include_dml     => TRUE,
    include_ddl     => TRUE,
    source_database => 'SLAVE11',
    inclusion_rule  => TRUE);
END;

9. Запускаем процессы считывания и записи
в базе MASTER_DB

BEGIN
  DBMS_APPLY_ADM.SET_PARAMETER(
    apply_name  => 'apply_simp',
    parameter   => 'disable_on_error',
    value       => 'N');
END;
/

BEGIN
  DBMS_APPLY_ADM.START_APPLY(
    apply_name  => 'apply_simp');
END;
/

в базе SLAVE11

BEGIN
  DBMS_CAPTURE_ADM.START_CAPTURE(
    capture_name  => 'capture_simp');
END;

Такая репликация будет отслеживать DDL и DML изменения таблицы.

Источники:

Simple Single-Source Replication Example
Common Data Replication and Integration Tasks