Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
mayton
Member

Откуда: loopback
Сообщений: 49768
Добрый день, уважаемые DBA.

Сессии, которые умерли по IDLE_TIME переходят в состояние SNIPED. И находятся там слишком долго. Вследствие этого новые соединения не могут создаватся (такова политика) по превышению SESSIONS_PER_USER.

Выставили в клиенте параметр SQLNET.EXPIRE_TIME=10.

Не помогло.

Дайте совет, что делать.


Протестировано на:

Сервер: Oracle10.2.0.3 HP-Unix 64
Клиент: Oracle10.2.0.3 (Win32)
14 дек 07, 16:22    [5050771]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
хрхр
Guest
запускать скрипт периодически и убивать все сесии в состоянии SNIPED
14 дек 07, 16:25    [5050798]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
AG#
Member

Откуда: Российская Федерация
Сообщений: 2305
SQLNET.EXPIRE_TIME тут совсем не из той серии...
14 дек 07, 16:28    [5050826]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
mayton
Member

Откуда: loopback
Сообщений: 49768
хрхр
запускать скрипт периодически и убивать все сесии в состоянии SNIPED


О джобе мы подумали сразу. В первую же очередь. Однако сначала хотим перебрать все варианты настроек Oracle и сетевого окружения чтобы добится требуемого эффекта без периодических alter system disconnect.
14 дек 07, 16:29    [5050834]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
хрхр
Guest
mayton
хрхр
запускать скрипт периодически и убивать все сесии в состоянии SNIPED


О джобе мы подумали сразу. В первую же очередь. Однако сначала хотим перебрать все варианты настроек Oracle и сетевого окружения чтобы добится требуемого эффекта без периодических alter system disconnect.


Не надо job, напишите os-скрипт+sqlplus скрипт, запускайте по cron-у, и сессии удаляйте kill -9
14 дек 07, 16:33    [5050870]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
jmar
Member

Откуда: Мариуполь
Сообщений: 36
Взято с metalink:
Solution Description
--------------------

On Unix, and if using a dedicated server, use the following shell script to
kill the shadow process (script has been tested on Solaris, AIX, Tru64 and
HPUX):

#!/bin/sh
tmpfile=/tmp/tmp.$$
sqlplus system/manager <<EOF
spool $tmpfile
select p.spid from v\$process p,v\$session s
where s.paddr=p.addr
and s.status='SNIPED';
spool off
EOF
for x in `cat $tmpfile | grep "^[0123456789]"`
do
kill -9 $x
done
rm $tmpfile

NOTE: Please beware that if you are running in a shared server environment
you do not accidently kill your dispatchers and/or shared servers.
See Note 120135.1.
14 дек 07, 16:46    [5051004]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
mayton
Member

Откуда: loopback
Сообщений: 49768
AG#
SQLNET.EXPIRE_TIME тут совсем не из той серии...


Возможно вы правы.

Поделюсь тем, что я заметил опытным путём.

Эксперимент 1

Допустим я запустил SQL*Plus и находился INACTIVE длительное время. Моя сессия перешла в SNIPED. Транзакции откатились. Но при этом сессионный процесс Oracle остаётся живой. Если я, в этой сесси сделаю следующее.

автор
SQL> select * from dual;
select * from dual
*
ERROR at line 1:
ORA-02396: exceeded maximum idle time, please connect again


И только после отправки этого сообщения сессия завершается.

Эксперимент 2

Те-же самые условия, но я отключаю клиента физически (отключаю сетевой коннектор). В этом случае, сессия уходит из v$session очень быстро. Практически сразу-же после SNIPED.
14 дек 07, 17:22    [5051285]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
AG#
Member

Откуда: Российская Федерация
Сообщений: 2305
Да тут даже с практической точки зрения все равно хуже чем предложенный выше вариант(еще и самим oracle).
Вы будете сотни-тысячи клиентов настраивать(даже не важно как технически) и следить за ними ? Проще на сервере одну процедуру сделать.
14 дек 07, 17:39    [5051393]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
mayton
Member

Откуда: loopback
Сообщений: 49768
AG#
Вы будете сотни-тысячи клиентов настраивать(даже не важно как технически) и следить за ними ? Проще на сервере одну процедуру сделать.


Процентов 80 сидят на Citrix.

Оставшиеся машины полностью подконтрольны и находятся в Windows домене. Так что если надо будет вбить какой-то фикс в sqlnet - проблем не будет.

Знать бы только что вбить...
14 дек 07, 19:32    [5051876]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
denix1
Member

Откуда: Киев
Сообщений: 4656
mayton
Знать бы только что вбить...

kill -9 ...
15 дек 07, 21:01    [5053885]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
Ааз
Member

Откуда: Москва/Протвино
Сообщений: 4274
mayton
Выставили в клиенте параметр SQLNET.EXPIRE_TIME=10. ...
Сервер: Oracle10.2.0.3 HP-Unix 64
Поставьте на сервере и рестартуйте экземпляр. Ежели не поможет (в 10g должнО) - гляньте в мой блог про KeepAlive.

Всего
15 дек 07, 23:53    [5054216]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
denix1
Member

Откуда: Киев
Сообщений: 4656
Ааз
mayton
Выставили в клиенте параметр SQLNET.EXPIRE_TIME=10. ...
Сервер: Oracle10.2.0.3 HP-Unix 64
Поставьте на сервере и рестартуйте экземпляр. Ежели не поможет (в 10g должнО) - гляньте в мой блог про KeepAlive.

так вроде ж ситуация не та...
тут сессии пытаются отключить по неактивности - IDLE_TIME
а не они сами погибают без нотификации сервера...
или я чего-то пропустил ?
16 дек 07, 10:46    [5054762]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
mayton
Member

Откуда: loopback
Сообщений: 49768
Ааз
..


denyx1
..


Спасибо. То что надо. Я выставлял параметры на клиенте, а нужно было на сервере.

Попробую этот вариант. Если не прокатит - будем крутить KEEP_ALIVE.
16 дек 07, 13:55    [5054904]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
denix1
Member

Откуда: Киев
Сообщений: 4656
mayton
То что надо. Я выставлял параметры на клиенте, а нужно было на сервере.

Попробую этот вариант. Если не прокатит - будем крутить KEEP_ALIVE.

отпишите пожалуйста о результатах!
16 дек 07, 22:13    [5055626]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
mayton
Member

Откуда: loopback
Сообщений: 49768
denix1
отпишите пожалуйста о результатах!


Хорошо.
16 дек 07, 22:49    [5055696]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
Ааз
Member

Откуда: Москва/Протвино
Сообщений: 4274
denix1
так вроде ж ситуация не та...
тут сессии пытаются отключить по неактивности - IDLE_TIME
а не они сами погибают без нотификации сервера...
или я чего-то пропустил ?
Та или не та ситуация... определяется тем, есть еще живой канал (IP1:PORT1-IP2:PORT2), или он уже закрыт одной из сторон - например, веб-броузером или кривоватым сервером приложения.

Когда канал связи между клиентом и серверным процессом закрыт так, что серверному процессу об этом неизвестно...

Для проверки "живости" канала можно пользовать DCD (Dead Connection Detection) или KeepAlive - первый способ предпочтителен, поскольку родной Oracle'иный, от платформы (в данном случае не только от ОС, но и от нижележащего протокола) независимый... Да еще в 10g доулучшенный (скажем так).

В остальном пометка сеанса как SNIPED по истечении IDLE_TIME похожа на ситуацию, когда такого лимита не в профиле не выставлено, но сеанс клиента прибили через "ALTER SYSTEM KILL/DISCONNECT"). Если в момент "убития" (или тем более истечения IDLE_TIME) серверный процесс не был активен, и не собирался пересылать ничего клиенту, он (сервеный процесс) будет тупо ждать клиента... Чтобы при очередном обращении клиента сказать ему "нас убили" или "у нас истек лимит времени простоя").

Важен тут факт, что сам сервеный процесс не инициирует никакого обмена данными с клиентом по собственной инициативе (если не включен DCD или KeepAlive). Даже если с "человеческой" точки зрения сообщение срочное.

Всего
17 дек 07, 01:43    [5055938]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
denix1
Member

Откуда: Киев
Сообщений: 4656
Ааз
...

значит пока ничего не пропустил :)
17 дек 07, 11:07    [5056588]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
AG#
Member

Откуда: Российская Федерация
Сообщений: 2305
mayton
denix1
отпишите пожалуйста о результатах!


Хорошо.


И как результаты ? Вышло что-нибудь на вашей платформе ?
Попробовал сейчас на БД oracle 10.2.0.3 под linux и клиентом windows 2K, что-то у меня ничего не получилось с DCD :(
Именно ситуация со SNIPED, когда связь физически не рвется, а просто клиентская сессия sqlplus(windows) простаивает.Интересно просто как на HP-UX + Win32
17 дек 07, 14:59    [5058301]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
mayton
Member

Откуда: loopback
Сообщений: 49768
2 Все.

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

С уважением.
17 дек 07, 16:43    [5059061]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
Ааз
Member

Откуда: Москва/Протвино
Сообщений: 4274
AG#
Именно ситуация со SNIPED, когда связь физически не рвется, а просто клиентская сессия sqlplus(windows) простаивает.Интересно просто как на HP-UX + Win32
Внеплатформенно. Ежели связь есть, то механизЬмы обнаружения разрыва связи бессильны :-)

Всего
18 дек 07, 00:52    [5060637]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
AG#
Member

Откуда: Российская Федерация
Сообщений: 2305
Ааз
[quot AG#]


почему-то так и думал.... :)
Ну вот облом, а я уж подумал что в механизме 10.2.0.3 чего такого нового начало появляться ... :-)

2 автору с его клиентами на Citrix счастье c disconnect sniped думаю все-равно особо не грозит :) исключая конечно фатальные случаи падения всего Citrix or net
18 дек 07, 20:17    [5065615]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
Ааз
Member

Откуда: Москва/Протвино
Сообщений: 4274
AG#
почему-то так и думал.... :)
Ну вот облом, а я уж подумал что в механизме 10.2.0.3 чего такого нового начало появляться ... :-)
Не скажи. Например, раньше в ситуации

- бд_1 -> dblink -> бд_2
- фактически, бд_1 является клиентом для бд_2 (!)

при удалённом вызове процедуры или "долгоиграющего" запроса из бд_1 в бд_2, и при наличии SQLNET.EXPIRE_TIME в sqlnet.ora на сервере бд_1 (заметь, предназначено для разборок с клиентами, соединяющимися с бд_1), случались обломы - серверный процесс на бд_2, обслуживающий соединение по dblink'у, был "слишком занят", чтобы вовремя отвечать на "пинги" от DCD... И его "коллега" на бд_1 закрывал соединение.

Эти ситуации теперь (в 10gR2 точно, 10gR1 не проверялся, в 9i IIRC как-то фифти-фифти) разруливаются корректно. Т.е. я предполагаю, что добавлен асинхронный (по времени появления DCD-пакета) механизм обработки.

По моему опыту - большой плюс. Иначе приходилось задействовать KeepAlive - таки сторонний для Oracle RDBMS механизм.

Всего
19 дек 07, 00:10    [5066125]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
mayton
Member

Откуда: loopback
Сообщений: 49768
Привет всем.

Поделюсь ситуацией на сегодняшний день.

1) Сетевой администратор высказал своё недоверие по поводу использования KEEP_ALIVE в нашей сети. Он считает, что есть рабочие станции, которые могут неадеватно отреагировать на тест ALIVE и дисконнектить работающие сессии (даже если они будут активны). По этому поводу дискуссия еще не закрыта.

Есть еще одна причина, по которой мы не хотим рубить сессии. Один из ведущих специалистов по биллингу поделился со мной наблюдением. Есть группа технологов, которые запускают пакетные задания. Выглядит это так. Оператор заходит в клиент (двухзвенка Sybase-Oracle) забивает в формочку параметры и толкает хранимую PL/SQL процедуру. Потом девушка-оператор (!!!) заходит в task-manager и прибивает (!!!) процесс своего клиента. Хранимка при этом продолжает работать и работает до конца. Результат сбрасывается в таблицы отчётов. Их потом можно посмотреть. Зачем они (операторы) так делают бог его знает. Так повелось исторически. Но этот момент также добавляет больше вопросов в отношении KEEP_ALIVE и заставляет нас ломать головы над организацией труда в сторонних подразделениях корпорации.

Короче пока отложили.

2) С джобом не вышло. Если давать команду disconnect на узле, отличном от того, где висит снятая сессия то команда отрабатывает с ошибкой.

SQL> alter system disconnect session '756,58984' immediate;
alter system disconnect session '756,58984' immediate
*
ERROR at line 1:
ORA-00030: User session ID does not exist.

Как гарантировать порождение джоба в определённом узле я не знаю.

В принципе у меня была мысль написать софт для коннекта к инстансу, но ... пока отложили.

3) Килять сессии скриптом ОС - пока тоже отложили.

4) Посоветовавшись решили снять resource_limit. Как только будут проблемы нехватки ресурсов - вернём обратно и будем ковырять sqlnet и TCP/IP.


Вот такие вот дела, уважаемые коллеги.
19 дек 07, 11:51    [5067400]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
denix1
Member

Откуда: Киев
Сообщений: 4656
mayton

Как гарантировать порождение джоба в определённом узле я не знаю.

DBMS_JOB.SUBMIT
...
 INSTANCE                       BINARY_INTEGER          IN     DEFAULT
...
19 дек 07, 12:09    [5067509]     Ответить | Цитировать Сообщить модератору
 Re: Oracle10:HP-Ux:Сессии слишком долго висят в SNIPED.  [new]
mayton
Member

Откуда: loopback
Сообщений: 49768
denix1
mayton

Как гарантировать порождение джоба в определённом узле я не знаю.

DBMS_JOB.SUBMIT
...
 INSTANCE                       BINARY_INTEGER          IN     DEFAULT
...


Спасибо. Попробуем.
19 дек 07, 12:17    [5067567]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить