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

согласен, не маленькая, а микроскопическая ...
особенно на фоне 384GB сервера, в которые у 112 мег есть хорошие шансы уместиться даже в виде хеша

Victor Metelitsa
"Разумеется", у DB2 хеш джойн есть. Возможно, настройки не позволили выделить нужное количество памяти.

я конечно не высокого мнения о db2, но о наличии хэш джина подозревал :D
и тоже голосую за настройки памяти.
18 окт 16, 22:52    [19797093]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4876
Victor Metelitsa,

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

Ещё раз: не всегда для соединения "больших" таблиц HJOIN эффективнее NLJOIN или MSJOIN.
18 окт 16, 23:12    [19797145]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
И тогда мы вновь возвращаемся к вопросу в первом письме = почему "суммарная нагрузка на СХД очень мала (примерно 25 -35 MB/s)".
18 окт 16, 23:37    [19797212]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4876
Yo.!
Mark Barinstein
Про одноблочное чтение - это откуда взято?
В плане - табличное сканирование большой (внешней) таблицы. Метод доступа - sequential prefetch - это чтение экстентами (большими блоками).

я так понимаю в плане 2, на каждую запись большой таблицы идет IXSCAN: (Index Scan) с PREFETCH: NONE. сканирование реально один блок читает, т.е. тот самый долбеж. разве нет ?
Нет, не правильно. Большая таблица (описание доступа в операторе 3) - слева, маленькая - справа.

автор
Mark Barinstein
Какой здесь смысл здесь таблицу из одного уникального проиндексированного поля засовывать в память, вычислять хэш для каждого уникального поля, чтобы потом по нему получать доступ?

не так. в оракле из pk маленькой таблицы построился бы хеш в памяти, потом пошел бы фуллскан большой. по мере чтения большой создавался бы хеш по pk и сравнивался с хеш-таблицой в памяти. если ключ не найдет в баню, если найден, в результирующий курсор нужные поля. таким образом он мог бы хоть петабайты большой таблицы читать и получить результат за адекватное время. думаю с 347 гб таблицы реально минут за 20 справиться по такой схеме.
Здесь 2 варианта, в обоих - сканирование большой таблицы. Отличаются они только способом к маленькой таблице.
db2 сканирует большую, но не строит хеш-индекс по маленькой, а пользуется существующим индексом по ней.
Другой вариант мог бы быть сканированием маленькой, построением хеш-индекса в памяти, доступ к ней по каждой строке из большой не по существующему индексу (который тоже вполне себе может сесть в память и быть не менее эффективным), а по фактически новому (хеш-индексу), построенному в процессе работы.
Я бы вот так сразу безапелляционно не сказал, какой способ лучше для пета- или экза- байтов лучше подойдёт. У обоих методов есть плюсы и минусы, и это надо на цену запроса и на время выполнения смотреть.
18 окт 16, 23:44    [19797232]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4876
Victor Metelitsa
И тогда мы вновь возвращаемся к вопросу в первом письме = почему "суммарная нагрузка на СХД очень мала (примерно 25 -35 MB/s)".
Да.
Здесь, наверное, можно просто простое сканирование на одну большую таблицу запустить (только с какой-нибудь агрегатной функцией, но чтоб было табличное сканированием плане), чтоб выяснить, на что система способна.
Можно и нужно также поэкспериментировать с block-based буфером.
18 окт 16, 23:52    [19797258]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4876
Альтернативный вариант получения HSJOIN без профиля - убить индекс на маленькую таблицу.
18 окт 16, 23:56    [19797272]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
Mark Barinstein
Yo.!
пропущено...
я так понимаю в плане 2, на каждую запись большой таблицы идет IXSCAN: (Index Scan) с PREFETCH: NONE. сканирование реально один блок читает, т.е. тот самый долбеж. разве нет ?
Нет, не правильно. Большая таблица (описание доступа в операторе 3) - слева, маленькая - справа.

Долбёж может быть по маленькой таблице, а точнее, по индексу маленькой таблицы. Конечно, если он закеширован, то всё должно быть ОК. А закеширован ли он? Я не уверен ни в чём.
19 окт 16, 09:42    [19797925]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
use-se
Member

Откуда: Москва
Сообщений: 448
Добрый день.
к сожалению, временно не смогу поводить тесты в том объеме, что ранее.
Понимаю, что звучит глупо, но это временно.
Буду выкладывать по готовности.
Спасибо.
19 окт 16, 12:42    [19799247]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
use-se
Member

Откуда: Москва
Сообщений: 448
Mark Barinstein
Альтернативный вариант получения HSJOIN без профиля - убить индекс на маленькую таблицу.

Индекс на маленькую таблицу убил и получил новый план, но по прежнему с NL,
но маленькая идет первой и в большой ищется по индексу. Профиль не прописывал. Но это только план,
сам тест пока запустить не могу.
+
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-19-14.27.50.161000
EXPLAIN_REQUESTER: DB2ADMIN

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

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



---------------- STATEMENT 1 SECTION 203 ----------------
QUERYNO: 1
QUERYTAG:
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,15692e+009
Query Degree: 1

Rows
RETURN
( 1)
Cost
I/O
|
1,69059e+008
NLJOIN
( 2)
1,15692e+009
4,37287e+008
/------+-------\
6,47055e+006 26,1275
TBSCAN FETCH
( 3) ( 4)
38146,2 95,3037
29031 36
| /---+----\
6,47055e+006 26,1275 5,24234e+009
TABLE: SH2 RIDSCN TABLE: SH1
SMALL_TAB ( 5) BIG_TAB
Q1 51,4576 Q2
4
|
26,1275
SORT
( 6)
51,4571
4
|
26,1275
IXSCAN
( 7)
51,4532
4
|
5,24234e+009
INDEX: SH1
BIG_TAB_PK
Q2



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

No extended Diagnostic Information for this statement.


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


1) RETURN: (Return Result)
Cumulative Total Cost: 1,15692e+009
Cumulative CPU Cost: 2,8679e+012
Cumulative I/O Cost: 4,37287e+008
Cumulative Re-Total Cost: 3,64762e+008
Cumulative Re-CPU Cost: 2,08065e+012
Cumulative Re-I/O Cost: 2,05764e+008
Cumulative First Row Cost: 73,3892
Estimated Bufferpool Buffers: 2,32969e+008

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

Input Streams:
-------------
9) 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) NLJOIN: (Nested Loop Join)
Cumulative Total Cost: 1,15692e+009
Cumulative CPU Cost: 2,8679e+012
Cumulative I/O Cost: 4,37287e+008
Cumulative Re-Total Cost: 3,64762e+008
Cumulative Re-CPU Cost: 2,08065e+012
Cumulative Re-I/O Cost: 2,05764e+008
Cumulative First Row Cost: 73,3892
Estimated Bufferpool Buffers: 2,32969e+008

Arguments:
---------
EARLYOUT: (Early Out flag)
NONE
FETCHMAX: (Override for FETCH MAXPAGES)
IGNORE
ISCANMAX: (Override for ISCAN MAXPAGES)
IGNORE

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

8) From Operator #4

Estimated number of rows: 26,1275
Number of columns: 3
Subquery predicate ID: Not Applicable

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


Output Streams:
--------------
9) 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)
SLOW
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) FETCH : (Fetch)
Cumulative Total Cost: 95,3037
Cumulative CPU Cost: 404410
Cumulative I/O Cost: 36
Cumulative Re-Total Cost: 56,726
Cumulative Re-CPU Cost: 320514
Cumulative Re-I/O Cost: 32
Cumulative First Row Cost: 64,3119
Estimated Bufferpool Buffers: 1,39037e+009

Arguments:
---------
JN INPUT: (Join input leg)
INNER
MAX RIDS: (Maximum RIDs per list prefetch request)
512
PREFETCH: (Type of Prefetch)
LIST
ROWLOCK : (Row Lock intent)
NONE
SPEED : (Assumed speed of scan, in sharing structures)
SLOW
TABLOCK : (Table Lock intent)
INTENT NONE
TBISOLVL: (Table access Isolation Level)
UNCOMMITTED READ
THROTTLE: (Scan may be throttled, for scan sharing)
FALSE
VISIBLE : (May be included in scan sharing structures)
FALSE
WRAPPING: (Scan may start anywhere and wrap)
FALSE

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

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



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

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

Column Names:
------------
+Q2.$RID$(A)

7) From Object SH1.BIG_TAB

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:
--------------
8) To Operator #2

Estimated number of rows: 26,1275
Number of columns: 3
Subquery predicate ID: Not Applicable

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


5) RIDSCN: (Row Identifier Scan)
Cumulative Total Cost: 51,4576
Cumulative CPU Cost: 174047
Cumulative I/O Cost: 4
Cumulative Re-Total Cost: 12,8812
Cumulative Re-CPU Cost: 94401
Cumulative Re-I/O Cost: 0
Cumulative First Row Cost: 51,4571
Estimated Bufferpool Buffers: 5,70915e+007

Arguments:
---------
NUMROWS : (Estimated number of rows)
27

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

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

Column Names:
------------
+Q2.$RID$(A)


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

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

Column Names:
------------
+Q2.$RID$(A)


6) SORT : (Sort)
Cumulative Total Cost: 51,4571
Cumulative CPU Cost: 172760
Cumulative I/O Cost: 4
Cumulative Re-Total Cost: 12,8785
Cumulative Re-CPU Cost: 86332,1
Cumulative Re-I/O Cost: 0
Cumulative First Row Cost: 51,4571
Estimated Bufferpool Buffers: 5,70915e+007

Arguments:
---------
DUPLWARN: (Duplicates Warning flag)
TRUE
NUMROWS : (Estimated number of rows)
27
ROWWIDTH: (Estimated width of rows)
20
SORTKEY : (Sort Key column)
1: Q2.$RID$(A)
TEMPSIZE: (Temporary Table Page Size)
4096
UNIQUE : (Uniqueness required flag)
TRUE

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

Estimated number of rows: 26,1275
Number of columns: 3
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q2.C1_ID(D)+Q2.C2_HISTORY_DATE(D)+Q2.$RID$


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

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

Column Names:
------------
+Q2.$RID$(A)


7) IXSCAN: (Index Scan)
Cumulative Total Cost: 51,4532
Cumulative CPU Cost: 160793
Cumulative I/O Cost: 4
Cumulative Re-Total Cost: 12,8785
Cumulative Re-CPU Cost: 86332,1
Cumulative Re-I/O Cost: 1
Cumulative First Row Cost: 51,4383
Estimated Bufferpool Buffers: 5,70915e+007

Arguments:
---------
MAXPAGES: (Maximum pages for prefetch)
1
PREFETCH: (Type of Prefetch)
NONE
ROWLOCK : (Row Lock intent)
NONE
SCANDIR : (Scan Direction)
FORWARD
TABLOCK : (Table Lock intent)
INTENT NONE
TBISOLVL: (Table access Isolation Level)
UNCOMMITTED READ

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

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


2) Stop Key Predicate,
Comparison Operator: Equal (=)
Subquery Input Required: No
Filter Factor: 4,98394e-009

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



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

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

Column Names:
------------
+Q2.C1_ID(D)+Q2.C2_HISTORY_DATE(D)+Q2.$RID$


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

Estimated number of rows: 26,1275
Number of columns: 3
Subquery predicate ID: Not Applicable

Column Names:
------------
+Q2.C1_ID(D)+Q2.C2_HISTORY_DATE(D)+Q2.$RID$


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

Schema: SH1
Name: BIG_TAB_PK
Type: Index

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: Yes
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



2) Сделал копию большой таблицы с секционированием на 20 партиций. На тестах скорость чтения
немного выше (40МБ/с), но в целом результат хуже. Эталонная выборка 2ч 30 минут, на партиционной почти 3 часа, но
возможно какие либо погрешности.
3) Запустил команду вида:
db2 select * from big_tab with ur > nul
, стабильно показывает 8МБ/с не больше, кажется немного странным, почему
4) Команда:
select count(c1_id), count(c2_history_date), count(pay_status) from big_tab_part with ur
читала со скоростью 450-550МБ/с, правда свалилась от арифм. переполнения, но оно и понятно (count_big).

Увеличить SORTHEAP без отключения STMM у меня не очень получилось )). Возможно стоит вообще подумать об отключении
STMM, но с другой стороны работает уже давно и дает какое то субъективное спокойствие (работает не трогай).

Когда снова появятся ресурсы, сделаю остальное:
а) Тестовю выгрузку по 1 пункту
б) MDC на большую таблицу
19 окт 16, 17:13    [19801006]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Yo.!
Guest
use-se
4) Команда:
select count(c1_id), count(c2_history_date), count(pay_status) from big_tab_part with ur
читала со скоростью 450-550МБ/с, правда свалилась от арифм. переполнения, но оно и понятно (count_big).

я же говорил NL долбит маленькую табличку одноблочным IXSCAN: (Index Scan)
добейся HASH JOIN и будет счастье. если результат ждешь дольше 30 минут, что-то не так.
19 окт 16, 18:37    [19801483]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
use-se
Member

Откуда: Москва
Сообщений: 448
Yo.!
use-se
4) Команда:
select count(c1_id), count(c2_history_date), count(pay_status) from big_tab_part with ur
читала со скоростью 450-550МБ/с, правда свалилась от арифм. переполнения, но оно и понятно (count_big).

я же говорил NL долбит маленькую табличку одноблочным IXSCAN: (Index Scan)
добейся HASH JOIN и будет счастье. если результат ждешь дольше 30 минут, что-то не так.

Ок. Спасибо большое. Я понял Вас еще по первому письму и пытаюсь к этому прийти. Да и подсказали уже относительно SORTHEAP.
Ресурсы не всегда доступны для тестов и сейчас мне придется подождать.
Но у меня к Вам тоже вопрос, почему на разных СХД с разной производительностью (DS5100 & Storwize v7000)
одни и те-же времена выборки, а бывает и хуже? Так или иначе все равно приходится сканировать большую таблицу,
выходит узкое место не в СХД? Тогда где?
Если бы я видел хоть какое либо значительное потребление ресурсов, CPU к примеру, или еще чего.
Мне кажется, что в данный момент я не могу даже правильно задать вопрос, наметив направление.
Думаю как только будут результаты тестов, включас HS, будет проще.
19 окт 16, 19:28    [19801620]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Yo.!
Guest
use-se
Ок. Спасибо большое. Я понял Вас еще по первому письму и пытаюсь к этому прийти. Да и подсказали уже относительно SORTHEAP.
Ресурсы не всегда доступны для тестов и сейчас мне придется подождать.
Но у меня к Вам тоже вопрос, почему на разных СХД с разной производительностью (DS5100 & Storwize v7000)
одни и те-же времена выборки, а бывает и хуже? Так или иначе все равно приходится сканировать большую таблицу,
выходит узкое место не в СХД? Тогда где?
Если бы я видел хоть какое либо значительное потребление ресурсов, CPU к примеру, или еще чего.
Мне кажется, что в данный момент я не могу даже правильно задать вопрос, наметив направление.
Думаю как только будут результаты тестов, включас HS, будет проще.

не знаю как в db2, а в оракле мы врубаем трейс по которому все видно. с какой скорости читает и что читает. у меня часто такие эффекты были когда insert into select писал в таблицу с констреинтами и одноблочное чтение оказывается вообще долбит третью таблицу из-за foreign key. по трейсу все четко видно, где и что читает, каким способом. ничего не надо гадать.
19 окт 16, 20:34    [19801764]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Mark Barinstein
Member

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

+ Создаем таблицу профилей, если еще нету

CREATE TABLE SYSTOOLS.OPT_PROFILE 
( 
  SCHEMA VARCHAR(128) NOT NULL
, NAME VARCHAR(128) NOT NULL
, PROFILE BLOB (2M) NOT NULL
, PRIMARY KEY ( SCHEMA, NAME ) 
) IN SYSTOOLSPACE;

+ optprof.xml
<?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='h'/> 
        <TBSCAN TABLE='l'/>
      </HSJOIN>                                  
    </OPTGUIDELINES>
  </STMTPROFILE>
</OPTPROFILE>


+ optprof.txt
"SH1","PROF1","optprof.xml"

+ q1.sql
-- запрос не будет выполняться, получим только план
set current explain mode explain;
set current explain snapshot explain;

-- Текст запроса должен быть такой же, как в xml файле
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
;

!db2exfmt -d DBNAME -1 -o exfmt.txt;

set current explain mode no;
set current explain snapshot no;

db2 "IMPORT FROM optprof.txt OF DEL MODIFIED BY LOBSINFILE INSERT_UPDATE INTO SYSTOOLS.OPT_PROFILE"
db2 "set current optimization profile SH1.PROF1"
db2 "flush optimization profile cache SH1.PROF1"
db2 -tf q1.sql

Покажите план из exfmt.txt
19 окт 16, 20:50    [19801794]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4876
Yo.!
я же говорил NL долбит маленькую табличку одноблочным IXSCAN: (Index Scan)
добейся HASH JOIN и будет счастье. если результат ждешь дольше 30 минут, что-то не так.
Многоблочное чтение маленькой таблицы закончится в самом начале сразу после построения хэш-индекса.
Потом при скане большой таблицы вне зависимости от того, какой именно индекс будет использоваться - существующий или хэш - для каждой записи большой таблицы придется обращаться к одной из 5М записей по этому индексу, и тут уже никакого многоблочного обращения быть не может.
Даже если всё хозяйство для маленькой таблицы будет в памяти, это далеко не бесплатная операция. Именно поэтому, скорее всего, оно и не может быстрее сканировать большую таблицу - не может быстрее обращаться в маленькую по индексу, каким бы эффективным он ни был.
19 окт 16, 20:59    [19801824]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4876
use-se
3) Запустил команду вида:
db2 select * from big_tab with ur > nul
, стабильно показывает 8МБ/с не больше, кажется немного странным, почему
4) Команда:
select count(c1_id), count(c2_history_date), count(pay_status) from big_tab_part with ur
читала со скоростью 450-550МБ/с, правда свалилась от арифм. переполнения, но оно и понятно (count_big).
Ничего странного. Прочитанное надо отдавать клиенту. Несмотря на то, что клиент локальный, оно просто не успевает передавать результат с такой скоростью, с которой могло бы читать. В 4 передавать большие объемы не надо, поэтому ничто читающего агента не тормозит.
use-se
Увеличить SORTHEAP без отключения STMM у меня не очень получилось )). Возможно стоит вообще подумать об отключении
STMM, но с другой стороны работает уже давно и дает какое то субъективное спокойствие (работает не трогай).
Трудно помочь с такой диагностикой проблемы - "не получилось". :)
19 окт 16, 22:19    [19802032]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Yo.!
Guest
Mark Barinstein
Многоблочное чтение маленькой таблицы закончится в самом начале сразу после построения хэш-индекса.
Потом при скане большой таблицы вне зависимости от того, какой именно индекс будет использоваться - существующий или хэш - для каждой записи большой таблицы придется обращаться к одной из 5М записей по этому индексу, и тут уже никакого многоблочного обращения быть не может.
Даже если всё хозяйство для маленькой таблицы будет в памяти, это далеко не бесплатная операция. Именно поэтому, скорее всего, оно и не может быстрее сканировать большую таблицу - не может быстрее обращаться в маленькую по индексу, каким бы эффективным он ни был.

не верю. в оракле бы
Yo.!
не так. в оракле из pk маленькой таблицы построился бы хеш в памяти, потом пошел бы фуллскан большой. по мере чтения большой создавался бы хеш по pk и сравнивался с хеш-таблицой в памяти. если ключ не найдет в баню, если найден, в результирующий курсор нужные поля. таким образом он мог бы хоть петабайты большой таблицы читать и получить результат за адекватное время. думаю с 347 гб таблицы реально минут за 20 справиться по такой схеме.


читать с HDD большую и параллельно сверять с хеш-таблицой в фоне думаю уже десятилетия не проблема. имхо все упирается в ограничения ио
19 окт 16, 23:10    [19802166]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
Хеш-джойн на оракле тем больше выгоден по сравнению с индексом, чем больше строк в таблице, которая стала хеш-таблицей. При условии, что всё влезло в память и хеш-функция адекватна для встретившихся данных (ну, свою в Oracle/DB2 мы всё равно задать не можем). Потому что доступ осуществляется "сразу", без прохода по дереву. Не видно причин, почему на DB2 должно быть по-другому.

Смысл работы с хешем в том, чтобы индекс отменить, осуществлять не проход по страницам индекса с бинарным поиском на каждой, а доступ a la
x := хештаблица[хешфункция(искомыйключ)],
где x - это список найденных значений с одинаковым значением хешфункция(искомыйключ),
и при "хорошей" хешфункции его размер "обычно" должен быть 0 или 1.

Если поисками в small_tab перегружен процессор, можно подумать о параллельном выполнении сканирования big_tab.
19 окт 16, 23:25    [19802239]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
Yo.!
читать с HDD большую и параллельно сверять с хеш-таблицой в фоне думаю уже десятилетия не проблема. имхо все упирается в ограничения ио


use-se
4) Команда:

select count(c1_id), count(c2_history_date), count(pay_status) from big_tab_part with ur

читала со скоростью 450-550МБ/с, правда свалилась от арифм. переполнения, но оно и понятно (count_big).
20 окт 16, 00:01    [19802326]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4876
Victor Metelitsa
Хеш-джойн на оракле тем больше выгоден по сравнению с индексом, чем больше строк в таблице, которая стала хеш-таблицей. При условии, что всё влезло в память и хеш-функция адекватна для встретившихся данных (ну, свою в Oracle/DB2 мы всё равно задать не можем). Потому что доступ осуществляется "сразу", без прохода по дереву. Не видно причин, почему на DB2 должно быть по-другому.

Смысл работы с хешем в том, чтобы индекс отменить, осуществлять не проход по страницам индекса с бинарным поиском на каждой, а доступ a la
x := хештаблица[хешфункция(искомыйключ)],
где x - это список найденных значений с одинаковым значением хешфункция(искомыйключ),
и при "хорошей" хешфункции его размер "обычно" должен быть 0 или 1.

Если поисками в small_tab перегружен процессор, можно подумать о параллельном выполнении сканирования big_tab.
Логически это то же индексирование, только сделанное немного по другому. Поиск одного знчения из миллионов "сразу" не бывает при любом подходе. Заставить оптимизатор "присмотреться" к HS без профиля можно, значительно увеличив SORTHEAP, конечно.
Несколько агентов (intra-parallelism) должны, конечно, помочь. Но ТС писал, что это не особо помогает, хотя я бы убедился в том, что в его тестах параллелизм действительно работает (план запроса надо получать из package cache в этом случае).
В этом конкретном случае хорошо помогла бы DPF - обе таблицы распределяются по ключу соединения, соединение на каждом разделе локальное. Очень хорошо должно параллелизоваться...
20 окт 16, 11:07    [19803474]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
use-se
Member

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

Создаем таблицу профилей...
...

Покажите план из exfmt.txt

В таком варианте план подрос
+
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-20-11.29.13.126007
EXPLAIN_REQUESTER: SH1

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

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.PROF1
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
/-----+------\
5,24234e+009 6,47055e+006
TBSCAN TBSCAN
( 3) ( 4)
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: 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)
22 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)
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 #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

4) From Operator #4

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 #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: 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
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 #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


4) 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
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 #2

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
20 окт 16, 11:45    [19803743]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Mark Barinstein
Member

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

Бессмысленно использовать HSJOIN в этой ситуации, как видно из цены запроса в плане, пока:
Sort Heap size:       84

Увеличте SORTHEAP до, скажем, 50000 (4K страниц) или даже 100000 и повторите получение плана запроса.
20 окт 16, 12:21    [19804021]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Mark Barinstein
Member

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

Вы можете попробовать получить план запроса даже на другом сервере db2 с гораздо меньшими характеристиками, даже на пустых таблицах, но с загруженной статистикой с промышленной системы.
Для этого вам надо:
- выгрузить DDL для каждой таблицы со статистикой:
db2look -d mydb -e -m -z SH1 -t BIG_TAB -o BIG_TAB.ddl
db2look -d mydb -e -m -z SH2 -t SMALL_TAB -o SMALL_TAB.ddl
- выполнить команды из файлов в тестовой БД
- установить характеристики пром. системы на тесте с помощью db2fopt (значения для opt_* взять из шапки плана запроса)

Дальше вы можете получать планы запроса на тестовой системе, играться там с опт. профилями, сравнивая цену запроса.
20 окт 16, 12:36    [19804129]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
use-se
Member

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

Вы можете попробовать получить план запроса даже на другом сервере db2 с гораздо меньшими характеристиками, даже на пустых таблицах, но с загруженной статистикой с промышленной системы.
Для этого вам надо:
- выгрузить DDL для каждой таблицы со статистикой:
db2look -d mydb -e -m -z SH1 -t BIG_TAB -o BIG_TAB.ddl
db2look -d mydb -e -m -z SH2 -t SMALL_TAB -o SMALL_TAB.ddl
- выполнить команды из файлов в тестовой БД
- установить характеристики пром. системы на тесте с помощью db2fopt (значения для opt_* взять из шапки плана запроса)

Дальше вы можете получать планы запроса на тестовой системе, играться там с опт. профилями, сравнивая цену запроса.

Болшое спасибо за помощь и за советы.
Я к сожалению сам по себе "небыстрая лань", но и в добавок бываю периоды, когда приходится
заниматься многоми задачами в параллель. Поэтому прошу простить за задержки.
Это план с 100 000 страницами сортировки:
+
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-20-12.33.43.605007
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: 8398165
Maximum Lock List: 98
Average Applications: 50
Locks Available: 263366448

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



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

Profile Information:
--------------------
OPT_PROF: (Optimization Profile Name)
SH1.PROF1
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: 1,565e+008
Query Degree: 1

Rows
RETURN
( 1)
Cost
I/O
|
1,69059e+008
HSJOIN
( 2)
1,565e+008
8,67065e+007
/-----+------\
5,24234e+009 6,47055e+006
TBSCAN TBSCAN
( 3) ( 4)
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,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:
---------
BLDLEVEL: (Build level)
DB2 v9.7.800.717 : s130316
HEAPUSE : (Maximum Statement Heap Usage)
96 Pages
PREPTIME: (Statement prepare time)
128 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: 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 #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

4) From Operator #4

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 #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: 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
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 #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


4) 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
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 #2

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



Думаю картина без dbm & db параметров все равно будет не полной.
+


Database Configuration for Database DB



Database configuration release level = 0x0d00

Database release level = 0x0d00



Database territory = RU

Database code page = 1251

Database code set = 1251

Database country/region code = 7

Database collating sequence = IDENTITY

Alternate collating sequence (ALT_COLLATE) =

Number compatibility = OFF

Varchar2 compatibility = OFF

Date compatibility = OFF

Database page size = 4096



Dynamic SQL Query management (DYN_QUERY_MGMT) = DISABLE



Statement concentrator (STMT_CONC) = OFF



Discovery support for this database (DISCOVER_DB) = ENABLE



Restrict access = NO

Default query optimization class (DFT_QUERYOPT) = 5

Degree of parallelism (DFT_DEGREE) = ANY

Continue upon arithmetic exceptions (DFT_SQLMATHWARN) = NO

Default refresh age (DFT_REFRESH_AGE) = 0

Default maintained table types for opt (DFT_MTTB_TYPES) = SYSTEM

Number of frequent values retained (NUM_FREQVALUES) = 10

Number of quantiles retained (NUM_QUANTILES) = 20



Decimal floating point rounding mode (DECFLT_ROUNDING) = ROUND_HALF_EVEN



Backup pending = NO



All committed transactions have been written to disk = NO

Rollforward pending = NO

Restore pending = NO



Multi-page file allocation enabled = NO



Log retain for recovery status = RECOVERY

User exit for logging status = YES



Self tuning memory (SELF_TUNING_MEM) = ON

Size of database shared memory (4KB) (DATABASE_MEMORY) = AUTOMATIC(83981658)

Database memory threshold (DB_MEM_THRESH) = 20

Max storage for lock list (4KB) (LOCKLIST) = AUTOMATIC(4096)

Percent. of lock lists per application (MAXLOCKS) = AUTOMATIC(98)

Package cache size (4KB) (PCKCACHESZ) = AUTOMATIC(8192)

Sort heap thres for shared sorts (4KB) (SHEAPTHRES_SHR) = AUTOMATIC(256)

Sort list heap (4KB) (SORTHEAP) = AUTOMATIC(51)



Database heap (4KB) (DBHEAP) = 300000

Catalog cache size (4KB) (CATALOGCACHE_SZ) = AUTOMATIC((MAXAPPLS*5))

Log buffer size (4KB) (LOGBUFSZ) = 16000

Utilities heap size (4KB) (UTIL_HEAP_SZ) = 200000

Buffer pool size (pages) (BUFFPAGE) = 200000

SQL statement heap (4KB) (STMTHEAP) = AUTOMATIC(4096)

Default application heap (4KB) (APPLHEAPSZ) = AUTOMATIC(2500)

Application Memory Size (4KB) (APPL_MEMORY) = AUTOMATIC(5000)

Statistics heap size (4KB) (STAT_HEAP_SZ) = AUTOMATIC(8096)



Interval for checking deadlock (ms) (DLCHKTIME) = 10000

Lock timeout (sec) (LOCKTIMEOUT) = -1



Changed pages threshold (CHNGPGS_THRESH) = 60

Number of asynchronous page cleaners (NUM_IOCLEANERS) = AUTOMATIC(39)

Number of I/O servers (NUM_IOSERVERS) = AUTOMATIC(60)

Index sort flag (INDEXSORT) = YES

Sequential detect flag (SEQDETECT) = YES

Default prefetch size (pages) (DFT_PREFETCH_SZ) = AUTOMATIC



Track modified pages (TRACKMOD) = YES



Default number of containers = 1

Default tablespace extentsize (pages) (DFT_EXTENT_SZ) = 32



Max number of active applications (MAXAPPLS) = 900

Average number of active applications (AVG_APPLS) = AUTOMATIC(100)

Max DB files open per application (MAXFILOP) = 65535



Log file size (4KB) (LOGFILSIZ) = 32000

Number of primary log files (LOGPRIMARY) = 20

Number of secondary log files (LOGSECOND) = 200

Changed path to log files (NEWLOGPATH) =

Path to log files = E:\logs\

Overflow log path (OVERFLOWLOGPATH) =

Mirror log path (MIRRORLOGPATH) =

First active log file = S0432036.LOG

Block log on disk full (BLK_LOG_DSK_FUL) = AUTOMATIC(YES)

Block non logged operations (BLOCKNONLOGGED) = NO

Percent max primary log space by transaction (MAX_LOG) = 0

Num. of active log files for 1 active UOW(NUM_LOG_SPAN) = 50



Group commit count (MINCOMMIT) = 1

Percent log file reclaimed before soft chckpt (SOFTMAX) = 1800

Log retain for recovery enabled (LOGRETAIN) = RECOVERY

User exit for logging enabled (USEREXIT) = OFF



HADR database role = STANDARD

HADR local host name (HADR_LOCAL_HOST) =

HADR local service name (HADR_LOCAL_SVC) =

HADR remote host name (HADR_REMOTE_HOST) =

HADR remote service name (HADR_REMOTE_SVC) =

HADR instance name of remote server (HADR_REMOTE_INST) =

HADR timeout value (HADR_TIMEOUT) = 120

HADR log write synchronization mode (HADR_SYNCMODE) = NEARSYNC

HADR peer window duration (seconds) (HADR_PEER_WINDOW) = 0



First log archive method (LOGARCHMETH1) = DISK:E:\archlogs\

Options for logarchmeth1 (LOGARCHOPT1) =

Second log archive method (LOGARCHMETH2) = OFF

Options for logarchmeth2 (LOGARCHOPT2) =

Failover log archive path (FAILARCHPATH) = H:\failarchpath\

Number of log archive retries on error (NUMARCHRETRY) = 5

Log archive retry Delay (secs) (ARCHRETRYDELAY) = 20

Vendor options (VENDOROPT) =



Auto restart enabled (AUTORESTART) = ON

Index re-creation time and redo index build (INDEXREC) = SYSTEM (RESTART)

Log pages during index build (LOGINDEXBUILD) = OFF

Default number of loadrec sessions (DFT_LOADREC_SES) = 1

Number of database backups to retain (NUM_DB_BACKUPS) = 366

Recovery history retention (days) (REC_HIS_RETENTN) = 366

Auto deletion of recovery objects (AUTO_DEL_REC_OBJ) = OFF



TSM management class (TSM_MGMTCLASS) = DB2MGMT

TSM node name (TSM_NODENAME) =

TSM owner (TSM_OWNER) =

TSM password (TSM_PASSWORD) =



Automatic maintenance (AUTO_MAINT) = ON

Automatic database backup (AUTO_DB_BACKUP) = OFF

Automatic table maintenance (AUTO_TBL_MAINT) = ON

Automatic runstats (AUTO_RUNSTATS) = OFF

Automatic statement statistics (AUTO_STMT_STATS) = OFF

Automatic statistics profiling (AUTO_STATS_PROF) = OFF

Automatic profile updates (AUTO_PROF_UPD) = OFF

Automatic reorganization (AUTO_REORG) = OFF



Auto-Revalidation (AUTO_REVAL) = DISABLED

Currently Committed (CUR_COMMIT) = DISABLED

CHAR output with DECIMAL input (DEC_TO_CHAR_FMT) = V95

Enable XML Character operations (ENABLE_XMLCHAR) = YES

WLM Collection Interval (minutes) (WLM_COLLECT_INT) = 0

Monitor Collect Settings

Request metrics (MON_REQ_METRICS) = NONE

Activity metrics (MON_ACT_METRICS) = NONE

Object metrics (MON_OBJ_METRICS) = NONE

Unit of work events (MON_UOW_DATA) = NONE

Lock timeout events (MON_LOCKTIMEOUT) = NONE

Deadlock events (MON_DEADLOCK) = WITHOUT_HIST

Lock wait events (MON_LOCKWAIT) = NONE

Lock wait event threshold (MON_LW_THRESH) = 4294967295

Number of package list entries (MON_PKGLIST_SZ) = 32

Lock event notification level (MON_LCK_MSG_LVL) = 1



SMTP Server (SMTP_SERVER) = xxx.xx.xx.xx

SQL conditional compilation flags (SQL_CCFLAGS) =

Section actuals setting (SECTION_ACTUALS) = NONE

Connect procedure (CONNECT_PROC) =



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

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

+ Сравнение 2-х планов
Database Context:                                 Database Context:                          
---------------- ----------------
Parallelism: None Parallelism: None
CPU Speed: 3,306410e-007 CPU Speed: 3,306410e-007
Comm Speed: 0 Comm Speed: 0
Buffer Pool size: 74211200 Buffer Pool size: 74211200
Sort Heap size: 1019 Sort Heap size: 100000
Database Heap size: 300000 Database Heap size: 300000
Lock List size: 8398150 Lock List size: 8398165
Maximum Lock List: 98 Maximum Lock List: 98
Average Applications: 50 Average Applications: 50
Locks Available: 263365984 Locks Available: 263366448

Access Plan: Access Plan:
----------- -----------
Total Cost: 2,36238e+008 Total Cost: 1,565e+008
Query Degree: 1 Query Degree: 1

Rows Rows
RETURN RETURN
( 1) ( 1)
Cost Cost
I/O I/O
| |
1,69059e+008 1,69059e+008
^NLJOIN HSJOIN
( 2) ( 2)
2,36238e+008 1,565e+008
8,67083e+007 8,67065e+007
/------+-------\ /-----+------\
5,24234e+009 0,0322488 5,24234e+009 6,47055e+006
TBSCAN IXSCAN TBSCAN TBSCAN
( 3) ( 4) ( 3) ( 4)
1,56039e+008 18,1524 1,56039e+008 38146,2
8,66775e+007 2 8,66775e+007 29031
| | | |
5,24234e+009 6,47055e+006 5,24234e+009 6,47055e+006
TABLE: SH1 INDEX: SH2 TABLE: SH1 TABLE: SH2
BIG_TAB SMALL_TAB_INDEX BIG_TAB SMALL_TAB
Q2 Q1 Q2 Q1

Суда по цене запроса план с HSJOIN имеет заметно меньшую цену, когда вы значительно расширили SORTHEAP.
Теперь можно попробовать без профиля попробовать (должно выбрать HSJOIN) и время выполнения с HSJOIN.
Ну и всё же с intra-parallel тоже надо бы попробовать.
20 окт 16, 14:26    [19804783]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
use-se
Member

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

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

И что же делать с SORTHEAP и остальными автоматическими настройками?
Отказаться, или каждый раз перед тяжелыми задачами менять SORTHEAP, SHEAPTHRES_SHR, LOCKLIST и пр.?
20 окт 16, 16:56    [19805545]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
Все форумы / IBM DB2, WebSphere, IMS, U2, etc Ответить