Oracle Direct Seminar...2010/10/19 · Oracle Direct Seminar...
Transcript of Oracle Direct Seminar...2010/10/19 · Oracle Direct Seminar...
<Insert Picture Here>
Oracle Direct Seminar
オラクルコンサルが語るSQLチューニングの真髄解決編Part3
日本オラクル株式会社
1
Copyright© 2010, Oracle. All rights reserved. 2
• Introduction
• 目的とゴール
• これまでの振り返り - Part1、Part2 -
• SQLチューニングにおけるアプローチ• 全体最適化を意識したアプローチ
• アーキテクチャを意識したアプローチ
• 事例から見るボトルネック発見とチューニング• 事例1 : ディスクI/O編
• 事例2 : メモリ編
• まとめ
アジェンダ
Copyright© 2010, Oracle. All rights reserved. 3
<Insert Picture Here>
Introduction
Copyright© 2010, Oracle. All rights reserved.
本セミナーの目的とゴール
4
目的とゴール
• SQLパフォーマンス問題へのアプローチを理解する• SQL パフォーマンス問題における全体最適化を睨んだアプローチ
• Oracle Database のアーキテクチャーを意識したアプローチ
• SQL パフォーマンス問題の分析・解決手法を理解する• 事例を通じたSQL パフォーマンス問題の分析方法
• 事例を通じたSQL パフォーマンス問題の解決方法
Copyright© 2010, Oracle. All rights reserved. 5
<Insert Picture Here>
これまでの振り返り
- Part1、Part2 -
Copyright© 2010, Oracle. All rights reserved. 6
チューニング・アプローチ
定型的なチューニング
非定型的なチューニング
アーキテクチャを意識したチューニング
- これまでの振り返り Part1、Part2 -
SQLパフォーマンス問題へのアプローチ
SQL文の記述方法が柔軟でも、パフォーマンス問題を発生させないようにするためには、記述方法にある程度守るべきルールが存在する。
SQLコーディングルールによるSQL文の確認
定型的な解があるわけではない、頭で考える必要のあるSQLチューニング。
SQLがどのように処理しているのかを意識しながら、実行計画の確認
Part1,2
Copyright© 2010, Oracle. All rights reserved.
- これまでの振り返り Part1、Part2 –
定型的なSQLチューニング
問題がおきたら最低限
これだけはチェックする
最低限これだけは守って
コーディングする
「定型的なSQLチューニング」 = 「最低限のSQLコーディング・ルール」
予防 チューニング
• 柔軟な言語だからこそ、守るべきルールが存在する
• 大きく4つのカテゴリに分かれる
1. アーキテクチャに伴う性能問題を避けるためのルール
2. 使用方法やノウハウを元に性能問題を避けるためのルール
3. 可読性や管理性を高めるためのルール
4. 運用ポリシーを考慮したルール
7
定型的なSQLチューニング
Copyright© 2010, Oracle. All rights reserved.
- これまでの振り返り Part1、Part2 –
SQLコーディングルール
8
定型的なSQLチューニング
1. アーキテクチャに伴う性能問題を避けるためのルール
2.使用方法やノウハウを元に性能問題を避けるためのルール
3.可読性や管理性を高めるためのルール
4. 運用ポリシーを考慮したルール
バインド変数の利用
ビューを利用しての表結合回避
命名規則に従った管理用コメントの付与
ヒント句の適切な付与
Copyright© 2010, Oracle. All rights reserved. 9
オプティマイザへのインプット情報は妥当か?
自身で実行計画を検討
オプティマイザが生成した実行計画は適切か?
パフォーマンスを確認し妥当であればチューニング完了
インプット情報を修正できるか?
NOYES
NOYES
NOYESNO
<STEP1>
CBO(コストベース・オプティマイザ)に対するインプット情報の理解
<STEP2>
CBOが決定した実行計画が妥当であるかを判断する指針の理解
チューニングの進め方
- これまでの振り返り Part1、Part2 –
非定型的なSQLチューニング
非定型的なSQLチューニング
Copyright© 2010, Oracle. All rights reserved.
- これまでの振り返り Part1、Part2 –
< STEP1 > オプティマイザへのインプット情報
CBO(コストベースオプティマイザ)
SQLテキスト
パラメータ
オブジェクト構造
データの実態
環境
統計情報
実行計画
レスポンス
• コストベース・オプティマイザ(CBO)はどのような情報をもとに実行計画を決定するか
10
非定型的なSQLチューニング
Copyright© 2010, Oracle. All rights reserved.
表結合方法
表結合順序
索引を利用して参照
表を直接参照
データアクセス方法
全表スキャン(TABLE ACCESS FULL)
索引のレンジスキャン(INDEX RANCE SCAN)
索引の一意スキャン(INDEX UNIQUE SCAN)
索引のフルスキャン(INDEX FULL SCAN)
索引の高速フルスキャン(INDEX FAST FULL SCAN)
ネステッドループ結合
索引のスキップスキャン(INDEX SKIP SCAN)
ハッシュ結合
ソートマージ結合
直積結合
判断のポイント 分岐の種類
EMP表から?DEPT表から?それとも・・
11
- これまでの振り返り Part1、Part2 –
< STEP2 > 実行計画の妥当性判断
非定型的なSQLチューニング
妥当性を判断する3つのポイント
Copyright© 2010, Oracle. All rights reserved.
索引を利用して参照
表を直接参照
データアクセス方法
全表スキャン(TABLE ACCESS FULL)
索引のレンジスキャン(INDEX RANCE SCAN)
索引の一意スキャン(INDEX UNIQUE SCAN)
索引のフルスキャン(INDEX FULL SCAN)
索引の高速フルスキャン(INDEX FAST FULL SCAN)
索引のスキップスキャン(INDEX SKIP SCAN)
- これまでの振り返り Part1、Part2 –
< STEP2 > 実行計画の妥当性判断データアクセス方法
• データアクセス方法は大きく2つあります
12
非定型的なSQLチューニング
Copyright© 2010, Oracle. All rights reserved.
表結合方法
ネステッドループ結合
ハッシュ結合
ソートマージ結合
直積結合
• 表結合方法は4つあります。
13
非定型的なSQLチューニング
- これまでの振り返り Part1、Part2 –
< STEP2 > 実行計画の妥当性判断表結合方法
Copyright© 2010, Oracle. All rights reserved.
• 同時に3つ以上の表を結合することはできません。
• 結合順序のパターンは表の数に依存します。
表結合順序 EMP表から?DEPT表から?それとも・・
14
- これまでの振り返り Part1、Part2 –
< STEP2 > 実行計画の妥当性判断結合順のパターン
Copyright© 2010, Oracle. All rights reserved. 15
• SQL コーディングルールが適用されているか?• バインド変数が利用されているか?
• ビューを利用しての結合が行われていないか?
• CBOに対して適切な情報がインプットされているか?• オブジェクトが正しく作成されているか?
• パラメータ、統計情報が適切に設定されているか?
• 適切な実行計画が取られているか?• コストの尐ないデータアクセス方法が取られているか?
• コストの尐ない結合方式・結合順序が取られているか?
- これまでの振り返り Part1、Part2 –
まとめ
SQLによるデータの取得を最小のブロックアクセスで行うことが原則です。しかしながら、SQL単体を最適化(レスポンス改善)するアプローチだけでは不十分です。
SQLチューニングのアプローチ
Copyright© 2010, Oracle. All rights reserved. 16
<Insert Picture Here>
SQLチューニングにおけるアプローチ
Copyright© 2010, Oracle. All rights reserved. 17
SQLチューニングにおけるアプローチ全体最適化を意識したアプローチ
インターネット
データベース
ファイアーウォール
SQL
JavaHTML
HTML
Web
サーバーアプリケーションサーバー
Webシステム
ネットワークが狭い?
リクエストが十分受け付けられない?
Javaコードの問題?メモリ、CPUが足りない?
SQLの問題? DBの設定?
毎回接続?
• レスポンス・スループットが悪化 = SQL チューニング?
• Webシステムが複雑化するにつれ、ボトルネックの発見は困難になりがち
• アプリケーションやネットワークに問題があるのにSQLをチューニングしても効果はない
チューニングアプローチとしては、システム全体の最適化を意識して、性能要件(スループットおよびレスポンス)を満たせることをゴールとすること
Copyright© 2010, Oracle. All rights reserved. 18
チューニング・アプローチ
定型的なチューニング
非定型的なチューニング
アーキテクチャを意識したチューニング
Part1,2
SQLチューニングにおけるアプローチアーキテクチャを意識したアプローチ
Part3
定型的なチューニング、非定型的なチューニングを実施しても改善しない場合は、Oracleアーキテクチャやアプリケーション・アーキテクチャを意識して考察する必要がある。
SQL文の実行状況、処理状況をアーキテクチャも含めて確認
Copyright© 2010, Oracle. All rights reserved. 19
データ・ファイル 制御ファイルREDOログ・ファイル
サーバープロセス
メモリ(SGA)
共有プール DBバッファ・キャッシュ
REDOログ・バッファ
ライブラリ・キャッシュ
ディクショナリ・キャッシュ
SQL文と実行計画
データ・ディクショナリ情報
変更履歴X→Y
COMMIT
CKPT LGWR
< SQL文 >の発行
DBWn
• アーキテクチャを理解し、俯瞰的なアプローチをすることが大切
SQLチューニングにおけるアプローチアーキテクチャを意識したアプローチ
Copyright© 2010, Oracle. All rights reserved. 20
<Insert Picture Here>
事例からみるボトルネックとチューニング
Copyright© 2010, Oracle. All rights reserved. 21
事例紹介に関する前提と注意事項
• 紹介事例は実際にOracleコンサルが現場で体験した事例です。• データは事象を再現させて取得している為、実際値とは異なります。• 画面は都合上、一部加工しています
• 紹介するチューニング方法は一例に過ぎません。
前提
注意事項
Copyright© 2010, Oracle. All rights reserved. 22
• 注文履歴の他システムデータ連携処理(月次バッチ)
• 単体テストの時点でSQLの性能問題は発生していない
• システムテストフェーズで突然、性能が劣化した
• テストデータを本番運用で想定される件数まで増やしている
事例1これまでの経緯と状況の説明
前提
テスト内容と結果
• 本番想定ジョブが規定時間以内に終了⇒規定時間以内に終わらず、性能要件を満たせず
Copyright© 2010, Oracle. All rights reserved. 23
事例1これまでの経緯と状況の説明
APサーバプロセス
APサーバプロセス
APサーバプロセス
APサーバプロセス
APサーバプロセス
APサーバプロセス
単体テスト
SQL文
JOB1
JOB2
JOB3
OracleDB
OracleDB
単体テスト
SQLを単体実行している為、その他の処理が重複しない
本番運用と同じジョブ構成で実行する為、
同時に複数のセッションから処理が実行される
Copyright© 2010, Oracle. All rights reserved. 24
ボトルネックの特定AWRを利用しての特定までの流れ
① 全体の把握待機イベントの発生状況をチェック
③ 詳細情報の確認待機イベントに関連する個所をチェック
② SQLの特定SQL文をチェック
Copyright© 2010, Oracle. All rights reserved. 25
• インスタンスにおける待機イベントの確認
db file sequential readsによる待機時間が長い
Wait ClassはUser I/O
⇒ I/O待ちによって待機が発生し性能が劣化している
ボトルネックの分析①全体の把握
発生した待機の中で性能に与える影響が大きいイベントを確認
Copyright© 2010, Oracle. All rights reserved. 26
• I/O統計の面からSQL文を確認
物理読み込みブロック数が多いSQL文(SQL ordered by Reads)
実行時間も比較的長い(Elapsed Time)
⇒ これらのSQL文で問題が起きている可能性がある
ボトルネックの分析② SQLの特定
ディスクから読み込まれたブロック数の多いSQL文を確認
Copyright© 2010, Oracle. All rights reserved. 27
• 不適切な実行計画が原因で読み込むブロック数が増加していないか
実行計画は単体テストの時と同じ
索引が使用されていて最適化されている
⇒実行計画の変動が性能劣化の原因ではない
ボトルネックの分析② SQLの特定(実行計画の確認)
特定したSQL文の実行計画に問題がないか確認
単体テスト時の実行計画
システムテスト時の実行計画
Copyright© 2010, Oracle. All rights reserved. 28
• I/O統計を確認
USERS表領域に対するReadsが多い
平均読み込み時間も長くなっている(Avg Rd(ms))
⇒ USERS表領域へI/Oが集中し読み込み性能が劣化した
ボトルネックの分析③詳細情報の確認 (I/O統計をチェック)
I/O競合が発生した表領域やデータファイルを確認
Copyright© 2010, Oracle. All rights reserved. 29
• 読み込み数の多いセグメントを確認
USERS表領域にある表・索引の読み込みが多い
実行時間の長いSQLでアクセスしている表や索引
⇒ これらのオブジェクトへのアクセスにおけるI/Oが原因
ボトルネックの分析③詳細情報の確認 (セグメント統計をチェック)
I/Oの多いセグメントを確認
Copyright© 2010, Oracle. All rights reserved. 30
-単体テストの場合
ボトルネックの分析アーキテクチャからのアプローチ
多重度をあげることでI/O競合が発生した原因を理解
① SQL解析
共有プール(ライブラリキャッシュ)
実行計画AP
②ディスクからの読込み③バッファ読込み
サーバプロセス
バッファキャッシュ
65
43
21
65
43
21
・データ量が尐なく必要なブロックがバッファキャッシュにキャッシュされやすい・多重度が低くディスクを読み込む際にもプロセス間で競合しにくい
Copyright© 2010, Oracle. All rights reserved. 31
- システムテストの場合
ボトルネックの分析アーキテクチャからのアプローチ
AP
ディスクからの読込み
サーバプロセス
・データ量や多重度が増えたことでキャッシュに乗り切らないブロックへのアクセスが増加
・同時に同じディスクへアクセスするためプロセス間でI/O競合が発生
・結果的にSQLレスポンスが劣化
APサーバプロセス
APサーバプロセス
APサーバプロセス
APサーバプロセス
65
43
21
1211
109
87
1817
1615
1413
2423
2221
2019
APサーバプロセス
APサーバプロセス
APサーバプロセス 共有プール(ライブラリキャッシュ)
実行計画
バッファキャッシュ
65
43
21
1211
109
87
I/O 競合
バッファからの読込み
Copyright© 2010, Oracle. All rights reserved. 32
ボトルネックの解消
• 原因①表と索引が同一表領域に格納されI/Oが集中しやすい
• 対策①表と索引の表領域を分け、各表領域を異なるRAIDグループに配置する
根本原因からチューニング案を検討する
索引用表領域
テーブル用表領域
COL1 COL2
1 AAA
2 BBB …
L11 L13サーバプロセス RAIDグループを分ける
ことでI/Oが分散される
Copyright© 2010, Oracle. All rights reserved. 33
ボトルネックの解消
• 原因②同時にアクセスされるセグメントが同じ表領域に格納され
多重化によりI/Oが集中しやすくなった
• 対策②同時にアクセスされやすいオブジェクト同士を異なる表領域に格納する。さらにアクセスが集中しやすいオブジェクトはパーティション化し、各パーティション毎に格納先を分ける。
TAB1表領域
TAB2表領域
サーバプロセス
Partition P1
Partition P2サーバプロセス
Copyright© 2010, Oracle. All rights reserved. 34
チューニング効果の確認
対策実施前 対策実施後
表領域 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 分散により、平均読み込み時間は減尐
Copyright© 2010, Oracle. All rights reserved. 35
• 前提• 単体フェーズでSQLの性能問題は発生していない
• システムテストで発生したバッチ処理関連でのI/Oの性能問題は無事解決した
• シナリオ概要• オンラインポータル画面の同時ログイン負荷テスト
• 確認内容• C/O⇒1年後⇒3年後想定の最大ユーザ数でログインし、スケーラブル(※)であること
• ポータルログイン、My画面(スケジュール、カレンダー、Memo、共通ニュース等含む)の表示への遷移が問題なくできること
• テスト結果
事例2これまでの経緯と状況の説明
C/O時 1年後想定 3年後想定
判定 OK OK NG
※スケーラブル:スループットを増やしてもレスポンスが劣化しないで処理がさばけること。
Copyright© 2010, Oracle. All rights reserved. 36
• オンラインポータル画面の同時ログイン負荷テスト
• 単体テストの時点でSQLの性能問題は発生していない
• システムテストで発生したバッチ処理関連での問題は無事解決
事例1これまでの経緯と状況の説明
前提
テスト内容と結果
• C/O⇒1年後⇒3年後想定の最大ユーザ数でログインし、スケーラブル(※)であるか
• ポータルログイン、My画面(スケジュール、カレンダー、Memo、共通ニュース等含む)の表示への遷移が問題なくできること
⇒ 3年後想定のテストで要件を満たせず。
(※) スケーラブル・・・スループットが増加した際にレスポンスが劣化しないこと
Copyright© 2010, Oracle. All rights reserved. 37
ボトルネックの特定ボトルネック特定までの流れ
分析(対象SQL)②SQL文(実行計画)を確認1つのSQL分が大半を占めているSQLID : cm17cbts5ga11
分析(対象待機)③待機イベントの確認cursor: pin S
latch : cache buffers chains
切り分け①DB以外の可能性をチェックCPU以外の目立った待機
テスト要件を満たせず
回避策⇒効果確認
分析(原因)④アーキテクチャから確認
Copyright© 2010, Oracle. All rights reserved. 38
ボトルネックの切り分け①DB以外の可能性をチェック
「CPU処理時間以外の待機」は何か?
• CPU処理時間以外の待機
待機イベントクラス「Other」「Concurency」が目立つ
⇒ DBまで処理が来ている
⇒ DB内の処理でボトルネックが発生していると判断
Copyright© 2010, Oracle. All rights reserved. 39
ボトルネックの分析②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単体は既に最適化され、実行計画の変動も性能劣化の原因ではない
Copyright© 2010, Oracle. All rights reserved. 40
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」 DBバッファキャッシュへの操作
⇒メモリ領域に対する処理がボトルネックとなっている
Copyright© 2010, Oracle. All rights reserved. 41
ボトルネックの分析④アーキテクチャから確認 「cursor : pin S」
「cursor: pin S」発生の仕組み
SQL解析
PGA
DBバッファキャッシュ共有プール REDOログバッファ
SGA
SQL
実行計画
AP
65
43
21
65
43
21
ディスクからの読込み
バッファからの読込みサーバプロセス
待機ポイント
Copyright© 2010, Oracle. All rights reserved. 42
SQL文 出力
パーサ(Parser)
オプティマイザ行ソース・ジェネレータ
SQL実行
スタート
ハードパース
SQL情報のキャッシュ
実行計画を渡す
共有プール
ソフトパース
ボトルネックの分析④アーキテクチャから確認 「cursor : pin S」
• 共有プール管理構造のポイント 共有プールに既に解析済み情報が存在するか確認する際に獲得されるのが「cursor: pin S」
共有プール上の存在有無でパースの種類は異なる
‐ 存在する:ソフトパース
‐ 存在しない:ハードパース
存在有無のチェックは何れのパース(ソフト、ハード)でも行われる共通処理である
※別のプロセスがパースする可能性があるため、内部的にロックやピンが発生
SQL情報の存在チェック
Copyright© 2010, Oracle. All rights reserved. 43
ボトルネックの分析④アーキテクチャをチェック 「latch : cache buffers chains」
「latch : cache buffers chains」発生の仕組み
SQL解析
PGA
DBバッファキャッシュ共有プール REDOログバッファ
SGA
SQL
実行計画
AP
65
43
21
65
43
21
ディスクからの読込み
バッファからの読込みサーバプロセス 待機ポイント
Copyright© 2010, Oracle. All rights reserved. 44
• データベース・バッファ管理構造のポイント
対象のデータブロックがバッファされているかどうかチェーンをたどって検索する際に取得されるのが「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」
Copyright© 2010, Oracle. All rights reserved. 45
ボトルネックの解消
共有プール
共有カーソル
共有プール
共有カーソル
・・・
サーバプロセス
サーバプロセス
サーバプロセス
サーバプロセス
共有カーソル
共有カーソル
共有カーソル
・・・・・・
サーバプロセス
サーバプロセス
サーバプロセス
サーバプロセス
• 原因• 特定のSQL文を複数プロセスから実行することにより、軽いロックにも関わらず過度の競合が発生していた
• 対策• 特定SQL文に対する処理を分散させる
• アクセスする共有カーソルを分散させる(異なるSQLとして認識)
同じるS
QL
異なるS
QL
「cursor: pin S」の原因と対策の考察
Copyright© 2010, Oracle. All rights reserved. 46
ボトルネックの解消
・・・
サーバプロセス
サーバプロセス
サーバプロセス
サーバプロセス
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」の原因と対策の考察
• 原因• 同一表の同一行へのアクセスにより、すべてのプロセスが同一ブロックへアクセスする必要があり、ブロックを管理するラッチに過度の競合が発生していた
• 対策• 特定ブロックに対するアクセスを分散させる
• ブロックを管理するチェーンを複数に分散させる(異なるチェーン、ラッチで管理)
Copyright© 2010, Oracle. All rights reserved. 47
実施したチューニング案および効果の確認
• 実施したチューニング案
cursor: pin S
スレッドIDをコメントとしてを付加する(異なるSQLと認識させる)
latch : cache buffers chains
PCTFREEを調整し1ブロック1行とする (物理的に異なるブロックに格納)
複数の行を使ってステータスチェックする (異なるブロックにアクセス)
SELECT status FROM stat_tab WHERE id = 1;
⇒SELECT /* <スレッドID> */ status FROM stat_tab WHERE id = B1; (B1は実行時にスレッドID)
Copyright© 2010, Oracle. All rights reserved. 48
• 結果のサマリ• Oracle アーキテクチャの観点から分析することで対処策が導き出せた
• 実際に対処案を実装し、効果があることが確認できた
• ポイントと注意点• 今回は特にデータベース側の観点から実装が現実的なものを実装した
• SQLを共有しないことで発生するメモリリソースの使用量なども考慮が必要
• 同様のボトルネックであっても今回の回避策でも解決できない場合もある
• そもそもステータスチェックをSQLで実装しなくてもいいのではないか?という考え方も必要
結果のサマリ
チューニング前 チューニング後
「latch : cache buffers chains」「cursor:pin S」がなくなっている
Copyright© 2010, Oracle. All rights reserved. 49
<Insert Picture Here>
まとめ
Copyright© 2010, Oracle. All rights reserved. 50
• 全体最適化を意識したアプローチ• ボトルネックがWebサーバ、APサーバ、DBサーバ etc の切り分け
• アーキテクチャを意識したアプローチ
まとめ
本セミナーで解説した内容
SQLパフォーマンス問題に対する、事例を通じての原因分析・解決手法アプローチ
SQLパフォーマンス問題に対する、事例を通じての原因分析・解決手法アプローチ
Copyright© 2010, Oracle. All rights reserved. 51
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コンテンツ オン デマンドか、セミナ実施時間内にダウンロード頂くようお願い致します。
Copyright© 2010, Oracle. All rights reserved. 52
OTNセミナー オンデマンド コンテンツダイセミで実施された技術コンテンツを動画で配信中!!
ダイセミのライブ感はそのままに、お好きな時間で受講頂けます。
※掲載のコンテンツ内容は予告なく変更になる可能性があります。期間限定での配信コンテンツも含まれております。お早めにダウンロード頂くことをお勧めいたします。
OTN オンデマンド
最新情報つぶやき中
oracletechnetjp
・人気コンテンツは?
・お勧め情報
・公開予告 など
Copyright© 2010, Oracle. All rights reserved. 53
Oracle エンジニアのための技術情報サイト
オラクルエンジニア通信http://blogs.oracle.com/oracle4engineer/
• 技術資料
• ダイセミの過去資料や製品ホワイトペーパー、スキルアップ資料などを多様な方法で検索できます
• キーワード検索、レベル別、カテゴリ別、製品・機能別
• コラム
• オラクル製品に関する技術コラムを毎週お届けします
• 決してニッチではなく、誰もが明日から使える技術の「あ、そうだったんだ!」をお届けします 先月はこんな資料が人気でした
Oracle Database 11gR2 RAC インストレーション・ガイド ASM 版 Microsoft Windows x86-64
Oracle Database 11gR2 旧バージョンからのアップグレード
オラクルエンジニア通信
最新情報つぶやき中
oracletechnetjp
Copyright© 2010, Oracle. All rights reserved.
オラクル クルクルキャンペーン
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日まで
Copyright© 2010, Oracle. All rights reserved. 55
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プロジェクト全般の相談窓口としてご支援いたします。
システム構成やライセンス/購入方法などお気軽にお問い合わせ下さい。