SQL*Net message from client - SQL*Net more data to client / Oracle

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Oracle [игнор отключен] [закрыт для гостей] / SQL*Net message from client - SQL*Net more data to client

25 сообщений из 29, страница 1 из 2

все

SQL*Net message from client - SQL*Net more data to client

#39279809

жвачкин

Гость

Есть некий select, который выполняется продолжительное время, сессия активна.
Сделал трассировку сессии, получил следующее:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        0      0.00       0.00          0          0          0           0
Execute      0      0.00       0.00          0          0          0           0
Fetch     6468    219.66     221.93      13494         28          0       51744
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total     6468    219.66     221.93      13494         28          0       51744

Misses in library cache during parse: 0
Parsing user id: 87  

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net more data to client                  6556        0.00          0.56
  SQL*Net message from client                  6468        0.02         10.15
  SQL*Net message to client                    6468        0.00          0.02
  direct path read temp                         109        0.07          1.42
  library cache: mutex X                         15        0.00          0.00
********************************************************************************

возник вопрос, чего ожидает сессия?

...

Рейтинг:

0 / 0

25.07.2016, 16:39:53

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39279829

booby

Участник

Сообщения: 2 667

Рейтинг: 1 / 0

жвачкин,

ваша сессия ожидает указание с клиента на фетч следующих восьми строк, после получения клиентом предыдущих восьми.
Но вас не это должно интересовать пока, так общее время этого ожидания составляет меньше 5% общего времени выборки данных.

...

Рейтинг:

0 / 0

25.07.2016, 17:13:17

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39279830

Dimitry Sibiryakov

Участник

Сообщения: 54 521

Рейтинг: 0 / 0

жвачкинчего ожидает сессия?
Пока клиентское приложение получит и прожуёт отправленную ему пачку записей.
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

25.07.2016, 17:13:24

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39280200

жвачкин

Гость

boobyжвачкин,

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

direct path read temp
library cache: mutex X

авторобщее время этого ожидания составляет меньше 5% общего времени выборки данных
Могли бы подсказать, остальные 95% времени - что занимает по этому трейсу?

проблема в недостаточном PGA - так как есть direct path read temp?

в трейс у меня попало два селекта, второй имеет вид:
select column from table where column=:p1;

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        0      0.00       0.00          0          0          0           0
Execute  14462      1.45       1.71          0          0          0           0
Fetch    14462      0.40       0.40          0      60093          0       14462
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total    28924      1.85       2.12          0      60093          0       14462

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 87     (recursive depth: 1)

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.

OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        0      0.00       0.00          0          0          0           0
Execute      0      0.00       0.00          0          0          0           0
Fetch     6468    219.66     221.93      13494         28          0       51744
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total     6468    219.66     221.93      13494         28          0       51744

Misses in library cache during parse: 0

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net more data to client                  6556        0.00          0.56
  SQL*Net message from client                  6468        0.02         10.15
  SQL*Net message to client                    6468        0.00          0.02
  direct path read temp                         109        0.07          1.42
  library cache: mutex X                         15        0.00          0.00


OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        0      0.00       0.00          0          0          0           0
Execute  14462      1.45       1.71          0          0          0           0
Fetch    14462      0.40       0.40          0      60093          0       14462
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total    28924      1.85       2.12          0      60093          0       14462

Misses in library cache during parse: 0

    2  user  SQL statements in session.
    0  internal SQL statements in session.
    2  SQL statements in session.
********************************************************************************
Trace file: C:\trace\new\orcl_ora_9172.trc
Trace file compatibility: 11.1.0.7
Sort options: fchela  
       4  sessions in tracefile.
       2  user  SQL statements in trace file.
       0  internal SQL statements in trace file.
       2  SQL statements in trace file.
       2  unique SQL statements in trace file.
  204181  lines in trace file.
     235  elapsed seconds in trace file.

...

Рейтинг:

0 / 0

26.07.2016, 11:57:45

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39280274

andrey_anonymous

Участник

Откуда: Москва

Сообщения: 18 719

Рейтинг: 0 / 0

жвачкинпроблема в недостаточном PGA - так как есть direct path read temp?
У Вас cpu на fetch - почти 220 секунд.
Скорее всего либо массивные сортировки, либо HJ
Смотреть запрос, план его исполнения, много думать.
Думать в двух направлениях:
1. Снизить ресурсоемкость запроса (более оптимальный план, возможно, поменять что-то на уровне данных, пересмотреть индексирование)
2. выделить больше ресурсов (--+ parallel, dbms_parallel_execute, по показаниям - добавить памяти, применить более быстрые носители, купить exadata, нанять специалиста)

...

Рейтинг:

0 / 0

26.07.2016, 12:57:30

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39280283

жвачкин

Гость

Подскажите, а как увидеть значения bind переменных в запросе, который уже завершился?
Трассировку сделать не успел, просто вижу текст запроса из поля sql_fulltext в v$sqlarea.
редакция SE One.

...

Рейтинг:

0 / 0

26.07.2016, 13:04:32

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39280304

жвачкин

Гость

andrey_anonymousжвачкинпроблема в недостаточном PGA - так как есть direct path read temp?
У Вас cpu на fetch - почти 220 секунд.
Скорее всего либо массивные сортировки, либо HJ
Смотреть запрос, план его исполнения, много думать.
Думать в двух направлениях:
1. Снизить ресурсоемкость запроса (более оптимальный план, возможно, поменять что-то на уровне данных, пересмотреть индексирование)
2. выделить больше ресурсов (--+ parallel, dbms_parallel_execute, по показаниям - добавить памяти, применить более быстрые носители, купить exadata, нанять специалиста)

план выполнения запроса такой:

Код: plsql

1.
2.
3.
4.
5.
6.
7.

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 10 (100)| |
|* 1 | FILTER | | | | | |
| 2 | SORT GROUP BY | | 346 | 625K| 10 (10)| 00:00:01 |
|* 3 | TABLE ACCESS FULL| TMP_TABLE_10 | 346 | 625K| 9 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------

т.е. шла работа с временной таблицей.
сколько записей было в той временной таблице для сессии - сказать не могу.
HJ - не было судя из плана запроса.
получается проблема в массивной сортировке, о чём говорит строка: SORT GROUP BY ?

...

Рейтинг:

0 / 0

26.07.2016, 13:21:35

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39280309

Вячеслав Любомудров

Участник

Откуда: Владивосток

Сообщения: 18 655

Рейтинг: 0 / 0

В запросе не было обращений к PL/SQL функциям?

...

Рейтинг:

0 / 0

26.07.2016, 13:24:57

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39280310

жвачкин

Гость

авторсколько записей было в той временной таблице для сессии - сказать не могу.
вру, получается могу из Rows - 346...но это крайне мало, для фетча в 229 секунд.
поправьте пожалуйста.

...

Рейтинг:

0 / 0

26.07.2016, 13:25:44

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39280315

жвачкин

Гость

Вячеслав ЛюбомудровВ запросе не было обращений к PL/SQL функциям?
были и очень много. запрос на страницу или больше, pl/sql функций + 100500...

куда дальше копать? что смотреть?

...

Рейтинг:

0 / 0

26.07.2016, 13:27:35

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39280321

Вячеслав Любомудров

Участник

Откуда: Владивосток

Сообщения: 18 655

Рейтинг: 0 / 0

Избавляться от них
Или, хотя бы, сделать так, чтоб они не вызывались больше чем надо (например, scalar subquery expression)

...

Рейтинг:

0 / 0

26.07.2016, 13:29:53

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39280328

жвачкин

Гость

Вячеслав ЛюбомудровИзбавляться от них
Или, хотя бы, сделать так, чтоб они не вызывались больше чем надо (например, scalar subquery expression)

мой запрос с кучей pl/sql содержит следующее:

Код: plsql

1.
2.

select fo kkkk, nvl(getmaincode(t10.own_id),'')
getmaincode(pid) stamp, getmaincode(CC_SUM) gk

Код: plsql

1.
2.

substr(EXTRACT(XMLAGG(xmlelement("V",
  decode(t10.surface,'S',null,','||GetMainCode(t10.Nrate)))

Код: plsql

1.
2.

max(nvl(p_Np.GetNP(acp_rpt.GetRouteOrVoid(a_opsid => t10.ops_id,a_cashcoef =
  > t10.cashcoef,a_surface => 1),'@route'),t10.fo_full)) route

таких строчек в запросе очень много...
но на чём именно затык?

getmaincode ?
acp_rpt.GetRouteOrVoid ?

...

Рейтинг:

0 / 0

26.07.2016, 13:40:29

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39280355

booby

Участник

Сообщения: 2 667

Рейтинг: 1 / 0

жвачкин,

троллите вы жестко.
andrey_anonymous вам уже ответил настолько, насколько возможно, по каменной силе силе вашего тролления.

авторпроблема в недостаточном PGA - так как есть direct path read temp?

direct path read temp - всего лишь следствие того, что весь ваш фетч выбирается с диска.
А это следствие сортировки или хеш - соединения.

может быть и PGA "недостаточно". его, рано или поздно, все равно будет недостаточно.
может быть есть смысл увеличивать sort/hash area size, или даже buffer pool
но лучше переписать запрос.

из того, что видно - у вас низкая средняя скорость чтения с диска - около 500К/сек.
и, что совершенно выглядит каменно, - в среднем за одно чтение с диска вы получаете 3 строки результата.

Вероятно, это свидетельство того, что выбирая по 8 строк за раз, вы многократно перечитываете один и тот блок с диска.

Ничего не меняя в запросе :

Просто увеличьте на клиенте fetch size так, чтобы за раз клиенту отдавалось число строк из пары хотя бы блоков.
Т.е. с 8 увеличьте до 80 или 180 - в зависимости от того, насколько широкие ваши строки данных.

В вашем случае это серьезно (вероятно - более чем вдвое) улучшит время фетча и даст вам время и возможность
спокойно, без использования каменных тролей на тропе чтения форума, разобраться с запросом.

...

Рейтинг:

0 / 0

26.07.2016, 14:04:48

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39280361

Вячеслав Любомудров

Участник

Откуда: Владивосток

Сообщения: 18 655

Рейтинг: 0 / 0

Вообще-то, судя пожвачкинт.е. шла работа с временной таблицей.
сколько записей было в той временной таблице для сессии - сказать не могу.
direct path read temp именно отсюда

Никакой памяти никуда увеличивать не надо -- у него тупо молотит CPU за счет переключения контекста и хрен знает чего у него там внутри функций
А если они еще и в условиях, ключах сортировки/группировки то наверняка вызываются много-много лишних раз
Тут бы помог DETERMINISTIC и RESULT_CACHE, но лучше избегать вообще лишних вызовов PL/SQL из SQL

...

Рейтинг:

0 / 0

26.07.2016, 14:13:49

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39280387

booby

Участник

Сообщения: 2 667

Рейтинг: 1 / 0

Вячеслав Любомудров,

на мой взгляд - не сходится про "тупо молотит cpu" и переключения контеста.
По крайней мере - с разбега - не сходится

у него весь OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS - 2.12
да и выполнился всего 14462 при уже добытых 51744 строках

Оно понятно, что набор у него недовыбран, и его pl/sql еще не все свои слова, вероятно, произнес.
но, если уж память не надо трогать, то pl/slq - два раза повременить.
он еще свой лик никак на показанную поверхность не явил.
и не просто не явил, а в интересных ему 212 секундах того pl/sql - всего 1% - 2.12+-мизер

...

Рейтинг:

0 / 0

26.07.2016, 14:33:18

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39280400

ora601

Участник

Сообщения: 785

Рейтинг: 0 / 0

Вячеслав ЛюбомудровТут бы помог DETERMINISTIC и RESULT_CACHE, но лучше избегать вообще лишних вызовов PL/SQL из SQL
DETERMINISTIC + RESULT_CACHE scalar subquery cache

...

Рейтинг:

0 / 0

26.07.2016, 14:41:45

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39280434

жвачкин

Гость

автору вас низкая средняя скорость чтения с диска - около 500К/сек.
могли бы вы любезно показать, как вы получили значение в 500 К/сек?

Код: plsql

1.
2.
3.

13494 физических чтений * 8Кб (размер блока)  = 107952 КБ - прочитано с диска
время выполнения: 221 секунду elapsed time
107952/221 = 488,4 КБ в секунду

так?

Код: plsql

 3 | TABLE ACCESS FULL| TMP_TABLE_10 | 346 | 625K| 9 (0)| 00:00:01 |

но у меня был TABLE ACCESS FULL к временной таблице и должно многоблочное чтение использоваться.
а это значит 13494 физических чтений * 128 КБ (db_file_multiblock_read_count=128) = 1727232 КБ /221 секунду - 7815 КБ в секунду...

если же предположение не верно и было одноблочное чтение, то почему оптимизатор его использовал для TABLE ACCESS FULL?

Oracle крутится на vmware, вкладка performance по диску показывает в среднем 22639 KBps для Read Rate.
и Highest latency 3 в среднем. тогда возникает ещё один вопрос, почему при этом такие низкие показатели чтения с диска?

...

Рейтинг:

0 / 0

26.07.2016, 15:26:11

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39280438

Вячеслав Любомудров

Участник

Откуда: Владивосток

Сообщения: 18 655

Рейтинг: 0 / 0

Советую разобраться, что такое ELAPSED, что такое CPU
И, насколько я понял не смешивать статистики и ожидания для "OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS" и конкретного оператора

...

Рейтинг:

0 / 0

26.07.2016, 15:32:01

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39280445

жвачкин

Гость

авторПросто увеличьте на клиенте fetch size так, чтобы за раз клиенту отдавалось число строк из пары хотя бы блоков.

у нас есть приложение, написанное внешним разработчиком.
менять код приложения, компилировать, и т.п. возможности нет.

правильно я понимаю, что на уровне БД я fetch size не задам?

...

Рейтинг:

0 / 0

26.07.2016, 15:42:25

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39280476

жвачкин

Гость

жвачкинавторПросто увеличьте на клиенте fetch size так, чтобы за раз клиенту отдавалось число строк из пары хотя бы блоков.

у нас есть приложение, написанное внешним разработчиком.
менять код приложения, компилировать, и т.п. возможности нет.

правильно я понимаю, что на уровне БД я fetch size не задам?

ссылка, которую предоставил любезно Elic:

https://docs.oracle.com/cd/E11882_01/java.112/e16548/resltset.htm#JJDBC28623

Код: plsql

1.
2.

To set the fetch size for a query, call setFetchSize on the statement object prior to running the query. 
If you set the fetch size to N, then N rows are fetched with each trip to the database.

я не могу изменять приложение...
значит в моём случае лишь писать письма разработчику?

...

Рейтинг:

0 / 0

26.07.2016, 16:18:01

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39280491

booby

Участник

Сообщения: 2 667

Рейтинг: 1 / 0

жвачкину нас есть приложение, написанное внешним разработчиком.
менять код приложения, компилировать, и т.п. возможности нет.

так значит есть возможность напрямую обратиться к разработчику, а не терять время на форуме.
Примите в расчет, что разработчик правомерно стребует с вас полноценную трассировку - запущенную до старта целевого запроса.
(в вашей трассировке 0 исполнений запроса - это мусор, а не трассировка).

жвачкинправильно я понимаю, что на уровне БД я fetch size не задам?
это зависит от того - кто фетчит целевой курсор
если клиент - надо явно задавать значение на клиентской стороне.
если сервер (через open - fetch - close) - косвенным задается значением limit при переписывании доступа к данным через bulk collect
требуется ли менять код и/или компилировать - зависит от деталей устройства вашего приложения.

ну, sqlplus-то у вас, может быть, найдется.
По крайней мере сможете проверить эту гипотезу, установив подходящий arraysize, и убедившись, например, в том, что
никакой существенной разницы вы не видите.

автор...
так?
да.
это оценка .
Для которой не имеет значения - насколько быстро что-то читалось "на самом деле".
Все, что было на самом деле - разглядывайте в сырой трассировке.
Нам же вы показываете здесь огрызки сферических коней в вакууме, требуя серьезной беседы.
С вами серьезно и беседуют.
То, что сия беседа есть запись из псих больницы - лучше подходит для пятницы, но и для вторника ничего, в условиях, когда еще вся среда впереди.

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

...

Рейтинг:

0 / 0

26.07.2016, 16:36:59

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39280518

жвачкин

Гость

авторнапрямую обратиться к разработчику, а не терять время на форуме.
что я любезно и сделал

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

авторподойдите к своему АБД с кирпичем в руках и запугайте
не знаю плакать вам или смеяться, но я и есть тот самый АБД
авториндексом на временной таблице в обмен на пиво
изменять структуру данных я не имею права - соглашение с разработчиком,
мы являемся владельцами данных, разработчик- владелец метаданных, и править нам
их запрещено - это значит создание/удаление индекса под запретом.
но мы можем дать рекомендации разработчику, если есть проблема.

в данном случае, советуем разработчику создать индекс на временную таблицу, чтобы
избегать фулл сканов?

автортот кусок плана, который вы показали - это жесть.
да, за 4 минуты прочесть 51744 строк - это и правда жесть.

...

Рейтинг:

0 / 0

26.07.2016, 17:05:53

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39280530

Dmitry Remizov

Гость

жвачкин,

можно попробовать
-Doracle.jdbc.defaultPrefetchSize=xxxxx

(предполагаю что это Java c Oracle драйверами).

ЗЫ
Не уверен что сработает однако :(.

...

Рейтинг:

0 / 0

26.07.2016, 17:16:48

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39280537

жвачкин

Гость

авторНам же вы показываете здесь огрызки сферических коней в вакууме
так оно и есть. но не всегда есть возможность сделать полноценный трейс:

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

Маша Иванова раз в месяц совершает некую процедуру обновления/копирования данных в базе.
Она пользуется интерфейсом, который любезно предоставил ей разработчик.
Маша настраивает фильтры, которых очень много, и нажимает на кнопку "Выполнить".
Обычно Маша ждёт минуту, этого времени достаточно, чтобы процедура отработала.
Но в какой-то момент Маша ждёт дольше и сообщает АБД, что "что-то подвисло". 
В процессе разбора выясняется, что разработчик выпустил обновление, которое
поставили на рабочую базу (на тестовой базе протестировать забыли или поленились проверить все отчёты)
 Вот и получилось, что проблемы ранее не было и она нежданно нагрянула.
АБД, видит активную сессию Маши Ивановой и запускает её трассировку,
а полученный огрызок изучает, и пишет письмо разработчику, параллельно выкладывая информацию
на форум, пытаясь разобраться что к чему.

Такая вот картина...

...

Рейтинг:

0 / 0

26.07.2016, 17:23:26

| Ответить | Цитировать | Написать

SQL*Net message from client - SQL*Net more data to client

#39280548

booby

Участник

Сообщения: 2 667

Рейтинг: 1 / 0

жвачкин,
добавление/удаление индекса не является изменением структуры данных.
Вам же никто не предлагает менять определение первичного ключа.

жвачкинв данном случае, советуем разработчику создать индекс на временную таблицу, чтобы
избегать фулл сканов?
дело не в том, чтобы "избегать фулсканов" вообще.
В данном конкретном случае фуллскан используется для фильтрации каждой строки, попадающей в отбор после этапа SORT GROUP BY
Если запрос у вас возвращает 54000 строк после этапа SORT GROUP BY,
то для каждой из них применяется фильтрующий fullscan по той же временной таблице.
Проблема здесь в том что у вас не один, а 54000 фуллсканов - на каждую восстановленную строку по персональному фуллскану..

Индекс вынут из того же носа, что и все остальное - из предоставленного вами вакуума.
Неудачный индекс сам по себе может дополнительно ухудшить вашу историю.
А удачный - (может быть) не только ускорит обе фазы разом, но и позволит преобразовать фильтр в join (запрос вы так и не показали).
И ваши 210 секунд превратятся в 0.02 или 0/002 секунд.
Т. е. даст выигрыш по времени в 3-4-5 порядков.
Но, может оказаться, что к удачному индексу подкрутка запроса прилагаться должна.

жвачкинв данном случае, советуем разработчику создать индекс на временную таблицу, чтобы
избегать фулл сканов?

Интересно, как вы это планируете сформулировать?
Мне тут на форуме один booby индекс создать присоветовал?

...

Рейтинг:

0 / 0

26.07.2016, 17:33:25

| Ответить | Цитировать | Написать

25 сообщений из 29, страница 1 из 2

все

Форумы / Oracle [игнор отключен] [закрыт для гостей] / SQL*Net message from client - SQL*Net more data to client

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=52&msg=39280200&tid=1887782]:	0ms
get settings:	11ms
get forum list:	15ms
check forum access:	3ms
check topic access:	3ms
track hit:	199ms
get topic data:	10ms
get forum data:	2ms
get page messages:	64ms
get tp. blocked users:	1ms
others:	244ms

total:	552ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы