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

Откуда: Москва
Сообщений: 448
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространства?

Имеем БД:
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 говорит, что так и должно быть и изменений не требуется.

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

Спасибо.
13 окт 16, 15:23    [19778091]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
sysdummy1
Guest
use-se

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

Спасибо.


Многое зависит от запроса.

Например :

db2 "select * from db2inst5.r_lineitem_compr" > /dev/null

читает с диска 4 MB/s

db2 "select count(*) from db2inst5.r_lineitem_compr" > /dev/null

читает с диска 800 MB/c

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

Откуда: Москва
Сообщений: 448
Мне стоило указать пример запроса.

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.

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

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

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

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

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

Откуда: Тюмень
Сообщений: 2549
Ограничения находятся в физике винчестеров. Основное время уходит на подвод головки, само же считывание очень быстро. Поэтому крупноблочное чтение очень быстрое, мелкоблочное чтение очень медленное (рахница разительна!), причём даже когда загрузка винчестеров в обоих случаях 100%. Для системы хранения данных прибавляется передача по сети, у которой подобная же проблема "крупноблочная передача vs мелкоблочная передача". Поэтому ограничиваться рассмотрением голых мегабайтов в секунду - ошибка. Надо рассматривать и другие параметры, вроде величины считываемого блока и загрузки винчестеров. Ещё довольно полезно анализировать планы, понимать, что стоит за цифрами "таймеронов" (я пришёл к выводу, что это расчётные миллисекунды), в каком случае чтение будет крупноблочным и в каком мелкоблочном и как это видно в плане. К сожалению, для DB2 я литературы на эту тему не знаю, читайте Jonathan Lewis. Cost based Oracle Fundamentals.
13 окт 16, 22:57    [19779578]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
"Мелкоблочность" чтения зависит от фрагментации на дисках, а это как мне кажется зависит от:

1) фрагментации виртуального диска или блока, например lun
2) фрагментации базы, что решается через reorg, по сути ночной reorg - это борьба за экономию на дневных IOPS-ах


При максимальной фрагментации получается почти случайное чтение, современные диски выдают около 200 random IOPS .
При размере блока=4K скорость получается 200*4K=800K/секунду=примерно 1 мбайт/секунду на каждый диск.

Если у вас качественный RAID10 (например ZFS), то предельная скорость random операций увеличивается до кол-ва дисков * 1мбайт/секунду.

Например, для 4 дисков - это около 4Мбайт/секунду.

Если ваши 30Мбайт в секунду - это для рандомного чтения, то это очень хороший показатель достижимый при количестве дисков около 20-30 шт.

Чисто рандомного чтения конечно не бывает:
1) Не так велика фрагментация на диске, особенно для ZFS, где все записи (даже перезаписи старых данных) последовательные в пределах доступного нефрагментированого пространства. По сути в ZFS не бывает перезаписи, походит на архивные логи базы, всегда на новом незанятом месте.
2) Обычно в хранилище несколько кэшей различного уровня

Например, при dd чтении с zvol с базой можно наблюдать флуктацию скорости от 3 до 30 МБ/сек.
3 - это когда совсем рандом
30 - это когда данные поступают из ARC, L2ARC либо просто последовательно вычитываются с дисков при удачном стечении обстоятельств, когда они записывались ранее

Сомнительно, что передача данных по сети на сколько-нибудь заметно замедляет работу СУБД, ethernet пофик фрагментация данных на диске, если только небольшой лаг, но ведь и другие интерфейсы типа SAS не мгновенные.
При скоростях около 30Мбайт/секунду, навряд ли сеть может как то повлиять на скорость.

Как можно улучшить ситуацию?
Наверно, с помощью nvram PCI SSD типа Intel DC 3700.
В случае ZFS можно не все данные размещать на SSD, а например только L2ARC кэш второго уровня, получается экономнее, но остается вероятность время от времени прямого рандомного чтения с HDD, что значительно медленнее, чем c SSD.

Еще SSD очень помогает улучшить производительность при update/insert/delete, если на них разместить активные логи.

Сколько IOPS у вас показывает хранилище при долгом чтении?
Сколько дисков в хранилище?
14 окт 16, 06:04    [19779844]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
еще наверно можно раскидать т. пространства по разным хранилищам
14 окт 16, 07:53    [19779910]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
dbtwoshnick
Например, при dd чтении с zvol с базой можно наблюдать флуктацию скорости от 3 до 30 МБ/сек.
3 - это когда совсем рандом
30 - это когда данные поступают из ARC, L2ARC либо просто последовательно вычитываются с дисков при удачном стечении обстоятельств, когда они записывались ранее


это всего лишь для 4! дисков в ZFS 2x2 как RAID10
14 окт 16, 07:56    [19779915]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
dbtwoshnick
"Мелкоблочность" чтения зависит от фрагментации на дисках


Нет, я про случай, когда файл табличного пространства непрерывен. Тем не менее, часть запросов крупноблочные, а часть мелкоблочные. Крупноблочные - фуллсканы, а мелкоблочные - поиск по индексу. Поэтому, например, могут быть очень выгодны MDC.
14 окт 16, 09:01    [19780051]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
Victor Metelitsa
Тем не менее, часть запросов крупноблочные, а часть мелкоблочные.

Точнее, одни access path крупноблочные, другие мелкоблочные. У DB2 в плане запроса у крупноблочных пунктов может быть что-то вроде "prefetch eligible".
14 окт 16, 09:04    [19780063]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Victor Metelitsa
dbtwoshnick
"Мелкоблочность" чтения зависит от фрагментации на дисках


Нет, я про случай, когда файл табличного пространства непрерывен. Тем не менее, часть запросов крупноблочные, а часть мелкоблочные. Крупноблочные - фуллсканы, а мелкоблочные - поиск по индексу. Поэтому, например, могут быть очень выгодны MDC.


а разве бывают непрерывные файлы в т.ч. TS с точки зрения HDD если база не только что залита из бэкапа, а долгое время накапливала данные раскидывая их случайным образом на всех уровнях абстракции данных? это ведь не свежескопированный на пустой винт большой ISO, который читается и пишется последовательно со скоростью 100 метров в сек и более

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

но ведь еще есть файловая система, обслуживающая lun

как мне кажется накладываются все факторы:
1) фрагментация хранилища под lun, если небыло полного предварительного thick eager provisioning
2) фрагментация TS поверх lun
3) случайный характер обращений DB2 при мелкоблочныx операциях

все это работает в комплексе и в конечном итоге может как увеличивать количество IOPs, так, наверно, иногда и уменьшать если повезет случайным блокам с точки зрения DB2 (или файловой системы верхнего уровня) физически оказаться рядом
14 окт 16, 09:43    [19780188]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
use-se
Member

Откуда: Москва
Сообщений: 448
Mark Barinstein
use-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, мне сказали,
что не актуально, это так?
14 окт 16, 10:24    [19780429]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Victor Metelitsa
Member

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

Ну, и поддержку raw devices у DB2, кажется, ещё не совсем зарезали.
14 окт 16, 10:25    [19780437]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Victor Metelitsa
Member

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

Include, скорее всего ускорит. Но если вы сумеете удачно разбить таблицу на секции (partitions, multidimentional clusters - MDC), так, чтобы считать небольшое количество секций не по индексу, а fullscan'ом по этим секциям, это будет ещё лучше.
14 окт 16, 10:43    [19780561]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
sysdymmy1
Guest
use-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-екстракторы, тянущие десятки миллионов строк из таблиц-источников. Производительность одного процесса примерно такая же. Но их идет несколько параллельно.
14 окт 16, 11:00    [19780661]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Victor Metelitsa
Если файловая система будет выделять место под файл блоками размером 1М (или кратными 1М), то это как раз то, что нужно.


а на что влияет размер блока хранилища? выравнивание при фрагментации?
и в чем он выражается размер блока хранилища (не измеряется)?

размер блока hdd то ведь не поменять, максимальное кол-во IOPS на 1 hdd тоже фиксированное

возможно, было бы хорошо когда размер блока хранилища был бы кратен с количеством зеркал (страйпов vdevs), помноженным на размер блока на каждом зеркале т.е. на каждом HDD, если это RAID10?

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

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

Ну, и поддержку raw devices у DB2, кажется, ещё не совсем зарезали.

TS:
Page size = 4k
Extent size = 32
Prefetch size = -1

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

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

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

Откуда: Москва
Сообщений: 448
sysdymmy1
use-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
14 окт 16, 11:36    [19780915]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
dbtwoshnick
Victor Metelitsa
Если файловая система будет выделять место под файл блоками размером 1М (или кратными 1М), то это как раз то, что нужно.


а на что влияет размер блока хранилища? выравнивание при фрагментации?
и в чем он выражается размер блока хранилища (не измеряется)?

размер блока hdd то ведь не поменять, максимальное кол-во IOPS на 1 hdd тоже фиксированное

возможно, было бы хорошо когда размер блока хранилища был бы кратен с количеством зеркал (страйпов vdevs), помноженным на размер блока на каждом зеркале т.е. на каждом HDD, если это RAID10?

тогда каждый блок хранилища был бы представлен одинаковым количеством блоков на каждом hdd, хотя хранилища все более интеллектуальные и трудно точно предугадать, как они будут распределять по дискам


время io = время на позиционирование головки (X1) + время на считывание/запись (X2)
1 мег (при размере блока DB2 = 32K и extent size = 32) можно прочитать за 32 * X1 + 32 * X2 или за 1 * X1 + 32 * X2.
Учитывая, что X1 очень велик по сравнению с X2, основной вклад в сравнении вносят именно 32 * X1 или 1 * X1.
Количество iops у винчестеров (и не только у них) всё-таки разные для разного размера, и потому, что X2 не 0, и потому, что могут вступить какие-то другие ограничивающие факторы.
Размер блока HDD имеет к этому весьма косвенное отношение. К примеру, выравнивание выбрано неудачно, по-старинке с 63-го сектора, а винчестер новый с блоком 4К, но современные операционные системы по умалчанию делают смещение 2048.

Желательно, чтобы чтение одного блока DB2 (4К ... 32К), будучи транслированным через разные уровни (собственно DB2, файловая система ОС, система на хранилище), приводило к одному чтению с одного HDD, и чтобы одно чтение экстента DB2 приводило к одному чтению с одного HDD, к этому надо стремиться, изучать и настраивать все уровни. Кроме того, чтение одного экстента (что приблизительно равно тому многоблочному чтению, о котором говорю) ещё более выгодно по сравнению с одноблочным, если разбиение неудачно. Например, случай выше со смещением 63 (512-байтовых логических блоков) на винчестере с 4К физических блоков, четырёхкилобайтовый блок будет считан за два физических чтения, но и экстент тоже).
14 окт 16, 12:26    [19781160]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
[quot use-se]
sysdymmy1
пропущено...
Да это 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


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

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

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


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

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

LOAD для меня еще большая проблема. Вне зависимости от параметров иногда намертво подвешивает всю БД.
Воспроизвел на тестовом сервере эту проблему и несколько раз запускал db2fods c hang парамтром, но увы умирает совсем,
но это другая песня.
Кстати export по сравнению с insert, прироста скорости не дает, да и реализация от разработчика именно ткая как написал выше.
14 окт 16, 12:49    [19781276]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4872
use-se
пока писал ответ скорость изменилась, сейчас скачет 7-30 мб/с

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

Надо план запроса смотреть - использование индексов тут, скорее всего, будет очень неэффективным.
Большую таблицу надо бы попробовать организовать по MDC (с1).
db2_parallel_io=* (т.е. 6) для Storwize в IBM PDOA. У вас очень большое значение.
14 окт 16, 13:58    [19781701]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
Да, с планом непонятно. Я автоматически думал, что большая ведущая, а маленькая ведомая, и для каждой b.c1 существует s.c1.
select c1, c2, c3, c4 -- кстати, здесь некорректно без префикса
from 
  big_tab b 
  join small_tab s on b.c1=s.c1

в таком случае вообще напрашивается хеш-джойн, а индексы не нужны. Маленькая таблица закачивается в память, затем большая полностью сканируется и по хешу c1 в памяти ищутся значения закешированной маленькой таблицей.

Забавно, что для одного и того же исполнения
* IBM рисует в explain'е плана маленькую таблицу раньше (левее) большой,
* а Oracle позже (ниже).
IBM, видимо, исходит из логики, что маленькая таблица скачивается первой, а Oracle считает более важным, что большая таблица полностью сканируется, и для каждой b ищется s, и неважно, закеширована ли s.

Важно, конечно, чтобы эта маленькая таблица была достаточно мала.

А вот когда только для маленького процента b.c1 существует s.c1, логично пройти по s.c1 и для каждой записи там искать в b1 соответствия. Тогда надо как минимум индекс, а MDC по c1 должно быть оптимальным.
14 окт 16, 14:59    [19782065]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
DECLARE myCurs CURSOR 
-- DATABASE $db1 USER $user1 USING $pwd1
FOR запрос
@

LOAD client FROM myCurs
OF cursor
INSERT INTO  таблица
-- 	STATISTICS USE PROFILE 
NONRECOVERABLE 
@


Без NONRECOVERABLE видал веселуху - табличному пространству позарез хочется забекапиться после LOAD'а. Но с NONRECOVERABLE всё всегда ОК.
14 окт 16, 15:05    [19782107]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс  [new]
use-se
Member

Откуда: Москва
Сообщений: 448
Mark Barinstein
use-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), соответственно.
Здесь немного статистики.
F1: 100 * OVERFLOW / CARD < 5
F2: 100 * (Effective Space Utilization of Data Pages) > 70
F3: 100 * (Required Pages / Total Pages) > 80

SCHEMA.NAME CARD OV NP FP ACTBLK TSIZE F1 F2 F3 REORG
----------------------------------------------------------------------------------------
Table: big_tab
5,2e+09 0 9e+07 9e+07 - 3,46e+11 0 99 99 ---
----------------------------------------------------------------------------------------

Index statistics:

F4: CLUSTERRATIO or normalized CLUSTERFACTOR > 80
F5: 100 * (Space used on leaf pages / Space available on non-empty leaf pages) > MIN(50, (100 - PCTFREE))
F6: (100 - PCTFREE) * (Amount of space available in an index with one less level / Amount of space required for all keys) < 100
F7: 100 * (Number of pseudo-deleted RIDs / Total number of RIDs) < 20
F8: 100 * (Number of pseudo-empty leaf pages / Total number of leaf pages) < 20

SCHEMA.NAME INDCARD LEAF ELEAF LVLS NDEL KEYS LEAF_RECSIZE NLEAF_RECSIZE LEAF_PAGE_OVERHEAD NLEAF_PAGE_OVERHEAD PCT_PAGES_SAVED F4 F5 F6 F7 F8 REORG
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Table: big_tab
Index: big_tab_PK
5,2e+09 6e+07 55765 5 7e+07 5,2e+09 20 20 370 370 0 69 73 2 1 0 *----
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
В момент первой загрузки/реорганизации по кластерному индексу 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 Barinstein
db2_parallel_io=* (т.е. 6) для Storwize в IBM PDOA. У вас очень большое значение.

здесь немного не понял, вариант
а)db2_parallel_io=*
или
б)db2_parallel_io=*.6

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

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