1. Oracle脳で考える
SQL Server運用
コンサルティング事業部
内山 義夫

2. 2
Contents
• 1. Oracle脳とは？
• 2. Oracle脳によるSQL Server運用例
• 3. まとめ

3. 3
Oracle脳とは？Oracle脳とは？

4. 4
Oracle脳とは？
• Oracle脳（造語）
「データベース=Oracle」なDBA
基盤の共通化でOracleがスタンダードに
小さいシステムでSQL ServerやMySQLを少々使用

5. 5
Oracle脳の現場
インデックス追加し
ておいてー。
インデックス追加し
ておいてー。
実行計画を固定化し
たいんだけどー。
実行計画を固定化し
たいんだけどー。
1時間前のデータに
戻してー。
1時間前のデータに
戻してー。
バッチが遅延したの
で、調査してー。
バッチが遅延したの
で、調査してー。
領域が不足しそう。
なんとかしてー。
領域が不足しそう。
なんとかしてー。
障害が発生したので、
調査してー。
障害が発生したので、
調査してー。
通常運用中
障害対応中

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
例えば・・・
自動データ最適化の使用自動データ最適化の使用
Ver 3.0
セグメントアドバイザの
推奨対応
セグメントアドバイザの
推奨対応
Ver 2.0
不要データの削除不要データの削除
Ver 1.0
空き領域が不足しそう。緊急で空きを作ってー。空き領域が不足しそう。緊急で空きを作ってー。

8. 8
そんなある日
• そっと聞こえる神の声
– 次のシステムリプレイス時に別のDBに移行するかも。
– SQL Serverって基幹システムで使えるの？
– まずは、小さいシステムから移行を検討してみるか。

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
SQL Serverへの移行？
• 移行にまつわる背景 その２
– ハードスペック向上
• SSDや大容量メモリなどDBの性能に大きく影響
• CPU数の増加はライセンスに影響も。。。
– MicrosoftのVS Oracle施策
• Oracleからの移行でライセンス無料
• Linux版SQL Serverのリリース
– その他要因
• ビッグデータによるデータ量の増加
• クラウドへの移行の加速

11. 11
Oracle脳によるSQL Server運用例Oracle脳によるSQL Server運用例

12. 12
SQL Serverで既存の運用はどう変わる？
• 実際の現場でよくあるOracle運用
– ケース１：空き領域が不足しそう。緊急で空きを作ってー。
– ケース２：実行計画を固定化したいんだけどー。
– ケース３：パフォーマンス遅延が発生。原因調査してー。
OracleとSQL Server でどこがどう違うのか？OracleとSQL Server でどこがどう違うのか？

13. 13
SQL Serverで既存の運用はどう変わる？
• 実際の現場でよくあるOracle運用
– ケース１：空き領域が不足しそう。緊急で空きを作ってー。
– ケース２：実行計画を固定化したいんだけどー。
– ケース３：パフォーマンス遅延が発生。原因調査してー。

14. 14
ケース１
自動データ最適化の使用自動データ最適化の使用
Ver 3.0
セグメントアドバイザの
推奨対応
セグメントアドバイザの
推奨対応
Ver 2.0
不要データの削除不要データの削除
Ver 1.0
空き領域が不足しそう。緊急で空きを作ってー。空き領域が不足しそう。緊急で空きを作ってー。

15. 15
空き領域不足→不要なデータの削除
• 不要なテーブル/データの削除
– よくあるゴミテーブルの削除
• Ex)
– EMP_BK
– EMP_20160715
– よくあるごみデータの削除
• deleted_flg=1のデータ
– よくある過去データ削除
• 保持期限が過ぎたデータ
• 過去パーティションや履歴テーブル等のデータ
– テーブルやインデックスの再構築
• 圧縮済みデータの再圧縮等

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
空き領域不足→セグメントアドバイザ
• セグメントアドバイザの使用
– セグメントアドバイザとは？
• 再生可能な領域があるセグメントを特定
• 定期的に自動実行（必要時に実行することも可）
• 圧縮、縮小、再構築などのアドバイスを実施。サイズの縮小を検討。

18. 18
空き領域不足→自動データ最適化
• 自動データ最適化（ADO）
– 自動データ最適化（Automatic Data Optimization）とは？
• アクセスがないデータをOracleが自動で圧縮
• ポリシーを作成し、そのポリシーに沿って自動圧縮
テーブルA（圧縮前） テーブルA（圧縮後）
空きブロックが増加
圧縮前：12ブロック
圧縮後：18ブロック
Ex)
１年以上更新がなかった行（ブロック）を圧縮
１週間以下
１週間～１年
１年以上

19. 19
ケース１（SQL Serverの場合）
自動データ最適化の使用自動データ最適化の使用
Ver 3.0
セグメントアドバイザの
推奨対応
セグメントアドバイザの
推奨対応
Ver 2.0
不要データの削除不要データの削除
Ver 1.0
不要データの削除 標準レポートの使用
アドバイザの使用
空き領域が不足しそう。緊急で空きを作ってー。空き領域が不足しそう。緊急で空きを作ってー。
N/A

20. 20
空き領域不足→不要なデータの削除
• 不要なデータの削除
– 不要なテーブルの削除はOracleと同じ
– 未使用インデックスの抽出
• 「インデックスの使用状況の統計」レポートで確認可能
• インスタンス起動以降の統計
参照無し

21. 21
空き領域不足→アドバイザ
• アドバイザ（断片化）
– インデックスの物理統計レポートで確認可能
• 「推奨されている操作」にアドバイスが記載
推奨する操作のアド
バイス

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
空き領域不足→×自動データ最適化
• 自動データ最適化
→SQL Serverに同等の機能はない。。。
– 他にSQL Serverでできる空き領域確保
• 列ストアインデックスの使用
– その他のインデックスが削除できる場合がある

24. 24
ケース１ まとめ
自動データ最適化の使用自動データ最適化の使用
Ver 3.0
セグメントアドバイザの
推奨対応
セグメントアドバイザの
推奨対応
Ver 2.0
不要データの削除不要データの削除
Ver 1.0
不要データの削除 標準レポートの使用
アドバイザの使用
空き領域が不足しそう。緊急で空きを作ってー。空き領域が不足しそう。緊急で空きを作ってー。
N/A

25. 25
SQL Serverで既存の運用はどう変わる？
• 実際の現場でよくあるOracle運用
– ケース１：空き領域が不足しそう。緊急で空きを作ってー。
– ケース２：実行計画を固定化したいんだけどー。
– ケース３：パフォーマンス遅延が発生。原因調査してー。

26. 26
ケース２
SQLプロファイルの適用SQLプロファイルの適用
Ver 3.0
SPMで固定化SPMで固定化
Ver 2.0
ヒント句追加ヒント句追加
Ver 1.0
実行計画を固定化したいんだけどー実行計画を固定化したいんだけどー

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
プラン固定化→ヒント句追加
• 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
プラン固定化→SPM
• SPMによる固定化
– SPM（SQL Plan Management）とは？
• SQLの実行計画を記録し、実行計画を管理。固定化も可能
• 過去に実行された実行計画を固定化することも可能
SPMで管理されてい
るSQL
固定化された実行計画

30. 30
• 過去に実行された実行計画の固定化
プラン固定化→SPM
過去に実行されたSQLを検索
作成したSQLチューニ
ングセットを指定
SQLチューニングセッ
トを作成
SPMで該当のSQLチューニングセットを指定

31. 31
プラン固定化→SQLプロファイル
• SQLプロファイルによる固定化
– SQLプロファイルとは？
• チューニングアドバイザで作成された実行計画
• 適用することで、実行計画が固定化
チューニングアドバイザの結果
SQLプロファイル適
用後の効果
（8.87%）
SQLプロファイル作成

32. 32
プラン固定化→SQLプロファイル
• Tips：ある期間の全クエリに対するアドバイス
過去２４時間のAWR
スナップショット
ある期間のSQLをSQLチューニングセットとして作成
SQLチューニングセットに対するアドバイザ実行
該当期間の全てのSQLに対する効果
改善前：2,888秒
改善後：2,409秒

33. 33
ケース２（SQL Serverの場合）
Ver 3.0Ver 2.0Ver 1.0
ヒント句追加 クエリストアで強制 N/A（推奨値の表示の
み）
SQLプロファイルの適用SQLプロファイルの適用SPMで固定化SPMで固定化ヒント句追加ヒント句追加
実行計画を固定化したいんだけどー実行計画を固定化したいんだけどー

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
プラン固定化→ヒント句追加
• 別クエリの実行プランを適用
SQLに、Option(USE PLAN
N’XML’)を追加することで、
左記の実行プランで実行さ
れる
SQLの実行プランをXMLに保存
実行プラン（XML）
実行プランの固定化

36. 36
• クエリストアからプランを強制
– クエリストアとは？
• クエリのパフォーマンス情報を収集、分析し、クエリのパフォーマンスを管理
• 実行プランの強制が可能
遅いときの
実行プラン
右上で選択した
プランを強制
速いときの
実行プラン
プラン固定化→クエリストアで固定化
クエリストア（リソースを消費するクエリの上位）

37. 37
プラン固定化→アドバイザ機能(のみ)
• アドバイザ機能
– データベースエンジンチューニングアドバイザー
SQLで右クリックし、データ
ベースエンジンチューニング
アドバイザーを起動
推奨インデックス
の定義が表示され
る
予想向上率

38. 38
• アドバイザ機能
– 不足しているインデックス
プラン固定化→アドバイザ機能(のみ)
インデックスを作成す
ると性能が向上する可
能性がある

39. 39
プラン固定化→アドバイザ機能(のみ)
• 不足しているインデックス一覧の出力
– dm_db_missing_index_detailsで参照可能
不足しているイン
デックスに指定す
る列名

40. 40
ケース２ まとめ
Ver 3.0Ver 2.0Ver 1.0
ヒント句追加 クエリストアで強制 N/A（推奨値の表示の
み）
SQLプロファイルの適用SQLプロファイルの適用SPMで固定化SPMで固定化ヒント句追加ヒント句追加
実行計画を固定化したいんだけどー実行計画を固定化したいんだけどー

41. 41
SQL Serverで既存の運用はどう変わる？
• 実際の現場でよくあるOracle運用
– ケース１：空き領域が不足しそう。緊急で空きを作ってー。
– ケース２：実行計画を固定化したいんだけどー。
– ケース３：パフォーマンス遅延発生。原因調査してー。

42. 42
ケース３
SQLモニタリングで調査SQLモニタリングで調査
Ver 3.0
EMで調査EMで調査
Ver 2.0
Statspackで調査Statspackで調査
Ver 1.0
パフォーマンス遅延発生。原因調査してー。パフォーマンス遅延発生。原因調査してー。

43. 43
パフォーマンス遅延→Statspackで調査
• Statspackを使用した調査
– パフォーマンス問題発生時のStatspackレポートを取得
– 正常時と比較して調査
• どのクエリが遅延しているか？
• 問題発生時にしかないクエリはないか？
• 何の待機が増加しているか？
• 全クエリが遅延してないか？

44. 44
• Enterprise Managerのパフォーマンス情報を調査
– トップアクティビティ→SQLの詳細で調査
該当時間帯にど
のクエリが遅い
か？
該当クエリの待機を確認。
ロック待ち？I/O？CPU？
パフォーマンス遅延→EMで調査

45. 45
• ASHレポートやAWRSQLレポートを使用した調査
パフォーマンス遅延→EMで調査

46. 46
• SQLモニタリング
– リアルタイムでクエリの負荷状況を確認可能
– クエリ実行中の場合、進行状況も表示
クエリの進行状況
完了時間も表示
パフォーマンス遅延→SQLモニタリングで調査

47. 47
ケース３（SQL Serverの場合）
SQLモニタリングで調査SQLモニタリングで調査
Ver 3.0
EMで調査EMで調査
Ver 2.0
Statspackで調査Statspackで調査
Ver 1.0
パフォーマンスデータコ
レクションで調査
クエリストアで調査
パフォーマンス遅延発生。原因調査してー。パフォーマンス遅延発生。原因調査してー。
N/A(利用状況モニター)

48. 48
パフォーマンス遅延→パフォーマンス
データコレクションで調査
• パフォーマンスデータコレクションによる調査
– パフォーマンスデータコレクションとは？
• データベースの稼働統計
• SQL Serverの待機やOSリソースの情報収集
• 過去データも遡って確認可能

49. 49
• クエリ統計でクエリの詳細を調査
該当時間帯にど
のクエリが遅い
か？
SQLの待機詳細
パフォーマンス遅延→パフォーマンス
データコレクションで調査
クエリ統計

50. 50
• クエリストアによる調査
– クエリストアとは？
• 実行されたクエリの情報を収集、分析可能
• クエリの遅延原因の分析
リソースを消費する
クエリの上位
全体のリソース消費量
追跡したクエリ
低下したクエリ
パフォーマンス遅延→クエリストアで調査

51. 51
• 過去１時間の間に低下した上位２５のクエリ
遅延が発生した
クエリ 遅いときの実行
プラン
パフォーマンス遅延→クエリストアで調査
速いときの実行
プラン

52. 52
• SQLモニター
– リアルタイムの接続状況を確認可能
– 遅延しているクエリ等の抽出は可能
– クエリ実行中の完了時間等は確認できず
パフォーマンス遅延→SQLモニター

53. 53
ケース３ まとめ
SQLモニタリングで調査SQLモニタリングで調査
Ver 3.0
EMで調査EMで調査
Ver 2.0
Statspackで調査Statspackで調査
Ver 1.0
パフォーマンスデータコ
レクションで調査
クエリストアで調査
パフォーマンス遅延発生。原因調査してー。パフォーマンス遅延発生。原因調査してー。
N/A(利用状況モニター)

54. 54
まとめまとめ

55. 55
• Oracle脳の運用はSQL Serverでも応用できる
– RDBMSなので、考え方は同じ
• ただし、一部の機能はOracleにしかない
– 自動データ最適化やSQLプロファイル、SQLモニタリングなど
– 使い込んでると運用にインパクト
• Oracleのノウハウをその他のDBへ
まとめ

56. 56
無断転載を禁ず
この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。
株式会社インサイトテクノロジーは本書の内容に関していかなる保証もしません。また、本書の内容に関連したいかな
る損害についても責任を負いかねます。
本書で使用している製品やサービス名の名称は、各社の商標または登録商標です。