If you are user DBC or user TDWM and you log onto a Teradata Database, you might get treated somewhat differently than other users. This posting describes what user DBC and user TDWM do, some of the special things about them, and when you can expect them to get treated differently. We’ll also look at any implications in setting up workload management for these two special users.
When you first install Teradata Database, it has only one user. This user is called DBC, and from it all other future databases and users in the system are created. In addition, user DBC initially owns all space until space is allocated to other users. Even on an established system user DBC will continue to own all unallocated space.
After you set up an administrative user, such as DBADMIN, the DBC user may not log onto the system very often. When it does, user DBC is generally used only for administration activities that only DBC can perform.
User DBC will establish a session priority when it logs on, in the same way that other user do at logon time. DBC’s logon and logoff activity will be recorded in DBC.LogonOff just as any other logon is. All requests that require AMP support within a session initiated by user DBC will map to one of the defined workloads the same way as any other user sessions do.
There are a couple of unusual characteristics of user DBC. You can’t give a profile to user DBC. What a profile does is applies an identical set of user parameters to a group of users. Because DBC is a super-user, it is not subject to profile control.
One other restriction is that DBC cannot be granted access to a secure zone. Administrative users like DBC are prevented from accessing user data within secure zones. User DBC can perform administrative work like creating secure zones and users that will be each zone's primary DBA, or grant a user privileges to do so. The primary DBA of a secure zone is the zone's super-user (equivalent to user DBC in a non-zone system). But DBC will not have access to database objects created within a zone by zone users.
TDWM is a user ID but it is also a database where internal tables related to workload management reside.
User TDWM is primarily involved in internal tasks to support workload management. For example, things like changing a rule set at a planned environment boundary, or writing to the TDWMEventLog when a system event is detected. For the most part TDWM initiates internal operations that are under the surface and are not reported in Database Query Log. But sometimes user TDWM issues actual SQL, for example from Viewpoint when a Viewpoint portlet needs to read data in the TDWM database. As with all SQL, that TDWM user activity will be recorded in the DBQLogTbl. Either way, it would be unusual to see an actual person, like a DBA, log on as user TDWM.
Within Viewpoint Workload Designer, user TDWM is used for activate and deactivate requests, and also for writes to the TDWM database. For example, user TDWM would be used when copying a rule set to the TDWM database.
In addition, Viewpoint uses the TDWM user for some read activities, such as:
Teradata Workload Management, whether TASM or TIWM, has an option called “Bypass” which can be applied to a user, or multiple users. When a user has been given bypass privileges, none of the user’s requests will ever be impacted by a system throttle or a system filter.
Users DBC and TDWM are automatically placed on the bypassed user list without your doing anything. That means requests coming from either of those users will never be delayed or rejected by system-level rules.
Administrators can add users other than DBC and TDWM to the bypass list. For example, special administrative users can be added to the bypass list, so they have immediate access for trouble-shooting purposes. However, adding to the bypass list is not widely embraced among Teradata Database administrators today. In a recent survey, close to 80% of Teradata sites said that they had not added any users to the bypass list, beyond DBC and TDWM.
Note that bypass status does not exempt requests from being managed by the workload it classifies into. And bypassed users are not free from all throttle rules: Only system throttles and virtual partition throttles honor bypass. Workload throttles do no honor bypass, nor do group throttles, so either of those lower-level types of throttles could delay a bypassed user's requests.
It is generally a good idea to create a separate workload for these two special users and place the workload high in the workload evaluation order. That way there is no ambiguity about which workload will be supporting requests from these important users. And you can make sure requests from these two users are going to execute at the priority of your choosing.
However, of the two users, user TDWM usually needs a higher priority than does user DBC. Requests made by user TDWM do things like change TASM states, or activate a rule set. These types of things don’t happen often, but they generally need to happen quickly.
To account for the different degree of criticalness of the work they submit, two separate workloads for these users are often implemented, one workload for DBC, one for TDWM. At some sites the special workload created for user TDWM is placed in the tactical tier, but most often the TDWM workload is placed in Timeshare Top (if running TIWM) or SLG Tier 1 (if running TASM). TDWM is not expected to use much resource.
User DBC, on the other hand, submits requests of a more administrative nature, such as allocating space. DBC requests are usually less urgent and less critical to overall performance than TDWM requests. For that reason, a workload created just for user DBC is often placed in a medium, or medium-high priority, rather than one of the very high priorities.
All requests, no matter what user they come from, will end up under the control of one workload or another. If a given request does not classify to any of the existing workloads, it will fall through and run at WD-Default, the default workload.
If you have not defined workloads where DBC and/or TDWM can classify, either as the session workload or the workload where the individual request will run, special conventions are in place to prevent WD-Default from being the first choice.
For user DBC, the special behavior you will experience related to workload assignment only applies during session workload mapping, not during request-level workload mapping.
When a session logs on, the session’s logon detail is compared to the “Who” criteria (also known as source criteria) of the defined workloads. What is called “session classification” happens by matching a workload’s source criteria (and ignoring its query characteristic or target criteria) to the session’s logon information. This is described in the Developer Exchange blog posting called “New, Simplified Approach to Parsing Workload Selection”. The workload chosen as a result of session classification is reported in DBQLogTbl as SessionWDID.
Under normal circumstances, if a user session logs on and there is no match to a workload on source criteria, any AMP activity that the session generates from the parsing engine (like getting column information from the data dictionary) will run in WD-Default. However, if the user is DBC and its session information does not classify to a workload other than WD-Default, the session will classify to the first tactical workload in the workload evaluation order. If there are no tactical workloads defined, the DBC session will then revert to using WD-Default as its SessionWDID.
It is important to note that all requests issued by user DBC once the logon is complete will be assigned a workload using normal conventions. If a request coming from DBC does not classify to any workload, it will run under the control of WD-Default There are no special behaviors related to request-to-workload classification from DBC requests.
Special considerations around workload mapping for User TDWM are a little different. If the source criteria from a session logon cannot match to a workload, then the workload that the session runs under will be WD-Default. There is no special treatment for TDWM session classification, as there is for DBC session classification.
However, once user TDWM logs on, any requests issued from user TDWM that do not classify to a workload will run in the first tactical workload that it encounters in the workload evaluation order. If there are no tactical workloads, it will run in WD-Default.
These special cases having to do with workload classification described above will never come to pass if you have set up a separate workload for both user DBC and for user TDWM. Doing so will give you more control over the priority used by those two important users, whether at the session or the request level.
Also, in the case of user DBC, if you have set up a parsing-only workload, as described in the blog posting mentioned earlier, and one of the classification criteria for that parsing-only workload is USER = *, then DBC will use the parsing-only workload for its session classification.
Where this special handling of users DBC and TDWM might be useful is if you have a tactical workload defined, but are not currently using it for any requests. In that case, user DBC could be using that tactical workload as its SessionWDID, and user TDWM could be using it to run its requests. Under those circumstances, you’d see some activity reported in your tactical workload when you might not be expecting it.
If you have set up separate workloads with classification by user for DBC and TDWM, such a situation will never come up.