Чи є час очікування на запит посилання на базу даних?

Редагування / передмова: Це питання перенесено з SO, тому що мене особливо цікавить питання про час очікування на запити посилань БД. Запропонований спосіб вирішення проблем SO дещо нормальний, але мене дуже цікавить саме питання.

Мотивація: у
мене був один запит, виконаний "назавжди" (більше 2 днів, поки я не вбив сеанс), який використовував посилання на базу даних. Проблема здавалася в тому, що віддалена база даних стала недоступною, і з якихось ще невідомих причин не ORA-02068було піднято (про що тут не йдеться), а запит просто чекав і чекав.

(Запит видається роботою dbms_scheduler, яка виконує процедуру в пакеті PL / SQL. Як наслідок, завдання також застрягло. Але це не представляє особливого інтересу для суті цього питання)

Я імітував цю ситуацію, поставивши один із моїх тестових БД у режим спокою і запитував його по посилання на базу даних. Як і передбачалося, запит чекав, поки або вручну скасовується або віддалена БД не буде видалена.

Питання:
Я не контролюю поведінку віддаленої бази даних та час роботи, тому я шукаю певну можливість встановити тайм-аут на запит, який використовує посилання на базу даних.

Я вже розглядав профілі ( CPU_PER_CALLтощо), sqlnet.oraпараметри, додаючи параметри локальних імен безпосередньо в рядок підключення (наприклад, додавання (connect_timeout=10)до визначення посилання на базу даних), виконуючи команду з ... for update wait 1, але вони або працюють для зайнятих або простоюючих сесій, але не на сеанси в очікуванні.

Тому я шукаю певний варіант на "локальній" стороні посилання на базу даних, який встановлює тайм-аут для запитів по посиланнях на бази даних.
Деякі рішення подобаються alter session set xyzабо select ... from a@b "wait 100" --(yes, I know this syntax doesn't exist)будуть вдячні, оскільки я не маю прав DBA на ці конкретні БД.

Зараз я перебуваю на 10gR2, але оновлення до 11gR2 за кілька тижнів, тому ідеї для будь-якої з цих версій будуть корисні.

Оскільки ви використовуєте dbms_scheduler, ви можете встановити атрибут max_run_duration завдання до деякого обмеження, а потім надіслати вам електронний лист-планувальник, якщо ця подія буде підвищена. Позаду Oracle використовує таблиці з чергою (за допомогою яких можна створювати завдання, які запускаються, коли подія піднімається , якщо ви хочете зробити додаткові кроки, щоб зробити більше автоматизації щодо вашої відповіді). Але в основному будь-яка робота, яка працює над налаштуванням max_run_duration, підніме тип події: JOB_OVER_MAX_DUR

Елемент електронної пошти побудований у 11гр2, дивіться тут для гарного запису.

Сподіваюся, що це допомагає.

Я не кажу, що у мене є рішення, але я також хотів би більше обговорити, як контролювати час очікування dblink. Я припускаю, що можна було б написати код, який запускає подію, або чекає події тайм-ауту TNS, а потім виконує:

ALTER SESSION CLOSE DATABASE LINK dblink;

Ви, звичайно, можете запитати віддалений сервер, перш ніж:

select * from dual@dblink

перевірити, чи він доступний, але це не вирішує проблему коду, який працює надто довго на пульті дистанційного керування. Неправильний віддалений код повинен викликати події очікування, тому я припускаю, що вони можуть бути захоплені (навіть на рівні класу в 12c). Це все ще не дає нам елегантного рішення примусити сеанс dblink до тайм-ауту.