Returns the step information (that is, a scaled-down version of the output of the EXPLAIN request modifier) of the current or running request for the specified host, session, and vproc.
Input Data
Element | Data Type | Description |
---|---|---|
IndByte | BYTE | Indicator bits that
specify which fields to treat as NULL if you are 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 3 or later. For a general explanation of monitor version choices, see MONITOR VERSION. |
host_id | SMALLINT NOT NULL |
Logical ID of a host (or client) with sessions logged on. host_id cannot exceed 1023 bytes. A host _id of zero identifies the system Console ID of the host on which the sessions are running. |
session_no | INTEGER NOT NULL |
Session number. The session number combined with the host_id represents a unique session ID. |
RunPEVprocNo | SMALLINT NOT NULL |
PE vproc number where the session runs. This is typically from the MONITOR SESSION response of the RunVprocNo field. See the MONITOR SESSION RunVprocNo field for more information. |
Monitor Privileges
To use this request, you must have the MONSESSION privilege as part of your default role or this privilege must be granted directly to you.
- 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 SQL
Before using this request, see Impact of Object Name Length on PM/API Requests.
When issuing a MONITOR SQL request, you must specify a minimum buffer size of 32,007 bytes or more. For custom applications, an error message may appear.
- A problematic query is using a large amount of system resources. Use of this feature provides the associated SQL text to the system administrator to help identify possible bottlenecks, hardware problems and bugs. The query text and DDL statements can also be forwarded to Teradata Support for help in diagnosing the problem.
- The information provided by this request can help to identify specific SQL problems, such as poorly structured tables and indexes.
- Problems can even be traced down to the individual step within a query.
The MONITOR SQL request may not be used on internal sessions or sessions that are logged onto the monitor. Request text and steps text are not stored for these types of sessions, and if an attempt is made to query one, an error is returned, indicating that the session is not an SQL session.
Ending processing is handled in the same way as when using the MONITOR SESSION request. See MONITOR SESSION.
If MONITOR SQL processing is not completed within the timeout interval, an error is returned to the client application. When a MONITOR SQL request is timed out, the processing continues internally to its completion. If the client application submits a new MONITOR SQL request for the same timed out target session while the previous timed out one is still being processed, an error is returned.
The default timeout interval is 60 seconds.
MONITOR SQL 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.
CLIv2 Response Parcels
The MONITOR SQL request is treated internally as a three statement request, with each statement generating a response. The three-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 = 110 (PCLMONSQL) |
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 text of the SQL request (see Statement 1). |
EndStatement | 11 | 6 | StatementNo = 2-byte integer |
Success | 8 | 18 to 273 | StatementNo = 2 ActivityCount = 1 ActivityType = 110 (PCLMONSQL) |
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 step count information (see Statement 2). |
EndStatement | 11 | 6 | StatementNo = 2-byte integer |
Success | 8 | 18 to 273 | StatementNo = 3 ActivityCount = Number of EXPLAIN steps ActivityType = 110 (PCLMONSQL) |
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. Each record contains step resource information (see Statement 3). |
EndStatement | 11 | 6 | StatementNo = 2-byte integer |
EndRequest | 12 | 4 | None |
Response
Statement 1
The response to the first statement returns a Record parcel that contains the SQL request text.
Field/Column Name | Data Type | Description |
---|---|---|
RequestText | VARCHAR (64000) | Actual SQL request for a specified session. A RequestText of 64001 bytes or more splits into multiple records. A variable number of characters up to 64000 is returned depending on the character set of the session. If needed, the request context is split into multiple rows such that each row does not exceed 64000 bytes.
|
Statement 2
The response to the second statement returns information regarding the total number of steps and which steps are executing.
Field/Column Name | Data Type | Description |
---|---|---|
NumOfSteps | SMALLINT NOT NULL |
Number of steps contained in the
description text in the third statement of the response. If this is a static plan (that is, when the DynamicPlan field value is zero), NumOfSteps is the total number of steps for the static plan. If this is a complete dynamic plan (that is, when the DynamicPlan field value is 1 and the PartialSteps field value is zero), NumOfSteps is the total number of steps for the dynamic plan. If this is a partial dynamic plan (that is, when both of the DynamicPlan and PartialSteps field values are 1), NumOfSteps is the total number of steps generated. This value is less than the total number of steps generated for the entire dynamic plan. If this is a request with a dynamic plan that has been throttled and is in the delay queue (that is, when the DynamicPlan and PartialSteps field values are 1 and no rows are returned in response to the third statement), NumOfSteps is zero. For more information, see the MONITOR SQL DynamicPlan and PartialSteps fields. |
CurLev1StepNum | SMALLINT NOT NULL |
Number of the running level 1 step. If parallel steps are running, this value is the number of the lowest executing step. If this is a request with a dynamic plan that has been throttled and is in the delay queue (for example, when the NumOfSteps field value is zero and both the DynamicPlan are PartialSteps field values are 1), the CurLev1StepNum field value is zero. |
CurLev2StepNum | SMALLINT NOT NULL |
Number of the running step. If parallel steps are running, this value is the number of the highest executing step. If this is a request with a dynamic plan that has been throttled and is in the delay queue (for example, when the NumOfSteps field value is zero and both the DynamicPlan are PartialSteps field values are 1), the CurLev2StepNum field value is 1. |
DynamicPlan | SMALLINT | Plan type:
For more information on static and dynamic explanations of a request, see EXPLAIN Request Modifier or EXPLAIN Request Modifier. |
PartialSteps | SMALLINT | Possible values:
A value 1 cannot occur for a static plan.
See STATIC EXPLAIN and DYNAMIC EXPLAIN. |
ZoneId | INTEGER NULLLABLE |
The unique identifier of the zone. |
SPName | VARCHAR(128) CHARACTER SET UNICODE |
This is the outer stored procedure name, if a stored procedure is running. NULL is returned in indicator mode if no stored procedure is running. |
SPDBName | VARCHAR(128) CHARACTER SET UNICODE |
This is the owner database name of the outer stored procedure, if a stored procedure is running. NULL is returned in indicator mode if no stored procedure is running. |
DefaultDBName | VARCHAR(128) CHARACTER SET UNICODE NOT NULL |
This field returns the default database name of the session at the start of a non-stored procedure request. For stored procedures, this field returns the default database name of the session when the stored procedure was compiled. |
Statement 3
The response to the third statement returns a Record parcel that contains the step text for a given request. Each step returns a separate row. This parcel description has changed from the version 3 parcel. The response parcel received is contingent on whether you set mon_ver_id 3 or mon_ver_id 4. The values returned vary in format and content depending on the value of mon_ver_id used.
If mon_ver_id 3 is set, the response to the third statement returns a Record parcel that contains the following steps text for a given request.
Field/Column Name | Data Type | Description |
---|---|---|
StepNum | SMALLINT NOT NULL |
Unique number identifying the EXPLAIN step. |
StepText | VARCHAR (2048) CHARACTER SET
UNICODE NOT NULL |
Generated text of the step. |
If mon_ver_id 4 is set, the response to the third statement returns a Record parcel that contains the following steps text for a given request.
Field/Column Name | Data Type | Description |
---|---|---|
StepNum | SMALLINT NOT NULL |
Unique number identifying the EXPLAIN step. |
Confidence | SMALLINT NOT NULL |
Confidence level as determined by
the optimizer:
|
EstRowCount | FLOAT NOT NULL |
Estimated row count generated from the Optimizer plan for this step. For a hybrid join method, also called a partial redistribution and partial duplication (PRPD) plan, the EstRowCount field for the split step (that is, a RETRIEVE or JOIN step with “split into” appearing in the EXPLAIN when target spools are generated) is the estimated row counts for all split spools. |
ActRowCount | FLOAT NOT NULL |
Actual row count returned from the AMP for this step. For a PRPD plan, this value includes rows from all split spools for a split step. |
EstElapTime | FLOAT NOT NULL |
Estimated time for the query as generated from the Optimizer plan. |
ActElapTime | FLOAT NOT NULL |
Actual elapsed time calculated by the dispatcher. |
StepText | VARCHAR (2048) CHARACTER SET UNICODE NOT NULL |
Generated text of the step. |
The estimated fields populate immediately. The low value supplied by the optimizer is used. The actual fields are populated at the same time with "-1". After the step runs, the actual values (or a zero for those kinds of steps with no row count) are placed in the actual fields to identify those steps that are run at the time of the API information capture.
Sample Input - CLIv2 Request
This example shows how the parcels for a MONITOR SQL 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 | 16 | Request | MONITOR SQL |
0003 | Data | 12 | MonVerID HostId SessionNo RunPEVprocNo |
3 1 1002 16383 |
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 SQL request. Your application program may display returned values in a different format.
The following is an Explain of a CREATE DATABASE SQL statement.
EXPLAIN CREATE DATABASE testdb AS PERM=1E6; Explanation ---------------------------------------------------------------------- 1) First, we lock data base testdb for exclusive use. 2) Next, we lock DBC.UIFDEPENDENCY for write on a reserved RowHash to prevent global deadlock. 3) We lock DBC.DataBaseSpace for write on a reserved RowHash to prevent global deadlock. 4) We lock DBC.Parents for write on a reserved RowHash to prevent global deadlock. 5) We lock DBC.Owners for write on a reserved RowHash to prevent global deadlock. 6) We lock DBC.AccessRights for write on a reserved RowHash in all partitions to prevent global deadlock. 7) We lock DBC.UIFDEPENDENCY for write, we lock DBC.DataBaseSpace for write, we lock DBC.Parents for write, we lock DBC.Owners for write, we lock DBC.DBase for write on a RowHash, we lock DBC.DBase for write on a RowHash, we lock DBC.Accounts for write on a RowHash, and we lock DBC.AccessRights for write. 8) We execute the following steps in parallel. 1) We do a single-AMP ABORT test from DBC.DBase by way of the unique primary index "Field_1 = 'TESTDB'" with no residual conditions. 2) We do a single-AMP ABORT test from DBC.Roles by way of the unique primary index "Field_1 = 'TESTDB'" with no residual conditions. 3) We do a single-AMP ABORT test from DBC.DBase by way of the unique primary index "Field_1 = 'DBC'" with a residual condition of ("DBC.DBase.Field_18 = 47"). 4) We do a single-AMP ABORT test from DBC.DBase by way of the unique primary index "Field_1 = 'DBC'" with a residual condition of ("1.00000000000000E 006 <= DBC.DBase.Field_10"). 5) We do an INSERT into DBC.DBase. 6) We do a single-AMP UPDATE from DBC.DBase by way of the unique primary index "Field_1 = 'DBC'" with no residual conditions. 7) We do a single-AMP RETRIEVE step from DBC.Parents by way of the primary index "Field_1 = '00000100'XB" with no residual conditions into Spool 1 (all_amps), which is redistributed by the hash code of (DBC.Parents.Field_2) to few AMPs. Then we do a SORT to order Spool 1 by row hash. 9) We do an all-AMPs MERGE into DBC.Owners from Spool 1 (Last Use). 10) We execute the following steps in parallel. 1) We do an INSERT into DBC.Owners. 2) We do a single-AMP RETRIEVE step from DBC.Parents by way of the primary index "Field_1 = '00000100'XB" with no residual conditions into Spool 2 (all_amps), which is redistributed by the hash code of ('00000404'XB) to few AMPs. Then we do a SORT to order Spool 2 by row hash. 11) We do an all-AMPs MERGE into DBC.Parents from Spool 2 (Last Use). 12) We execute the following steps in parallel. 1) We do an INSERT into DBC.Parents. 2) We do an INSERT into DBC.Accounts. 3) We do a single-AMP RETRIEVE step from a single partition of DBC.AccessRights by way of the primary index "Field_1 = '00000000'XB, Field_2 = '00000000'XB, Field_3 = '000000000000'XB" with a residual condition of ( "(DBC.AccessRights.Field_5 <> 'ZO') AND ((DBC.AccessRights.Field_5 <> 'DZ') AND ((DBC.AccessRights.Field_5 <> 'CZ') AND ((DBC.AccessRights.Field_5 <> 'OR') AND ((DBC.AccessRights.Field_5 <> 'OA') AND ((DBC.AccessRights.Field_5 <> 'DS') AND ((DBC.AccessRights.Field_5 <> 'CS') AND ((DBC.AccessRights.Field_5 <> 'OD') AND ((DBC.AccessRights.Field_5 <> 'OU') AND ((DBC.AccessRights.Field_5 <> 'OS') AND ((DBC.AccessRights.Field_5 <> 'OI') AND ((DBC.AccessRights.Field_5 <> 'SA') AND ((DBC.AccessRights.Field_5 <> 'SD') AND ((DBC.AccessRights.Field_5 <> 'GM') AND ((DBC.AccessRights.Field_5 <> 'GD') AND ((DBC.AccessRights.Field_5 <> 'GC') AND ((DBC.AccessRights.Field_5 <> 'OP') AND ((DBC.AccessRights.Field_5 <> 'AE') AND ((DBC.AccessRights.Field_5 <> 'CE') AND ((DBC.AccessRights.Field_5 <> 'DO') AND ((DBC.AccessRights.Field_5 <> 'CO') AND ((DBC.AccessRights.Field_5 <> 'DR') AND ((DBC.AccessRights.Field_5 <> 'CR') AND ((DBC.AccessRights.Field_5 <> 'AP') AND ((DBC.AccessRights.Field_5 <> 'UM') AND ((DBC.AccessRights.Field_5 <> 'UT') AND ((DBC.AccessRights.Field_5 <> 'UU') AND ((DBC.AccessRights.Field_5 <> 'SH') AND ((DBC.AccessRights.Field_5 <> 'EF') AND ((DBC.AccessRights.Field_5 <> 'AF') AND ((DBC.AccessRights.Field_5 <> 'CF') AND ((DBC.AccessRights.Field_5 <> 'PE') AND ((DBC.AccessRights.Field_5 <> 'NT') AND ((DBC.AccessRights.Field_5 <> 'PC') AND ((DBC.AccessRights.Field_5 <> 'TH') AND ((DBC.AccessRights.Field_5 <> 'RO') AND ((DBC.AccessRights.Field_5 <> 'IX') AND ((DBC.AccessRights.Field_5 <> 'RF') AND ((DBC.AccessRights.Field_5 <> 'AS') AND ((DBC.AccessRights.Field_5 <> 'SR') AND ((DBC.AccessRights.Field_5 <> 'SS') AND ((DBC.AccessRights.Field_5 <> 'MR') AND ((DBC.AccessRights.Field_5 <> 'MS') AND (DBC.AccessRights.Field_3 = '000000000000'XB)))))))))))))))))))))))))))))))))))))))))))") into Spool 3 (all_amps), which is redistributed by the rowkey of ('00000100'XB, '00000404'XB, '000000000000'XB) to few AMPs. 13) We execute the following steps in parallel. 1) We do a single-AMP RETRIEVE step from a single partition of DBC.AccessRights by way of the primary index "Field_1 = '00000000'XB, Field_2 = '00000000'XB, Field_3 = '000001000000'XB" with a residual condition of ( "DBC.AccessRights.Field_3 = '000001000000'XB") into Spool 3 (all_amps), which is redistributed by the rowkey of ( '00000404'XB, '00000404'XB, '000000000000'XB) to few AMPs. 2) We do an all-AMPs RETRIEVE step from DBC.AccessRights by way of an all-rows scan with a condition of ( "DBC.AccessRights.Field_8 = 'Y'") into Spool 4 (all_amps), which is redistributed by the hash code of ( DBC.AccessRights.Field_1) to all AMPs. Then we do a SORT to order Spool 4 by row hash. 14) We do an all-AMPs JOIN step from DBC.Owners by way of a RowHash match scan with a condition of ("DBC.Owners.Field_2 = '00000404'XB"), which is joined to Spool 4 (Last Use) by way of a RowHash match scan. DBC.Owners and Spool 4 are joined using a merge join, with a join condition of ("DBC.Owners.Field_1 = Field_1"). The result goes into Spool 3 (all_amps), which is redistributed by the rowkey of ('00000404'XB, DBC.AccessRights.Field_2, DBC.AccessRights.Field_3) to all AMPs. Then we do a SORT to partition Spool 3 by rowkey. 15) We execute the following steps in parallel. 1) We do an all-AMPs MERGE into DBC.AccessRights from Spool 3 (Last Use). 2) We do an INSERT into DBC.UIFDEPENDENCY. 16) We flush the DISKSPACE and AMPUSAGE caches. 17) We do an all-AMPs ABORT test from DBC.DataBaseSpace by way of the unique primary index "Field_1 = '00000100'XB, Field_2 = '000000000000'XB" with a residual condition of ( "2.50000000000000E 005 <= (DBC.DataBaseSpace.Field_4 - DBC.DataBaseSpace.Field_8)"). 18) We do an INSERT into DBC.DataBaseSpace. 19) We do an all-AMPs UPDATE from DBC.DataBaseSpace by way of the unique primary index "Field_1 = '00000100'XB, Field_2 = '000000000000'XB" with no residual conditions. 20) We flush the DISKSPACE and AMPUSAGE caches. 21) We spoil the parser's dictionary cache for the database. 22) Finally, we send out an END TRANSACTION step to all AMPs involved in processing the request. -> No rows are returned to the user as the result of statement 1.
The following is the output from a PM/API application capturing the step data of the preceding SQL statement.
The number is a sequential count of the rows returned from the DBS.
A repeated step number indicates that a parallel step. For example, in the following example, the step number 8 is repeated multiple times. This coincides with the parallel steps found for step 8 in the preceding Explain.
Step text is derived information and not the true EXPLAIN text.
A sample of a PM/API application output appears as follows:
Submitting request MONITOR SQL; ... Total SQL records = 1 create database testdb as perm=1e6; ============================ NumOfSteps: 33 CurStepBegNum: 33 CurStepEndNum: 33 DynamicPlan: 0 PartialSteps: 0 ZoneId: 0 SPName/SPDBName: SP NOT executing. Default Database Name: [DBC] 33 explain steps found Confidence= 0, RowCount 0/ 4, ET 0.00/ 0.00 1) First, lock [DBId=0x0406]. for exclusive. Confidence= 0, RowCount 0/ 1, ET 0.00/ 0.00 2) Next, we lock DBC.[TBId=0x0130] for write on a row hash. Confidence= 0, RowCount 0/ 1, ET 0.00/ 0.00 3) We lock DBC.DBSpace for write on a row hash. Confidence= 0, RowCount 0/ 1, ET 0.00/ 0.00 4) We lock DBC.Parents for write on a row hash. Confidence= 0, RowCount 0/ 1, ET 0.00/ 0.00 5) We lock DBC.Owners for write on a row hash. Confidence= 0, RowCount 0/ 1, ET 0.00/ 0.00 6) We lock DBC.AccessRights for write on a row hash. Confidence= 0, RowCount 0/ 4, ET 0.00/ 0.00 7) We lock DBC.[TBId=0x0130] for write, we lock DBC.DBSpace for write, we lock DBC.Parents for write, we lock DBC.Owne. Confidence= 0, RowCount 0/ 0, ET 0.00/ 0.00 8) We do a Single-AMP ABORT test from DBC.DBase by way of the unique primary index. This step begins a parallel block . Confidence= 0, RowCount 0/ 0, ET 0.00/ 0.00 8) We do a Single-AMP ABORT test from DBC.[TBId=0x0138] by way of the unique primary index. This step is performed in . Confidence= 0, RowCount 0/ 0, ET 0.00/ 0.00 8) We do a Single-AMP ABORT test from DBC.DBase by way of the unique primary index. This step is performed in parallel. Confidence= 0, RowCount 0/ 0, ET 0.00/ 0.00 8) We do a Single-AMP ABORT test from DBC.DBase by way of the unique primary index. This step is performed in parallel. Confidence= 0, RowCount 0/ 1, ET 0.00/ 0.01 8) We do an INSERT step into table DBC.DBase. This step is performed in parallel. Confidence= 0, RowCount 0/ 1, ET 0.00/ 0.00 8) We do a Single-AMP UPDATE from DBC.DBase by way of the unique primary index. This step is performed in parallel. Confidence= 0, RowCount 0/ 0, ET 0.00/ 0.00 8) We do a Single-AMP RETRIEVE step from DBC.Parents by way of the primary index into Spool 50, which is redistributed. Confidence= 0, RowCount 0/ 0, ET 0.00/ 0.00 9) We do a MERGE into table DBC.Owners from Spool 50. Confidence= 0, RowCount 0/ 1, ET 0.00/ 0.00 10) We do an INSERT step into table DBC.Owners. This step begins a parallel block of steps. Confidence= 0, RowCount 0/ 0, ET 0.00/ 0.00 10) We do a Single-AMP RETRIEVE step from DBC.Parents by way of the primary index into Spool 51, which is redistribute. Confidence= 0, RowCount 0/ 0, ET 0.00/ 0.00 11) We do a MERGE into table DBC.Parents from Spool 51. Confidence= 0, RowCount 0/ 1, ET 0.00/ 0.00 12) We do an INSERT step into table DBC.Parents. This step begins a parallel block of steps. Confidence= 0, RowCount 0/ 1, ET 0.00/ 0.02 12) We do an INSERT step into table DBC.Accounts. This step is performed in parallel. Confidence= 0, RowCount 0/ 25, ET 0.00/ 0.00 12) We do a Single-AMP RETRIEVE step from DBC.AccessRights accessing a single partition by way of the primary index in. Confidence= 0, RowCount 0/ 21, ET 0.00/ 0.00 13) We do a Single-AMP RETRIEVE step from DBC.AccessRights accessing a single partition by way of the primary index in. Confidence= 0, RowCount 0/ 0, ET 0.00/ 0.00 13) We do an All-AMPs RETRIEVE step from DBC.AccessRights by way of an all-rows scan into Spool 53, which is redistrib. Confidence= 0, RowCount 0/ 46, ET 0.00/ 0.01 14) We do an All-AMPs JOIN step from DBC.Owners by way of an all-rows scan, which is joined to Spool 53. table Owners . Confidence= 0, RowCount 0/ 46, ET 0.00/ 0.01 15) We do a MERGE into table DBC.AccessRights from Spool 52. This step begins a parallel block of steps. Confidence= 0, RowCount 0/ 1, ET 0.00/ 0.02 15) We do an INSERT step into table [TBId=0x0130]. This step ends a parallel block of steps. Confidence= 0, RowCount 0/ 0, ET 0.00/ 0.00 16) We flush the DISKSPACE and AMPUSAGE caches. Confidence= 0, RowCount 0/ 0, ET 0.00/ 0.00 17) We do an All-AMPs ABORT test from DBC.DBSpace by way of the unique primary index. Confidence= 0, RowCount 0/ 4, ET 0.00/ 0.00 18) We do an INSERT step into table DBC.DBSpace. Confidence= 0, RowCount 0/ 4, ET 0.00/ 0.00 19) We do an All-AMPs UPDATE from DBC.DBSpace by way of the unique primary index. Confidence= 0, RowCount 0/ 0, ET 0.00/ 0.01 20) We flush the DISKSPACE and AMPUSAGE caches. Confidence= 0, RowCount 0/ -1, ET 0.00/ -1.00 21) We Spoil the parser's dictionary cache for the database. Confidence= 0, RowCount 0/ -1, ET 0.00/ 0.00 22) We send out an END TRANSACTION step to all AMPs involved in processing the request.