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
- ABORTSESSION
- MONRESOURCE
- MONSESSION
- SETRESRATE
- SETSESSRATE
- Teradata Vantage™ - Database Administration, B035-1093
- Teradata Vantage™ - Advanced SQL Engine Security Administration, B035-1100
- Teradata JDBC Driver Reference, available at https://teradata-docs.s3.amazonaws.com/doc/connectivity/jdbc/reference/current/frameset.html
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 |
|
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 |
|
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
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:
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:
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:
A node is up (U) when it is:
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:
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:
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.
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.
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
- 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.
- 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).