Home Page for the TeradataForum
 

Archives of the TeradataForum

Message Posted: Wed, 30 Nov 2005 @ 23:11:06 GMT


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


Subj:   Re: How to leave an intentional lock for testing
 
From:   McCall, Glenn David

  Good call - The "transactional locking" doesn't work, as MLOAD just waits it out. (Found that the long way) - I'm trying to find a case where I can blow up an MLOAD on the target table .. Someone had mentioned a NULL into a NOT NULL column might do it. I'm working on that at the moment. Unfortunately, time and other tasks seem to always get in the way...  


If you bomb out the mload, then depending upon how you bombed it, you would probably just get a "table is being loaded type of error".

Null values into not null columns don't seem to bomb the mload job. On V2R6 at least an entry is made in the "UV" table with error code 3604 which means "Cannot place a null value in a NOT NULL field."

The easiest way to see this type of lock would be to export a table (eg. Via bteq ".export data file=xxx.dat") type of operation. Use the file to mload data back into Teradata and simply break (eg. Control-c) the mload during the acquisition or the application phase.

If you are wanting to see the utility locking, the only way I could imagine you achieving this is to run the maximum number of utilities concurrently and then run one more. The last one should block. Ideally you would lower the maximum number of jobs so you don't have to manage a large number of mload commands.

The trick then becomes how to delay the utility. If it were me, I would probably use multiload with a simple INMOD that simply slept for a period of time then returned an EOF condition. If you wanted to get slightly sophisticated, you could get the inmod to poll something every few seconds (eg. Existence or absence of a file) to trigger it to return the EOF condition. In that way, you could get the mload to wait indefinitely. You would also have the ability to get the mload to terminate in an orderly fashion. The amount of code required to achieve this would be less than the two page example shown in the manuals. However, you would need someone who could code in 'C' to write it for you.

I recall that when I suffered this problem way back on V2R2 (or similar) the utility would display a "retrying message" every few minutes. If memory serves it was every five minutes. I don't know if the modern utilities exhibit this same behaviour because I've not encountered the limit since those "good old days".

I am now really curious. Why is it important to demonstrate this functionality?



     
  <Prev Next>   <<First <Prev Next> Last>>  
 
 
 
 
 
 
 
 
  
  Top Home Privacy Feedback  
 
 
Copyright for the TeradataForum (TDATA-L), Manta BlueSky    
Copyright 2016 - All Rights Reserved    
Last Modified: 15 Jun 2023