Have a doubt in my mind, just want to clear it regarding the types of locks applied during fast load abort case and why is it different from that of multiload
normally based on the phase in which mload aborts we have to first release the lock applied on the target table and then restart it from the last check point by simply resubmitting the script..
However in case of fast load failure during the loading , we release the lock on the target table by using this in the script (commenting the insert)
error file et1,et12
after succesful completition, locks gets automatically relased and we resubmit the job..
My doubt here is that why is this different from mload where we simply release the locks by RELEASE MLOAD statement.??
Is there any reason behind it or its the way fload is programmed?
Nishant, I will answer from my viewpoints :). Fload is built for fast loading into empty tables. Mload is built with 5 phases...blah blah.. So you see the differences. Both utilities are built for their own purposes by TD. They have different steps of processing.
Thanks Raja for reply.
My query is more from the Locking Prosepective.
Can you please throw some light on the locking mechnasin in Fload? vs what we have in mload
As I am not sure,can you please share some pointers in the difference of locking mechanism between Fast load vs Mload.
Also,can we execute different fast load scripts at a time, to load a single table but in to different partitions,
Is it possible ..? Please suggest
Technically, there are no locks when Fastload or Multiload are not running - if the job has aborted or been halted prior to finishing. There is a status recorded in the table that says that the table is in process of being loaded. The status is left in the table to enable the job to be restarted, continue from where it left off and run to completion.
This status is simple to remove in the case of fastload because the only choices are to drop or delete all and reload the table.
Since there is already data in the table being multiloaded, there is more complexity. If the apply phase has not been started yet, then cleanup must be done but the table contents have not yet been affected. If apply phase has begun, then the table is in an uncertain state. It is not recommended to release the mload when the table is in that state but it is allowed with the additional option. Because of the added complexity, the release mload is a form of "are you sure" check before you put your table into an uncertain state or remove the ability to restart and complete the mload.
It is not possible to run concurrent fastload jobs into the same table at this time. It is on the to do list to allow multiple insert selects to insert into separate partitions via new functionalty being build to allow locks at the partition level - no release date available at this time.
Thanks a lot Todd for your sharing your thoughts & comments . It really helps.
Just have a doubt in mind regarding the H.U.T ( hostutility locks), I was under the impression that during the execution of various T.T.U (mload/fload), these got applied for mainiting the
Can you please share some pointers to deep dive in this area as well?