Люди! Подскажите как бороться с зависшими соединениями.
Что реально происходит:
Юзера работают, работают, создают всякие отчеты (простые и сложные), затем случайно запускается одновременно несколько тяжелых задач. Естественно все начинает тормозить. Дольше кто-то из юзеров не выдерживает пытки ожиданием и через CTRL-ALT-DEL вырубает свою программу. В большинстве случаем соединение этого пользователя (со статусом ACTIVE) самостоятельно дорабатывает до конца и благополучно отстреливается. Но некоторые продолжают жить со статусом ACTIVE бог знает сколько времени. Хотя реально процедуры рабатуют макимум 5 мин.
Как правило подвисает на следующем операторе:
INSERT INTO tbl SELECT ...
Причем никаких блокировок для этого соединения вроде бы нет.
В ручную эти соединения убить можно (добрые люди подсказали через ORAKILL, а то ALTER SYSTEM KILL SESSION только помечает на удаление ).

Подскажите что надо настроить на сервере, чтобы такие соединения отстреливать автоматом (параметр sqlnet.expire_time = 1)?

PS: не знаю важно ли это, но вставка строк идет во временную таблицу (CREATE GLOBAL TEMPORARY TABLE tbl(...) ON COMMIT PRESERVE ROWS)

Заранее благодарен.

OraKill.exe програмка (в NT находится в каталоге BIN оракла). Позволяет грохать все процессы (соединения) оракла по ID процесса.

Вот копался и обнаружил такую штуку:
-при просмотре v$transaction я увидел, что на зависшую сессию приходятся
ДВЕ ТРАНЗАКЦИИ!!!
Как это такое может быть (какова рашифровка по v$transaction)?
PS:Сервак 2*CPU
на всякий случай привожу результат SELECTA из V$TRANSACTION (для зависшей сессии)
\nADDR XIDUSN XIDSLOT XIDSQN UBAFIL UBABLK
-------- ------ ------- ------ ------ ------
041469F0 2 37 10157 2 593
04146D60 2 16 10155 2 595

UBASQN UBAREC STATUS START_SCNB START_SCNW
------ ------ ------ ---------- ----------
16204 5 ACTIVE 14130236 0
16204 1 ACTIVE 14130237 0

START_UEXT START_UBAFIL START_UBABLK START_UBASQN
---------- ------------ ------------ ------------
97 2 592 16204
97 2 594 16204

START_UBAREC SES_ADDR FLAG SPA REC NOU PTX
------------ -------- -------- --- --- --- ---
4 03EB0BF0 7683 NO NO NO NO
1 03EB0BF0 67112483 NO YES NO NO

PRV_XIDUSN PRV_XIDSLT PRV_XIDSQN PTX_XIDUSN
---------- ---------- ---------- ----------
0 0 0 0
2 37 10157 0

PTX_XIDSLT DSCN-B DSCN-W USED_UBLK USED_UREC
---------- -------- ------ --------- ---------
0 14129634 0 2 12
0 14129634 0 2 2

LOG_IO PHY_IO CR_GET CR_CHANGE
--------- ------ ------ ---------
194701402 97 1088 59908176
194701332 0 2 59908099

В данном случае автономные транзакции не используются.

А по поводу вывода к таблице v$transaction насторожила следующая штука:
-в столбце REC (рекурсивная транзакция) для одной транзакции стоит YES, а для другой NO, причем из v$session ссылка идет только одну из этих транзакций, вторая делает непонятно, что!!!

Наконец, то добил эту гадину!!!
Итак обнаружил следующую вещь:
-как только я с временных таблиц, в которые производится insert, убрал все constraints, так сразу зависания insert пропали (уже 5 дней работает)
При constaraint зависания происходили (1 в 2 дня)

Вот вопрос: это у меня Oracle8i так глючит (8.1.5 на NT2000) или это такая особенность временных таблиц?