Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Oracle脳で考える
SQL Server運用
コンサルティング事業部
内山 義夫
2
Contents
• 1. Oracle脳とは?
• 2. Oracle脳によるSQL Server運用例
• 3. まとめ
3
Oracle脳とは?Oracle脳とは?
4
Oracle脳とは?
• Oracle脳(造語)
「データベース=Oracle」なDBA
基盤の共通化でOracleがスタンダードに
小さいシステムでSQL ServerやMySQLを少々使用
5
Oracle脳の現場
インデックス追加し
ておいてー。
インデックス追加し
ておいてー。
実行計画を固定化し
たいんだけどー。
実行計画を固定化し
たいんだけどー。
1時間前のデータに
戻してー。
1時間前のデータに
戻してー。
バッチが遅...
6
リクエストに対する対処
• Oracle脳レベル
– Oracleを運用している環境やスキルにより異なる
・EEオプションは当たり前
・最新のOracleの機能を率
先して使うアーリーアダプ
ター
・EEオプションは当たり前
・最新のOra...
7
例えば・・・
自動データ最適化の使用自動データ最適化の使用
Ver 3.0
セグメントアドバイザの
推奨対応
セグメントアドバイザの
推奨対応
Ver 2.0
不要データの削除不要データの削除
Ver 1.0
空き領域が不足しそう。緊急で空...
8
そんなある日
• そっと聞こえる神の声
– 次のシステムリプレイス時に別のDBに移行するかも。
– SQL Serverって基幹システムで使えるの?
– まずは、小さいシステムから移行を検討してみるか。
9
SQL Serverへの移行?
• 移行にまつわる背景
– SE、SE One廃止/SE RACの制限強化
• 1ノード1ソケットに制限
– EEに上げるか、ソケット数を落とすか。。。
• 12.1.0.1は2016年8月でExtended...
10
SQL Serverへの移行?
• 移行にまつわる背景 その2
– ハードスペック向上
• SSDや大容量メモリなどDBの性能に大きく影響
• CPU数の増加はライセンスに影響も。。。
– MicrosoftのVS Oracle施策
• ...
11
Oracle脳によるSQL Server運用例Oracle脳によるSQL Server運用例
12
SQL Serverで既存の運用はどう変わる?
• 実際の現場でよくあるOracle運用
– ケース1:空き領域が不足しそう。緊急で空きを作ってー。
– ケース2:実行計画を固定化したいんだけどー。
– ケース3:パフォーマンス遅延が発生...
13
SQL Serverで既存の運用はどう変わる?
• 実際の現場でよくあるOracle運用
– ケース1:空き領域が不足しそう。緊急で空きを作ってー。
– ケース2:実行計画を固定化したいんだけどー。
– ケース3:パフォーマンス遅延が発生...
14
ケース1
自動データ最適化の使用自動データ最適化の使用
Ver 3.0
セグメントアドバイザの
推奨対応
セグメントアドバイザの
推奨対応
Ver 2.0
不要データの削除不要データの削除
Ver 1.0
空き領域が不足しそう。緊急で空き...
15
空き領域不足→不要なデータの削除
• 不要なテーブル/データの削除
– よくあるゴミテーブルの削除
• Ex)
– EMP_BK
– EMP_20160715
– よくあるごみデータの削除
• deleted_flg=1のデータ
– よく...
16
空き領域不足→不要なデータの削除
• 不要なインデックスの削除
– アプリケーションで使用されていないインデックスを削除
• 未使用インデックスを抽出
– インデックスの監視設定を使用
» Alter index [インデックス名] mo...
17
空き領域不足→セグメントアドバイザ
• セグメントアドバイザの使用
– セグメントアドバイザとは?
• 再生可能な領域があるセグメントを特定
• 定期的に自動実行(必要時に実行することも可)
• 圧縮、縮小、再構築などのアドバイスを実施。...
18
空き領域不足→自動データ最適化
• 自動データ最適化(ADO)
– 自動データ最適化(Automatic Data Optimization)とは?
• アクセスがないデータをOracleが自動で圧縮
• ポリシーを作成し、そのポリシーに...
19
ケース1(SQL Serverの場合)
自動データ最適化の使用自動データ最適化の使用
Ver 3.0
セグメントアドバイザの
推奨対応
セグメントアドバイザの
推奨対応
Ver 2.0
不要データの削除不要データの削除
Ver 1.0
不...
20
空き領域不足→不要なデータの削除
• 不要なデータの削除
– 不要なテーブルの削除はOracleと同じ
– 未使用インデックスの抽出
• 「インデックスの使用状況の統計」レポートで確認可能
• インスタンス起動以降の統計
参照無し
21
空き領域不足→アドバイザ
• アドバイザ(断片化)
– インデックスの物理統計レポートで確認可能
• 「推奨されている操作」にアドバイスが記載
推奨する操作のアド
バイス
22
空き領域不足→アドバイザ
• アドバイザ(圧縮)
– 圧縮による効果を確認
• sp_estimate_data_compression_savingsの使用
– インデックス毎に圧縮率を測定
– インスタンス起動以降の統計
USE TP...
23
空き領域不足→×自動データ最適化
• 自動データ最適化
→SQL Serverに同等の機能はない。。。
– 他にSQL Serverでできる空き領域確保
• 列ストアインデックスの使用
– その他のインデックスが削除できる場合がある
24
ケース1 まとめ
自動データ最適化の使用自動データ最適化の使用
Ver 3.0
セグメントアドバイザの
推奨対応
セグメントアドバイザの
推奨対応
Ver 2.0
不要データの削除不要データの削除
Ver 1.0
不要データの削除 標準レ...
25
SQL Serverで既存の運用はどう変わる?
• 実際の現場でよくあるOracle運用
– ケース1:空き領域が不足しそう。緊急で空きを作ってー。
– ケース2:実行計画を固定化したいんだけどー。
– ケース3:パフォーマンス遅延が発生...
26
ケース2
SQLプロファイルの適用SQLプロファイルの適用
Ver 3.0
SPMで固定化SPMで固定化
Ver 2.0
ヒント句追加ヒント句追加
Ver 1.0
実行計画を固定化したいんだけどー実行計画を固定化したいんだけどー
27
プラン固定化→ヒント句追加
• SQLにヒント句を追加
– アプリケーションの改修を伴う
SELECT
e.empno,
e.ename,
d.deptno,
d.dname
FROM
emp e,
dept d
WHERE
e.dept...
28
プラン固定化→ヒント句追加
• Tips:別クエリの実行計画からヒント句作成
SELECT
/*+
BEGIN_OUTLINE_DATA
USE_NL(@"SEL$1" "E"@"SEL$1")
LEADING(@"SEL$1" "D"@...
29
プラン固定化→SPM
• SPMによる固定化
– SPM(SQL Plan Management)とは?
• SQLの実行計画を記録し、実行計画を管理。固定化も可能
• 過去に実行された実行計画を固定化することも可能
SPMで管理されてい...
30
• 過去に実行された実行計画の固定化
プラン固定化→SPM
過去に実行されたSQLを検索
作成したSQLチューニ
ングセットを指定
SQLチューニングセッ
トを作成
SPMで該当のSQLチューニングセットを指定
31
プラン固定化→SQLプロファイル
• SQLプロファイルによる固定化
– SQLプロファイルとは?
• チューニングアドバイザで作成された実行計画
• 適用することで、実行計画が固定化
チューニングアドバイザの結果
SQLプロファイル適
...
32
プラン固定化→SQLプロファイル
• Tips:ある期間の全クエリに対するアドバイス
過去24時間のAWR
スナップショット
ある期間のSQLをSQLチューニングセットとして作成
SQLチューニングセットに対するアドバイザ実行
該当期間の...
33
ケース2(SQL Serverの場合)
Ver 3.0Ver 2.0Ver 1.0
ヒント句追加 クエリストアで強制 N/A(推奨値の表示の
み)
SQLプロファイルの適用SQLプロファイルの適用SPMで固定化SPMで固定化ヒント句追加ヒ...
34
プラン固定化→ヒント句追加
• ヒント句の追加
SELECT
e.empno,
e.ename,
d.deptno,
d.dname
FROM
emp e,
dept d
WHERE
e.deptno = d.deptno;
SELECT...
35
プラン固定化→ヒント句追加
• 別クエリの実行プランを適用
SQLに、Option(USE PLAN
N’XML’)を追加することで、
左記の実行プランで実行さ
れる
SQLの実行プランをXMLに保存
実行プラン(XML)
実行プランの固...
36
• クエリストアからプランを強制
– クエリストアとは?
• クエリのパフォーマンス情報を収集、分析し、クエリのパフォーマンスを管理
• 実行プランの強制が可能
遅いときの
実行プラン
右上で選択した
プランを強制
速いときの
実行プラン...
37
プラン固定化→アドバイザ機能(のみ)
• アドバイザ機能
– データベースエンジンチューニングアドバイザー
SQLで右クリックし、データ
ベースエンジンチューニング
アドバイザーを起動
推奨インデックス
の定義が表示され
る
予想向上率
38
• アドバイザ機能
– 不足しているインデックス
プラン固定化→アドバイザ機能(のみ)
インデックスを作成す
ると性能が向上する可
能性がある
39
プラン固定化→アドバイザ機能(のみ)
• 不足しているインデックス一覧の出力
– dm_db_missing_index_detailsで参照可能
不足しているイン
デックスに指定す
る列名
40
ケース2 まとめ
Ver 3.0Ver 2.0Ver 1.0
ヒント句追加 クエリストアで強制 N/A(推奨値の表示の
み)
SQLプロファイルの適用SQLプロファイルの適用SPMで固定化SPMで固定化ヒント句追加ヒント句追加
実行計画を...
41
SQL Serverで既存の運用はどう変わる?
• 実際の現場でよくあるOracle運用
– ケース1:空き領域が不足しそう。緊急で空きを作ってー。
– ケース2:実行計画を固定化したいんだけどー。
– ケース3:パフォーマンス遅延発生。...
42
ケース3
SQLモニタリングで調査SQLモニタリングで調査
Ver 3.0
EMで調査EMで調査
Ver 2.0
Statspackで調査Statspackで調査
Ver 1.0
パフォーマンス遅延発生。原因調査してー。パフォーマンス遅延...
43
パフォーマンス遅延→Statspackで調査
• Statspackを使用した調査
– パフォーマンス問題発生時のStatspackレポートを取得
– 正常時と比較して調査
• どのクエリが遅延しているか?
• 問題発生時にしかないクエリ...
44
• Enterprise Managerのパフォーマンス情報を調査
– トップアクティビティ→SQLの詳細で調査
該当時間帯にど
のクエリが遅い
か?
該当クエリの待機を確認。
ロック待ち?I/O?CPU?
パフォーマンス遅延→EMで調査
45
• ASHレポートやAWRSQLレポートを使用した調査
パフォーマンス遅延→EMで調査
46
• SQLモニタリング
– リアルタイムでクエリの負荷状況を確認可能
– クエリ実行中の場合、進行状況も表示
クエリの進行状況
完了時間も表示
パフォーマンス遅延→SQLモニタリングで調査
47
ケース3(SQL Serverの場合)
SQLモニタリングで調査SQLモニタリングで調査
Ver 3.0
EMで調査EMで調査
Ver 2.0
Statspackで調査Statspackで調査
Ver 1.0
パフォーマンスデータコ
レク...
48
パフォーマンス遅延→パフォーマンス
データコレクションで調査
• パフォーマンスデータコレクションによる調査
– パフォーマンスデータコレクションとは?
• データベースの稼働統計
• SQL Serverの待機やOSリソースの情報収集
...
49
• クエリ統計でクエリの詳細を調査
該当時間帯にど
のクエリが遅い
か?
SQLの待機詳細
パフォーマンス遅延→パフォーマンス
データコレクションで調査
クエリ統計
50
• クエリストアによる調査
– クエリストアとは?
• 実行されたクエリの情報を収集、分析可能
• クエリの遅延原因の分析
リソースを消費する
クエリの上位
全体のリソース消費量
追跡したクエリ
低下したクエリ
パフォーマンス遅延→クエリ...
51
• 過去1時間の間に低下した上位25のクエリ
遅延が発生した
クエリ 遅いときの実行
プラン
パフォーマンス遅延→クエリストアで調査
速いときの実行
プラン
52
• SQLモニター
– リアルタイムの接続状況を確認可能
– 遅延しているクエリ等の抽出は可能
– クエリ実行中の完了時間等は確認できず
パフォーマンス遅延→SQLモニター
53
ケース3 まとめ
SQLモニタリングで調査SQLモニタリングで調査
Ver 3.0
EMで調査EMで調査
Ver 2.0
Statspackで調査Statspackで調査
Ver 1.0
パフォーマンスデータコ
レクションで調査
クエリス...
54
まとめまとめ
55
• Oracle脳の運用はSQL Serverでも応用できる
– RDBMSなので、考え方は同じ
• ただし、一部の機能はOracleにしかない
– 自動データ最適化やSQLプロファイル、SQLモニタリングなど
– 使い込んでると運用にイ...
56
無断転載を禁ず
この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。
株式会社インサイトテクノロジーは本書の内容に関していかなる保証もしません。また、本書の内容に関連したいかな
る損害についても責任...
Upcoming SlideShare
Loading in …5
×

[db tech showcase Tokyo 2016] A32: Oracle脳で考えるSQL Server運用 by 株式会社インサイトテクノロジー 内山 義夫

1,750 views

Published on

Published in: Technology
  • Be the first to comment

[db tech showcase Tokyo 2016] A32: Oracle脳で考えるSQL Server運用 by 株式会社インサイトテクノロジー 内山 義夫

  1. 1. Oracle脳で考える SQL Server運用 コンサルティング事業部 内山 義夫
  2. 2. 2 Contents • 1. Oracle脳とは? • 2. Oracle脳によるSQL Server運用例 • 3. まとめ
  3. 3. 3 Oracle脳とは?Oracle脳とは?
  4. 4. 4 Oracle脳とは? • Oracle脳(造語) 「データベース=Oracle」なDBA 基盤の共通化でOracleがスタンダードに 小さいシステムでSQL ServerやMySQLを少々使用
  5. 5. 5 Oracle脳の現場 インデックス追加し ておいてー。 インデックス追加し ておいてー。 実行計画を固定化し たいんだけどー。 実行計画を固定化し たいんだけどー。 1時間前のデータに 戻してー。 1時間前のデータに 戻してー。 バッチが遅延したの で、調査してー。 バッチが遅延したの で、調査してー。 領域が不足しそう。 なんとかしてー。 領域が不足しそう。 なんとかしてー。 障害が発生したので、 調査してー。 障害が発生したので、 調査してー。 通常運用中 障害対応中
  6. 6. 6 リクエストに対する対処 • Oracle脳レベル – Oracleを運用している環境やスキルにより異なる ・EEオプションは当たり前 ・最新のOracleの機能を率 先して使うアーリーアダプ ター ・EEオプションは当たり前 ・最新のOracleの機能を率 先して使うアーリーアダプ ター Ver 3.0 ・EEやEEのオプションを使 用した環境がメイン ・Oracleの機能を色々使用 して運用している ・EEやEEのオプションを使 用した環境がメイン ・Oracleの機能を色々使用 して運用している Ver 2.0 ・SEやSE Oneの環境を主に 運用している ・EEの環境もあるが、オプ ション等は使用していない ・SEやSE Oneの環境を主に 運用している ・EEの環境もあるが、オプ ション等は使用していない Ver 1.0
  7. 7. 7 例えば・・・ 自動データ最適化の使用自動データ最適化の使用 Ver 3.0 セグメントアドバイザの 推奨対応 セグメントアドバイザの 推奨対応 Ver 2.0 不要データの削除不要データの削除 Ver 1.0 空き領域が不足しそう。緊急で空きを作ってー。空き領域が不足しそう。緊急で空きを作ってー。
  8. 8. 8 そんなある日 • そっと聞こえる神の声 – 次のシステムリプレイス時に別のDBに移行するかも。 – SQL Serverって基幹システムで使えるの? – まずは、小さいシステムから移行を検討してみるか。
  9. 9. 9 SQL Serverへの移行? • 移行にまつわる背景 – SE、SE One廃止/SE RACの制限強化 • 1ノード1ソケットに制限 – EEに上げるか、ソケット数を落とすか。。。 • 12.1.0.1は2016年8月でExtended Support無しで終了 – Oracleのサポートライセンス • 毎年2%ずつ上昇(更新時調整率) 。 • ボディーブローのように効いてくる。 – 2020年12月に11gR2のExtended Support終了 • まだ先の話だが、アプリの改修も考えるとそろそろ動き出す時期?
  10. 10. 10 SQL Serverへの移行? • 移行にまつわる背景 その2 – ハードスペック向上 • SSDや大容量メモリなどDBの性能に大きく影響 • CPU数の増加はライセンスに影響も。。。 – MicrosoftのVS Oracle施策 • Oracleからの移行でライセンス無料 • Linux版SQL Serverのリリース – その他要因 • ビッグデータによるデータ量の増加 • クラウドへの移行の加速
  11. 11. 11 Oracle脳によるSQL Server運用例Oracle脳によるSQL Server運用例
  12. 12. 12 SQL Serverで既存の運用はどう変わる? • 実際の現場でよくあるOracle運用 – ケース1:空き領域が不足しそう。緊急で空きを作ってー。 – ケース2:実行計画を固定化したいんだけどー。 – ケース3:パフォーマンス遅延が発生。原因調査してー。 OracleとSQL Server でどこがどう違うのか?OracleとSQL Server でどこがどう違うのか?
  13. 13. 13 SQL Serverで既存の運用はどう変わる? • 実際の現場でよくあるOracle運用 – ケース1:空き領域が不足しそう。緊急で空きを作ってー。 – ケース2:実行計画を固定化したいんだけどー。 – ケース3:パフォーマンス遅延が発生。原因調査してー。
  14. 14. 14 ケース1 自動データ最適化の使用自動データ最適化の使用 Ver 3.0 セグメントアドバイザの 推奨対応 セグメントアドバイザの 推奨対応 Ver 2.0 不要データの削除不要データの削除 Ver 1.0 空き領域が不足しそう。緊急で空きを作ってー。空き領域が不足しそう。緊急で空きを作ってー。
  15. 15. 15 空き領域不足→不要なデータの削除 • 不要なテーブル/データの削除 – よくあるゴミテーブルの削除 • Ex) – EMP_BK – EMP_20160715 – よくあるごみデータの削除 • deleted_flg=1のデータ – よくある過去データ削除 • 保持期限が過ぎたデータ • 過去パーティションや履歴テーブル等のデータ – テーブルやインデックスの再構築 • 圧縮済みデータの再圧縮等
  16. 16. 16 空き領域不足→不要なデータの削除 • 不要なインデックスの削除 – アプリケーションで使用されていないインデックスを削除 • 未使用インデックスを抽出 – インデックスの監視設定を使用 » Alter index [インデックス名] monitoring usage; declare cursor cur is select owner, index_name from dba_indexes where owner In('XXX') and index_type In( 'NORMAL','FUNCTION-BASED NORMAL' ) and index_name Not like ‘BIN$%’; ls_sql varchar2(100); begin for rec in cur loop ls_sql := 'alter index '||rec.owner||'.'||rec.index_name||' monitoring usage'; execute immediate ( ls_sql ); end loop; exception when others then dbms_output.put_line(ls_sql); dbms_output.put_line(sqlerrm); end; / Ex) XXXユーザーが所有するすべてのインデックスに監視設定を適用する場合
  17. 17. 17 空き領域不足→セグメントアドバイザ • セグメントアドバイザの使用 – セグメントアドバイザとは? • 再生可能な領域があるセグメントを特定 • 定期的に自動実行(必要時に実行することも可) • 圧縮、縮小、再構築などのアドバイスを実施。サイズの縮小を検討。
  18. 18. 18 空き領域不足→自動データ最適化 • 自動データ最適化(ADO) – 自動データ最適化(Automatic Data Optimization)とは? • アクセスがないデータをOracleが自動で圧縮 • ポリシーを作成し、そのポリシーに沿って自動圧縮 テーブルA(圧縮前) テーブルA(圧縮後) 空きブロックが増加 圧縮前:12ブロック 圧縮後:18ブロック Ex) 1年以上更新がなかった行(ブロック)を圧縮 1週間以下 1週間~1年 1年以上
  19. 19. 19 ケース1(SQL Serverの場合) 自動データ最適化の使用自動データ最適化の使用 Ver 3.0 セグメントアドバイザの 推奨対応 セグメントアドバイザの 推奨対応 Ver 2.0 不要データの削除不要データの削除 Ver 1.0 不要データの削除 標準レポートの使用 アドバイザの使用 空き領域が不足しそう。緊急で空きを作ってー。空き領域が不足しそう。緊急で空きを作ってー。 N/A
  20. 20. 20 空き領域不足→不要なデータの削除 • 不要なデータの削除 – 不要なテーブルの削除はOracleと同じ – 未使用インデックスの抽出 • 「インデックスの使用状況の統計」レポートで確認可能 • インスタンス起動以降の統計 参照無し
  21. 21. 21 空き領域不足→アドバイザ • アドバイザ(断片化) – インデックスの物理統計レポートで確認可能 • 「推奨されている操作」にアドバイスが記載 推奨する操作のアド バイス
  22. 22. 22 空き領域不足→アドバイザ • アドバイザ(圧縮) – 圧縮による効果を確認 • sp_estimate_data_compression_savingsの使用 – インデックス毎に圧縮率を測定 – インスタンス起動以降の統計 USE TPCC GO EXEC sp_estimate_data_compression_savings 'dbo', 'CUSTOMER', NULL, NULL, ‘PAGE' ; GO Ex) TPCCデータベースのCUSTOMER表をページ圧縮で分析
  23. 23. 23 空き領域不足→×自動データ最適化 • 自動データ最適化 →SQL Serverに同等の機能はない。。。 – 他にSQL Serverでできる空き領域確保 • 列ストアインデックスの使用 – その他のインデックスが削除できる場合がある
  24. 24. 24 ケース1 まとめ 自動データ最適化の使用自動データ最適化の使用 Ver 3.0 セグメントアドバイザの 推奨対応 セグメントアドバイザの 推奨対応 Ver 2.0 不要データの削除不要データの削除 Ver 1.0 不要データの削除 標準レポートの使用 アドバイザの使用 空き領域が不足しそう。緊急で空きを作ってー。空き領域が不足しそう。緊急で空きを作ってー。 N/A
  25. 25. 25 SQL Serverで既存の運用はどう変わる? • 実際の現場でよくあるOracle運用 – ケース1:空き領域が不足しそう。緊急で空きを作ってー。 – ケース2:実行計画を固定化したいんだけどー。 – ケース3:パフォーマンス遅延が発生。原因調査してー。
  26. 26. 26 ケース2 SQLプロファイルの適用SQLプロファイルの適用 Ver 3.0 SPMで固定化SPMで固定化 Ver 2.0 ヒント句追加ヒント句追加 Ver 1.0 実行計画を固定化したいんだけどー実行計画を固定化したいんだけどー
  27. 27. 27 プラン固定化→ヒント句追加 • SQLにヒント句を追加 – アプリケーションの改修を伴う SELECT e.empno, e.ename, d.deptno, d.dname FROM emp e, dept d WHERE e.deptno = d.deptno; SELECT /*+ use_hash(e,d) */ e.empno, e.ename, d.deptno, d.dname FROM emp e, dept d WHERE e.deptno = d.deptno; ---------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 14 | 364 | 6 (17)| 00:00:01 | | 1 | MERGE JOIN | | 14 | 364 | 6 (17)| 00:00:01 | | 2 | TABLE ACCESS BY INDEX ROWID| DEPT | 4 | 52 | 2 (0)| 00:00:01 | | 3 | INDEX FULL SCAN | PK_DEPT | 4 | | 1 (0)| 00:00:01 | |* 4 | SORT JOIN | | 14 | 182 | 4 (25)| 00:00:01 | | 5 | TABLE ACCESS FULL | EMP | 14 | 182 | 3 (0)| 00:00:01 | ---------------------------------------------------------------------------------------- --------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 14 | 364 | 6 (0)| 00:00:01 | |* 1 | HASH JOIN | | 14 | 364 | 6 (0)| 00:00:01 | | 2 | TABLE ACCESS FULL| DEPT | 4 | 52 | 3 (0)| 00:00:01 | | 3 | TABLE ACCESS FULL| EMP | 14 | 182 | 3 (0)| 00:00:01 | --------------------------------------------------------------------------- ヒント句使用前 ヒント句使用後
  28. 28. 28 プラン固定化→ヒント句追加 • Tips:別クエリの実行計画からヒント句作成 SELECT /*+ BEGIN_OUTLINE_DATA USE_NL(@"SEL$1" "E"@"SEL$1") LEADING(@"SEL$1" "D"@"SEL$1" "E"@"SEL$1") FULL(@"SEL$1" "E"@"SEL$1") FULL(@"SEL$1" "D"@"SEL$1") OUTLINE_LEAF(@"SEL$1") ALL_ROWS DB_VERSION('11.2.0.4') OPTIMIZER_FEATURES_ENABLE('11.2.0.4') IGNORE_OPTIM_EMBEDDED_HINTS END_OUTLINE_DATA */ e.empno, e.ename, d.deptno, d.dname FROM emp e, dept d WHERE e.deptno = d.deptno; EXPLAIN PLAN FOR SELECT /*+ use_nl(e,d) */ e.empno, e.ename, d.deptno, d.dname FROM emp e, dept d WHERE e.deptno = d.deptno; SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY(format => 'ADVANCED')); Outline Data ------------- /*+ BEGIN_OUTLINE_DATA USE_NL(@"SEL$1" "E"@"SEL$1") LEADING(@"SEL$1" "D"@"SEL$1" "E"@"SEL$1") FULL(@"SEL$1" "E"@"SEL$1") FULL(@"SEL$1" "D"@"SEL$1") OUTLINE_LEAF(@"SEL$1") ALL_ROWS DB_VERSION('11.2.0.4') OPTIMIZER_FEATURES_ENABLE('11.2.0.4') IGNORE_OPTIM_EMBEDDED_HINTS END_OUTLINE_DATA */ --------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 82 | 4510 | 26 (0)| 00:00:01 | | 1 | NESTED LOOPS | | 82 | 4510 | 26 (0)| 00:00:01 | | 2 | TABLE ACCESS FULL| DEPT | 82 | 1804 | 2 (0)| 00:00:01 | |* 3 | TABLE ACCESS FULL| EMP | 1 | 33 | 0 (0)| 00:00:01 | --------------------------------------------------------------------------- 固定化したいクエリをExplain Plan Forで実行 ヒント句が画面に出力 ヒント句をクエリに指定
  29. 29. 29 プラン固定化→SPM • SPMによる固定化 – SPM(SQL Plan Management)とは? • SQLの実行計画を記録し、実行計画を管理。固定化も可能 • 過去に実行された実行計画を固定化することも可能 SPMで管理されてい るSQL 固定化された実行計画
  30. 30. 30 • 過去に実行された実行計画の固定化 プラン固定化→SPM 過去に実行されたSQLを検索 作成したSQLチューニ ングセットを指定 SQLチューニングセッ トを作成 SPMで該当のSQLチューニングセットを指定
  31. 31. 31 プラン固定化→SQLプロファイル • SQLプロファイルによる固定化 – SQLプロファイルとは? • チューニングアドバイザで作成された実行計画 • 適用することで、実行計画が固定化 チューニングアドバイザの結果 SQLプロファイル適 用後の効果 (8.87%) SQLプロファイル作成
  32. 32. 32 プラン固定化→SQLプロファイル • Tips:ある期間の全クエリに対するアドバイス 過去24時間のAWR スナップショット ある期間のSQLをSQLチューニングセットとして作成 SQLチューニングセットに対するアドバイザ実行 該当期間の全てのSQLに対する効果 改善前:2,888秒 改善後:2,409秒
  33. 33. 33 ケース2(SQL Serverの場合) Ver 3.0Ver 2.0Ver 1.0 ヒント句追加 クエリストアで強制 N/A(推奨値の表示の み) SQLプロファイルの適用SQLプロファイルの適用SPMで固定化SPMで固定化ヒント句追加ヒント句追加 実行計画を固定化したいんだけどー実行計画を固定化したいんだけどー
  34. 34. 34 プラン固定化→ヒント句追加 • ヒント句の追加 SELECT e.empno, e.ename, d.deptno, d.dname FROM emp e, dept d WHERE e.deptno = d.deptno; SELECT e.empno, e.ename, d.deptno, d.dname FROM emp e inner hash join dept d ON e.deptno = d.deptno;
  35. 35. 35 プラン固定化→ヒント句追加 • 別クエリの実行プランを適用 SQLに、Option(USE PLAN N’XML’)を追加することで、 左記の実行プランで実行さ れる SQLの実行プランをXMLに保存 実行プラン(XML) 実行プランの固定化
  36. 36. 36 • クエリストアからプランを強制 – クエリストアとは? • クエリのパフォーマンス情報を収集、分析し、クエリのパフォーマンスを管理 • 実行プランの強制が可能 遅いときの 実行プラン 右上で選択した プランを強制 速いときの 実行プラン プラン固定化→クエリストアで固定化 クエリストア(リソースを消費するクエリの上位)
  37. 37. 37 プラン固定化→アドバイザ機能(のみ) • アドバイザ機能 – データベースエンジンチューニングアドバイザー SQLで右クリックし、データ ベースエンジンチューニング アドバイザーを起動 推奨インデックス の定義が表示され る 予想向上率
  38. 38. 38 • アドバイザ機能 – 不足しているインデックス プラン固定化→アドバイザ機能(のみ) インデックスを作成す ると性能が向上する可 能性がある
  39. 39. 39 プラン固定化→アドバイザ機能(のみ) • 不足しているインデックス一覧の出力 – dm_db_missing_index_detailsで参照可能 不足しているイン デックスに指定す る列名
  40. 40. 40 ケース2 まとめ Ver 3.0Ver 2.0Ver 1.0 ヒント句追加 クエリストアで強制 N/A(推奨値の表示の み) SQLプロファイルの適用SQLプロファイルの適用SPMで固定化SPMで固定化ヒント句追加ヒント句追加 実行計画を固定化したいんだけどー実行計画を固定化したいんだけどー
  41. 41. 41 SQL Serverで既存の運用はどう変わる? • 実際の現場でよくあるOracle運用 – ケース1:空き領域が不足しそう。緊急で空きを作ってー。 – ケース2:実行計画を固定化したいんだけどー。 – ケース3:パフォーマンス遅延発生。原因調査してー。
  42. 42. 42 ケース3 SQLモニタリングで調査SQLモニタリングで調査 Ver 3.0 EMで調査EMで調査 Ver 2.0 Statspackで調査Statspackで調査 Ver 1.0 パフォーマンス遅延発生。原因調査してー。パフォーマンス遅延発生。原因調査してー。
  43. 43. 43 パフォーマンス遅延→Statspackで調査 • Statspackを使用した調査 – パフォーマンス問題発生時のStatspackレポートを取得 – 正常時と比較して調査 • どのクエリが遅延しているか? • 問題発生時にしかないクエリはないか? • 何の待機が増加しているか? • 全クエリが遅延してないか?
  44. 44. 44 • Enterprise Managerのパフォーマンス情報を調査 – トップアクティビティ→SQLの詳細で調査 該当時間帯にど のクエリが遅い か? 該当クエリの待機を確認。 ロック待ち?I/O?CPU? パフォーマンス遅延→EMで調査
  45. 45. 45 • ASHレポートやAWRSQLレポートを使用した調査 パフォーマンス遅延→EMで調査
  46. 46. 46 • SQLモニタリング – リアルタイムでクエリの負荷状況を確認可能 – クエリ実行中の場合、進行状況も表示 クエリの進行状況 完了時間も表示 パフォーマンス遅延→SQLモニタリングで調査
  47. 47. 47 ケース3(SQL Serverの場合) SQLモニタリングで調査SQLモニタリングで調査 Ver 3.0 EMで調査EMで調査 Ver 2.0 Statspackで調査Statspackで調査 Ver 1.0 パフォーマンスデータコ レクションで調査 クエリストアで調査 パフォーマンス遅延発生。原因調査してー。パフォーマンス遅延発生。原因調査してー。 N/A(利用状況モニター)
  48. 48. 48 パフォーマンス遅延→パフォーマンス データコレクションで調査 • パフォーマンスデータコレクションによる調査 – パフォーマンスデータコレクションとは? • データベースの稼働統計 • SQL Serverの待機やOSリソースの情報収集 • 過去データも遡って確認可能
  49. 49. 49 • クエリ統計でクエリの詳細を調査 該当時間帯にど のクエリが遅い か? SQLの待機詳細 パフォーマンス遅延→パフォーマンス データコレクションで調査 クエリ統計
  50. 50. 50 • クエリストアによる調査 – クエリストアとは? • 実行されたクエリの情報を収集、分析可能 • クエリの遅延原因の分析 リソースを消費する クエリの上位 全体のリソース消費量 追跡したクエリ 低下したクエリ パフォーマンス遅延→クエリストアで調査
  51. 51. 51 • 過去1時間の間に低下した上位25のクエリ 遅延が発生した クエリ 遅いときの実行 プラン パフォーマンス遅延→クエリストアで調査 速いときの実行 プラン
  52. 52. 52 • SQLモニター – リアルタイムの接続状況を確認可能 – 遅延しているクエリ等の抽出は可能 – クエリ実行中の完了時間等は確認できず パフォーマンス遅延→SQLモニター
  53. 53. 53 ケース3 まとめ SQLモニタリングで調査SQLモニタリングで調査 Ver 3.0 EMで調査EMで調査 Ver 2.0 Statspackで調査Statspackで調査 Ver 1.0 パフォーマンスデータコ レクションで調査 クエリストアで調査 パフォーマンス遅延発生。原因調査してー。パフォーマンス遅延発生。原因調査してー。 N/A(利用状況モニター)
  54. 54. 54 まとめまとめ
  55. 55. 55 • Oracle脳の運用はSQL Serverでも応用できる – RDBMSなので、考え方は同じ • ただし、一部の機能はOracleにしかない – 自動データ最適化やSQLプロファイル、SQLモニタリングなど – 使い込んでると運用にインパクト • Oracleのノウハウをその他のDBへ まとめ
  56. 56. 56 無断転載を禁ず この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。 株式会社インサイトテクノロジーは本書の内容に関していかなる保証もしません。また、本書の内容に関連したいかな る損害についても責任を負いかねます。 本書で使用している製品やサービス名の名称は、各社の商標または登録商標です。

×