данные оракула из нескольких таблиц - PullRequest
0 голосов
/ 10 ноября 2011

* ОБНОВЛЕНИЕ

Я попытаюсь объяснить ситуацию еще раз: у меня есть один datamart, который содержит всех клиентов и исходные платежи, а также статус и фискальныйпериод в формате ггггммдд.статус должен быть сопоставлен со статусом в другой таблице, чтобы я получал только те имена клиентов и финансовые периоды, в которых status_datamart = status_table и status_table in ('неактивно', 'активно').теперь эти данные вставляются в таблицу с именем 'inv', которая содержит: PORTFOLIO_INV, CLIENT_INV, ACCT_TYPE_INV, PERIOD, DESK, STATUS, PRIOR_OCA_CALC, PRINCIPAL, CUR_BAL

второй платеж данных снова содержит клиента, fiscal_period,и нетто) тип транзакции.один запрос используется для выборки только тех записей из этого datamart, где тип txn сопоставляется с другой таблицей, а категория txn - это «брутто».второй запрос имеет те же фильтры, что и выше, только категория txn теперь заменена на 'net'.

Причина, по которой 2 запроса получают значение общего и чистого значения, заключается в том, что данные имеют следующий формат:

client1 |финансовый период |статус |брутто клиент2 |финансовый период |статус |брутто клиент1 |финансовый период |статус |чистый клиент3 |финансовый период |статус |брутто

, поэтому я использую запрос один для хранения брутто в одной таблице 'pmt': PORTFOLIO_PMT, CLIENT_PMT, ACCT_TYPE_PMT, PERIOD_PMT, DETAIL_TRANSACTION_TYPE, DETAIL_DESK_AT_PMT * DET_AT_T_T_T_0_T_0_0_TUST_TUST_TUSTTв другую таблицу «net»: PORTFOLIO_NET, CLIENT_NET, ACCT_TYPE_NET, PERIOD_NET, DETAIL_TRANSACTION_TYPE_NET, DETAIL_DESK_AT_PMT_NET, DETAIL_STATUS_AT_NET, PRIOR_OCA_Cнадеюсь, это поможет ...


Я пишу запрос, который будет извлекать имя клиента, финансовый год и основную сумму из таблицы T1, сумму (текущие платежи) из другой таблицы T2 (для того же клиентаи тот же финансовый период) и сумма (нетто) из третьей таблицы (для того же клиента, что и в T1 и T2).выполнение запроса заняло 2132,78 секунды для примерно 3400 записей в T1, 939 в T2 и 103 в T3.

Есть ли способ, которым я НЕ могу использовать объединения и просто быстро получать нужные данные?Общее количество записей в каждой таблице будет различаться в зависимости от основной суммы и количества полученных платежей.

Ответы [ 2 ]

0 голосов
/ 10 ноября 2011

2132 секунд для томов данных, которые вы предлагаете, по-видимому, указывают на то, что критерии объединения могут быть неточными, и вы можете увидеть MERGE JOIN CARTESIAN в вашем плане выполнения.Если вам нужно отследить ваш запрос и опубликовать вывод tkprof или просто объяснить SQL и опубликовать план, это будет полезно при диагностике проблемы.

0 голосов
/ 10 ноября 2011

Вы пытались проанализировать, почему ваш запрос медленный?

Похоже, вам не нужно использовать объединения, а скорее объединение всех трех запросов.Похоже на независимую функциональность.

Вам нужно использовать объединения, когда у вас есть таблица с именем contact и другая таблица с именем contact_address, где есть связанная информация с основной таблицей.

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

...