Utility Session Management - It's Inside the Database in Teradata 13.10! (UPDATED)

How do you pick the number of sessions to assign to your utility jobs?  Chances are you guess.  In Teradata 13.10 the task of deciding the number of sessions has been moved inside the database, meaning one less thing for you to worry about.  Read on for a quick intoduction to how this feature works.

Once you get on Teradata 13.10, if TASM is enabled, then the database is dictating the number of sessions each load job will get.  This is happening automatically, without your doing a thing.  Any parameters or config files you have set up will be ignored, and by default you will get a number of sessions between 20 and 100 for each utility you run. 

(See the new text in the section titled "Is the Session Setting a Max or a Limit?"  if you have read this posting previously.)

Default Session Management Rules

There are default session management rules in place that will be in control when you first get on Teradata 13.10.  You can change the number of sessions that these default rules provide if you like.  There are 3 types of default rules:

1. FastLoad and Muiltiload (including TPT and JDBC variants)

2. FastExport

3. Archive and Restore

The number of sessions specified by the session management default rules will be different based on the number of AMPs in your configuration, as illustrated by the following formulas.  First is the formula that the default session management rules use for the load type utilities:

 

FastExport always uses 1 session per AMP, up to an upper limit of 4 sessions per job.

Here is the formula that the default session management rules use to determine the number sessions for archive and restore jobs:

 

User-Defined Session Management Rules

In order to provide more granular control over the number of sessions used by utilities, you may create your own rules.   Which session management rules will be used by a given utility job is determined  by means of a classification process, similar to workload classification.   Classification to the default rules is based on utility name and optionally utility data size.  If you create your own customized session management rules you will have the opportunity to select TASM "who" criteria (user, account, query band, etc.) that will limit which utilities will use that rule.

For example, you may want to make sure that user loads from a sandbox user classify to a rule with a very low number of sessions.  Or you might want to ensure that your loads to your large, dynamic, sales tables have access to a higher number of sessions when they run.

Once you set up additional rules, you will need to specify an evaluation order.  The first session management rule that a utility classifies to will be the rule that determines the number of sessions that it will use.   At the bottom of the evaluation order is the default rule for that utility type, which is where all unmatched utilities will classify.

Is the Session Setting a Max or a Limit?

If you modify the number of sessions in one of the default session rules, or create a new customized rule, you will see that Viewpoint Utility Session screens refer to this number of sessions as a "Session Limit" or  a "Max Number of Sessions".

However, this number of sessions you specify is not an upper limit for the supported utilities (FastLoad, TPTLoad, etc.).  Rather it’s the exact number that must be available for the utility to begin execution, assuming you are on both Teradata 13.10 and TTU13.10 or later releases.  The session number specified in the TASM session rule will override both the minimum and maximum session specifications that have been placed in the script.

However, for non-conforming utilities that come from 3rd party tools or for utilities executing on pre-TTU13.10 software, the TASM session rules set a limit.  Only the maximum sesssion specification within the script will be overridden for those jobs, so it is possible that fewer sessions than specified in the TASM rule may be applied.

Viewpoint Utility Session terminology accounts for all of the situations described above, when it uses the term "limit".  However, if you are using the standard Teradata utilities from TTU13.10, this should be interpreted as "Number of sessions".

Utility Data Size 

If you know the size of the load job that is typically submitted by a specific user, then you can create a customized session management rule that uses the load type and the user name (or other criteria) to ensure those user’s jobs get the number of sessions that are appropriate.   Knowing the user and creating a rule for him is one way to manage the relationship between data size and number of sessions, and also keep the decision on the number of sessions inside the database.

Another approach is by using a new reserved query band called UtilityDataSize.  You have 2 values you can pass with that query band:  LARGE and SMALL.  If you do not pass a query band, the default number of sessions (equivalent to a MEDIUM size) is used.  Use of query bands puts control in the hands of the client, rather than the database, and assume that is 3rd party tool is being used, that the tool has the intelligence to support query bands.  

Below is some abbreviated FastLoad code that shows you where you can place the query band. 

12345678910111213141516171819202122232425262728293031

sleep 1;tenacity 1; .SET SESSION CHARSET "ASCII";.RUN NODEID.user1;set record VARTEXT "|" DISPLAY_ERRORS NOSTOP;errlimit 3; SET QUERY_BAND = 'UtilityDataSize=SMALL;' UPDATE for session; DELETE FROM fl_table_1; define     start_datetime (varchar(200),NULLIF='')     ...     ,file=data1; begin loading    fl_table_1      errorfiles et_fl_table_1,                 uv_fl_table_1; insert into fl_table_1 (      start_datetime     ...     ) values (     :start_datetime     ...     ); end loading;.logoff;

 

The session management rule that the utility classifies to has a specific number of sessions.  There are three versions of each default rule, one for SMALL, one for medium data sizes called "Default", and one for LARGE data sizes.  The default version represents the standard number of sessions for that utility and will be used if no query band is passed.  If the query band says “LARGE” it will match to the LARGE version of the rule, whose number of sessions will have been increased by 50%.  If the query band says “SMALL” the rule it matches to will have a number of sessions that will be half of those in the default.  An example of those different size-specific rules whose default specifies 32 sessions follows:

DEFAULT:     = 32 sessions

LARGE:         32 * 1.50 = 48 sessions

SMALL:         32 * 0.5 = 16 sessions

Number of Sessions with Teradata Parallel Transporter (TPT)

When you’re using TPT you can initiate multiple instances of a load operator within a single load job.  All the instances will share a common logical sequence number (LSN).  One utility slot is required for each LSN.  In the database, the number of sessions specified by a session management rule will be applied to the LSN.  So if there are multiple load operators within a load job, they will share the number of sessions given to the load utility.

For example, if the session management rule for a TPT job specifies 10 sessions, and the TPT Load job has 2 load operators, then each operator will get 5 sessions.

How To Benefit from the Session Management Feature

You can do nothing, and once you are on Teradata 13.10, the default session management rules will be deciding how many sessions each of your utility jobs will use.

You can simply change the number of sessions that are specified in the default session management rules.    For your site, you may find 32 sessions for a configuration with 240 AMPs (for example) is too high, and you want most users to have a much lower number of sessions.

You can start using query bands to influence the number of sessions based on passing the value of LARGE or SMALL, if appropriate.  In that case, the number of sessions in the default rules or in the rules you have created will be selected based on the size value specified within the query band, as shown in the example above.

Or  you can define additional customized session management rules, based on your knowledge of who is submitting load utilities, and their needs.  Creating your own rules will give you more granular control over session assignments.  Don’t forget the evaluation order.