Интерпретация SQL*Net message to client после трассировки

Простой запрос вытаскивает 40000 строк.
Если в выборке указать одно поле, например id,
то на запрос уходит 2 секунды.
Если вытаскивать все поля (
varchar2(256) - 3,
char(30) - 3
number(38) - 15
куртка замшевая - три штуки),
то удовольствие растягивается на пять минут. (при 100% загрузке клиента)

В первом случае tkporf показывает

Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ----------------------
SQL*Net message from client 2507 3.67 4.85

Во втором:
SQL*Net message from client 2508 151.77 420.48

Умом понимаю, что передается больше данных, но как это сказать терминами, и можно ли что то изменить?!

Спасибо!

В сабже to client, в tkprof - from client.

SQL*Net message to client - база данных шлет сообщение клиенту, но при этом происходит ожидание. Возможно связь с клиентом медленная
SQL*Net message from client - клиент шлет сообщение БД, но при этом происходит ожидание. Это сообщение поступает и тогда, когда клиент сидит и ничего не делает...

А вообще то эти сообщения редко являются настоящей проблемой. ИМХО дело в другом...

Все, что можно прочитать у Тома Кайта, я прочитал.
Но что именно происходит? Что клиент должен базе передать?
Сам запрос выполняется в обоих случаях за 0.3 сек.

На hotsos
SQLnet Message from client - Idle Time or your Problem.pdf

expimp

Но что именно происходит? Что клиент должен базе передать? Сам запрос выполняется в обоих случаях за 0.3 сек.

Cледующий FETCH, очевидно :)
Клиент тормозит или сетка загружена/неустойчива.
Возможно, слишком маленький размер па... Нет, это пока не надо :)

В http://oracle.com/global/ru/oramag/sepoct2004/admin_wait_events3.html
http://oracle.com/global/ru/oramag/nov2004/admin_wait_events4.html
http://www.oracle.com/global/ru/oramag/dec2004/admin_wait_events5.html:

Настройка систем баз данных с помощью анализа событий ожидания: реальные примеры

Событие ожидания "SQL*Net message from client" возникает во время выполнения процесса, когда он завершает выполнение запроса пользователя и должен ждать следующего запроса. Обычно вы замечаете большое время ожидания этого события в клиентских частях приложения, которые тратят много времени, ожидая, когда пользователь введет запрос или инициирует некоторое другое действие, которому требуется реакция сервера базы данных. Так что 300 секунд времени ожидания здесь не удивляли, но большое количество ожиданий не казалось правильным. ... Более внимательная проверка справочных данных, извлекаемых приложением, показала, что выбирается 9,245 строк справочных данных. Код приложения выбирал данные из курсоров по одной строке за один раз. Это приводило к двум "круговым" сетевым обменам и одному логическому чтению для каждой выбранной строки. Приложение было модифицировано для использования интерфейса обработки массивов в сервере Oracle, чтобы выбирать одновременно по 100 строк. Это существенно ускоряло приложение за счет уменьшения количества "круговых" сетевых обменов. Дополнительная выгода заключалась в том, что уменьшилась потребность в центральном процессоре на сервере базы данных, потому что требовалось приблизительно только одно логическое чтение при обработке одного блока данных, а не одно логическое чтение для извлечения каждой строки.

автор

Возможно, слишком маленький размер па... Нет, это пока не надо :)

+5
------------------------------
Not affilated with VAZ

Вот какая интересная (для меня во всяком случае) фигня обнаружилась методом тыка

Если запустить SQL*Plus и отправить запрос на выполнение,
это займет 5 минут.

Если увеличить set linesize 500 (а по умолчанию linesize = 80),
то время отработки - 10 секунд.

Между этими значениями зависимость (ну, там 120, 150, 200...)
почти линейная.

В чем дело - не понимаю! Ну не в ТРИДЦАТЬ же раз!

expimp

В чем дело - не понимаю! Ну не в ТРИДЦАТЬ же раз!

set arraysize?

expimp

Если запустить SQL*Plus и отправить запрос на выполнение, это займет 5 минут. Если увеличить set linesize 500 (а по умолчанию linesize = 80), то время отработки - 10 секунд. В чем дело - не понимаю! Ну не в ТРИДЦАТЬ же раз!

Когда строка из столбцов не влазит в linesize, то значения столбцов начинают переносится на следующие строки. Если одна строка данных занимает N строк в выводе, то шапка запроса занимает 2*N. Если (шапка+1_строка_данных)=3*N > pagesize/2, то шапка выводится для каждой строки данных. Т.е. объём вывода увеличивается почти в 3*N раз. А это всё ещё надо вывести на экран (в файл).
Вывод: у тебя слишком медленный 2D-ускоритель