Oracle Direct Seminar · • SQLチューニングのアプローチ •...

<Insert Picture Here>

Oracle Direct Seminar

オラクルコンサルタントが語るSQLチューニングの真髄-解決編Part5 -

日本オラクル株式会社

Copyright© 2010 Oracle. All rights reserved. 2

アジェンダ

• はじめに• これまでの振り返り（Part1～Part4）

• 本日の範囲とゴール

• 設計と各種最適化の関係• 設計の定義とフォーカスする範囲

• 設計、実装レベルのチューニング• データ主観の設計 -正規化と統合化 -

• 業務を最適化する設計

• 性能を最適化する設計

• データベースの機能を使用した対処案

• まとめ

• Appendix 付録

・SQL Serverからの移行アセスメント・MySQLからの移行相談

・PostgreSQLからの移行相談・Accessからの移行アセスメント

・Oracle Database バージョンアップ支援・Oracle Developer/2000 Webアップグレード相談

・パフォーマンス・クリニック・Oracle Database 構成相談

・Oracle Database 高可用性診断・システム連携アセスメント・システムセキュリティ診断

・簡易業務診断・メインフレーム資産活用

無償技術サービスOracle Direct Concierge

http://www.oracle.com/lang/jp/direct/services.html



はじめに

• これまでの振り返り（Part1～4）

• 本日の範囲とゴール


• 解決編、とうとうPart5

• SQLチューニングのアプローチ

• パフォーマンス問題発生の理由の考察

• 定型的なチューニング

• 非定型的なチューニング

• アーキテクチャを意識したチューニング

• APロジックや設計を意識したチューニング

and more..

オプティマイザへのインプット情報は妥当か？

自身で実行計画を検討

オプティマイザが生成した実行計画は適切か？

インプット情報を修正できるか？

NOYES

NOYES

NOYESNO

YES

チューニング完了

NO

パフォーマンスは妥当か？

SQL単体以外のチューニング

アプリケーションチューニング

設計チューニング

多重処理チューニング

これまでの振り返り（Part1～4）


コンサルタントのチューニング・アプローチ

アーキテクチャを意識した

SQLチューニング

定型的な


非定型的な


21 3

システムのパフォーマンス問題のほとんどがSQL

パフォーマンス問題に帰着する

SQLパフォーマンス問題が減らない

SQLパフォーマンス問題の解決に時間がかかる

何をどのように調査すればよいのかわからない

言語的特徴に起因する理由がある

• 記述に対する柔軟性が高い

• 処理ロジックを意識させないコーディングができる

• 同一の処理内容に対して、複数の記述方法が可能

• 処理方法はデータベースに任されている

開発時の状況や意識に及ぶ理由がある

• 正しい結果が返ることには気にしても、処理の効率化やデータベース内での処理を意識した開発に気が回らない

現場の声・現状原因・理由

Part1/Part2 Part3

SQLパフォーマンス問題解決へのアプローチ問題発生の原因と理由の考察


予防チューニング

問題がおきたら最低限これだけはチェックする

最低限これだけは守ってコーディングする

「定型的なSQLチューニング」 =「最低限のSQLコーディング・ルール」

• 柔軟な言語だからこそ、守るべきルールが存在する

• 大きく4つのカテゴリに分かれる• アーキテクチャに伴う性能問題を避けるためのルール

• 使用方法やノウハウを元に性能問題を避けるためのルール

• 可読性や管理性を高めるためのルール

• 運用ポリシーを考慮したルール

• ルールを活用するにはポイントがある

• 開発者にも直観的にわかりやすいものにする

• ルールが必要となる理由を明確にし、指針、注意点、例なども加える

• プログラムレビューと同様にSQLコーディングもレビュー（チェックシートでチェック）

SQLパフォーマンス問題解決へのアプローチ定型的なSQLチューニング


• CBOのインプット、アウトプット情報

• 「実行計画」を作成するために必要な情報は何か

CBO(コストベースオプティマイザ)

SQLテキスト

パラメータ

オブジェクト構造

環境

実行計画

レスポンス

統計情報データの実態

SQLパフォーマンス問題解決へのアプローチ非定型的なSQLチューニング


妥当性の判断

全パターンを検証するのは難しい

意識するのは

・SQL単体の最適化

・システム全体の最適化表結合方法

表結合順序

索引を利用して参照

表を直接参照

データアクセス方法

全表スキャン（TABLE ACCESS FULL）

索引のレンジスキャン（INDEX RANCE SCAN）

索引の一意スキャン（INDEX UNIQUE SCAN）

索引のフルスキャン（INDEX FULL SCAN）

索引の高速フルスキャン（INDEX FAST FULL SCAN）

ネステッドループ結合

索引のスキップスキャン（INDEX SKIP SCAN）

ハッシュ結合

ソートマージ結合

直積結合

判断のポイント分岐の種類

EMP表から？DEPT表から？それとも・・



TAB2

ID

CLASS

TAB1

ID

START_DATE <= :b3+1

END_DATE > :b3


アクセス1回⇒絞込でX件ヒット

NLアクセス X回⇒X*1件ヒット

①

TAB3

ID

CLASS

NLアクセス X回⇒X*63.5件ヒット

②

TAB4

CODE = :b2

FLAG = ‘Y’

CLASS

③

NL アクセスX*63.5回⇒絞込で2件ヒット

TAB5

NUM = :b1

CLASS

④

NL アクセス2回⇒絞込で1 or 2件ヒット

Start

Point

表アクセス回数カーディナリティ

TAB1 1回 X行

TAB2 X回 X×1行

TAB3 X回 X×63.5行

TAB4 X×63.5回 2行

TAB5 2回 1 or 2行


SQL解析

SQLパフォーマンス問題解決へのアプローチアーキテクチャを意識したSQLチューニング

PGA

DBバッファキャッシュ共有プール REDOログバッファ

SGA

SQL

実行計画

AP

65

43

21

65

43

21

ディスクからの読込み

バッファからの読込み

発生している待機「cursor: pin S」「latch : cache buffers chains」を考察

ここ！

サーバプロセス

ここ！

cursor: pin S

latch : cache buffers chains

• 何の（どこに関連した）処理か？

「cursor: pin S」共有プール

「latch : cache buffers chains」 DBバッファキャッシュ

⇒メモリ領域に対する処理がボトルネックとなっている


SQLは本当に必要なのか：

Case ①： SQL関数の使用

Case ②：アプリケーションの一時情報の格納

Case ②：

アプリケーションの一時的な情報の格納場所として、データベースを使用している場合

永続的な保護が必要なデータのみデータベースに格納する

go1

STATUSId

ステータス表

DBサーバ

APサーバ

SQL発行 go1

STATUSIdｔ

ステータス情報

DBサーバ

APサーバ

実データ実データ

SQL発行 SQL発行

• SQLの必要性 / SQLの発行回数を減らす/ SQLの発行形態

SQLパフォーマンス問題解決へのアプローチアプリケーションロジックや設計を意識したSQLチューニング


【解決編 Part1～2】

• SQL単体の最適化

• 定型的なSQLチューニング

• 非定型的なSQLチューニング

SQLパフォーマンス問題解決へのアプローチこれまでとこれから





NOYES

NOYES

NOYESNO

YES


NO




SQL単体

システム全体

【Part3～】

• システム全体の最適化• SQL単体を最適化しても発生する（解決しない）パフォーマンス問題がある




本セミナーの目的とゴール

本日

全体

• SQLパフォーマンス問題を減らし、予防する仕組みを身につける• システム全体で発生するSQLパフォーマンス問題を減らす

• 表面的なチューニングではなく裏に潜む真の問題を見つけて解決する

• SQLパフォーマンス問題を予防する仕組みを実現する

• 設計時の不備をSQLの観点から改善できるようになる• SQLのパフォーマンス問題と論理設計の関係をクリアにする

• 問題発生時にどのような点に着目して設計を確認すべきか整理する



設計と各種最適化の関係

• 設計の定義とフォーカスする範囲


• SQL単体の実行計画などは問題がないが性能が出ないケースがある。

① 設計時に考慮が足りないことがある

② システム開発の前フェーズでスルーされてしまうことがある

③ 運用中に問題が発覚して策がないことがある

設計の定義とフォーカスする範囲設計の不備は設計者だけのせい？

SQLの観点から、設計の不備を発見していく

今回は、特に論理設計にフォーカスする

論理設計：

アプリケーションから見たデータベースの構造を定義する


• APから見たデータベースの構造設計

• 表、列、データ型、桁数などの決定

• キー、リレーション、整合性規約などの決定

• 索引候補、パーティション候補の決定

• 表領域、データファイルの設計

• 各ファイルのディスク上への物理配置を決定

• インスタンス設計（初期化パラメータ）

• 容量設計

論理設計物理設計

system01.dbf

表索引

System Data Index Temp UNDO

データブロック

エクステント

各種エンティティ

データベースオブジェクトの物理属性

表領域

temp01.dbfdata01.dbfindex01.dbf undo01.dbf

ファイルやディスクへのマッピング

設計の定義とフォーカスする範囲論理設計と物理設計の違い


トップダウンアプローチユーザー要件やシステムの設計者の経験を基に、システムに必要な情報を洗い出し、エンティティや属性

項目を決める

ボトムアップアプローチ

エンドユーザーが必要としている情報を、既存システムの画面や帳票、ファイルなどを基に抽出するアプ

ローチ

トップダウンボトムアップ

メリットシステムに本来あるべき姿に近いモデリ

ングを行うことができる

ユーザーのニーズや現状に基づいたアプロー

チであるため、わかりやすく漏れがない

デメリットユーザーのニーズを全て収集するのが難しく、経験を要する

システムに本来あるべき姿に理想の形を見つけにくい

有効な使いど

ころ

新規業務に関するデータを洗い出すと

きなど、既存システムから情報収集が行

えない場合に有効

既存システムのリプレースなど、エンドユーザーが必要としている情報が比較的明確になっている場合に有効

設計の定義とフォーカスする範囲データ分析アプローチの種類

両方のアプローチを組み合わせてモデリングを行う事が重要



設計、実装レベルのチューニング

• データ主観の設計 -正規化と統合化 –




データ主観での設計正規化と統合化

• データ主観での設計

• 正規化

リレーショナルデータベースの保持しやすい状態にデータを表形式化

• 統合化

正規化後、同じ識別項目を持つエンティティをまとめる

フェーズ要件定義・分析設計構築

DB設計作業データ収集

非正規

モデル作成

正規化統合化業務最適化

性能最適化

特定のRDBMSや

システム構成への

変換

DB

構築

一般的なDB設計工程

概念設計論理設計

物理設計実装設計実装


概要

RDBMSの論理設計において、業務データを表形式に変換して行く際にデータの一貫性の維持と効率良いデータアクセスを導くための手法

メリット

データの整合性

-重複データが存在しないため、データの一貫性が保ちやすい

更新処理の高速化

- 表当たりの索引数が減るため、更新処理が高速化できる

同時処理の改善

-表が最適に分割されるため、表に対するロック影響を最小化できる

正規化とは


社員番号氏名部署内線番号役職

1 オラクル太郎営業 100 課長

2 オラクル次郎営業 100 主任

3 オラクル花子経理 200 主任

データの重複

レコードが削除されると経理部に関する情報が消失

例) 正規化された表データ

社員番号氏名部署役職

1 オラクル太郎営業課長

2 オラクル次郎営業主任

3 オラクル花子経理主任

部署内線番号

営業 100

経理 200

例) 正規化されていない表データ

重複項目、依存項目を別表へ分割

正規化されていないデータ


非正規形非正規形

第1正規形第1正規形



繰り返し項目の排除 / 分離

キー項目の一部に依存した項目の排除 / 分離

第1正規化

第2正規化

第3正規化データ項目の一部に依存した項目の排除 / 分離

導出項目の排除

正規化の手順


受注番号

商品番号(1) 商品名(1) 値段(1) 発注数(1) 商品番号(2) 商品名(2)

値段(2) 発注数(2)

合計受注日

1 1 りんご 100 1 100 2/3

2 1 りんご 100 3 2 みかん 200 1 500 2/4

3 3 なし 150 2 300 2/4

4 2 みかん 200 1 3 なし 150 2 500 2/5

第1正規化では繰り返し項目の排除 / 分離を行う

繰り返し項目

受注番号合計受注日

1 100 2/3

2 500 2/4

3 300 2/4

4 500 2/5

受注番号商品番号商品名値段発注数

1 1 りんご 100 1

2 1 りんご 100 3

2 2 みかん 200 1

3 3 なし 150 2

4 2 みかん 200 1

4 3 なし 150 2

繰り返し項目を分割

第1正規化


第2正規化ではキー項目の一部に依存した項目の排除 / 分離を行う

受注番号商品番号商品名値段発注数

1 1 りんご 100 1

2 1 りんご 100 3

2 2 みかん 200 1

3 3 なし 150 2

4 2 みかん 200 1

4 3 なし 150 2

[商品番号]が決定すると[商品名]、[値段]も決定するため、商品番号に依存している

受注番号商品番号発注数

1 1 1

2 1 3

2 2 1

3 3 2

4 2 1

4 3 2

商品番号商品名値段

1 りんご 100

2 みかん 200

3 なし 150キー項目に依存している項目を別表として分割

第2正規化


第3正規化ではデータ項目の一部に依存した項目の排除 / 分離、導出項目の排除を行う

受注番号合計受注日

1 100 2/3

2 500 2/4

3 300 2/4

4 500 2/5


1 1 1

2 1 3

2 2 1

3 3 2

4 2 1

4 3 2

商品番号商品名値段

1 りんご 100

2 みかん 200

3 なし 150

[発注数]と[値段]より[合計]が算出可能なため[合計]は導出項目にあたる

受注番号受注日

1 2/3

2 2/4

3 2/4

4 2/5

導出項目を排除(この例ではデータ項目に依存する項目はありません)

第3正規化


統合化のメリット

複数のエンティティを1つのテーブルに統合してI/O特性の向上を図る

運用管理単位ごとに統合することで、運用面の向上を図る

ベース項目

サブセット項目１

サブセット項目２

Nu

ll

上位エンティティ

サブセットエンティティ

サブセット項目１

サブセット項目２

Nu

ll

ベース項目

統合

統合化とは


統合化とは

受注番号

受注年月日

営業担当者コード

顧客コード

販売区分

受注備考

納期年月日

特注/標準区分

生産管理担当者コード

生産備考

受注番号

受注年月日


顧客コード

販売区分

備考

受注番号

納期年月日


顧客コード

特注/標準区分

生産管理担当者コード

備考

営業側で正規化した

受注エンティティ

統合化した


生産側で正規化した


•各業務で正規化した後、同じ識別項目（受注番号）を持つ

エンティティを１つにまとめる。


業務を最適化する設計目的と手段

• 業務最適化の目的

• 業務要件や業務プロセスに基づいて業務機能が実現可能であるかを確認

• 業務最適化の手段

• 業務観点から必要な情報の抜け漏れの確認

• 時間経過を考慮した最適化

• データサイクルを考慮した最適化



非正規

モデル作成


性能最適化

特定のRDBMSや


変換

DB

構築





受注出荷請求売上入金

受注売上請求入金

ビジネス・プロセス：

エンティティ：

出荷のエンティティがないが大丈夫か？

業務を最適化する設計時間経過を考慮した最適化

• ERモデルでは時間経過が表現できない

• 業務プロセスや業務処理、データのライフサイクルの観点から確認

• 流れを意識しながらERモデルの最適化を行う

例）ビジネス・プロセスとエンティティ抽出の確認


業務を最適化する設計データサイクルを考慮した最適化

• ERモデルではデータサイクルや実装機能は表現できない

• データ操作や機能の抜けもれ、データの整合性の観点を確認

• ユーザ・インターフェースをイメージしながらERモデルの最適化を行う

例）プロセスとエンティティ抽出の確認

随時月次

受注物流請求入金

リソース顧客 R R U

商品 R R

営業担当者 R R

イベント受注 CRUD R

受注明細 CRUD R

C：生成（Create）、R：参照（Reference）、U：修正（Update）、D：削除（Delete）

エンティティ


性能を最適化する設計目的と手段

• 性能最適化の目的

• 負荷が高い業務やテーブルに対する構造上の弱点を減らす

• 性能要件（処理トラフィックやスケーラブル）を満たす設計

• 業務プロセス、運用管理性が考慮された設計

• 性能最適化の手段

• 分割化、統合化、冗長化、要約化



非正規

モデル作成


性能最適化

特定のRDBMSや


変換

DB

構築





性能観点から対策を検討する分割化と統合化による性能最適化

• 分割化・統合化とは、表をわけるか、まとめるか

• どのようにデータにアクセスされるかSQLの性能観点で確認

• I/O の効率化、開発/運用の生産性

ベース項目

拡張項目

サブセット項目1

サブセット項目2

Nu

ll

顧客 R

顧客名

顧客番号

個人法人

代表者名

男女

個人／法人区分

性別

顧客テーブル

顧客名

顧客番号

個人テーブル

性別

顧客番号(FK)

法人テーブル

代表者名

顧客番号(FK)

顧客テーブル

顧客名個人／法人区分性別代表者名

顧客番号

個人テーブル

顧客名性別

顧客番号

法人テーブル

顧客名代表者名

顧客番号サブセット分割

ベースサブセット分割

すべて統合


分割と統合による比較業務プロセスの頻度別の比較例

• 業務プロセス特徴別の実装シミュレーション

• 「個人」「法人」で個別アクセスの頻度が高い

• 「個人」「法人」が同時アクセスの頻度が高い


分割と統合による比較Ⅰ.「個人」「法人」で個別アクセスの頻度が高い

テーブル構成実現方法SQL アクセスデータのイメージ（※）特徴

①

分割

SELECT ...

FROM 個人テーブル；

⇒テーブル指定

○アクセス件数が尐ない

○頻度高の業務プロセス（個人と法人は別フロー）マッチ

○他の絞り込み条件での処理でも生産性が高い

②

分割

SELECT ...

FROM 顧客テーブル kk,

個人テーブル kj

WHERE kk.顧客NO=

kj.顧客NO;

⇒等価結合

×複数テーブルを結合するオペレーション分オーバーヘッド有り

× 2つのテーブルに対する更新処理が必要

△先に個人テーブルで絞れる場合は索引スキャン

③

統合

SELECT ...

FROM 顧客テーブル

WHERE 区分=‘個人’;

⇒絞り込み条件指定

×カーディナリティが低く索引スキャンのメリットが低い（個人、法人区分を条件に絞り込む場合）

×頻度高の業務プロセス（個人と法人は別フロー）マッチしない

顧客テーブル

顧客名

顧客番号

個人テーブル

性別

顧客番号(FK)

法人テーブル

代表者名

顧客番号(FK)

顧客テーブル


顧客番号

個人テーブル

顧客名性別

顧客番号

法人テーブル


顧客番号

※概要イメージ。条件や個別処理、索引使用有無などにより変動。動作については、Appendix 参照。


分割と統合による比較Ⅰ.「個人」「法人」で個別アクセスの頻度が高い

• パターン①がより効率的

• 結合オペレーションが必要ない

• アクセス件数、ブロック数共に尐なくて済む

• 頻度が高い業務プロセスとマッチしており、生産性も高い


分割と統合による比較Ⅱ.「個人」「法人」が同時アクセスの頻度が高い

テーブル構成実現方法（SQL）アクセスデータのイメージ（※）特徴

①

分割

SELECT xxx , yyy

FROM 個人テーブル

UNION ALL

SELECT xxx ,yyy

FROM 法人テーブル；

⇒UNION ALL 句

× 2つのテーブルの検索結果を読みこむ必要がある

×アクセスするブロックが多い

②

分割

SELECT xxx ,yyy ,aaa

FROM 顧客テーブル kk,

個人テーブル kj

WHERE kk.顧客NO=

kj.顧客NO(+);

⇒外部結合

SELECT xxx ,yyy

FROM 顧客テーブル;

⇒単一テーブル

【詳細項目が必要】

×複数テーブルを結合するオペレーション分オーバーヘッドがある

×更新処理も2つのテーブルに対して必要

【共通項目のみ】

○結合のオーバーヘッドなし

○ 1ブロックあたりの必要データ多


③

統合

SELECT ...

FROM 顧客テーブル;

⇒単一テーブル

○結合のオーバーヘッドがない


△ 1ブロックあたりの必要データ尐

顧客テーブル

顧客名

顧客番号

個人テーブル

性別

顧客番号(FK)

法人テーブル

代表者名

顧客番号(FK)

顧客テーブル


顧客番号

個人テーブル

顧客名性別

顧客番号

法人テーブル


顧客番号

※概要イメージ。条件や個別処理、索引使用有無などにより変動。


分割と統合による比較Ⅱ.「個人」「法人」が同時アクセスの頻度が高い

• パターン②、パターン③がより効率的

• 同時アクセスが共通項目のみで済む場合

• パターン②（詳細項目は顧客番号指定でアクセス）

• 共通項目のみであれば列数が尐なく、1ブロック内のレコード数が多い

• 取得行数が同じでも、データの取得効率が高い

• 同時アクセスが個別項目も必要になる場合

• パターン③

• どの項目を抽出する場合でも単一表アクセスで結合オーバヘッドなし

• 更新処理も単一表で済み、生産性も高い


性能観点から対策を検討する冗長化による性能最適化

• 冗長化は非正規化の作業

• 冗長化のメリットは非正規化のデメリットであり、逆もしかり

• あるべき第3正規化を行ってから、冗長化を考える


冗長化のメリット（=正規化のデメリット）

正規化を徹底したデータはデータが分散しているが、冗長化により繰り返し項目を持たせることで、関連データを一行に収め、I/O特性の向上を図ることを目的としている

冗長化(現在より低い正規形に戻す)により結合表数を減らす


1 1 1

2 1 3

2 2 1

3 3 2

4 2 1


1 2/3

2 2/4

3 2/4

4 2/5

+

受注番号商品番号発注数受注日

1 1 1 2/3

2 1 3 2/4

2 2 1 2/4

3 3 2 2/4

4 2 1 2/5

SELECT 受注番号,発注数,発注日FROM…SELECT 受注番号,発注数,発注日FROM…

第3正規形：結合回数1回第2正規形：結合なし

冗長化（非正規化）


冗長化のデメリット（=正規化のメリット）

• 1行のサイズが大きくなるため、行移行、行連鎖が発生しやすい

• 汎用性が低くなり再利用しにくくなるので、仕様変更やシステムを新しくする際のコストがかかる


1 1 1

2 1 3

2 2 1

3 3 2

4 2 1


1 2/3

2 2/4

3 2/4

4 2/5

+

受注番号商品番号発注数受注日

1 1 1 2/3

2 1 3 2/4

2 2 1 2/4

3 3 2 2/4

4 2 1 2/5

第3正規形：結合回数1回第2正規形：結合なし

冗長化（非正規化）

特別な条件（※）以外は、原則として冗長化は禁止

※繰り返しの数が非常に尐ない場合、複数表に対する結合階層や結合パターンが非常に多くなる場合など。


• 業務で必要となる要約したデータを持たせることで、I/O特性や業務ロジック性能向上を図ることを目的としている

1. 親表への要約項目追加

3. 導出項目の追加

2. 要約表の追加

4. 同一項目の二重管理

親表子表

要約項目

表A

項目1

表B

項目1

明細表サマリ表

伝票番号年月地域商品売上額

年月地域商品合計売上額

明細表

合計売上額

伝票番号商品単価数量

性能観点から対策を検討する要約化による性能最適化



1 1 1

2 1 3

2 2 1

3 3 2

4 2 1


1 2/3

2 2/4

3 2/4

4 2/5 SELECT文による集計結果を格納

受注表受注項目表

受注番号受注日総発注数

1 2/3 1

2 2/4 4

3 2/4 2

4 2/5 1

•受注番号ごとの発注数を要約した要約表の追加

要約表

要約化



データベースの機能を使用した対処案

• クラスタ表による冗長化

• マテリアライズドビューによる要約化


• 複数の表を１つの領域(セグメント)に格納し、同じデータブロックを共有する表のグループみたいなもの

クラスタ表のメリット

•論理的な関係を変更することなく物理的に同じ場所（同じブロック）に格納できる

クラスタキー（親表のプライマリキー）

親表のデータ

データブロック

※クラスタ表による冗長化の対応

別々にアクセスされることの多い表にはクラスタ表を使用しない！

クラスタ表による冗長化クラスタ表とは

クラスタキーに属する

子表のデータ


クラスタ表による冗長化クラスタ表の構造


1 1 1

2 1 3

2 2 1

3 3 2

4 2 1


1 2/3

2 2/4

3 2/4

4 2/5

+

非クラスタ化表

クラスタ化表(クラスタ化キー受注番号)


1 2/3


2 2/4


3 2/4


4 2/5関連データをまとめて格納できるため

効率がよい

関連データを別々に格納するため必要領域も増大

商品番号発注数

1 1


1 3

2 1


3 2


2 1



1 1 1

2 1 3

2 2 1

3 3 2

4 2 1


1 2/3

2 2/4

3 2/4

4 2/5 SELECT文による集計結果を格納

SELECT a.受注番号,

b.受注日,

SUM(a.発注数) 総発注数

FROM 受注項目表 a,受注表 b

WHERE a.受注番号=b.受注番号

GROUP BY a.受注番号;

受注表受注項目表

受注番号受注日総発注数

1 2/3 1

2 2/4 4

3 2/4 2

4 2/5 1

•受注番号ごとの発注数を要約した要約表の追加

要約表

マテリアライズドビューによる要約化要約表の追加例


• リモート・データベース上に存在するデータをローカル・データベース上に定期的にコピーするもの（スナップショット）

• データの集計や結合処理の結果を実体として持たせるもの

• 結合処理など、複雑な検索処理のパフォーマンス向上のために用いられる

リモートコピー結合集計（要約）

sum count

sum count

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

マテリアライズドビューによる要約化マテリアライズドビューの構造



まとめ


【解決編 Part1～2】

• SQL単体の最適化

• 定型的なSQLチューニング

• 非定型的なSQLチューニング

SQLパフォーマンス問題解決へのアプローチ本日の範囲





NOYES

NOYES

NOYESNO

YES


NO




SQL単体

システム全体

【Part3～】

• システム全体の最適化• SQL単体を最適化しても発生する（解決しない）パフォーマンス問題がある




• SQL単体では問題ないが性能がでないケース・・・

① 設計時に考慮が足りないことがある

② システム開発の前フェーズでスルーされてしまうことがある

③ 運用中に問題が発覚して策がないことがある

データ主観の設計（正規化と統合化） / 業務を最適化する設計 / 性能を最適化する設計について考慮された設計が行われている必要がある。

設計の知識と性能への関連性について（①）開発者が知識を持つことで、設計の不備をSQL観点から逆引きで指摘し改善することができる。

運用時に問題が発生した場合、どのような点に着目して設計を確認すべきかが整理できている。1つの案として、データベースの機能を使用した解決案も提示できること。

設計時の不備をSQLの観点から改善できるようになる

SQLパフォーマンス問題解決へのアプローチまとめ



Appendix


顧客番号顧客名

001

002

003

004

…

Aさん

Bさん

Cさん

Dさん

…

性別

男

女

男

男

…

個人テーブル

個人テーブルを全表走査してデータを取得する

統合と分割別アクセスの動作例

顧客テーブル

顧客番号顧客名001

002

003

004

005

Aさん

B社

Cさん

Dさん

E社

区分

個人

法人

個人

個人

法人

性別

男

女

男

代表者名

Bさん

Eさん… … … … …

顧客テーブルを全表走査して区分によって個人を選択

パターン①最初から検索対象が絞り込まれているため走査件数が尐なくなる

パターン②結合する分 1行のデータを読むコストは高くなる

顧客番号001003004

…

性別男女男…

個人テーブルを全表走査、取得した顧客番号で顧客テーブルをインデックス・スキャンして結合

顧客番号顧客名001002003004005

AさんB社CさんDさんE社

… …

顧客テーブル

個人テーブル

パターン③個人／法人区分を検索条件として指定する必要がある


• 実データは持たず、他のカラムから関数によって定義される仮想的な列

例) acc_no(アカウント番号)の上2桁をacc_branch(支店番号)として用いる場合

バーチャルカラムのメリット

•ある列に対するファンクションや計算式を記述する必要がない

acc_no acc_name acc_branch

12500 Nakashima 12

12507 Aritaki 12

12666 Seo 12

13666 Aritaki 13

13668 Inoue 13

バーチャルカラムによる要約化

Copyright© 2010, Oracle. All rights reserved. 56

OTN×ダイセミでスキルアップ!!

※OTN掲示版は、基本的にOracleユーザー有志からの回答となるため100%回答があるとは限りません。ただ、過去の履歴を見ると、質問の大多数に関してなんらかの回答が書き込まれております。

Oracle Technology Network(OTN)を御活用下さい。

・一般的な技術問題解決方法などを知りたい！・セミナ資料など技術コンテンツがほしい！

一般的技術問題解決にはOTN掲示版の

「データベース一般」をご活用ください

http://otn.oracle.co.jp/forum/index.jspa?categoryID=2

過去のセミナ資料、動画コンテンツはOTNの

「OTNセミナーオンデマンドコンテンツ」へ

http://www.oracle.com/technology/global/jp/ondemand/otn-seminar/index.html

※ダイセミ事務局にダイセミ資料を請求頂いても、お受けできない可能性がございますので予めご了承ください。ダイセミ資料はOTNコンテンツオンデマンドか、セミナ実施時間内にダウンロード頂くようお願い致します。

http://otn.oracle.co.jp/forum/index.jspa?categoryID=2


Windows環境でもシェアNo.1！Databaseの合言葉はオラ98(キュッパ)」

日頃ご利用・ご提案頂いている皆様の声を投票にてお聞かせください。抽選でプレミアム・グッズをプレゼント。47都道府県を超えたら、投票総数が2,000件を超えたら、賞品がグレードアップ！！締め切りは11月30日（火）まで。皆様のご応募をお待ちしております！！

日本全国オラ98


OTNセミナーオンデマンドコンテンツダイセミで実施された技術コンテンツを動画で配信中!!

ダイセミのライブ感はそのままに、お好きな時間で受講頂けます。

※掲載のコンテンツ内容は予告なく変更になる可能性があります。期間限定での配信コンテンツも含まれております。お早めにダウンロード頂くことをお勧めいたします。

OTN オンデマンド

最新情報つぶやき中

oracletechnetjp

・人気コンテンツは？

・お勧め情報

・公開予告など


Oracle エンジニアのための技術情報サイト

オラクルエンジニア通信http://blogs.oracle.com/oracle4engineer/

• 技術資料

• ダイセミの過去資料や製品ホワイトペーパー、スキルアップ資料などを多様な方法で検索できます

• キーワード検索、レベル別、カテゴリ別、製品・機能別

• コラム

• オラクル製品に関する技術コラムを毎週お届けします

• 決してニッチではなく、誰もが明日から使える技術の「あ、そうだったんだ！」をお届けします

先月はこんな資料が人気でした

Oracle 10gR2がWindows 2008R2/Windows7に対応

【チュートリアル】意外と簡単!? Oracle Database 11g

Release2 - Windows版「データベース構築編」

Oracle Database 11gR2 RAC インストレーション・ガイドASM 版 Microsoft Windows x86-64

オラクルエンジニア通信

最新情報つぶやき中

oracletechnetjp

http://blogs.oracle.com/oracle4engineer/


■パフォーマンス診断サービス

•Webシステムボトルネック診断サービス

•データベースパフォーマンス診断サービス

オラクル社のエンジニアが直接ご支援しますお気軽にご活用ください!

オラクル無償支援検索

NEW

■システム構成診断サービス

•Oracle Database構成相談サービス

•サーバー統合支援サービス

•仮想化アセスメントサービス

•メインフレーム資産活用相談サービス

•BI EEアセスメントサービス

•簡易業務診断サービス

■バージョンアップ支援サービス

•Oracle Databaseバージョンアップ支援サービス

•Weblogic Serverバージョンアップ支援サービス

•Oracle Developer/2000(Froms/Reports)

Webアップグレード相談サービス

■移行支援サービス

•SQL Serverからの移行支援サービス

•DB2からの移行支援サービス

•Sybaseからの移行支援サービス

•MySQLからの移行支援サービス

•Postgre SQLからの移行支援サービス

•Accessからの移行支援サービス

•Oracle Application ServerからWeblogicへ移行支援サービス

ITプロジェクト全般に渡る無償支援サービス

Oracle Direct Conciergeサービス

NEW

NEW

Copyright© 2010, Oracle. All rights reserved.

11月30日まで!! 締め切り迫る

61

Enterprise Editionはここが違う!!

• 圧倒的なパフォーマンス!

•データベース管理がカンタン!

•データベースを止めなくていい!

• もちろん障害対策も万全!

Oracle Databaseのライセンス価格を大幅に抑えて

ご導入いただけます

詳しくはコチラ

http://www.oracle.co.jp/campaign/kurukuru/index.html

あのOracle Database Enterprise Editionが超おトク!!

お問い合わせフォームhttp://www.oracle.co.jp/inq_pl/INQUIRY/quest?rid=28

多くのお客様でサーバー使用期間とされる

5年間にライセンス期間を限定

•期間途中で永久ライセンスへ差額移行

• 5年後に新規ライセンスを購入し継続利用

• 5年後に新システムへデータを移行


http://www.oracle.co.jp/inq_pl/INQUIRY/quest?rid=28

Oracle Direct 検索

あなたにいちばん近いオラクル

Oracle Directまずはお問合せください

Web問い合わせフォームフリーダイヤル

専用お問い合わせフォームにてご相談内容を承ります。

※フォームの入力には、Oracle Direct Seminar申込時と同じログインが必要となります。

※こちらから詳細確認のお電話を差し上げる場合がありますので、ご登録されている連絡先が最新のものになっているか、ご確認下さい。

0120－155－096

※月曜~金曜 9:00~12:00、13:00~18:00

（祝日および年末年始除く）

システムの検討・構築から運用まで、ITプロジェクト全般の相談窓口としてご支援いたします。

システム構成やライセンス/購入方法などお気軽にお問い合わせ下さい。

http://www.oracle.co.jp/inq_pl/INQUIRY/quest?rid=28


以上の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。

Oracle、PeopleSoft、JD Edwards、及びSiebelは、米国オラクル・コーポレーション及びその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標の可能性があります。

Oracle Direct Seminar · • SQLチューニングのアプローチ •...

Documents

Transcript of Oracle Direct Seminar · • SQLチューニングのアプローチ •...