13 lines
1.4 KiB
Plaintext
13 lines
1.4 KiB
Plaintext
=== on 2 Feb 2017, 08:16:35 Alexandre Gigleux wrote:
|
|
I used to write a lot of PL/SQL code taking data from source tables and loading them into target tables. When you work on huge data set and you can't increase the oracle temp tablespace or transaction log to a huge value, the only way is to commit every N inserts. If you don't do that and handle millions of rows in a long transaction, you will have performance issue. For sure, if you commit for each iteration in a loop, you will have also performance issue. So all in one, it's a matter of testing and finding the correct commit threshold especially when dealing with migration script and it's acceptable in that context to not have to manage a long transaction if your script is able to recover in case of failure (restart from where it failed). I'm sceptical about the number of FP and I would decrease the Severity to Major.
|
|
|
|
=== on 2 Feb 2017, 14:14:49 Ann Campbell wrote:
|
|
Addressed per our discussion [~alexandre.gigleux]
|
|
|
|
=== on 16 Feb 2017, 12:07:07 Pierre-Yves Nicolas wrote:
|
|
\[~ann.campbell.2] It seems that you added a note at the end of the description. Is it an exception or an accepted false positive?
|
|
|
|
=== on 16 Feb 2017, 16:00:09 Ann Campbell wrote:
|
|
I suppose it's an accepted FP [~pierre-yves.nicolas]. I added this in response to [~alexandre.gigleux]'s presentation of a use case where ``++COMMIT++`` may be required inside a loop.
|
|
|