нужно оптимизировать код

Mapuo
Дата: 24.11.2008 09:10:23
ситуация следующая:
есть таблица, которая содержит около 1 500 000 записей.
есть кусок кода, который делает merge по нескольким полям по схеме:

1. заполняется временная кеш-таблица с нужными данными (тоже около 1 500 000 записей)
2. по кеш-таблице собираются статистики
3. далее происходит merge в основную таблицу на основе кэша
merge /*+parallel(t02,2) parallel(t01,2)*/
into table_01 t01
using table_02 t02
on (t02.field = t01.field)........
нужен совет - как можно ускорить данный процесс.
wurdu
Дата: 24.11.2008 09:16:54
Переименовать кеш-таблицу в таблицу, сделать из нее копию основной и сразу грузить туда данные какими они должны быть (direct path, nologging, parallel... на любителя). Дальше либо с помощью exchange partition, либо rename заменяем основную.
andreymx
Дата: 24.11.2008 09:23:24
это делается один раз или на постоянной основе? как часто?
Mapuo
Дата: 24.11.2008 09:31:01
wurdu,
так не пойдет. основная таблица - это что-то вроде справочника актуального на конец предыдущих скток. кусок кода обновляет несколько полей на ежедневной основе (другие поля тоже обновляются). значения этих полей могут как менятся так и не менятся + погут появится новые записи, поэтому используется merge.
Mapuo
Дата: 24.11.2008 09:35:44
andreymx,
делается на ежедневной основе, чтобы было понятнее - это таблица-справочник хранилица данных по клиентам. код обновляет несколько полей, информация в которых может как измениться так и остаться прежней.
wurdu
Дата: 24.11.2008 09:44:22
Mapuo
значения этих полей могут как менятся так и не менятся + погут появится новые записи, поэтому используется merge
Во второй таблице примерно столько же записей, сколько в основной. Это потому что большинство записей меняется или просто много добавляется?
Mapuo
Дата: 24.11.2008 10:01:07
wurdu,
изменяется как раз немного, большинство записей остаются неизменными. я уже думал, что можно уменьшить размер кеш-таблицы, но дело в том, что если при ее заполнении учитывать, только измененные и новые записи это скорее всего приведет к долгому заполнению кеш-таблицы.

основная таблица содержит инфу типа - клиент/тариф клиента на конец позавчерашних суток.
в кеш таблицу складывается инфа на конец вчерашних суток и потом merge.
wurdu
Дата: 24.11.2008 10:08:43
Mapuo
изменяется как раз немного, большинство записей остаются неизменными. я уже думал, что можно уменьшить размер кеш-таблицы, но дело в том, что если при ее заполнении учитывать, только измененные и новые записи это скорее всего приведет к долгому заполнению кеш-таблицы.
Если я правильно понял, обновляются записи, даже которые не должны обновляться? Если избавиться от этого, то во 2-ю таблицу не придется вставлять 1.5 млн записей, а потом не придется делать UPDATE 1.5 млн записей. Почему же кажется что ограничение выборки в запросе займет больше времени чем эти две DML-операции?
Mapuo
Дата: 24.11.2008 10:17:06
wurdu,
на счет бесполезного по сути апдейта - согласен.
на счет ограничения выборки - тут дело в том, что ограничение получается нетривиальным. хотя, в принципе, может получиться, что в суммарное время в итоге ократиться.
сейчас попробую протестировать - посмотрю, что получится.