db tech showcase Tokyo 2013 - A35 特濃JPOUG：潮溜まりでジャブジャブ、SQLチューニング

潮溜まりでジャブジャブ、
SQLチューニング

Rock Pool / Michael

Hiroshi Sekiguchi ( @discus_hamburg )
13年11月16日土曜日

自己紹介

@discus_hamburg

関口裕士（屋号 Stargrass Software）
最近の仕事 : Software Engineer < DB Engineer
最近は医者のような問診に興味を持っている
JPOUG ボードメンバー
Oracle ACE (2012)
Blog : Mac De Oracle / http://discus-hamburg.cocolog-nifty.com


皆が、Deep dive、Deep diveというの
で、Oracle Coreの深い海ではなく沢⼭山
のSQL⽂文が泳ぐ浅瀬へShallow Diveす
ることに決めた天の邪⻤⿁鬼。


潮溜溜まりに取り残された、⼀一癖ありそう
なSQL⽂文を釣り上げてみると...
いろいろな病に苦しんでいた。
治療療できたのか、治療療できなかったの
か...


釣り上げたSQL文の病名
過フィルタリング症候群
クエリー分裂症
バッファキャッシュ欠乏症
参照整合性制約アレルギー


過フィルタリング症候群


ウォームアップ！


クエリー分裂症


釣り上げたSQLは、一匹で
あるかのように見えるが...
散らばっている情報が治療
を難しくする...

問診結果
OLTPで分散クエリーを利用している。(分散DB）
OLTPなので大きなクエリーではないものの非機能要
件が厳しいので可能な限り改善したい。
大人の事情により、SQL文だけしか変更できない。
(・・)


分散クエリーとリモートクエリー

どのような
クエリーなのでしょう？


分散クエリー


リモートクエリー


釣り上げたSQL文
SELECT

/*+
USE_NL(tab1
tab2
tab3
tab4)
*/

tab4.*
FROM

tab1

INNER
JOIN
tab2

ON

tab1.unique#
=
tab2.unique#

AND
tab1.unique#
IN
(1,2)

INNER
JOIN
tab3

ON

tab2.unique#
=
tab3.unique#

AND
tab2.branch#
=
tab3.branch#

INNER
JOIN
tab4

ON

tab3.unique#
=
tab4.unique#

AND
tab3.branch#
=
tab4.branch#

AND
tab3.loc#

=
tab4.loc#
;

釣り上げたSQL文 (実行計画)
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|
Id

|
Operation

|
Name

|
Rows

|
Bytes
|
Cost
(%CPU)|
Time

|
Inst

|IN-‐OUT|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|

0
|
SELECT
STATEMENT

|

|
20000
|

11M|

603

(0)|
00:00:01
|

|

|
|

1
|

NESTED
LOOPS

|

|

|

|

|

|

|

|
|

2
|

NESTED
LOOPS

|

|
20000
|

11M|

603

(0)|
00:00:01
|

|

|
|

3
|

NESTED
LOOPS

|

|

200
|
15600
|

3

(0)|
00:00:01
|

|

|
|

4
|

NESTED
LOOPS

|

|

200
|
13000
|

3

(0)|
00:00:01
|

|

|
|

5
|

REMOTE

|
TAB3

|

200
|

7800
|

3

(0)|
00:00:01
|
PDBOR~
|
R-‐>S
|
|

6
|

REMOTE

|
TAB2

|

1
|

26
|

0

(0)|
00:00:01
|
PDBOR~
|
R-‐>S
|
|

7
|

REMOTE

|
TAB1

|

1
|

13
|

0

(0)|
00:00:01
|
PDBOR~
|
R-‐>S
|
|*

8
|

INDEX
RANGE
SCAN

|
PK_TAB4
|

1
|

|

2

(0)|
00:00:01
|

|

|
|

9
|

TABLE
ACCESS
BY
INDEX
ROWID|
TAB4

|

100
|
51400
|

3

(0)|
00:00:01
|

|

|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
Predicate
Information
(identified
by
operation
id):
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

8
-‐
access("TAB3"."UNIQUE#"="TAB4"."UNIQUE#"
AND
"TAB3"."BRANCH#"="TAB4"."BRANCH#"
AND

"TAB3"."LOC#"="TAB4"."LOC#")

filter("TAB4"."UNIQUE#"=1
OR
"TAB4"."UNIQUE#"=2)


釣り上げたSQL文 (DB Link..)
●USER_DB_LINKSより
DB_LINK

USERNAME

HOST
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
PDBORCL_R

SCOTT

PDBORCL_R
●USER_SYNONYMSより
SYNONYM_NAME

TABLE_NAME

DB_LINK
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
TAB1

TAB1

PDBORCL_R
TAB2

TAB2

PDBORCL_R
TAB3

TAB3

PDBORCL_R


釣り上げたSQL文 (DB Link..)
●USER_DB_LINKSより
DB_LINK

USERNAME

HOST
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
PDBORCL_R

SCOTT

PDBORCL_R

DB Link先は１つで
３表が同一リモートデ
ータベースに存在する

●USER_SYNONYMSより
SYNONYM_NAME

TABLE_NAME

DB_LINK
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
TAB1

TAB1

PDBORCL_R
TAB2

TAB2

PDBORCL_R
TAB3

TAB3

PDBORCL_R


釣り上げたSQL文 (表の配置)


釣り上げたSQL文 (表の配置)
リモート表の３
表は同一インスタ
ンスにある

問題のSQL文は
このインスタンス
から実行される。

釣り上げたSQL文 (実行計画)
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|
Id

|
Operation

|
Name

|
Rows

|
Bytes
|
Cost
(%CPU)|
Time

|
Inst

|IN-‐OUT|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|

0
|
SELECT
STATEMENT

|

|
20000
|

11M|

603

(0)|
00:00:01
|

|

|
|

1
|

NESTED
LOOPS

|

|

|

|

|

|

|

|
|

2
|

NESTED
LOOPS

|

|
20000
|

11M|

603

(0)|
00:00:01
|

|

|
|

3
|

NESTED
LOOPS

|

|

200
|
15600
|

3

(0)|
00:00:01
|

|

|
|

4
|

NESTED
LOOPS

|

|

200
|
13000
|

3

(0)|
00:00:01
|

|

|
|

5
|

REMOTE

|
TAB3

|

200
|

7800
|

3

(0)|
00:00:01
|
PDBOR~
|
R-‐>S
|
|

6
|

REMOTE

|
TAB2

|

1
|

26
|

0

(0)|
00:00:01
|
PDBOR~
|
R-‐>S
|
|

7
|

REMOTE

|
TAB1

|

1
|

13
|

0

(0)|
00:00:01
|
PDBOR~
|
R-‐>S
|
|*

8
|

INDEX
RANGE
SCAN

|
PK_TAB4
|

1
|

|

2

(0)|
00:00:01
|

|

|
|

9
|

TABLE
ACCESS
BY
INDEX
ROWID|
TAB4

|

100
|
51400
|

3

(0)|
00:00:01
|

|

|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
Predicate
Information
(identified
by
operation
id):
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

この実行計画はローカルデー

8
-‐
AND
AND


OR
"TAB4"."UNIQUE#"=2)

タベースで取得されたもの


リモートクエリーの実行計画
Remote
SQL
Information
(identified
by
operation
id):
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

5
-‐
SELECT
/*+
USE_NL
("TAB3")
*/
"UNIQUE#","BRANCH#"

,"LOC#"
FROM
"TAB3"
"TAB3"
WHERE

"UNIQUE#"=1
OR
"UNIQUE#"=2
(accessing
'PDBORCL_R'
)

6
-‐
SELECT
/*+
USE_NL
("TAB2")
*/
"UNIQUE#","BRANCH#"

FROM
"TAB2"
"TAB2"
WHERE
"BRANCH#"=:1

AND
"UNIQUE#"=:2
AND
("UNIQUE#"=1
OR
"UNIQUE#"=2)

(accessing
'PDBORCL_R'
)

7
-‐
SELECT
/*+
USE_NL
("TAB1")
*/
"UNIQUE#"

FROM
"TAB1"
"TAB1"
WHERE
"UNIQUE#"=:1
AND

("UNIQUE#"=1
OR
"UNIQUE#"=2)
(accessing
'PDBORCL_R'
)

explain plan文などでオプティマイザーが
切り出したリモートクエリーを確認

リモートクエリーの実行計画
Remote
SQL
Information
(identified
by
operation
id):
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

5
-‐
SELECT
/*+
USE_NL
("TAB3")
*/
"UNIQUE#","BRANCH#"

,"LOC#"
FROM
"TAB3"
"TAB3"
WHERE

"UNIQUE#"=1
OR
"UNIQUE#"=2
(accessing
'PDBORCL_R'
)

6
-‐
SELECT
/*+
USE_NL
("TAB2")
*/
"UNIQUE#","BRANCH#"

FROM
"TAB2"
"TAB2"
WHERE
"BRANCH#"=:1

AND
"UNIQUE#"=:2
AND
("UNIQUE#"=1
OR
"UNIQUE#"=2)

(accessing
'PDBORCL_R'
)

7
-‐
SELECT
/*+
USE_NL
("TAB1")
*/
"UNIQUE#"

FROM
"TAB1"
"TAB1"
WHERE
"UNIQUE#"=:1
AND

("UNIQUE#"=1
OR
"UNIQUE#"=2)
(accessing
'PDBORCL_R'
)

これらのSQL文はリモートデータベースで実
行されるため、実行計画はリモートデータベ
ース上で確認する必要がある。

リモートクエリーの
実行計画①
Remote
SQL
Information
(identified
by
operation
id):
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

5
-‐
SELECT
/*+
USE_NL
("TAB3")
*/
"UNIQUE#","BRANCH#"

,"LOC#"
FROM
"TAB3"
"TAB3"
WHERE

"UNIQUE#"=1
OR
"UNIQUE#"=2
(accessing
'PDBORCL_R'
)

-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|
Id

|
Operation

|
Name

|
Rows

|
Bytes
|
Cost
(%CPU)|
Time

|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|

0
|
SELECT
STATEMENT

|

|

200
|

2000
|

3

(0)|
00:00:01
|
|

1
|

INLIST
ITERATOR

|

|

|

|

|

|
|*

2
|

INDEX
RANGE
SCAN|
PK_TAB3
|

200
|

2000
|

3

(0)|
00:00:01
|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐


実行計画①
Remote
SQL
Information
(identified
by
operation
id):
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

5
-‐
SELECT
/*+
USE_NL
("TAB3")
*/
"UNIQUE#","BRANCH#"

,"LOC#"
FROM
"TAB3"
"TAB3"
WHERE

"UNIQUE#"=1
OR
"UNIQUE#"=2
(accessing
'PDBORCL_R'
)

-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|
Id

|
Operation

|
Name

|
Rows

|
Bytes
|
Cost
(%CPU)|
Time

|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|

0
|
SELECT
STATEMENT

|

|

200
|

2000
|

3

(0)|
00:00:01
|
|

1
|

INLIST
ITERATOR

|

|

|

|

|

|
|*

2
|

INDEX
RANGE
SCAN|
PK_TAB3
|

200
|

2000
|

3

(0)|
00:00:01
|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
チューニングが必要だとは
思えない...


実行計画②
Remote
SQL
Information
(identified
by
operation
id):
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

6
-‐
SELECT
/*+
USE_NL
("TAB2")
*/
"UNIQUE#","BRANCH#"

FROM
"TAB2"
"TAB2"
WHERE
"BRANCH#"=:1

AND
"UNIQUE#"=:2
AND
("UNIQUE#"=1
OR
"UNIQUE#"=2)

(accessing
'PDBORCL_R'
)
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|
Id

|
Operation

|
Name

|
Rows

|
Bytes
|
Cost
(%CPU)|
Time

|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|

0
|
SELECT
STATEMENT

|

|

1
|

7
|

1

(0)|
00:00:01
|
|*

1
|

FILTER

|

|

|

|

|

|
|*

2
|

INDEX
UNIQUE
SCAN|
PK_TAB2
|

1
|

7
|

1

(0)|
00:00:01
|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐


実行計画②
Remote
SQL
Information
(identified
by
operation
id):
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

6
-‐
SELECT
/*+
USE_NL
("TAB2")
*/
"UNIQUE#","BRANCH#"

FROM
"TAB2"
"TAB2"
WHERE
"BRANCH#"=:1

AND
"UNIQUE#"=:2
AND
("UNIQUE#"=1
OR
"UNIQUE#"=2)

(accessing
'PDBORCL_R'
)
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|
Id

|
Operation

|
Name

|
Rows

|
Bytes
|
Cost
(%CPU)|
Time

|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|

0
|
SELECT
STATEMENT

|

|

1
|

7
|

1

(0)|
00:00:01
|
|*

1
|

FILTER

|

|

|

|

|

|
|*

2
|

INDEX
UNIQUE
SCAN|
PK_TAB2
|

1
|

7
|

1

(0)|
00:00:01
|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
思えない...


実行計画③
Remote
SQL
Information
(identified
by
operation
id):
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

7
-‐
SELECT
/*+
USE_NL
("TAB1")
*/
"UNIQUE#"

FROM
"TAB1"
"TAB1"
WHERE
"UNIQUE#"=:1
AND

("UNIQUE#"=1
OR
"UNIQUE#"=2)
(accessing
'PDBORCL_R'
)

-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|
Id

|
Operation

|
Name

|
Rows

|
Bytes
|
Cost
(%CPU)|
Time

|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|

0
|
SELECT
STATEMENT

|

|

1
|

4
|

1

(0)|
00:00:01
|
|*

1
|

FILTER

|

|

|

|

|

|
|*

2
|

INDEX
UNIQUE
SCAN|
PK_TAB1
|

1
|

4
|

1

(0)|
00:00:01
|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐


実行計画③
Remote
SQL
Information
(identified
by
operation
id):
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

7
-‐
SELECT
/*+
USE_NL
("TAB1")
*/
"UNIQUE#"

FROM
"TAB1"
"TAB1"
WHERE
"UNIQUE#"=:1
AND

("UNIQUE#"=1
OR
"UNIQUE#"=2)
(accessing
'PDBORCL_R'
)

-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|
Id

|
Operation

|
Name

|
Rows

|
Bytes
|
Cost
(%CPU)|
Time

|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|

0
|
SELECT
STATEMENT

|

|

1
|

4
|

1

(0)|
00:00:01
|
|*

1
|

FILTER

|

|

|

|

|

|
|*

2
|

INDEX
UNIQUE
SCAN|
PK_TAB1
|

1
|

4
|

1

(0)|
00:00:01
|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
思えない...


リモートクエリーの分析結果
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|
Id

|
Operation

|
Name

|
Rows

|
Bytes
|
Cost
(%CPU)|
Time

|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|

0
|
SELECT
STATEMENT

|

|

200
|

2000
|

3

(0)|
00:00:01
|
|

1
|

INLIST
ITERATOR

|

|

|

|

|

|
|*

2
|

INDEX
RANGE
SCAN|
PK_TAB3
|

200
|

2000
|

3

(0)|
00:00:01
|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|
Id

|
Operation

|
Name

|
Rows

|
Bytes
|
Cost
(%CPU)|
Time

|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|

0
|
SELECT
STATEMENT

|

|

1
|

7
|

1

(0)|
00:00:01
|
|*

1
|

FILTER

|

|

|

|

|

|
|*

2
|

INDEX
UNIQUE
SCAN|
PK_TAB2
|

1
|

7
|

1

(0)|
00:00:01
|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|
Id

|
Operation

|
Name

|
Rows

|
Bytes
|
Cost
(%CPU)|
Time

|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|

0
|
SELECT
STATEMENT

|

|

1
|

4
|

1

(0)|
00:00:01
|
|*

1
|

FILTER

|

|

|

|

|

|
|*

2
|

INDEX
UNIQUE
SCAN|
PK_TAB1
|

1
|

4
|

1

(0)|
00:00:01
|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐


リモートクエリーの分析結果
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|
Id

|
Operation

|
Name

|
Rows

|
Bytes
|
Cost
(%CPU)|
Time

|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|

0
|
SELECT
STATEMENT

|

|

200
|

2000
|

3

(0)|
00:00:01
|
|

1
|

INLIST
ITERATOR

|

|

|

|

|

|
|*

2
|

INDEX
RANGE
SCAN|
PK_TAB3
|

200
|

2000
|

3

(0)|
00:00:01
|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|
Id

|
Operation

|
Name

|
Rows

|
Bytes
|
Cost
(%CPU)|
Time

|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|

0
|
SELECT
STATEMENT

|

|

1
|

7
|

1

(0)|
00:00:01
|
|*

1
|

FILTER

|

|

|

|

|

|
|*

2
|

INDEX
UNIQUE
SCAN|
PK_TAB2
|

1
|

7
|

1

(0)|
00:00:01
|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|
Id

|
Operation

|
Name

|
Rows

|
Bytes
|
Cost
(%CPU)|
Time

|
３本のリモートクエリは個別は、個別に発行
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
されており、実行計画は単純であり、SQL文
|

0
|
SELECT
STATEMENT

|

|

1
|

4
|

1

(0)|
00:00:01
|
|*

1
|

FILTER

|

|

|

|

|

|
単体ではチューニングが必要という状態には
|*

2
|

INDEX
UNIQUE
SCAN|
PK_TAB1
|

1
|

4
|

1

(0)|
00:00:01
|
ない....
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
ほかにチューニング可能な箇所はないか.......

改善できそうな箇所
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|
Id

|
Operation

|
Name

|
Rows

|
Bytes
|
Cost
(%CPU)|
Time

|
Inst

|IN-‐OUT|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|

0
|
SELECT
STATEMENT

|

|
20000
|

11M|

603

(0)|
00:00:01
|

|

|
|

1
|

NESTED
LOOPS

|

|

|

|

|

|

|

|
|

2
|

NESTED
LOOPS

|

|
20000
|

11M|

603

(0)|
00:00:01
|

|

|
|

3
|

NESTED
LOOPS

|

|

200
|
15600
|

3

(0)|
00:00:01
|

|

|
|

4
|

NESTED
LOOPS

|

|

200
|
13000
|

3

(0)|
00:00:01
|

|

|
|

5
|

REMOTE

|
TAB3

|

200
|

7800
|

3

(0)|
00:00:01
|
PDBOR~
|
R-‐>S
|
|

6
|

REMOTE

|
TAB2

|

1
|

26
|

0

(0)|
00:00:01
|
PDBOR~
|
R-‐>S
|
|

7
|

REMOTE

|
TAB1

|

1
|

13
|

0

(0)|
00:00:01
|
PDBOR~
|
R-‐>S
|
|*

8
|

INDEX
RANGE
SCAN

|
PK_TAB4
|

1
|

|

2

(0)|
00:00:01
|

|

|
|

9
|

TABLE
ACCESS
BY
INDEX
ROWID|
TAB4

|

100
|
51400
|

3

(0)|
00:00:01
|

|

|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
Predicate
Information
(identified
by
operation
id):
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

8
-‐
AND
AND


OR
"TAB4"."UNIQUE#"=2)


改善できそうな箇所
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|
Id

|
Operation

|
Name

|
Rows

|
Bytes
|
Cost
(%CPU)|
Time

|
Inst

|IN-‐OUT|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|

0
|
SELECT
STATEMENT

|

|
20000
|

11M|

603

(0)|
00:00:01
|

|

|
|

1
|

NESTED
LOOPS

|

|

|

|

|

|

|

|
|

2
|

NESTED
LOOPS

|

|
20000
|

11M|

603

(0)|
00:00:01
|

|

|
|

3
|

NESTED
LOOPS

|

|

200
|
15600
|

3

(0)|
00:00:01
|

|

|
|

4
|

NESTED
LOOPS

|

|

200
|
13000
|

3

(0)|
00:00:01
|

|

|
|

5
|

REMOTE

|
TAB3

|

200
|

7800
|

3

(0)|
00:00:01
|
PDBOR~
|
R-‐>S
|
|

6
|

REMOTE

|
TAB2

|

1
|

26
|

0

(0)|
00:00:01
|
PDBOR~
|
R-‐>S
|
|

7
|

REMOTE

|
TAB1

|

1
|

13
|

0

(0)|
00:00:01
|
PDBOR~
|
R-‐>S
|
|*

8
|

INDEX
RANGE
SCAN

|
PK_TAB4
|

1
|

|

2

(0)|
00:00:01
|

|

|
|

9
|

TABLE
ACCESS
BY
INDEX
ROWID|
TAB4

|

100
|
51400
|

3

(0)|
00:00:01
|

|

|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
Predicate
Information
(identified
by
operation
id):
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

３つのリモートクエリーをDB Linkを介して
ネットワーク越しにNested Loop結合を行っ

8
-‐
AND
AND
ている。


OR
"TAB4"."UNIQUE#"=2)
この部分をすべてリモートデータベース内で

完結させれば、多少の効率改善になるのでは
ないか....


治療方針

３つのリモートクエリーを
インラインビューにまとめ
ることで、１つのリモート
クエリーとして効率化を狙
う

SELECT

/*+
USE_NL(t01
tab4)
*/

tab4.*
FROM

(

SELECT

/*+
NO_MERGE
*/

tab3.unique#

,tab3.branch#

,tab3.loc#

FROM

tab1

INNER
JOIN
tab2

ON

tab1.unique#
=
tab2.unique#
AND
tab1.unique#
IN
(1,2)

INNER
JOIN
tab3

ON

tab2.unique#
=
tab3.unique#
AND
tab2.branch#
=
tab3.branch#

)
t01

INNER
JOIN
tab4

ON

t01.unique#
=
tab4.unique#
AND
t01.branch#
=
tab4.branch#

AND
t01.loc#

=
tab4.loc#
;


DEMO


治療後の実行計画(ローカル)
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|
Id

|
Operation

|
Name

|
Rows

|
Bytes
|
Cost
(%CPU)|
Time

|
Inst

|IN-‐OUT|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|

0
|
SELECT
STATEMENT

|

|
20000
|

10M|

2004

(1)|
00:00:01
|

|

|
|

1
|

NESTED
LOOPS

|

|

|

|

|

|

|

|
|

2
|

NESTED
LOOPS

|

|
20000
|

10M|

2004

(1)|
00:00:01
|

|

|
|

3
|

VIEW

|

|

200
|

7800
|

3

(0)|
00:00:01
|

|

|
|

4
|

REMOTE

|

|

|

|

|

|
PDBOR~
|
R-‐>S
|
|*

5
|

INDEX
RANGE
SCAN

|
PK_TAB4
|

100
|

|

2

(0)|
00:00:01
|

|

|
|

6
|

TABLE
ACCESS
BY
INDEX
ROWID|
TAB4

|

100
|
51400
|

10

(0)|
00:00:01
|

|

|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
Predicate
Information
(identified
by
operation
id):
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

5
-‐
access("T01"."UNIQUE#"="TAB4"."UNIQUE#"
AND
"T01"."BRANCH#"="TAB4"."BRANCH#"
AND

"T01"."LOC#"="TAB4"."LOC#")
Remote
SQL
Information
(identified
by
operation
id):
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

4
-‐
EXPLAIN
PLAN
SET
STATEMENT_ID='PLUS8440309'
INTO
PLAN_TABLE@!
FOR
SELECT
/*+
NO_MERGE
*/

"A1"."UNIQUE#","A1"."BRANCH#","A1"."LOC#"
FROM
"TAB1"
"A3","TAB2"
"A2","TAB3"
"A1"
WHERE

"A2"."UNIQUE#"="A1"."UNIQUE#"
AND
"A2"."BRANCH#"="A1"."BRANCH#"
AND

"A3"."UNIQUE#"="A2"."UNIQUE#"
AND
("A3"."UNIQUE#"=1
OR
"A3"."UNIQUE#"=2)
AND
("A2"."UNIQUE#"=1

OR
"A2"."UNIQUE#"=2)
AND
("A1"."UNIQUE#"=1
OR
"A1"."UNIQUE#"=2)
(accessing
'PDBORCL_R'
)


治療後の実行計画(リモート)
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|
Id

|
Operation

|
Name

|
Rows

|
Bytes
|
Cost
(%CPU)|
Time

|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|

0
|
SELECT
STATEMENT

|

|

20
|

420
|

3

(0)|
00:00:01
|
|

1
|

NESTED
LOOPS

|

|

20
|

420
|

3

(0)|
00:00:01
|
|

2
|

NESTED
LOOPS

|

|

20
|

340
|

3

(0)|
00:00:01
|
|

3
|

INLIST
ITERATOR

|

|

|

|

|

|
|*

4
|

INDEX
RANGE
SCAN|
PK_TAB3
|

200
|

2000
|

3

(0)|
00:00:01
|
|*

5
|

INDEX
UNIQUE
SCAN|
PK_TAB2
|

1
|

7
|

0

(0)|
00:00:01
|
|*

6
|

INDEX
UNIQUE
SCAN
|
PK_TAB1
|

1
|

4
|

0

(0)|
00:00:01
|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
Predicate
Information
(identified
by
operation
id):
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

4
-‐
access("A1"."UNIQUE#"=1
OR
"A1"."UNIQUE#"=2)

5
-‐
access("A2"."UNIQUE#"="A1"."UNIQUE#"
AND

"A2"."BRANCH#"="A1"."BRANCH#")

filter("A2"."UNIQUE#"=1
OR
"A2"."UNIQUE#"=2)

6
-‐
access("A3"."UNIQUE#"="A2"."UNIQUE#")

filter("A3"."UNIQUE#"=1
OR
"A3"."UNIQUE#"=2)


治療効果の確認

Elapsed TIme

Before
After

治療完！
釣ったSQL文はリリース


治療完！
釣ったSQL文はリリース
分散クエリーをチューニングする
スキルを手に入れた。:)


Oracle® Database管理者ガイド 12c リリース1 (12.1)
分散問合せのチューニング

http://docs.oracle.com/cd/E49329_01/server.
121/b71301/ds_appdev.htm#i1007640


バッファキャッシュ欠乏症


釣り上げたSQLは、バッフ
ァキャッシュが足りなくて
息も絶え絶え...ほとんどが
User I/O待機...治療法は...

問診結果
開口一番、予算はほぼないが小手先でなにか対処で
きない？
UPDATE文をループ処理内で繰り返し発行している
（ループ処理は大人の事情により一括化できない）
ストレージは非力で遅い
処理対象表のデータは増加しつづける
OracleはStandard Edition
年々というより毎月処理速度が劣化している
etc...

精密検査（コード）
DECLARE

CURSOR
cs_foobar
IS

SELECT

rowid

FROM

foobar

WHERE

unique#
BETWEEN
1
AND
400000

ORDER
BY

unique#

FOR
UPDATE;
BEGIN

FOR
row
IN
cs_foobar
LOOP

UPDATE
foobar

SET

foobar_str
=
LPAD('y',500,'y')

WHERE

rowid
=
row.rowid;

END
LOOP;

COMMIT;
END;
/


精密検査（統計情報）
USER_INDEXESより
TABLE_NAME
INDEX_NAME
NUM_ROWS
DISTINCT_KEYS CLUSTERING_FACTOR
-------------- --------------- ---------- ------------- ----------------FOOBAR
SYS_C0010235
2070913
2070913
2070899
USER_IND_COLUMNSより
NDEX_NAME
COLUMN_NAME
---------------- -------------SYS_C0010235
UNIQUE#
USER_TABLESより
TABLE_NAME
NUM_ROWS
AVG_ROW_LEN
------------ ---------- ----------FOOBAR
2000000
506


精密検査（統計情報）
USER_INDEXESより
TABLE_NAME
INDEX_NAME
NUM_ROWS
DISTINCT_KEYS CLUSTERING_FACTOR
-------------- --------------- ---------- ------------- ----------------FOOBAR
SYS_C0010235
2070913
2070913
2070899
USER_IND_COLUMNSより
NDEX_NAME
COLUMN_NAME
---------------- -------------SYS_C0010235
UNIQUE#

クラスタリング
ファクタが高い
400,000件更新するので全表走

USER_TABLESより
TABLE_NAME
NUM_ROWS
AVG_ROW_LEN
------------ ---------- ----------FOOBAR
2000000
506


査１回のほうが効率的だが..大
人の事情でできない。

精密検査（初期化パラメータ）
バッファキャッシュ関連
NAME
-------------------db_block_size
db_cache_size
db_16k_cache_size
db_2k_cache_size
db_32k_cache_size
db_4k_cache_size
db_8k_cache_size
pga_aggregate_target


TYPE
----------integer
big integer
big integer
big integer
big integer
big integer
big integer
big integer

VALUE
------8192
32M
0
0
0
0
0
512M

精密検査（初期化パラメータ）
バッファキャッシュ関連
NAME
-------------------db_block_size
db_cache_size
db_16k_cache_size
db_2k_cache_size
db_32k_cache_size
db_4k_cache_size
db_8k_cache_size
pga_aggregate_target


TYPE
----------integer
big integer
big integer
big integer
big integer
big integer
big integer
big integer

VALUE
------8192
32M
0
0
0
0
0
512M

確かに少ないです。
が....
大人の事情で物理メモリ
は増やせません！

精密検査（続き）
Block Size = 8192bytes → 4096blocks(Buffer Cache)
AVG_ROW_LEN = 506bytes、 PCTFREE＝10％
→ 1ブロックあたり14行程度（大雑把に計算すると）
200万行中、40万件更新 → 28,572blocks(程度は更新)
対象データブロックをすべてをバッファキャッシュに乗せるこ
とはできない。
脳内シュミレーション中....


治療法を考える
DECLARE

CURSOR
cs_foobar
IS

SELECT

rowid

FROM

foobar

WHERE

unique#
BETWEEM
1
AND
400000

ORDER
BY

unique#

FOR
UPDATE;
BEGIN

FOR
row
IN
cs_foobar
LOOP

UPDATE
foobar

SET

foobar_str
=
LPAD('y',500,'y')

WHERE

rowid
=
row.rowid;

END
LOOP;

COMMIT;
END;
/


治療法を考える

主キーのク

DECLARE
ラスタリングファクタ

CURSOR
cs_foobar
IS

SELECT

rowid
の高さとバッファキャッ

FROM

foobar

WHERE
スの少なさに

unique#
BETWEEM
1
AND
400000

ORDER
BY

unique#
着目！

FOR
UPDATE;
BEGIN

FOR
row
IN
cs_foobar
LOOP

UPDATE
foobar

SET

foobar_str
=
LPAD('y',500,'y')

WHERE

rowid
=
row.rowid;

END
LOOP;

COMMIT;
END;
/


仮説（現状の動作）
クラスタリングファクタの高い主キー索引でソート
主キー順で更新すると最悪の場合、１行毎に異なる
データブロックをバッファキャッシュに読み込む
バッファキャッシュは更新する全ブロックを保持でき
るほど大きくない。１行だけ更新されたデータブロ
ックがバッファキャッシュから書き出される可能性


現状の動き（妄想も含む）脳内シュミレーション中....
（１∼２５でソート後、１件毎に更新。１∼５の更新イメージ）

０

Buffer Cache

０
I/O回数合計

Storage

１６

１１

２２

４

２５

１

２３

１３

９

５

６

２

８

２０

２１
１０


１５

１２
２４

７
１９

１７
３

１４
１８

現状の動き（妄想も含む）脳内シュミレーション中....
（１∼２５でソート後、１件毎に更新。１∼５の更新イメージ）

０
１
5
4
3
2

１７
２１
１４
７
１２
１９
１０
１８
３
２４

Buffer Cache

２２
１１
１６
４
１５
１３
２３
２５
９
１

０
１
4
3
2

２０
８
２
５
６

I/O回数合計

Storage

１６

１１

２２

４

２５

１

２３

１３

９

５

６

２

８

２０

２１
１０


１５

１２
２４

７
１９

１７
３

１４
１８

仮説（治療後のイメージ）
ROWIDのブロック番号部分でソート
バッファキャッシュに読み込んだブロックに含まれる
全行を１行毎に更新。
バッファキャッシュは更新対象となる全ブロックを保
持できるほど大きくないが、１行毎に異なるブロッ
クを読み込む可能性は低くなる。（物理I/O削減）


治療後の動き（妄想も含む）脳内シュミレーション中....
（同一ブロック内の全行を１行毎に更新、全行の更新時のイメージ）
Buffer Cache

０
０
I/O回数合計

Storage

１６

１１

２２

４

２５

１

２３

１３

９

５

６

２

８

２０

２１
１０


１５

１２
２４

７
１９

１７
３

１４
１８

治療後の動き（妄想も含む）脳内シュミレーション中....
（同一ブロック内の全行を１行毎に更新、全行の更新時のイメージ）
Buffer Cache

１５
１６
４
２２
１１
２５
１３
１
９
２３
５
２０
２
６
８

５
４
３
２
１
０

１２
２１
１７
１４
７
２４
１０
１８
３
１９

４
３
２
１
０
I/O回数合計

Storage

１６
２５
５
２１
１０


１５
１

１１
２３

１２
２４

７
１９

６

２

２２
１３

４
９

８

２０

１７
３

１４
１８

治療方針確定
主キー順のソートは業務要件なのか？必須でなけ
れば、ソート条件を変更したい。（重要）
→回答：業務要件ではなく主キー順なら高速に処理
できると考えた。索引があるのでソート処理はバイパ
スされソート処理のコストがないので良しとしてい
た。


処方箋
DECLARE

CURSOR
cs_foobar
IS

SELECT

rowid

FROM

foobar

WHERE

unique#
BETWEEN
1
AND
400000

ORDER
BY

DBMS_ROWID.ROWID_BLOCK_NUMBER(rowid)

FOR
UPDATE;
BEGIN

FOR
row
IN
cs_foobar
LOOP

UPDATE
foobar

SET

foobar_str
=
LPAD('y',500,'y')

WHERE

rowid
=
row.rowid;

END
LOOP;

COMMIT;
END;
/


v$sysstatより
STATISTICS NAME

BEFORE

AFTER

Diff

dirty buffers inspected

785,126

298,823

-486,303

free buffer inspected

847,091

308,384

-538,707

free buffer requested

839,961

307,981

-531,980

physical read IO requests

791,470

273,368

-518,102

physical read total IO requests

794,522

274,376

-520,146

0

0

0

physical reads

802,309

273,605

-528,704

physical reads cache

802,140

273,410

-528,730

physical write IO requests

774,818

246,934

-527,884

physical write total IO requests

779,397

248,918

-530,479

physical writes

825,809

306,644

-519,165

physical writes from cache

825,631

306,479

-519,152

physical writes non checkpoint

818,900

303,921

-514,979

physical read total multi block requests


グラフ 10

治療効果の確認
900,000

675,000

225,000
0

free buﬀer requested
physical reads cache
physical writes from cache
BEFORE


AFTER

Blocks

450,000

治療完。
釣ったSQLはリリース！


治療完。
釣ったSQLはリリース！
バッファキャッシュを効果的に利
用するスキルを手に入れた。


釣り上げたSQLは、アレル
ギーを発症していた....
一度発症すると、一生付き
合って行くしか無い...

仕様書で見るERDは...

Oracle SQL Developer Data Modeler 4.0.0


リバースエンジニアリングすると...


キーレスエントリー
（SQLアンチパターンより）


よく見かけます。


なぜ
が発症してしまうの
でしょう？

通りすがりで、
SQLアンチパターン勉強会
へ参加した時のこと...
(@t_wadaさんにお会いした :）


否定派の意見(私見含む）
テストデータを作るときに面倒。
参照整合性制約？、なにそれ怖い症候群。
参照整合性制約って遅くね？
整合性チェックプログラムがあればOKじゃね。
etc....


賛成派の意見（私見含む）
参照整合性制約は、有効／無効化できる
データ不整合が発生した時の方が厄介だ
参照整合性制約が定義できないデータモデルのほう
が怖い
プログラムやSQL文のコード量が削減できる
オプティマイザが考慮してくる（SQL文最適化）
etc...

ERDではリレーションが定義されていて
も...


実際には参照整合性制約は定義されな
い。なぜ...


参照整合性制約のメリット
が語られてるのを見た事が
ない。→良さを知らない。
参照整合性制約？
なにそれ怖い症候群

そもそも参照整合性制約を
作成できない。

正規化できてない＞＜

後から気づいても、対処の
しようがない。（多分）


突然ですが、
ここで問題です


前のスライドでお見せした
ERDを基に、オーダー毎の
アイテム数を取得するクエ
リーを考えてください。


このようなクエリーを書く事に....
SELECT

orderitems.order#,COUNT(1)
FROM

orderitems

INNER
JOIN
items

ON

orderitems.item#
=
items.item#

INNER
JOIN
orders

ON

orderitems.order#
=
orders.order#

INNER
JOIN
customers

ON

orders.customer#
=
customers.customer#
GROUP
BY

orderitems.order#
;

理由は？
依存関係にあるデータの存在が保証され
ない為、依存関係にあるデータを結合し
ないと正しい結果が得られない可能性が
ある。念のために結合しておこう。


裏返せば、依存関係のあるデータの存在
が参照整合性制約で保証されていれば、
結合は不要！

結合は不要！
(大切なので２度書きました)


参照整合性制約がある場合は

これでいいですよね！
SELECT
FROM
orderitems
GROUP BY
orderitems.order#
;


オプティマイザーはどう判
断するのでしょう？


SELECT
FROM
orderitems
INNER JOIN items
ON
orderitems.item# = items.item#
INNER JOIN orders
ON
orderitems.order# = orders.order#
INNER JOIN customers
ON
orders.customer# = customers.customer#
GROUP BY
orderitems.order#
;


SELECT
FROM
orderitems
INNER JOIN items
ON
orderitems.item# = items.item#
INNER JOIN orders
ON
orderitems.order# = orders.order#
INNER JOIN customers
ON
orders.customer# = customers.customer#
GROUP BY
orderitems.order#
参照整合性制約の有無で実行計画がどう変
;
化するか見てみます！


参照整合性制約なし
実行計画
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
Plan
hash
value:
411877633
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|
Id

|
Operation

|
Name

|
Rows

|
Bytes
|TempSpc|
Cost
(%CPU)|
Time

|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|

0
|
SELECT
STATEMENT

|

|
50000
|

1464K|

|

1325

(3)|
00:00:16
|
|

1
|

SORT
GROUP
BY
NOSORT

|

|
50000
|

1464K|

|

1325

(3)|
00:00:16
|
|

2
|

NESTED
LOOPS

|

|

246K|

7212K|

|

1325

(3)|
00:00:16
|
|

3
|

NESTED
LOOPS

|

|

246K|

6010K|

|

1313

(2)|
00:00:16
|
|

4
|

MERGE
JOIN

|

|

247K|

4831K|

|

1301

(1)|
00:00:16
|
|

5
|

INDEX
FULL
SCAN

|
PK_ORDERITEMS
|

250K|

2441K|

|

1029

(1)|
00:00:13
|
|*

6
|

SORT
JOIN

|

|
50000
|

488K|

1976K|

271

(1)|
00:00:04
|
|

7
|

TABLE
ACCESS
FULL|
ORDERS

|
50000
|

488K|

|

68

(0)|
00:00:01
|
|*

8
|

INDEX
UNIQUE
SCAN

|
PK_ITEMS

|

1
|

5
|

|

0

(0)|
00:00:01
|
|*

9
|

INDEX
UNIQUE
SCAN

|
PK_CUSTOMERS

|

1
|

5
|

|

0

(0)|
00:00:01
|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
Predicate
Information
(identified
by
operation
id):
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

6
-‐
access("ORDERITEMS"."ORDER#"="ORDERS"."ORDER#")

filter("ORDERITEMS"."ORDER#"="ORDERS"."ORDER#")

8
-‐
access("ORDERITEMS"."ITEM#"="ITEMS"."ITEM#")

9
-‐
access("ORDERS"."CUSTOMER#"="CUSTOMERS"."CUSTOMER#")
統計
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

0

recursive
calls

0

db
block
gets

262017

consistent
gets

244

physical
reads

0

redo
size

1126677

bytes
sent
via
SQL*Net
to
client

37207

bytes
received
via
SQL*Net
from
client

3335

SQL*Net
roundtrips
to/from
client

1

sorts
(memory)

0

sorts
(disk)

50000

rows
processed


参照整合性制約あり
オプティマイザーは賢い :)
実行計画
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
Plan
hash
value:
3325112419
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|
Id

|
Operation

|
Name

|
Rows

|
Bytes
|TempSpc|
Cost
(%CPU)|
Time

|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
|

0
|
SELECT
STATEMENT

|

|
50536
|

246K|

|

516

(2)|
00:00:07
|
|

1
|

HASH
GROUP
BY

|

|
50536
|

246K|

2952K|

516

(2)|
00:00:07
|
|

2
|

INDEX
FAST
FULL
SCAN|
IX01_ORDERITEMS
|

250K|

1220K|

|

145

(1)|
00:00:02
|
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐
統計
-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

0

recursive
calls

0

db
block
gets

589

consistent
gets

0

physical
reads

0

redo
size

1126677

bytes
sent
via
SQL*Net
to
client

37207

bytes
received
via
SQL*Net
from
client

3335

SQL*Net
roundtrips
to/from
client

0

sorts
(memory)

0

sorts
(disk)

50000

rows
processed


無駄に結合してませんか？


DWHでも使えるんですよ:)


Oracle® Databaseデータ・ウェアハウス・ガイド
11gリリース2(11.2) / 整合性制約

http://docs.oracle.com/cd/E16338_01/server.112/
b56309/constra.htm#i1006284


アレルギーが発症してしま
った場合、一生うまく付き
合って行くしかない。
予防はアレルゲンを溜め込
みすぎないこと。

アレルギーが発症してしま
った場合、一生うまく付き
合って行くしかない。
予防はアレルゲンを溜め込
みすぎないこと。

抗アレルギー剤を手に入れた。

まとめ
過フィルタリング症候群（治癒）
クエリー分裂症（治癒）
バッファキャッシュ欠乏症（治癒）
参照整合性制約アレルギー（？）


最後に
2007年2月14日、 Insight World 2007というイベントがありました。
そのキーノートでアンニョ・コークさんがおっしゃっていたことを今でも思い出します。

アンニョ・コーク / "Oracle Performance Management: Past, Present and Future"
“Oracle10gがリリースされ初期化パラメータが少なくなり、Oracle⾃自⾝身が各パラメータを
調整するようになった今、DBAに求められる役割は、Oracleの細かなチュ−ニングよりも
アプリケーション側の問題を指摘したりすることにシフトしてきている。
....
パフォーマンス劣劣化問題の原因の多くは、データベース側というよりも
アプリケーション側にあることが多くなっている.”


ご清聴ありがとうございました

http://www.jpoug.org


db tech showcase Tokyo 2013 - A35 特濃JPOUG：潮溜まりでジャブジャブ、SQLチューニング

More Related Content

Featured

db tech showcase Tokyo 2013 - A35 特濃JPOUG：潮溜まりでジャブジャブ、SQLチューニング