ビッグデータ量のDML操作bulk collect into limit forall commit;


大きなデータ量のDML操作トランザクションがある場合は、OLAPレポートなどの低同時ライブラリにあります.そして、強制的にアーカイブモード中である.
BULKとFORALLを採用した方が早いです!
open cur_COLUMN_USER;
  loop
   fetch cur_COLUMN_USER bulk collect
   into 
          l_ARY_statedate,                    
          l_ARY_form,
          l_ARY_columnid,           
          l_ARY_usernumber,                   
          l_ARY_new_user,               
          l_ARY_exit_use    
   limit g_batch_size_n;
   
   forall i in 1..l_ARY_statedate.count
    insert into content_lst_day
    (......)
    values(l_ary_statedate(i),....);

 commit;
end loop;

 
通常のカーソルループを用いるデータを抽出する処理に比べてかなり高速である.
理由1 bulk collect intoから配列まで一度にデータを抽出でき、サイクル中のPL/SQLとSQLサポートの切り替え時間を短縮
理由2 forall in.....一次型のデータをどこに提出しても同様にサイクル中のPL/SQLとSQLサポートの切り替え時間を減らす
注意1データが大きすぎて合理的なLIMITを設置しなければならない.そうしないと、配列のデータがPGAの返信メモリを爆発させる.
原因3 bulk内部操作はinsert deleteに対して最適化してロット方法を採用した.RedoとUndoの使用量を大幅に減少する.
理由4は、大きなデータ量のinsertが非常に遅い場合、バッチ挿入の総時間が一度の挿入よりも多くの時間を節約することを証明するためである.
 
An ORA-22813 when using BULK COLLECT is typically expected behavior indicating that you have exceeded the amount of free memory in the PGA.  As collections are processed by PL/SQL they use the PGA to store their memory structures.  Depending on the LIMIT size of the BULK COLLECT and additional processing of the collected data you may exceed the free memory of the PGA.  While intuitively you may think that increasing the PGA memory and increasing the LIMIT size will increase performance, the following example shows you that this is not true in this case.  So, by reviewing this example you should be able to strike a balance between a reasonable LIMIT size and the size of the PGA while maintaining a high level of performance using BULK COLLECT.