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

Имеем БД:
DB2 LUW ver 9.7 fix pack 8 Enterprise x64
на платформе: Win 2008 R2 Enterprise x64
сервер: BC Hx5, CPU: E7-4870, RAM: 384GB
СХД: Storwize V7000.
Суть проблемы:
Есть таблица с количеством строк порядка 5 млд. записей и небольшой средней длинной записи . В табличном пространстве только эта таблица. На таблице 1 кластеризованный индекс, который используется когда выборка данных небольшая и не используется когда итоговая выборка составляет > 300 тыс. строк. Это все нормально и оптимизатор отрабатывает корректно, поскольку таблица кластеризована именно по этой большой выборке и коэффициент селективности небольшой.
Проблема заключается в том, что когда идет большая выборка данных мы видим, что суммарная нагрузка на СХД очень мала (примерно 25 -35 MB/s), причем скорость выборки не зависит ни от нагрузки на БД не от нагрузки на СХД. Причем скорость выборки не зависит даже от мощности СХД, наши тесты на DS5100 и на Storwize v7000 показывают одинаковые результаты. На обоих СХД используется 1 большой массив из RAID 10. Попытка разнести табличное пространство на 10 логических дисков (в пределах 1 массива на СХД) не принесла результата, мы имеем все ту же скорость ~30 MB/s., пропорционально распределенную по контейнерам. На комбинированных тестах мы получали на Storwize v7000 суммарную скорость ~ 2 GB/s. Изменение параметров: intra_parallel & querydegree результатов не дали, не можем понять где узкое место. DB2ADVIS говорит, что так и должно быть и изменений не требуется.

Вопрос. Почему мы не можем получить сравнимые скорости (или хотя бы улучшение) при выборке данных? На что стоит посмотреть, на какие параметры БД или может СХД?

Спасибо.

Мне стоило указать пример запроса.

small_tab(c1 bigint), row_count=6 000 000
big_tab(c1..c7), row_count=5 000 000 000
result request count ~ 280 000 000

select c1, c2, c3, c4 from big_tab b, small_tab s where b.c1=s.c1 with ur;

>>"Если у вас запрос подобный первому, то много из него вы не выжмете"
Это из личного опыта или есть какие либо причины, ограничения или еще что то?
Если не трудно, поделитесь, пожалуйста.

Кстати, если начать длинную транзакцию, а потом прервать ее, то можно получить скорость записи
до 300 МБ/с на этом же TBSP.

Спасибо.

Mark Barinsteinuse-se,

А какая скорость работы с диском у, скажем:

select count(c1), count(c2), count(c3), count(c4) from big_tab b, small_tab s where b.c1=s.c1 with ur;

?

Скорость упала до 10 мб/с (причем стартовал процесс с 1 мб/с потом дорос до 10 мб/с, сейчас упал до 5мб/с).
В принципе все объяснимо, поскольку чтение идет сейчас из индексного TS.
Можно, конечно, пересоздать индекс с добавлением (include) полей и тогда посмотреть, может это решит проблему?

dbtwoshnick ,
Спасибо за подробное описание.
У меня нет точных данных по lun и пр., но к примеру на DS5100 было 44 диска RAID10, на Storwize их больше +
там SDD как то включено. Насчет последовательности чтения, попробую перезалить таблицу, через экспорт.

Mark Barinstein ,
пока писал ответ скорость изменилась, сейчас скачет 7-30 мб/с

Интересно насколько актуальным является параметр db2_parallel_io=*.45 (сейчас стоит) для СХД вроде Storwize, мне сказали,
что не актуально, это так?

Victor MetelitsaПредположим, в табличном пространстве размер блока 32K, а размер экстента 32 блока - то есть 1M. Мелкоблочное чтение как раз про блоки, крупноблочное про экстенты (хотя есть нюансы). Если файловая система будет выделять место под файл блоками размером 1М (или кратными 1М), то это как раз то, что нужно.

Ну, и поддержку raw devices у DB2, кажется, ещё не совсем зарезали.
TS:
Page size = 4k
Extent size = 32
Prefetch size = -1

Victor Metelitsause-seСкорость упала до 10 мб/с (причем стартовал процесс с 1 мб/с потом дорос до 10 мб/с, сейчас упал до 5мб/с).
В принципе все объяснимо, поскольку чтение идет сейчас из индексного TS.
Можно, конечно, пересоздать индекс с добавлением (include) полей и тогда посмотреть, может это решит проблему?

Include, скорее всего ускорит. Но если вы сумеете удачно разбить таблицу на секции (partitions, multidimentional clusters - MDC), так, чтобы считать небольшое количество секций не по индексу, а fullscan'ом по этим секциям, это будет ещё лучше.
попробую

sysdymmy1use-seМне стоило указать пример запроса.

small_tab(c1 bigint), row_count=6 000 000
big_tab(c1..c7), row_count=5 000 000 000
result request count ~ 280 000 000

select c1, c2, c3, c4 from big_tab b, small_tab s where b.c1=s.c1 with ur;


Если вы просто куда-то фетчите все эти 280M строк, то тогда неудивительно
Это какие-то выгрузки ? Ну не юзеру же в репорте понадобилось столько строк ...

use-se>>"Если у вас запрос подобный первому, то много из него вы не выжмете"
Это из личного опыта или есть какие либо причины, ограничения или еще что то?
У меня примерно так же работают всякие ETL-екстракторы, тянущие десятки миллионов строк из таблиц-источников. Производительность одного процесса примерно такая же. Но их идет несколько параллельно.
Да это ETL, вида:
db2 +c alter table res activate not logged initially with empty table
db2 insert into res select c1, c2, c3, c4 from big_tab b, small_tab s where b.c1=s.c1 with ur
Проблема в том, что процесс выборки:
1. достаточно долгий (2-6 часов)
2. при наличии длинной транзакции на БД растут логи
3. БД в большей степени OLTP

[quot Victor Metelitsa]use-seпропущено...


Вместо insert может быть удобнее load from cursor - едва ли быстрее, но хотя бы таблицу не надо пересоздавать, если что-то сломается по дороге. (Хотя при восстановлении из бекапа всё равно придётся. Жаль, что никто не предложит ibm-ерам на такие случаи сделать что-нибудь вроде alter table ... validate with empty table - пусть содержимое потерялось, но пересоздавать таблицы не доставляет удовольствия).

А сам запрос выглядит безобидным, предполагая, что большая таблица фуллсканируется, а маленькая таблица вошла в буферный пул.
LOAD для меня еще большая проблема. Вне зависимости от параметров иногда намертво подвешивает всю БД.
Воспроизвел на тестовом сервере эту проблему и несколько раз запускал db2fods c hang парамтром, но увы умирает совсем,
но это другая песня.
Кстати export по сравнению с insert, прироста скорости не дает, да и реализация от разработчика именно ткая как написал выше.

Mark Barinsteinuse-seпока писал ответ скорость изменилась, сейчас скачет 7-30 мб/с

Интересно насколько актуальным является параметр db2_parallel_io=*.45 (сейчас стоит) для СХД вроде Storwize, мне сказали,
что не актуально, это так?
Надо план запроса смотреть - использование индексов тут, скорее всего, будет очень неэффективным.
Большую таблицу надо бы попробовать организовать по MDC (с1).
db2_parallel_io=* (т.е. 6) для Storwize в IBM PDOA. У вас очень большое значение.
План запроса напрямую зависит от количества выбираемых данных.
Основное назначение БД OLTP, т.е. для нашей большой таблицы на 1 запрос выбирается от 20 до 1000
записей, время выборки меньше 1 секунды (доли секунды), здесь используется индекс.
При большой выборке, как было указано вначале, индекс не используется, а если и используется
(на граничных условиях) то приводит, как правило, к увеличению общего времени выборки.

Таблица имеет уникальный кластерный индекс по 3 первым полям (bigint,date,bigint), соответственно.
Здесь немного статистики.
В момент первой загрузки/реорганизации по кластерному индексу clasterfacktor конечно же был выше, но и сейчас выборка
большого количества данных из таблице не намного хуже (по времени). Главная проблема, что нет прироста скорости на новом железе. Первичная реорганизация была offline. Конечно же хотелось бы реорганизовать табличку снова, но....
На тестовом сервере (с этой же БД) с имитацией нагрузки я пытался сделать online реорганизацию, но после 5 дней непрерывной реорганизации прервал ее.
Относительно маленькой таблицы, то она каждый день содержит новые данные и после каждого ETL чистится.
Я не вижу, что с ней можно сделать, там всего 1 поле (bigint).

Относительно:
>>Большую таблицу надо бы попробовать организовать по MDC (с1).
буду пробовать, но немного страшновато по следующим причинам:
1. Уникальность первичного ключа - это 3 поля, следовательность размерность будет 3? насколько вырастет потребность в дисковом пространстве?
2. пока не имею практики использования (почитать, конечно же почитаю и попробую), но насколько сложны
эти MDC в обслуживании?
3. я так понял стоит попробовать именно
авторORGANIZE BY -- Groups rows with similar values on multiple dimensions in the same table extent. This concept is known as multidimensional clustering (MDC).

а не
авторPARTITION BY -- Groups rows with similar values of a single dimension in the same data partition. This concept is known as table partitioning.


Mark Barinsteindb2_parallel_io=* (т.е. 6) для Storwize в IBM PDOA. У вас очень большое значение.
здесь немного не понял, вариант
а)db2_parallel_io=*
или
б)db2_parallel_io=*.6

Буду пробовать, тестировать - это займет время.
У меня будет возможность проверить эту выборку на IBM FlashSystem, посмотрим, что там будет.

Большое спасибо всем за помощь, всем удачных выходных.