15.10 - MONITOR PHYSICAL CONFIG - Teradata Database

Teradata Database Application Programming Reference

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

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

 

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.

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 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
  • 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” on page 90.

    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.

    The MONITOR PHYSICAL CONFIG request is treated internally as a two statement request, with each statement generating a response. Teradata 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 Database 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 or Teradata Call-Level Interface Version 2 Reference for Workstation-Attached Systems. Within the parcel body fields, the order of items and their data types and lengths are determined by the USING Phrase.

    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 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.
  • 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.

    4

    SystemName

    VARCHAR(15)

    Name of the system running Teradata.

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

    SMALLINT,
    NOT NULL

    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.

    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 Teradata 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 Database software, such as 5650, 6700, or ‘Other’.

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

    CliqueNo

    SMALLINT,
    NOT NULL

    Clique number of the node.

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

    Note: If you are using MONITOR software version ID (mon_ver_id) 10 or earlier, this output parameter is not available.

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

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

    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.

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

    Note: Your application program may display returned values in a different format.

    NetAUp:  U NetBUp:  U
    SystemType: 5500C
    SystemName: localhost
     
    1 node(s) found
     
    ProcId:      33   Status:  U   CPUType: Xeon     CPUCount: 1
    SystemType: 5500C
    CliqueNo: 0
    NetAUp:  U NetBUp:  U
    PhyMemory: 5720

    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.

    Note: The MONITOR PHYSICAL CONFIG and MONITOR PHYSICAL SUMMARY requests do not return the status of non-Teradata 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 Teradata 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).