[ТЕМА ЗАКРЫТА]
17.10.2006 14:54
reddevil
 
После перехода на Oracle9i и Windows2003, периодически происходит следующее:

После некоторого времени нормальной работы (24, 48 или более часов), клиент как будто бы перестает получать ответ от сервера,

То есть если например войти а Базовый Модуль СМ то загружается главная форма если же попытаться открыть какой либо раздел(Накладные, карточки),

То Базовый модуль просто зависает, при этом сессия в БД находиться в статусе INACTIVE. Примечание-клиенты у которых это происходит находяться в подсети отличной от той в которой находиться сервер БД. Однако при этом в тоже самое время подключение БД и работа с ней из других подсетей происходит нормально.

Прилкладываю последние строки трассировки клиента с уровнем SUPPORT. К сожалению на основании этих данных никаких выводов сделать не удалось. Проблема решается только перезагрузкой сервера, перезапуск базы и Listener никакого результата не дает.
Может кто сталкивался, иля хотя бы подскажет где еще покапать?[/code]
17.10.2006 14:55
reddevil
 
кусок тарассировки
Код:
snsbitcl_ts: entry
snsbitcl_ts: normal exit
nsdo: *what=1, *bl=2038
snsbitts_ts: entry
snsbitts_ts: acquired the bit
snsbitts_ts: normal exit
nsdo: nsctxrnk=0
snsbitcl_ts: entry
snsbitcl_ts: normal exit
nsdo: normal exit
nioqrc: exit
nioqsn: entry
nioqrc: entry
nsdo: entry
nsdo: cid=0, opcode=84, *bl=0, *what=1, uflgs=0x20, cflgs=0x3
snsbitts_ts: entry
snsbitts_ts: acquired the bit
snsbitts_ts: normal exit
nsdo: rank=64, nsctxrnk=0
snsbitcl_ts: entry
snsbitcl_ts: normal exit
nsdo: nsctx: state=8, flg=0x420d, mvd=0
nsdo: gtn=32, gtc=32, ptn=10, ptc=2047
nsdofls: entry
nsdofls: DATA flags: 0x0
nsdofls: sending NSPTDA packet
nspsend: entry
nspsend: plen=21, type=6
nttwr: entry
nttwr: socket 556 had bytes written=21
nttwr: exit
nspsend: 21 bytes to transport
nspsend: packet dump
nspsend:00 15 00 00 06 00 00 00  |........|
nspsend:00 00 03 05 39 01 00 00  |....9...|
nspsend:00 10 00 00 00 00 00 00  |........|
nspsend: normal exit
nsdofls: exit (0)
snsbitts_ts: entry
snsbitts_ts: acquired the bit
snsbitts_ts: normal exit
nsdo: nsctxrnk=0
snsbitcl_ts: entry
snsbitcl_ts: normal exit
nsdo: normal exit
nsdo: entry
nsdo: cid=0, opcode=85, *bl=0, *what=0, uflgs=0x0, cflgs=0x3
snsbitts_ts: entry
snsbitts_ts: acquired the bit
snsbitts_ts: normal exit
nsdo: rank=64, nsctxrnk=0
snsbitcl_ts: entry
snsbitcl_ts: normal exit
nsdo: nsctx: state=8, flg=0x420d, mvd=0
nsdo: gtn=32, gtc=32, ptn=10, ptc=2047
snsbitts_ts: entry
snsbitts_ts: acquired the bit
snsbitts_ts: normal exit
snsbitcl_ts: entry
snsbitcl_ts: normal exit
nsdo: switching to application buffer
nsrdr: entry
nsrdr: recving a packet
nsprecv: entry
nsprecv: reading from transport...
nttrd: entry
на этом конец .....
17.10.2006 15:03
EugeneT
 
Рутер между подсетями какой? Может рубит неактивные соединения или какие-то бродкасты.
17.10.2006 15:06
OlegON
 
Собака его знает, ты курсор sharing в force не выкручивал? У меня с этим на 8ке аналогичные косяки были, только, конечно, перегрузка базы лечила. Кстати, дистрибутив у тебя какой? Вроде 64-битный? Попробуй netstat, что у тебя там с количеством сессий?
17.10.2006 15:06
reddevil
 
да нет, сис.админ говорит что пакеты пролетают а потом перестают.
17.10.2006 15:07
reddevil
 
"Попробуй netstat" - с количеством сессий чего? в базе много но это происходит и ночью, когда пара десятков сессий, мне кажется что проблема в операционке - 2003х64 R2
17.10.2006 15:11
OlegON
 
Нет, тут про TCP-сессии, у меня аналогичная засада была с ослом, открывал невиданное количество сессий, которые так и зависали
Проблемы с TCP/IP
в итоге винда впадала в ступор до перезагрузки.
17.10.2006 15:17
OlegON
 
Гейт не линуксовый? У меня было такое, что гейт, собака, почему-то оставлял сессии в состоянии ESTABILISHED, хотя комп уже давно был выключен. Иными словами, как будет поменьше сессий, иди на сервак и набирай в консоли netstat, должно быть ровно столько сессий, сколько ты ожидаешь, а не больше. А параметр по ссылке выше по любому можешь попробовать поменять.
17.10.2006 15:17
reddevil
 
одно но, у меня винда работает и остальные клиенты (с других подсетей тоже работают)
17.10.2006 15:20
EugeneT
 
Все подсети через один рутер ходят?
17.10.2006 15:22
OlegON
 
Да, это я неправильно высказался. Именно сдыхали подключения. Винда жила, нормально работала во всем, кроме сети. Хм, вчитался, из других подсетей? Т.е. есть подсеть, которая этим страдает? Может сетевуха отдельная и роутинг слетает или она сама глючит?
17.10.2006 15:28
reddevil
 
Цитата:
EugeneT Все подсети через один рутер ходят?
да через один
17.10.2006 15:34
EugeneT
 
Клиенты дохнут после некоторого простоя? Наяваять прожку или батчик делающую простенький select в цикле и посмотреть заткнется ли.

Added: Глюки только с СМ? Пинги там, принтеры, ресурсы других подсетей видны и доступны? К шарам на сервере СМ подключится можешь?
17.10.2006 15:40
reddevil
 
Цитата:
EugeneT Клиенты дохнут после некоторого простоя? Наяваять прожку или батчик делающую простенький select в цикле и посмотреть заткнется ли.
Точно! Забыл еще вводную. Если запускаю SQL+ и выполняю запрос все нормально, если PL/SQL developer в multisseisn mode то он также не может запустить вторую сессию, такое ощушение что одновременно от одного запущеного приложения может присутствовать только одна сессия.
17.10.2006 15:45
EugeneT
 
Файрвол? Не спец Oracle (надеюсь пока), он всех клиентов на одном порту слушает или динамически открывает?
17.10.2006 15:46
reddevil
 
USE_SHARED_SOCKET=TRUE если ты про это
17.10.2006 16:00
OlegON
 
Ну и убери эту гадость... Посмотришь, как будет без нее. У тебя циска что ли? Изначально гадкий параметр же.
17.10.2006 17:01
EugeneT
 
Цитата:
reddevil USE_SHARED_SOCKET=TRUE если ты про это
Не я про другое. На примере ФТП, активный и пассивный режим. А активном по 21-му порту проходит авторизация, затем сервер говорит "на тебе порт ХХХХХ и качай", причем каждая новая сессия получает свой порт, пассивный режим - авторизация по 21-му порту, качать всех отправляют на 20-й.
У тебя все выглядит так будто, рутер считает зависшую сессию активной и не дает клиенту подконнектится заново, причем как будто сессия поддерживается со стороны сервера (раз его перезагрузка помогает)
Кста, а перезагрузка рутера проблему лечит?
18.10.2006 05:59
reddevil
 
Цитата:
olegon Ну и убери эту гадость... Посмотришь, как будет без нее. У тебя циска что ли? Изначально гадкий параметр же.
Да я бы не сказал что гадкий, но убрать все равно не могу - по VPN партнеры ходят!
18.10.2006 08:30
OlegON
 
Для винды с ее сокетами это не очень хорошая идея. У Oracle же есть шлюз, может его попробовать? Кстати, при чем тут VPN? Или они прямо на оракловый сервак VPNом садятся? Что с количеством TCP-сессий?
30.10.2006 06:50
reddevil
 
Up, помаленьку)
Применели все рекомендации, перезагрузили-в субботу вечером повторилось. При это м количество сесси было ну не больше сотни. Куда еще копнуть у ма не приложу %(
30.10.2006 08:36
OlegON
 
Так ты посмотрел, сколько в этот момент было TCP-сессий? Или про них речь? На металинке смотрел? SHARED убрал? Какие именно рекомендации применил? Я все таки тоже склоняюсь к мысли, что винда дурит.
30.10.2006 09:39
reddevil
 
"было TCP-сессий?" - никак не смотрел по времени суток прдполагаю.
"На металинке смотрел" - паролем поделишься?:)
"Какие именно рекомендации применил?" - которые в этой ветке и по ссылке. USE_SHARED_SOCKET- убрать не могу.
30.10.2006 09:53
OlegON
 
А что мешает использовать Connection Manager? Пугает меня этот USE_SHARED_SOCKET. Не верю я в то, что на винде с достаточно большим количеством подключений это будет работать. Кстати, у тебя везде dedicated?
30.10.2006 09:56
OlegON
 
TRACE_LEVEL_CLIENT= 16
?
TRACE_DIRECTORY_CLIENT = <directory>
TRACE_FILE_DIRECTORY= <filename>
30.10.2006 10:05
reddevil
 
Цитата:
olegon TRACE_LEVEL_CLIENT= 16
?
TRACE_DIRECTORY_CLIENT = <directory>
TRACE_FILE_DIRECTORY= <filename>
делал с SUPPORT, конец файла во втором сообщении(я если честно ни хрена из него не понял)
30.10.2006 10:09
OlegON
 
Сделай батничек с
Код:
netstat -a>log
rar m -agDDMMHHMM log log
и пускай раз в 10 минут на сервере. Скажи, чтобы точно засекли время, когда подвисли сессии и в течение 10 минут пробовали логиниться.
30.10.2006 10:19
reddevil
 
батник круглые сутки с интервалом в 10 мин гонять или только когда проблема возникает?
30.10.2006 10:27
OlegON
 
да думаю, что лучше заранее иметь логи происходящего, т.е. вдруг всплекс сессий, потом они все отвалятся, все висит... Пусть круглые сутки вертится, там маленький лог-то, просто куча их будет... Зато хоть на что-то посмотрим... Нужен будет лог до момента повисания, и в момент повисания. Ты же спишь иногда :) Главное, чтобы время повисания на сервере смотрели или на синхронной машине, а то запаримся нужные логи искать.


Опции темы


Часовой пояс GMT +3, время: 18:49.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.