Archives of the TeradataForum

Message Posted: Wed, 13 Dec 2000 @ 19:43:57 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

Gloria,

MultiLoad times out after waiting 300 seconds when requesting a lock on its own error UV table, while running in APPLY phase, according to your problem description. You may investigate and try to find out the root cause for this: it may be a real lock problem, i.e. someone may have requested and successfully got a database lock on CPARS. On rare occasions someone may have been trying to query rows from the own UV table, for instance using BTEQ. If you were trying to INSERT a large number of rows and you have many uniqueness violation hits, you may be experiencing a MultiLoad design limitation, i.e. too many hash lock collisions for its own error table. Possible workarounds: if the UV table is still locked, and the problem is due to an external action like the first two examples mentioned above, try to recover the lock and then rerun the MultiLoad job as is, to completion. Of course NEVER drop any error and log MultiTran tables, to be able to recover from point of failure, otherwise you may loose your target table(s). A way to recover the lock from the UV table can be an INSERT/SELECT to a new table, defined exactly as the UV, ask for LOCKING FOR ACCESS in the SELECT so you can read the table in spite of its lock, then rename the old table to any name (just keep it until you recover MultiLoad completely), finally rename new table to UV_CPRTRACK_TBL in database CPARS. Then you are ready to rerun MultiLoad. If your problem is due to a very high number of hash lock collisions you may try to DELETE rows from the UV error table, be careful here, just delete a percentage of the rows, the table must be available for MultiLoad to recover, if you need the error rows, they are available in the old renamed UV. If this becomes a common problem you may use something like IGNORE DUPLICATE INSERT ROWS in your .DMLs in future MultiLoad jobs, again, unless you do need this error information.

Hope this may be of help.

Best regards,

Jorge.

	<Prev	Next>		<<First	<Prev	Next>	Last>>