【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; ? : : バインド変数にセットされた値を元に、最適な実行計画を立案する機能

バインドピークの落とし穴１回目の実行 SELECT * FROM tbl_xxx WHERE col1 = :var1; : ? 2回目の実行 : : SELECT * FROM tbl_xxx 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アーキテクチャ入門～番外編～

by devsumi2009 on Mar 02, 2009

Accessibility

Tags

Upload Details

Usage Rights

1 Embed 22

Statistics