Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / IBM DB2, WebSphere, IMS, U2, etc Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4]      все
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4869
use-se
И что же делать с SORTHEAP и остальными автоматическими настройками?
Отказаться, или каждый раз перед тяжелыми задачами менять SORTHEAP, SHEAPTHRES_SHR, LOCKLIST и пр.?

Хороший вопрос...
Если это преимущественно транзакционная система, то такой большой SORTHEAP может "скрывать" проблемы приложений. Транзакционые запросы не должны делать большие сортировки. Если при маленьком SORTHEAP вы можете отловить такие запросы по кол-ву переполнений сортировок (SORT_OVERFLOWS), то при большом вы их, скорее всего, не увидите, этих переполнений. И вам придется обнаруживать такие запросы по другим признакам, например, по заметному TOTAL_SECTION_SORT_TIME. Это если вы вообще этим занимаетесь...
20 окт 16, 18:32    [19805880]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
use-se
Mark Barinstein
use-se,
Суда по цене запроса план с HSJOIN имеет заметно меньшую цену, когда вы значительно расширили SORTHEAP.
Теперь можно попробовать без профиля попробовать (должно выбрать HSJOIN) и время выполнения с HSJOIN.
Ну и всё же с intra-parallel тоже надо бы попробовать.

Мда, результат есть, ранее лучшее время было 2ч 30м -
сейчас 38минут, и таки да, я увидел скорость чтения 100-300 стабильно и в пике 700мб/с.
Большое спасибо всем кто помог и учавствовал.

И что же делать с SORTHEAP и остальными автоматическими настройками?
Отказаться, или каждый раз перед тяжелыми задачами менять SORTHEAP, SHEAPTHRES_SHR, LOCKLIST и пр.?


Я помню в моих экспериментах, что HSJOIN DB2 в плане показывала не в том порядке, что Oracle (при примерно одинаковом выполнении). Так что или я глючу и всё напутал, или имеет смысл попробовать поменять порядок:

+
<?xml version="1.0" encoding="UTF-8"?>
<OPTPROFILE VERSION="9.1.0.0">

<STMTPROFILE ID="Test Guidelines">
<STMTKEY>
<![CDATA[SELECT h.c1_id, h.c2_HISTORY_DATE, h.PAY_STATUS
FROM big_tab h, small_tab l
WHERE h.c1_id =l.c1_id
WITH UR]]>
</STMTKEY>
<OPTGUIDELINES>
<HSJOIN>
<TBSCAN TABLE='l'/>
<TBSCAN TABLE='h'/>
</HSJOIN>
</OPTGUIDELINES>
</STMTPROFILE>
</OPTPROFILE>


Кроме того, мы всё ещё не увидели вариант с MDC, который имеет шансы быть самым быстрым.

MDC, де-факто, это IOT (Index Organized Table), только когда в обычном индексе вы при поиске c1_id получаете строку (или несколько строк с равным c1_id), здесь вы найдёте сразу экстент (или набор экстентов) с равным c1_id, к чему можно применить многоблочное чтение.
20 окт 16, 23:08    [19806565]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
use-se
Member

Откуда: Москва
Сообщений: 448
Mark Barinstein
use-se
И что же делать с SORTHEAP и остальными автоматическими настройками?
Отказаться, или каждый раз перед тяжелыми задачами менять SORTHEAP, SHEAPTHRES_SHR, LOCKLIST и пр.?

Хороший вопрос...
Если это преимущественно транзакционная система, то такой большой SORTHEAP может "скрывать" проблемы приложений. Транзакционые запросы не должны делать большие сортировки. Если при маленьком SORTHEAP вы можете отловить такие запросы по кол-ву переполнений сортировок (SORT_OVERFLOWS), то при большом вы их, скорее всего, не увидите, этих переполнений. И вам придется обнаруживать такие запросы по другим признакам, например, по заметному TOTAL_SECTION_SORT_TIME. Это если вы вообще этим занимаетесь...

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

Victor Metelitsa
Кроме того, мы всё ещё не увидели вариант с MDC, который имеет шансы быть самым быстрым.

Да Вы правы за мной должок:
1) Тест с MDC по С1
2) Тест с профилем, который Вы предложили в последнем письме
3) Не уверен, что нужен тест с HJ на FlashSystem, но если кого заинтересует то сделаю
4) Думаю все же сделать тест с профилем NL, и индексом на малую таблицу (первый/старый план), и с увеличенным SORTHEAP
5) С включенным INTRA_PARALLEL=YES
Только прошу не ожидать от меня быстрых результатов, тесты буду делать в свободное от работы время
и по доступности ресурсов.

Еще раз всем большое спасибо.
21 окт 16, 11:37    [19808105]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4869
Victor Metelitsa
Я помню в моих экспериментах, что HSJOIN DB2 в плане показывала не в том порядке, что Oracle (при примерно одинаковом выполнении).
Да, это так.
DB2 build (или inner) сторону (маленькую таблицу) показывает справа, в отличие от Oracle.
У DB2 правило - outer таблица join'а - слева, inner - справа.

Victor Metelitsa
Кроме того, мы всё ещё не увидели вариант с MDC, который имеет шансы быть самым быстрым.

MDC, де-факто, это IOT (Index Organized Table), только когда в обычном индексе вы при поиске c1_id получаете строку (или несколько строк с равным c1_id), здесь вы найдёте сразу экстент (или набор экстентов) с равным c1_id, к чему можно применить многоблочное чтение.

Статистика по C1_ID большой таблицы:

Number of distinct column values: 200 644 459 (из 5 242 341 755)

Для MDC очень опасная ситуация - в среднем по 25 значений на один id. Даже с минимальными pagesize = 4 K и extent size = 2 это будет очень большая трата дискового места зря - 8K для 25 коротких записей.
Я бы очень не рекомендовал использовать MDC здесь - у поля слишком высокая кардинальность.
21 окт 16, 17:17    [19810369]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
Проверил и убедился, что таки сглючил
+
Access Plan:
-----------
Total Cost: 61711.4
Query Degree: 1

Rows
RETURN
( 1)
Cost
I/O
|
1
GRPBY
( 2)
61711.4
36105
|
10000
HSJOIN
( 3)
61711.1
36105
/-----+------\
1e+007 100
TBSCAN TBSCAN
( 4) ( 5)
61476.3 8.66916
36104 1
| |
1e+007 100
TABLE: DB2INST1 TABLE: DB2INST1
T_BIG T_SMALL
Q2 Q1
(хм, я почему-то думал, что будет наоборот. или тогда глючил не я, а DB2 выдавала странный план?)

и поленился просчитать MDC.

Правда, у меня тут же возникла мысль делать MDC не по C1_ID, а по выражению вроде C1_ID/1000 (и для верности прибавить h. C1_ID/1000=l. C1_ID/1000 в условие), но, хотя растрату пространства таким способом можно радикально уменьшить, выигрыш в скорости под сомнением. По-видимому, он будет, если диапазон возможных значений C1_ID в маленькой таблице "радикально" меньше диапазона в большой. В таком случае "нужные" строчки сконцентрируются в относительно небольшом количестве экстентов. В целом, сомнительная затея.

Ну, а кусок буферного пула под крупноблочность в любом случае должно быть полезно выделить.
21 окт 16, 18:33    [19810626]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
Кстати, поскольку речь шла не о простой выборке, а о выборке со вставкой в таблицу, ограничивать могут транзакционные логи и чистка грязного буферного пула.
24 окт 16, 09:33    [19814361]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
use-se
Member

Откуда: Москва
Сообщений: 448
Victor Metelitsa
Кстати, поскольку речь шла не о простой выборке, а о выборке со вставкой в таблицу, ограничивать могут транзакционные логи и чистка грязного буферного пула.

Там NOT LOGGED INITIALLY.
Относительно MDC, получается что таблица займет примерно 1.6 ТБ?
С практичекой точки зрения это не применимо.
Поскольку таблицу все равно придется читать полностью, то и скорость
выборки не уверен что вырастет.
24 окт 16, 12:30    [19815255]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
Ну да, Марк показал, что MDC не годится, а я поленился подсчитать.

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

См.

num_iocleaners http://www.ibm.com/support/knowledgecenter/en/SSEPGG_10.5.0/com.ibm.db2.luw.admin.config.doc/doc/r0000332.html

DB2_USE_ALTERNATE_PAGE_CLEANING http://www.ibm.com/support/knowledgecenter/en/SSEPGG_10.5.0/com.ibm.db2.luw.admin.regvars.doc/doc/r0005665.html

и т.п.

По-хорошему, конечно, следовало бы сперва посмотреть мониторингом на то, во что оно таки упирается.
24 окт 16, 14:33    [19815871]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
use-se
Member

Откуда: Москва
Сообщений: 448
Victor Metelitsa
Ну да, Марк показал, что MDC не годится, а я поленился подсчитать.

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

См.

num_iocleaners http://www.ibm.com/support/knowledgecenter/en/SSEPGG_10.5.0/com.ibm.db2.luw.admin.config.doc/doc/r0000332.html

DB2_USE_ALTERNATE_PAGE_CLEANING http://www.ibm.com/support/knowledgecenter/en/SSEPGG_10.5.0/com.ibm.db2.luw.admin.regvars.doc/doc/r0005665.html

и т.п.

По-хорошему, конечно, следовало бы сперва посмотреть мониторингом на то, во что оно таки упирается.

Спасибо за подсказку, но пока не планирую совершать каких либо резких движений.
1) За время обсуждения данной проблемы мои взгляды на текущее состояние БД сильно пошатнулись и мне
сейчас гораздо важнее найти другие проблемы, которые сейчас для меня не видны.
К примеру, те же планы запросов пересмотреть с увеличенными SORTHEAP и пр.
Нужно разобраться с использованием временых TS.
2) БД преймущественно OLTP и рассматриваемый запрос запускается 1 раз в сутки.
Сейчас стоит вот так:
Changed pages threshold                (CHNGPGS_THRESH) = 60
Number of asynchronous page cleaners (NUM_IOCLEANERS) = AUTOMATIC(39)
и честно говоря я пока не готов что либо менять.
Пока в планах попробовать отказаться от STMM.
Кстати, параметр NUM_IOCLEANERS практически всегда держится на ~40 и практически не плавает.
24 окт 16, 17:43    [19816994]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
Полезно же понять, что запрос упирается именно во вставку (или не упирается), в том числе в сопутствущую чистку буферов, пусть и не делая никаких "резких движений".
24 окт 16, 18:19    [19817191]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
use-se
Member

Откуда: Москва
Сообщений: 448
Victor Metelitsa
Полезно же понять, что запрос упирается именно во вставку (или не упирается), в том числе в сопутствущую чистку буферов, пусть и не делая никаких "резких движений".

Вы абсолютно правы.
Просто, нужно хотя бы сделать те тесты, что я описал ранее.
И вот прошел день, а я даже не начинал, то одно то другое и все вроде важное.
24 окт 16, 19:38    [19817411]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
use-se
Member

Откуда: Москва
Сообщений: 448
Victor Metelitsa
пропущено...

Я помню в моих экспериментах, что HSJOIN DB2 в плане показывала не в том порядке, что Oracle (при примерно одинаковом выполнении). Так что или я глючу и всё напутал, или имеет смысл попробовать поменять порядок:

+
<?xml version="1.0" encoding="UTF-8"?>
<OPTPROFILE VERSION="9.1.0.0">

<STMTPROFILE ID="Test Guidelines">
<STMTKEY>
<![CDATA[SELECT h.c1_id, h.c2_HISTORY_DATE, h.PAY_STATUS
FROM big_tab h, small_tab l
WHERE h.c1_id =l.c1_id
WITH UR]]>
</STMTKEY>
<OPTGUIDELINES>
<HSJOIN>
<TBSCAN TABLE='l'/>
<TBSCAN TABLE='h'/>
</HSJOIN>
</OPTGUIDELINES>
</STMTPROFILE>
</OPTPROFILE>


пропущено....

2) Вот план запроса, если в профиле поменять местами таблицы (inner,outer)
+
DB2 Universal Database Version 9.7, 5622-044 (c) Copyright IBM Corp. 1991, 2009
Licensed Material - Program Property of IBM
IBM DATABASE 2 Explain Table Format Tool



******************** EXPLAIN INSTANCE ********************

DB2_VERSION: 09.07.8
SOURCE_NAME: SQLC2H23
SOURCE_SCHEMA: NULLID
SOURCE_VERSION:
EXPLAIN_TIME: 2016-10-25-11.27.30.612007
EXPLAIN_REQUESTER: SH1

Database Context:
----------------
Parallelism: None
CPU Speed: 3,306410e-007
Comm Speed: 0
Buffer Pool size: 74211200
Sort Heap size: 100000
Database Heap size: 300000
Lock List size: 8398152
Maximum Lock List: 98
Average Applications: 50
Locks Available: 263366048

Package Context:
---------------
SQL Type: Dynamic
Optimization Level: 5
Blocking: Block All Cursors
Isolation Level: Uncommitted Read



---------------- STATEMENT 1 SECTION 201 ----------------
QUERYNO: 2
QUERYTAG: CLP
Statement Type: Select
Updatable: No
Deletable: No
Query Degree: 1

Profile Information:
--------------------
OPT_PROF: (Optimization Profile Name)
SH1.PROF2
STMTPROF: (Statement Profile Name)
Test Guidelines

Original Statement:
------------------
SELECT h.C1_ID, h.C2_HISTORY_DATE, h.PAY_STATUS
FROM SH1.BIG_TAB h, SH2.SMALL_TAB l
WHERE h.C1_ID = l.C1_ID
WITH UR


Optimized Statement:
-------------------
SELECT Q2.C1_ID AS "C1_ID", Q2.C2_HISTORY_DATE AS "C2_HISTORY_DATE", Q2.PAY_STATUS AS
"PAY_STATUS"
FROM SH2.SMALL_TAB AS Q1, SH1.BIG_TAB AS Q2
WHERE (Q2.C1_ID = Q1.C1_ID)

Access Plan:
-----------
Total Cost: 3,40282e+038
Query Degree: 1

Rows
RETURN
( 1)
Cost
I/O
|
1,69059e+008
HSJOIN
( 2)
3,40282e+038
3,40282e+038
/-----+------\
6,47055e+006 5,24234e+009
TBSCAN TBSCAN
( 3) ( 4)
38146,2 1,56039e+008
29031 8,66775e+007
| |
6,47055e+006 5,24234e+009
TABLE: SH2 TABLE: SH1
SMALL_TAB BIG_TAB
Q1 Q2



Extended Diagnostic Information:
--------------------------------

No extended Diagnostic Information for this statement.


Plan Details:
-------------


1) RETURN: (Return Result)
Cumulative Total Cost: 3,40282e+038
Cumulative CPU Cost: 3,40282e+038
Cumulative I/O Cost: 3,40282e+038
Cumulative Re-Total Cost: 3,40282e+038
Cumulative Re-CPU Cost: 3,40282e+038
Cumulative Re-I/O Cost: 3,40282e+038
Cumulative First Row Cost: 3,40282e+038
Estimated Bufferpool Buffers: 3,40282e+038

Arguments:
---------
BLDLEVEL: (Build level)
DB2 v9.7.800.717 : s130316
HEAPUSE : (Maximum Statement Heap Usage)
96 Pages
PREPTIME: (Statement prepare time)
228 milliseconds
STMTHEAP: (Statement heap size)
4096

Input Streams:
-------------
5) From Operator #2

Estimated number of rows: 1,69059e+008
Number of columns: 3
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q3.PAY_STATUS+Q3.C2_HISTORY_DATE+Q3.C1_ID


2) HSJOIN: (Hash Join)
Cumulative Total Cost: 3,40282e+038
Cumulative CPU Cost: 3,40282e+038
Cumulative I/O Cost: 3,40282e+038
Cumulative Re-Total Cost: 3,40282e+038
Cumulative Re-CPU Cost: 3,40282e+038
Cumulative Re-I/O Cost: 3,40282e+038
Cumulative First Row Cost: 3,40282e+038
Estimated Bufferpool Buffers: 3,40282e+038

Arguments:
---------
BITFLTR : (Hash Join Bit Filter used)
FALSE
EARLYOUT: (Early Out flag)
NONE
HASHCODE: (Hash Code Size)
32 BIT
HASHTBSZ: (Number of hash table entries)
200644464
TEMPSIZE: (Temporary Table Page Size)
4096
TUPBLKSZ: (Tuple Block Size (bytes))
16000

Predicates:
----------
2) Predicate used in Join,
Comparison Operator: Equal (=)
Subquery Input Required: No
Filter Factor: 4,98394e-009

Predicate Text:
--------------
(Q2.C1_ID = Q1.C1_ID)



Input Streams:
-------------
2) From Operator #3

Estimated number of rows: 6,47055e+006
Number of columns: 1
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q1.C1_ID

4) From Operator #4

Estimated number of rows: 5,24234e+009
Number of columns: 3
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q2.PAY_STATUS+Q2.C2_HISTORY_DATE+Q2.C1_ID


Output Streams:
--------------
5) To Operator #1

Estimated number of rows: 1,69059e+008
Number of columns: 3
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q3.PAY_STATUS+Q3.C2_HISTORY_DATE+Q3.C1_ID


3) TBSCAN: (Table Scan)
Cumulative Total Cost: 38146,2
Cumulative CPU Cost: 1,13216e+010
Cumulative I/O Cost: 29031
Cumulative Re-Total Cost: 3684,1
Cumulative Re-CPU Cost: 1,11423e+010
Cumulative Re-I/O Cost: 0
Cumulative First Row Cost: 9,0773
Estimated Bufferpool Buffers: 29031

Arguments:
---------
JN INPUT: (Join input leg)
OUTER
MAXPAGES: (Maximum pages for prefetch)
ALL
PREFETCH: (Type of Prefetch)
SEQUENTIAL
ROWLOCK : (Row Lock intent)
NONE
SCANDIR : (Scan Direction)
FORWARD
SPEED : (Assumed speed of scan, in sharing structures)
FAST
TABLOCK : (Table Lock intent)
INTENT NONE
TBISOLVL: (Table access Isolation Level)
UNCOMMITTED READ
THROTTLE: (Scan may be throttled, for scan sharing)
TRUE
VISIBLE : (May be included in scan sharing structures)
TRUE
WRAPPING: (Scan may start anywhere and wrap)
TRUE

Input Streams:
-------------
1) From Object SH2.SMALL_TAB

Estimated number of rows: 6,47055e+006
Number of columns: 2
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q1.$RID$+Q1.C1_ID


Output Streams:
--------------
2) To Operator #2

Estimated number of rows: 6,47055e+006
Number of columns: 1
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q1.C1_ID


4) TBSCAN: (Table Scan)
Cumulative Total Cost: 1,56039e+008
Cumulative CPU Cost: 9,56255e+012
Cumulative I/O Cost: 8,66775e+007
Cumulative Re-Total Cost: 1,56039e+008
Cumulative Re-CPU Cost: 9,56255e+012
Cumulative Re-I/O Cost: 8,66775e+007
Cumulative First Row Cost: 12,8677
Estimated Bufferpool Buffers: 8,66775e+007

Arguments:
---------
JN INPUT: (Join input leg)
INNER
MAXPAGES: (Maximum pages for prefetch)
ALL
PREFETCH: (Type of Prefetch)
SEQUENTIAL
ROWLOCK : (Row Lock intent)
NONE
SCANDIR : (Scan Direction)
FORWARD
SPEED : (Assumed speed of scan, in sharing structures)
FAST
TABLOCK : (Table Lock intent)
INTENT NONE
TBISOLVL: (Table access Isolation Level)
UNCOMMITTED READ
THROTTLE: (Scan may be throttled, for scan sharing)
TRUE
VISIBLE : (May be included in scan sharing structures)
TRUE
WRAPPING: (Scan may start anywhere and wrap)
TRUE

Input Streams:
-------------
3) From Object SH1.BIG_TAB

Estimated number of rows: 5,24234e+009
Number of columns: 4
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q2.$RID$+Q2.PAY_STATUS+Q2.C2_HISTORY_DATE+Q2.C1_ID


Output Streams:
--------------
4) To Operator #2

Estimated number of rows: 5,24234e+009
Number of columns: 3
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q2.PAY_STATUS+Q2.C2_HISTORY_DATE+Q2.C1_ID


Objects Used in Access Plan:
---------------------------

Schema: SH1
Name: BIG_TAB
Type: Table

Schema: SH2
Name: SMALL_TAB
Type: Table

Extended Statistics Information:
--------------------------------

Tablespace Context:
-------------------
Name: T_H_TS_IDX
Overhead: 12.670000
Transfer Rate: 0.180000
Prefetch Size: 1920
Extent Size: 32
Type: Database managed
Partition Group Name: NULLP
Buffer Pool Identifier: 0

Name: T_H_TS_TBLS
Overhead: 12.670000
Transfer Rate: 0.180000
Prefetch Size: 1920
Extent Size: 32
Type: Database managed
Partition Group Name: NULLP
Buffer Pool Identifier: 0

Name: GVAPTABS
Overhead: 9.000000
Transfer Rate: 0.060000
Prefetch Size: 192
Extent Size: 32
Type: Database managed
Partition Group Name: NULLP
Buffer Pool Identifier: 0

Base Table Statistics:
----------------------
Name : SMALL_TAB
Schema: SH2
Number of Columns: 1
Number of Pages with Rows: 29031
Number of Pages: 29031
Number of Rows: 6470552
Table Overflow Record Count: 0
Width of Rows: 14
Time of Creation: 2016-09-09-01.00.34.218012
Last Statistics Update: 2016-09-09-01.21.43.373004
Primary Tablespace: GVAPTABS
Tablespace for Indexes: NULLP
Tablespace for Long Data: NULLP
Number of Referenced Columns: 1
Number of Indexes: 0
Volatile Table: No
Number of Active Blocks: -1
Number of Column Groups: 0
Number of Data Partitions: 1
Average Row Compression Ratio: -1.000000
Percent Rows Compressed: -1.000000
Average Compressed Row Size: -1
Statistics Type: U

Column Information:
--------------------
Number: 1
Name: C1_ID
Statistics Available: Yes

Column Statistics:
------------------
Schema name of the column type: SYSIBM
Name of column type: BIGINT
Maximum column length: 8
Scale for decimal or timestamp column: 0
Number of distinct column values: 6470552
Average column length: 8
Number of most frequent values: -1
Number of quantiles: 20
Second highest data value: 268615579
Second lowest data value: 1537590
Column sequence in partition key: 0
Average number of sub-elements: -1
Average length of delimiters: -1

Column Distribution Statistics:
-------------------------------
Quantile Statistics:
Valcount Value Distcount
----------------------------------------------
1 1142011 1
340555 87288721 340555
681111 106824791 681111
1021666 132208218 1021666
1362221 144856874 1362221
1702777 152931756 1702777
2043332 164940760 2043332
2383888 178662943 2383888
2724443 190381699 2724443
3064998 199993277 3064998
3405554 211764305 3405554
3746109 231107293 3746109
4086664 237462093 4086664
4427220 241699507 4427220
4767775 246905464 4767775
5108331 252268977 5108331
5448886 257246078 5448886
5789441 261978211 5789441
6129997 266292888 6129997
6470552 268615580 6470552

Base Table Statistics:
----------------------
Name : BIG_TAB
Schema: SH1
Number of Columns: 9
Number of Pages with Rows: 86677492
Number of Pages: 86677492
Number of Rows: 5242341755
Table Overflow Record Count: 0
Width of Rows: 44
Time of Creation: 2015-05-02-21.32.08.419004
Last Statistics Update: 2016-10-12-11.06.17.653000
Primary Tablespace: T_H_TS_TBLS
Tablespace for Indexes: T_H_TS_IDX
Tablespace for Long Data: NULLP
Number of Referenced Columns: 3
Number of Indexes: 1
Volatile Table: No
Number of Active Blocks: -1
Number of Column Groups: 0
Number of Data Partitions: 1
Average Row Compression Ratio: -1.000000
Percent Rows Compressed: -1.000000
Average Compressed Row Size: -1
Statistics Type: U

Column Information:
--------------------
Number: 4
Name: PAY_STATUS
Statistics Available: Yes

Column Statistics:
------------------
Schema name of the column type: SYSIBM
Name of column type: SMALLINT
Maximum column length: 2
Scale for decimal or timestamp column: 0
Number of distinct column values: 11
Average column length: 2
Number of most frequent values: 10
Number of quantiles: 14
Second highest data value: 2052
Second lowest data value: 2025
Column sequence in partition key: 0
Average number of sub-elements: -1
Average length of delimiters: -1

Column Distribution Statistics:
-------------------------------
Frequency Statistics:
Valcount Value
--------------------------------
-226909440 2022
335509920 2025
314540544 2043
199209008 2037
110089192 2028
73392800 2031
73392800 2034
31454056 2052
26211712 2040
10484685 2046

Quantile Statistics:
Valcount Value Distcount
----------------------------------------------
0 2022 0
-226909440 2022 0
-158759168 2025 0
48313344 2025 0
119085056 2028 0
187235840 2028 0
255385600 2031 0
326157824 2034 0
394308096 2037 0
533230080 2037 0
601380864 2043 0
879224832 2043 0
947374459 2052 0
947374459 2052 0

Column Information:
--------------------
Number: 2
Name: C2_HISTORY_DATE
Statistics Available: Yes

Column Statistics:
------------------
Schema name of the column type: SYSIBM
Name of column type: DATE
Maximum column length: 4
Scale for decimal or timestamp column: 0
Number of distinct column values: 3776
Average column length: 4
Number of most frequent values: 10
Number of quantiles: 20
Second highest data value: 2016-09-30
Second lowest data value: 1998-03-01
Column sequence in partition key: 0
Average number of sub-elements: -1
Average length of delimiters: -1

Column Distribution Statistics:
-------------------------------
Frequency Statistics:
Valcount Value
--------------------------------
20969370 2013-12-01
18348200 2015-03-24
15727028 2012-01-01
15727028 2012-07-01
15727028 2014-06-01
15727028 2014-11-30
15727028 2015-01-14
15727028 2015-05-14
15727028 2016-02-13
15727028 2016-07-01

Quantile Statistics:
Valcount Value Distcount
----------------------------------------------
2621171 2006-01-01 0
275222976 2009-08-08 0
553067136 2011-03-25 0
838774784 2012-01-01 0
1111376640 2012-07-01 0
1381357184 2012-12-19 0
1656580352 2013-06-01 0
1931803264 2013-10-01 0
-2087941120 2014-01-22 0
-1810096896 2014-05-27 0
-1532252928 2014-08-21 0
-1254408960 2014-12-15 0
-984427776 2015-03-11 0
-709204736 2015-05-31 0
-431360768 2015-08-29 0
-156137984 2015-11-27 0
121705984 2016-02-06 0
396929024 2016-04-09 0
672152064 2016-06-13 0
947374459 2016-09-01 0

Column Information:
--------------------
Number: 1
Name: C1_ID
Statistics Available: Yes

Column Statistics:
------------------
Schema name of the column type: SYSIBM
Name of column type: BIGINT
Maximum column length: 8
Scale for decimal or timestamp column: 0
Number of distinct column values: 200644459
Average column length: 8
Number of most frequent values: 10
Number of quantiles: 20
Second highest data value: 268783998
Second lowest data value: 1067929
Column sequence in partition key: 0
Average number of sub-elements: -1
Average length of delimiters: -1

Column Distribution Statistics:
-------------------------------
Frequency Statistics:
Valcount Value
--------------------------------
1299 36438362
1288 36447884
1131 33866795
1125 32505228
1112 33812528
1106 84402767
1084 78760604
1083 41686576
1077 33504966
1074 83684924

Quantile Statistics:
Valcount Value Distcount
----------------------------------------------
9 1067928 1
-1535840067 148562089 96135473
-1535839970 148562090 96135474
-1259927333 156774640 103673316
-1259927325 156774641 103673317
-984014650 166080005 112142940
-984014573 166080006 112142941
-708101903 176682081 121106182
-708101879 176682082 121106183
-432189190 185813489 129730788
-432189060 185813490 129730789
-156276450 196955705 139491342
-156276427 196955706 139491343
119636278 208728225 149829902
119636290 208728226 149829903
395549005 226710331 162637745
395549032 226710332 162637746
671461724 243685423 178698359
671461737 243685424 178698360
947374459 268783999 200644459

Indexes defined on the table:
-----------------------------
Name : BIG_TAB_PK
Schema: SH1
Unique Rule: Primary key index
Used in Operator: No
Page Fetch Pairs: Available
Number of Columns: 3
Index Leaf Pages: 57207556
Index Tree Levels: 5
Index First Key Cardinality: 200644459
Index Full Key Cardinality: 5242341755
Index Cluster Ratio: -1
Index Cluster Factor: 0.686509
Time of Creation: 2015-05-02-21.32.08.528002
Last Statistics Update: 2016-10-12-11.06.17.653000
Index Sequential Pages: 28302903
Index First 2 Keys Cardinality: 5241031435
Index First 3 Keys Cardinality: 5242341755
Index First 4 Keys Cardinality: -1
Index Avg Gap between Sequences: 222959.000000
Fetch Avg Gap between Sequences: -1.000000
Index Avg Sequential Pages: 786191.000000
Fetch Avg Sequential Pages: -1.000000
Index Avg Random Pages: 586145.000000
Fetch Avg Random Pages: -1.000000
Index RID Count: 5321149234
Index Deleted RID Count: 73837652
Index Empty Leaf Pages: 55765
Avg Partition Cluster Ratio: -1
Avg Partition Cluster Factor: -1.000000
Data Partition Cluster Factor: 1.000000
Data Partition Page Fetch Pairs: Not Available

Page Fetch Pairs information:
-----------------------------
Number of Page Fetch Pairs: 11

Buffer Size Page Fetches
--------------------------------------------------------
Pair 1: 100 1039302010
Pair 2: 350052 416376800
Pair 3: 9451404 206844276
Pair 4: 22053276 118214180
Pair 5: 31504680 98877758
Pair 6: 41656188 91777118
Pair 7: 53207904 89230548
Pair 8: 67910088 87250817
Pair 9: 86112792 86889824
Pair 10: 86462766 86462766
Pair 11: 86462766 86462766


стоимость выросла, сделал только план - выборку делать не стал

5) Сделал отдельный bufferpool на 200 000 страниц с numblockpages 50 000 для TS большой таблицы.
Включил intra_parallel. Включил monitor switches, сделал выборку. Время выборки уменьшилось с
38 минут до 35.
План запроса тут:
+
DB2 Universal Database Version 9.7, 5622-044 (c) Copyright IBM Corp. 1991, 2009
Licensed Material - Program Property of IBM
IBM DATABASE 2 Explain Table Format Tool



******************** EXPLAIN INSTANCE ********************

DB2_VERSION: 09.07.8
SOURCE_NAME: SQLC2H23
SOURCE_SCHEMA: NULLID
SOURCE_VERSION:
EXPLAIN_TIME: 2016-10-26-12.45.39.599003
EXPLAIN_REQUESTER: SH1

Database Context:
----------------
Parallelism: Intra-Partition Parallelism
CPU Speed: 3,306410e-007
Comm Speed: 0
Buffer Pool size: 74411200
Sort Heap size: 100000
Database Heap size: 300000
Lock List size: 8892802
Maximum Lock List: 98
Average Applications: 50
Locks Available: 278878272

Package Context:
---------------
SQL Type: Dynamic
Optimization Level: 5
Blocking: Block All Cursors
Isolation Level: Uncommitted Read



---------------- STATEMENT 1 SECTION 201 ----------------
QUERYNO: 2
QUERYTAG: CLP
Statement Type: Select
Updatable: No
Deletable: No
Query Degree: -1

Original Statement:
------------------
SELECT h.C1_ID, h.C2_HISTORY_DATE, h.PAY_STATUS
FROM SH1.BIG_TAB h, SH2.SMALL_TAB l
WHERE h.C1_ID = l.C1_ID
WITH UR


Optimized Statement:
-------------------
SELECT Q2.C1_ID AS "C1_ID", Q2.C2_HISTORY_DATE AS "C2_HISTORY_DATE", Q2.PAY_STATUS AS
"PAY_STATUS"
FROM SH2.SMALL_TAB AS Q1, SH1.BIG_TAB AS Q2
WHERE (Q2.C1_ID = Q1.C1_ID)

Access Plan:
-----------
Total Cost: 1,56539e+008
Query Degree: 40

Rows
RETURN
( 1)
Cost
I/O
|
1,69059e+008
LTQ
( 2)
1,56539e+008
8,67065e+007
|
1,69059e+008
HSJOIN
( 3)
1,565e+008
8,67065e+007
/-----+------\
5,24234e+009 6,47055e+006
TBSCAN TBSCAN
( 4) ( 5)
1,56039e+008 38146,2
8,66775e+007 29031
| |
5,24234e+009 6,47055e+006
TABLE: SH1 TABLE: SH2
BIG_TAB SMALL_TAB
Q2 Q1



Extended Diagnostic Information:
--------------------------------

No extended Diagnostic Information for this statement.


Plan Details:
-------------


1) RETURN: (Return Result)
Cumulative Total Cost: 1,56539e+008
Cumulative CPU Cost: 1,09698e+013
Cumulative I/O Cost: 8,67065e+007
Cumulative Re-Total Cost: 1,565e+008
Cumulative Re-CPU Cost: 1,08508e+013
Cumulative Re-I/O Cost: 8,67065e+007
Cumulative First Row Cost: 1,565e+008
Estimated Bufferpool Buffers: 8,66775e+007

Arguments:
---------
BLDLEVEL: (Build level)
DB2 v9.7.800.717 : s130316
HEAPUSE : (Maximum Statement Heap Usage)
96 Pages
PREPTIME: (Statement prepare time)
51858 milliseconds
STMTHEAP: (Statement heap size)
4096

Input Streams:
-------------
6) From Operator #2

Estimated number of rows: 1,69059e+008
Number of columns: 3
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q3.PAY_STATUS+Q3.C2_HISTORY_DATE+Q3.C1_ID


2) TQ : (Table Queue)
Cumulative Total Cost: 1,56539e+008
Cumulative CPU Cost: 1,09698e+013
Cumulative I/O Cost: 8,67065e+007
Cumulative Re-Total Cost: 1,565e+008
Cumulative Re-CPU Cost: 1,08508e+013
Cumulative Re-I/O Cost: 8,67065e+007
Cumulative First Row Cost: 1,565e+008
Estimated Bufferpool Buffers: 8,66775e+007

Arguments:
---------
LISTENER: (Listener Table Queue type)
FALSE
TQ TYPE : (Table queue type)
LOCAL
TQDEGREE: (Degree of Intra-Partition parallelism)
40
TQMERGE : (Merging Table Queue flag)
FALSE
TQREAD : (Table Queue Read type)
READ AHEAD
UNIQUE : (Uniqueness required flag)
FALSE

Input Streams:
-------------
5) From Operator #3

Estimated number of rows: 1,69059e+008
Number of columns: 3
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q3.PAY_STATUS+Q3.C2_HISTORY_DATE+Q3.C1_ID


Output Streams:
--------------
6) To Operator #1

Estimated number of rows: 1,69059e+008
Number of columns: 3
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q3.PAY_STATUS+Q3.C2_HISTORY_DATE+Q3.C1_ID


3) HSJOIN: (Hash Join)
Cumulative Total Cost: 1,565e+008
Cumulative CPU Cost: 1,08508e+013
Cumulative I/O Cost: 8,67065e+007
Cumulative Re-Total Cost: 1,565e+008
Cumulative Re-CPU Cost: 1,08508e+013
Cumulative Re-I/O Cost: 8,67065e+007
Cumulative First Row Cost: 1,565e+008
Estimated Bufferpool Buffers: 8,66775e+007

Arguments:
---------
BITFLTR : (Hash Join Bit Filter used)
FALSE
EARLYOUT: (Early Out flag)
NONE
HASHCODE: (Hash Code Size)
24 BIT
HASHTBSZ: (Number of hash table entries)
6470552
TEMPSIZE: (Temporary Table Page Size)
4096
TUPBLKSZ: (Tuple Block Size (bytes))
16000

Predicates:
----------
2) Predicate used in Join,
Comparison Operator: Equal (=)
Subquery Input Required: No
Filter Factor: 4,98394e-009

Predicate Text:
--------------
(Q2.C1_ID = Q1.C1_ID)



Input Streams:
-------------
2) From Operator #4

Estimated number of rows: 5,24234e+009
Number of columns: 3
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q2.PAY_STATUS+Q2.C2_HISTORY_DATE+Q2.C1_ID

4) From Operator #5

Estimated number of rows: 6,47055e+006
Number of columns: 1
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q1.C1_ID


Output Streams:
--------------
5) To Operator #2

Estimated number of rows: 1,69059e+008
Number of columns: 3
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q3.PAY_STATUS+Q3.C2_HISTORY_DATE+Q3.C1_ID


4) TBSCAN: (Table Scan)
Cumulative Total Cost: 1,56039e+008
Cumulative CPU Cost: 9,56255e+012
Cumulative I/O Cost: 8,66775e+007
Cumulative Re-Total Cost: 1,56039e+008
Cumulative Re-CPU Cost: 9,56255e+012
Cumulative Re-I/O Cost: 8,66775e+007
Cumulative First Row Cost: 12,8677
Estimated Bufferpool Buffers: 8,66775e+007

Arguments:
---------
JN INPUT: (Join input leg)
OUTER
MAXPAGES: (Maximum pages for prefetch)
ALL
PREFETCH: (Type of Prefetch)
SEQUENTIAL
ROWLOCK : (Row Lock intent)
NONE
SCANDIR : (Scan Direction)
FORWARD
SCANGRAN: (Intra-Partition Parallelism Scan Granularity)
2
SCANTYPE: (Intra-Partition Parallelism Scan Type)
LOCAL PARALLEL
SCANUNIT: (Intra-Partition Parallelism Scan Unit)
PAGE
SPEED : (Assumed speed of scan, in sharing structures)
FAST
TABLOCK : (Table Lock intent)
INTENT NONE
TBISOLVL: (Table access Isolation Level)
UNCOMMITTED READ
THROTTLE: (Scan may be throttled, for scan sharing)
TRUE
VISIBLE : (May be included in scan sharing structures)
TRUE
WRAPPING: (Scan may start anywhere and wrap)
TRUE

Input Streams:
-------------
1) From Object SH1.BIG_TAB

Estimated number of rows: 5,24234e+009
Number of columns: 4
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q2.$RID$+Q2.PAY_STATUS+Q2.C2_HISTORY_DATE+Q2.C1_ID


Output Streams:
--------------
2) To Operator #3

Estimated number of rows: 5,24234e+009
Number of columns: 3
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q2.PAY_STATUS+Q2.C2_HISTORY_DATE+Q2.C1_ID


5) TBSCAN: (Table Scan)
Cumulative Total Cost: 38146,2
Cumulative CPU Cost: 1,13216e+010
Cumulative I/O Cost: 29031
Cumulative Re-Total Cost: 3684,1
Cumulative Re-CPU Cost: 1,11423e+010
Cumulative Re-I/O Cost: 0
Cumulative First Row Cost: 9,0773
Estimated Bufferpool Buffers: 29031

Arguments:
---------
JN INPUT: (Join input leg)
INNER
MAXPAGES: (Maximum pages for prefetch)
ALL
PREFETCH: (Type of Prefetch)
SEQUENTIAL
ROWLOCK : (Row Lock intent)
NONE
SCANDIR : (Scan Direction)
FORWARD
SCANGRAN: (Intra-Partition Parallelism Scan Granularity)
2
SCANTYPE: (Intra-Partition Parallelism Scan Type)
LOCAL PARALLEL
SCANUNIT: (Intra-Partition Parallelism Scan Unit)
PAGE
SPEED : (Assumed speed of scan, in sharing structures)
FAST
TABLOCK : (Table Lock intent)
INTENT NONE
TBISOLVL: (Table access Isolation Level)
UNCOMMITTED READ
THROTTLE: (Scan may be throttled, for scan sharing)
TRUE
VISIBLE : (May be included in scan sharing structures)
TRUE
WRAPPING: (Scan may start anywhere and wrap)
TRUE

Input Streams:
-------------
3) From Object SH2.SMALL_TAB

Estimated number of rows: 6,47055e+006
Number of columns: 2
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q1.$RID$+Q1.C1_ID


Output Streams:
--------------
4) To Operator #3

Estimated number of rows: 6,47055e+006
Number of columns: 1
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q1.C1_ID


Objects Used in Access Plan:
---------------------------

Schema: SH1
Name: BIG_TAB
Type: Table

Schema: SH2
Name: SMALL_TAB
Type: Table

Extended Statistics Information:
--------------------------------

Tablespace Context:
-------------------
Name: T_H_TS_IDX
Overhead: 12.670000
Transfer Rate: 0.180000
Prefetch Size: 1920
Extent Size: 32
Type: Database managed
Partition Group Name: NULLP
Buffer Pool Identifier: 0

Name: T_H_TS_TBLS
Overhead: 12.670000
Transfer Rate: 0.180000
Prefetch Size: 1920
Extent Size: 32
Type: Database managed
Partition Group Name: NULLP
Buffer Pool Identifier: 0

Name: GVAPTABS
Overhead: 9.000000
Transfer Rate: 0.060000
Prefetch Size: 192
Extent Size: 32
Type: Database managed
Partition Group Name: NULLP
Buffer Pool Identifier: 0

Base Table Statistics:
----------------------
Name : BIG_TAB
Schema: SH1
Number of Columns: 9
Number of Pages with Rows: 86677492
Number of Pages: 86677492
Number of Rows: 5242341755
Table Overflow Record Count: 0
Width of Rows: 44
Time of Creation: 2015-05-02-21.32.08.419004
Last Statistics Update: 2016-10-12-11.06.17.653000
Primary Tablespace: T_H_TS_TBLS
Tablespace for Indexes: T_H_TS_IDX
Tablespace for Long Data: NULLP
Number of Referenced Columns: 3
Number of Indexes: 1
Volatile Table: No
Number of Active Blocks: -1
Number of Column Groups: 0
Number of Data Partitions: 1
Average Row Compression Ratio: -1.000000
Percent Rows Compressed: -1.000000
Average Compressed Row Size: -1
Statistics Type: U

Column Information:
--------------------
Number: 4
Name: PAY_STATUS
Statistics Available: Yes

Column Statistics:
------------------
Schema name of the column type: SYSIBM
Name of column type: SMALLINT
Maximum column length: 2
Scale for decimal or timestamp column: 0
Number of distinct column values: 11
Average column length: 2
Number of most frequent values: 10
Number of quantiles: 14
Second highest data value: 2052
Second lowest data value: 2025
Column sequence in partition key: 0
Average number of sub-elements: -1
Average length of delimiters: -1

Column Distribution Statistics:
-------------------------------
Frequency Statistics:
Valcount Value
--------------------------------
-226909440 2022
335509920 2025
314540544 2043
199209008 2037
110089192 2028
73392800 2031
73392800 2034
31454056 2052
26211712 2040
10484685 2046

Quantile Statistics:
Valcount Value Distcount
----------------------------------------------
0 2022 0
-226909440 2022 0
-158759168 2025 0
48313344 2025 0
119085056 2028 0
187235840 2028 0
255385600 2031 0
326157824 2034 0
394308096 2037 0
533230080 2037 0
601380864 2043 0
879224832 2043 0
947374459 2052 0
947374459 2052 0

Column Information:
--------------------
Number: 2
Name: C2_HISTORY_DATE
Statistics Available: Yes

Column Statistics:
------------------
Schema name of the column type: SYSIBM
Name of column type: DATE
Maximum column length: 4
Scale for decimal or timestamp column: 0
Number of distinct column values: 3776
Average column length: 4
Number of most frequent values: 10
Number of quantiles: 20
Second highest data value: 2016-09-30
Second lowest data value: 1998-03-01
Column sequence in partition key: 0
Average number of sub-elements: -1
Average length of delimiters: -1

Column Distribution Statistics:
-------------------------------
Frequency Statistics:
Valcount Value
--------------------------------
20969370 2013-12-01
18348200 2015-03-24
15727028 2012-01-01
15727028 2012-07-01
15727028 2014-06-01
15727028 2014-11-30
15727028 2015-01-14
15727028 2015-05-14
15727028 2016-02-13
15727028 2016-07-01

Quantile Statistics:
Valcount Value Distcount
----------------------------------------------
2621171 2006-01-01 0
275222976 2009-08-08 0
553067136 2011-03-25 0
838774784 2012-01-01 0
1111376640 2012-07-01 0
1381357184 2012-12-19 0
1656580352 2013-06-01 0
1931803264 2013-10-01 0
-2087941120 2014-01-22 0
-1810096896 2014-05-27 0
-1532252928 2014-08-21 0
-1254408960 2014-12-15 0
-984427776 2015-03-11 0
-709204736 2015-05-31 0
-431360768 2015-08-29 0
-156137984 2015-11-27 0
121705984 2016-02-06 0
396929024 2016-04-09 0
672152064 2016-06-13 0
947374459 2016-09-01 0

Column Information:
--------------------
Number: 1
Name: C1_ID
Statistics Available: Yes

Column Statistics:
------------------
Schema name of the column type: SYSIBM
Name of column type: BIGINT
Maximum column length: 8
Scale for decimal or timestamp column: 0
Number of distinct column values: 200644459
Average column length: 8
Number of most frequent values: 10
Number of quantiles: 20
Second highest data value: 268783998
Second lowest data value: 1067929
Column sequence in partition key: 0
Average number of sub-elements: -1
Average length of delimiters: -1

Column Distribution Statistics:
-------------------------------
Frequency Statistics:
Valcount Value
--------------------------------
1299 36438362
1288 36447884
1131 33866795
1125 32505228
1112 33812528
1106 84402767
1084 78760604
1083 41686576
1077 33504966
1074 83684924

Quantile Statistics:
Valcount Value Distcount
----------------------------------------------
9 1067928 1
-1535840067 148562089 96135473
-1535839970 148562090 96135474
-1259927333 156774640 103673316
-1259927325 156774641 103673317
-984014650 166080005 112142940
-984014573 166080006 112142941
-708101903 176682081 121106182
-708101879 176682082 121106183
-432189190 185813489 129730788
-432189060 185813490 129730789
-156276450 196955705 139491342
-156276427 196955706 139491343
119636278 208728225 149829902
119636290 208728226 149829903
395549005 226710331 162637745
395549032 226710332 162637746
671461724 243685423 178698359
671461737 243685424 178698360
947374459 268783999 200644459

Indexes defined on the table:
-----------------------------
Name : BIG_TAB_PK
Schema: SH1
Unique Rule: Primary key index
Used in Operator: No
Page Fetch Pairs: Available
Number of Columns: 3
Index Leaf Pages: 57207556
Index Tree Levels: 5
Index First Key Cardinality: 200644459
Index Full Key Cardinality: 5242341755
Index Cluster Ratio: -1
Index Cluster Factor: 0.686509
Time of Creation: 2015-05-02-21.32.08.528002
Last Statistics Update: 2016-10-12-11.06.17.653000
Index Sequential Pages: 28302903
Index First 2 Keys Cardinality: 5241031435
Index First 3 Keys Cardinality: 5242341755
Index First 4 Keys Cardinality: -1
Index Avg Gap between Sequences: 222959.000000
Fetch Avg Gap between Sequences: -1.000000
Index Avg Sequential Pages: 786191.000000
Fetch Avg Sequential Pages: -1.000000
Index Avg Random Pages: 586145.000000
Fetch Avg Random Pages: -1.000000
Index RID Count: 5321149234
Index Deleted RID Count: 73837652
Index Empty Leaf Pages: 55765
Avg Partition Cluster Ratio: -1
Avg Partition Cluster Factor: -1.000000
Data Partition Cluster Factor: 1.000000
Data Partition Page Fetch Pairs: Not Available

Page Fetch Pairs information:
-----------------------------
Number of Page Fetch Pairs: 11

Buffer Size Page Fetches
--------------------------------------------------------
Pair 1: 100 1039302010
Pair 2: 350052 416376800
Pair 3: 9451404 206844276
Pair 4: 22053276 118214180
Pair 5: 31504680 98877758
Pair 6: 41656188 91777118
Pair 7: 53207904 89230548
Pair 8: 67910088 87250817
Pair 9: 86112792 86889824
Pair 10: 86462766 86462766
Pair 11: 86462766 86462766

Base Table Statistics:
----------------------
Name : SMALL_TAB
Schema: SH2
Number of Columns: 1
Number of Pages with Rows: 29031
Number of Pages: 29031
Number of Rows: 6470552
Table Overflow Record Count: 0
Width of Rows: 14
Time of Creation: 2016-09-09-01.00.34.218012
Last Statistics Update: 2016-09-09-01.21.43.373004
Primary Tablespace: GVAPTABS
Tablespace for Indexes: NULLP
Tablespace for Long Data: NULLP
Number of Referenced Columns: 1
Number of Indexes: 0
Volatile Table: No
Number of Active Blocks: -1
Number of Column Groups: 0
Number of Data Partitions: 1
Average Row Compression Ratio: -1.000000
Percent Rows Compressed: -1.000000
Average Compressed Row Size: -1
Statistics Type: U

Column Information:
--------------------
Number: 1
Name: C1_ID
Statistics Available: Yes

Column Statistics:
------------------
Schema name of the column type: SYSIBM
Name of column type: BIGINT
Maximum column length: 8
Scale for decimal or timestamp column: 0
Number of distinct column values: 6470552
Average column length: 8
Number of most frequent values: -1
Number of quantiles: 20
Second highest data value: 268615579
Second lowest data value: 1537590
Column sequence in partition key: 0
Average number of sub-elements: -1
Average length of delimiters: -1

Column Distribution Statistics:
-------------------------------
Quantile Statistics:
Valcount Value Distcount
----------------------------------------------
1 1142011 1
340555 87288721 340555
681111 106824791 681111
1021666 132208218 1021666
1362221 144856874 1362221
1702777 152931756 1702777
2043332 164940760 2043332
2383888 178662943 2383888
2724443 190381699 2724443
3064998 199993277 3064998
3405554 211764305 3405554
3746109 231107293 3746109
4086664 237462093 4086664
4427220 241699507 4427220
4767775 246905464 4767775
5108331 252268977 5108331
5448886 257246078 5448886
5789441 261978211 5789441
6129997 266292888 6129997
6470552 268615580 6470552



Снял снимок
+

Application Snapshot

Application handle = 187
Application status = UOW Waiting
Status change time = 26.10.2016 13:36:23.151125
Application code page = 1251
Application country/region code = 7
DUOW correlation token = *LOCAL.INST.161026094524
Application name = db2bp.exe
Application ID = *LOCAL.INST.161026094524
Sequence number = 00009
TP Monitor client user ID =
TP Monitor client workstation name =
TP Monitor client application name =
TP Monitor client accounting string =

Connection request start timestamp = 26.10.2016 12:45:24.119532
Connect request completion timestamp =
Application idle time = 37 minutes 17 seconds
CONNECT Authorization ID = SH1
Client login ID = DB2ADMIN
Configuration NNAME of client = DB
Client database manager product ID = SQL09078
Process ID of client application = 6232
Platform of client application = NT 64BIT
Communication protocol of client = Local Client

Inbound communication address = *LOCAL.INST

Database name = DB
Database path = D:\INST\NODE0000\SQL00001\
Client database alias = DB
Input database alias =
Last reset timestamp =
Snapshot timestamp = 26.10.2016 14:13:40.686533
Authorization level granted =
User authority:
DBADM authority
CREATETAB authority
BINDADD authority
CONNECT authority
CREATE_NOT_FENC authority
LOAD authority
IMPLICIT_SCHEMA authority
CREATE_EXT_RT authority
QUIESCE_CONN authority
DATAACCESS authority
ACCESSCTRL authority
Group authority:
SYSADM authority
DBADM authority
BINDADD authority
CONNECT authority
DATAACCESS authority
ACCESSCTRL authority
Coordinating database partition number = 0
Current database partition number = 0
Coordinator agent process or thread ID = 2940
Current Workload ID = 1
Agents stolen = 0
Agents waiting on locks = 0
Maximum associated agents = 3
Priority at which application agents work = 0
Priority type = Dynamic

Lock timeout (seconds) = -1
Locks held by application = 0
Lock waits since connect = 0
Time application waited on locks (ms) = 0
Deadlocks detected = 0
Lock escalations = 0
Exclusive lock escalations = 0
Number of Lock Timeouts since connected = 0
Total time UOW waited on locks (ms) = 0

Total sorts = 0
Total sort time (ms) = 0
Total sort overflows = 0

Buffer pool data logical reads = 386430992
Buffer pool data physical reads = 2806
Buffer pool temporary data logical reads = 0
Buffer pool temporary data physical reads = 0
Buffer pool data writes = 392209
Buffer pool index logical reads = 415
Buffer pool index physical reads = 21
Buffer pool temporary index logical reads = 0
Buffer pool temporary index physical reads = 0
Buffer pool index writes = 0
Buffer pool xda logical reads = 0
Buffer pool xda physical reads = 0
Buffer pool temporary xda logical reads = 0
Buffer pool temporary xda physical reads = 0
Buffer pool xda writes = 0
Total buffer pool read time (milliseconds) = 8165
Total buffer pool write time (milliseconds)= 107930
Time waited for prefetch (ms) = 9796
Unread prefetch pages = 0
Direct reads = 30
Direct writes = 10
Direct read requests = 3
Direct write requests = 1
Direct reads elapsed time (ms) = 15
Direct write elapsed time (ms) = 9

Number of SQL requests since last commit = 0
Commit statements = 8
Rollback statements = 0
Dynamic SQL statements attempted = 12
Static SQL statements attempted = 8
Failed statement operations = 0
Select SQL statements executed = 1
Xquery statements executed = 0
Update/Insert/Delete statements executed = 1
DDL statements executed = 1
Inactive stmt history memory usage (bytes) = 0
Internal automatic rebinds = 0
Internal rows deleted = 0
Internal rows inserted = 0
Internal rows updated = 0
Internal commits = 1
Internal rollbacks = 0
Internal rollbacks due to deadlock = 0
Binds/precompiles attempted = 0
Rows deleted = 0
Rows inserted = 280486641
Rows updated = 0
Rows selected = 1
Rows read = 5530885076
Rows written = 280486885

UOW log space used (Bytes) = 0
Previous UOW completion timestamp = 26.10.2016 13:34:47.490617
Elapsed time of last completed uow (sec.ms)= 95.425489
UOW start timestamp = 26.10.2016 13:34:47.725623
UOW stop timestamp = 26.10.2016 13:36:23.151112
UOW completion status = Committed - Commit Statement

Open remote cursors = 0
Open remote cursors with blocking = 0
Rejected Block Remote Cursor requests = 0
Accepted Block Remote Cursor requests = 1
Open local cursors = 0
Open local cursors with blocking = 0
Total User CPU Time used by agent (s) = 3597.211459
Total System CPU Time used by agent (s) = 135.471268
Host execution elapsed time = 2106.509529

Package cache lookups = 9
Package cache inserts = 9
Application section lookups = 14
Application section inserts = 10
Catalog cache lookups = 50
Catalog cache inserts = 8
Catalog cache overflows = 0
Catalog cache high water mark = 0

Workspace Information


Most recent operation = Static Commit
Most recent operation start timestamp = 26.10.2016 13:36:23.150157
Most recent operation stop timestamp = 26.10.2016 13:36:23.151110
Agents associated with the application = 3
Number of hash joins = 1
Number of hash loops = 0
Number of hash join overflows = 0
Number of small hash join overflows = 0
Number of OLAP functions = 0
Number of OLAP function overflows = 0

Statement type = Static SQL Statement
Statement = Static Commit
Section number = 0
Application creator =
Package name =
Consistency Token =
Cursor name =
Statement database partition number = 0
Statement start timestamp = 26.10.2016 13:36:23.150157
Statement stop timestamp = 26.10.2016 13:36:23.151110
Elapsed time of last completed stmt(sec.ms)= 0.000953
Total Statement user CPU time = 0.000000
Total Statement system CPU time = 0.000000
SQL compiler cost estimate in timerons = 0
SQL compiler cardinality estimate = 0
Degree of parallelism requested = 1
Number of agents working on statement = 1
Number of subagents created for statement = 1
Statement sorts = 0
Total sort time = 0
Sort overflows = 0
Rows read = 0
Rows written = 0
Rows deleted = 0
Rows updated = 0
Rows inserted = 0
Rows fetched = 0
Buffer pool data logical reads = 0
Buffer pool data physical reads = 0
Buffer pool temporary data logical reads = 0
Buffer pool temporary data physical reads = 0
Buffer pool index logical reads = 0
Buffer pool index physical reads = 0
Buffer pool temporary index logical reads = 0
Buffer pool temporary index physical reads = 0
Buffer pool xda logical reads = 0
Buffer pool xda physical reads = 0
Buffer pool temporary xda logical reads = 0
Buffer pool temporary xda physical reads = 0
Blocking cursor = NO

Memory usage for application:

Memory Pool Type = Application Heap
Current size (bytes) = 131072
High water mark (bytes) = 196608
Configured size (bytes) = 10289152

Agent process/thread ID = 2940
Agent Lock timeout (seconds) = -1
Memory usage for agent:

Memory Pool Type = Other Memory
Current size (bytes) = 196608
High water mark (bytes) = 393216
Configured size (bytes) = 412292743168

Agent process/thread ID = 6760
Agent Lock timeout (seconds) = -1
Memory usage for agent:

Memory Pool Type = Other Memory
Current size (bytes) = 196608
High water mark (bytes) = 196608
Configured size (bytes) = 412292743168

Agent process/thread ID = 8656
Agent Lock timeout (seconds) = -1
Memory usage for agent:

Memory Pool Type = Other Memory
Current size (bytes) = 196608
High water mark (bytes) = 196608
Configured size (bytes) = 412292743168

если честно, то я не понял есть ли какие либо ограничения в выборке и в чем они выражаются.
Возможно следует смотреть не через snapshot а посредством иных инструментов, подскажите если что...
26 окт 16, 15:09    [19824091]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4869
use-se,

Сколько времени выполняется теперь запрос ниже, каков его план?

SELECT count(h.PAY_STATUS)
FROM SH1.BIG_TAB h, SH2.SMALL_TAB l
WHERE h.C1_ID = l.C1_ID
WITH UR

Он должен гораздо быстрее выполняться...
26 окт 16, 21:48    [19825827]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
use-se
Member

Откуда: Москва
Сообщений: 448
Mark Barinstein
use-se,

Сколько времени выполняется теперь запрос ниже, каков его план?

SELECT count(h.PAY_STATUS)
FROM SH1.BIG_TAB h, SH2.SMALL_TAB l
WHERE h.C1_ID = l.C1_ID
WITH UR

Он должен гораздо быстрее выполняться...

Запрос выполняется 19 минут.
Его план тут:
+
DB2 Universal Database Version 9.7, 5622-044 (c) Copyright IBM Corp. 1991, 2009
Licensed Material - Program Property of IBM
IBM DATABASE 2 Explain Table Format Tool



******************** EXPLAIN INSTANCE ********************

DB2_VERSION: 09.07.8
SOURCE_NAME: SQLC2H23
SOURCE_SCHEMA: NULLID
SOURCE_VERSION:
EXPLAIN_TIME: 2016-10-27-10.56.52.499001
EXPLAIN_REQUESTER: SH1

Database Context:
----------------
Parallelism: Intra-Partition Parallelism
CPU Speed: 3,306410e-007
Comm Speed: 0
Buffer Pool size: 74411200
Sort Heap size: 100000
Database Heap size: 300000
Lock List size: 8892802
Maximum Lock List: 98
Average Applications: 50
Locks Available: 278878272

Package Context:
---------------
SQL Type: Dynamic
Optimization Level: 5
Blocking: Block All Cursors
Isolation Level: Uncommitted Read



---------------- STATEMENT 1 SECTION 201 ----------------
QUERYNO: 14
QUERYTAG: CLP
Statement Type: Select
Updatable: No
Deletable: No
Query Degree: -1

Original Statement:
------------------
SELECT count(h.PAY_STATUS)
FROM SH1.BIG_TAB h, SH2.SMALL_TAB l
WHERE h.C1_ID = l.C1_ID
WITH UR


Optimized Statement:
-------------------
SELECT Q4.$C0
FROM
(SELECT COUNT(*)
FROM
(SELECT $RID$
FROM SH2.SMALL_TAB AS Q1, SH1.BIG_TAB AS Q2
WHERE (Q2.C1_ID = Q1.C1_ID)) AS Q3) AS Q4

Access Plan:
-----------
Total Cost: 1,56513e+008
Query Degree: 40

Rows
RETURN
( 1)
Cost
I/O
|
1
GRPBY
( 2)
1,56513e+008
8,67065e+007
|
1
LTQ
( 3)
1,56513e+008
8,67065e+007
|
1
GRPBY
( 4)
1,56513e+008
8,67065e+007
|
1,69059e+008
HSJOIN
( 5)
1,56499e+008
8,67065e+007
/-----+------\
5,24234e+009 6,47055e+006
TBSCAN TBSCAN
( 6) ( 7)
1,56039e+008 38146,2
8,66775e+007 29031
| |
5,24234e+009 6,47055e+006
TABLE: SH1 TABLE: SH2
BIG_TAB SMALL_TAB
Q2 Q1



Extended Diagnostic Information:
--------------------------------

No extended Diagnostic Information for this statement.


Plan Details:
-------------


1) RETURN: (Return Result)
Cumulative Total Cost: 1,56513e+008
Cumulative CPU Cost: 1,08923e+013
Cumulative I/O Cost: 8,67065e+007
Cumulative Re-Total Cost: 1,56513e+008
Cumulative Re-CPU Cost: 1,08923e+013
Cumulative Re-I/O Cost: 8,67065e+007
Cumulative First Row Cost: 1,56513e+008
Estimated Bufferpool Buffers: 8,66775e+007

Arguments:
---------
BLDLEVEL: (Build level)
DB2 v9.7.800.717 : s130316
HEAPUSE : (Maximum Statement Heap Usage)
96 Pages
PREPTIME: (Statement prepare time)
201 milliseconds
STMTHEAP: (Statement heap size)
4096

Input Streams:
-------------
8) From Operator #2

Estimated number of rows: 1
Number of columns: 1
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q5.$C0


2) GRPBY : (Group By)
Cumulative Total Cost: 1,56513e+008
Cumulative CPU Cost: 1,08923e+013
Cumulative I/O Cost: 8,67065e+007
Cumulative Re-Total Cost: 1,56513e+008
Cumulative Re-CPU Cost: 1,08923e+013
Cumulative Re-I/O Cost: 8,67065e+007
Cumulative First Row Cost: 1,56513e+008
Estimated Bufferpool Buffers: 8,66775e+007

Arguments:
---------
AGGMODE : (Aggregation Mode)
FINAL
GROUPBYC: (Group By columns)
FALSE
GROUPBYN: (Number of Group By columns)
0
ONEFETCH: (One Fetch flag)
FALSE

Input Streams:
-------------
7) From Operator #3

Estimated number of rows: 1
Number of columns: 0
Subquery predicate ID: Not Applicable


Output Streams:
--------------
8) To Operator #1

Estimated number of rows: 1
Number of columns: 1
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q5.$C0


3) TQ : (Table Queue)
Cumulative Total Cost: 1,56513e+008
Cumulative CPU Cost: 1,08923e+013
Cumulative I/O Cost: 8,67065e+007
Cumulative Re-Total Cost: 1,56513e+008
Cumulative Re-CPU Cost: 1,08923e+013
Cumulative Re-I/O Cost: 8,67065e+007
Cumulative First Row Cost: 1,56513e+008
Estimated Bufferpool Buffers: 8,66775e+007

Arguments:
---------
LISTENER: (Listener Table Queue type)
FALSE
TQ TYPE : (Table queue type)
LOCAL
TQDEGREE: (Degree of Intra-Partition parallelism)
40
TQMERGE : (Merging Table Queue flag)
FALSE
TQREAD : (Table Queue Read type)
READ AHEAD
UNIQUE : (Uniqueness required flag)
FALSE

Input Streams:
-------------
6) From Operator #4

Estimated number of rows: 1
Number of columns: 0
Subquery predicate ID: Not Applicable


Output Streams:
--------------
7) To Operator #2

Estimated number of rows: 1
Number of columns: 0
Subquery predicate ID: Not Applicable


4) GRPBY : (Group By)
Cumulative Total Cost: 1,56513e+008
Cumulative CPU Cost: 1,08923e+013
Cumulative I/O Cost: 8,67065e+007
Cumulative Re-Total Cost: 1,56513e+008
Cumulative Re-CPU Cost: 1,08923e+013
Cumulative Re-I/O Cost: 8,67065e+007
Cumulative First Row Cost: 1,56513e+008
Estimated Bufferpool Buffers: 8,66775e+007

Arguments:
---------
AGGMODE : (Aggregation Mode)
PARTIAL
GROUPBYC: (Group By columns)
FALSE
GROUPBYN: (Number of Group By columns)
0
ONEFETCH: (One Fetch flag)
FALSE

Input Streams:
-------------
5) From Operator #5

Estimated number of rows: 1,69059e+008
Number of columns: 0
Subquery predicate ID: Not Applicable


Output Streams:
--------------
6) To Operator #3

Estimated number of rows: 1
Number of columns: 0
Subquery predicate ID: Not Applicable


5) HSJOIN: (Hash Join)
Cumulative Total Cost: 1,56499e+008
Cumulative CPU Cost: 1,085e+013
Cumulative I/O Cost: 8,67065e+007
Cumulative Re-Total Cost: 1,56499e+008
Cumulative Re-CPU Cost: 1,085e+013
Cumulative Re-I/O Cost: 8,67065e+007
Cumulative First Row Cost: 1,56499e+008
Estimated Bufferpool Buffers: 8,66775e+007

Arguments:
---------
BITFLTR : (Hash Join Bit Filter used)
FALSE
EARLYOUT: (Early Out flag)
NONE
HASHCODE: (Hash Code Size)
24 BIT
HASHTBSZ: (Number of hash table entries)
6470552
TEMPSIZE: (Temporary Table Page Size)
4096
TUPBLKSZ: (Tuple Block Size (bytes))
16000

Predicates:
----------
2) Predicate used in Join,
Comparison Operator: Equal (=)
Subquery Input Required: No
Filter Factor: 4,98394e-009

Predicate Text:
--------------
(Q2.C1_ID = Q1.C1_ID)



Input Streams:
-------------
2) From Operator #6

Estimated number of rows: 5,24234e+009
Number of columns: 1
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q2.C1_ID

4) From Operator #7

Estimated number of rows: 6,47055e+006
Number of columns: 1
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q1.C1_ID


Output Streams:
--------------
5) To Operator #4

Estimated number of rows: 1,69059e+008
Number of columns: 0
Subquery predicate ID: Not Applicable


6) TBSCAN: (Table Scan)
Cumulative Total Cost: 1,56039e+008
Cumulative CPU Cost: 9,56255e+012
Cumulative I/O Cost: 8,66775e+007
Cumulative Re-Total Cost: 1,56039e+008
Cumulative Re-CPU Cost: 9,56255e+012
Cumulative Re-I/O Cost: 8,66775e+007
Cumulative First Row Cost: 12,8677
Estimated Bufferpool Buffers: 8,66775e+007

Arguments:
---------
JN INPUT: (Join input leg)
OUTER
MAXPAGES: (Maximum pages for prefetch)
ALL
PREFETCH: (Type of Prefetch)
SEQUENTIAL
ROWLOCK : (Row Lock intent)
NONE
SCANDIR : (Scan Direction)
FORWARD
SCANGRAN: (Intra-Partition Parallelism Scan Granularity)
2
SCANTYPE: (Intra-Partition Parallelism Scan Type)
LOCAL PARALLEL
SCANUNIT: (Intra-Partition Parallelism Scan Unit)
PAGE
SPEED : (Assumed speed of scan, in sharing structures)
FAST
TABLOCK : (Table Lock intent)
INTENT NONE
TBISOLVL: (Table access Isolation Level)
UNCOMMITTED READ
THROTTLE: (Scan may be throttled, for scan sharing)
TRUE
VISIBLE : (May be included in scan sharing structures)
TRUE
WRAPPING: (Scan may start anywhere and wrap)
TRUE

Input Streams:
-------------
1) From Object SH1.BIG_TAB

Estimated number of rows: 5,24234e+009
Number of columns: 2
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q2.$RID$+Q2.C1_ID


Output Streams:
--------------
2) To Operator #5

Estimated number of rows: 5,24234e+009
Number of columns: 1
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q2.C1_ID


7) TBSCAN: (Table Scan)
Cumulative Total Cost: 38146,2
Cumulative CPU Cost: 1,13216e+010
Cumulative I/O Cost: 29031
Cumulative Re-Total Cost: 3684,1
Cumulative Re-CPU Cost: 1,11423e+010
Cumulative Re-I/O Cost: 0
Cumulative First Row Cost: 9,0773
Estimated Bufferpool Buffers: 29031

Arguments:
---------
JN INPUT: (Join input leg)
INNER
MAXPAGES: (Maximum pages for prefetch)
ALL
PREFETCH: (Type of Prefetch)
SEQUENTIAL
ROWLOCK : (Row Lock intent)
NONE
SCANDIR : (Scan Direction)
FORWARD
SCANGRAN: (Intra-Partition Parallelism Scan Granularity)
2
SCANTYPE: (Intra-Partition Parallelism Scan Type)
LOCAL PARALLEL
SCANUNIT: (Intra-Partition Parallelism Scan Unit)
PAGE
SPEED : (Assumed speed of scan, in sharing structures)
FAST
TABLOCK : (Table Lock intent)
INTENT NONE
TBISOLVL: (Table access Isolation Level)
UNCOMMITTED READ
THROTTLE: (Scan may be throttled, for scan sharing)
TRUE
VISIBLE : (May be included in scan sharing structures)
TRUE
WRAPPING: (Scan may start anywhere and wrap)
TRUE

Input Streams:
-------------
3) From Object SH2.SMALL_TAB

Estimated number of rows: 6,47055e+006
Number of columns: 2
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q1.$RID$+Q1.C1_ID


Output Streams:
--------------
4) To Operator #5

Estimated number of rows: 6,47055e+006
Number of columns: 1
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q1.C1_ID


Objects Used in Access Plan:
---------------------------

Schema: SH1
Name: BIG_TAB
Type: Table

Schema: SH2
Name: SMALL_TAB
Type: Table

Extended Statistics Information:
--------------------------------

Tablespace Context:
-------------------
Name: T_H_TS_IDX
Overhead: 12.670000
Transfer Rate: 0.180000
Prefetch Size: 1920
Extent Size: 32
Type: Database managed
Partition Group Name: NULLP
Buffer Pool Identifier: 0

Name: T_H_TS_TBLS
Overhead: 12.670000
Transfer Rate: 0.180000
Prefetch Size: 1920
Extent Size: 32
Type: Database managed
Partition Group Name: NULLP
Buffer Pool Identifier: 0

Name: GVAPTABS
Overhead: 9.000000
Transfer Rate: 0.060000
Prefetch Size: 192
Extent Size: 32
Type: Database managed
Partition Group Name: NULLP
Buffer Pool Identifier: 0

Base Table Statistics:
----------------------
Name : BIG_TAB
Schema: SH1
Number of Columns: 9
Number of Pages with Rows: 86677492
Number of Pages: 86677492
Number of Rows: 5242341755
Table Overflow Record Count: 0
Width of Rows: 40
Time of Creation: 2015-05-02-21.32.08.419004
Last Statistics Update: 2016-10-12-11.06.17.653000
Primary Tablespace: T_H_TS_TBLS
Tablespace for Indexes: T_H_TS_IDX
Tablespace for Long Data: NULLP
Number of Referenced Columns: 2
Number of Indexes: 1
Volatile Table: No
Number of Active Blocks: -1
Number of Column Groups: 0
Number of Data Partitions: 1
Average Row Compression Ratio: -1.000000
Percent Rows Compressed: -1.000000
Average Compressed Row Size: -1
Statistics Type: U

Column Information:
--------------------
Number: 4
Name: PAY_STATUS
Statistics Available: No

Column Information:
--------------------
Number: 1
Name: C1_ID
Statistics Available: Yes

Column Statistics:
------------------
Schema name of the column type: SYSIBM
Name of column type: BIGINT
Maximum column length: 8
Scale for decimal or timestamp column: 0
Number of distinct column values: 200644459
Average column length: 8
Number of most frequent values: 10
Number of quantiles: 20
Second highest data value: 268783998
Second lowest data value: 1067929
Column sequence in partition key: 0
Average number of sub-elements: -1
Average length of delimiters: -1

Column Distribution Statistics:
-------------------------------
Frequency Statistics:
Valcount Value
--------------------------------
1299 36438362
1288 36447884
1131 33866795
1125 32505228
1112 33812528
1106 84402767
1084 78760604
1083 41686576
1077 33504966
1074 83684924

Quantile Statistics:
Valcount Value Distcount
----------------------------------------------
9 1067928 1
-1535840067 148562089 96135473
-1535839970 148562090 96135474
-1259927333 156774640 103673316
-1259927325 156774641 103673317
-984014650 166080005 112142940
-984014573 166080006 112142941
-708101903 176682081 121106182
-708101879 176682082 121106183
-432189190 185813489 129730788
-432189060 185813490 129730789
-156276450 196955705 139491342
-156276427 196955706 139491343
119636278 208728225 149829902
119636290 208728226 149829903
395549005 226710331 162637745
395549032 226710332 162637746
671461724 243685423 178698359
671461737 243685424 178698360
947374459 268783999 200644459

Indexes defined on the table:
-----------------------------
Name : BIG_TAB_PK
Schema: SH1
Unique Rule: Primary key index
Used in Operator: No
Page Fetch Pairs: Available
Number of Columns: 3
Index Leaf Pages: 57207556
Index Tree Levels: 5
Index First Key Cardinality: 200644459
Index Full Key Cardinality: 5242341755
Index Cluster Ratio: -1
Index Cluster Factor: 0.686509
Time of Creation: 2015-05-02-21.32.08.528002
Last Statistics Update: 2016-10-12-11.06.17.653000
Index Sequential Pages: 28302903
Index First 2 Keys Cardinality: 5241031435
Index First 3 Keys Cardinality: 5242341755
Index First 4 Keys Cardinality: -1
Index Avg Gap between Sequences: 222959.000000
Fetch Avg Gap between Sequences: -1.000000
Index Avg Sequential Pages: 786191.000000
Fetch Avg Sequential Pages: -1.000000
Index Avg Random Pages: 586145.000000
Fetch Avg Random Pages: -1.000000
Index RID Count: 5321149234
Index Deleted RID Count: 73837652
Index Empty Leaf Pages: 55765
Avg Partition Cluster Ratio: -1
Avg Partition Cluster Factor: -1.000000
Data Partition Cluster Factor: 1.000000
Data Partition Page Fetch Pairs: Not Available

Page Fetch Pairs information:
-----------------------------
Number of Page Fetch Pairs: 11

Buffer Size Page Fetches
--------------------------------------------------------
Pair 1: 100 1039302010
Pair 2: 350052 416376800
Pair 3: 9451404 206844276
Pair 4: 22053276 118214180
Pair 5: 31504680 98877758
Pair 6: 41656188 91777118
Pair 7: 53207904 89230548
Pair 8: 67910088 87250817
Pair 9: 86112792 86889824
Pair 10: 86462766 86462766
Pair 11: 86462766 86462766

Base Table Statistics:
----------------------
Name : SMALL_TAB
Schema: SH2
Number of Columns: 1
Number of Pages with Rows: 29031
Number of Pages: 29031
Number of Rows: 6470552
Table Overflow Record Count: 0
Width of Rows: 14
Time of Creation: 2016-09-09-01.00.34.218012
Last Statistics Update: 2016-09-09-01.21.43.373004
Primary Tablespace: GVAPTABS
Tablespace for Indexes: NULLP
Tablespace for Long Data: NULLP
Number of Referenced Columns: 1
Number of Indexes: 0
Volatile Table: No
Number of Active Blocks: -1
Number of Column Groups: 0
Number of Data Partitions: 1
Average Row Compression Ratio: -1.000000
Percent Rows Compressed: -1.000000
Average Compressed Row Size: -1
Statistics Type: U

Column Information:
--------------------
Number: 1
Name: C1_ID
Statistics Available: Yes

Column Statistics:
------------------
Schema name of the column type: SYSIBM
Name of column type: BIGINT
Maximum column length: 8
Scale for decimal or timestamp column: 0
Number of distinct column values: 6470552
Average column length: 8
Number of most frequent values: -1
Number of quantiles: 20
Second highest data value: 268615579
Second lowest data value: 1537590
Column sequence in partition key: 0
Average number of sub-elements: -1
Average length of delimiters: -1

Column Distribution Statistics:
-------------------------------
Quantile Statistics:
Valcount Value Distcount
----------------------------------------------
1 1142011 1
340555 87288721 340555
681111 106824791 681111
1021666 132208218 1021666
1362221 144856874 1362221
1702777 152931756 1702777
2043332 164940760 2043332
2383888 178662943 2383888
2724443 190381699 2724443
3064998 199993277 3064998
3405554 211764305 3405554
3746109 231107293 3746109
4086664 237462093 4086664
4427220 241699507 4427220
4767775 246905464 4767775
5108331 252268977 5108331
5448886 257246078 5448886
5789441 261978211 5789441
6129997 266292888 6129997
6470552 268615580 6470552



я немного не понял "быстрее" относительно какого запроса,
с агрегированием данных, но выполненным ранее?
Дело в том, что в базовом запросе данные клиенту тоже не возвращаются,
а вставляются в таблицу, выглядит это примерно так:
db2 +c alter table res activate not logged initially with empty table
db2 insert into res select c1_id, c2_history_date, pay_status from big_tab h, small_tab l where h.c1_id-lc1_id with ur
и тесты я соответственно делаю такие же. Опять же я немного не понимаю суть intra_parallel и как DB2 выбирает эту параллельность.
К примеру сейчас, для теста, я разбил TS на 10 контейнеров, раскидал их по разным логическим дискам (правда в пределах одного массива на СХД), 40 CPU (условно), все свободно, но насколько я понял из плана, параллельность = 2. ???
Практически цель вопроса, ускорить выгрузку, достигнута, 35 минут это хороший даже отличный результат, за что Вам и всем кто принимал участие большое спасибо, но есть одна небольшая проблема, теперь поселился червячок сомнения, а вдруг, что то еще не так и возможно производильность может быть и выше )))
Вот кстати, еще 1 вопрос сомнений. Сейчас (на БД, СХД DS5100) стоит: OVERHEAD=12.67, TRANSFERRATE=0.18 для TS, и фактически эти параметры переносятся вместе c backup на копии для тестов, Storwize v7000 и FlashSystem.
Я думаю, что эти параметры влияют только на выбор планов, но вдруг и на что то еще?
1) Нужно ли менять эти 2 параметра при переносе БД?
2)Какова методика расчета этих параметров для БД или нужно искать в документации на железо, может просто есть где то рекомендации IBM где в табличке приведены DB2 & СХД?
Вот такие сомнения.
27 окт 16, 12:15    [19827621]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4869
use-se,

Можете попробовать:
db2 declare c1 cursor for select c1_id, c2_history_date, pay_status from big_tab h, small_tab l where h.c1_id-lc1_id with ur
db2 load from c1 of cursor messages res.load.msg replace reset dictionary into res nonrecoverable

OVERHEAD, TRANSFERRATE:
Table space impact on query optimization

В плане у вас:
Query Degree:		40
Параллелизм выбирается согласно значению переменной сессии CURRENT DEGREE.
db2 выделяет для работы N агентов, которые патаются выполнять работу параллельно, передавая результаты своей работы координирующему агенту.
27 окт 16, 15:38    [19829089]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Yo.!
Guest
use-se,


38 минут однозначно долго. как я понял хеш таблица на диск пишется, т.е. HJ вместо read-ahead по большой таблице читает то временную хеш-таблицу, то большую таблицу. надо добиться, что бы хеш таблица от чтения маленькой таблицы умещалась в память, тогда еще в несколько раз быстрее будет.
27 окт 16, 16:30    [19829480]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
use-se
Member

Откуда: Москва
Сообщений: 448
Yo.!
use-se,


38 минут однозначно долго. как я понял хеш таблица на диск пишется, т.е. HJ вместо read-ahead по большой таблице читает то временную хеш-таблицу, то большую таблицу. надо добиться, что бы хеш таблица от чтения маленькой таблицы умещалась в память, тогда еще в несколько раз быстрее будет.

Не пишется хеш ни маленькой не большой таблицы, иначе была бы заметна запись на диск в темповый TS.
Да и из плана видно, что inner(правая) это маленькая таблица.
И на снимке я не увидел чтобы как то использовалась временная область.
Однако, я подумал, что 38 минут это хорошо, Вы сказали - плохо. )))
Опять есть о чем думать. ))
27 окт 16, 16:44    [19829608]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
use-se
Member

Откуда: Москва
Сообщений: 448
Mark Barinstein
use-se,

Можете попробовать:
db2 declare c1 cursor for select c1_id, c2_history_date, pay_status from big_tab h, small_tab l where h.c1_id-lc1_id with ur
db2 load from c1 of cursor messages res.load.msg replace reset dictionary into res nonrecoverable

OVERHEAD, TRANSFERRATE:
Table space impact on query optimization

В плане у вас:
Query Degree:		40
Параллелизм выбирается согласно значению переменной сессии CURRENT DEGREE.
db2 выделяет для работы N агентов, которые патаются выполнять работу параллельно, передавая результаты своей работы координирующему агенту.

Пробовал я ранее делать Load, параметры были немного другими.
Там другая проблема, я уже писал об, виснет наглухо процесс db2syscs, вот так
+
D:\tmp>db2pd -util show detail

Database Partition 0 -- Active -- Up 1 days 05:16:14 -- Date 2016-10-27-16.18.06.017000

Utilities:
Address ID Type State Invoker Priority StartTime DBName NumPhases CurPhase Description
0x0000000012EBEA80 3 LOAD 0 0 0 Thu Oct 27 16:11:56 DB 2 2 [LOADID: 2940.2016-10-27-16.11.56.544006.0 (40;20)] [*LOCAL.INST.161026094524] OFFLINE LOAD CURSOR AUTOMATIC INDEXING REPLACE NON-RECOVERABLE SH2.res

Progress:
Address ID PhaseNum CompletedWork TotalWork StartTime Description
0x0000000012EBEE28 3 1 0 bytes 0 bytes Thu Oct 27 16:11:56 SETUPl
0x0000000012EBEFE0 3 2 0 rows 0 rows Thu Oct 27 16:11:57 LOAD

D:\tmp>db2 list utilities show detail
<...висит...>
час примерно будет так висеть, потом отвиснет и загрузки пойдут нормально. Помогает если ставить опцию COPY YES, но тоже не всегда. Поэтому на продуктиве делаю load только когда есть сервисный интервал.

Про параметры TS видел, но думал может есть рекомендации конкретно по каждому СХД.
27 окт 16, 16:55    [19829703]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
use-se
Member

Откуда: Москва
Сообщений: 448
use-se,

Оттаял процесс, суммарно load длился 1 час 16 м
27 окт 16, 17:31    [19829934]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
mitek
Member

Откуда:
Сообщений: 605
use-se
Вот кстати, еще 1 вопрос сомнений. Сейчас (на БД, СХД DS5100) стоит: OVERHEAD=12.67, TRANSFERRATE=0.18 для TS, и фактически эти параметры переносятся вместе c backup на копии для тестов, Storwize v7000 и FlashSystem.
Я думаю, что эти параметры влияют только на выбор планов, но вдруг и на что то еще?
1) Нужно ли менять эти 2 параметра при переносе БД?
2)Какова методика расчета этих параметров для БД или нужно искать в документации на железо, может просто есть где то рекомендации IBM где в табличке приведены DB2 & СХД?


Вот здесь (правда для SAP'а)

для IBM Flash System рекомендуется :
OVERHEAD = 0.3
TRANSFERRATE = 0.1

Для сторвайзов будет зависеть от того на каком конкретно пуле (HDD, SSD, гибридный) будут лежать соответствующие VDISK'и
Также для сторвайзов рекомендуется использовать число VDISK'ов кратное 4-ем.
28 окт 16, 12:55    [19833105]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
Параметры OVERHEAD и TRANSFERRATE используются для вычисления стоимости.
Пример
OVERHEAD=12.67 миллисекунд
TRANSFERRATE=0.18 миллисекунд на страницу
размер страницы 4К
размер экстента 4 страницы

Тогда в 1 мебайте 256 страниц, при линейном чтении (без overhead) это оценивается, что прочитается примерно за 256*0.18 = 46 миллисекунд, т.е. скорость оценивается 21 мег в секунду.

Но если мы прочитаем это постранично случайным доступом, время оценивается как 256*(12.57+0.18)= 3264 миллисекунд (3.264 секунды), в 71 раз медленнее линейного чтения.

Но если мы прочитаем это поэкстентно, время оценивается как 64*12.57+256*0.18 = 851 миллисекунда, в 18 раз медленнее линейного чтения.

DB2-шные таймероны, в которых указана стоимость, как я понимаю, это и есть расчётные миллисекунды.

Эти цифры
OVERHEAD=12.67 миллисекунд
TRANSFERRATE=0.18 миллисекунд на страницу
не мне кажутся адекватными для данного случая.

Но я не знаю, как получить параметры, особенно на системах хранения, кроме как воспользовавшись как IOmeter'ом или ORION'ом (а ORION ныне идёт только в комплекте с Oracle Server).

Надо ещё прибавить, что чем больше одновременных запросов (из разных процессов или нитей) наваливается на диски, тем OVERHEAD больше (растёт в разы), но оптимизатор про это не знает.

Ну, и в статье, которую я недавно читал про оптимизатор (в поисках DB2 LEO), автор заявил, что эти цифры не очень важны, а настоящая проблема в оценке cardinality у предикатов. В самом деле, от этого очень сильно зависит, когда индекс нужен, когда не нужен, когда nested loop join использовать и когда hash join и в каком порядке. Жестокая борьба ведётся (Ораклем!), но результаты ... неоднозначные.

Ещё надо иметь в виду
29 окт 16, 00:35    [19836169]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
use-se
Mark Barinstein
use-se,

Сколько времени выполняется теперь запрос ниже, каков его план?

SELECT count(h.PAY_STATUS)
FROM SH1.BIG_TAB h, SH2.SMALL_TAB l
WHERE h.C1_ID = l.C1_ID
WITH UR

Он должен гораздо быстрее выполняться...

Запрос выполняется 19 минут.

А вставка 30. Напрашивается мысль о сильном влиянии чистки грязного буферного пула. Но нужен мониторинг диска и процессоров, чтобы это подтвердить.
29 окт 16, 00:37    [19836176]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
use-se
Member

Откуда: Москва
Сообщений: 448
mitek
use-se
Вот кстати, еще 1 вопрос сомнений. Сейчас (на БД, СХД DS5100) стоит: OVERHEAD=12.67, TRANSFERRATE=0.18 для TS, и фактически эти параметры переносятся вместе c backup на копии для тестов, Storwize v7000 и FlashSystem.
Я думаю, что эти параметры влияют только на выбор планов, но вдруг и на что то еще?
1) Нужно ли менять эти 2 параметра при переносе БД?
2)Какова методика расчета этих параметров для БД или нужно искать в документации на железо, может просто есть где то рекомендации IBM где в табличке приведены DB2 & СХД?


Вот здесь (правда для SAP'а)

для IBM Flash System рекомендуется :
OVERHEAD = 0.3
TRANSFERRATE = 0.1

Для сторвайзов будет зависеть от того на каком конкретно пуле (HDD, SSD, гибридный) будут лежать соответствующие VDISK'и
Также для сторвайзов рекомендуется использовать число VDISK'ов кратное 4-ем.

Большое спасибо.
Попробую.
1 ноя 16, 14:29    [19846420]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
use-se
Member

Откуда: Москва
Сообщений: 448
Victor Metelitsa
use-se
пропущено...

Запрос выполняется 19 минут.

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

Мне кажется, что при использовании агрегатных функци, DB2 несколько иначе
обрабатывает строки, возможно я ошибаюсь.
Если вместо вставки в таблицу использовать экспорт на диск,
то суммарно время выборки незначительно но возрастает.
1 ноя 16, 14:56    [19846596]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4]      все
Все форумы / IBM DB2, WebSphere, IMS, U2, etc Ответить