When a lengthy load takes place, the last thing a user wants to see is an ORA-
error or any other error displayed on the console. This is an emerging issue which usually has to do with a lack of resources to finish the job. There should be enough free space not only for the data to be loaded, but also for the related indexes as well. As SQL*Loader has a default number of rows to commit in a batch load, there is no risk of exhausting the undo regions during a conventional data load.
While performing a lengthy load with a constrained time frame it is better (for peace of mind) to reduce the possibility of any unforeseen circumstances arising that may prevent the successful completion of the task. That is why storage levels must be evaluated to ensure there is enough free space to hold the massive load, otherwise it will have to be restarted by means of a recalculation of the SKIP
value to jump to the point of failure, and continue the load from that point on.
Another more practical...