My system has the SCHMON settings (default) show below:
The strings you showed should map correctly to L/M/H. Unless there's a second $ within the accountstring only the first character will be used for matching.
If you're using TASM the dbc.QryLogExceptionsV view returns a WDID and NewWDID indicating if a query was re-classified and moved into a different workload.
As we are on Appliance box we dont have full blown TASM (just filters and throttles; no workloads). In the QryLogExceptions, I just see the exceptions for the filters that we set. Wondering where can I check for the demotion path of the queries? I see that appliance has few basic query milestones set and hence wanted to check how good it is performing at the user level. Thanks.
Is there any limit on number account strings that need to be created for one system. Currently we are each one for individual user and databse (except, for DBA's Developer's, and some system oriented id's).
For ex: If we have a application, we create 7 different objects, like AppID(Application id for that application), UserID(user id for that app), ID1(View DB ID), ID2(Logical View DB ID),ID3(MartTabl DB ID)/ (I used some random example), But like this our list of ASE are increased to 3 digit number and reaching to 4 digits shortly. I am concerned 99% of them are mapped to MEDIUM PG, and i know we need to tweak them to allocate some of the low level app IDs to LOW priority PG. And important ones to HIGH (but not to RUSH). Just wanted to know are there any best practies need to be followed to keep the number low for number of accnt strings and better way to map the existing and future account strings to L/M/H PGs(or may be create more PGs for better maintenance).
i don't know if there's a limit, but i don't think so.
Hopefully there's a pattern, so you can easily map account strings to PG based on wildcards in TDWM.