0

質問があります（下記）。説明計画は、私たちのラボでもダウンタイムを引き起こした高い CPU 使用率を示しています。このクエリをさらにチューブ化することは可能ですか? チューニングするにはどうすればよいですか？

参考までに、mtr_main_a、mtr_main_b、mtr_hist には 1000 万以上の膨大な数のレコードが含まれています。

SELECT to_char(MAX(mdt), 'MM-DD-RRRR HH24:MI:SS')
FROM   (
           SELECT MAX(mod_date - 2 / 86400) mdt
           FROM   mtr_main_a
           UNION
           SELECT MAX(mod_date - 2 / 86400) mdt
           FROM   mtr_main_b
           UNION
           SELECT MAX(mod_date - 2 / 86400) mdt
           FROM   mtr_hist@batch_hist
       )
/

説明プランは以下の通り

Execution Plan
----------------------------------------------------------
Plan hash value: 1573811822

-------------------------------------------------------------------------------------------------------------
| Id  | Operation              | Name       | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Inst   |IN-OUT|
-------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |            |     1 |     9 |       | 79803   (1)| 00:18:38 |        |      |
|   1 |  SORT AGGREGATE        |            |     1 |     9 |       |            |          |        |      |
|   2 |   VIEW                 |            |     2 |    18 |       | 79803   (1)| 00:18:38 |        |      |
|   3 |    SORT UNIQUE         |            |     2 |    17 |    77M| 79803   (2)| 00:18:38 |        |      |
|   4 |     UNION-ALL          |            |       |       |       |            |          |        |      |
|   5 |      SORT AGGREGATE    |            |     1 |     8 |       | 79459   (1)| 00:18:33 |        |      |
|   6 |       TABLE ACCESS FULL| MTR_MAIN_A |  5058K|    38M|       | 67735   (1)| 00:15:49 |        |      |
|   7 |      SORT AGGREGATE    |            |     1 |     9 |       |   344   (1)| 00:00:05 |        |      |
|   8 |       TABLE ACCESS FULL| MTR_MAIN_B |     1 |     9 |       |   343   (1)| 00:00:05 |        |      |
|   9 |      REMOTE            |            |       |       |       |            |          |  HISTB | R->S |
-------------------------------------------------------------------------------------------------------------

Remote SQL Information (identified by operation id):
----------------------------------------------------

   9 - EXPLAIN PLAN SET STATEMENT_ID='PLUS10294704' INTO PLAN_TABLE@! FOR SELECT
       MAX("A1"."MOD_DATE"-.00002314814814814814814814814814814814814815) FROM "MTR_HIST" "A1" (accessing
       'HISTB' )

ありがとう、チャンドラ

4

2 に答える 2

1

列にインデックスがある場合、このバージョンはどのように機能しますか？

SELECT to_char((case when a.mdt > b.mdt and a.mdt > c.mdt then a.mdt
                     when b.mdt > c.mdt then b.mdt
                     else c.mdt
                end) - 2 / 86400, 'MM-DD-RRRR HH24:MI:SS')
FROM (SELECT MAX(mod_date) mdt
      FROM   mtr_main_a
     ) a cross join
     (SELECT MAX(mod_date) mdt
      FROM   mtr_main_b
     ) b cross join
     (SELECT MAX(mod_date) mdt
      FROM   mtr_hist@batch_hist
     ) c

unionバージョンが高速に動作しない場合、これは単なる提案です。

于 2013-01-16T11:34:34.960 に答える
1

mod_date最大日付を決定した後、列にインデックスを配置し、最後に減算を行うようにクエリを変更することで、パフォーマンスを大幅に改善できるはずです。

SELECT to_char(MAX(mdt) - 2 / 86400, 'MM-DD-RRRR HH24:MI:SS')
FROM   (
           SELECT MAX(mod_date) mdt
           FROM   mtr_main_a
           UNION
           SELECT MAX(mod_date) mdt
           FROM   mtr_main_b
           UNION
           SELECT MAX(mod_date) mdt
           FROM   mtr_hist@batch_hist
       )

これにより、テーブル全体のスキャンが取り除かれます。

于 2013-01-16T10:40:26.533 に答える