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オプションは当たり前・最新の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

例えば・・・

自動データ最適化の使用自動データ最適化の使用

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 Support無しで終了

– Oracleのサポートライセンス• 毎年2%ずつ上昇（更新時調整率） 。

• ボディーブローのように効いてくる。

– 2020年12月に11gR2のExtended Support終了• まだ先の話だが、アプリの改修も考えるとそろそろ動き出す時期？

10

SQL Serverへの移行？

• 移行にまつわる背景 その２

– ハードスペック向上• SSDや大容量メモリなどDBの性能に大きく影響

• CPU数の増加はライセンスに影響も。。。

– MicrosoftのVS Oracle施策• Oracleからの移行でライセンス無料

• Linux版SQL Serverのリリース

– その他要因• ビッグデータによるデータ量の増加

• クラウドへの移行の加速

11

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

12

SQL Serverで既存の運用はどう変わる？

• 実際の現場でよくあるOracle運用

– ケース１：空き領域が不足しそう。緊急で空きを作ってー。

– ケース２：実行計画を固定化したいんだけどー。

– ケース３：パフォーマンス遅延が発生。原因調査してー。

OracleとSQL Server でどこがどう違うのか？OracleとSQL Server でどこがどう違うのか？

13

SQL Serverで既存の運用はどう変わる？

• 実際の現場でよくあるOracle運用

– ケース１：空き領域が不足しそう。緊急で空きを作ってー。

– ケース２：実行計画を固定化したいんだけどー。

– ケース３：パフォーマンス遅延が発生。原因調査してー。

14

ケース１

自動データ最適化の使用自動データ最適化の使用

Ver 3.0

セグメントアドバイザの推奨対応セグメントアドバイザの推奨対応

Ver 2.0

不要データの削除不要データの削除

Ver 1.0

空き領域が不足しそう。緊急で空きを作ってー。空き領域が不足しそう。緊急で空きを作ってー。

15

空き領域不足→不要なデータの削除

• 不要なテーブル/データの削除

– よくあるゴミテーブルの削除• Ex)

– EMP_BK

– EMP_20160715

– よくあるごみデータの削除• deleted_flg=1のデータ

– よくある過去データ削除• 保持期限が過ぎたデータ

• 過去パーティションや履歴テーブル等のデータ

– テーブルやインデックスの再構築• 圧縮済みデータの再圧縮等

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

空き領域不足→セグメントアドバイザ

• セグメントアドバイザの使用

– セグメントアドバイザとは？• 再生可能な領域があるセグメントを特定

• 定期的に自動実行（必要時に実行することも可）

• 圧縮、縮小、再構築などのアドバイスを実施。サイズの縮小を検討。

18

空き領域不足→自動データ最適化

• 自動データ最適化（ADO）

– 自動データ最適化（Automatic Data Optimization）とは？• アクセスがないデータをOracleが自動で圧縮

• ポリシーを作成し、そのポリシーに沿って自動圧縮

テーブルA（圧縮前） テーブルA（圧縮後）

空きブロックが増加圧縮前：12ブロック圧縮後：18ブロック

Ex)１年以上更新がなかった行（ブロック）を圧縮

１週間以下１週間～１年１年以上

19

ケース１（SQL Serverの場合）

自動データ最適化の使用自動データ最適化の使用

Ver 3.0

セグメントアドバイザの推奨対応セグメントアドバイザの推奨対応

Ver 2.0

不要データの削除不要データの削除

Ver 1.0

不要データの削除 標準レポートの使用アドバイザの使用

空き領域が不足しそう。緊急で空きを作ってー。空き領域が不足しそう。緊急で空きを作ってー。

N/A

20

空き領域不足→不要なデータの削除

• 不要なデータの削除

– 不要なテーブルの削除はOracleと同じ

– 未使用インデックスの抽出• 「インデックスの使用状況の統計」レポートで確認可能

• インスタンス起動以降の統計

参照無し

21

空き領域不足→アドバイザ

• アドバイザ（断片化）

– インデックスの物理統計レポートで確認可能• 「推奨されている操作」にアドバイスが記載

推奨する操作のアドバイス

22

空き領域不足→アドバイザ

• アドバイザ（圧縮）

– 圧縮による効果を確認

• sp_estimate_data_compression_savingsの使用

– インデックス毎に圧縮率を測定

– インスタンス起動以降の統計

USE TPCCGOEXEC sp_estimate_data_compression_savings 'dbo', 'CUSTOMER', NULL, NULL, ‘PAGE' ;GO

Ex)TPCCデータベースのCUSTOMER表をページ圧縮で分析

23

空き領域不足→×自動データ最適化

• 自動データ最適化

→SQL Serverに同等の機能はない。。。

– 他にSQL Serverでできる空き領域確保• 列ストアインデックスの使用

– その他のインデックスが削除できる場合がある

24

ケース１ まとめ

自動データ最適化の使用自動データ最適化の使用

Ver 3.0

セグメントアドバイザの推奨対応セグメントアドバイザの推奨対応

Ver 2.0

不要データの削除不要データの削除

Ver 1.0

不要データの削除 標準レポートの使用アドバイザの使用

空き領域が不足しそう。緊急で空きを作ってー。空き領域が不足しそう。緊急で空きを作ってー。

N/A

25

SQL Serverで既存の運用はどう変わる？

• 実際の現場でよくあるOracle運用

– ケース１：空き領域が不足しそう。緊急で空きを作ってー。

– ケース２：実行計画を固定化したいんだけどー。

– ケース３：パフォーマンス遅延が発生。原因調査してー。

26

ケース２

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.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

プラン固定化→ヒント句追加

• Tips：別クエリの実行計画からヒント句作成

SELECT/*+

BEGIN_OUTLINE_DATAUSE_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_ROWSDB_VERSION('11.2.0.4')OPTIMIZER_FEATURES_ENABLE('11.2.0.4')IGNORE_OPTIM_EMBEDDED_HINTSEND_OUTLINE_DATA

*/e.empno,e.ename,d.deptno,d.dname

FROMemp e,dept d

WHEREe.deptno = d.deptno;

EXPLAIN PLAN FOR SELECT /*+ use_nl(e,d) */

e.empno,e.ename,d.deptno,d.dname

FROMemp e,dept d

WHEREe.deptno = d.deptno;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY(format => 'ADVANCED'));

Outline Data-------------

/*+BEGIN_OUTLINE_DATAUSE_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_ROWSDB_VERSION('11.2.0.4')OPTIMIZER_FEATURES_ENABLE('11.2.0.4')IGNORE_OPTIM_EMBEDDED_HINTSEND_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

プラン固定化→SPM

• SPMによる固定化

– SPM（SQL Plan Management）とは？

• SQLの実行計画を記録し、実行計画を管理。固定化も可能

• 過去に実行された実行計画を固定化することも可能

SPMで管理されているSQL

固定化された実行計画

30

• 過去に実行された実行計画の固定化

プラン固定化→SPM

過去に実行されたSQLを検索

作成したSQLチューニングセットを指定

SQLチューニングセットを作成

SPMで該当のSQLチューニングセットを指定

31

プラン固定化→SQLプロファイル

• SQLプロファイルによる固定化

– SQLプロファイルとは？

• チューニングアドバイザで作成された実行計画

• 適用することで、実行計画が固定化

チューニングアドバイザの結果SQLプロファイル適用後の効果（8.87%）

SQLプロファイル作成

32

プラン固定化→SQLプロファイル

• Tips：ある期間の全クエリに対するアドバイス

過去２４時間のAWR

スナップショット

ある期間のSQLをSQLチューニングセットとして作成

SQLチューニングセットに対するアドバイザ実行

該当期間の全てのSQLに対する効果

改善前：2,888秒改善後：2,409秒

33

ケース２（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

e.empno,

e.ename,

d.deptno,

d.dname

FROM

emp e inner hash join

dept d

ON

e.deptno = d.deptno;

35

プラン固定化→ヒント句追加

• 別クエリの実行プランを適用

SQLに、Option(USE PLAN

N’XML’)を追加することで、左記の実行プランで実行される

SQLの実行プランをXMLに保存

実行プラン（XML）

実行プランの固定化

36

• クエリストアからプランを強制

– クエリストアとは？• クエリのパフォーマンス情報を収集、分析し、クエリのパフォーマンスを管理

• 実行プランの強制が可能

遅いときの実行プラン

右上で選択したプランを強制

速いときの実行プラン

プラン固定化→クエリストアで固定化

クエリストア（リソースを消費するクエリの上位）

37

プラン固定化→アドバイザ機能(のみ)

• アドバイザ機能

– データベースエンジンチューニングアドバイザー

SQLで右クリックし、データベースエンジンチューニングアドバイザーを起動

推奨インデックスの定義が表示される

予想向上率

38

• アドバイザ機能

– 不足しているインデックス

プラン固定化→アドバイザ機能(のみ)

インデックスを作成すると性能が向上する可能性がある

39

プラン固定化→アドバイザ機能(のみ)

• 不足しているインデックス一覧の出力– dm_db_missing_index_detailsで参照可能

不足しているインデックスに指定する列名

40

ケース２ まとめ

Ver 3.0Ver 2.0Ver 1.0

ヒント句追加 クエリストアで強制 N/A（推奨値の表示のみ）

SQLプロファイルの適用SQLプロファイルの適用SPMで固定化SPMで固定化ヒント句追加ヒント句追加

実行計画を固定化したいんだけどー実行計画を固定化したいんだけどー

41

SQL Serverで既存の運用はどう変わる？

• 実際の現場でよくあるOracle運用

– ケース１：空き領域が不足しそう。緊急で空きを作ってー。

– ケース２：実行計画を固定化したいんだけどー。

– ケース３：パフォーマンス遅延発生。原因調査してー。

42

ケース３

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

ケース３（SQL Serverの場合）

SQLモニタリングで調査SQLモニタリングで調査

Ver 3.0

EMで調査EMで調査

Ver 2.0

Statspackで調査Statspackで調査

Ver 1.0

パフォーマンスデータコレクションで調査

クエリストアで調査

パフォーマンス遅延発生。原因調査してー。パフォーマンス遅延発生。原因調査してー。

N/A(利用状況モニター)

48

パフォーマンス遅延→パフォーマンスデータコレクションで調査

• パフォーマンスデータコレクションによる調査

– パフォーマンスデータコレクションとは？

• データベースの稼働統計

• SQL Serverの待機やOSリソースの情報収集

• 過去データも遡って確認可能

49

• クエリ統計でクエリの詳細を調査

該当時間帯にどのクエリが遅いか？

SQLの待機詳細

パフォーマンス遅延→パフォーマンスデータコレクションで調査

クエリ統計

50

• クエリストアによる調査

– クエリストアとは？

• 実行されたクエリの情報を収集、分析可能

• クエリの遅延原因の分析

リソースを消費するクエリの上位

全体のリソース消費量

追跡したクエリ

低下したクエリ

パフォーマンス遅延→クエリストアで調査

51

• 過去１時間の間に低下した上位２５のクエリ

遅延が発生したクエリ 遅いときの実行

プラン

パフォーマンス遅延→クエリストアで調査

速いときの実行プラン

52

• SQLモニター

– リアルタイムの接続状況を確認可能

– 遅延しているクエリ等の抽出は可能

– クエリ実行中の完了時間等は確認できず

パフォーマンス遅延→SQLモニター

53

ケース３ まとめ

SQLモニタリングで調査SQLモニタリングで調査

Ver 3.0

EMで調査EMで調査

Ver 2.0

Statspackで調査Statspackで調査

Ver 1.0

パフォーマンスデータコレクションで調査

クエリストアで調査

パフォーマンス遅延発生。原因調査してー。パフォーマンス遅延発生。原因調査してー。

N/A(利用状況モニター)

54

まとめまとめ

55

• Oracle脳の運用はSQL Serverでも応用できる

– RDBMSなので、考え方は同じ

• ただし、一部の機能はOracleにしかない

– 自動データ最適化やSQLプロファイル、SQLモニタリングなど

– 使い込んでると運用にインパクト

• Oracleのノウハウをその他のDBへ

まとめ

56

無断転載を禁ず

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