15.10 - MONITOR SQL - Teradata Database

Teradata Database Application Programming Reference

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

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.

 

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.

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 3 or later.

For a general explanation of monitor version choices, see “MONITOR VERSION” on page 162.

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.

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:

  • Database Administration
  • Security Administration
  • Teradata JDBC Driver User Guide
  • Before using this request, see “Impact of Object Name Length on PM/API Requests” on page 54.

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

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

    The MONITOR SQL request is treated internally as a three statement request with each statement generating a response. The three-statement response returned from Teradata 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” on page 152).

    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” on page 152).

    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” on page 154).

    EndStatement

    11

    6

    StatementNo = 2-byte integer

    EndRequest

    12

    4

    None

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

    Note: If RequestText is 64001 bytes or greater in length, it will automatically split into multiple records

    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 SQL Data Manipulation Language or SQL Request and Transaction Processing.

    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.

    Note: A value 1 cannot occur for a static plan.

    For more information on static and dynamic explanations of a request, see SQL Data Manipulation Language or SQL Request and Transaction Processing.

    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.

    Note: 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 SQL Request and Transaction Processing or Database Administration.

    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 SQL Request and Transaction Processing or Database Administration.

    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.

    Note: 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” on page 152.

    This example shows how the parcels for a MONITOR SQL request, built by CLIv2, appear when sent to the Teradata 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

    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.

    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.

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