15.10 - MONITOR VIRTUAL CONFIG - Teradata Database

Teradata Database Application Programming Reference

prodname
Teradata Database
vrm_release
15.10
category
Programming Reference
featnum
B035-1090-151K

Collects information on virtual processor (vproc) availability.

 

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.

Note: 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” on page 162.

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:

  • Database Administration
  • Security Administration
  • Teradata JDBC Driver User Guide
  • 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” on page 170.

    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.

    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

    Note: 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.

    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.
  • Note: 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.
  • Note: 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’.

    Note: 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

    SMALLINT

    ID associated with a node. This value is computed as the module number within a cabinet plus 100 times the cabinet number. Usually formatted for display as zz9-99. However, this display format can be changed by the user.

    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.

    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

    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.

    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.

    Success parcel:
     StatementNo: 1    ActivityCount: 1
     ActivityType: 91    FieldCount: 3
    DataInfo parcel:
     FieldCount: 3
    Record parcel.
     Parcel flavor:        10    Parcel body length:   10
     NetAUp = 'U',  NetBUp = 'U',  SystemType = "6700 ".
    EndStatement.
    Success parcel:
     StatementNo: 2    ActivityCount: 20
     ActivityType: 91    FieldCount: 6
    DataInfo parcel:
     FieldCount: 6
    Record parcel.
     Parcel flavor:        10    Parcel body length:   13
     NodeId = 746,  VProcNo = 0,  VProcType = "AMP",  HostId = <null>,
     VProcStatus = 'U',  DiskSlice = 0.
    Record parcel.
     Parcel flavor:        10    Parcel body length:   13
     NodeId = 736,  VProcNo = 1,  VProcType = "AMP",  HostId = <null>,
     VProcStatus = 'U',  DiskSlice = 1.
    Record parcel.
     Parcel flavor:        10    Parcel body length:   13
     NodeId = 746,  VProcNo = 2,  VProcType = "AMP",  HostId = <null>,
     VProcStatus = 'U',  DiskSlice = 2.
    Record parcel.
     Parcel flavor:        10    Parcel body length:   13
     NodeId = 736,  VProcNo = 3,  VProcType = "AMP",  HostId = <null>,
     VProcStatus = 'U',  DiskSlice = 3.
    Record parcel.
     Parcel flavor:        10    Parcel body length:   13
     NodeId = 746,  VProcNo = 4,  VProcType = "AMP",  HostId = <null>,
     VProcStatus = 'U',  DiskSlice = 4.
    Record parcel.
     Parcel flavor:        10    Parcel body length:   13
     NodeId = 736,  VProcNo = 5,  VProcType = "AMP",  HostId = <null>,
     VProcStatus = 'U',  DiskSlice = 5.
    Record parcel.
     Parcel flavor:        10    Parcel body length:   13
     NodeId = 746,  VProcNo = 6,  VProcType = "AMP",  HostId = <null>,
     VProcStatus = 'U',  DiskSlice = 6.
    Record parcel.
     Parcel flavor:        10    Parcel body length:   13
     NodeId = 736,  VProcNo = 7,  VProcType = "AMP",  HostId = <null>,
     VProcStatus = 'U',  DiskSlice = 7.
    Record parcel.
     Parcel flavor:        10    Parcel body length:   13
     NodeId = 746,  VProcNo = 8,  VProcType = "AMP",  HostId = <null>,
     VProcStatus = 'U',  DiskSlice = 8.
    Record parcel.
     Parcel flavor:        10    Parcel body length:   13
     NodeId = 736,  VProcNo = 9,  VProcType = "AMP",  HostId = <null>,
     VProcStatus = 'U',  DiskSlice = 9.
    Record parcel.
     Parcel flavor:        10    Parcel body length:   13
     NodeId = 746,  VProcNo = 10,  VProcType = "AMP",  HostId = <null>,
     VProcStatus = 'U',  DiskSlice = 10.
    Record parcel.
     Parcel flavor:        10    Parcel body length:   13
     NodeId = 736,  VProcNo = 11,  VProcType = "AMP",  HostId = <null>,
     VProcStatus = 'U',  DiskSlice = 11.
    Record parcel.
     Parcel flavor:        10    Parcel body length:   13
     NodeId = 746,  VProcNo = 12,  VProcType = "AMP",  HostId = <null>,
     VProcStatus = 'U',  DiskSlice = 12.
    Record parcel.
     Parcel flavor:        10    Parcel body length:   13
     NodeId = 736,  VProcNo = 13,  VProcType = "AMP",  HostId = <null>,
     VProcStatus = 'U',  DiskSlice = 13.
    Record parcel.
     Parcel flavor:        10    Parcel body length:   13
     NodeId = 746,  VProcNo = 14,  VProcType = "AMP",  HostId = <null>,
     VProcStatus = 'U',  DiskSlice = 14.
    Record parcel.
     Parcel flavor:        10    Parcel body length:   13
     NodeId = 736,  VProcNo = 15,  VProcType = "AMP",  HostId = <null>,
     VProcStatus = 'U',  DiskSlice = 15.
    Record parcel.
     Parcel flavor:        10    Parcel body length:   13
     NodeId = 746,  VProcNo = 1020,  VProcType = "PE ",  HostId = 52,
     VProcStatus = 'U',  DiskSlice = <null>,
    Record parcel.
     Parcel flavor:        10    Parcel body length:   13
     NodeId = 746,  VProcNo = 1021,  VProcType = "PE ",  HostId = 52,
     VProcStatus = 'U',  DiskSlice = <null>,
    Record parcel.
     Parcel flavor:        10    Parcel body length:   13
     NodeId = 736,  VProcNo = 1022,  VProcType = "PE ",  HostId = 52,
     VProcStatus = 'U',  DiskSlice = <null>,
    Record parcel.
     Parcel flavor:        10    Parcel body length:   13
     NodeId = 736,  VProcNo = 1023,  VProcType = "PE ",  HostId = 52,
     VProcStatus = 'U',  DiskSlice = <null>,
    EndStatement.
    EndRequest.

    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.