ローカルパーティションインデックスを追加することによりSQLの性能を向上させた事例を解析します。
11860 ワード
このsqlは以下の通りです。
ネスト接続は、処理するデータセットを外部ループ(駆動データソース)と内部ループ(駆動データソース)に分け、外部ループは一回のみ実行し、内部サイクルの実行回数は外部ループの実行回数と同じです。この接続の利点はメモリの使用が非常に少ないことです。駆動データソースが限られ、かつ、駆動テーブルが接続列に対応するインデックスを持っている場合には、このような接続方式が効率的である。以下はこの3つのテーブルのインデックスの場合です。
Select /*+ parallel(src, 8) */ distinct
src.systemname as systemname
, src.databasename as databasename
, src.tablename as tablename
, src.username as username
from <STRONG>meta_dbql_table_usage_exp_hst</STRONG> src
inner <STRONG>join DR_QRY_LOG_EXP_HST</STRONG> rl on
<STRONG>src.acctstringdate = rl.acctstringdate
and src.queryid = rl.queryid</STRONG>
And Src.Systemname = Rl.Systemname
and src.acctstringdate > sysdate - 30
And Rl.Acctstringdate > Sysdate - 30
inner join <STRONG>meta_dr_qry_log_tgt_all_hst </STRONG>tgt on
upper(tgt.systemname) = upper('MOZART')
And Upper(tgt.Databasename) = Upper('GDW_TABLES')
And Upper(tgt.Tablename) = Upper('SSA_SLNG_LSTG_MTRC_SD')
<STRONG>AND src.acctstringdate = tgt.acctstringdate
and rl.statement_id = tgt.statement_id</STRONG>
and rl.systemname = tgt.systemname
And Tgt.Acctstringdate > Sysdate - 30
And Not(
Upper(Tgt.Systemname)=Upper(src.systemname)
And
Upper(Tgt.Databasename) = Upper(Src.Databasename)
And
Upper(Tgt.Tablename) = Upper(Src.Tablename)
)
And tgt.Systemname is not null
And tgt.Databasename Is Not Null
And tgt.tablename is not null
SQLの簡単な分析はとにかく見てください。このSQLは三つの表です。dbqlテーブルアメリカage.exp_hst,DR_QRY_LOG_EXP_HST,meta_druqryロゴtgt_all_hst)のINNER JOINは、この3つのテーブルのデータ量はすべて百万レベルであり、かつパーティションテーブル(acctstingdateをパーティションキーとする)であり、実行計画は以下の通りである。
------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop |
------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 159 | 8654 | | |
| 1 | PX COORDINATOR | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10002 | 1 | 159 | 8654 | | |
| 3 | SORT UNIQUE | | 1 | 159 | 8654 | | |
| 4 | PX RECEIVE | | 1 | 36 | 3 | | |
| 5 | PX SEND HASH | :TQ10001 | 1 | 36 | 3 | | |
|* 6 | TABLE ACCESS BY LOCAL INDEX ROWID| DR_QRY_LOG_EXP_HST | 1 | 36 | 3 | | |
| 7 | NESTED LOOPS | | 1 | 159 | 8633 | | |
| 8 | NESTED LOOPS | | 8959 | 1076K| 4900 | | |
| 9 | BUFFER SORT | | | | | | |
| 10 | PX RECEIVE | | | | | | |
| 11 | PX SEND BROADCAST | :TQ10000 | | | | | |
| 12 | PARTITION RANGE ITERATOR | | 1 | 56 | 4746 | KEY | 14 |
|* 13 | TABLE ACCESS FULL | META_DR_QRY_LOG_TGT_ALL_HST | 1 | 56 | 4746 | KEY | 14 |
| 14 | PX BLOCK ITERATOR | | 8959 | 586K| 154 | KEY | KEY |
|* 15 | TABLE ACCESS FULL | META_DBQL_TABLE_USAGE_EXP_HST | 8959 | 586K| 154 | KEY | KEY |
| 16 | PARTITION RANGE ITERATOR | | 1 | | 2 | KEY | KEY |
|* 17 | INDEX RANGE SCAN | DR_QRY_LOG_EXP_HST_IDX | 1 | | 2 | KEY | KEY |
------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
6 - filter("RL"."STATEMENT_ID"="TGT"."STATEMENT_ID" AND "RL"."SYSTEMNAME"="TGT"."SYSTEMNAME" AND "SRC"."SYSTEMNAME"="RL"."SYSTEMNAME")
13 - filter(UPPER("TGT"."SYSTEMNAME")='MOZART' AND UPPER("TGT"."DATABASENAME")='GDW_TABLES' AND
UPPER("TGT"."TABLENAME")='SSA_SLNG_LSTG_MTRC_SD' AND "TGT"."ACCTSTRINGDATE">SYSDATE@!-30 AND "TGT"."SYSTEMNAME" IS NOT NULL
"TGT"."DATABASENAME" IS NOT NULL AND "TGT"."TABLENAME" IS NOT NULL)
15 - filter("SRC"."ACCTSTRINGDATE"="TGT"."ACCTSTRINGDATE" AND (UPPER("TGT"."SYSTEMNAME")<>UPPER("SRC"."SYSTEMNAME") OR
UPPER("TGT"."DATABASENAME")<>UPPER("SRC"."DATABASENAME") OR UPPER("TGT"."TABLENAME")<>UPPER("SRC"."TABLENAME")) AND
"SRC"."ACCTSTRINGDATE">SYSDATE@!-30)
17 - access("SRC"."QUERYID"="RL"."QUERYID" AND "SRC"."ACCTSTRINGDATE"="RL"."ACCTSTRINGDATE")
filter("RL"."ACCTSTRINGDATE">SYSDATE@!-30)
ポジショニング問題は上記の実行計画中のテーブル接続方式から分かります。この3つのテーブルの間でNESTEP LOOPが2回行われています。問題は最下位層のNESTEP LOOPに発生しています。表は全部百万レベルですから、性能に問題があります。DBQL_TABLE_USAGE_EXP_HSTは何回も全表スキャンをしました。全表スキャンをインデックスに変換できれば、性能は大幅に向上します。ネスト接続は、処理するデータセットを外部ループ(駆動データソース)と内部ループ(駆動データソース)に分け、外部ループは一回のみ実行し、内部サイクルの実行回数は外部ループの実行回数と同じです。この接続の利点はメモリの使用が非常に少ないことです。駆動データソースが限られ、かつ、駆動テーブルが接続列に対応するインデックスを持っている場合には、このような接続方式が効率的である。以下はこの3つのテーブルのインデックスの場合です。
SQL> select index_name, table_name from user_indexes where table_name in ('DR_QRY_LOG_EXP_HST',upper('meta_dbql_table_usage_exp_hst'), upper('meta_dr_qry_log_tgt_all_hs
INDEX_NAME TABLE_NAME
------------------------------------------------------------ ------------------------------------------------------------
META_DR_QRY_LOG_TGT_ALL_IDX META_DR_QRY_LOG_TGT_ALL_HST
META_DBQL_TUSAGE_EHST_IDX META_DBQL_TABLE_USAGE_EXP_HST
DR_QRY_LOG_EXP_HST_IDX DR_QRY_LOG_EXP_HST
CREATE INDEX "GV"."META_DR_QRY_LOG_TGT_ALL_IDX" ON "GV"."META_DR_QRY_LOG_TGT_ALL_HST" ("STATEMENT_ID", "ACCTSTRINGDATE")
CREATE INDEX "GV"."META_DBQL_TUSAGE_EHST_IDX" ON "GV"."META_DBQL_TABLE_USAGE_EXP_HST" ("QUERYID", "ACCTSTRINGDATE")
CREATE INDEX "GV"."DR_QRY_LOG_EXP_HST_IDX" ON "GV"."DR_QRY_LOG_EXP_HST" ("QUERYID", "ACCTSTRINGDATE")
という3つのインデックスはすべてローカルパーティションインデックスです。QRY_LOG_EXP_HSTテーブルはインデックスが足りないので、テーブルと一緒にいます。druqryロゴtgt_all_hstはstatementにいますidでjoinをするので、statementにあるべきです。IDにもローカルパーティションインデックスが作成されています。
create index DR_QRY_LOG_EXP_HST_IDX2 on gv.DR_QRY_LOG_EXP_HST (statement_id,ACCTSTRINGDATE) local;
の性能比較の新しい実行計画は以下の通りです。
------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop |
------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 159 | 4838 | | |
| 1 | SORT UNIQUE | | 1 | 159 | 4838 | | |
|* 2 | TABLE ACCESS BY LOCAL INDEX ROWID | META_DBQL_TABLE_USAGE_EXP_HST | 1 | 67 | 3 | | |
| 3 | NESTED LOOPS | | 1 | 159 | 4816 | | |
| 4 | NESTED LOOPS | | 18 | 1656 | 4762 | | |
| 5 | PARTITION RANGE ITERATOR | | 1 | 56 | 4746 | KEY | 14 |
|* 6 | TABLE ACCESS FULL | META_DR_QRY_LOG_TGT_ALL_HST | 1 | 56 | 4746 | KEY | 14 |
| 7 | PARTITION RANGE ITERATOR | | 18 | 648 | 16 | KEY | 14 |
|* 8 | TABLE ACCESS BY LOCAL INDEX ROWID| DR_QRY_LOG_EXP_HST | 18 | 648 | 16 | KEY | 14 |
|* 9 | <STRONG>INDEX RANGE SCAN | DR_QRY_LOG_EXP_HST_IDX2</STRONG> | 31 | | 15 | KEY | 14 |
| 10 | PARTITION RANGE ITERATOR | | 1 | | 2 | KEY | KEY |
|* 11 | INDEX RANGE SCAN | META_DBQL_TUSAGE_EHST_IDX | 1 | | 2 | KEY | KEY |
------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter((UPPER("TGT"."SYSTEMNAME")<>UPPER("SRC"."SYSTEMNAME") OR
UPPER("TGT"."DATABASENAME")<>UPPER("SRC"."DATABASENAME") OR UPPER("TGT"."TABLENAME")<>UPPER("SRC"."TABLENAME"))
AND "SRC"."SYSTEMNAME"="RL"."SYSTEMNAME")
6 - filter(UPPER("TGT"."SYSTEMNAME")='MOZART' AND UPPER("TGT"."DATABASENAME")='GDW_TABLES' AND
UPPER("TGT"."TABLENAME")='SSA_SLNG_LSTG_MTRC_SD' AND "TGT"."ACCTSTRINGDATE">SYSDATE@!-30 AND "TGT"."SYSTEMNAME"
IS NOT NULL AND "TGT"."DATABASENAME" IS NOT NULL AND "TGT"."TABLENAME" IS NOT NULL)
8 - filter("RL"."SYSTEMNAME"="TGT"."SYSTEMNAME")
9 - access("RL"."STATEMENT_ID"="TGT"."STATEMENT_ID" AND "RL"."ACCTSTRINGDATE">SYSDATE@!-30 AND
"RL"."ACCTSTRINGDATE" IS NOT NULL)
11 - access("SRC"."QUERYID"="RL"."QUERYID" AND "SRC"."ACCTSTRINGDATE"="RL"."ACCTSTRINGDATE")
filter("SRC"."ACCTSTRINGDATE"="TGT"."ACCTSTRINGDATE" AND "SRC"."ACCTSTRINGDATE">SYSDATE@!-30)
は新しい実行計画から分かります。最初のNESTED LOOPはやはり最新のインデックスを使っています。以下は、実行時間:
: 00: 00: 02.16
2秒で解決し、彼の期待をはるかに超える5 s:)方法をまとめたNESTED LOOPの効率的な条件です。駆動データ源が限られ、かつ、駆動テーブルによって接続列に対応するインデックスがあります。