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, я попробую аналоги для соляры подобрать