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
- ABORTSESSION
- MONRESOURCE
- MONSESSION
- SETRESRATE
- SETSESSRATE
- Using Roles to Manage User Privileges
- Teradata JDBC Driver Reference, available at https://teradata-docs.s3.amazonaws.com/doc/connectivity/jdbc/reference/current/frameset.html
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 need not 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 the database contains the following sequence of parcel types:
| Parcel Sequence | Parcel Number | 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 |
|
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 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 |
|
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
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.
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 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 and 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 returns 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:
|
| 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. However, an up vproc is one that is online and fully up or is in online recovery. The status of the vproc:
|
| 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 database server. In this example, the size of the response buffer is set at the maximum (64,000 bytes). The minimum response size is 32,000 bytes.
| Number | 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 database server, see Teradata JDBC Driver Reference, available at https://teradata-docs.s3.amazonaws.com/doc/connectivity/jdbc/reference/current/frameset.html.
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
- Run the MONITOR VIRTUAL SUMMARY request every 5 or 10 minutes for a low-cost, continuous monitoring of your system.
- Run the MONITOR VIRTUAL CONFIG request to get a picture of your system configuration at defined times, such as at the beginning of a day, different 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 recovering the AMP first and then running the job is less costly than running the job without full system availability. |
| Why an application runs more slowly than usual | This situation may be caused by a down AMP, which makes the backup AMP do more work (backup and primary processing). This can 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 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 get more detailed resource usage data.