Home Page for the TeradataForum

Archives of the TeradataForum

Message Posted: Thu, 30 Jun 2005 @ 15:13:48 GMT

  <Prev Next>  
Next> Last>>  

Subj:   Transaction Rollback
From:   Dong, Charles J

I am a new Teradata DBA. I tried to learn more about its behaviors. It is different from other major RDBMS, such as Oracle, Informix, . Teradata is for Data Warehousing. I am ready for brain washing.

Recent I did one simple job. The results worry me.

I create a SET TABLE A with no fallback, no before_journal, and no after_journal. Then I loaded it with an INSERT statement,

     INSERT INTO A SELECT col1, col2, col3, . FROM B;

Because of running out of space, the job failed. Table B had 395370215 rows. The whole process, from starting INSERT to end of rollback, took 1 day, 9 hours, 57 minutes, 22 seconds. I did not stop the Teradata, and did not kill the session. I did not intervene, and just let it completely rollback.

Afterwards, I added more space to the database, and reran the same SQL. It took only 1 hour, 19 minutes and 39 seconds to load 132520696 rows. Duplicate rows were not loaded into this SET TABLE.

Why was there a so large time difference, 34 hours vs. 1.5 hours (22 times as much for rollback). Is there anything Teradata can work on? Or I should do it in an alternative way, or the system can be set up in a better "SHAPE"? Table a was empty before loading. I do not know if I can kill a transaction or not. As I was told, the server would resume rollback even if I restarted it while rollbacking in progress. I could abort the session, but I was also told the session would not terminate until rollback completed. But I could call Teradata Tech Support for rescue. That is ridiculous, I think. If it happens in a production environment, what can I do? Calling Teradata? Otherwise, the system had to go down for 2 days, and people could only watch it dying helplessly. Table and A and B (?) cannot be queried during the whole process. I think this kind of problems happens frequently to a DBA, especially when the data is skew, or disk space is limited. If a DBA cannot handle it NOW, NCR should provide a better solution instead of letting DBAs call for help.

Can any Teradata experts here help? Thanks in advance.

A New Teradata DBA

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