oracle8/8iパフォーマンスチューニングⅡotndnld.oracle.co.jp/deploy/performance/pdf/oracle8i... ·...

1

1

Oracle8/8iパフォーマンスチューニングⅡパフォーマンスチューニングⅡパフォーマンスチューニングⅡパフォーマンスチューニングⅡ

日本オラクル株式会社日本オラクル株式会社日本オラクル株式会社日本オラクル株式会社

2

2

アジェンダ

• OLTPシステムのチューニング

• バッチ処理のチューニング

• DSSのチューニング

3

3

ＯＬＴＰシステムのチューニング

• ＯＬＴＰシステムの特徴

• チューニング事例

– STEP０エラーの回避

– STEP１共有プールの調整

– STEP２データベース・バッファの最適化

– STEP３Ｉ／Ｏ (ＤＢＷＲ) の最適化

– STEP４ＲＥＤＯＬＯＧ (ＬＧＷＲ) の最適化

– STEP５ロールバックセグメント待ちの解消

4

4

チューニング特性の理解

• OLTP処理

– 多同時ユーザー数サポート

– ショートトランザクション（更新処理）

– 定型処理

• DSS処理

– 比較的少ユーザー利用

– DWH

– 検索性能重視

– 非定型問合せ処理（Ad-hoc Query）

– バッチ処理による事前準備

5

5

OLTP処理の特徴

• 定型クエリーと定型更新

– あらかじめ予想可能な定型処理が中心

– インデックスの有効活用が可能

• データベースの規模より同時実行ユーザー数

– ショート・トランザクションの多重処理

– データベース・キャッシュの有効利用

• LGWRとDBWRの書き込み最適化– 大量のランダムWriteリクエストが発生

6

6










7

7

チューニングモデル

システム（300M）

stock（5,5G）

Temp（4G）

order_line（5G）

ware（4M）

iitem（2,5M）

icustomer（100M）

icustomer2（250M）

inew_order（50M）

REDOログ（2G）

REDOログ（2G）

アーカイブ・ログ（2G）

アーカイブ・ログ（2G）

customer（4G）

rollback（300M）

iorder_line（2G）

history（400M）

iorders（450M）

iorders2（200M）

istock（300M）

orders（300M）

new_order（125M）

item（20M）

2GB 2GB 2GB 2GB 2GB

2GB 2GB 2GB 2GB 2GB

2GB 2GB 2GB 2GB 2GB

2GB 2GB 2GB

<ハードウェア環境>CPU 250MHz ＊ 41GB Main MemoryDISK 2G × 18本

ユーザ数:１２０によるOLTP処理の

シュミレート

8

8

STEP０エラーの回避

• 予想されるエラーと回避方法

– ORA-04031（共有プールの不足）

• shared_pool_sizeを大きく取る

– ORA-00020（Processesの不足）

• processesを最大ユーザー数＋6システムプロセス）まで大きく

– ORA-01552（rollback_segmentsの不足）

• rollback_segmentsの数を最大ユーザー数まで

• max_rollback_segmentsをrollback_segments + 1に設定

9

9

• スタートポイントはデフォルトの初期化パラメータ

• 発生するエラーを回避するために、パラメータを変更

• エンドポイントはエラーが発生しなくなるまで

スタートポイント

10

10

• スタートポイント

– shared_pool_size = 3500000

– processes = 50

– rollback_segments = 4

– max_rollback_segments = 30

• 120 ユーザのシステムを想定

今回のスタートポイント

11

11

• ユーザを増やしていった結果３０ユーザで「ORA-04031」発生

• ３．５ＭＢで２０ユーザまでＯ．Ｋ．

• ２０×６＝１２０ユーザまで実行できるように

３．５ＭＢ×６＝２１ＭＢ

に設定

• 共有プールの更なるチューニングについてはＳＴＥＰ１で行う

shared_pool_size の調整

12

12

• ユーザを増やしていった結果５０ユーザで「ORA-00020」発生

• １２０ユーザ（１２０ユーザ＋６バックグラウンドプロセス）まで実行できるように１５０に設定

processes の調整

13

13

• ユーザを増やしていった結果１００ユーザで「ORA-1552」発生

• rollback_segments

– ４ → １２０に変更

• max_rollback_segmensts

– ３０ → １２１に設定

rollback_segments の調整

14

14










15

15

STEP1 共有プールの調整

SMON PMON DBWR LGWR ARCH CKPT

共有プール

ＳＧＡ (システムグローバルエリア)

データベースバッファ

16

16

共有プールの調整

• データベースバッファにできるだけメモリを使わせたい。

• パフォーマンスが落ちない程度に小さくする。

– ピーク時の共有プール使用量の確認

– ライブラリ・キャッシュのチューニング

• キャッシュ・ミスを減らす(SHARED_POOL_SIZE)– ディクショナリ・キャッシュのチューニング

• キャッシュ・ミスを減らす(SHARED_POOL_SIZE)

17

17

SQL> select sum(250*users_opening) from v$sqlarea;

SUM(SHARABLE_MEM)----------------- 1343625

SQL> select sum(sharable_mem) from v$db_object_cache;

SUM(SHARABLE_MEM)----------------- 523848

SQL> select sum(sharable_mem) from v$sqlarea;

SUM(SHARABLE_MEM)----------------- 3547088

TOTAL： 5,414,561 Bytes

使用状況の確認作業

ピーク時の共有プール使用量の確認

ピーク時５．５ＭＢ → 余裕を持って１０ＭＢまで小さくする

18

18

• ヒット率（PINHITRATIO）は90%以上が理想

• リロード（RELOADS）は0が理想

– ヒット率が低くリロードがある場合はshared_pool_sizeを増やす

LIBRARY GETS GETHITRATI PINS PINHITRATI RELOADS INVALIDATI------------ ---------- ---------- ---------- ---------- ---------- ----------BODY 980 .992 980 .981 0 0CLUSTER 73 .986 107 .981 0 0INDEX 0 1 0 1 0 0OBJECT 0 1 0 1 0 0PIPE 0 1 0 1 0 0SQL AREA 4936 .921 75297 .99 1 4TABLE/PROCED 1541 .907 30894 .991 0 0TRIGGER 0 1 0 1 0 0

90%以上にゼロに近く

ライブラリキャッシュのチューニング

目標

19

19

– ミス（GET_MISS, SCAN_MISS）が多い場合はshared_pool_sizeを増やす

– CUR_USAGEがCOUNTに達している場合はshared_pool_sizeを増やす

NAME GET_REQS GET_MISS SCAN_REQ SCAN_MIS MOD_REQS COUNT CUR_USAG--------------- -------- -------- -------- -------- -------- -------- --------dc_tablespaces 912 10 0 0 0 12 11dc_free_extents 272 95 36 0 84 64 57dc_segments 885 90 0 0 41 248 238dc_rollback_seg 3636 0 0 0 0 364 356dc_used_extents 79 56 0 0 57 74 53dc_tablespace_q 2 1 0 0 2 7 1dc_users 1403 10 0 0 0 25 11dc_user_grants 907 9 0 0 0 10 9dc_objects 1252 117 0 0 5 243 238

GET_MISS／GET_REQS ＜０．１５ゼロに近く COUNT > CUR_USAGE

ディクショナリキャッシュのチューニング

目標

20

20

ＳＴＥＰ１でのチューニング

• 無駄なメモリーは使わない

– shared_pool_size

• ３５ＭＢ → １０ＭＢ

• パフォーマンス劣化無し

21

21










22

22

STEP2 データベース・バッファの調整


共有プール


ＳＧＡ (システムグローバルエリア)

23

23

データベースバッファの調整

• キャッシュ・ヒット率

– バッファ数の調整(DB_BLOCK_BUFFERS)

• LRUラッチの競合

– LRUリスト数の調整(DB_BLOCK_LRU_LATCHES)

24

24

キャッシュヒット率の確認

• ヒット率 = 1 - (‘physical reads’ / (‘consistent gets’ + ‘db block gets’))– ヒット率が90%未満の場合はdb_block_buffersを増やす

Statistic Total Per Transact Per Logon Per Second--------------------------- ------------ ------------ ------------ ------------consistent gets 831184 125.67 5894.92 689.21db block gets 263825 39.89 1871.1 218.76physical reads 809041 122.32 5737.88 670.85

I/O統計

ヒット率＝ 1－（809041／（831184＋263825））＝ 1－809041／1095009≒ 0.26（26%）

25

25

ページングの防止

• db_block_buffersを増やすほどパフォーマンスが向上

• db_block_buffersがあるサイズを超えるとOSのページングおよびスワッピングが発生してパフォーマンスが極端に低下

db_block_buffersサイズと性能

0.00

500.00

1000.00

1500.00

2000.00

2500.00

3000.00

50

100

150

200

250

300

350

400

450

500

550

600

650

700

750

800

Buffer Size (MBytes)

ページングの発生

ページングが発生するまでは増やさない事

26

26

データベースバッファの調整

• キャッシュ・ヒット率

– バッファ数の調整(DB_BLOCK_BUFFERS)

• LRUラッチの競合

– LRUリスト数の調整(DB_BLOCK_LRU_LATCHES)

27

27

ロックとラッチ－ロック

・ロックは、Ｏｒａｃｌｅの各リソースをエンキューを使用して排他制御する

・ ENQUEUEの取得例

enqueue

12

プロセスAプロセスB

28

28

ロックとラッチ－ラッチ

・ラッチとは、Oracleのメモリ上のリソースを取得するために

必要な事前に取得する権利

プロセスA プロセスB

latch

プロセスAがLatchを解放するまでGetをリトライする

29

29

LRUチェーン

LRUWチェーン( ダーティリスト )

バッファ・キャッシュ

先頭最後

フリーブロックの検索

全てのバッファはどちらかのリストでポイントされている

① LRUリストの末尾から使用可能バッファを探索する。② その際使用済みバッファが存在すれば、LRUWリストにエントリーする。③ 使用可能バッファがあればデータをキャッシュする。④ 使用可能バッファが見つからない時は、DBWRによる書込みを待つ⑤ 使用済みバッファは、DBWRによってデータファイルに書き込まれると、使用可能バッファとなり再利用される

使用可能バッファ：変更の加わっていないバッファ使用済みバッファ： commitの有無に関わらず変更の加わっているバッファ

30

30

LRUチェーン


ラッチ競合


LRUリストはLRUラッチで管理サーバプロセスA

LRUラッチ

ラッチを獲得したプロセスがLRUリストにアクセスできる

サーバプロセスB ラッチを獲得するまで

待ち状態

競合

31

31

LRUチェーン


ラッチ競合の回避

LRUリストはLRUラッチで管理サーバプロセスA

LRUラッチ

ラッチを獲得したプロセスがLRUリストにアクセスできる

サーバプロセスB

LRUチェーン



LRUラッチ

LRUのセットを複数作成することにより競合を回避できる・ DB_BLOCK_BUFFERSをLRUセット数で割った分のブロック数を１つのLRUセットで管理

・ LRUセットの数は db_block_lru_latches で設定する

32

32

LRUリスト数の調整

• データベースバッファにアクセスするプロセスは、まずラッチを獲得する必要がある。

• ラッチが獲得できなかったプロセスは、一定時間待った後で再度獲得を試み、成功するまで繰り返す

• マルチCPU環境で、ヒット率（cache buffers lru）が低い場合、db_block_lru_latches（デフォルトはCPU数の半分）をCPUと同じ数程度まで増やしてみる。

LATCH_NAME GETS MISSES HIT_RATIO SLEEPS SLEEPS/MISS------------------ ----------- ----------- ----------- ----------- -----------cache buffer handl 162239 97 .999 22 .227cache buffers chai 32309956 19758 .999 5318 .269cache buffers lru 90222 10400 .885 2267 .218

ラッチ統計

できるだけ１に近づける

33

33

ＳＴＥＰ２でのチューニング

• データベースバッファは最大に(注)

– db_block_buffers

• ４００ＫＢ → ７５０ＭＢ (1875倍)

• ヒット率２６％ → ９４％

• ラッチ競合の回避

– db_block_lru_latches

• ２ → ４

• HIT_RATIO 89％ → 98％

• 性能１６倍ＵＰ

(注) ページングの発生に注意すること

34

34










35

35

STEP３Ｉ／Ｏ (ＤＢＷＲ) の最適化


共有プール


36

36

• ＲＥＤＯログファイルとデータベースファイルを別のディスクに置く。

• １つのディスクに頻繁にアクセスする表が複数ある場合は、表を別のデイスクに格納する。

• 索引付きの表に頻繁にアクセスする場合、表と索引を別のディスクに格納する。

• 大きな表に頻繁にアクセスする場合、表を複数のディスクに分割して格納する。( 表のストライピング )

• ソート処理をするユーザの一時表領域を表が格納されているディスクと分け、更にストライピングを行う。

• 基本方針に従いファイル配置を決め、テストを実施。あるディスクにＩ／Ｏが集中している時は、頻繁にアクセスされるファイルをあまりＩ／Ｏが発生していないディスクに移動する。

Ｉ／Ｏ分散の基本方針

37

37

SVRMGR> Rem I/O should be spread evenly accross drives. A big difference betweenSVRMGR> Rem phys_reads and phys_blks_rd implies table scans are going on.SVRMGR> select table_space, file_name, 2> phys_reads reads, phys_blks_rd blks_read, phys_rd_time read_time, 3> phys_writes writes, phys_blks_wr blks_wrt, phys_wrt_tim write_time, 4> megabytes_size megabytes 5> from stats$files order by table_space, file_name;

TABLE_SPACE FILE_NAME READS BLKS_READ READ_TIME WRITES BLKS_WRT WRITE_TIME------------- --------------------- -------- --------- --------- --------- --------- ---------------RBS /DISK2/rbs01.dbf 26 26 50 257 257 411SCOTT_DATA /DISK4/scott_dat.dbf 65012 413752 38420 564 564 8860SCOTT_INDEX /DISK4/scott_idx.dbf 8 8 0 8 8 0SYSTEM /DISK1/sys01.dbf 806 1538 1985 116 116 1721TEMP /DISK1/tmp01.dbf 168 666 483 675 675 0USER_DATA /DISK3/user01.dbf 8 8 0 8 8 0

6 rows selected.

Ｉ／Ｏの監視

• ＵＴＬＢＳＴＡＴ／ＵＴＬＥＳＴＡＴＵＴＬＢＳＴＡＴ／ＵＴＬＥＳＴＡＴＵＴＬＢＳＴＡＴ／ＵＴＬＥＳＴＡＴＵＴＬＢＳＴＡＴ／ＵＴＬＥＳＴＡＴにて特定ディスクにＩ／Ｏが発生していないか確認する

38

38

ＳＴＥＰ３でのチューニング

• ディスク負荷のバランスを取る

– アクセスが高い表に対するDISKを増やす(stock表とcustomer表)

– REDOログに格納しているディスクのBUSY率が低かったので、これに割り当てられているDISKを減らす

• CPU使用率のWAIT 40% → 25%

• パフォーマンス１５％UP

39

39










40

40

ＲＥＤＯＬＯＧ (ＬＧＷＲ) の最適化


共有プール


ログバッファ

41

41

ログバッファ・サイズの調整(1)

• ‘log buffer space’のAvg Timeが5秒（500）以上の場合

– log_bufferを大きくする

– REDOログをストライピングする

Event Name Count Total Time Avg Time-------------------------------- ------------- ------------- -------------log buffer space 1053 43223 41.05

log buffer space

LGWRがログバッファ中のログをREDOログファイルに書き出すより、バッファが満杯になる速度が早く、バッファへのスペース・リクエストが発生するので、待ちが発生している状態。

42

42

ログバッファ・サイズの調整(2)

• redo log space requestsが0以外の場合– log_bufferを大きくする

Statistic Total Per Transact Per Logon Per Second--------------------------- ------------ ------------ ------------ ------------redo entries 2617867 23.49 18566.43 2054.84redo log space requests 237 0 1.68 .19redo size 782928712 7025.31 5552685.9 614543.73redo small copies 413287 3.71 2931.11 324.4

redo log space requests

アクティブログファイルが一杯で領域の割当てを待っている状態。

43

43

ＳＴＥＰ４でのチューニング

• STEP4 REDOログの最適化

(大量更新では効果大)

– log_buffer を8192(デフォルト)、32768、163840と変化させたが性能の向上が見られなかった

44

44










45

45

STEP５ロールバックセグメント待ちの解消

• trans_tbl_waits = 0が理想

• trans_tbl_waits / trans_tbl_gets > 0.05 (5%)の場合は、ロールバック・セグメントを追加する

UNDO_SEGMENT TRANS_TBL_GETS TRANS_TBL_WAITS UNDO_BYTES_WRITTENSEGMENT_SIZE_BYTES XACTS SHRINKS WRAPS------------------- ------------------- ------------------- -------------------------------------- ------------------- ------------------- ------------------- 0 8 0 0 407552 0 0 0 235 2665 1 1890278 796672 0 0 16 236 2783 0 1898696 264192 0 0 17

46

46

ＳＴＥＰ５でのチューニング

• STEP5 ロールバックセグメントの最適化

( MAX User を意識した設定にする)– 初期の段階で十分に設定したためチューニングは行わなかった

47

47

チューニング効果の測定

• それぞれのステップを実施（倍率で表示）

STEP

0 1 2 3 4 5

15

30倍倍倍倍

(注) このデータはある特定の条件下でのテスト結果ですあくまでも1つの例としてお考え下さい

48

48

アジェンダ




49

49

バッチ処理のチューニング

ダイレクトロード

REDO情報の書込み中止

ロールバックセグメント

一時表領域

50

50

SQL*Loader

制御ファイル制御ファイル制御ファイル制御ファイル

テキスト・ファイルテキスト・ファイルテキスト・ファイルテキスト・ファイル

データベースデータベースデータベースデータベース

表表表表

SQL*Loader

INSERTINSERT

INSERT

表表表表

テキスト・ファイルのデータをデータベースの表に取りいれるためのユーティリティ

SQL*Loader 従来型パス従来型パス従来型パス従来型パスダイレクト・パスダイレクト・パスダイレクト・パスダイレクト・パス

従来型パス従来型パス従来型パス従来型パス

51

51

SQL*Loaderのダイレクト・ロード

• データベースのブロックイメージを直接作るので、処理が早い

sqlldr scott/tiger control=lineitem.ctl direct=true従来型パス従来型パス従来型パス従来型パスダイレクト・パスダイレクト・パスダイレクト・パスダイレクト・パス

0

2000

4000

8000

6000

処理時間(係数値)

400MBのデータをロードのデータをロードのデータをロードのデータをロード

制御ファイル制御ファイル制御ファイル制御ファイル

データ・ファイルデータ・ファイルデータ・ファイルデータ・ファイル

データベースデータベースデータベースデータベース

表表表表

SQL*Loader

ブロックブロックブロックブロック

表表表表


52

52





一時表領域

53

53


REDOログを書き出さないため、高速な処理が可能

例) データ件数 200,731件の列にNon_Unique索引作成

Create Index … LOGGING

Create Index … NOLOGGING

27％短縮

大量データのロード後の索引作成などに効果大索引作成後は、必ずバックアップの取得を運用に組み込むこと


54

54





一時表領域

55

55

INITIAL , NEXTで指定するサイズは必ず同一サイズにする専用の表領域に配置する扱うデータよりも大きなものを数個用意するOLTP用のRBSと使い分ける

ロールバックセグメントのチューニング

56

56

ＲＢＳ RB_BIG

ＲＢＳ RB_SMALL1

ＲＢＳ RB_SMALL2

BEGIN SET TRANSACTION USE RALLBACK SEGMENT rb_big … … …END ；

<バッチ処理>

オンラインプロセス1オンラインプロセス2オンラインプロセス3オンラインプロセス4

特定のRBSが設定されていない場合はOracleが自動的に割り当てる

ロールバックセグメントの使い分け

57

57





一時表領域

58

58

一時表領域

• INDEX作成やデータの集計などソート処理を伴うバッチ的

な処理には高速なディスクを用意する

• 専用の表領域を使用する

(CREATE TABLE SPACE ～ TEMPORARYを使用)• INITIALとNEXTを同じ値にPCTINCREASEを０に設定

• INDEX作成などの大量のソートを伴うバッチ処理では、大

きなサイズにする

– 例．INITIAL 100MB NEXT 100MB

59

59

アジェンダ




60

60

ＤＳＳのチューニング

• ＤＳＳシステムの特徴

• Ｉ／Ｏのチューニング

• パフォーマンスアップの為の機能

– ビットマップインデックス(チューニングⅠ参照)

– ハッシュジョイン

– パラレルクエリー

– パーティション化

– マテラアライズド・ビュー


61

61

チューニング特性の理解

• OLTP処理

• 多同時ユーザー数サポート

• ショートトランザクション（更新処理）

• 定型処理

• DSS処理

• 比較的少ユーザー利用

• DWH

• 検索性能重視

• 非定型問合せ処理（Ad-hoc Query）

• バッチ処理による事前準備

62

62

ＤＳＳ処理の特徴

• 非定型クエリーへの対応

– 全件検索処理の効率化

– 既存のインデックスの有効活用

• 大規模データベースへの対応

– 検索範囲の明確化と絞り込み

– パラレル検索処理の活用

• 日次バッチ処理の高速化– データの大量一括処理(Update/Delete/Insert)

63

63











64

64

Ｉ／Ｏのチューニング

• 特に注意すべき部分

– 大規模な表が格納されている表領域のＩ／Ｏを分散する。

– 一時表領域はＤＳＳではネックになりやすいのでＩ／Ｏを分散の効果大。

• ソート処理

• ジョイン処理

– ハッシュ・ジョイン／ソートマージジョイン

65

65

ソート処理の確認方法

• UTLBSTAT/UTLESTATにてディスクでソート処理

が起こっているか確認する

SVRMGR> Rem The total is the total value of the statistic between the time

SVRMGR> Rem bstat was run and the time estat was run. Note that the estat

SVRMGR> Rem script logs on as "internal" so the per_logon statistics will

SVRMGR> Rem always be based on at least one logon.

SVRMGR> select n1.name "Statistic",

・

Statistic Total Per Transact Per Logon Per Second

--------------------------- ------------ ------------ ------------ ------------

CPU used by this session 536 536 268 1.68

・

・

sorts (memory) 94 94 94 1.43

sorts (disk) 1 1 1 0.01

sorts (rows) 3743 3743 3743 136.86

テンポラリー表領域を使用してソートが行われたことを示しているテンポラリー表領域を使用してソートが行われたことを示しているテンポラリー表領域を使用してソートが行われたことを示しているテンポラリー表領域を使用してソートが行われたことを示している

DSSDSSDSSDSSでは、すべてのソート処理をでは、すべてのソート処理をでは、すべてのソート処理をでは、すべてのソート処理をメモリ上で実行することは困難。メモリ上で実行することは困難。メモリ上で実行することは困難。メモリ上で実行することは困難。できるだけできるだけできるだけできるだけSORT_AREA_SIZESORT_AREA_SIZESORT_AREA_SIZESORT_AREA_SIZEをををを

大きくする。大きくする。大きくする。大きくする。

66

66











67

67

SELECTSELECTSELECTSELECT ename ename ename ename , , , , emp emp emp emp....deptnodeptnodeptnodeptno , , , , loc loc loc loc FROM FROM FROM FROM emp emp emp emp , dept , dept , dept , dept WHERE WHERE WHERE WHERE emp emp emp emp....deptnodeptnodeptnodeptno = dept. = dept. = dept. = dept.deptno deptno deptno deptno

ジョイン処理とは

EMPEMPEMPEMP表表表表

ENAME DEPTNOENAME DEPTNOENAME DEPTNOENAME DEPTNO

SMITH 20SMITH 20SMITH 20SMITH 20ALLEN 30ALLEN 30ALLEN 30ALLEN 30WARD 20WARD 20WARD 20WARD 20JONES 40JONES 40JONES 40JONES 40 … …

DEPTDEPTDEPTDEPT表表表表

DEPTNO LOCDEPTNO LOCDEPTNO LOCDEPTNO LOC

10 BOSTON10 BOSTON10 BOSTON10 BOSTON20 NEW YORK20 NEW YORK20 NEW YORK20 NEW YORK30 DALLAS30 DALLAS30 DALLAS30 DALLAS40 CHICAGO40 CHICAGO40 CHICAGO40 CHICAGO … …

結果結果結果結果

＋

ENAME DEPTNO LOCENAME DEPTNO LOCENAME DEPTNO LOCENAME DEPTNO LOC

SMITH 20 NEWYORKSMITH 20 NEWYORKSMITH 20 NEWYORKSMITH 20 NEWYORKALLEN 30 DALLASALLEN 30 DALLASALLEN 30 DALLASALLEN 30 DALLASWARD 20 NEWYORKWARD 20 NEWYORKWARD 20 NEWYORKWARD 20 NEWYORKJONES 40 CHICAGOJONES 40 CHICAGOJONES 40 CHICAGOJONES 40 CHICAGO … …

３つのジョイン方法３つのジョイン方法３つのジョイン方法３つのジョイン方法１．１．１．１．ネステッドループジョインネステッドループジョインネステッドループジョインネステッドループジョイン２．２．２．２．ソートマージジョインソートマージジョインソートマージジョインソートマージジョイン３．３．３．３．ハッシュジョインハッシュジョインハッシュジョインハッシュジョイン

68

68

ネステッドループジョイン／ソートマージジョイン

ネステッドループジョイン ① EMP表を全表走査する ② EMP表の各行について、DEPTNOが対応するものを探す ③ EMP表の各行と②で得たデータを結合し、結果を返す

SELECTSELECTSELECTSELECT ename ename ename ename , , , , emp emp emp emp．．．．deptnodeptnodeptnodeptno , , , , loc loc loc loc FROM FROM FROM FROM emp emp emp emp , dept , dept , dept , dept WHERE WHERE WHERE WHERE emp emp emp emp．．．．deptnodeptnodeptnodeptno = dept = dept = dept = dept．．．．deptno deptno deptno deptno

ソートマージジョイン ① EMP表とDEPT表を、DEPTNO順にソートする ② EMP表とDEPT表をマージし、その結果を返す

ソートが発生するので、ソートが発生するので、ソートが発生するので、ソートが発生するので、SORT_AREA_SIZESORT_AREA_SIZESORT_AREA_SIZESORT_AREA_SIZE で指定したメモリ領域で指定したメモリ領域で指定したメモリ領域で指定したメモリ領域で処理がしきれないと一時表領域を使用するで処理がしきれないと一時表領域を使用するで処理がしきれないと一時表領域を使用するで処理がしきれないと一時表領域を使用する

69

69

ハッシュテーブルハッシュテーブルハッシュテーブルハッシュテーブル

＜ＳＴＥＰ１＞＜ＳＴＥＰ１＞＜ＳＴＥＰ１＞＜ＳＴＥＰ１＞ハッシュテーブルの作成ハッシュテーブルの作成ハッシュテーブルの作成ハッシュテーブルの作成（（（（ビルド・フェーズビルド・フェーズビルド・フェーズビルド・フェーズ））））＜ＳＴＥＰ２＞＜ＳＴＥＰ２＞＜ＳＴＥＰ２＞＜ＳＴＥＰ２＞外部表の読み込みとジョイン（外部表の読み込みとジョイン（外部表の読み込みとジョイン（外部表の読み込みとジョイン（プローブ･フェーズプローブ･フェーズプローブ･フェーズプローブ･フェーズ））））

DEPTNO DEPTNO DEPTNO DEPTNO modulo modulo modulo modulo ３３３３

ハッシュジョイン（１）

DEPTDEPTDEPTDEPT表表表表

DEPTNO LOCDEPTNO LOCDEPTNO LOCDEPTNO LOC

10 BOSTON10 BOSTON10 BOSTON10 BOSTON20 NEW YORK20 NEW YORK20 NEW YORK20 NEW YORK30 DALLAS30 DALLAS30 DALLAS30 DALLAS40 CHICAGO40 CHICAGO40 CHICAGO40 CHICAGO … …

＜ＳＴＥＰ１＞＜ＳＴＥＰ１＞＜ＳＴＥＰ１＞＜ＳＴＥＰ１＞ハッシュテーブルの作成ハッシュテーブルの作成ハッシュテーブルの作成ハッシュテーブルの作成（（（（ビルド・フェーズビルド・フェーズビルド・フェーズビルド・フェーズ））））

片方のテーブルを読み、ハッシュ関数をかけ、ハッシュテーブル片方のテーブルを読み、ハッシュ関数をかけ、ハッシュテーブル片方のテーブルを読み、ハッシュ関数をかけ、ハッシュテーブル片方のテーブルを読み、ハッシュ関数をかけ、ハッシュテーブル((((一種の索引一種の索引一種の索引一種の索引) ) ) ) をメモリ内に作成するをメモリ内に作成するをメモリ内に作成するをメモリ内に作成する

００００

１１１１

２２２２

(30 (30 (30 (30 DALLAS )DALLAS )DALLAS )DALLAS )

(10 (10 (10 (10 BOSTON (40 CHICAGO) BOSTON (40 CHICAGO) BOSTON (40 CHICAGO) BOSTON (40 CHICAGO)

(20 (20 (20 (20 NEW YORK NEW YORK NEW YORK NEW YORK

ハッシュインデックスハッシュインデックスハッシュインデックスハッシュインデックスハッシュチェインハッシュチェインハッシュチェインハッシュチェイン

70

70

ハッシュジョイン（２）

ENAME DEPTNO LOCENAME DEPTNO LOCENAME DEPTNO LOCENAME DEPTNO LOC

SMITH 20 NEWYORKSMITH 20 NEWYORKSMITH 20 NEWYORKSMITH 20 NEWYORKALLEN 30 DALLASALLEN 30 DALLASALLEN 30 DALLASALLEN 30 DALLASWARD 20 NEWYORKWARD 20 NEWYORKWARD 20 NEWYORKWARD 20 NEWYORKJONES 40 CHICAGOJONES 40 CHICAGOJONES 40 CHICAGOJONES 40 CHICAGO … …

ハッシュテーブル

００００

１１１１

２２２２

(10 (10 (10 (10 BOSTON (40 CHICAGO) BOSTON (40 CHICAGO) BOSTON (40 CHICAGO) BOSTON (40 CHICAGO)

(20 (20 (20 (20 NEW YORK NEW YORK NEW YORK NEW YORK

EMP表

ENAME DEPTNOENAME DEPTNOENAME DEPTNOENAME DEPTNO

SMITH 20SMITH 20SMITH 20SMITH 20ALLEN 30ALLEN 30ALLEN 30ALLEN 30WARD 20WARD 20WARD 20WARD 20JONES 40JONES 40JONES 40JONES 40

… …

DEPTNO DEPTNO DEPTNO DEPTNO にハッシュ関数をかけにハッシュ関数をかけにハッシュ関数をかけにハッシュ関数をかけ該当するものを探索該当するものを探索該当するものを探索該当するものを探索

ジョイン

ハッシュエリアを展開するメモリ領域はPGA内に取られる

＜ＳＴＥＰ２＞＜ＳＴＥＰ２＞＜ＳＴＥＰ２＞＜ＳＴＥＰ２＞外部表の読み込みとジョイン（外部表の読み込みとジョイン（外部表の読み込みとジョイン（外部表の読み込みとジョイン（プローブ･フェーズプローブ･フェーズプローブ･フェーズプローブ･フェーズ））））

０

１

２

(30 DALLAS )

(10 BOSTON (40 CHICAGO)

(20 NEW YORK

71

71

• ハッシュジョイン処理に使用されるメモリの最大値を指定する初期化パラメータ

• サーバプロセス毎に動的に割り当てられる（ＰＧＡの領域を利用）

• ハッシュジョイン処理が、ＨＡＳＨ_AREA_SIZE を越える領域が必要な場合、一時表領域を使用する

• デフォルトはＳＯＲＴ_ＡＲＥＡ_ＳＩＺＥの２倍

• 一時表領域への書込みが発生している場合、大きく設定する

– スワップが発生するほど大きく設定しない事

– サーバプロセス毎に取られる事にも注意する事

ＨＡＳＨ_AREA_SIZE のチューニング

72

72

ジョイン処理に対するヒント

ORDERD FROM句で指定された順序で表を結合させる

USE_NL(table) ネスティッド・ループ・ジョインで結合させる

USE_MERGE(table) ソート・マージ・ジョインで結合させる

USE_HASH(table) ハッシュジョインで結合させる

73

73











74

74

パラレル・クエリー

AAAA

BBBB

CCCC

AAAA

BBBB

CCCC

AAAA

BBBB

CCCC

問合わせ問合わせ問合わせ問合わせサーバーサーバーサーバーサーバー

AAAA


BBBB


CCCC


FFFF


EEEE


DDDD

問合わせ問合わせ問合わせ問合わせコーディネータコーディネータコーディネータコーディネータ

①①①①SQLSQLSQLSQL文の文の文の文の実行実行実行実行

②問合わせサーバーの確保②問合わせサーバーの確保②問合わせサーバーの確保②問合わせサーバーの確保 ③読み込み範囲の指定③読み込み範囲の指定③読み込み範囲の指定③読み込み範囲の指定

④データの読み込み④データの読み込み④データの読み込み④データの読み込み⑤ソートの実行⑤ソートの実行⑤ソートの実行⑤ソートの実行

⑥検索結果⑥検索結果⑥検索結果⑥検索結果を戻すを戻すを戻すを戻す

SELECT deptno,sum(sal) FROM emp GROUP BY deptno;

並列度３並列度３並列度３並列度３

75

75

並列度の設定

① ＳＱＬ文でのヒント句での並列度

– SELECT /*+ FULL(emp) PARALLEL(emp,5) */ ～

② 表定義でのパラレル句での並列度

– CREATE TABLE ～

PARALLEL (DEGREE 3 )

③ データベースのデフォルト並列度

優先度

76

76

パラレル・クエリー関連の重要パラメータ

PARALLEL_MIN_SERVERS … インスタンス起動時に作成する

問合せサーバ数

PARALLEL_MAX_SERVERS … システムで使用できる最大の

問合せサーバ数

目安 PARALLEL_MAX_SERVERS = (使用する最大の並列度) × (問合せの同時実行数) × ２

77

77

パラレルクエリーのチューニング

• 各リソースとのバランスを考え、並列度を決めていく

– ＣＰＵ

• ＣＰＵを使い切っているようだったら、並列度を下げ、余裕があるようだったら並列度を上げる

– ＤＩＳＫ

• 少なくとも並列度と同じ台数のDISKにデータがストライピングされている事が望ましい

– メモリ

• 問合わせサーバ毎にSORT_AREA_SIZE 、HASH_AREA_SIZE で設定したメモリを使用する事に注意

78

78











79

79

パーティション化

• Oracle8 R8.0のパーティショニング

– レンジパーティショニング

• Oracle8i のパーティショニング

– ハッシュパーティショニング

– コンポジットパーティショニング

• Oracle8i での機能強化・変更点

– パーテイション・プルーニング

– パーテイション・ワイズ・ジョイン

80

80

パーティション化とは

• 大規模な表や索引を複数の小さな部分(パーティション)に分割

• パーティション毎にセグメント

• 管理性向上

• 可用性向上

• パフォーマンス向上

81

81

レンジ・パーティショニング

• 管理性向上

• 可用性向上

• パフォーマンス向上レンジ・パーティショニングレンジ・パーティショニングレンジ・パーティショニングレンジ・パーティショニング

パーティショニング・カラムの値がパーティショニング・カラムの値がパーティショニング・カラムの値がパーティショニング・カラムの値がどの｢レンジ｣に入っているかどの｢レンジ｣に入っているかどの｢レンジ｣に入っているかどの｢レンジ｣に入っているかによってによってによってによって格納するパーティションを決定格納するパーティションを決定格納するパーティションを決定格納するパーティションを決定

salesdate

～1997-03-31

1997-04-01～

1997-06-30

1997-07-01～

1997-09-30

1997-10-01～

1997-12-31

sales97q1

sales97q2

sales97q3

sales97q4

sales97

表領域q1

表領域q4

表領域q3

表領域q2

1997-04-01

1997-07-01

1997-10-01

1998-01-01

82

82

管理操作性の向上

• パーティション単位で管理可能

• 時系列データベースの定期メンテナンス

– 日付のレンジでパーティション化

sales97q1

sales97q2

sales97q3

sales97q4

sales96q4

Partitioned Table

P1

P2

P3

DROP PARTITION ...DROP PARTITION ...DROP PARTITION ...DROP PARTITION ...

ローディングローディングローディングローディング((((sqlldrsqlldrsqlldrsqlldr))))

ANALYZE...PARTITIONANALYZE...PARTITIONANALYZE...PARTITIONANALYZE...PARTITION

83

83

可用性の向上

• 定期メンテナンス時の可用性– 管理作業をパーティション単位で実行

– 管理作業を複数のパーティションで同時に(パラレルに)実行

• 不慮の障害時の可用性– パーティション毎に別々のディスクを使用

– パーティションを細かく分割

•影響範囲の減少

•停止時間の短縮

Partitioned Table

P1

P2

P3

ローディングローディングローディングローディング((((sqlldrsqlldrsqlldrsqlldr))))

INSERT INTO ...INSERT INTO ...INSERT INTO ...INSERT INTO ...

DROP PARTITION ...DROP PARTITION ...DROP PARTITION ...DROP PARTITION ...

84

84

パフォーマンスの向上

• 効果的なＩ／Ｏ負荷分散

• パーティション・エルミネーション

Hot Data

OldHistricalData

高速ストライプ高速ストライプ高速ストライプ高速ストライプボリュームボリュームボリュームボリューム

低速大容量低速大容量低速大容量低速大容量ディスクディスクディスクディスク

sales97q1 sales97q2 sales97q3 sales97q4

sales97

SELECT ... FROM sales97WHERE date=TO_DATE(‘1997-09-16’,’YYYY-MM-DD’);

必要なパーティションのみにアクセス

85

85










86

86

Oracle8i で追加されたパーティショニング・メソッド

コンポジット・コンポジット・コンポジット・コンポジット・パーティショニングパーティショニングパーティショニングパーティショニング

ハッシュ・ハッシュ・ハッシュ・ハッシュ・パーティショニングパーティショニングパーティショニングパーティショニング

NewNew

87

87

ハッシュ・パーティショニングパーティション数パーティション数パーティション数パーティション数:8

ハッシュ関数ハッシュ関数ハッシュ関数ハッシュ関数

パーティショニング・カラムとパーティション数を基にOracle内部のハッシュ関数で自動的にパーティションに分割データの分散が簡単に出来る

パーティション数:8

パーティショニング・カラムパーティショニング・カラムパーティショニング・カラムパーティショニング・カラム

番号名前1 川上2 三好3 島野4 小野5 大西

1 川上

2 三好

3 島野4 小野

5 大西

88

88

パーティション・プルーニング

• =、INまたはIS NULL条件の時にパーティション・プルーニング(エリミネーション)可能

• 範囲条件の時はパーティション・プルーニングできない

ハッシュ・パーティショニングされたテーブルのハッシュ・パーティショニングされたテーブルのハッシュ・パーティショニングされたテーブルのハッシュ・パーティショニングされたテーブルのパーティション・プルニングパーティション・プルニングパーティション・プルニングパーティション・プルニング

0

5,000

10,000

15,000

20,000

25,000

30,000

35,000

40,000

45,000

"="条件 "IN"条件範囲条件

ブロック

P1

P2

P3

P4

P5

P6

P7

P8

1. col = 52. col IN (1,2,3,4)3. col < 5

89

89

ハッシュ・パーティショニング～可用性～

ハッシュ関数ハッシュ関数ハッシュ関数ハッシュ関数(orderkey)

レンジ・パーティショニングレンジ・パーティショニングレンジ・パーティショニングレンジ・パーティショニング

1～3月(orderdate)

Q2～Q4のデータは使用可能

ハッシュ・パーティショニングハッシュ・パーティショニングハッシュ・パーティショニングハッシュ・パーティショニング

どのデータが使用可能かわからない

4～6月(orderdate)

7～9月(orderdate)

10～12月(orderdate)

90

90

ハッシュパーティショニング

• 簡単に必要なパーテイションにサイズの偏りなく、データ分散が出来る(注)

→ I／Ｏ分散によるパフォーマンスＵＰ

• パーティションプルニング

→ アクセスブロックの減少によるパフォーマンスＵＰ

• レンジパーティションのような可用性は無い。

(注) 使用されるOracleのハッシュ関数の関係で、パーティション数が２累乗でないと各パーテイションに偏りができる

91

91










92

92

コンポジット・パーティショニングパーティショニングパーティショニングパーティショニングパーティショニング(レンジレンジレンジレンジ)

Q1 Q2 Q3 Q4

クォーター毎にレンジで4分割、さらに、パーティション内をハッシュで4分割。合計16個のサブパーティション。

サブパーティショニング(

ハッシュ)

レンジとハッシュを組合わせたパーティション

必ず先にレンジでパーティションしてから、各パーティションをハッシュでパーテイションする

サブパーティション

93

93

パーティション・プルーニング

SELECT SUM(price)FROM salesWHERE sales_date BETWEEN ‘19990701’ AND ‘19990930’AND cust_id = 5;

パーティションパーティションパーティションパーティションQ3Q3Q3Q3内で、内で、内で、内で、cust_idcust_idcust_idcust_id=5=5=5=5のデータを含むのデータを含むのデータを含むのデータを含むサブパーティションのみをアクセスサブパーティションのみをアクセスサブパーティションのみをアクセスサブパーティションのみをアクセス

cust_id列でハッシュ・サブパーティショニング

sales_date列のレンジでパーティショニング

Q1 Q2 Q3 Q4

該当するサブパーティションのみ該当するサブパーティションのみ該当するサブパーティションのみ該当するサブパーティションのみをアクセスするをアクセスするをアクセスするをアクセスする

94

94










95

95

パーティション・プルーニング（１）

• Oracle8.0 → パーティション・エリミネーション

– 連続したパーティションにしかアクセス出来なかった

• Oracle8i → パーティション・プルーニング

– クエリー実行に必要なパーティションだけにアクセス

– Oracle8 R8.0では、連続したパーティションにしかアクセスできなかったが、Oracle8iでは、ピン・ポイントでアクセス可能

96

96

パーティション・プルーニング（２）

SELECT SUM(price)FROM salesWHERE quarter IN (’Q1’,’Q4’);

Oracle8 R8.0Oracle8 R8.0Oracle8 R8.0Oracle8 R8.0

Q1Q1Q1Q1 Q2Q2Q2Q2 Q3Q3Q3Q3 Q4Q4Q4Q4

Oracle8Oracle8Oracle8Oracle8iiii

Q1Q1Q1Q1 Q2Q2Q2Q2 Q3Q3Q3Q3 Q4Q4Q4Q4Oracle8 R8.0では、すべてのパーティションにアクセスしていたが、Oracle8iでは、Q1とQ4だけにアクセス

97

97










98

98

パーティション・ワイズ・ジョイン

対応するデータがあるパーティション対応するデータがあるパーティション対応するデータがあるパーティション対応するデータがあるパーティション同士をパーティション単位でジョイン同士をパーティション単位でジョイン同士をパーティション単位でジョイン同士をパーティション単位でジョイン

実行時間削減実行時間削減実行時間削減実行時間削減使用リソース削減使用リソース削減使用リソース削減使用リソース削減

読込・ジョイン




customer(ハッシュハッシュハッシュハッシュ) sales(ハッシュハッシュハッシュハッシュ)

パーティションパーティションパーティションパーティションごとにジョインごとにジョインごとにジョインごとにジョイン

99

99

Oracle8iでのメリット

• ハッシュ・パーティショニングに対応

• コンポジット・パーティショニングを利用することでパーティション・プルーニングと組合せ可能

SELECT c.cust_name, SUM(s.price) FROM sales s, customer cWHERE c.cust_id = s.cust_id AND s.quarter = ‘Q3’;

sales(レンジレンジレンジレンジ)customer


Q1Q1Q1Q1 Q2Q2Q2Q2 Q3Q3Q3Q3 Q4Q4Q4Q4

sales(コンポジットコンポジットコンポジットコンポジット)customer(ハッシュハッシュハッシュハッシュ)




100

100











101

101

マテリアライズド・ビュー

• マテリアライズド・ビューとは

• マテリアライズド・ビューの機能

– リフレッシュ

– クエリーリライト

– アドバイザ機能

102

102

マテリアライズド・ビューとは？

l RDBMSが用意している「サマリー表(中間テーブル)」

l 集計や結合を行った結果を実際に格納しておき、クエリーパフォーマンスを向上させる

l データを実際に格納した「ビュー」

マスター表マスター表マスター表マスター表

地方地方地方地方

時間時間時間時間

支店支店支店支店売上売上売上売上

都道府県都道府県都道府県都道府県製品製品製品製品

売上集計売上集計売上集計売上集計

売上集計が知りたい！売上集計が知りたい！売上集計が知りたい！売上集計が知りたい！

集計・結合集計・結合集計・結合集計・結合

マテリアライズド･マテリアライズド･マテリアライズド･マテリアライズド･ビュービュービュービュー

CREATE MATERIALIZED VIEW sumAS SELECT … FROM 売上、時間売上、時間売上、時間売上、時間････････････;

103

103

サマリー表(中間テーブル)の問題点

従来のやり方でサマリー表(中間テーブル)を作成すると･･

! マスター表のデータをサマリー表に反映する仕組みを作る必要がある。

! サマリー表を意識したアプリケーションを作る必要がある。

?複数のサマリー表がある時、どれを使ったら一番効率が良いのか分からない。

?どのようなサマリー表をつくっていいのか分からない。

104

104

マテリアライズド･ビューのメリット

マテリアライズド･ビューでサマリー表を作成すれば･･

① リフレッシュ

• マスター表のデータをサマリー表に反映する仕組み（リフレッシュ）がある。

② クエリーリライト

• サマリー表を意識したアプリケーションを作る必要がない。

• コストベースオプティマイザが、効率良く検索できるサマリー表を選択する。

③ アドバイザ

• サマリー表を作る指針を提供する。

105

105







106

106

リフレッシュ（１）



支店支店支店支店

売上売上売上売上

都道府県都道府県都道府県都道府県

製品製品製品製品

今年の売上集計が知りたい！今年の売上集計が知りたい！今年の売上集計が知りたい！今年の売上集計が知りたい！

マスター表へアクセスした結果とマスター表へアクセスした結果とマスター表へアクセスした結果とマスター表へアクセスした結果とサマリー表へアクセスした結果はサマリー表へアクセスした結果はサマリー表へアクセスした結果はサマリー表へアクセスした結果は同じ結果になるはず同じ結果になるはず同じ結果になるはず同じ結果になるはず

本来は本来は本来は本来は

98年度売上集計年度売上集計年度売上集計年度売上集計

100万円万円万円万円



=

サマリー表サマリー表サマリー表サマリー表

====98989898年１～１１月分売上明細年１～１１月分売上明細年１～１１月分売上明細年１～１１月分売上明細 98989898年１～１１月分売上明細年１～１１月分売上明細年１～１１月分売上明細年１～１１月分売上明細

107

107








リフレッシュ（２）

今年の売上集計が知りたい！今年の売上集計が知りたい！今年の売上集計が知りたい！今年の売上集計が知りたい！ところがところがところがところがマスター表が更新されるとマスター表が更新されるとマスター表が更新されるとマスター表が更新されるとクエリーの結果が異なるクエリーの結果が異なるクエリーの結果が異なるクエリーの結果が異なる

12121212月分の月分の月分の月分の売上詳細売上詳細売上詳細売上詳細20202020万円万円万円万円

DBA





≠≠≠≠

!?


≠≠≠≠98989898年１～年１～年１～年１～１２１２１２１２月分売上明細月分売上明細月分売上明細月分売上明細 98989898年１～１１月分売上明細年１～１１月分売上明細年１～１１月分売上明細年１～１１月分売上明細

108

108








リフレッシュ（３）


リフレッシュしてメンテナンスを行う必要がある。

そこでサマリー表に変更を反映させるそこでサマリー表に変更を反映させるそこでサマリー表に変更を反映させるそこでサマリー表に変更を反映させる

リフレッシュリフレッシュリフレッシュリフレッシュ





=


====98989898年１～年１～年１～年１～１２１２１２１２月分売上明細月分売上明細月分売上明細月分売上明細 98989898年１～年１～年１～年１～１２１２１２１２月分売上明細月分売上明細月分売上明細月分売上明細

109

109







110

110

クエリーリライト（１）

従来のやり方でのサマリー表を作成した場合

ユーザーユーザーユーザーユーザー

ユーザー（アプリケーション）からユーザー（アプリケーション）からユーザー（アプリケーション）からユーザー（アプリケーション）からマスター表とサマリー表のどちらにアクセスマスター表とサマリー表のどちらにアクセスマスター表とサマリー表のどちらにアクセスマスター表とサマリー表のどちらにアクセスするのかを意識する必要があるするのかを意識する必要があるするのかを意識する必要があるするのかを意識する必要がある

マスター表マスター表マスター表マスター表


select ... from master;

select ... from summary;

111

111

クエリーリライト（２）

マテリアライズド・ビューでサマリー表を作成した場合

ユーザーユーザーユーザーユーザーマスター表マスター表マスター表マスター表

マテリアライズド・ビューマテリアライズド・ビューマテリアライズド・ビューマテリアライズド・ビュー

•ユーザー（アプリケーションユーザー（アプリケーションユーザー（アプリケーションユーザー（アプリケーション))))はマスター表へのはマスター表へのはマスター表へのはマスター表へのクエリーを書くだけでよいクエリーを書くだけでよいクエリーを書くだけでよいクエリーを書くだけでよい

コストベースコストベースコストベースコストベースオプティマイザオプティマイザオプティマイザオプティマイザクエリークエリークエリークエリー

リライトリライトリライトリライト

•コストベースオプティマイザがコストベースオプティマイザがコストベースオプティマイザがコストベースオプティマイザが自動的に自動的に自動的に自動的に使用可能使用可能使用可能使用可能で最適なマテリアライズド・ビューに対するクエで最適なマテリアライズド・ビューに対するクエで最適なマテリアライズド・ビューに対するクエで最適なマテリアライズド・ビューに対するクエリーに書き換えを行う（リライト）リーに書き換えを行う（リライト）リーに書き換えを行う（リライト）リーに書き換えを行う（リライト）

ssssｅｌｅｃｔｅｌｅｃｔｅｌｅｃｔｅｌｅｃｔ … from from from from summarysummarysummarysummary;;;;

ssssｅｌｅｃｔｅｌｅｃｔｅｌｅｃｔｅｌｅｃｔ … from from from from mastermastermastermaster;;;;

112

112







113

113

アドバイザ機能

• DBMS_OLAPパッケージでアドバイザ機能を提供

• データディクショナリの情報と、Oracle Traceから得られる作業負荷情報を使用

• マテリアライズド・ビューに関する3つの情報を提供

– サイズ推測

– 使用状況

– 推奨

アドバイザアドバイザアドバイザアドバイザ(DBMS_OLAP)

データディクショナリ情報

作業負荷情報

（オプション）

Oracle Trace

マテリアライズマテリアライズマテリアライズマテリアライズ

ド・ビューのサド・ビューのサド・ビューのサド・ビューのサ

イズ推測イズ推測イズ推測イズ推測

マテリアライズド・ビューの推奨マテリアライズド・ビューの推奨マテリアライズド・ビューの推奨マテリアライズド・ビューの推奨

マテリアライズドマテリアライズドマテリアライズドマテリアライズドビュー使用状況ビュー使用状況ビュー使用状況ビュー使用状況

114

114











115

115

チューニング事例

• 中規模DSS環境でのチューニング事例

– WindowsNT Server 4.0 使用

– Oracle R7.3.2.2 (注)

• チューニングテクニック

– コストベース・オプティマイザの利用

– ハッシュジョインの使用

– パラレル・クエリーの活用

(注) 今回の事例の考え方は、Basicな部分なので、Oracle8 / 8i でも同様

116

116

マシン構成

Pentium ProPentium ProPentium ProPentium Pro(166MHz) (166MHz) (166MHz) (166MHz) ×××× 4 4 4 4

ＣＰＵＣＰＵＣＰＵＣＰＵ

メモリメモリメモリメモリ 640 640 640 640MBMBMBMB

メモリメモリメモリメモリ

CD-ROMCD-ROMCD-ROMCD-ROM

各テーブル、各テーブル、各テーブル、各テーブル、TEMPORARY、、、、RBS用表領域用表領域用表領域用表領域

4GB x 7=28GB(ハードウェアハードウェアハードウェアハードウェアRAID0)

ALLEY CONTROLLER

WindowsNT ORACLE_HOME SYSTEM表領域表領域表領域表領域 REDOログログログログ

117

117

Oracle の設定

チューニング前の主なチューニング前の主なチューニング前の主なチューニング前の主なinit.oraパラメータパラメータパラメータパラメータ

compatible = 7.3.2.2.1compatible = 7.3.2.2.1compatible = 7.3.2.2.1compatible = 7.3.2.2.1

db_block_sizedb_block_sizedb_block_sizedb_block_size = 8192 = 8192 = 8192 = 8192

db_file_multiblock_read_countdb_file_multiblock_read_countdb_file_multiblock_read_countdb_file_multiblock_read_count = 7 = 7 = 7 = 7

db_block_buffersdb_block_buffersdb_block_buffersdb_block_buffers = 1000 = 1000 = 1000 = 1000

hash_multiblock_io_counthash_multiblock_io_counthash_multiblock_io_counthash_multiblock_io_count = 7 = 7 = 7 = 7

sort_direct_writessort_direct_writessort_direct_writessort_direct_writes = true = true = true = true

parallel_max_serversparallel_max_serversparallel_max_serversparallel_max_servers = 250 = 250 = 250 = 250

processes = 50processes = 50processes = 50processes = 50

sort_area_sizesort_area_sizesort_area_sizesort_area_size = 1000000 = 1000000 = 1000000 = 1000000

hash_area_sizehash_area_sizehash_area_sizehash_area_size = 2000000 = 2000000 = 2000000 = 2000000

parallel_min_serversparallel_min_serversparallel_min_serversparallel_min_servers = 8 = 8 = 8 = 8

118

118

SQL文

select ps_partkey, sum(ps_supplycost*ps_availqty) as value

from partsupp, supplier, nation

where ps_suppkey=s_suppkey

and s_nationkey=n_nationkey

and n_name='GERMANY'

group by ps_partkey

having sum(ps_supplycost*ps_availqty) >

(select

sum(ps_supplycost*ps_availqty) * 0.00001

from partsupp, supplier, nation

where ps_suppkey=s_suppkey

and s_nationkey=n_nationkey

and n_name='GERMANY'

)

order by value desc;

ドイツ製部品の中で、在庫金額がドイツ全体のドイツ製部品の中で、在庫金額がドイツ全体のドイツ製部品の中で、在庫金額がドイツ全体のドイツ製部品の中で、在庫金額がドイツ全体の0.001%0.001%0.001%0.001%より大きい部品の部品番号と在庫金額より大きい部品の部品番号と在庫金額より大きい部品の部品番号と在庫金額より大きい部品の部品番号と在庫金額を、在庫金額の多い順に表示するを、在庫金額の多い順に表示するを、在庫金額の多い順に表示するを、在庫金額の多い順に表示するSQLSQLSQLSQL文文文文

データ件数データ件数データ件数データ件数

partsupp 800万件万件万件万件

supplier 10万件万件万件万件

nation 25件件件件

119

119

実行計画

O_NODE OPERATION OPTIONS O_NAME OTHER_TAG

-------- ------------------------ --------- -------- -----------------------------

SELECT STATEMENT Cost = 32424

:Q123005 SORT ORDER BY PARALLEL_TO_SERIAL

:Q123004 FILTER PARALLEL_TO_PARALLEL

:Q123004 SORT GROUP BY PARALLEL_COMBINED_WITH_PARENT

:Q123003 HASH JOIN PARALLEL_TO_PARALLEL

:Q123001 NESTED LOOPS PARALLEL_TO_PARALLEL

:Q123000 TABLE ACCESS FULL NATION PARALLEL_FROM_SERIAL

:Q123001 TABLE ACCESS FULL SUPPLIER PARALLEL_COMBINED_WITH_PARENT

:Q123002 TABLE ACCESS FULL PARTSUPP PARALLEL_TO_PARALLEL

SORT AGGREGATE

:Q122003 HASH JOIN PARALLEL_TO_SERIAL

:Q122001 NESTED LOOPS PARALLEL_TO_PARALLEL

:Q122000 TABLE ACCESS FULL NATION PARALLEL_FROM_SERIAL

:Q122001 TABLE ACCESS FULL SUPPLIER PARALLEL_COMBINED_WITH_PARENT

:Q122002 TABLE ACCESS FULL PARTSUPP PARALLEL_TO_PARALLEL

120

120

パフォーマンスモニターの結果１

ディスク使用率に余裕がある

DiskQueueLengthの値が1より低い

I/O速度は、約6MB/秒

TEMP I/Oが多発している

CPU使用率が低い

121

121

検証１

• パフォーマンス・モニターの結果

– CPU/ディスクともに使用率低い

パラレル・クエリー処理の実行パラレル・クエリー処理の実行パラレル・クエリー処理の実行パラレル・クエリー処理の実行

並列度をどうするか？並列度をどうするか？並列度をどうするか？並列度をどうするか？

→→→→ CPU*2 = 8 CPU*2 = 8 CPU*2 = 8 CPU*2 = 8 と仮定して実施と仮定して実施と仮定して実施と仮定して実施

実行時間実行時間実行時間実行時間----------------------------------------------------

417.63 417.63 417.63 417.63

実行時間は時間に係数をかけた値です

122

122

パフォーマンスモニターの結果２

ディスク使用率が常時100%のI/Oネック

I/O処理はRAIDコントローラが行うため

CPU使用率が低い

haiving句からクエリー

本体へ処理が移る時に16個のスレッドが起動

I/O速度は、約15MB/秒

ソートのためのTEMP I/O

ハッシュジョインのためのTEMP書き込み

DiskQueueLengthの値が常時、非常に高い(約30)

123

123

検証２

並列度並列度並列度並列度 8 8 8 8


417.63 417.63 417.63 417.63


181.16 181.16 181.16 181.16

236 236 236 236短縮短縮短縮短縮

• パフォーマンス・モニターパフォーマンス・モニターパフォーマンス・モニターパフォーマンス・モニターの結果の結果の結果の結果

– ディスク使用率は常時ディスク使用率は常時ディスク使用率は常時ディスク使用率は常時100%100%100%100%

– ディスク競合が発生ディスク競合が発生ディスク競合が発生ディスク競合が発生並列度を並列度を並列度を並列度を 4 4 4 4 に変更に変更に変更に変更


124

124

検証３

並列度並列度並列度並列度 8

実行時間実行時間実行時間実行時間------------- 417.63


236短縮短縮短縮短縮




• パフォーマンス・モニターパフォーマンス・モニターパフォーマンス・モニターパフォーマンス・モニターの結果の結果の結果の結果– ソートや結合時にソートや結合時にソートや結合時にソートや結合時にTEMPORARY表領域を使用表領域を使用表領域を使用表領域を使用

初期化パラメータの変更初期化パラメータの変更初期化パラメータの変更初期化パラメータの変更sort_area_size 2,000,000 →→→→ 6,000,000hash_area_size 1,000,000 →→→→ 10,000,000


125

125

パフォーマンスモニターの結果３

haiving句の処理に移る時に8個のクエリーサーバー

が起動

I/Oネックは解消せず

DiskQueueLengthの値が12位まで下がった

I/O速度は、約15MB/秒を維持

ソート中のディスクアクセスがなくなった

ソート、ジョインのためのTEMP I/Oは完全になくなった

126

126

検証４








init.ora変更変更変更変更（ソート（ソート（ソート（ソート,ハッシュ）ハッシュ）ハッシュ）ハッシュ）



• パフォーマンス・モニターの結果– I/Oがボトルネックがボトルネックがボトルネックがボトルネック

– ディスクネックではなくディスクネックではなくディスクネックではなくディスクネックではなくSCSIバスネックバスネックバスネックバスネック

ディスク構成の変更ディスク構成の変更ディスク構成の変更ディスク構成の変更 2本の本の本の本のSCSIチャネルにデータ・ディスクを分散チャネルにデータ・ディスクを分散チャネルにデータ・ディスクを分散チャネルにデータ・ディスクを分散


127

127

検証５



417.63 417.63 417.63 417.63


181.16 181.16 181.16 181.16

236 236 236 236短縮短縮短縮短縮


171.16 171.16 171.16 171.16


10 10 10 10短縮短縮短縮短縮

initinitinitinit....oraoraoraora変更変更変更変更（ソート（ソート（ソート（ソート,,,,ハッシュ）ハッシュ）ハッシュ）ハッシュ）


163.59 163.59 163.59 163.59

8 8 8 8短縮短縮短縮短縮


111.80 111.80 111.80 111.80

ディスク構成変更ディスク構成変更ディスク構成変更ディスク構成変更


73.2%73.2%73.2%73.2%短縮短縮短縮短縮 !! !! !! !!


128

128

チューニング事例まとめ

• 中規模DSS環境のチューニング・ポイント

– ハッシュ・ジョインとパラレル・クエリーの組み合わせが効果的

– メモリー上のソート領域やハッシュ領域を大きく確保

– 表のデータ件数に応じた適切な処理方法

– I/O競合をおこさないようなデータ配置

• データのストライピング

129

129

チューニング作業

チューニングというのは「データの取得」 → 「データ分析」 → 「改善作業」 → 「データの取得」 …の地道な繰り返しツールを有効に使い作業効率を上げる事が重要

システム開発の初期の段階からパフォーマンスチューニングを意識した開発を行う

現在のシステムにおいては、Ｉ／Ｏの部分がネックにな

るケースが多いこの部分をいかに減らすかがポイント

130

SOFTWARE POWERS THE INTERNET

oracle8/8iパフォーマンスチューニングⅡotndnld.oracle.co.jp/deploy/performance/pdf/oracle8i... ·...

Documents