MONITOR VIRTUAL CONFIG - Teradata Database - Teradata Vantage NewSQL Engine

Application Programming Reference

Product
Teradata Database
Teradata Vantage NewSQL Engine
Release Number
16.20
Published
March 2019
Language
English (United States)
Last Update
2019-05-02
dita:mapPath
vwf1492987142269.ditamap
dita:ditavalPath
changebar_rev_16_20_exclude_audience_ie.ditaval
dita:id
B035-1090
lifecycle
previous
Product Category
Teradata Vantage™

Purpose

Collects information on virtual processor (vproc) availability.

Input Data

Element Data Type Description
IndByte BYTE Indicator bits that specify which fields to treat as NULL if you are using the indicator mode.

Each bit in the byte corresponds to one field in the input data.

If data is supplied for that field, set the bit to zero.

If the data for that field is NULL (that is, there is no data supplied for that field), set the bit to 1.

The IndByte field is only required if the CLIv2 request is submitted in indicator mode.
mon_ver_id SMALLINT

NOT NULL

MONITOR software version ID. This can be version 2 or later.

For a general explanation of monitor version choices, see MONITOR VERSION.

Monitor Privileges

To use this request, you must have any one of the following monitor privileges as part of your default role or any of these privileges must be granted directly to you:
  • ABORTSESSION
  • MONRESOURCE
  • MONSESSION
  • SETRESRATE
  • SETSESSRATE
For more information on roles and privileges, see:

Usage Notes - MONITOR VIRTUAL CONFIG

Information regarding vproc status is returned for all AMP, PE, and TVS vprocs in the system.

MONITOR VIRTUAL CONFIG is most useful when used with the MONITOR VIRTUAL SUMMARY request for doing a quick overall system health check. For more information, see Relationship Between MONITOR VIRTUAL CONFIG and MONITOR VIRTUAL SUMMARY.

If you use MONITOR VIRTUAL CONFIG, you do not need to dump out the DBC.SW_Event_Log table (accessible from the DBC.Software_Event_LogV view) to see if there is a physical problem with the system.

CLIv2 Response Parcels

The MONITOR VIRTUAL CONFIG request is treated internally as a two statement request with each statement generating a response. The two statement response returned from Teradata Database contains the following sequence of parcel types:

Parcel Sequence Parcel Flavor Length

(Bytes)

Comments/Key Parcel Body Fields
Success 8 18 to 273 StatementNo =1

ActivityCount = 1

ActivityType = 91 (PCLMONVCONFIG)

DataInfo 71 6 to 64100 Optional; this parcel is present if request was IndicData parcel.
Record 10
  • 5 to 64100 (record mode)
  • 6 to 64100 (indicator mode)
Depending on request (Data or IndicData), data is in record or indicator mode. This record contains the BYNET status data and the type of system running the Teradata Database software.
EndStatement 11 6 StatementNo = 2-byte integer
Success 8 18 to 273 StatementNo = 2

ActivityCount = Number of vprocs

ActivityType = 91 (PCLMONVCONFIG)

DataInfo 71 6 to 64100 Optional; this parcel is present if request was IndicData parcel.
Record 10
  • 5 to 64100 (record mode)
  • 6 to 64100 (indicator mode)
Depending on request (Data or IndicData), data is in record or indicator mode. This record contains the vproc-specific information; one record per vproc.
EndStatement 11 6 StatementNo = 2-byte integer
EndRequest 12 4 None

Response

Each of the statement types described below correspond to a ResultSet returned by the Teradata JDBC Driver, and each statement type field corresponds to a ResultSet column. For more information on ResultSets, see Teradata JDBC Driver Reference, available at https://developer.teradata.com/connectivity/reference/jdbc-driver .

Statement 1

The following table describes the order in which the Record parcel in the first statement of the MONITOR VIRTUAL CONFIG returns the BYNET status values and the system type.

Column Field/Column Name Data Type Description
1 NetAUp VARCHAR (1)

NOT NULL

Status of the BYNETs (if there are more than two, the first two) on a system-wide basis.
  • U = All node BYNETs are up/online.
  • D = One or more node BYNETs is down/offline.
  • “” = A temporary condition where the BYNET data is not available.
This output parameter is available on monitor software version 9 or later only.
2 NetBUp VARCHAR (1)

NOT NULL

Status of the BYNETs (if there are more than two, the first two) on a system-wide basis:
  • U = All node BYNETs are up/online.
  • D = One or more node BYNETs is down/offline.
  • “” = A temporary condition where the BYNET data is not available.
This output parameter is available on monitor software version 9 or later only.
3 SystemType VARCHAR (7)

NOT NULL

Type of system running the Teradata Database software, such as 5650, 6700, or ‘Other’.

If all the nodes in the system are the same type, this field returns the type of the system.

If any of the nodes are of a different type, this field returns ‘Mixed’.

This output parameter is available on monitor software version 9 or later only.

Statement 2

The Record parcels in the second statement of the MONITOR VIRTUAL CONFIG response return one record for each processor, with six fields in each record. Records are sorted based on VProcNo. For example, if you have 32 vprocs, 32 records are returned with specific information for each vproc, in addition to the one record of BYNET data for the whole system.

Field/Column Name Data Type Description
ProcId INTEGER ID associated with a node.

This value is computed as the module number within a cabinet plus the cabinet number times 10000. For example, a node #123 on cabinet #4 would return an INTEGER value of 40123.

VProcNo SMALLINT

NOT NULL

ID of an AMP (that is, a set of disk) and the associated tasks or processes that, in combination, make up the AMP), PE or TVS vproc.
VProcType VARCHAR (3)

NOT NULL

Type of vproc:
  • AMP
  • PE
  • MISC
HostId SMALLINT Logical host ID for the PEs. This field shows NULL for the AMP or TVS vprocs associated with this record. Each channel- or TCP/IP network-connected host is assigned an ID at the time the system is configured. Each PE is assigned to a (single) channel-connected host (or client) or a TCP/IP network-connected host. The host ID of zero is reserved for the PEs processing internal sessions.
Status VARCHAR (1)

NOT NULL

Status of the vproc associated with this record. A vproc is considered up or down from the standpoint of whether the vproc is helping a query process SQL statements. For example, an AMP doing offline recovery is considered to be down because the AMP is not helping to process SQL statements. On the other hand, an up vproc is one that is online and fully up or is in online recovery.
The status of the vproc:
  • U = The vproc is up/online.
  • D = The vproc is down/offline.
DiskSlice SMALLINT Virtual disk ID defining the portion of a physical disk assigned to an AMP.

This value is NULL for TVS vprocs.

Sample Input - CLIv2 Request

This example shows how the parcels for a MONITOR VIRTUAL CONFIG request, built by CLIv2, appear when sent to the Teradata Database server. In this example, the size of the response buffer is set at the maximum (64,000 bytes), although you can set it to any size. However, a minimum response size is 32,000 bytes.

Flavor Length Body
Num Name Bytes Field Value
0001 Req 26 Request MONITOR VIRTUAL CONFIG
0003 Data 6 MonVerID 2
0004 Resp 6 BufferSize 64000

Sample Input - Teradata JDBC Driver Request

For an example of how the PM/API request, built in Java, appears when sent to the Teradata Database server, see Teradata JDBC Driver Reference, available at https://developer.teradata.com/connectivity/reference/jdbc-driver .

Sample Output

This example shows the values returned in character text format for the MONITOR VIRTUAL CONFIG request. Your application program may display returned values in a different format.

Submitting request MONITOR VIRTUAL CONFIG; ...

NetAUp:  U NetBUp:  U
SystemType: 5500C

8 vproc(s) found

ProcId          Node Loc        VProcNo VProcType       HostId  Status  DiskSlice
========        ========        ======= =========       ======  ======  =========
10001           (1-1)           0       AMP             0       U       0
10001           (1-1)           1       AMP             0       U       1
10001           (1-1)           2       AMP             0       U       2
10001           (1-1)           3       AMP             0       U       3
10001           (1-1)           28670   TVS             0       U       0
10001           (1-1)           28671   TVS             0       U       0
10001           (1-1)           30718   PE              1       U       0
10001           (1-1)           30719   PE              1       U       0

Relationship Between MONITOR VIRTUAL CONFIG and MONITOR VIRTUAL SUMMARY

Use MONITOR VIRTUAL SUMMARY with the MONITOR VIRTUAL CONFIG request for an overall system status. These are low overhead requests.
  • Execute the MONITOR VIRTUAL SUMMARY request every 5 or 10 minutes for a low-cost, continuous monitoring of your system.
  • Execute the MONITOR VIRTUAL CONFIG request to get a picture of your system configuration at defined times, such as at the beginning of a day, various times during the day, or when the system is down.

Using these requests to spot problems, such as abnormal AMP CPU load balancing, and possible sources of system performance bottlenecks. For example, if the HiCPUAMPUse, HiCPUPEUse, LoCPUAMPUse, and LoCPUPEUse figures are consistently widely separated and do not approximate the AMPAvgCPU figure, you may need to evaluate whether the system is using available resources efficiently. Alternatively, if the PEAvgCPU is consistently much higher than the AMPAvgCPU, the system may not be configured to efficiently use AMP resources. How often you perform a health check of your system depends on the size of your system and the type of applications run.

Knowledge of the overall system status can help you to determine:

Concern Comments
When to run production applications, especially large ones For example, if you have a down AMP, you may decide that it is less costly to recover the AMP first and run the job than to run the job without full system availability.
Why an application runs more slowly than usual This situation may be caused by a down AMP, which results in the backup AMP doing more work, specifically, doing backup and primary processing. This, in turn, could cause your application to run more slowly.
Whether all vprocs have come back up after a system restart Examine the Status value returned in a MONITOR VIRTUAL CONFIG request to determine whether each vproc is up or down (see the MONITOR VIRTUAL CONFIG Status field).

The response data returned by MONITOR VIRTUAL CONFIG is similar in content to the response data returned by a MONITOR VIRTUAL RESOURCE request, but it is in an abbreviated form. In your initial problem analysis, if the information returned from a MONITOR VIRTUAL SUMMARY query does not give you enough data. For example, you need BYNET or CPU% busy information and you may want to use MONITOR VIRTUAL RESOURCE to obtain more detailed resource usage data.