An auxiliary session is not required as part of a load utility job, although most Teradata utilities do support that option. But if you use an auxiliary session it will not be part of the utility unit of work because it is not included in the UOW protocols. The database cannot control what might end up being executed within an auxiliary session. So the decision was made by engineering to only allow the actual necessary non-optional load pieces to be part of that UOW. That is why they appear to the database to be just another SQL request and will not classify to the same workload as the one running the utility.
For that reason your statement below is correct. The auxiliary session SQL DOES carry the same LSN and does have the same application name as the load utility. So by using system throttle classification (where that SQL might classify) to exclude by application name will effectively prevent auxiliary (that's hard for me to spell!) session work from being delayed there.
Jana,
An auxiliary session is not required as part of a load utility job, although most Teradata utilities do support that option. But if you use an auxiliary session it will not be part of the utility unit of work because it is not included in the UOW protocols. The database cannot control what might end up being executed within an auxiliary session. So the decision was made by engineering to only allow the actual necessary non-optional load pieces to be part of that UOW. That is why they appear to the database to be just another SQL request and will not classify to the same workload as the one running the utility.
For that reason your statement below is correct. The auxiliary session SQL DOES carry the same LSN and does have the same application name as the load utility. So by using system throttle classification (where that SQL might classify) to exclude by application name will effectively prevent auxiliary (that's hard for me to spell!) session work from being delayed there.
Thanks, -Carrie