This section describes the Teradata Dynamic Workload Management interfaces that use CLIv2 or the Teradata JDBC Driver. These interfaces are referred to as PM/API requests.
For details on using the Teradata JDBC Driver requests, see Teradata JDBC Driver Reference, available at https://teradata-docs.s3.amazonaws.com/doc/connectivity/jdbc/reference/current/frameset.html .
Before using the System PMPC PM/APIs, read the following topic on the impact of object name length on PM/API requests.
Impact of Object Name Length on PM/API Requests
Object names contain 128 Unicode characters; however, to use object names of 128 characters, applications must use monitor software version 10 or later.
|If your custom application uses monitor software version ...||The object field in the input area can be ...|
|8 or earlier||CHAR(30). A fixed parcel field size of 30 bytes. The names must be padded with spaces.
For more information on monitor software version 8 or earlier, see previous releases of Workload Management API: PM/API and Open API.
|9||VARCHAR(120). A parcel field size of up to 120 bytes in variable length.
For more information about monitor software version 9, see Application Programming Reference: Workload Management.
|10 or later||VARCHAR(512). A parcel field size of up to 512 bytes in variable length in host character set format.|
Depending on the version of your custom application, some of the PM/API request output fields for object names may be truncated. For example, if the output field is an object name of 100 bytes in length when converted to host character set format, and you are using a PM/API request with monitor software version 8 or earlier, the database name will be truncated to fit the fixed parcel field size of 30 bytes.
Common Warning and Error Messages
Most of the monitor requests covered in this section depend on periodic collection of data. When this collection process is disturbed, the returned data can temporarily become confusing or inaccurate.
If this happens, the user receives a warning message indicating that the data returned may not give a true picture of system or user activity.
- The data returned may have been affected by a system restart or a single processor recovery. Resource/session usage values may not be realistic until requests on the database re-attain their normal level of activity.
- Data may also be incomplete in cases where:
- A full data collection period has not transpired since the database has gone through a recovery.
- A full data collection period has not transpired since the related monitoring rate was changed.
For more detailed information on warning and error messages, see Teradata Vantage™ - Database Messages, B035-1096.
Errors Resulting from PMPC Subsystem Failures
PMPC fault isolation provides automatic recovery from internal software errors or faults in System PMPC tasks. This significantly reduces the cases in which the PMPC subsystem must be shut down because of internal software errors or faults in PMPC modules. The PMPC subsystem continues to be available after clean up of local resources, in most cases.
When an internal software error or a fault occurs in PMPC tasks, all current MONITOR partition sessions are forced off with an error and logons to the MONITOR partition are temporarily disabled while the PMPC subsystem recovery is in progress. After the recovery is complete the logons to the MONITOR partition are re-enabled. The PMPC subsystem recovery is expected to take up to 3 minutes on a system with a normal workload.