Oracle оптимизация схемы для 1: 0..1 отношений

У меня есть две таблицы, которые выглядят следующим образом:Oracle оптимизация схемы для 1: 0..1 отношений

table A: FieldID NUMBER (PK), other non-relevant fields 
table B: FieldID NUMBER (PK/FK), other non-relevant fields

Таблицы отображающую 1: отношения 0..1. В частности, после того, как новая строка будет вставлена в таблицу A, в какой-то момент в будущей таблице B будут заполнены дополнительные данные.

Этот проект изначально был предпочтен уникальной расширенной таблице, поэтому везде, где есть поля, не допускающие обнуления (поскольку нет возможности предсказать, когда будет заполняться часть данных «B»).

Теперь ... Выполнение выбора соединения из A и B удивительно ужасно. Мы говорим о нескольких 100k строках в обеих таблицах, и все же внутреннее соединение simpe занимает огромное количество времени для завершения.

Помимо перемещения полей из B в A (вещь, которую я бы предпочел не делать, чтобы избежать дополнительных «нулевых» проверок), как я могу улучшить свои выступления?

источник

2013-02-12 Andrea

Определить «ужасный», в частности это для одиночных запросов PK или ПОЛНОГО ТАБЛИЦЫ СКАНИРОВАНИЯ? –

Привет, это для поиска PK. Если я сделаю (например), выберите * из A, B, где A.FieldID = B.FieldID и rownum <= 10, для завершения требуется ~ 20 секунд. – Andrea

Пожалуйста, опубликуйте план объяснения. [Отслеживание запроса] (http://docs.oracle.com/cd/E11882_01/server.112/e16638/sqltrace.htm#PFGRF01020) также может помочь понять, почему требуется столько времени. –

ли ваш присоединиться так: SELECT /*+GATHER_PLAN_STATISTICS*/ ... FROM .. WHERE ...; А потом, покажите нам выход: SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(FORMAT=>'ALLSTATS LAST'));

Это покажет план выполнения с ассоциированной статистикой, по оценкам, и на самом деле найден при выполнении запроса.

источник

2013-02-12 10:24:49 Plouf

Привет, спасибо за ваше внимание. У меня нет доступа к этой функциональности, но я попрошу мою dba предоставить ее мне. – Andrea

Будем надеяться, что вы его получите. Доступ к планам выполнения и такая информация обратной связи по мощности важны для анализа производительности запросов. –

@ Andrea Скажите ему, что какой-то случайный парень из Интернета спросил вас. ;) Более серьезно, как сказал @DavidAlridge, это важно, если вы хотите указать на реальную проблему. Или вы можете использовать 'set autotrace' в sql * plus, это лучше, чем ничего, но вы не получаете разницу между ожидаемыми и фактическими строками. – Plouf

Если вы равны для двух таблиц для всех строк, вы должны получить максимальную производительность от хеш-соединения. Если меньший набор соединенных данных может быть кэширован, то стоимость будет всего лишь чуть больше, чем полное сканирование обеих таблиц, что примерно так же эффективно, как вы можете получить.

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

источник

2013-02-12 10:35:14

Oracle оптимизация схемы для 1: 0..1 отношений

ответ

Смежные вопросы