Home Page for the TeradataForum
 

Archives of the TeradataForum

Message Posted: Sun, 12 Dec 2004 @ 14:31:11 GMT


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


Subj:   Re: Performace impact of adding rows to ACESSLOG
 
From:   Geoffrey Rommel

  Our auditors are requesting that we log all update activity by a number of our users.... what I haven't been able to find is anything that quantifies how much overhead is caused as you add rules for the logging.  


Unfortunately, I don't have any quantitative information on the overhead of access logging, but we used it quite heavily on a 400-AMP system and had relatively little trouble with it. The one thing to watch out for is that (on V2R4 at least) the primary index of DBC.AccLogTbl is (LogonDate, LogonTime), which means that if you log every statement in a session they will all go to the same AMP. You're logging every insert, so this could be a real killer; it could even lead to a shortage of AMP worker tasks.

If the users are doing hundreds of these statements in each session, you might want to consider some changes. For instance, you could modify the application to do its own logging (with a different primary index); you could automatically log them off and start a new session after so many statements; or you could try to persuade the auditors to live with FIRST instead of EACH.


  This particular request will require more than 1400 new rules of the format BEGIN LOGGING ON EACH INSERT, UPDATE, DELETE BY userid ON DATABASE proddb.  


Could that instead be coded as "begin logging ... by all on database proddb"? That would put one row in AccLogRules instead of 1400.



     
  <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