Соединение с базой данных Соединение с таймером

Question

У меня есть сервер tomcat, вызывающий хранимую процедуру из jsp. В хранимой процедуре у меня есть запрос, который заполняет временную таблицу данными. Затем эта временная таблица соединяется с другой таблицей через dblink, чтобы заполнить другую таблицу темп, используя подсказку - DRIVING_SITE. Последняя временная таблица затем соединяется с другой таблицей в нашей базе данных, чтобы вернуть набор результатов в tomcat.

Извините, но я не могу представить пример кода для всего этого, но проблема, с которой я столкнулась, - это то, что через некоторое время ссылка на базу данных не используется, первый запрос, сделанный с использованием ссылки ничего не будет делать и возвращать ошибку:

test.jsp caught exception, closing connection: ORA-02068: following severe error from DATABASE_LINK_NAME 
ORA-03135: connection lost contact 

Каждый последующий запрос сделанный на ссылку базы данных в течение 10 минут или около последнего вызова будет хорошо. Таблица temp может быть огромной или малой, количество запрошенных данных, похоже, не имеет значения, но первый вызов после простоя получит эту ошибку, вероятно, в 75% случаев. Кто-нибудь испытал эту проблему? Если да, есть ли какие-либо резолюции?

Запрос структурирована следующим образом:

INSERT INTO temp_table_2 
WITH last_submissions AS (
    SELECT /*+ DRIVING_SITE(some_schema.some_table_1) */ 
      bs.unique_id, 
      CASE WHEN COUNT(bs.unique_id) > 1 THEN 'Y' ELSE 'N' END some_flag, 
      MAX(trx.unique_id) last_submission 
    FROM (SELECT unique_id 
      FROM temp_table_1) oids, 
      some_schema.some_table_1@DATABASE_LINK bs, 
      some_schema.some_table_1@DATABASE_LINK trx 
    WHERE oids.unique_id = bs.unique_id 
     AND bs.non_unique_join_id = trx.non_unique_join_id 
    GROUP BY bs.unique_id), 
something_relevant AS (
    SELECT /*+ DRIVING_SITE(some_schema.some_table_2) */ 
      last_value_of_something.unique_id, 
      last_value_of_something.some_flag, 
      mv.value_description status 
    FROM (
     SELECT /*+ DRIVING_SITE(some_schema.some_table_1) */ 
       ls.unique_id, 
       CASE WHEN COUNT(ls.unique_id) > 1 THEN 'Y' ELSE 'N' END some_flag, 
       MAX(prd.prd_some_id) last_submission 
     FROM last_submissions ls, 
       some_schema.some_table_1@DATABASE_LINK trx, 
       some_schema.some_table_2@DATABASE_LINK prd 
     WHERE ls.last_submission = trx.unique_id 
      AND trx.some_unique_id = prd.some_unique_id (+) 
     GROUP BY ls.unique_id) last_value_of_something, 
     some_schema.some_table_2@DATABASE_LINK prd, 
     some_schema.some_table_3@DATABASE_LINK cs, 
     some_schema.some_display_value_table@DATABASE_LINK mv 
    WHERE last_value_of_something.last_submission = prd.prd_some_id (+) 
     AND prd.some_id = cs.some_id (+) 
     AND cs.status_code = mv.value (+) 
     AND mv.value_type (+) = 'SOME_INDICATOR_FOR_DISPLAY_VALUES') 
SELECT ls.unique_id unique_id, 
     NVL(pr.status, trx.some_code) status, 
     CASE WHEN ls.some_flag = 'Y' OR pr.some_flag = 'Y' THEN 'Yes' ELSE 'No' END display_the_flag 
FROM /*+ DRIVING_SITE(some_schema.some_table_1) */ 
     last_submissions ls, 
     some_schema.some_table_1@DATABASE_LINK trx, 
     something_relevant pr 
WHERE ls.last_submission = trx.unique_id 
    AND ls.unique_id = pr.unique_id 

Answer 1

Ожидаете ли Вы сеть между двумя серверами баз данных, чтобы быть стабильной и разрешить соединения существовать в течение некоторого времени?

Когда вы используете ссылку базы данных, локальный сервер открывает соединение с удаленным сервером. Это соединение будет оставаться открытым, пока ваш сеанс открыт для использования другими запросами. Если вы видите, что соединения отбрасываются, это часто означает, что в сети есть что-то (брандмауэр), который обнаруживает и убивает незанятые соединения. Это также может означать, что сеть между двумя серверами просто нестабильна.

В идеале, вы решили бы эту проблему, исправив любую имеющуюся у вас проблему с сетью. Если есть брандмауэр, который убивает простоя подключений, вы должны иметь возможность изменить конфигурацию брандмауэра, чтобы избежать убийства этих подключений, например.

Если фиксируя инфраструктуру не вариант, вы можете закрыть соединение с удаленным сервером после каждого запроса (или, по крайней мере, после каждого запроса, который может последовать долгое время простоя)

ALTER SESSION CLOSE DATABASE LINK <<dblink name>> 

Это означает, однако, что вы настроили и разрывали соединение с удаленным сервером, потенциально на каждый запрос, - это потенциально относительно дорого и потенциально вызывает большую нагрузку на удаленный сервер (в зависимости, конечно, от того, как часто это происходит и сколько сеансов у вас может быть).

Весь процесс вытягивания данных по ссылке базы данных в ряд временных таблиц для обслуживания данных для человека с использованием веб-приложения также поражает меня как потенциально проблемную архитектуру. Возможно, у вас есть веские причины для этого. Но я бы решительно рассмотрел возможность использования какой-то технологии репликации (материализованные представления, потоки или GoldenGate - это встроенные параметры), а не вытягивание данных во время выполнения по ссылкам на базы данных.