2010-07-15 3 views
-1

Я выполняю запрос в oracle с помощью CTE. Когда я выполнить запрос он отлично работает в операторе отбора, но когда я использую вставки заявление она занимает достаточно времени, чтобы помочь execute.Any здесь кодCTE With Insert В Oracle

INSERT INTO port_weeklydailypricesTest (co_code,start_dtm,end_dtm) 
    SELECT * FROM 
     (
      WITH CTE(co_code, start_dtm, end_dtm) AS 
      (
       SELECT co_code              , 
       CAST(NEXT_DAY(MIN(dlyprice_date),'FRIDAY')-6 AS DATE) start_dtm , 
       CAST(NEXT_DAY(MIN(dlyprice_date),'FRIDAY') AS DATE)  end_dtm 
       FROM feed_dlyprice 
       GROUP BY co_code 
       UNION ALL 
       SELECT co_code  , 
       CAST(TO_CHAR(end_dtm + INTERVAL '1' DAY,'DD-MON-YYYY') AS DATE), 
       CAST(TO_CHAR(end_dtm + INTERVAL '7' DAY,'DD-MON-YYYY') AS DATE) 
       FROM CTE 
       WHERE CAST(end_dtm AS DATE) <= TO_CHAR(TO_DATE(SYSDATE+1,'DD-MON-YYYY')) 
      ) 
      SELECT co_code,start_dtm,end_dtm 
      FROM CTE 
     ); 
+1

Пожалуйста, используйте приведенный формат кода (на этот раз я надену его вам). –

+0

Зачем вставлять записи вообще - Почему бы не использовать представление? –

ответ

2

Если, как вы говорите, производительность SELECT, сама по себе удовлетворительна, проблема должна лежать в части INSERT утверждения.

Есть целый ряд вещей, которые могут вызвать вставку бежать медленно:

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

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

+1

Одно из предостережений: SELECT может быть оптимизирован для FIRST_ROWS (в зависимости от цели оптимизатора базы данных). INSERT всегда оптимизирован для ALL_ROWS, потому что это одно исполнение. Таким образом, вы можете проверить оба утверждения с помощью EXPLAIN PLAN и посмотреть, есть ли разница –