|
|
Archives of the TeradataForum
Message Posted: Thu, 12 Dec 2002 @ 18:38:11 GMT
Subj: | | Re: V2R5 Query Log vs Ambeo Usage Tracker |
|
From: | | Walter, Todd A |
The V2R5 Query Log should not be thought of as a single binary on/off kind of thing. It has a number of options for controlling the
logging performed. Some of these options are going to be reasonable to have on all the time. Others are going to be more costly in
resources and space and will probably only be used for investigating a part of the workload, or a new application, in detail. For ad-hoc,
strategic queries, I would expect logging at the qeury level to be on all the time. However, to log every step executed for every one of
those queries will probably be more expensive than is desirable for most customers. But when there is a performance issue or a new
application is being deployed, being able to investigate at the step level will be extremely valuable. Likewise for objects - when object
logging is on, each object touched will result in a record in the log. This will be a LOT of logging for a high volume of queries. And of
course if you don't wish to pay the price of that logging for every query, it will be difficult to use it to identify unused objects. Note
that if the primary reason for logging objects is to understand what is used, then a daily job to aggregate that log to capture one record
per object rather than one per object per query will reduce the long term storage for the information radically. In some cases, it will
probably not be appropriate to turn on logging at all for certain user ids. Most obvious perhaps is TPUMP where query level logging will
result in a record in the log for every pack sent by tpump, probably much more logging than desired relative to the value of the
information.
And a peek to the future - V2R5.1 will populate the use count and last access date columns in the dictionary. This will allow a simple
query at any time to find out when any particular object was last used and how frequently use occurs. And it will be implemented in a way
that costs very little system resources so it will just always be on all the time.
| |