Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Создание индекса и проблемы с TEMP  [new]
Деев И.
Member

Откуда: отсюда
Сообщений: 783
Добрый день!

Есть здоровенные таблицы, после массированного обновления которых необходимо будет пересоздать индексы. (Не UNIQUE-индексы предварительно отключаются или сносятся.) Причем заранее неизвестно, какими точно будут параметры файла инициализации, размеры временного пространства.

Как рассчитать, при каких параметрах TEMP индекс не может быть создан, если на диске 100%-но есть необходимое пространство для данных индекса в пользовательском пространстве, используется параметр PGA_AGREGATE_TARGET или для сессии устанавливается SORT_AREA_SIZE = 100M для сессии. Что-то в доке искал, не нашел - сколько должно быть свободного места в TEMP минимум, исходя из размера индекса? Есть ли такие ограничения?

Интересно еще, почему REBUILD не проходит а CREATE проходит по тому же самому индексу. Какие-то разные у них алгоритмы, что ли... REBUILD TEMP активно использует, судя по всему ( выдается ошибка в нехватке свободного места в TEMP). В документации утверждается, что REBUILD значительно быстрее проходит - но в моих экспериментах оказалось, что примерно одинаковое время проходит (Oracle 10.2.0.3.0).

Пока не исследовал сам дотошно - времени не хватает. Спасибо, если укажете на ссылки в доке.
6 мар 07, 10:48    [3867995]     Ответить | Цитировать Сообщить модератору
 Re: Создание индекса и проблемы с TEMP  [new]
StarWoofy
Member

Откуда: Moscow
Сообщений: 1005
Деев И.
Добрый день!
Причем заранее неизвестно, какими точно будут параметры файла инициализации, размеры временного пространства.

Караул.
Изначально ставь из расчета на прогнозируемый размер.

Деев И.

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

Не менее чем потребуется для сортировки.

Деев И.

Интересно еще, почему REBUILD не проходит а CREATE проходит по тому же самому индексу. Какие-то разные у них алгоритмы, что ли...

Механизм.

Деев И.

В документации утверждается, что REBUILD значительно быстрее проходит - но в моих экспериментах оказалось, что примерно одинаковое время проходит (Oracle 10.2.0.3.0).

У тебя неправильные условия эксперимента. ;)

Наибольшая ценность rebuild, imho в возможности rebuild online.
6 мар 07, 12:04    [3868716]     Ответить | Цитировать Сообщить модератору
 Re: Создание индекса и проблемы с TEMP  [new]
Деев И.
Member

Откуда: отсюда
Сообщений: 783
Не менее чем потребуется для сортировки.
Вот я и хочу оценить объем - только не знаю, как точно это сделать. Потребуется ведь не все пространство, которое занимает индекс. А вот какую часть от этого объема необходимо обеспечить в TEMP - требуется посчитать. Вопрос - как?
6 мар 07, 12:59    [3869222]     Ответить | Цитировать Сообщить модератору
 Re: Создание индекса и проблемы с TEMP  [new]
Dimka9
Member

Откуда: Владивосток
Сообщений: 1851
считай 2Х
6 мар 07, 13:01    [3869231]     Ответить | Цитировать Сообщить модератору
 Re: Создание индекса и проблемы с TEMP  [new]
SQL*Plus
Member

Откуда: Россия, Москва
Сообщений: 8131
Деев И.
Интересно еще, почему REBUILD не проходит а CREATE проходит по тому же самому индексу. Какие-то разные у них алгоритмы, что ли... REBUILD TEMP активно использует, судя по всему ( выдается ошибка в нехватке свободного места в TEMP). В документации утверждается, что REBUILD значительно быстрее проходит - но в моих экспериментах оказалось, что примерно одинаковое время проходит (Oracle 10.2.0.3.0).
REBUILD не строит индекс заново, а использует данные из старого индекса.
1. Построить новый индекс, используя данные старого
2. Удалить старый индекс.
3. Перевести сегменты построенного нового индекса из состояния TEMPORARY в INDEX.
То есть какое-то время место занимают и старый, и новый индекс.
6 мар 07, 13:12    [3869346]     Ответить | Цитировать Сообщить модератору
 Re: Создание индекса и проблемы с TEMP  [new]
Деев И.
Member

Откуда: отсюда
Сообщений: 783
Попробовал построить индекс по всем полям таблицы, которая занимала больше, чем весь TEMP на тот момент. Результат - TEMP расширился до объема, который стал занимать созданный индекс. Т.е. место в TEMP нужно готовить столько, сколько потребуется для самого большого индекса.
(правда, можно прогнозировать уменьшение объема при перестроении).
Матчасть надо повторять заново...
6 мар 07, 14:12    [3869849]     Ответить | Цитировать Сообщить модератору
 Re: Создание индекса и проблемы с TEMP  [new]
mcureenab
Member

Откуда: Murmansk
Сообщений: 5928
Деев И.
Пока не исследовал сам дотошно - времени не хватает. Спасибо, если укажете на ссылки в доке.


Предлагаю конкретизировать обсуждение. Нарисуй контрольный пример с ошибками выделения временного пространства. Полезно построить графики значений статистик сессии хотябы от времени, тогда можно будет понять что делает оракл и сколько ресурсов потребляет.
Возможно MetaLink ответ даст.

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

Подозреваю, что для создания индекса используется алгоритм сортировки слияния.

В первом приближении процесс я вижу так. Порция ключей с соответствующими ROWID загружается в область SORT_AREA_SIZE, подвергается внутренней сортировке, затем сбрасывается на диск во временное табличное пространство. Затем сортируется следующая порция и т.д. Затем полученные блоки отсортированных записей из временного пространства подвергаются слиянию и результат сохраняются в сегмент индекса. Исходя из такой модели нужно оценить количество ключей с rowid которые помещаются в один блок SORT_AREA_SIZE, количество таких блоков, наконец размер потребного временного сегмента.
Думаю, что блоков SORT_AREA_SIZE нужно примерно столько же, сколько будет занимать рузультирующий индекс, поскольку дополнительных данных скорее всего не нужно и ключи не дублируются по крайней мере до тех пор, пока размер SORT_AREA_SIZE позволяет слить минимум по одной записи из всех временных блоков SORT_AREA_SIZE. Если это не так, то придётся сливать только часть блоков, сохранять результат во временное пространстро, а затем выполнять слияние меньшего числа более крупных блоков и т.д., пока не удасться слить все временные блоки за один пролход. В этом случае за счёт дублирования данных может потребоваться вдвое больше временного пространства.

Наконец можно обратиться к фиче
Oracle Database Application Developer's Guide - Fundamentals 10g Release 2 (10.2) Part No. B14251-01
resumable storage allocation
6 мар 07, 14:58    [3870272]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить