アジェンダ はじめに これまでの振り返り (Part1~Part4) 本日の範囲とゴール 設計と各種最適化の関係 設計の定義とフォーカスする範囲 設計 実装レベルのチューニング データ主観の設計 - 正規化と統合化 - 業務を最適化する設計 性能を最適化する設計 データベースの機能を使用した対処案

<Insert Picture Here>

Oracle

Direct Seminar

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

解決編Part5

アジェンダ

•

はじめに

•

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

•

本日の範囲とゴール

•

設計と各種最適化の関係

•

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

•

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

•

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

-•

業務を最適化する設計

•

性能を最適化する設計

•

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

•

まとめ

•

Appendix 付録

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

・MySQLからの移行相談

・PostgreSQLからの移行相談

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

・Oracle Database バージョンアップ支援

・Oracle Developer/2000 Webアップグレード相談

・パフォーマンス・クリニック

・Oracle Database 構成相談

・Oracle Database 高可用性診断

・システム連携アセスメント

・システムセキュリティ診断

・簡易業務診断

<Insert Picture Here>

はじめに

•

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

•

本日の範囲とゴール

•

解決編、とうとうPart5

•

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

•

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

•

定型的なチューニング

•

非定型的なチューニング

•

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

•

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

and more..

オプティマイザへの インプット情報は妥当か？ 自身で実行計画を検討 オプティマイザが生成した 実行計画は適切か？ インプット情報を修正できるか？ NO YES NO YES NO YES NO YES チューニング完了 NO パフォーマンスは妥当か？ SQL単体以外のチューニング アプリケーション チューニング 設計 チューニング 多重処理 チューニング

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

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

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

SQLチューニング

定型的な

SQLチューニング

非定型的な

SQLチューニング

2

1

3



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

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



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



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



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

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

•

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

•

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

•

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

•

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

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

•

正しい結果が返ることには気にしても、処理の効率化や

データベース内での処理を意識した開発に気が回らない

現場の声・現状

原因・理由

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）

ハッシュ結合

ソートマージ結合

直積結合

判断のポイント

分岐の種類

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

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

TAB2

ID

CLASS

TAB1

ID

START_DATE <= :b3+1

END_DATE > :b3

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

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

アクセス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

6 5 4 3 2 1 6 5 4 3 2 1

ディスクからの読込み

バッファからの読込み

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

ここ！

サーバ

プロセス

ここ！

cursor: pin S

latch : cache buffers chains

•

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



「cursor: pin S」 共有プール

SQLは本当に必要なのか ：

Case ①：

SQL関数の使用

Case ②：

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

Case ②：

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

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

go 1 STATUS Id ステータス表 DBサーバ APサーバ SQL発行 1 go STATUS Idｔ ステータス情報 DBサーバ APサーバ 実データ 実データ SQL発行 SQL発行

•

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

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

アプリケーションロジックや設計を意識したSQLチューニング

【解決編 Part1～2】

•

SQL単体の最適化

•

定型的なSQLチューニング

•

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

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

これまでとこれから

オプティマイザへの インプット情報は妥当か？ 自身で実行計画を検討 オプティマイザが生成した 実行計画は適切か？ インプット情報を修正できるか？ NO YES NO YES NO YES NO YES NO パフォーマンスは妥当か？ SQL単体以外のチューニング アプリケーション チューニング SQL単体 システム全体

【Part3～】

•

システム全体の最適化

•

SQL単体を最適化しても発生する（解

決しない）パフォーマンス問題がある

設計 チューニング 多重処理 チューニング

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

本日

全体

•

SQLパフォーマンス問題を減らし、予防する仕組み

を身につける

•

システム全体で発生するSQLパフォーマンス問題を減らす

•

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

•

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

•

設計時の不備をSQLの観点から改善

できるようになる

•

SQLのパフォーマンス問題と論理設計の関係をクリアにする

•

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

<Insert Picture Here>

設計と各種最適化の関係

•

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

•

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

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

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

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

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

設計の不備は設計者だけのせい？

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

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

論理設計：

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

•

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

•

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

•

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

•

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

•

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

•

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

•

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

•

容量設計

論理設計

物理設計

system01.dbf 表 索引

System Data Index Temp UNDO データブロック エクステント 各種エンティティ データベース オブジェクトの 物理属性 表領域 temp01.dbf data01.dbf index01.dbf undo01.dbf ファイルや ディスクへの マッピング

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

論理設計と物理設計の違い

トップダウンアプローチ

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

項目を決める

ボトムアップアプローチ

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

ローチ

トップダウン

ボトムアップ

メリット

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

ングを行うことができる

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

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

デメリット

ユーザーのニーズを全て収集するのが

難しく、経験を要する

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

けにくい

有効な使いど

ころ

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

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

えない場合に有効

既存システムのリプレースなど、エンドユーザ

ーが必要としている情報が比較的明確になっ

ている場合に有効

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

データ分析アプローチの種類

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

<Insert Picture Here>

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

•

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

–

•

業務を最適化する設計

データ主観での設計

正規化と統合化

•

データ主観での設計

•

正規化

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

•

統合化

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

フェーズ 要件定義・分析 設計 構築 DB設計作業 データ_収集 非正規 モデル 作成 正規化 統合化 業務 最適化 性能 最適化 特定のRDBMSや システム構成への 変換 DB 構築 一般的な DB設計工程 概念設計 論理設計 物理設計 実装設計 実装



概要

RDBMSの論理設計において、業務データを表形式に変換して行く際に

データの一貫性の維持と効率良いデータアクセス

を導くための手法



メリット



データの整合性

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



更新処理の高速化

-

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



同時処理の改善

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

正規化とは

社員番号

氏名

部署

内線番号

役職

1

オラクル太郎

営業

100

課長

2

オラクル次郎

営業

100

主任

3

オラクル花子

経理

200

主任

データの重複

レコードが削除されると

経理部に関する情報が

消失

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

社員番号

氏名

部署

役職

1

オラクル太郎

営業

課長

2

オラクル次郎

営業

主任

3

オラクル花子

経理

主任

部署

内線番号

営業

100

経理

200

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

重複項目、依存項目を

別表へ分割

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

非正規形

非正規形

第1正規形

第1正規形

第2正規形

第2正規形

第3正規形

第3正規形



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



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

第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

ベース項目

統合

統合化とは

統合化とは

受注番号

受注年月日

営業担当者コード

顧客コード

販売区分

受注備考

納期年月日

特注/標準区分

生産管理担当者コード

生産備考

受注番号

受注年月日

営業担当者コード

顧客コード

販売区分

備考

受注番号

納期年月日

営業担当者コード

顧客コード

特注/標準区分

生産管理担当者コード

備考

営業側で正規化した

受注エンティティ

統合化した

受注エンティティ

生産側で正規化した

受注エンティティ

•

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

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

<Insert Picture Here>

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

•

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

–

•

業務を最適化する設計

•

性能を最適化する設計

業務を最適化する設計

目的と手段

•

業務最適化の目的

•

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

•

業務最適化の手段

•

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

•

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

•

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

フェーズ

要件定義・分析

設計

構築

DB設計作業

データ

_収集

非正規

モデル

作成

正規化

統合化

業務

最適化

性能

最適化

特定のRDBMSや

システム構成への

変換

DB

構築

一般的な

DB設計工程

概念設計

論理設計

物理設計

実装設計

実装

受注

出荷

売上

請求

入金

受注

売上

請求

入金

ビジネス・プロセス：

エンティティ：

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

業務を最適化する設計

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

•

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

•

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

•

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

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

業務を最適化する設計

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

•

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

•

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

•

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

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

随時

月次

受注

物流

請求入金

リソース

顧客

R

R

U

商品

R

R

営業担当者

R

R

イベント

受注

CRUD

R

受注明細

CRUD

R

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

エンティティ

<Insert Picture Here>

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

•

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

–

•

業務を最適化する設計

性能を最適化する設計

目的と手段

•

性能最適化の目的

•

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

•

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

•

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

•

性能最適化の手段

•

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

フェーズ

要件定義・分析

設計

構築

DB設計作業

データ

_収集

非正規

モデル

作成

正規化

統合化

業務

最適化

性能

最適化

特定のRDBMSや

システム構成への

変換

DB

構築

一般的な

DB設計工程

概念設計

論理設計

物理設計

実装設計

実装

性能観点から対策を検討する

分割化と統合化による性能最適化

•

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

•

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

•

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

ベース項目

拡張項目

サ

ブ

セ

ッ

ト

項

目

1

サ

ブ

セ

ッ

ト

項

目

2

Null

顧客 R

顧客名

顧客番号

個人

法人

代表者名

男

女

個人／法人区分

性別

顧客テーブル 顧客名 顧客番号 個人テーブル 性別 顧客番号(FK) 法人テーブル 代表者名 顧客番号(FK) 顧客テーブル 顧客名 個人／法人区分 性別 顧客番号 個人テーブル 顧客名 性別 顧客番号 法人テーブル 顧客名 代表者名 顧客番号 サブセッ_ト分割 ベース サブセッ ト分割 すべて 統合

分割と統合による比較

業務プロセスの頻度別の比較例

•

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

•

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

•

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

分割と統合による比較

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

テーブル構成

実現方法SQL

アクセスデータのイメージ（※）

特徴

①

分

割

SELECT ...

FROM 個人テーブル；

⇒テーブル指定

○

アクセス件数が尐ない

○

頻度高の業務プロセス（個人と

法人は別フロー）マッチ

○

他の絞り込み条件での処理でも

生産性が高い

②

分

割

SELECT ...

FROM 顧客テーブル kk,

個人テーブル kj

WHERE kk.顧客NO=

kj.顧客NO;

⇒等価結合

×

複数テーブルを結合するオペレ

ーション分オーバーヘッド有り

×

2つのテーブルに対する更新処

理が必要

△

先に個人テーブルで絞れる場合

は索引スキャン

③

統

合

SELECT ...

FROM 顧客テーブル

WHERE 区分=‘個人’;

⇒絞り込み条件指定

×

カーディナリティが低く索引スキ

ャンのメリットが低い（個人、法

人区分を条件に絞り込む場合）

×

頻度高の業務プロセス（個人と

法人は別フロー）マッチしない

顧客テーブル

顧客名

顧客番号

個人テーブル

性別

顧客番号(FK)

法人テーブル

代表者名

顧客番号(FK)

顧客テーブル

顧客名

個人／法人区分

性別

顧客番号

個人テーブル

顧客名

性別

顧客番号

法人テーブル

顧客名

代表者名

顧客番号

分割と統合による比較

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

•

パターン①がより効率的

•

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

•

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

•

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

分割と統合による比較

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

テーブル構成

実現方法（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

•

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

要約表

要約化

<Insert Picture Here>

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

•

クラスタ表による冗長化

•

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

表のグループみたいなもの



クラスタ表のメリット

•

論理的な関係を変更することなく

物理的に同じ場所（同じブロック）

に格納できる

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

親表のデータ

データブロック

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

クラスタ表による冗長化

クラスタ表とは

クラスタキーに属する

子表のデータ

クラスタ表による冗長化

クラスタ表の構造

受注番号

商品番号

発注数

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.受注番号

受注表

受注項目表

受注番号

受注日

総発注数

1

2/3

1

2

2/4

4

3

2/4

2

4

2/5

1

•

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

要約表

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

要約表の追加例

•

リモート・データベース上に存在するデータをローカル・データベース上

に定期的にコピーするもの（スナップショット）

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

•

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

れる

リモートコピー

結合

集計（要約）

sum count sum count

マテリアライズドビュー

マテリアライズドビュー

マテリアライズドビュー

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

マテリアライズドビューの構造

<Insert Picture Here>

【解決編 Part1～2】

•

SQL単体の最適化

•

定型的なSQLチューニング

•

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

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

本日の範囲

オプティマイザへの インプット情報は妥当か？ 自身で実行計画を検討 オプティマイザが生成した 実行計画は適切か？ インプット情報を修正できるか？ NO YES NO YES NO YES NO YES チューニング完了 NO パフォーマンスは妥当か？ SQL単体以外のチューニング アプリケーション チューニング SQL単体 システム全体

【Part3～】

•

システム全体の最適化

•

SQL単体を最適化しても発生する（解

決しない）パフォーマンス問題がある

設計 チューニング 多重処理 チューニング

•

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

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

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

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

データ主観の設計（正規化と統合化） / 業務を最適化する設計 / 性能を最適化する設計

について考慮された設計が行われている必要がある。

設計の知識と性能への関連性について（①）開発者が知識を持つことで、設計の不備を

SQL観点から逆引きで指摘し改善することができる。

運用時に問題が発生した場合、どのような点に着目して設計を確認すべきかが整理できて

いる。1つの案として、データベースの機能を使用した解決案も提示できること。

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

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

まとめ

<Insert Picture Here>

顧客番号

顧客名

001

002

003

004

…

Aさん

Bさん

Cさん

Dさん

…

性別

男

女

男

男

…

個人テーブル

個人テーブルを

全表走査してデータを

取得する

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

顧客テーブル

顧客番号

顧客名

001

002

003

004

Aさん

B社

Cさん

Dさん

区分

個人

法人

個人

個人

性別

男

女

男

代表者名

Bさん

顧客テーブル

を全表走査して

区分によって

個人を選択

パターン①

最初から検索対象

が絞り込まれているため走査件

数が尐なくなる

パターン②

結合する分 1行のデ

ータを読むコストは高くなる

顧客番号

001

003

004

…

性別

男

女

男

…

個人テーブルを全表走査、

取得した顧客番号で顧客テーブル

をインデックス・スキャンして結合

顧客番号

顧客名

001

002

003

004

005

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

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

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

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

日頃ご利用・ご提案頂いている皆様の声を投票にてお聞かせください。抽選でプレミアム・

グッズをプレゼント。47都道府県を超えたら、投票総数が2,000件を超えたら、賞品がグレ

ードアップ！！締め切りは

11月30日（火）まで

。皆様のご応募をお待ちしております！！

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

オラクルエンジニア通信

最新情報つぶやき中

■

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

•

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

11月30日まで!!

締め切り迫る

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プロジェクト全般の相談窓口としてご支援いたします。

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

以上の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。

また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことは

できません。以下の事項は、マテリアルやコード、機能を提供することをコミットメン

ト（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さ

い。オラクル製品に関して記載されている機能の開発、リリースおよび時期につい

ては、弊社の裁量により決定されます。

Oracle、PeopleSoft、JD Edwards、及びSiebelは、米国オラクル・コーポレーション及びその子会社、関連会社の登

録商標です。その他の名称はそれぞれの会社の商標の可能性があります。