Oracle Direct Seminar...2010/10/19 · Oracle Direct Seminar オラクルコンサルが語るSQLチューニングの真髄解決編Part3 日本オラクル株式会社

<Insert Picture Here>

Oracle Direct Seminar

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

日本オラクル株式会社

1

Copyright© 2010, Oracle. All rights reserved. 2

• Introduction

• 目的とゴール

• これまでの振り返り - Part1、Part2 -

• SQLチューニングにおけるアプローチ• 全体最適化を意識したアプローチ

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

• 事例から見るボトルネック発見とチューニング• 事例1 ：ディスクI/O編

• 事例2 ：メモリ編

• まとめ

アジェンダ



Introduction

Copyright© 2010, Oracle. All rights reserved.

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

4

目的とゴール

• SQLパフォーマンス問題へのアプローチを理解する• SQL パフォーマンス問題における全体最適化を睨んだアプローチ

• Oracle Database のアーキテクチャーを意識したアプローチ

• SQL パフォーマンス問題の分析・解決手法を理解する• 事例を通じたSQL パフォーマンス問題の分析方法

• 事例を通じたSQL パフォーマンス問題の解決方法



これまでの振り返り

- Part1、Part2 -


チューニング・アプローチ

定型的なチューニング

非定型的なチューニング

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

- これまでの振り返り Part1、Part2 -

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

SQL文の記述方法が柔軟でも、パフォーマンス問題を発生させないようにするためには、記述方法にある程度守るべきルールが存在する。

SQLコーディングルールによるSQL文の確認

定型的な解があるわけではない、頭で考える必要のあるSQLチューニング。

SQLがどのように処理しているのかを意識しながら、実行計画の確認

Part1,2


- これまでの振り返り Part1、Part2 –

定型的なSQLチューニング

問題がおきたら最低限

これだけはチェックする

最低限これだけは守って

コーディングする

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

予防チューニング

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

• 大きく4つのカテゴリに分かれる

1. アーキテクチャに伴う性能問題を避けるためのルール

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

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

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

7




SQLコーディングルール

8


1. アーキテクチャに伴う性能問題を避けるためのルール

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

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

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

バインド変数の利用

ビューを利用しての表結合回避

命名規則に従った管理用コメントの付与

ヒント句の適切な付与


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

自身で実行計画を検討

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

パフォーマンスを確認し妥当であればチューニング完了

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

NOYES

NOYES

NOYESNO

<STEP１>

CBO（コストベース・オプティマイザ）に対するインプット情報の理解

<STEP2>

CBOが決定した実行計画が妥当であるかを判断する指針の理解

チューニングの進め方


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




< STEP1 > オプティマイザへのインプット情報

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

SQLテキスト

パラメータ

オブジェクト構造

データの実態

環境

統計情報

実行計画

レスポンス

• コストベース・オプティマイザ(CBO)はどのような情報をもとに実行計画を決定するか

10



表結合方法

表結合順序

索引を利用して参照

表を直接参照

データアクセス方法

全表スキャン（TABLE ACCESS FULL）

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

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

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

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

ネステッドループ結合

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

ハッシュ結合

ソートマージ結合

直積結合

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

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

11


< STEP2 > 実行計画の妥当性判断


妥当性を判断する3つのポイント


索引を利用して参照

表を直接参照

データアクセス方法

全表スキャン（TABLE ACCESS FULL）

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

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

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

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

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


< STEP2 > 実行計画の妥当性判断データアクセス方法

• データアクセス方法は大きく2つあります

12



表結合方法

ネステッドループ結合

ハッシュ結合

ソートマージ結合

直積結合

• 表結合方法は4つあります。

13



< STEP2 > 実行計画の妥当性判断表結合方法


• 同時に3つ以上の表を結合することはできません。

• 結合順序のパターンは表の数に依存します。

表結合順序 EMP表から？DEPT表から？それとも・・

14


< STEP2 > 実行計画の妥当性判断結合順のパターン


• SQL コーディングルールが適用されているか？• バインド変数が利用されているか？

• ビューを利用しての結合が行われていないか？

• CBOに対して適切な情報がインプットされているか？• オブジェクトが正しく作成されているか？

• パラメータ、統計情報が適切に設定されているか？

• 適切な実行計画が取られているか？• コストの尐ないデータアクセス方法が取られているか？

• コストの尐ない結合方式・結合順序が取られているか？


まとめ

SQLによるデータの取得を最小のブロックアクセスで行うことが原則です。しかしながら、SQL単体を最適化（レスポンス改善）するアプローチだけでは不十分です。

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



SQLチューニングにおけるアプローチ


SQLチューニングにおけるアプローチ全体最適化を意識したアプローチ

インターネット

データベース

ファイアーウォール

SQL

JavaHTML

HTML

Web

サーバーアプリケーションサーバー

Webシステム

ネットワークが狭い？

リクエストが十分受け付けられない？

Javaコードの問題？メモリ、CPUが足りない？

SQLの問題？ DBの設定？

毎回接続？

• レスポンス・スループットが悪化 = SQL チューニング？

• Webシステムが複雑化するにつれ、ボトルネックの発見は困難になりがち

• アプリケーションやネットワークに問題があるのにSQLをチューニングしても効果はない

チューニングアプローチとしては、システム全体の最適化を意識して、性能要件(スループットおよびレスポンス)を満たせることをゴールとすること


チューニング・アプローチ

定型的なチューニング

非定型的なチューニング

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

Part1,2

SQLチューニングにおけるアプローチアーキテクチャを意識したアプローチ

Part3

定型的なチューニング、非定型的なチューニングを実施しても改善しない場合は、Oracleアーキテクチャやアプリケーション・アーキテクチャを意識して考察する必要がある。

SQL文の実行状況、処理状況をアーキテクチャも含めて確認


データ・ファイル制御ファイルREDOログ・ファイル

サーバープロセス

メモリ（SGA）

共有プール DBバッファ・キャッシュ

REDOログ・バッファ

ライブラリ・キャッシュ

ディクショナリ・キャッシュ

SQL文と実行計画

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

変更履歴X→Y

COMMIT

CKPT LGWR

< SQL文 >の発行

DBWｎ

• アーキテクチャを理解し、俯瞰的なアプローチをすることが大切

SQLチューニングにおけるアプローチアーキテクチャを意識したアプローチ



事例からみるボトルネックとチューニング


事例紹介に関する前提と注意事項

• 紹介事例は実際にOracleコンサルが現場で体験した事例です。• データは事象を再現させて取得している為、実際値とは異なります。• 画面は都合上、一部加工しています

• 紹介するチューニング方法は一例に過ぎません。

前提

注意事項


• 注文履歴の他システムデータ連携処理（月次バッチ）

• 単体テストの時点でSQLの性能問題は発生していない

• システムテストフェーズで突然、性能が劣化した

• テストデータを本番運用で想定される件数まで増やしている

事例1これまでの経緯と状況の説明

前提

テスト内容と結果

• 本番想定ジョブが規定時間以内に終了⇒規定時間以内に終わらず、性能要件を満たせず



APサーバプロセス






単体テスト

SQL文

JOB1

JOB2

JOB3

OracleDB

OracleDB

単体テスト

SQLを単体実行している為、その他の処理が重複しない

本番運用と同じジョブ構成で実行する為、

同時に複数のセッションから処理が実行される


ボトルネックの特定AWRを利用しての特定までの流れ

① 全体の把握待機イベントの発生状況をチェック

③ 詳細情報の確認待機イベントに関連する個所をチェック

② SQLの特定SQL文をチェック


• インスタンスにおける待機イベントの確認

db file sequential readsによる待機時間が長い

Wait ClassはUser I/O

⇒ I/O待ちによって待機が発生し性能が劣化している

ボトルネックの分析①全体の把握

発生した待機の中で性能に与える影響が大きいイベントを確認


• I/O統計の面からSQL文を確認

物理読み込みブロック数が多いSQL文（SQL ordered by Reads）

実行時間も比較的長い（Elapsed Time）

⇒ これらのSQL文で問題が起きている可能性がある

ボトルネックの分析② SQLの特定

ディスクから読み込まれたブロック数の多いSQL文を確認


• 不適切な実行計画が原因で読み込むブロック数が増加していないか

実行計画は単体テストの時と同じ

索引が使用されていて最適化されている

⇒実行計画の変動が性能劣化の原因ではない

ボトルネックの分析② SQLの特定（実行計画の確認）

特定したSQL文の実行計画に問題がないか確認

単体テスト時の実行計画

システムテスト時の実行計画


• I/O統計を確認

USERS表領域に対するReadsが多い

平均読み込み時間も長くなっている（Avg Rd(ms)）

⇒ USERS表領域へI/Oが集中し読み込み性能が劣化した

ボトルネックの分析③詳細情報の確認（I/O統計をチェック）

I/O競合が発生した表領域やデータファイルを確認


• 読み込み数の多いセグメントを確認

USERS表領域にある表・索引の読み込みが多い

実行時間の長いSQLでアクセスしている表や索引

⇒ これらのオブジェクトへのアクセスにおけるI/Oが原因

ボトルネックの分析③詳細情報の確認（セグメント統計をチェック）

I/Oの多いセグメントを確認


-単体テストの場合

ボトルネックの分析アーキテクチャからのアプローチ

多重度をあげることでI/O競合が発生した原因を理解

① SQL解析

共有プール（ライブラリキャッシュ）

実行計画AP

②ディスクからの読込み③バッファ読込み

サーバプロセス

バッファキャッシュ

65

43

21

65

43

21

・データ量が尐なく必要なブロックがバッファキャッシュにキャッシュされやすい・多重度が低くディスクを読み込む際にもプロセス間で競合しにくい


- システムテストの場合

ボトルネックの分析アーキテクチャからのアプローチ

AP

ディスクからの読込み


・データ量や多重度が増えたことでキャッシュに乗り切らないブロックへのアクセスが増加

・同時に同じディスクへアクセスするためプロセス間でI/O競合が発生

・結果的にSQLレスポンスが劣化





65

43

21

1211

109

87

1817

1615

1413

2423

2221

2019



APサーバプロセス共有プール（ライブラリキャッシュ）

実行計画

バッファキャッシュ

65

43

21

1211

109

87

I/O 競合

バッファからの読込み


ボトルネックの解消

• 原因①表と索引が同一表領域に格納されI/Oが集中しやすい

• 対策①表と索引の表領域を分け、各表領域を異なるRAIDグループに配置する

根本原因からチューニング案を検討する

索引用表領域

テーブル用表領域

COL1 COL2

１ AAA

2 BBB …

L11 L13サーバプロセス RAIDグループを分ける

ことでI/Oが分散される



• 原因②同時にアクセスされるセグメントが同じ表領域に格納され

多重化によりI/Oが集中しやすくなった

• 対策②同時にアクセスされやすいオブジェクト同士を異なる表領域に格納する。さらにアクセスが集中しやすいオブジェクトはパーティション化し、各パーティション毎に格納先を分ける。

TAB1表領域

TAB2表領域


Partition P1

Partition P2サーバプロセス


チューニング効果の確認

対策実施前対策実施後

表領域 Avg Rd(ms) Reads Avg Rd(ms) Reads

USERS 15.3ms 54,221 - -

TAB1 - - 1.3ms 17,981

TAB2 - - 1.5ms 19,350

IDX1 - - 0.8ms 9,975

IDX2 - - 1.1ms 8,037

チューニング結果

当然、読み込みブロック数は変化なし

I/O 分散により、平均読み込み時間は減尐


• 前提• 単体フェーズでSQLの性能問題は発生していない

• システムテストで発生したバッチ処理関連でのI/Oの性能問題は無事解決した

• シナリオ概要• オンラインポータル画面の同時ログイン負荷テスト

• 確認内容• C/O⇒1年後⇒3年後想定の最大ユーザ数でログインし、スケーラブル（※）であること

• ポータルログイン、My画面（スケジュール、カレンダー、Memo、共通ニュース等含む）の表示への遷移が問題なくできること

• テスト結果


C/O時 1年後想定 3年後想定

判定 OK OK NG

※スケーラブル：スループットを増やしてもレスポンスが劣化しないで処理がさばけること。


• オンラインポータル画面の同時ログイン負荷テスト

• 単体テストの時点でSQLの性能問題は発生していない

• システムテストで発生したバッチ処理関連での問題は無事解決


前提

テスト内容と結果

• C/O⇒1年後⇒3年後想定の最大ユーザ数でログインし、スケーラブル（※）であるか

• ポータルログイン、My画面（スケジュール、カレンダー、Memo、共通ニュース等含む）の表示への遷移が問題なくできること

⇒ 3年後想定のテストで要件を満たせず。

（※）スケーラブル・・・スループットが増加した際にレスポンスが劣化しないこと


ボトルネックの特定ボトルネック特定までの流れ

分析（対象SQL）②SQL文（実行計画）を確認1つのSQL分が大半を占めているSQLID ： cm17cbts5ga11

分析（対象待機）③待機イベントの確認cursor: pin S

latch : cache buffers chains

切り分け①DB以外の可能性をチェックCPU以外の目立った待機

テスト要件を満たせず

回避策⇒効果確認

分析（原因）④アーキテクチャから確認


ボトルネックの切り分け①DB以外の可能性をチェック

「CPU処理時間以外の待機」は何か？

• CPU処理時間以外の待機

待機イベントクラス「Other」「Concurency」が目立つ

⇒ DBまで処理が来ている

⇒ DB内の処理でボトルネックが発生していると判断


ボトルネックの分析②SQL文（実行計画）の確認

「SELECT status FROM stat_tab WHERE id = 1;」SQL文と実行計画は妥当か？

実行計画、実行時統計実行計画は単体テスト時と同じ「INDEX RANGE SCAN」で完結1実行あたり、1blockしかバッファを読込んでいない

表、索引の構造STAT_TAB_IX1 索引（複合索引）・抽出対象（SELECT）のstatus列・絞込条件（WHERE）のid列

• SQL文と実行計画

SQL文に必要な要素が索引に含まれ、表のデータにアクセスする必要なし

アクセスしているブロックは1blockのみで最小限である

⇒SQL単体は既に最適化され、実行計画の変動も性能劣化の原因ではない


SQL解析

ボトルネックの分析③待機イベントの確認

PGA

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

SGA

SQL

実行計画

AP

65

43

21

65

43

21


バッファからの読込み

どこに対する待機か？

待機ポイント


待機ポイント

cursor: pin S


• 各待機イベントの内容

「cursor: pin S」共有プールへの操作

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

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


ボトルネックの分析④アーキテクチャから確認「cursor : pin S」

「cursor: pin S」発生の仕組み

SQL解析

PGA


SGA

SQL

実行計画

AP

65

43

21

65

43

21


バッファからの読込みサーバプロセス

待機ポイント


SQL文出力

パーサ（Parser）

オプティマイザ行ソース・ジェネレータ

SQL実行

スタート

ハードパース

SQL情報のキャッシュ

実行計画を渡す

共有プール

ソフトパース

ボトルネックの分析④アーキテクチャから確認「cursor : pin S」

• 共有プール管理構造のポイント共有プールに既に解析済み情報が存在するか確認する際に獲得されるのが「cursor: pin S」

共有プール上の存在有無でパースの種類は異なる

‐ 存在する：ソフトパース

‐ 存在しない：ハードパース

存在有無のチェックは何れのパース（ソフト、ハード）でも行われる共通処理である

※別のプロセスがパースする可能性があるため、内部的にロックやピンが発生

SQL情報の存在チェック


ボトルネックの分析④アーキテクチャをチェック「latch : cache buffers chains」

「latch : cache buffers chains」発生の仕組み

SQL解析

PGA


SGA

SQL

実行計画

AP

65

43

21

65

43

21


バッファからの読込みサーバプロセス待機ポイント


• データベース・バッファ管理構造のポイント

対象のデータブロックがバッファされているかどうかチェーンをたどって検索する際に取得されるのが「latch : cache buffers chains」

1つのチェーンには、同じバケットにハッシュされたものがチェーンされる

チェーンされているのはブロック（バッファ）へリンクされるヘッダ情報

ヘッダ情報からブロック（バッファ）へアクセスを行う

バケットはラッチで保護され、バケットの数に比べてラッチの数は尐ない

・・・




ヘッダ情報

データベース・バッファ･キャッシュ

バケットチェーンラッチ

・・・・・

・・・・・

・・・・・

ヘッダ情報

ヘッダ情報

ヘッダ情報

ヘッダ情報

ヘッダ情報

ヘッダ情報





block

block

block

block

block

block

block

block

block

block

block

block

block

block

block

block

block

block

block

block

block

block

block

blockサーバプロセス

ボトルネックの分析④アーキテクチャをチェック「latch : cache buffers chains」



共有プール

共有カーソル

共有プール

共有カーソル

・・・





共有カーソル

共有カーソル

共有カーソル

・・・・・・





• 原因• 特定のSQL文を複数プロセスから実行することにより、軽いロックにも関わらず過度の競合が発生していた

• 対策• 特定SQL文に対する処理を分散させる

• アクセスする共有カーソルを分散させる（異なるSQLとして認識）

同じるS

QL

異なるS

QL

「cursor: pin S」の原因と対策の考察



・・・





DBバッファ

blockhead

・・・





status id

open 1

open 2

open 3

open 4

open 5

DBバッファ

blockhead

blockhead

head head block

status id

open 1

block

head head block

「latch : cache buffers chains」の原因と対策の考察

• 原因• 同一表の同一行へのアクセスにより、すべてのプロセスが同一ブロックへアクセスする必要があり、ブロックを管理するラッチに過度の競合が発生していた

• 対策• 特定ブロックに対するアクセスを分散させる

• ブロックを管理するチェーンを複数に分散させる（異なるチェーン、ラッチで管理）


実施したチューニング案および効果の確認

• 実施したチューニング案

cursor: pin S

スレッドIDをコメントとしてを付加する（異なるSQLと認識させる）


PCTFREEを調整し1ブロック1行とする（物理的に異なるブロックに格納）

複数の行を使ってステータスチェックする（異なるブロックにアクセス）

SELECT status FROM stat_tab WHERE id = 1；

⇒SELECT /* <スレッドID> */ status FROM stat_tab WHERE id = B1; (B1は実行時にスレッドID）


• 結果のサマリ• Oracle アーキテクチャの観点から分析することで対処策が導き出せた

• 実際に対処案を実装し、効果があることが確認できた

• ポイントと注意点• 今回は特にデータベース側の観点から実装が現実的なものを実装した

• SQLを共有しないことで発生するメモリリソースの使用量なども考慮が必要

• 同様のボトルネックであっても今回の回避策でも解決できない場合もある

• そもそもステータスチェックをSQLで実装しなくてもいいのではないか？という考え方も必要

結果のサマリ

チューニング前チューニング後

「latch : cache buffers chains」「cursor:pin S」がなくなっている



まとめ


• 全体最適化を意識したアプローチ• ボトルネックがWebサーバ、APサーバ、DBサーバ etc の切り分け

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

まとめ

本セミナーで解説した内容

SQLパフォーマンス問題に対する、事例を通じての原因分析・解決手法アプローチ

SQLパフォーマンス問題に対する、事例を通じての原因分析・解決手法アプローチ


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


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

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

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

OTN オンデマンド

最新情報つぶやき中

oracletechnetjp

・人気コンテンツは？

・お勧め情報

・公開予告など


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

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

• 技術資料

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

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

• コラム

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

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

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

Oracle Database 11gR2 旧バージョンからのアップグレード

オラクルエンジニア通信

最新情報つぶやき中

oracletechnetjp

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


オラクルクルクルキャンペーン

54

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年後に新システムへデータを移行

2010年11月30日まで


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

Documents

Oracle Direct Seminar...2010/10/19 · Oracle Direct Seminar オラクルコンサルが語るSQLチューニングの真髄 解決編Part3 日本オラクル株式会社

Oracle Direct Seminar...2010/10/19 · Oracle Direct Seminar オラクルコンサルが語るSQLチューニングの真髄解決編Part3 日本オラクル株式会社