Home Page for the TeradataForum
 

Archives of the TeradataForum

Message Posted: Wed, 13 Aug 2003 @ 13:08:28 GMT


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


Subj:   Re: Renaming table
 
From:   Arunachalam, Sankar

Thanks to all ..

Actually our need was not just administrative but technical. Which of course Dave had addressed all of them. However, I would like to add to his views my 2 cents. As far as the 'security' checks, every sql statement issued by any user must have been checked for the security clearance. There may be subtle differences in the extend they are done. Therefore the only additional check that may have to be done is the space related issues for this type of renaming.

We had a need to move a table from one database to another, because of backup related issues. Part of the tables in the database are loaded with the batch data, nightly starting midnight and the rest starting 3 hours later. The backup for the entire database takes about 5 hours. When backing up, ARCMAIN locks the entire database and doesn't let the batch load to start until it releases the lock or skips the table which could not be locked by it. Hence this idea of moving those tables which have the loading process starting at later time to another database and have it backed up at different schedule. It looks like (I am a novice in this area) the ARCMAIN needs exclusive access to the database to make complete clean backup. (What I mean is without skipping table being data loaded or the ArcMain itself without having to wait for the loading job to finish).

Actually I posted a message couple of weeks ago asking this forum experts about the way they handle backups. Unfortunately I didn't get any replies.

One of my important questions was, How do the shops running 24X7 today handle their backup, given the nature of ARCMAIN, which doesn't permit loading or skips loading when data loads are going on...

Second important question was, Actually in our system 3% of the tables hold 99% of the data. Interestingly these 3% tables get loaded with every night just 1/2% of data (compared to the table size). To backup the incremental 1/2% we need to backup the entire 100% data which actually consumes the 99.9% of the backup time. I am sure we can circumvent using additional processing logic backing up the incremental data instead of the entire 99.9% of the data. However that would mean adding further overhead on processing at the time of restoring the table. Wouldn't be nicer and more logical for Teradata to come up with capabilities like incremental backup, hot-backup (ability to backup when data access/loading is in process) etc., Anyways, if some one you folks can educate us with the most efficient way of doing the minimal backup while maintaining harmony in the system I would surely appreciate.

Once again my sincere thanks to this highly lively informative forum

Sankar



     
  <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