IDS 7.31 FD10 Solaris 10

исходные данные
есть детачнутые индексы в отдельном пространстве, довольно сильно фрагментированные и пространство к тому же близко к исчерпанию.

имеется сильное желание их переложить в другие пространства и на всякий случай дефрагментировать.

Вопрос использовал ли кто нибудь для этого alter fragment on index ... init in newdbs ?

То что их можно пересоздать понятно, но может альтер фрагментом быстрее?

onstat-

3. Блокировок тоже может не хватать.



Я предполагаю переводить БД в нелогируемый режим, при этом может нехватать блокировок?

vasiliscprЯ предполагаю переводить БД в нелогируемый режим
Если так, то никто из пользователей работать с БД не будет, а значит способ drop-create более предпочтителен.
А где лежат системные индексы ?
Если вы создавали констрейнты без предварительного создания соответствующих индексов, то системные индексы лежат в том же дбспейсе, где создана БД. Поэтому в вашем существующем пространстве с отсоединенными индексами системных индексов, скорее всего, нет.
Если же и системные индексы тоже нужно переносить, то помните о порядке выключения связных констрейнтов.


drop-create делать не хочется т.к. это таблица на которую имеется совершенно безумное количество ссылок.

Системных индексов нет, все созданы явно т.к. таблицу в свое время я перевел в круговую фрагментацию. Так что этой проблемы нет.

Сейчас как раз сисадмины подогнали тестовый сервер, проверяю альтер фрагмент.
Работает он как то странно. Насколько я вижу он пытается построить индекс заново.
Очень похоже, что для первичного ключа надо будет сделать alter fragment , а для остальных индексов использовать проверенный дедвский способ.

похоже, что для меня (в смысле 7.31) alter fragment не подойтет точно.
Индекс он строит так: каждый фрагмент сканируется столько раз, сколько у меня чанков. При этом первый чанк сканится 1 раз, 2-й 2 раза, 3-й 3 раза ... 16-й 16 раз.
У меня 4 фрагмента по 16 чанков. Дай то бог, чтобы первичный ключ за приемлемое время удалось переместить.
Ну еще можно попробовать настройки pdq потюнить.

vasilis,

Ага, скорее я не совсем корректно высказался. Автоиндексов нет, т.к. ... и т.д.

cprпохоже, что для меня (в смысле 7.31) alter fragment не подойтет точно.
Индекс он строит так: каждый фрагмент сканируется столько раз, сколько у меня чанков. При этом первый чанк сканится 1 раз, 2-й 2 раза, 3-й 3 раза ... 16-й 16 раз.
У меня 4 фрагмента по 16 чанков. Дай то бог, чтобы первичный ключ за приемлемое время удалось переместить.
Ну еще можно попробовать настройки pdq потюнить.

Мама моя рОдная, этот альтер фрагмент писали какие-то монстры. Он описаный выше процесс делал ТРИ раза. Но в приемлемое время для индекса первичного ключа слава богу попадаю.

cprcprпохоже, что для меня (в смысле 7.31) alter fragment не подойтет точно.
Индекс он строит так: каждый фрагмент сканируется столько раз, сколько у меня чанков. При этом первый чанк сканится 1 раз, 2-й 2 раза, 3-й 3 раза ... 16-й 16 раз.
У меня 4 фрагмента по 16 чанков. Дай то бог, чтобы первичный ключ за приемлемое время удалось переместить.
Ну еще можно попробовать настройки pdq потюнить.

Мама моя рОдная, этот альтер фрагмент писали какие-то монстры. Он описаный выше процесс делал ТРИ раза. Но в приемлемое время для индекса первичного ключа слава богу попадаю.

Слова про монстров забираю обратно.
Create index делал ровно то же самое.

Алексанvasilisalter fragment тем и ценен, что позволяет переносить данные не вникая в многочисленные связи и зависимости между таблицами. Но за эту "легкость использования" надо чем то платить... Абсолютно согласен с предыдущим оратором. И напрашивается логичное, на мой взгляд, решение - если индекс не обслуживает констрейнт, его имеет смысл перестроить (время то же, но он станет более компактным), а если обслуживает, то его имеет смысл не трогать, дабы не иметь последующего удовольствия восстанавливать "пропавшие" констрейнты.

Сделал альтер фрагмент и дроп-криэйт. Разница очень незначительна 256 минут и 264 минуты на один индекс. Спрашивайтся зачем брать с собой эту лошадь.

Если кому интересно - подробности
Таблица в четырех фрагментах общий объем 102 гига, платформа UltraSPARCIV 1350 MHz дисковая посистема FC массив (внутри SAS) 3Gbit/sec интерфейс, RAID10.

onstat-

У Вас что то не так сконфигурировано, при таком же объеме таблицы( около 100 ГБ), длине ключа
около 20 байт и 150 млн записей, постойка одного индекса занимала около 20 мин.
Фрагментов у меня по более было ( около 20 ).
Основные критерии это производительность процессоров и
производительность дисковой подсистемы по мультиблочному чтению.
Процессоры должны быть загружены на все 100% ~( 90(User)+5(SYS)+5(IOW) )

Интересно.
данные по таблице
33,5 миллиона записей, 4 фрагмента по 32 гиг каждый.
Размер записи 776 байт.
Подскажите где посмотреть размер ключа?
iostat показывает что с диска чтение происходит примерно 130 метров в секунду.
загрузка CPU от одного до двух ядер CPU

onstat-,

я предполагаю от ширины записи таблицы многое зависит.
и возможно от количества чанков в фрагменте.

cpr,

прикладываю onconfig

onstat-cpronstat-,

я предполагаю от ширины записи таблицы многое зависит.
и возможно от количества чанков в фрагменте.

Я тоже думаю что это имеет влияние процентов на 10-15%, но не в 10 раз.

Сотношение загрузка процессора - загрузки дисковой подсистемы у Вас какое ?

Дайте результат sar -ud и onstat -g mgm
во время постройки индекса.

sar -ud это что?

у меня такой утилиты нет т.к. соляра. у меня iostat

вывод onstat -g mgm во время завершения построения индекса, когда уже данные перестали массированно читаться

IBM Informix Dynamic Server Version 7.31.FD10 -- On-Line -- Up 20:04:19 -- 27206656 Kbytes

Memory Grant Manager (MGM)
--------------------------

MAX_PDQPRIORITY: 0
DS_MAX_QUERIES: 307200
DS_MAX_SCANS: 1048576
DS_TOTAL_MEMORY: 39321600 KB

Queries: Active Ready Maximum
0 0 307200

Memory: Total Free Quantum
(KB) 39321600 39321600 128

Scans: Total Free Quantum
1048576 1048576 1

Load Control: (Memory) (Scans) (Priority) (Max Queries) (Reinit)
Gate 1 Gate 2 Gate 3 Gate 4 Gate 5
(Queue Length) 0 0 0 0 0

Active Queries: None

Ready Queries: None

Free Resource Average # Minimum #
-------------- --------------- ---------
Memory 0.0 +- 0.0 4915200
Scans 0.0 +- 0.0 1048576

Queries Average # Maximum # Total #
-------------- --------------- --------- -------
Active 0.0 +- 0.0 0 0
Ready 0.0 +- 0.0 0 0

Resource/Lock Cycle Prevention count: 0

onstat-,

если можно завтра выложу остальное.

подскажите что это за ключи у sar, я попробую аналоги для соляры подобрать

подскажите плиз, это не ошибка?

давал команду onmod -M 10000000
в логе вылезло сообщение

mgm_reinit: memory 10000000 K < minimum (128 K) times queries (307200)

onstat-
Подозреваю, что в Вашем случае основную массу составляет ввод вывод temp.


Это не так.

Вот вывод onstat -D
======================================================================
Chunks
address chk/dbs offset page Rd page Wr pathname
5513622a8 1 1 0 0 3046 /dev/md/rdsk/d66
552c2f108 2 2 0 0 107 /dev/md/rdsk/d50
552c2f450 5 4 0 0 26 /dev/md/rdsk/d52
552c2f568 6 4 0 0 4 /dev/md/rdsk/d53
552d20028 58 13 0 18 3 /dev/md/rdsk/d140
552d20488 62 13 0 0 1 /dev/md/rdsk/d144
552d205a0 63 13 0 0 1 /dev/md/rdsk/d145
552d206b8 64 13 0 0 1 /dev/md/rdsk/d146
552d207d0 65 13 0 0 1 /dev/md/rdsk/d147
552d208e8 66 13 0 0 1 /dev/md/rdsk/d148
552d20a00 67 13 0 0 1 /dev/md/rdsk/d149
552d20b18 68 3 0 1747098 1752677 /opt/informix/dbs/chunk_tempdbs_01.dbs
552d20f78 72 14 0 3104116 0 /dev/md/rdsk/d155
552d21090 73 14 0 8186000 0 /dev/md/rdsk/d156
552d211a8 74 14 0 11040284 0 /dev/md/rdsk/d157
552d212c0 75 14 0 13894568 0 /dev/md/rdsk/d158
552d213d8 76 14 0 16748852 0 /dev/md/rdsk/d159
552d214f0 77 14 0 19603136 0 /dev/md/rdsk/d160
552d21608 78 14 0 22457420 0 /dev/md/rdsk/d161
552d21720 79 14 0 25311704 0 /dev/md/rdsk/d162
552d21838 80 14 0 28165988 0 /dev/md/rdsk/d163
552d21950 81 14 0 31020272 0 /dev/md/rdsk/d164
552d21a68 82 14 0 33874556 0 /dev/md/rdsk/d165
552d21b80 83 14 0 36728840 0 /dev/md/rdsk/d166
552d21c98 84 14 0 39583124 0 /dev/md/rdsk/d167
552d21db0 85 14 0 42437408 0 /dev/md/rdsk/d168
552d21ec8 86 14 0 45291692 0 /dev/md/rdsk/d169
552d28028 87 14 0 50331716 0 /dev/md/rdsk/d170
552d33c98 171 19 0 3145827 0 /dev/md/rdsk/d256
552d33db0 172 19 0 8186000 0 /dev/md/rdsk/d257
552d33ec8 173 19 0 11040284 0 /dev/md/rdsk/d258
552d34028 174 19 0 13894568 0 /dev/md/rdsk/d259
552d34140 175 19 0 16748852 0 /dev/md/rdsk/d260
552d34258 176 19 0 19603136 0 /dev/md/rdsk/d261
552d34370 177 19 0 22457420 0 /dev/md/rdsk/d262
552d34488 178 19 0 25311704 0 /dev/md/rdsk/d263
552d345a0 179 19 0 28165988 0 /dev/md/rdsk/d264
552d346b8 180 19 0 31020272 0 /dev/md/rdsk/d265
552d347d0 181 19 0 33874556 0 /dev/md/rdsk/d266
552d348e8 182 19 0 36728840 0 /dev/md/rdsk/d267
552d34a00 183 19 0 39583124 0 /dev/md/rdsk/d268
552d34b18 184 19 0 42437408 0 /dev/md/rdsk/d269
552d34c30 185 19 0 45291692 0 /dev/md/rdsk/d270
552d34d48 186 19 0 50331716 0 /dev/md/rdsk/d271
552d3f838 254 23 0 1769638 1775224 /opt/informix/dbs/chunk_tempdbs1_01.dbs
552d3f950 255 24 0 1635322 1640891 /opt/informix/dbs/chunk_tempdbs2_01.dbs
552d3fa68 256 25 0 1742758 1748340 /opt/informix/dbs/chunk_tempdbs3_01.dbs
552d44028 261 26 0 0 161 /opt/informix/dbs/chunk_l_logdbs_02.dbs
552d445a0 266 27 0 3000249 0 /dev/md/rdsk/d339
552d446b8 267 27 0 3000248 0 /dev/md/rdsk/d340
552d447d0 268 27 0 3000248 0 /dev/md/rdsk/d341
552d448e8 269 27 0 3000248 0 /dev/md/rdsk/d342
552d44a00 270 27 0 3000248 0 /dev/md/rdsk/d343
552d44b18 271 27 0 3000248 0 /dev/md/rdsk/d344
552d44c30 272 27 0 3000248 0 /dev/md/rdsk/d345
552d44d48 273 27 0 3000248 0 /dev/md/rdsk/d346
552d44e60 274 27 0 3000248 0 /dev/md/rdsk/d347
552d44f78 275 27 0 3000248 0 /dev/md/rdsk/d348
552d45090 276 27 0 622275 0 /dev/md/rdsk/d349
552d45720 282 28 0 3000249 0 /dev/md/rdsk/d355
552d45838 283 28 0 3000248 0 /dev/md/rdsk/d356
552d45950 284 28 0 3000248 0 /dev/md/rdsk/d357
552d45a68 285 28 0 3000248 0 /dev/md/rdsk/d358
552d45b80 286 28 0 3000248 0 /dev/md/rdsk/d359
552d45c98 287 28 0 3000248 0 /dev/md/rdsk/d360
552d45db0 288 28 0 3000248 0 /dev/md/rdsk/d361
552d45ec8 289 28 0 3000248 0 /dev/md/rdsk/d362
552d46028 290 28 0 1920944 0 /dev/md/rdsk/d363
552d468e8 298 13 0 0 1 /dev/md/rdsk/d371
552d46a00 299 13 0 0 1 /dev/md/rdsk/d372
552d46b18 300 13 0 0 1 /dev/md/rdsk/d373
552d46c30 301 13 0 0 1 /dev/md/rdsk/d374
552d46d48 302 13 0 0 1 /dev/md/rdsk/d375
552d46e60 303 13 0 0 1 /dev/md/rdsk/d376
552d59b80 373 33 0 9 51922 /dev/md/rdsk/d446
552d59c98 374 33 0 119 475757 /dev/md/rdsk/d447
392 active, 2047 maximum
================================================================

пространства 14, 19 это фрагменты по 16 чанков, заполненные полностью.
пространства 27, 29 это фрагмены заполненные примерно напополоам
пространства 3, 23-25 - темповые.
основной ввод вывод это чтение полных фрагментов. наблюдение iostat это полностью подтвердило.

За подсказки спасибо, все варианты попробую. Но мне кажется причина все же в другом. Очень похоже что количество чанков с данными играет основную роль т.к. фрагменты имеющие 16 чанков с данными сканились намного больше, чем те в которых данных меньше.
Надо попробовать все варианты. Если подсказки по тюнингу PDQ не помогут надо будет пробовать таблицу перегружать в большее количество фрагментов и переиндексировать.

vasilis,

спасибо, будем попробовать.

Всем спасиобо за наводки!

Окончательно удалось победить сырость после того как были определены еще переменные окружения

PDQPRIORITY=100
PSORT_DBTEMP= каталог на файловой системе

скорость чтения с дискового массива возросла в пике до почти 200 метров в секунду,
а загрузка цпу выростала в пике до 64% т.е. практически до 10 ядер из 16-и имеющихся.

АнатоЛойНу и сколько теперь минут на один индекс по сравнению с
автор256 минут и 264 минуты

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

Сегодня проводил такой эксперимент.
Взял таблицу (которую собираюсь фрагментированть на каникулах) размер 23 гига с индексами, примерно 78 млн записей. Загрузил ее в 6 фрагментов.
До настройки PDQ один индекс строился в районе часа, после настройки все 11 индексов были построены за 34 минуты. Так что PDQ работает как положено.

С моей самой большой таблицей не так все хорошо.
Пока наблюдаю следующее:
при запуске create index 4 фрагмента сканятся одновременно в 4 руки.
Незаполненные 2 фрагмента были просканены один раз. Заполненные 2 фрагмента (16 чанков по 2 гига) сканятся очень долго с повторным чтением чанков. Такое ощущение, что есть какая то магическая граница, количество чанков в фрагменте больше которой приводит к очень длительному проходу фрагмента. Буду экспериментировать дальше, проблема только одна - потртребуется очень много времени на перевыгрузку большой таблицы в большее количество фрагментов.

АнатоЛойНу и сколько теперь минут на один индекс по сравнению с
автор256 минут и 264 минуты

там где было 256 минут стало 56 минут. Тоже неплохо.

cprАнатоЛойНу и сколько теперь минут на один индекс по сравнению с
автор256 минут и 264 минуты

там где было 256 минут стало 56 минут. Тоже неплохо.

Как я и предполагал, после загрузки таблицы в 10 фрагментов (в каждом фрагменте получилось 5 с копейками чанков по 2 гига) один индекс построился за 10минут 34 секунды.
Итого операция ускорилась в 23 раза :-)

cpr,

И все же интересно чем объясняется такая разница во времени по созданию индекса?
В одном случае таблица находилась в 4-х фрагментах 2 по 16 чанков 3 по примено 8 чанков.
В другом случае таблица была перевыгружена в 10 фрагментов, данные соответственно равномерно легли во все фрагменты.
Данные естественно одни и те же.
Вопрос сугубо практический т.к. таблица очень активно растет.
До сих пор у меня была простая стратегия: по мере заполнения текущих фрагментов подсоединять по два максимального для 7.31 размера т.е. по 32 Гига.

onstat-,

система практически 24x7x365

таблица фрагментирована по round robin. детачить фрагменты в архив мне не грозит.

vasiliscprИ все же интересно чем объясняется такая разница во времени по созданию индекса?
В одном случае таблица находилась в 4-х фрагментах 2 по 16 чанков 3 по примено 8 чанков.
В другом случае таблица была перевыгружена в 10 фрагментов, данные соответственно равномерно легли во все фрагменты.
Думаю, что основное ускорение получено за счет параметров PDQ и увеличения параллельности при основных времяпотребляющих операций (сканирование и сортировка).

Основное время это именно сканирование, тут у меня вопросов нет.
В том почему в больших фрагментах сканирование происходло много кратно. Так первый чанк сканился один раз, второй чанк два раза, третий -три и т.д. Таким образом два больших фрагмента сканились многократно, что и составило основное время.
При большем количестве фрагменто и соответственно меньших их размерах чанки сканились в каждом фрагменте последовательно один раз. Все фрагменты сканились параллельно, суммарное количество чтений намного меньше.
Вопрос именно почему так происходит, действительно ли есть связь с количеством чанков в фрагменте?

vasilis
Думаю, да. Связь есть, но если уточнить, то не с кол-вом чанков, а с общим объемом информации в фрагменте. Ведь сканируя фрагмент считанную информацию надо куда то положить. а затем еще и отсортировать, а потом еще и отсортированные куски слить в одно целое. Поетому за один раз данный объем работы было трудно выполнить. Пришлось делать в несколько проходов. А почему некоторые чанки многократно читались ? Думаю, что еще причиной был и round robin (или недостаток алгоритма :)


Все логично, знать бы это магическое число чанков или записей :-)

Что касается round robin, то думаю что дело не в нем.