powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / CLI и SQLRowCount
14 сообщений из 14, страница 1 из 1
CLI и SQLRowCount
    #34345201
Dmitry Y.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
День добрый.


Столкнулся с таким моментом.

Выполняется выборка на CLI. Сам Execute занимает допустим 2 сек (250к записей), а вот
SQLRowCount выполняется 20-30сек.

Т.е. получается, что выборка с сортировкой занимает 2 сек , а узнать кол-во записей в
этой выборке надо 20-30сек.


Или есть иной, более правильный, способ узнать кол-во записей?


Спасибо.
...
Рейтинг: 0 / 0
CLI и SQLRowCount
    #34346537
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вы используете SQLRowCount() для селектов?
И что, она что-то похожее на правду при этом возвращает?
Тут написано, что она должна для UPDATE, INSERT, DELETE, MERGE команд работать...
Если так уж охота точное кол-во записей узнать, может, можно запрос типа
Код: plaintext
1.
2.
3.
4.
5.
with a as 
(
"ваш_запрос"
)
select a.*, (select count( 1 ) from a) $rowcnt
from a;
написать?
...
Рейтинг: 0 / 0
CLI и SQLRowCount
    #34351176
Dmitry Y.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
автор

Вы используете SQLRowCount() для селектов?
И что, она что-то похожее на правду при этом возвращает?





Как это не странно - правду:) Просто дико тормозит при больших запросах. Как будто пытается все считать до конца - а потом возвращает значение.


Понятно, что можно запрос напичать так - чтобы он возвращал кол-во записей. Но я как то привык, что такого рода информация, где то должна лежать в самом statement.
...
Рейтинг: 0 / 0
CLI и SQLRowCount
    #34351568
Dmitry Y.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
И еще.

Код: plaintext
1.
2.
3.
4.
5.
6.
with a as 
(
"ваш_запрос"
)
select a.*, (select count( 1 ) from a) $rowcnt
from a;

Первый fetch из такой выборки занимает те самые 30 сек. Остальные мгновенно:)
Очень странно.
...
Рейтинг: 0 / 0
CLI и SQLRowCount
    #34351573
Dmitry Y.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вывод такой - информация о кол-ве записей в запросе, более ресурсоемкая, чем сам запрос. Но как так получается, для меня загадка.
...
Рейтинг: 0 / 0
CLI и SQLRowCount
    #34352372
mustaccio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dmitry Y.Вывод такой - информация о кол-ве записей в запросе, более ресурсоемкая, чем сам запрос. Но как так получается, для меня загадка.

Это иллюзия. Если в запросе нет никаких операций, требующих его полной материализации (сортировки, агрегации и т.п.), то ДБ2 может начать возвращать записи, не дожидаясь полной обработки запроса. Иначе говоря, первая запись может быть возвращена еще до того, как последняя прочитана с диска.

В вашем случае, чтобы определить результат, ДБ2 приходится сначала прочитать _все_ записи, прежде чем вернуть хоть что-нибудь.
...
Рейтинг: 0 / 0
CLI и SQLRowCount
    #34352592
Dmitry Y.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
В запросе присутствует и сортировка и выборка из нескольких таблиц и условие. Агрегации нет.
...
Рейтинг: 0 / 0
CLI и SQLRowCount
    #34353041
mustaccio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dmitry Y.Агрегации нет.

Как это "нет"? А COUNT(1) - это что?
...
Рейтинг: 0 / 0
CLI и SQLRowCount
    #34353178
Dmitry Y.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mustaccio Dmitry Y.Агрегации нет.

Как это "нет"? А COUNT(1) - это что?


Мух с котлетами не путайте. Вопрос в том, почему запрос исполняется за 2сек, а кол-во записей в запросе 20-30сек при сортировках, сложных выборках и тп. COUNT(1) один из способов узнать кол-во записей в запросе. SQLRowCount тоже работает.
...
Рейтинг: 0 / 0
CLI и SQLRowCount
    #34355308
mustaccio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ладно, попробую объяснить еще раз.

Если в запросе нет сортировки или агрегатных функций, таких как, например, COUNT(), первые записи возвращаются клиенту, как только они прочитаны с диска (или из буфера). У наблюдателя создается иллюзия мгновенного возврата результатов, тогда как запрос на самом деле продолжает работать и выбирать дополнительные данные.

Код: plaintext
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.
SQL Statement:

  select userid
  from pwwdbo.logfile


Section Code Page = 1252

Estimated Cost = 452977.031250
Estimated Cardinality = 3220124.000000

Access Table Name = PWWDBO.LOGFILE  ID = 2,23
|  Index Scan:  Name = PWWDBO.XLOGFILE0  ID = 1
|  |  Regular Index (Not Clustered)
|  |  Index Columns:
|  |  |  1: USERID (Ascending)
|  |  |  2: APPLICATION (Ascending)
|  |  |  3: DATE (Ascending)
|  |  |  4: TIME (Ascending)
|  #Columns = 1
|  #Key Columns = 0
|  |  Start Key: Beginning of Index
|  |  Stop Key: End of Index
|  Index-Only Access
|  Index Prefetch: Eligible 48091
|  Lock Intents
|  |  Table: Intent Share
|  |  Row  : Next Key Share
|  Sargable Index Predicate(s)
|  |  Return Data to Application
|  |  |  #Columns = 1
Return Data Completion

End of section


Optimizer Plan:

       RETURN
       (   1)
         |
       IXSCAN
       (   2)
      /      \
 Index:     Table:
 PWWDBO     PWWDBO
 XLOGFILE0  LOGFILE

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

Код: plaintext
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.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
SQL Statement:

  select userid, (
     select count(1)
     from pwwdbo.logfile)a
  from pwwdbo.logfile


Section Code Page = 1252

Estimated Cost = 906194.875000
Estimated Cardinality = 3220124.000000

Access Table Name = PWWDBO.LOGFILE  ID = 2,23
|  Index Scan:  Name = PWWDBO.XLOGFILE0  ID = 1
|  |  Regular Index (Not Clustered)
|  |  Index Columns:
|  |  |  1: USERID (Ascending)
|  |  |  2: APPLICATION (Ascending)
|  |  |  3: DATE (Ascending)
|  |  |  4: TIME (Ascending)
|  #Columns = 0
|  #Key Columns = 0
|  |  Start Key: Beginning of Index
|  |  Stop Key: End of Index
|  Index-Only Access
|  Index Prefetch: Eligible 48091
|  Lock Intents
|  |  Table: Intent Share
|  |  Row  : Next Key Share
|  Sargable Index Predicate(s)
|  |  Predicate Aggregation
|  |  |  Column Function(s)
Aggregation Completion
|  Column Function(s)
Nested Loop Join
|  Access Table Name = PWWDBO.LOGFILE  ID = 2,23
|  |  Index Scan:  Name = PWWDBO.XLOGFILE0  ID = 1
|  |  |  Regular Index (Not Clustered)
|  |  |  Index Columns:
|  |  |  |  1: USERID (Ascending)
|  |  |  |  2: APPLICATION (Ascending)
|  |  |  |  3: DATE (Ascending)
|  |  |  |  4: TIME (Ascending)
|  |  #Columns = 1
|  |  #Key Columns = 0
|  |  |  Start Key: Beginning of Index
|  |  |  Stop Key: End of Index
|  |  Index-Only Access
|  |  Index Prefetch: Eligible 48091
|  |  Lock Intents
|  |  |  Table: Intent Share
|  |  |  Row  : Next Key Share
|  |  Sargable Index Predicate(s)
|  |  |  Return Data to Application
|  |  |  |  #Columns = 2
Return Data Completion

End of section


Optimizer Plan:

                 RETURN
                 (   1)
                   |
                 NLJOIN
                 (   2)
             /--/      \--\
       GRPBY               IXSCAN
       (   3)              (   2)
         |                /      \
       IXSCAN        Index:     Table:
       (   4)        PWWDBO     PWWDBO
      /      \       XLOGFILE0  LOGFILE
 Index:     Table:
 PWWDBO     PWWDBO
 XLOGFILE0  LOGFILE
...
Рейтинг: 0 / 0
CLI и SQLRowCount
    #34356231
Dmitry Y.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ситуация немного поменялась. Теперь первый fetch тормозит.
Вот кучочек отладочного лога:

Создали временную талицу.

BEGIN SendQuery2 2007-02-26 15:24:59 =======================================
QUERY: DECLARE GLOBAL TEMPORARY TABLE session.controltape(
END Elapsed :32 ms ==============================================

Туда закинули 250к записей.

BEGIN SendQuery2 2007-02-26 15:25:02 =======================================
QUERY: insert into session.controltape select check_num,
END Elapsed :2860 ms ==============================================


Посчитали там кол-во записей за 109 мс :)

BEGIN SendInsertQuery 2007-02-26 15:25:02 =======================================
QUERY: SELECT count(*) FROM session.controltape
END Elapsed :109 ms ==============================================


Сделали выборку.
BEGIN SendQuery 2007-02-26 15:25:02 =======================================
QUERY: SELECT check_num,CHAR(dates) as dates,cash_code,casher_code,sect,smena,group_s,plu,names,izm,cnt/1000.0 as cnt,prr/100.0 as prr, sk/100.0 as sk,sumr/100.0 as sumr,CHAR(rowid) as rowid FROM session.controltape ORDER BY UPPER(plu) ASC,rowid ASC
END Elapsed Execute :32 ms Rowcount :0 ms =========================



Считали первые 100 строк за 11 сек!!!!!
BEGIN Fetch 2007-02-26 15:25:13 =======================================
END Elapsed :11047 ms ==============================================

Следующие 100 строк.
BEGIN Fetch 2007-02-26 15:25:24 =======================================
END Elapsed :93 ms ==============================================



Откуда на первом fetch 11сек? Вот отсюда все грабли.
...
Рейтинг: 0 / 0
CLI и SQLRowCount
    #34356382
mustaccio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dmitry Y.ORDER BY UPPER(plu) ASC,rowid ASC
END Elapsed Execute :32 ms Rowcount :0 ms =========================



Считали первые 100 строк за 11 сек!!!!!
BEGIN Fetch 2007-02-26 15:25:13 =======================================
END Elapsed :11047 ms ==============================================

Следующие 100 строк.
BEGIN Fetch 2007-02-26 15:25:24 =======================================
END Elapsed :93 ms ==============================================



Откуда на первом fetch 11сек? Вот отсюда все грабли.

Вам, безусловно, откроется истина, когда вы научитесь пользоваться EXPLAIN.
...
Рейтинг: 0 / 0
CLI и SQLRowCount
    #34357435
Dmitry Y.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mustaccio Dmitry Y.
Откуда на первом fetch 11сек? Вот отсюда все грабли.

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

Ну как расскажите, как я сделаю explain на fetch? ;)
...
Рейтинг: 0 / 0
CLI и SQLRowCount
    #34357485
Dmitry Y.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
BTW, такой запрос в IBM-ком контрол центре исполняется и показывает первые 100 записей менее чем за 2 сек. Вот что мне покоя не дает.
...
Рейтинг: 0 / 0
14 сообщений из 14, страница 1 из 1
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / CLI и SQLRowCount
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]