Запрос таблицы Oracle с высокой степенью параллелизма приводит к полному сканированию таблицы

Question

Ну, заголовок описывает то, с чем я недавно столкнулся при работе с базой данных Oracle.

Вот немного фона:

• Таблица, о которой идет речь, разбита хешем на 4 раздела.
• Параллельная степень таблицы 4.
• Ключ хеша равен PK.
• В таблице довольно много строк, около 200 млн.
• Индекс PK также разделен (локальный раздел).
• Параллельная степень индекса равна 1.

Хорошо, теперь у меня запрос странно себя ведет, когда я изменяю параллельную степень таблицы.

Если степень таблицы равна 4, это приводит к полному сканированию таблицы (согласованное параллельное полное сканирование таблицы), как показано в плане объяснения. На выполнение запроса уходит 30 минут или более.

Если уровень таблицы равен 1-3, он правильно использует индекс PK (сканирование диапазона, однопоточный) и возвращает результат через 20 секунд.

Если установить для степени таблицы и степени индекса значение 4, будет выполнено полное сканирование таблицы (такой же результат, как в первом сценарии выше).

Это поведение, однако, не происходит в другой базе данных, где у меня есть почти идентичный клон таблицы. Разница лишь в количестве записей. Таблица в другой базе данных имеет немного меньший размер (минус 1-2 миллиона). Меньшая таблица, также со степенью 4, не выполняет полное сканирование таблицы с тем же запросом.

Я потратил некоторое время на поиск в Google и нашел следующее о параллельном запросе:

Из официального документа Oracle

Высокая степень параллельности таблицы смещает оптимизатор к полному сканированию таблицы при сканировании диапазона. Изучите столбец DEGREE в ALL_TABLES для таблицы, чтобы определить степень параллелизма.

и от http://www.toadworld.com/Portals/0/GuyH/Articles/Oracle%20Parallel%20SQL%20Part%201.pdf Параллельный запрос должен применяться, когда

SQL выполняет как минимум одну полную проверку таблицы, индекса или раздела

А с AskTom.com

Параллельный запрос подходит для определенного класса больших задач: очень большие проблемы у которого нет другого решения. Параллельный запрос - мой последний путь решения проблема производительности; это никогда не мой первый образ действий.

Кажется, что параллельное выполнение предназначено для обработки очень большого объема данных, когда не существует другого лучшего решения. Он пытается повысить производительность, выполняя параллельные процессы, при этом каждый ЦП (процесс) выделяется для работы с отдельной частью данных (диапазон блоков, разделы таблиц или индексные разделы). Так что он не предназначен для ускорения общего запроса или запроса, который не покрывает достаточную часть всей таблицы.

Верно ли мое понимание того, что параллель не должна использоваться в качестве средства для ускорения общего запроса?

Если да, значит ли это, что лучше всего отключать параллельное (степень как 0) и разрешать для конкретного запроса / операции с помощью подсказки или параллельного предложения?

И в дополнение ко всему, какой должна быть лучшая практика для настройки PARALLEL? Если то, что я хочу сделать, это обеспечить лучшую производительность чтения с помощью многопоточности, то какими должны быть настройки?

Здесь много вопросов. Большое спасибо заранее.

Answer 1

Для вашего конкретного запроса параллелизм, вероятно, не самая большая проблема.Новая оценочная стоимость и время запроса будут очень приблизительно равны первоначальной стоимости, деленной на степень параллелизма.Оптимизатор может ошибаться здесь;например, если у вас есть только один жесткий диск, тогда новый план, скорее всего, не будет быстрее.Но ошибка оценки в 4 раза не должна приводить к разнице в производительности в 90 раз.Это заставляет меня поверить, что ваш план уже был на грани провала, и это просто перевернуло его.Насколько близки приблизительные и фактические значения вашего непараллельного плана?Что бы ни вызывало эти различия, это может быть причиной большей части вашей проблемы.

На ваши более общие вопросы нет простых ответов.Есть несколько десятков вещей, которые вы, возможно, должны рассмотреть для параллелизма, только вы можете знать, какие из них будут применяться к вашей ситуации.Лучше всего прекратить попытки Google это и вместо этого прочитать руководство.Хорошее место для начала - глава Использование параллельного выполнения в Руководстве по хранилищу данных.

Answer 2

Степень отношения или таблицы в SQL означает количество атрибутов в отношении. Например: если отношение в SQL имеет три строки и четыре столбца, его степень в четыре. Просто мы можем сказать, что количество столбцов отношения называется его степенью.

Answer 3

Как правило, я согласен с Томом. Наша основная базовая таблица содержит около 240 миллионов строк плюс другие индексы, где от 10 до 1000 операций вставки, удаления и обновления выполняются 24 часа в сутки. Обычно мы получаем информацию из нее за доли секунды, а затем, если нам нужно много информации, перейдем к полному сканированию и справимся с 2,5 часами, которые требуются. В ответ на некоторые из ваших вопросов, если вы собираетесь выполнять более крупные запросы, чем маленькие, переходите к разделу. Если нет, то не надо.