Purpose
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 obtained 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.
- Teradata Vantage™ - Database Administration, B035-1093
- Teradata Vantage™ - Advanced SQL Engine Security Administration, B035-1100
- 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 some custom applications, an error message may appear.
- A problematic query is utilizing 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 Center 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 of them, an error is returned indicating that it is not an SQL session.
Abort processing is handled in the same way as when using the MONITOR SESSION request. For further information about abort handling, 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 timeout interval can be set in the DBS Control field, PMPC_TimeoutSecs. The default timeout interval is 60 seconds. If the PMPC_TimeoutSecs field is set to zero, the MONITOR SQL timeout request will be disabled and no timeout will occur. For more information on the PMPC_TimeoutSecs field, see Utilities.
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 Flavor | 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 results in 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. If RequestText is 64001 bytes or greater in length,
it will automatically split 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 currently 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 currently executing
level 1 step. If parallel steps are executing, it 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 currently executing
step. If parallel steps are executing, it 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 the EXPLAIN request modifier in Teradata Vantage™ - SQL Data Manipulation Language, B035-1146 or Teradata Vantage™ - SQL Request and Transaction Processing, B035-1142. |
PartialSteps | SMALLINT | Possible values:
A value 1 cannot occur for a static
plan.
For more information on static and dynamic explanations of a request, see Teradata Vantage™ - SQL Data Manipulation Language, B035-1146 or Teradata Vantage™ - SQL Request and Transaction Processing, B035-1142. |
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 being executed. NULL is returned in indicator mode if no stored procedure is being executed. |
SPDBName | VARCHAR(128) CHARACTER SET UNICODE |
This is the owner database name of
the outer stored procedure, if a stored procedure is being
executed. NULL is returned in indicator mode if no stored procedure is being executed. |
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, it 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. For more information on PRPD, see Teradata Vantage™ - SQL Request and Transaction Processing, B035-1142 or Teradata Vantage™ - Database Administration, B035-1093. |
ActRowCount | FLOAT NOT NULL |
Actual row count returned from the
AMP for this step. For a PRPD plan, it includes rows from all split
spools for a split step. For more information on PRPD, see Teradata Vantage™ - SQL Request and Transaction Processing, B035-1142 or Teradata Vantage™ - Database Administration, B035-1093. |
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 a “-1”. After the step executes, 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 executed 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), 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 | 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 SQL statement above.
The number is a sequential count of the rows returned from the DBS.
When a step number is repeated, it indicates that it is a parallel step. For instance, in the following example, the step number 8 is repeated multiple times. This coincides with the parallel steps found for step 8 in the above 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.