Commit on thousands of records

Question

Hello,
I've encountered the following problem while trying to update records in an Oracle 8i database :
I have a java program that updates thousands of records from a flat file to the oracle database, the "commit" command is done at the end of the program,the problem is that some records are not updated in the database but no exception is raised !
If I try to do a commit after each update, the problem seems to be solved, but of course it takes more time to do the massive update, and I think it is not recommended to do a commit after each record?
Is there a limit to which a commit can be done? (a number of maximum records to be updated)
Thanks greatly for your help!
Regards,
Carine

Answer 1

If it was a problem with the size of the rollback statements, you would have received an error.
But are you sure that you don't have any neglected errors (like a when others that does no handling?). In that case you wouldn't receive any error and no rollback would be performed (but a commit instead) resulting in "saving" your already done modifications.
In the book "expert one-on-one" from thomas kyte, there is a chapter of what exactly a commit does.
a small extract:
basicly a commit has a fairly flat response time. This because 99.9 percent of the work is already done before you commit.
[list]
[*]you have already genererated the rollback segments in the sga
[*]modified data blocks have been generated in the sga
[*]buffered redo for the above two items has been generated in the sga
[*]depending on the size of the above three, and the amount of time spent, some combination of the above data may have been flushed onto disk already
[*]all locks have been acquired
[list]
when you commit, all that is left is the following
[list]
[*]generate a scn (system change number) for our transaction
[*]lgwr writes all of our remaining buffered redo log entries to disk, and records the scn in the online redo log files as well. This step is actually the commit. if this step occurs, we have committed. Our transaction entry is removed, this shows that we have committed. Our record in the v$transaction view will 'disappear'.
[*]All locks held by our session are released, and everyone who was enqueued waiting on locks we held will be released.
[*]Many of the blocks our transaction modified will be visited and 'cleaned out' in a fast mode if they are still in the buffer cache.
[list]
Flushing the redo log buffer by lgwris the lengthiest operation.
To avoid long waiting, this flushing is done continuously as we are processing:
[list]
[*]every three seconds
[*]when the redo log buffer is one third or one MB full
[*] upon any transaction commit
[list]
for more information do a search on akstom.oracle.com or read his book.
But is must be clear that the commit on itself has no limits on processed rows.
There's no limit re: commit. There is a limit on the number of rows that can be modified (updt, del, ins) ina transaction (e.g. between commits). It depends on rollback segment size (and other activity). This varies with each database (see your DBA).
If you were hitting this limit it would normally "rolllback" all changes to the last commit.
Ken
=======
Hello Ken,
Thanks a lot for this quick answer. The wonder is that I do not get any error message concerning the rollback segment:
if I do the commit at the end after updating thousands of records, it seems like it was done correctly but I see that only some records have not been updated in the database (thus I would not be hitting the limit as all changes would have been rolledback) ?
Is there a way to get a return status from the commit ? Should I do a commit after each 1000 records for example?
Thanks again,
Carine