MONITOR PHYSICAL CONFIG Request | Application Programming Reference | Vantage - MONITOR PHYSICAL CONFIG - Advanced SQL Engine - Teradata Database

Application Programming Reference

Product
Advanced SQL Engine
Teradata Database
Release Number
17.10
Published
July 2021
Language
English (United States)
Last Update
2021-07-27
dita:mapPath
hvk1593628831140.ditamap
dita:ditavalPath
hvk1593628831140.ditaval
dita:id
B035-1090
lifecycle
previous
Product Category
Teradata Vantage™

Collects overall information on node availability. Node status information is returned for all nodes in the system.

Input Data

Element Data Type Description
IndByte BYTE Indicator bits that specify which fields to treat as NULL if using 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 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 PHYSICAL CONFIG

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

You can use the MONITOR PHYSICAL CONFIG request instead of dumping the DBC.SW_Event_Log table (accessible from the DBC.Software_Event_LogV view) to check for a physical problem with the system.

CLIv2 Response Parcels

The MONITOR PHYSICAL CONFIG request is treated internally as a two statement request, with each statement generating a response. The database returns the two statement response containing the following sequence of parcels.

Parcel Sequence Parcel Flavor Length (Bytes) Comments/Key Parcel Body Fields
Success 8 18 to 273 StatementNo = 1

ActivityCount = 1

ActivityType = 92 (PCLMONPCONFIG)

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 Vantage software.
EndStatement 11 6 StatementNo = 2-byte integer
Success 8 18 to 273 StatementNo = 2

ActivityCount = Number of nodes

ActivityType = 92 (PCLMONPCONFIG)

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. Multiple record parcels are returned that consist of a record for each node in the system. This record contains node-specific information; one record per node.
EndStatement 11 6 StatementNo = 2-byte integer
EndRequest 12 4 None

For descriptions of the flavor field and length field, see Teradata® Call-Level Interface Version 2 Reference for Mainframe-Attached Systems, B035-2417 or Teradata® Call-Level Interface Version 2 Reference for Workstation-Attached Systems, B035-2418. Within the parcel body fields, the order of items and their data types and lengths are determined by the USING Phrase.

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://teradata-docs.s3.amazonaws.com/doc/connectivity/jdbc/reference/current/frameset.html.

Statement 1

The Record parcel in the first statement of the MONITOR PHYSICAL CONFIG response returns the following values:

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 Vantage 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.
4 SystemName VARCHAR(15) Name of the system running Teradata.
If you are using MONITOR software version ID (mon_ver_id) 10 or earlier, this output parameter is not available.

Statement 2

The response to the second statement results in multiple Record parcels that consist of a record for each node in the system. For example, if you have two nodes, two records are returned with specific information for each processor.

Records are sorted based on NodeID. The following table shows the order in which the Record parcel returns the data.

Field/Column Name Data Type Description
ProcId INTEGER

NOT NULL

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.

Status VARCHAR(1) NOT NULL Status of the node associated with this record:
  • U = Up/online
  • D = Down/offline
  • S = Standby
A node is up (U) when it is:
  • Configured into the system
  • Online
  • Capable of actively performing tasks associated with normal database activity

Down (D) represents all other potential states.

Standby (S) indicates the node is ready to join the configuration in place if another node goes down. When the node status is Standby, the SystemType, NetAUp, and NetBUp fields are not available and NULL or spaces will be returned.

CPUType VARCHAR (7)

NOT NULL

Type of central processing unit (CPU) installed in this node , for example, ‘Pentium’, ‘PentPro’, or ‘Unknown’.
CPUCount INTEGER

NOT NULL

Number of CPUs in this node.
SystemType VARCHAR (7) Type of system running the Teradata Vantage software, such as 5650, 6700, or ‘Other’.
This output parameter is available on monitor software version 9 or later only.
CliqueNo SMALLINT

NOT NULL

Clique number of the node.
This output parameter is available on monitor software version 9 or later only.
NetAUp VARCHAR(1) Status of the BYNETs (if there are more than two, the first two) on a system-wide basis:
  • U = Node BYNET is up/online.
  • D = Node BYNET 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.
NetBUp VARCHAR(1) Status of the BYNETs (if there are more than two, the first two) on a system-wide basis:
  • U = Node BYNET is up/online.
  • D = Node BYNET 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.
PhyMemory INTEGER Size of the physical memory of the node in MBs.
If you are using MONITOR software version ID (mon_ver_id) 10 or earlier, this output parameter is not available.

Sample Input - CLIv2 Request

The following example shows how the parcels for a MONITOR PHYSICAL CONFIG request, built by CLIv2, look when sent to the database server.

In the following 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 27 Request MONITOR PHYSICAL CONFIG
0003 Data 6 MonVerID 9
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 database server, see Teradata JDBC Driver Reference, available at https://teradata-docs.s3.amazonaws.com/doc/connectivity/jdbc/reference/current/frameset.html.

Sample Output

Using monitor software version ID 11, this request might return the following values in character text format.

Your application program may display returned values in a different format.
Submitting request MONITOR PHYSICAL CONFIG; ...

NetAUp:  U NetBUp:  U
SystemType: 5500C
SystemName: localhost

1 node(s) found

ProcId:    10001 (1-1) Status: [ U]   CPUType: [Xeon   ]  CPUCount: 1
SystemType: [5500C  ]
CliqueNo: 0
NetAUp: [  ] NetBUp: [  ]
PhyMemory: 5720

Relationship Between MONITOR PHYSICAL CONFIG and MONITOR PHYSICAL SUMMARY

Use the MONITOR PHYSICAL SUMMARY request with the MONITOR PHYSICAL CONFIG request for an overall system status. These are low overhead requests.
  • Execute the MONITOR PHYSICAL SUMMARY request every 5 or 10 minutes for a low-cost, continuous monitoring of your system.
  • Execute the MONITOR PHYSICAL 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.

Use these requests to spot problems, such as abnormal Central Processing Unit (CPU) load balancing, and possible sources of system performance bottlenecks. For example, if the High/LowCPUUse figures are consistently widely separated and do not approximate the AvgCPU figure, you may need to evaluate whether the system is using available resources efficiently. How often you check your system depends on the size of your system and the type of applications your system runs.

Knowledge of the overall system status can help you to determine these three concerns.

Concern Comments
When to run production applications, especially large ones For example, if you have a down node, some Access Module Processors (AMPs) and Parsing Engines (PEs) may migrate to other nodes. It may be less costly to recover the node 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 node, which causes the online nodes to run more than the optimal number of AMPs and PEs. This, in turn, could cause your application to run more slowly.
Whether all nodes have come back up after a system restart Examine the Status value returned in a MONITOR PHYSICAL CONFIG request to determine whether each node is up or down.

If the data returned from a MONITOR PHYSICAL SUMMARY query does not give you enough information (for example, you need BYNET or CPU% busy information), use the MONITOR PHYSICAL RESOURCE request to obtain more detailed resource usage data.

The data returned by the MONITOR PHYSICAL CONFIG request is an abbreviated form of the data returned by the MONITOR PHYSICAL RESOURCE request.

The MONITOR PHYSICAL CONFIG and MONITOR PHYSICAL SUMMARY requests do not return the status of non-database nodes. However, the MONITOR PHYSICAL RESOURCE and MONITOR PHYSICAL SUMMARY requests accumulate and return data on some resources consumed by non-Teradata applications running on database nodes. To determine the resources consumed by non-Teradata applications, compare:
  • Data returned by the MONITOR PHYSICAL RESOURCE request with that of the MONITOR VIRTUAL RESOURCE request (that is, the subtotal of the various resource statistics by node).
  • Data returned by the MONITOR PHYSICAL SUMMARY request with that of the MONITOR VIRTUAL SUMMARY request (that is, the subtotal/average by node of the various resource statistics in the MONITOR VIRTUAL SUMMARY).