Привет, All!

Проблема такова. Есть несколько машин с Oracle 9i Release 1 (последний релиз, содержавший JServer). На машинах -- от 512M до 1G оперативки. Знаю, что мало, но поделать ничего не могу. Иногда Oracle начинает ни с того ни с сего тормозить, т. е. коннектов к базе -- нуль, процессор не загружен, свопления активного не заметно -- а новое соединение установить не могу. Более того, на сервере 1521 порт открыт и слушается (сетевое соединение есть), а вот законнектиться по JDBC -- хрен. Версии драйверов на клиенте -- произвольные (от 9.0.1 до 10.1, пробовал и thin, и oci).

Лечится иногда рестартом оракла, иногда -- рестартом серверной машины.

Понимаю, что надо читать Performance Tuning Guide, но не мог бы уважаемый All посоветовать, где искать подводные грабли, а заодно, что можно почитать по настройке производительности на машинах класса low-end?

Заранее спасибо.

патчить. а лучше ставить 9.2, 9.0.x не самый удачный релиз оракла
к стате это под виндовсом ?

Здравствуйте, Bass, Вы писали:

B>Привет, All!

B>Проблема такова. Есть несколько машин с Oracle 9i Release 1 (последний релиз, содержавший JServer). На машинах -- от 512M до 1G оперативки. Знаю, что мало, но поделать ничего не могу. Иногда Oracle начинает ни с того ни с сего тормозить, т. е. коннектов к базе -- нуль, процессор не загружен, свопления активного не заметно -- а новое соединение установить не могу. Более того, на сервере 1521 порт открыт и слушается (сетевое соединение есть), а вот законнектиться по JDBC -- хрен.

Я бы искал проблему поближе к Jxxx. У меня дома 9.2 вполне неплохо чувствует себя на pIII-800/256Mb.

Здравствуйте, Bass, Вы писали:


B>Проблема такова. Есть несколько машин с Oracle 9i Release 1 (последний релиз, содержавший JServer). На машинах -- от 512M до 1G оперативки. Знаю, что мало, но поделать ничего не могу. Иногда Oracle начинает ни с того ни с сего тормозить, т. е. коннектов к базе -- нуль,
Т.е. вообще нет коннектов или нет новых пытающихся подключиться?

Здравствуйте, Bass, Вы писали:

Опиши проблему подробнее.

B>Иногда Oracle начинает ни с того ни с сего тормозить
В чем именно тормозит, чем замерено, с чем сравнивал. "новое соединение установить не могу" — это не тормоза это другое.

B>а вот законнектиться по JDBC -- хрен
Что значит хрен, какой он на вид . SQL*Plus как коннектится?

B>Oracle 9i Release 1 (последний релиз, содержавший JServer)
При чем здесь JServer?

B>>Иногда Oracle начинает ни с того ни с сего тормозить
W>В чем именно тормозит, чем замерено, с чем сравнивал. "новое соединение установить не могу" — это не тормоза это другое.

Замерять бессмысленно, т. к. все разумные рамки превышены. Ну не буду ж я ждать 15 минут?!

B>>а вот законнектиться по JDBC -- хрен
W>Что значит хрен, какой он на вид . SQL*Plus как коннектится?
Никак. Т. е. sqlplus/nolog; connect scott/tiger@ORCL засыпает навечно (или почти навечно), а telnet example com 1521 устанавливает сетевое соединение.

B>>Oracle 9i Release 1 (последний релиз, содержавший JServer)
W>При чем здесь JServer?

Это к вопросу о патчах и апгрейдах -- мы этот самый JServer используем и жить без него не можем. Т. е. перейти на 9.2 или 10.1 пока не можем.
OS -- Solaris 9/SPARC (UltraSPARC IIi 440Mhz/1024M RAM), Windows/Linux (Celeron 900-1200 Mhz, 512M RAM).

Здравствуйте, Аноним, Вы писали:

А>патчить. а лучше ставить 9.2, 9.0.x не самый удачный релиз оракла
А>к стате это под виндовсом ?

Ну, 9.0.x всё-таки удачнее, чем 8.1.7. Или я не прав?

Здравствуйте, Softwarer, Вы писали:

S>Я бы искал проблему поближе к Jxxx.

Да я и так уже отвёл под Java Pool Size 300M. Результат -- тот же.

Здравствуйте, KisA, Вы писали:
KA>Т.е. вообще нет коннектов или нет новых пытающихся подключиться?

Имеется в виду, что изначально база не загружена, а попыток коннекта -- один штук (я сижу и жду). Причём ситуация совершенно идентична и для Shared Server, и для Dedicated Server.

видел похожее когда сервер зачем-то лазил в DNS пытаясь выяснит название клиента. попробуй прописать имя клиента в hosts.

Здравствуйте, Аноним, Вы писали:

А>видел похожее когда сервер зачем-то лазил в DNS пытаясь выяснит название клиента. попробуй прописать имя клиента в hosts.

Уже есть. Видимо, не в этом дело.

Здравствуйте, Bass, Вы писали:

W>>Что значит хрен, какой он на вид . SQL*Plus как коннектится?
B>Никак. Т. е. sqlplus/nolog; connect scott/tiger@ORCL засыпает навечно (или почти навечно), а telnet example com 1521 устанавливает сетевое соединение.
Ну а как с самого сервера коннект? То есть локализуйте проблему: сетевые компоненты, Listener или сам Oracle не создает сессию. Если первое/второе, то плиз в Net Services Administrator's Guide, Part III Testing and Troubleshooting Oracle Net Services. Если третье (что очень маловероятно), то смотрите трейсы, вывешивайте эвенты. Запустите какой-нить joв: если отрабатывает, то с созданием сессий проблем нет. Может триггер на Logon навесили задумчивый?

Обратитесь в суппорт в конце концов, если лицензия имеется.

---

B>Это к вопросу о патчах и апгрейдах -- мы этот самый JServer используем и жить без него не можем. Т. е. перейти на 9.2 или 10.1 пока не можем.
Шо вы мене такое говорите!

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.5.0 - 64bit Production
With the Partitioning option
JServer Release 9.2.0.5.0 - Production

S>Я бы искал проблему поближе к Jxxx.
B>Да я и так уже отвёл под Java Pool Size 300M. Результат -- тот же.
Опять путаете! Для того чтобы законнектиться, не нужен никакой Java Pool, хоть через JDBC хоть через задницу!

Здравствуйте, wildwind, Вы писали:

W>Ну а как с самого сервера коннект? То есть локализуйте проблему: сетевые компоненты, Listener или сам Oracle не создает сессию. Если первое/второе, то плиз в Net Services Administrator's Guide, Part III Testing and Troubleshooting Oracle Net Services. Если третье (что очень маловероятно), то смотрите трейсы, вывешивайте эвенты. Запустите какой-нить joв: если отрабатывает, то с созданием сессий проблем нет.

Именно третье. Т. е. listener работает.

W>Может триггер на Logon навесили задумчивый?

Нет. Девственно чистая база.

W>

---

B>>Это к вопросу о патчах и апгрейдах -- мы этот самый JServer используем и жить без него не можем. Т. е. перейти на 9.2 или 10.1 пока не можем.
W>Шо вы мене такое говорите!
W>

W>Connected to:
W>Oracle9i Enterprise Edition Release 9.2.0.5.0 - 64bit Production
W>With the Partitioning option
W>JServer Release 9.2.0.5.0 - Production
W>

Это он пишет. А в доках к 9.2 русским по белому сказано про "desupport of JServer". По крайней мере, поддержки CORBA, EJB и JSP в 9.2 уже нет, хотя кастрированную JVM всё-таки сохранили. А единственный способ получить работающий JServer на 9.2 -- это upgrade версии 9.0.1.


S>>Я бы искал проблему поближе к Jxxx.
B>>Да я и так уже отвёл под Java Pool Size 300M. Результат -- тот же.
W>Опять путаете! Для того чтобы законнектиться, не нужен никакой Java Pool, хоть через JDBC хоть через задницу!

Я понимаю В данном случае Java -- определённо не в тему. Хотя тормозов добавляет.

Здравствуйте, Bass, Вы писали:

B>Привет, All!

B>Проблема такова. Есть несколько машин с Oracle 9i Release 1 (последний релиз, содержавший JServer). На машинах -- от 512M до 1G оперативки. Знаю, что мало, но поделать ничего не могу. Иногда Oracle начинает ни с того ни с сего тормозить, т. е. коннектов к базе -- нуль, процессор не загружен, свопления активного не заметно -- а новое соединение установить не могу.

Несколько вопросов:

— Содержимое alertlog-а
— Что говорит connect as sysdba + startup nomount с последующим alter database open?
— archivelog или noarchivelog? Если archivelog, то auto archiving или manual archiving? Может, он сидит и ждет, когда кто-нибудь сархивирует redolog-и (в этом случае некоторое время назад он должен был разрешать коннекты, т.к. кто-то должен был заполнить redolog-и).
— включить tracing на клиентской стороне, посмотреть, устанавливается ли соединение с БД с последующим зависанием, или же виснет на создании соединения. В sqlnet.ora добавить такие строки:

  trace_directory_client=c:\wutemp
  trace_file_client=conn_cli.trc
  trace_level_client=admin

— включить tracing на серверной стороне, может там чего интересного

  trace_directory_server=c:\wutemp
  trace_file_server=conn_srv.trc
  trace_level_server=admin

Здравствуйте, Bass, Вы писали:

B>Это он пишет. А в доках к 9.2 русским по белому сказано про "desupport of JServer". По крайней мере, поддержки CORBA, EJB и JSP в 9.2 уже нет, хотя кастрированную JVM всё-таки сохранили.
Ну положим этого там не сказано, тем более русским. Desupport касается EJB, JSP и CORBA, а JServer просто переименован в Oracle JVM. Оно и правильно — нечего пихать в базу все подряд, в частности presentation layer (и кроме того надо же покупать OAS )

B>А единственный способ получить работающий JServer на 9.2 -- это upgrade версии 9.0.1.
Можно и с 8.1.7.

B>Именно третье. Т. е. listener работает.
Плохо. Может с настройками что намудрили. Установка с нуля/на другую машину помогает?

Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, Bass, Вы писали:

W>Ну положим этого там не сказано, тем более русским. Desupport касается EJB, JSP и CORBA, а JServer просто переименован в Oracle JVM. Оно и правильно — нечего пихать в базу все подряд, в частности presentation layer (и кроме того надо же покупать OAS )
Согласен, не русским Касательно JServer -- признаю, лажанулся: я имел в виду именно CORBA. Просто эту самую корбу мы и используем.

B>>А единственный способ получить работающий JServer на 9.2 -- это upgrade версии 9.0.1.
W>Можно и с 8.1.7.
Не пробовал, но верю

B>>Именно третье. Т. е. listener работает.
W>Плохо. Может с настройками что намудрили. Установка с нуля/на другую машину помогает?
Девственно чистая база. Т. е. не помогает.

Здравствуйте, Sergey Ten, Вы писали:

ST>- Содержимое alertlog-а

Прошу прощения за ламерство, но где он лежит? Просто я не админ, я программист

ST>- Что говорит connect as sysdba + startup nomount с последующим alter database open?

Ещё не пробовал, ситуация пока не повторялась. Повторится -- попробую.

ST>- archivelog или noarchivelog? Если archivelog, то auto archiving или manual archiving? Может, он сидит и ждет, когда кто-нибудь сархивирует redolog-и (в этом случае некоторое время назад он должен был разрешать коннекты, т.к. кто-то должен был заполнить redolog-и).

archivelog, manual archiving. А можно с этого момента подробнее?

ST>- включить tracing на клиентской стороне, посмотреть, устанавливается ли соединение с БД с последующим зависанием, или же виснет на создании соединения. В sqlnet.ora добавить такие строки:
ST>

ST>  trace_directory_client=c:\wutemp
ST>  trace_file_client=conn_cli.trc
ST>  trace_level_client=admin
ST>

ST>- включить tracing на серверной стороне, может там чего интересного
ST>

ST>  trace_directory_server=c:\wutemp
ST>  trace_file_server=conn_srv.trc
ST>  trace_level_server=admin
ST>

Чайниковский вопрос: на серверной стороне это делается через ALTER SYSTEM или тоже в sqlnet.ora?
Ещё вопрос: какой из sqlnet.ora использовать? Я нашёл два:
${ORACLE_BASE}/config/${ORACLE_VERSION}/sqlnet.ora
${ORACLE_BASE}/product/${ORACLE_VERSION}/network/admin/sqlnet.ora

Здравствуйте, Bass, Вы писали:

B>Здравствуйте, Sergey Ten, Вы писали:

ST>>- Содержимое alertlog-а

B>Прошу прощения за ламерство, но где он лежит? Просто я не админ, я программист
Все мы тут не админы.

SQL> select value from v$parameter where name = 'background_dump_dest';

VALUE
-----------------------------------------------------------------------
C:\oracle\admin\work92\bdump

ST>>- archivelog или noarchivelog? Если archivelog, то auto archiving или manual archiving? Может, он сидит и ждет, когда кто-нибудь сархивирует redolog-и (в этом случае некоторое время назад он должен был разрешать коннекты, т.к. кто-то должен был заполнить redolog-и).

B>archivelog, manual archiving. А можно с этого момента подробнее?

Можно. Oracle использует несколько redolog-ов по кругу, что, естественно, вызывает их перезапись, когда очередной круг завершен. Если включено архивирование redolog-ов, то перед тем, как повторно использовать файл redolog-а, Oracle должен сделать его копию в директории, заданной параметром

select value from v$parameter where name = 'log_archive_dest';

В случае autoarchiving Oracle делает это автоматически, а в случае manual archiving он ждет, когда админ это сделает вручную командой

ALTER SYSTEM ARCHIVE LOG ALL;

Если админ своевременно этого не сделал, то Oracle впадает в спячку, так как перезапись файла невозможна, а без redolog-а он работать не может.

ST>>- включить tracing на клиентской стороне, посмотреть, устанавливается ли соединение с БД с последующим зависанием, или же виснет на создании соединения. В sqlnet.ora добавить такие строки:
ST>>

ST>>  trace_directory_client=c:\wutemp
ST>>  trace_file_client=conn_cli.trc
ST>>  trace_level_client=admin
ST>>

ST>>- включить tracing на серверной стороне, может там чего интересного
ST>>

ST>>  trace_directory_server=c:\wutemp
ST>>  trace_file_server=conn_srv.trc
ST>>  trace_level_server=admin
ST>>

B>Чайниковский вопрос: на серверной стороне это делается через ALTER SYSTEM или тоже в sqlnet.ora?
B>Ещё вопрос: какой из sqlnet.ora использовать? Я нашёл два:
B>${ORACLE_BASE}/config/${ORACLE_VERSION}/sqlnet.ora
B>${ORACLE_BASE}/product/${ORACLE_VERSION}/network/admin/sqlnet.ora

На серверной стороне — тоже через sqlnet.ora. Какой из них — точно не скажу, но скорее всего, второй. Надо смотреть Oracle документацию на тот UNIX, под которым он работает.

Здравствуйте, Sergey Ten, Вы писали:

ST>В случае autoarchiving Oracle делает это автоматически, а в случае manual archiving он ждет, когда админ это сделает вручную командой
ST>

ST>ALTER SYSTEM ARCHIVE LOG ALL;
ST>

Большое спасибо за информацию. Последний вопрос: как этот ARCHIVE LOG вообще выключить? Я нашёл только как включить/выключить автоматическую архивацию?

Здравствуйте, Bass, Вы писали:

B>Последний вопрос: как этот ARCHIVE LOG вообще выключить? Я нашёл только как включить/выключить автоматическую архивацию?

shutdown;
startup mount;
alter database noarchivelog;
alter database open;

Неделю спустя. Прихожу после выходных -- проблема повторяется.

Сначала пытаюсь установить соединение с опубликованным CORBA-объектом по sess_iiop://, клиент зависает.

Затем пытаюсь установить соединение из SQLPlus, с той же удалённой машины:

$ sqlplus /nolog
SQL> CONNECT SYS/change_on_install@ORCL AS SYSDBA;

Клиент зависает. В то же время listener живой, соединение с портами 1521 и 2481 устанавливается. Лог для последнего соединения с клиентской стороны (включённый через sqlnet.ora):

=========== skipped ===========
[09-АВГ-2004 10:27:24:770] nioqsn: entry
[09-АВГ-2004 10:27:24:770] nioqsn: exit
[09-АВГ-2004 10:27:24:770] nioqrc: entry
[09-АВГ-2004 10:27:24:771] nsdo: cid=0, opcode=84, *bl=0, *what=1, uflgs=0x20, c
[09-АВГ-2004 10:27:24:771] nsdo: rank=64, nsctxrnk=0
[09-АВГ-2004 10:27:24:771] nsdo: nsctx: state=8, flg=0x400d, mvd=0
[09-АВГ-2004 10:27:24:771] nsdo: gtn=127, gtc=127, ptn=10, ptc=2011
[09-АВГ-2004 10:27:24:771] nsdofls: DATA flags: 0x0
[09-АВГ-2004 10:27:24:771] nsdofls: sending NSPTDA packet
[09-АВГ-2004 10:27:24:771] nspsend: plen=770, type=6
[09-АВГ-2004 10:27:24:771] nttwr: entry
[09-АВГ-2004 10:27:24:771] nttwr: socket 12 had bytes written=770
[09-АВГ-2004 10:27:24:771] nttwr: exit
[09-АВГ-2004 10:27:24:771] nspsend: 770 bytes to transport
[09-АВГ-2004 10:27:24:772] nsdo: nsctxrnk=0
[09-АВГ-2004 10:27:24:772] nsdo: cid=0, opcode=85, *bl=0, *what=0, uflgs=0x0, cf
[09-АВГ-2004 10:27:24:772] nsdo: rank=64, nsctxrnk=0
[09-АВГ-2004 10:27:24:772] nsdo: nsctx: state=8, flg=0x400d, mvd=0
[09-АВГ-2004 10:27:24:772] nsdo: gtn=127, gtc=127, ptn=10, ptc=2011
[09-АВГ-2004 10:27:24:772] nsdo: switching to application buffer
[09-АВГ-2004 10:27:24:772] nsrdr: recving a packet
[09-АВГ-2004 10:27:24:772] nsprecv: reading from transport...
[09-АВГ-2004 10:27:24:772] nttrd: entry

Ну, то, что "reading from transport" -- это и так понятно. Логинюсь на сервер по ssh, пытаюсь зайти локально:

$ sqlplus /nolog
SQL> CONNECT / AS SYSDBA;

-- тот же отрицательный результат. Решаю посмотреть серверные логи. В ${ORACLE_BASE}/admin/ORCL за последние два дня ничего интересного. Т. е. последняя запись -- два дня назад. Серверный лог (через sqlnet.ora) для последнего соединения, того самого, которое "reading from transport":

========== skipped ===================
nttrd: socket 20 had bytes read=181
nttrd: exit
nsprecv: 181 bytes from transport
nsprecv: tlen=181, plen=181, type=6
nsrdr: got NSPTDA packet
nsrdr: NSPTDA flags: 0x0
nsdo: *what=1, *bl=2009
nsdo: nsctxrnk=0
nioqrc: exit
nioqsn: entry
nioqrc: entry
nsdo: cid=0, opcode=84, *bl=0, *what=1, uflgs=0x20, cflgs=0x3
nsdo: rank=64, nsctxrnk=0
nsdo: nsctx: state=8, flg=0x420c, mvd=0
nsdo: gtn=156, gtc=156, ptn=10, ptc=2019
nsdofls: DATA flags: 0x0
nsdofls: sending NSPTDA packet
nspsend: plen=93, type=6
nttwr: entry
nttwr: socket 20 had bytes written=93
nttwr: exit
nspsend: 93 bytes to transport
nsdo: nsctxrnk=0
nsdo: cid=0, opcode=85, *bl=0, *what=0, uflgs=0x0, cflgs=0x3
nsdo: rank=64, nsctxrnk=0
nsdo: nsctx: state=8, flg=0x420c, mvd=0
nsdo: gtn=156, gtc=156, ptn=10, ptc=2019
nsdo: switching to application buffer
nsrdr: recving a packet
nsprecv: reading from transport...
nttrd: entry
nttrd: socket 20 had bytes read=770
nttrd: exit
nsprecv: 770 bytes from transport
nsprecv: tlen=770, plen=770, type=6
nsrdr: got NSPTDA packet
nsrdr: NSPTDA flags: 0x0
nsdo: *what=1, *bl=2009
nsdo: nsctxrnk=0
nioqrc: exit

Аналогичный локальный клиентский лог (видимо, для работающего на той же машине oracle enterprise manager'а) весит 600 Мб и вся вторая половина загажена сообщениями след. вида:

...nsevwait: nsevwait: nsevwait: nsevwait: nsevwait:
nsevwait: nsevwait: nsevwait: nsevwait: nsevwait:
nsevwait: nsevwait: nsevwait: nsevwait: nsevwait: ...

В то же время

ps -e -o "user,pid,pcpu,pmem,rss,vsz,args"

сообщает, что есть штук восемь процессов с "args" oracle_ORCL, из них три отожрали почти всю память (25, 25 и 17%), причём для одного значение "pcpu" колеблется между 97% и 100%, причём эти "почти сто процентов" -- не system time, а user time, что подтверждается: по данным sdtperfmeter (утилита такая в соляре для мониторинга производительности), активность disk/page/swap практически на нуле. Но при этом cpu load -- 100%, system load -- 4. vmstat сообщает то же самое:

cpu
cs  us sy id
287  99 1 0
285 100 0 0
280 100 0 0
272 100 0 0
298  98 2 0
275  99 1 0
267 100 0 0
307  97 3 0
282 100 0 0
270 100 0 0
307  98 2 0
287 100 0 0

Здесь "cs" -- "the number of cpu context switches per second" (кто бы объяснил толком, что это такое);
"us" -- user time процессора; "sy" -- system time процессора.


Ждал три часа, нормально зашатдаунить базу так и не смог, плюнул, перезагрузил машину. Помогло. До след. викенда.
Вопрос: над чем оракл мог так долго думать? На OTN народ сказал, что, скорее всего, это баг, и надо обращаться в metalink. Есть ли какие-л. другие пути? Может ли быть мисконфигурация оракла?

Заранее спасибо.

Здравствуйте, Bass, Вы писали:

B>Неделю спустя. Прихожу после выходных -- проблема повторяется.
B> === skipped ===
B>Ждал три часа, нормально зашатдаунить базу так и не смог, плюнул, перезагрузил машину. Помогло. До след. викенда.

Оставил бы висящую sys сессию, чтобы потом можно было отмониторить изнутри.
Очень подозрительно.

на металинке только 8рка фигурирует. выдай точно что за ось и сильно рекомендую апгрейд до 9.2.0.5
посмотри top, покажи какие процессы, наверху.


Doc ID: Note:68059.1
Subject: ALERT: Oracle 8 SQL*Plus connections from Solaris 2.6 to HP/UX & SNI hang
Type: ALERT
Status: PUBLISHED

Content Type: TEXT/PLAIN
Creation Date: 14-JAN-1999
Last Revision Date: 10-MAY-2002

Oracle 8 sqlplus client connections from Solaris 2.6 to HP/UX and SNI systems

can hang.

This problem has been described in a number of Oracle bugs: bug:601571,

bug:752562, bug:757577, bug:761106, bug:805590.

There has been much confusion over the issue, and suggestions that it's caused

(or resolved) by Solaris patch 105786-05, and that using a Net 8 listener, or

MTS on the server is a workaround. None of this has been proved to be true.

The ONLY RELIABLE WORKAROUND that has been identified is to set:

DISABLE_OOB=ON

In the client's "sqlnet.ora" file (disabling Oracle's use of urgent data

messages).

The problem is actually due to incorrect behaviour by either the Sun or

HP/Pyramid TCP stack when dealing with un-ack'd urgent data messages. The

problem is currently the subject of discussion between Sun & HP.

It causes the client and server processes to get out of sync, by affecting

SQL*Net's (default) out-of-band break/reset mechanism.

This break/reset mechanism is implemented by the client sending a single-byte

urgent data message (the TCP MSB_OOB flag is set), followed by an 11-byte

normal data packet (NSPTMK).

The reason this only affects Solaris to HP/UX & SNI is that these platforms

have a different method for handling simultaneous urgent messages on the same

socket. On HP & SNI the first byte of the 11-byte data packet is lost, causing

a 12569: header checksum error.

Note: This problem does NOT affect Server Manager's connection attempt, as

Server Manager doesn't perform the same datatype negotiation during connection

establishment, therefore avoiding use of the break/reset mechanism.

This bug can be identified by the following information in level 16 client and

server trace files:

Client trace file:

~~~~~~~~~~~~~~~~~~

...

nsrdr: NSPTDA flags: 0x0

nsrdr: normal exit

nsdo: *what=1, *bl=2038

nsdo: nsctxrnk=0

nsdo: normal exit

nioqrc: exit

nioqsn: entry

nioqbr: entry

nioqbr: state = normal (0)

nioqsm: entry

nioqsm: Sending break packet (1)...

nsdo: entry

nsdo: cid=0, opcode=67, *bl=1, *what=18, uflgs=0x100, cflgs=0x3

nsdo: rank=64, nsctxrnk=0

nsdo: nsctx: state=8, flg=0x420d, mvd=0

nsdo: gtn=127, gtc=127, ptn=10, ptc=2047

nsdo: sending ATTN

nsdo: 127 urgent byte to transport

nsdo: nsctxrnk=0

nsdo: normal exit

nioqbr: exit

nioqrs: entry

nioqrs: state = interrupted (1)

nioqrs: nioqrs: Not in send state ...

nioqsm: entry

nioqsm: Sending reset packet (2)...

nsdo: entry

nsdo: cid=0, opcode=67, *bl=1, *what=17, uflgs=0x0, cflgs=0x3

nsdo: rank=64, nsctxrnk=0

nsdo: nsctx: state=8, flg=0x420d, mvd=0

nsdo: gtn=127, gtc=127, ptn=10, ptc=2047

nsdofls: entry

nsdofls: DATA flags: 0x0

nsdofls: normal exit

nsdo: sending NSPTMK packet

nspsend: entry

nspsend: plen=11, type=12

nttwr: entry

nttwr: socket 11 had bytes written=11

nttwr: exit

nspsend: 11 bytes to transport

nspsend: packet dump

nspsend:00 0B 00 00 0C 00 00 00 |........|

nspsend:01 00 02 00 00 00 00 00 |........|

nspsend: normal exit

nsdoacts: entry

nsdofls: entry

nsdofls: DATA flags: 0x0

nsdofls: normal exit

nsdoacts: flushing transport

nttctl: entry

nsdoacts: normal exit

nsdo: nsctxrnk=0

nsdo: normal exit

nioqrs: nioqrs: sucking for reset marker...

nioqar: entry

nioqar: nioqar: suck pipe til I get a reset...

nscontrol: entry

nscontrol: cmd=1, lcl=0x0

nscontrol: normal exit

nscontrol: entry

nscontrol: cmd=3, lcl=0x2

nscontrol: normal exit

nsdo: entry

nsdo: cid=0, opcode=85, *bl=0, *what=0, uflgs=0x0, cflgs=0x3

nsdo: rank=64, nsctxrnk=0

nsdo: nsctx: state=8, flg=0x420d, mvd=0

nsdo: gtn=127, gtc=127, ptn=10, ptc=2047

nsdo: switching to application buffer

nsrdr: entry

nsrdr: recving a packet

nsprecv: entry

nsprecv: reading from transport...

nttrd: entry

nttrd: socket 11 had bytes read=11

nttrd: exit

nsprecv: 11 bytes from transport

nsprecv: tlen=11, plen=11, type=12

nsprecv: packet dump

nsprecv:00 0B 00 00 0C 00 00 00 |........|

nsprecv:01 00 02 00 00 00 00 00 |........|

nsprecv: normal exit

nsrdr: got NSPTMK packet

nsrdr: normal exit

nsdo: *what=17, *bl=1

nsdo: nsctxrnk=0

nsdo: normal exit

nioqar: exit

nscontrol: entry

nscontrol: cmd=2, lcl=0x0

nscontrol: normal exit

nsnactl: entry

nactl_internal: entry

naeectl: entry

naeectl: exit

naecctl: entry

naecctl: exit

nactl_internal: exit

nsnactl: error exit

nserror: entry

nserror: nsres: id=0, op=77, ns=12630, ns2=0; nt[0]=0, nt[1]=0, nt[2]=0

nioqer: entry

nioqer: incoming err = 0

nioqce: entry

nioqce: exit

nioqer: returning err = 0

nioqer: exit

nioqrs: exit

nioqrc: entry

nsdo: entry

nsdo: cid=0, opcode=85, *bl=0, *what=0, uflgs=0x0, cflgs=0x3

nsdo: rank=64, nsctxrnk=0

nsdo: nsctx: state=8, flg=0x420d, mvd=0

nsdo: gtn=127, gtc=127, ptn=10, ptc=2047

nsdo: switching to application buffer

nsrdr: entry

nsrdr: recving a packet

nsprecv: entry

nsprecv: reading from transport...

nttrd: entry

The client hangs at this point....

Server trace file:

~~~~~~~~~~~~~~~~~~

...

nsdo: switching to application buffer

nsrdr: entry

nsrdr: recving a packet

nsprecv: entry

nsprecv: reading from transport...

nttrd: entry

nttrd: socket 12 had bytes read=10

nttrd: exit

nsprecv: 10 bytes from transport

-<ERROR>- nsprecv: header checksum error

nsprecv:packet hdr

nsprecv:0B 00 00 0C 00 00 00 00 |........|

nsprecv: error exit

nserror: entry

-<ERROR>- nserror: nsres: id=0, op=68, ns=12569, ns2=0; nt[0]=0, nt[1]=0, nt[2]=0

nsrdr: error exit

nsdo: nsctxrnk=0

nsdo: error exit

osnqrc: interrupt came in while in ns...

osnqhp: entry

osnqhp: handling break in state sent (1)

osnqhp: exit

osnqrc: exit

osnqrs: entry

osnqrs: state = interrupted (1)

osnqrs: osnqrs: sending reset marker...

osnqsm: entry

osnqsm: Sending reset packet (2)...

nsdo: entry

nsdo: cid=0, opcode=67, *bl=1, *what=17, uflgs=0x0, cflgs=0x3

nsdo: rank=64, nsctxrnk=0

nsdo: nsctx: state=8, flg=0x420c, mvd=0

nsdo: gtn=143, gtc=143, ptn=10, ptc=2048

nsdofls: entry

nsdofls: DATA flags: 0x0

nsdofls: normal exit

nsdo: sending NSPTMK packet

nspsend: entry

nspsend: plen=11, type=12

nttwr: entry

nttwr: socket 12 had bytes written=11

nttwr: exit

nspsend: 11 bytes to transport

nspsend:packet dump

nspsend:00 0B 00 00 0C 00 00 00 |........|

nspsend:01 00 02 00 00 00 00 00 |........|

nspsend: normal exit

nsdoacts: entry

nsdofls: entry

nsdofls: DATA flags: 0x0

nsdofls: normal exit

nsdoacts: flushing transport

nttctl: entry

nsdoacts: normal exit

nsdo: nsctxrnk=0

nsdo: normal exit

osnqsm: exit

osnqrs: osnqrs: sucking for reset marker...

osnqar: entry

osnqar: osnqar: suck pipe til I get a reset...

nsdo: entry

nsdo: cid=0, opcode=85, *bl=0, *what=0, uflgs=0x0, cflgs=0x3

nsdo: rank=64, nsctxrnk=0

nsdo: nsctx: state=8, flg=0x420c, mvd=0

nsdo: gtn=143, gtc=143, ptn=10, ptc=2048

nsdo: switching to application buffer

nsrdr: entry

nsrdr: recving a packet

nsprecv: entry

nsprecv: reading from transport...

The server hangs at this point.

Большое спасибо за информацию.

Система -- Sun Ultra 10, 1 UltraSPARC IIi 440Mhz CPU.
Ось -- Solaris 5.9 Maintenance Update 4
Оракл -- 9.0.1 (9i Release 1) без каких-либо патчей/апдейтов.

Вопрос: сейчас на эту версию оракла получить платную поддержку можно? А то я по OTN полазил -- ничего путного не нашёл. Все в сотоянии эйфории от выхода 10g...

B>Система -- Sun Ultra 10, 1 UltraSPARC IIi 440Mhz CPU.
B>Ось -- Solaris 5.9 Maintenance Update 4
B>Оракл -- 9.0.1 (9i Release 1) без каких-либо патчей/апдейтов.

сначала пачить хотя бы до 9.0.1.4 (там 250 мб), если не проканает то до 9.2.0.5. имхо только потом можно смотреть логи.

B>Вопрос: сейчас на эту версию оракла получить платную поддержку можно? А то я по OTN полазил -- ничего путного не нашёл. Все в сотоянии эйфории от выхода 10g...

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

Здравствуйте, Аноним, Вы писали:

А>а на otn ничего не бывает в принципе — им металик продавать нада ...
Ну почему же, на форумах достаточно много независимой и толковой публики. Даже наши иногда тусуются, индусов поучают...