Сам многим рекомендовал к использованию. Но как оказалось пригоден от только на базах для домохозяек. Чуть-чуть более-менее приличную таблицу нужно переносить между dbspace-ами только HPL-ем.
Убил 8 часов времени на трансформацию 220млн записей + 4 индекса (22Гб). +4 часа на rollback с рассказом, что места под индекс нет :-(.

Что было сделано:
А. База переведан в NON log.
Б. Места в новом dbspace-e с 40Гб запасом.
В. 4 temp dbspace по 2Гб (как оказалось маловато).

Чего не было сделано:
А. PSORT_NPROCS=cpu*2
Б. PSORT_DBTEMP=в каталоги на разных дисках, где места полно
В. PDQPRIORITY=100
Г. дропнуть индексы перед alter fragment и восстановить их после. Правда в этом случае я не вижу, чем "alter fragment" будет удобнее, чем HPL.

Мне это тоже интересно, особенно красиво выглядил откат, который начался сам, при этом сессия имела нулевые коды ошибок. То что идет откат, я осознал только по букве R в 3-й позиции onstat -u.

19:25:57 WARNING: Not enough temp space for parallel index build.
Space required = 4336318 pages; space available = 4080740 pages.
Partial index build started.
19:30:42 Fuzzy Checkpoint Completed: duration was 5 seconds, 1 buffers not flushed.
19:30:42 Checkpoint loguniq 429470, logpos 0x1007c0
...
20:50:31 Checkpoint Completed: duration was 132 seconds.
20:50:31 Checkpoint loguniq 429470, logpos 0x1be33c

20:51:15 WARNING: Not enough temp space for parallel index build.
Space required = 4336318 pages; space available = 4074340 pages.
Partial index build started.
20:55:57 Checkpoint Completed: duration was 26 seconds.
20:55:57 Checkpoint loguniq 429470, logpos 0x1c4018
...
21:41:32 Checkpoint Completed: duration was 105 seconds.
21:41:32 Checkpoint loguniq 429470, logpos 0x1ce2f0

21:45:35 WARNING: Not enough temp space for parallel index build.
Space required = 4336318 pages; space available = 4074340 pages.
Partial index build started.
21:49:06 Checkpoint Completed: duration was 154 seconds.
21:49:06 Checkpoint loguniq 429470, logpos 0x1d1018

...
До этого времени во всю шло занятие новых чанков и активная в них запись, с еще более активным использованием TEMP-ов. В процессе двух длительных чекпоинтов шло активное чтение из новых чанков, с очень небольшим расходованием буфферов (не более 200 сотен dirty) и совсем малой записью (меньше десятка страниц на чанк).

23:32:58 Checkpoint Completed: duration was 0 seconds.
23:32:58 Checkpoint loguniq 429471, logpos 0x4e018


Mon Jun 13 01:35:22 2005

01:35:22 Checkpoint Completed: duration was 7043 seconds.
01:35:22 Checkpoint loguniq 429471, logpos 0x55034

02:14:04 Checkpoint Completed: duration was 2022 seconds.
02:14:04 Checkpoint loguniq 429471, logpos 0x561f8

02:19:03 Checkpoint Completed: duration was 0 seconds.
02:19:03 Checkpoint loguniq 429471, logpos 0x59018

Вот в этот момент и было выдано сессией "Cannot add index, not enough space".

valisisPDQPRIORITY=100 сильно не помог бы
У меня в некоторых местах прикладной софтины лет n назад были баги с PDQ, поэтому в onconfig-e я жестко поставил MAX_PDQPRIORITY 0 .

valisis
Может вся проблема при ALTER FRAGMENT в том, что 4-е индекса строятся одновременно и место в темпах тебе нужно было на все индексы, которые ты мог заранее и просчитать ?

Судя по записям в лог-е (3 Warning-a) они одновременно не строились. Просто 8Гб ему не хватило на построение индекса. Сейчас все осталось по старому, сама таблица - выделенно 6.6 Гб. Индексы 5.4, 4.2, 3.6, 2.8Гб. Итого 22.4Гб. В принципе екстенты выделяются большими кусками, поэтому свободного места гуляет достаточно много (считать в лом, но думаю, что в пределах 4-8Гб). В момент наибольшего съедения новых чанков, было полностью сожрано 7 чанков, т.е. 14Гб.

Дошло до меня где места нехватило. ALTER FRAGMENT suxx^2.
Таблица фрагментирована в 5 dbscpac-ах.
Один индекс живет вместе с ней, размазанный также.
Два других в индексном дбспейсе.
Один (так уж получилось) в основном dbspace-е базы (индекс не был задан явно).
Все индексы детаччед.
Свободного места во всех 8 dbspac-ах менее 0.2%.
Таблица переезжала в новый абсолютно пустой dbspace, в котором места просто завались.
Но индексы то я не переносил (хотя планировал), поэтому эта зараза их пыталась ребилдить в тех самых спейсах. Итак, для меня однозначно, дабы не строить индексы 2 раза, нужно:
1. drop index.
2. alter или HPL таблицу.
3. create index.

vasilisНе пойму, в чем вина ALTER FRAGMENT ...
В том, что если у таблицы есть деттачед индексы их надо перестраивать 2 раза. Одним махом перенести все таблицу и индексы в новый dbspac-e низзя.
Ну конечно на suxx^2 это не тянет, если знать, что зачем и как, то использовать его можно. Хотя HPL все равно круче :-).

Имелось ввиду, если индексы тоже необходимо переносить в другой спейс.
Насчет HPL:
Daugava 2002
Другая табличка, на 70 млн записей (2.8Гб), вместо 3-х
часов грузилась 8 минут+ 55 минут. на построение index-а по 3 integer
полям.

(c) Google

Расчеты показали, что время переноса данных по сравнению с необходимостью перестройки 4 индексов и 3 foreign key констрейнтов пренебрежимо мало.
Благодаря Троице, имеем 3 выходных, посему я обошелся без HPL, да и без Alter Fragment тоже. Банально создал новую таблицу туда перенес insert/select-ом данные. Данные переехали всего-то за полтора часа.
С индексами я решил немного поэксперементировать на предмет того, куда распределить память в SHMVIRTSIZE,DS_TOTAL_MEMORY,BUFFERS. К единому мнению так и не пришел. Память похоже нужна всем :-). Кстати, в темп каталогах за время построения индексов я ни разу не видел файлов больше, чем на 4Гб, а при прошлой попытке при построение в tempdbspac-ах не хватило 8Гб. PSORT_DBTEMP рулит.
Сейчас достраиваю констрейнты, но что-то меня смущает. Ради того, чтобы индекс оказался в нужном мне дбспейсе, его надо создать до констрейнта. А при построении констрейнта опять сканируются все данные :-(.

vasilis
Daugava
PSORT_DBTEMP рулит.

А куда ты его направлял ? Только на свои темповые ДБ-пространства или на каталоги файловой системы ? Второе, вроде, существенно быстрее при сортировках


У меня 4 диска по 18Гб на внутреннем SCSI контролере, не в RAID-e. По 2Гб там выделено под tempdbspace, ну и по 16Гб файловой системы. Памятуя про рассказы, что сортировка в файловой системе выполняется быстрее, ну плюс еще и 8Гб места оказалось прошлый раз мало, PSORT_DBTEMP я указал на файловую систему.

Вообщем, имея 3 дня выходных, я смог все (+ 12 часовой update statistics), сделать без напряга, как это забарывают люди на БД 7x24 я себе не представляю.

Я в итоге проверил оба варианта. Но первый не смог отработать до конца :-).
Кроме того, помнится Воронцов или Нечаев, а может и сам Шульженко :-) несколько лет назад сие уже делали. Бекапный сервер у меня к сожалению не имеет таких запасов дисков, играться с рабочим еще раз желания особого нет.

update statistics у меня можно критиковать сколько угодно, но мне оно к сожалению мало поможет.
В течение 3-х лет я делаю update statistics 5 раз в день (длительностью порядка 30-50 секунд). На это время останавливаются "сервера приложений", которые активно меняют БД, но не разгоняются юзера. Вся проблема в специфике моей БД:
А. Таблицы, с которыми идет практически OLTP работа (правда роботами) еженочно переливаются в архивные и пересоздаются.
Б. Изменения за день очень серьезные, при этом основной пик приходится на 16-18 часов.
В. Для быстроты данные updates делаются согласно рекомендациям лучших собаководов, не помню с кого дрался скрипт, но откуда с IIUG (но не Art Kagel dostats, а что-то другое).
Г. Основное время дневных update statistics - это процедуры. У меня все на них построенно. Можно конечно выбраться только те, которые меня волнуют, но все равно их будет слишком много, да и минута простоя меня вполне устраивает (юзера ее не замечают).

К архивным таблицам update statistics прикручивать я не стал, их не так часто мучают, время доступа к ним не критично и как бы "работает не трогай".
Сейчас после пересоздания собственно таблицы связей между всеми архивами мне пришлось все таки именно для этой таблицы статистику пересобрать (одна из процедур решила, что лучшим подходом будет FULL SCAN по 223 млн. записей при наличии 4-х индексов). Учитывая, что она состоит из 4 integer-ов , datetime и char(1). В запросах не учитывается только datetime, поэтому на данный overhead я забил и дал update statistics high ;-).