https://imgflip.com/i/52l14s
http://www.nocoug.org/download/2012-11/NoCOUG_201211_Tim_Gorman_Data_Warehouse_Partitioning.pdf
You want to maximize the amount of work not being performed.
Do you really care about how much undo is being generated? No. You want the
data loaded. Quickly.
Stop focusing on making more room available for undo and minimize
generating undo.
The volume of redo being generated is likely causing other issues as well.
Apologies for replying to the wrong thread snippet.
Paul
On Sun, Mar 21, 2021, 12:49 Mladen Gogala <gogala.mladen@xxxxxxxxx> wrote:
This can be replaced by a PL/SQL selecting into an array, doing bulk
inserts and committing regularly. PL/SQL will not perform as well as the
SQL below but will probably perform good enough. There is a rather
infamous optimization of commit in a PL/SQL loop which will mitigate the
impact of a gazillion commits. As for the conjecture about indexes, it
is most likely correct. Direct insert uses the blocks after the HWM
which are empty so there is not much content in the data blocks to
write to the undo space. The content is probably coming from the index
blocks.
On 3/21/21 1:16 AM, Pap wrote:
--
INSERT /*+ append parallel(16) nologging */ INTO USER1.TAB (c1, c2,
c3, c4... c11) SELECT...;
Mladen Gogala
Database Consultant
Tel: (347) 321-1217
https://dbwhisperer.wordpress.com
--
//www.freelists.org/webpage/oracle-l
