Czy istnieje limit czasu dla zapytania dotyczącego łącza do bazy danych?

Edycja / Przedmowa: To pytanie zostało przeniesione z SO, ponieważ jestem szczególnie zainteresowany pytaniem o przekroczenia limitu czasu w zapytaniach do łącza DB. Dostarczone obejście z SO jest nieco OK, ale naprawdę interesuje mnie samo pytanie.

Motywacja:
miałem jedno zapytanie działające „na zawsze” (ponad 2 dni, dopóki nie zabiłem sesji), które używało łącza do bazy danych. Wydawało się, że problem polega na tym, że zdalna baza danych stała się niedostępna i z jakiegoś jeszcze nieznanego powodu nie ORA-02068zgłoszono żadnego (nie do omówienia tutaj), a zapytanie tylko czekało i czekało.

(Zapytanie jest wysyłane przez zadanie dbms_scheduler, które wykonuje procedurę w pakiecie PL / SQL. W rezultacie zadanie również zostało zablokowane. Ale to nie jest szczególnie interesujące dla sedna tego pytania)

Symulowałem tę sytuację, wprowadzając jedną z moich testowych baz danych w tryb wyciszenia i sprawdziłem ją przez łącze do bazy danych. Zgodnie z przewidywaniami kwerenda czekała na ręczne anulowanie lub zdalne wykonanie DB.

Pytanie:
Nie mam kontroli nad zachowaniem i czasem działania zdalnej bazy danych, dlatego szukam możliwości ustawienia limitu czasu dla zapytania korzystającego z łącza do bazy danych.

Przeglądałem już profile ( CPU_PER_CALLitp.), sqlnet.oraParametry, dodawanie lokalnych parametrów nazewnictwa bezpośrednio do ciągu połączenia (np. Dodawanie (connect_timeout=10)do definicji łącza do bazy danych), uruchamianie komendy ... for update wait 1, ale albo działają one dla zajętych lub bezczynnych sesji, ale nie na sesje oczekujące.

Dlatego szukam opcji po „lokalnej” stronie łącza do bazy danych, która określa limit czasu dla zapytań dotyczących łączy do bazy danych.
Niektóre rozwiązania podobają się alter session set xyzlub select ... from a@b "wait 100" --(yes, I know this syntax doesn't exist)byłyby mile widziane, ponieważ nie mam uprawnień DBA do tych konkretnych DB.

Obecnie używam 10gR2, ale w ciągu kilku tygodni przeprowadzę aktualizację do 11gR2, więc pomysły na każdą z tych wersji będą przydatne.

Ponieważ używasz dbms_scheduler, możesz ustawić atrybut max_run_duration zadania na pewien limit, a następnie poprosić program planujący o wysłanie e-maila, jeśli to zdarzenie zostanie zgłoszone. Za kulisami Oracle wykorzystuje tabele kolejkowania (które mogą umożliwić tworzenie zadań uruchamianych po wystąpieniu zdarzenia , jeśli chcesz wykonać dodatkowe kroki w celu zwiększenia automatyzacji odpowiedzi). Ale w zasadzie każde zadanie przebiegające przez skonfigurowany czas trwania max_run_duration wywoła typ zdarzenia: JOB_OVER_MAX_DUR

Wiadomość e-mail jest zbudowana w wersji 11gr2, zobacz tutaj, aby napisać dobrze.

Mam nadzieję, że to pomaga.

Nie mówię, że mam rozwiązanie, ale chciałbym też więcej dyskusji na temat kontrolowania limitu czasu dblink. Przypuszczam, że można sobie wyobrazić napisanie kodu, który uruchamia zdarzenie lub czeka na przekroczenie limitu czasu TNS, a następnie wykonuje:

ALTER SESSION CLOSE DATABASE LINK dblink;

Oczywiście możesz wcześniej sondować zdalny serwer za pomocą:

select * from dual@dblink

aby sprawdzić, czy jest dostępny, ale to nie rozwiązuje problemu zbyt długiego działania kodu na pilocie. Zły zdalny kod powinien wywoływać zdarzenia oczekiwania, więc przypuszczam, że mogą one zostać uwięzione (nawet na poziomie klasy w 12c). To wciąż nie daje nam eleganckiego rozwiązania zmuszania sesji dblink do przekroczenia limitu czasu.