 |
 |
Archives of the TeradataForum
Message Posted: Sun, 12 Dec 2004 @ 14:31:11 GMT
| 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.
| |
