Хочется разобраться в этом. Когда делаешь ребилд большого индекса - конечно хочется это сделать побыстрее, поэтому ставишь при ребилде степень побольше.

Но если делать
alter index [index_name] rebuild parallel [N];

то после ребилда degree у индекса изменится - что повлияет на степень выполнения, планы запросов и некоторые другие детали.
Таким образом напрашивается вывод: сделать ребилд с большой степенью, а потом проапдейтить метаданные для индекса в правильные:

alter index [index_name] degree [M];

Но вопрос который меня интересует: если делать параллельный ребилд с большой степенью - не создается ли индекс немного по-другому? Скажем, не будет ли у него N рутов у дерева ( я сейчас про B*tree индексы ) , не повлияет ли это на реальный кост запросов
по уникальным ключам? Есть наблюдение, что влияет, но хотелось бы поинтересоваться, может кто-то глубоко изучал этот вопрос или натыкался на статью об этом.

А где хранятся degree и prefix_length ( для компрессии ) для партиций индекса?
Потому что в dba_ind_partitions этой инфы нет.
Если я пересоздам партицию индекса в 32 потока - не аффектнет ли это планы, которые используют как раз эту партицию?
Вопросы, вопросы...
То же самое для компрессии - как узнать, сжата ли уже эта партиция или еще только предстоит ее сжать?

А, черт, я был неправ. Я почему-то считал что можно ребилднуть одну партицию индекса с COMPRESS.

Эта нота говорит что нельзя:

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=396291552743654&id=312843.1&_afrWindowMode=0&_adf.ctrl-state=wmewgytqh_4

Притом что в доке такой синтаксис есть!

https://docs.oracle.com/cd/E11882_01/server.112/e41084/statements_1010.htm

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

Вячеслав Любомудров, ну у меня индекс уже COMPRESS. Просто с опцией compress , скажем 5. А мне нужно изменить на compress 3.
И судя по всему единственный способ это сделать - это дропнуть индекс и создать его заново.

Т.е. prefix_length задается только на глобальном уровне, и даже нет способа его изменить.
В то время как отдельная партиция индекса может быть либо сжата ( и тогда она будет сжата с глобальным prefix_length), либо разжата.

Вячеслав ЛюбомудровТаки иметь разную длину префикса для разных секций -- достаточно редкая хотелка (а оптимальная должна вычисляться на этапе проектирования)

Ахаха. Ну, не вычислили те, кто это проектировал. Мне трудно их судить - у оракла примерно миллион опций при создании таблиц/индексов, реально нужно иметь очень большой опыт чтобы еще на этапе проектирования абсолютно все их выставить правильно. Поэтому оракл мог бы и сделать возможность менять их по-партиционно :)
Ладно, будем думать как перестроить 10-терабайтный первичный ключ на живой таблице.

Valergrad,

а так да, в 12c advanced compression насколько я понял автоматически вычислять эту степень и регулировать ее не только на уровне партиции, но и отдельного блока.

Nobody111Вячеслав Любомудров, хорошая идея.

Даже если прибиты, можно, думаю, переименовать новый в старый.

Это да. Но еще лишних 10 терабайт у нас нету ( да еще и в одном тейблспейсе).
Соответственно очень извращенный план который приходит в голову:

1. Создать ind2 ( с лишним полем 0 ) как unusable для всех партиций.
2. Далее по каждой партиции осуществлять следующую операцию: ребилдить по одной партиции ind2, после чего дропать ( т.е. делать эту же партицию unusable ) у ind. Таким образом, в любой момент для любой партиции будет хотя бы один рабочий индекс.
3. Когда ind2 будет построен целиком, нужно дропнуть Ind, и тут же создать его unusable.
4. После чего такой же цикл как в п.2 по перекидыванию партиций из ind2 в ind.

Это был бы отличный план... вот только поиск по dba_source в пакетах выдает 225 запросов в которых этот индекс захинтован. Да, у нас в компании распространен идиотизм хинтования запросов вместо решения реальных проблем. Это, разумеется, постоянно делает только хуже ( в 9 случаях из 10 я решаю перфоманс ишью просто удаляя все хинты из запроса ), и это всего лишь очередной такой случай.

xtenderValergrad2. Далее по каждой партиции осуществлять следующую операцию: ребилдить по одной партиции ind2, после чего дропать ( т.е. делать эту же партицию unusable ) у ind. Таким образом, в любой момент для любой партиции будет хотя бы один рабочий индекс.не поможет, если бинд используется для partition pruning. Так что только если используете литералы.

Боюсь я не понял мысль. Можете пояснить?