Teradata-插入表需要很长时间-计划执行有问题吗?

问题描述 投票:0回答:1

我想将数据插入目标表,但是不幸的是,这花费了太多时间,即使只有80万条记录也是如此。我认为问题出在执行计划/错误的索引或统计信息,但是,请问您查看解释计划是否有疑问?

这里是计划:

 This query is optimized using type 2 profile nonested_cost, profileid
 10003.
 This request is eligible for incremental planning and execution (IPE)
 but does not meet cost thresholds. The following is the static plan
 for the request.
  1) First, we lock Schema1.Target_Table in TD_MAP1
     for write on a reserved RowHash to prevent global deadlock.
  2) Next, we lock Schema1.Target_Table in TD_MAP1
     for write, we lock Schema1.Table1 in view
     Schema1.Table1_View in TD_MAP1 for access, and we lock
     Schema1.Table2 in view
     Schema1.Table3 in TD_MAP1 for access.
  3) We do an all-AMPs RETRIEVE step in TD_MAP1 from
     Schema1.Table2 in view
     Schema1.Table3 by way of an all-rows scan
     with a condition of ("(NOT (Schema1.Table2 in
     view Schema1.Table3.CUSTOMER_ID IS NULL
     )) AND (Schema1.Table2 in view
     Schema1.Table3.TYPE = 2.)") into Spool 3
     (all_amps) (compressed columns allowed), which is redistributed by
     the hash code of (
     Schema1.Table2.CUSTOMER_ID) to all AMPs in
     TD_Map1.  The size of Spool 3 is estimated with high confidence to
     be 66,211 rows (66,939,321 bytes).  The estimated time for this
     step is 0.80 seconds.
  4) We do an all-AMPs JOIN step in TD_Map1 from Spool 3 (Last Use) by
     way of a RowHash match scan, which is joined to
     Schema1.Table1 in view Schema1.Table1_View by way
     of a RowHash match scan with no residual conditions.  Spool 3 and
     Schema1.Table1 are joined using a single partition hash
     join, with a join condition of ("CUSTOMER_ID =
     Schema1.Table1.CUSTOMER_ID").  The result goes into
     Spool 4 (all_amps) (compressed columns allowed), which is
     redistributed by the hash code of (
    HERE IS THE LIST OF COLUMNS FROM TABLE 1 AND TABLE 2 to all AMPs in TD_Map1.
     Then we do a SORT to order Spool 4 by row hash.  The size of Spool
     4 is estimated with index join confidence to be 66,211 rows (
     73,163,155 bytes).  The estimated time for this step is 0.11
     seconds.
  5) We execute the following steps in parallel.
       1) We do an all-AMPs RETRIEVE step in TD_Map1 from Spool 4 by
          way of an all-rows scan into Spool 5 (all_amps) (compressed
          columns allowed) fanned out into 33 hash join partitions,
          which is duplicated on all AMPs in TD_Map1.  The size of
          Spool 5 is estimated with index join confidence to be
          28,603,152 rows (31,635,086,112 bytes).  The estimated time
          for this step is 1.69 seconds.
       2) We do an all-AMPs RETRIEVE step in TD_MAP1 from
          S.TAB_M by way of an all-rows scan with a
          condition of ("(NOT (S.TAB_M.EQUIPMENT_ID IS NULL ))
          AND (NOT (S.TAB_M.COUNTY_ID IS NULL ))")
          into Spool 6 (all_amps) (compressed columns allowed) fanned
          out into 33 hash join partitions, which is built locally on
          the AMPs.  The size of Spool 6 is estimated with high
          confidence to be 120,648,009 rows (29,679,410,214 bytes).
          The estimated time for this step is 2.68 seconds.
  6) We do an all-AMPs JOIN step in TD_Map1 from Spool 6 (Last Use) by
     way of an all-rows scan, which is joined to Spool 5 (Last Use) by
     way of an all-rows scan.  Spool 6 and Spool 5 are joined using a
     hash join of 33 partitions, with a join condition of ("(NOT
     (SubCustomer_ID IS NULL )) AND ((NOT (ORG_ID IS NULL )) AND
     ((EQUIPMENT_ID = SubCustomer_ID) AND ((COUNTY_ID )= (ORG_ID
     (FLOAT, FORMAT '-9.99999999999999E-999')))))").  The result goes
     into Spool 7 (all_amps) (compressed columns allowed), which is
     redistributed by the hash code of (
HERE IS THE LIST OF COLUMNS FROM TABLE 1 AND TABLE 2) to all AMPs in
     TD_Map1.  Then we do a SORT to order Spool 7 by row hash.  The
     size of Spool 7 is estimated with index join confidence to be
     88,525 rows (28,239,475 bytes).
  7) We do an all-AMPs JOIN step in TD_Map1 from Spool 7 (Last Use) by
     way of a RowHash match scan, which is joined to Spool 4 (Last Use)
     by way of a RowHash match scan.  Spool 7 and Spool 4 are
     right outer joined using a merge join, with a join condition of (
     "Field_1 = Field_1").  The result goes into Spool 2 (all_amps)
     (compressed columns allowed), which is built locally on the AMPs.
     The size of Spool 2 is estimated with index join confidence to be
     88,525 rows (114,639,875 bytes).  The estimated time for this step
     is 1.68 seconds.
  8) We do an all-AMPs SUM step in TD_Map1 to aggregate from Spool 2
     (Last Use) by way of an all-rows scan, grouping by field1 (HERE IS THE LIST OF COLUMNS FROM TABLE 1 AND TABLE 2 AND S.TAB_M).  Aggregate Intermediate
     Results are computed locally, then placed in Spool 11 in TD_Map1.
     The size of Spool 11 is estimated with low confidence to be 66,394
     rows (330,575,726 bytes).  The estimated time for this step is
     0.23 seconds.
  9) We do an all-AMPs RETRIEVE step in TD_Map1 from Spool 11 (Last
     Use) by way of an all-rows scan into Spool 1 (all_amps)
     (compressed columns allowed), which is redistributed by the hash
     code of ((CASE WHEN (NOT (S.TAB_M.TIME_DELIVERY IS
     NULL )) THEN (S.TAB_M.TIME_DELIVERY) WHEN (NOT
     (S.TAB_M.TIME_DELIVERY_EXP IS NULL )) THEN
     (S.TAB_M.TIME_DELIVERY_EXP) ELSE (0) END )(INTEGER)) to
     all AMPs in TD_Map1.  Then we do a SORT to order Spool 1 by row
     hash.  The size of Spool 1 is estimated with low confidence to be
     66,394 rows (85,050,714 bytes).  The estimated time for this step
     is 0.05 seconds.
 10) We do an all-AMPs MERGE step in TD_MAP1 into
     Schema1.Target_Table from Spool 1 (Last Use).
     The size is estimated with low confidence to be 66,394 rows.  The
     estimated time for this step is 4.00 seconds.
 11) We spoil the parser's dictionary cache for the table.
 12) 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.```

sql performance optimization teradata sql-execution-plan
1个回答
0
投票

常见的性能问题之一是DDL与需求不符。同样,如果您有任何约束,触发器或分区,这也会减慢INSERT的速度。请您添加创建声明吗?

© www.soinside.com 2019 - 2024. All rights reserved.