Archives of the TeradataForum
Message Posted: Wed, 20 Mar 2002 @ 21:42:11 GMT
<-- Anonymously Posted: Wednesday, March 20, 2002 11:26 -->
The NCR CRM application (formerly CERES) uses generic userids to sign on to Teradata via a mid-tier taskbroker. The generic userids (CRM1, CRM2 etc) use sessions that they leave open for days at a time. In this way many SQL requests are executed by a generic CRM userid via a long-established session.
CRM users have there own username and are assigned CRM-specific session identifiers via the CRM interface when they initiate work requests.
We end up with the following scenario:
USER : Fred
USER : Bill
Bill has no idea that the work request he has initiated results in a piece of SQL that produces a resource-hungry job. We can see from the delta cpu/io figures in PMON/Session Information that one of the CRM users has initiated such a job. However, there appears to be no way of tracing a piece of CRM SQL that is currently running under a generic userid, with a long-established session, back to a CRM user's task.
Are there any workarounds for this?
Also, the way in which sessions are left open means that cpu/io usage reporting via dbc.acctg is devalued. Although we have session level cpu/io reporting via ASE, the CRM userids execute thousands of SQL requests within each session. The cpu/io usage is recorded against the session so we can't see the cpu/io used by an individual piece of SQL.
|Copyright 2016 - All Rights Reserved|
|Last Modified: 27 Dec 2016|