【13-D-3】　プロとしてのOracleアーキテクチャ入門～番外編～

プロとしてのOracleアーキテク
チャ入門～番外編～

13-D-3 渡部亮太
株式会社コーソル

渡部亮太 – (株)コーソル
“OO厨”転じて“RDB厨”
2008/8に「プロとしてのOracle
アーキテクチャ入門」を上梓しま
した
所有資格: Oracle Master
10g Platinum他
株式会社コーソル所属
エンジニアのOracle Master 所有
率（96%)
社員79名(2009/1/20時点)

本日の目標
以下について理解していただくことを目標と
しています

１）SQL実行/チューニングに関連する
Oracleアーキテクチャの概要
２）CBOと関連する構成要素
３）SQL開発において注意すべき点

DB運用ではなく、SQL開発を想定した説明
となっています。

SQL実行とOracleアーキテクチャ
SGA
サーバプロセス
共有プール
SELECT
検証・解析
クライアント・
解析済み
アプリケーション
行 SQL情報
実行・フェッチ
データベース・
バッファキャッシュ

PGA
メモリ
ディスク

一時ファイルデータファイル
（一時表領域）（永続表領域）

SQL発行とSQL解析
SGA
①
共有プール
SELECT ②検証・解析
クライアント・ ③
（ハードパース）解析済み
アプリケーションキャッシュ
SQL情報

「検証・解析」で実施する処理
SQL構文チェック
アクセス対象オブジェクトのチェック
SQLの最適化
実行計画の立案
解析結果は共有プールにキャッシュ

SQLの実行と実行計画
解析済みSQL情報

実行計画

結合方式＋結合の順序
アクセスパス
ネステッドループ
テーブルスキャン

ソートマージ
+ A A
+
索引スキャン Z Z
ハッシュ
f(x) f(x)

実行計画の立案とCBO
（Cost Based Optimizer）
実行計画
SQL
SELECT * FROM EMP
CBO
WHERE EMP_NO = :emp_no;

初期化パラメータ
・・・

オプティマイザ統計システム統計
収集
環境的な要因!!
テーブル・索引

テーブルと索引へのアクセス
・・・

・・・

選択率と最適なアクセス
? ?
?

: :
:
?

ヒストグラムオプティマイザ統計・・・

値ベースのヒストグラム

高さ＝頻度

収集
:
or
高さベースのヒストグラム
幅＝頻度

CBOの欠点と対応策

影響
・・・

オプティマイザ統計実行計画
利点：データ状態（の変化）欠点：実行計画が変化して、
に応じた実行計画を突然パフォーマンスが
立案できる変動する可能性がある

安定性を優先する場合
ヒント句の使用
例: SELECT /*+ USE_NL(emp, dept) */ …
アウトラインの使用
例: ALTER SESSION SET use_stored_outline =
<outline_name>;

解析済みSQL情報のキャッシュ
SGA
①
共有プール
SELECT ②検証・解析
クライアント・ ③
（ハードパース）
アプリケーション解析済み
キャッシュ
SQL情報

サーバプロセス ⑥再利用
④
⑤検証・解析
SELECT
クライアント・（ソフトパース）

一度実行されたSQLの解析結果は再利用される
⇒ SQL実行に伴う負荷を軽減

実行/フェッチ
SGA
クライアント・バッファキャッシュ
②メモリ
アクセス
③行

consistent gets ①ファイルI/O

メモリ
ディスク
physical reads データファイル
（永続表領域）

DBバッファキャッシュのキャッシュ効果
SGA
クライアント・バッファキャッシュ
②メモリ
アクセス
③行
ディスクアクセス
→低速

クライアント・ ①ファイルI/O
④メモリ
アプリケーションアクセス
⑤行
メモリ
メモリアクセス
→高速ディスク

データファイル
（永続表領域）

パフォーマンス測定とキャッシュ
シビアなパフォーマンス測定の場合は、
キャッシュを意識する必要があります
明示的なDBバッファキャッシュのflushが有効で
す（10g～）
ALTER SYSTEM FLUSH BUFFER_CACHE;
通常、OS/ファイルシステムのバッファキャッ
シュの影響はありません
大部分のプラットフォームで、OracleはOS/ファイル
システムのバッファキャッシュをバイパスします
より厳密なレベルでは、ストレージのキャッシュ
の影響を受けます

ソート（必要な場合）
SGA
①
クライアント・実行・フェッチバッファキャッシュ
③行 ②ソート

PGA
メモリでソート
A
⇒ 高速
Z
メモリ
②ソート

ディスク
一時ファイル（一時表領域）
ディスクでソート
A
⇒ 低速

Z

統計：キャッシュとソート
consistent gets : バッファ読み込み（ブロッ
ク数）
physical reads : ファイル読み込み（ブロッ
ク数）
sorts (memory) : メモリソート（回数）
sorts (disk) : ディスクソート（回数）

V$SESSTAT / V$SYSSTATビュー
SQL*Plus autotrace statistics

SQL開発において留意すべき点
１）実行計画（+SQL）の妥当性チェック
しかし・・・、複雑なSQLの妥当性チェックは困難
そもそも、CBOが自動的に最適な実行計画を立案する
「はず」なのだから、開発者がいちいち実行計画をチェッ
クするのはナンセンス
ただし、最低限、以下はチェックしておきたい
索引が使用できないSQLを書いていないか
処理データ量が大量なSQLの場合に、想定する実行計画
２）意味のあるパフォーマンスの測定（or 把握）
本番環境にできるだけ近い環境
データ量、オプティマイザ統計については特に配慮を
→ CBOによる実行計画の立案にも大きく影響
キャッシュを意識した性能測定が必要な場合も

索引を使用できないSQL
典型的な例
NULL値の検索
暗黙の型変換を伴うSQL
索引列へのファンクションの適用
等
参考：「パフォーマンスチューニングガイド」→「SQL
チューニングの概要」→「効率的なSQL文の開発」
SQL Tuning Advisor(10g～)の利用も検討
要： Enterprise Edition + Diagnostic Pack
+Tuning Pack

実行計画確認時の注意
本番環境類似の環境整備
1.
オプティマイザ統計のメンテナンス
2.
バインド変数を用いたSQLの実行計画の
3.
確認方法
4. バインドピークが実行計画に与える影響
5. クエリ変換

１）本番環境類似の環境整備
実行計画立案にかかわる環境条件を、「で
きるだけ」開発環境と本番環境で同じくする
オブジェクト定義：テーブル、索引
易
オプティマイザ統計
（システム統計）
一般的には
データここらへん
Oracleデータベース物理設計が限界？
各種ハードウェア（CPU、ディスク）
難

２）オプティマイザ統計のメンテナンス
原則的に、全てのオブジェクトの最新のオプ
ティマイザ統計を取得すべきです
開発中にオブジェクト、データの追加があった場
合は適宜オプティマイザ統計を更新してください
ただし、環境について明確なポリシーがある
場合はそれに準じます
何らかの理由で、オプティマイザ統計取得対象
のオブジェクトが決まっている
オプティマイザ統計は環境ごとに独自に取得せ
ず、本番環境からコピーして使用する
等

DBMS_STATSの利用
：オプティマイザ統計
・・・

開発DB
RESTORE_
本番DB
*_STATS
（10g～) ・・・
・・・

・・・
・・・
過去
現在
IMPORT_ EXPORT_
*.dmp
TABLE_STATS TABLE_STATS

オプティマイザ統計の収集には、原則としてDBMS_STATS
パッケージを使用する
ANALYZEコマンドは使用すべきでない

truncate tableとオプティマイザ統計
truncate tableしてもオプティマイザ統計は
更新されません

よって、以下のような事態が発生しえます
実際の行数 = 0
オプティマイザ統計の行数 = 1000

CBOはオプティマイザ統計を見るので、誤っ
た実行計画を立案する可能性があります

３）バインド変数を用いたSQLの実行計画
SQLトレース、V$SQL_PLANから実行計画
を確認するのが安全です

explain plan文、SQL*Plusのautotraceコマ
ンドは避ける
バインド変数を使ったSQLでは実際に実行され
た実行計画を確認できない場合があります

４）バインドピーク（9i～）

SELECT * FROM tbl_xxx
WHERE col1 = :var1;

?

:
:

バインド変数にセットされ
た値を元に、最適な実行
計画を立案する機能

バインドピークの落とし穴
１回目の実行
WHERE col1 = :var1;
:
?

2回目の実行 :
:
WHERE col1 = :var1;
:

?

バインドピークの落とし穴を避ける
１）バインドピークをOFFにする
隠しパラメータ（KROWN:81865）の設定が必要
本番環境との整合性を確認要
２）バインド変数を使用しない
そもそもバインド変数値により最適な実行計画が大幅
に異なるSQLでは、バインド変数を使用すべきでない

※：11gでは、バインドピークの機能が改善
1回目と2回目で実行統計が大きく異なる場合は、3回目
では別の実行計画を立案

５）クエリ変換 CREATE VIEW VW_EMP AS
SELECT * FROM EMP
サーバプロセス WHERE sal > 1000;

検証・解析 SELECT * FROM VW_EMP
WHERE job = ‘CLERK’;

実行・フェッチビューマージ
SELECT * FROM EMP
WHERE sal > 1000
AND job = ‘CLERK’;

OR展開 / INリストの
ビューマージ
繰り返し
条件節(WHERE句）の
プッシュ等・・・
副問合せのネスト解除

クエリ変換と実行計画
CBO
クライアント・
変換された
SQL
SQL

実行計画

注）一部のクエリ変換は /* NO_QUERY_TRANSFORMATION */
ヒントで無効化可能

新種のクエリ変換の導入の流れ
Beta-like State: First official Final State:
publication:
・クエリ変換の適用有無
・クエリ変換実装済みがコスト計算を基に判断
・クエリ変換がデフォルト
・隠しパラメータまたは・Undocumentedな
で常に適用
ヒントはdeprecatedに
Undocumentedなヒント・コスト計算なし
で制御可能

※:書籍「Cost-Based Oracle Fundamentals」より

実績的に新種のクエリ変換はひっそりと導入される傾向
にある
このため、アプリ開発者の方（Oracle非専業）が、クエリ
変換を把握して開発することは現実的に困難かも・・・

まとめに代えて – CBOへの対応
１）一般的なアプローチ
CBOとうまく付き合う
次スライドで案内する3つのアプローチをバラ
ンスよく

２）凝り性なアプローチ
CBOの動作を徹底的に理解したい！
参考書籍のご案内

CBOとの付き合い方
・CBOの存在意義否定
① CBOを信頼せず、
・環境の変化に追随できない
ヒント句/アウトラインで
・実行頻度/パフォーマンス影
実行計画を制御
響大SQLに限定の適用は可
・吟味対象のSQLの限定が
② CBOの動作をできる
必要
限り理解し、実行計画を
・典型的な落とし穴について
逐一吟味する
は、本セッションで紹介

③ CBOの特性を（ある・現実的な解
程度）理解し、CBOの・動作環境の構成要素につ
いては、本セッションで説明
動作環境を整備する

3つのアプローチをバランスよく

参考書籍：CBOの理解のために
門外不出のOracle現場ワザ
データベースパフォーマンス
アップの教科書基本原理編
本気で学ぶSQLチューニング～
DB Magazine連載
以上すべて翔泳社様

Cost-Based Oracle
Fundamentals
APress(US)

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

【13-D-3】　プロとしてのOracleアーキテクチャ入門～番外編～

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Mehr von devsumi2009

Mehr von devsumi2009 (20)