MONITOR SQL Request | Application Programming Reference | Teradata Vantage - 17.10 - MONITOR SQL - Advanced SQL Engine - Teradata Database

Teradata Vantage™ - Application Programming Reference

Product
Advanced SQL Engine
Teradata Database
Release Number
17.10
Release Date
July 2021
Content Type
Programming Reference
Publication ID
B035-1090-171K
Language
English (United States)

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.

For more information on roles and privileges, see:

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.

The MONITOR SQL request can be used in the following ways:
  • 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
  • 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 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
  • 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 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
  • 5 to 64100 (record mode)
  • 6 to 64100 (indicator mode)
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

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, available at https://teradata-docs.s3.amazonaws.com/doc/connectivity/jdbc/reference/current/frameset.html.

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:
  • 0 = Static plan
  • 1 = Dynamic plan

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:
  • 0 = All steps are returned
  • 1 = Partial plan or no plan is returned

    If a partial plan is returned, this indicates the steps for the final plan fragment of the dynamic explanation of the request has not yet been generated.

    If no plan is returned, this indicates the request has been throttled and is in the delay queue.

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.
If only one step is executing, CurLevlStepNum and CurLEv2StepNum are identical.

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:
  • 0 = None
  • 1= Foreign Key
  • 2 = Low
  • 3 = High
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.

If the request has been throttled and is in the delay queue (that is, when the NumOfSteps field value is zero and both the DynamicPlan are PartialSteps field values are 1), the response to this statement returns no rows. For more information on the NumOfSteps, DynamicPlan, and the PartialSteps fields, see Statement 2.

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 EXPLAIN steps shown are not as inclusive as those provided by the EXPLAIN request modifier.

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.