【Oracle Database 12c】Oracleライセンス「SE2」検証 CPUスレッド数制限はどんな仕組みで制御されるのか：データベースサポート最前線の現場から（12）（1/2 ページ）

データベース管理システムの運用でトラブルが発生したらどうするか。データベースサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は、Oracle Database 12c（12.1）で採用されたライセンス形態「Standard Edition 2（以下、SE2）」の機能制限がどのように行われるのかを検証します。

[大野高志，株式会社アシスト]

※本連載は、アシストのデータベースサポートスペシャリストによる「Database Support Blog」より、提供社の許可の下、一部修正して転載するものです。

連載バックナンバー

「SE2」のCPUスレッド数制限を確かめる

　2015年9月にリリースされた「Oracle Database 12c（12.1.0.2）」以降のStandard Editionは、これまでのライセンス体系だったStandard Edition One（SE1）およびStandard Edition（SE）ではなく、新たなライセンス体系である「Standard Edition 2（SE2）」として提供されます。

• 【Oracle Database 12c】SE1／SEから、新ライセンス「SE2」への移行で注意すべきこと

　SE2への変更は、これまでのSE1／SEにはなかった以下の「CPUスレッド数の制限」が特に大きな変更内容になります。

SE2で追加された制限

1. 搭載可能CPUソケット数は「2つ」まで（全OSで共通）
2. インスタンス当たり、最大で「16CPUスレッド」までしか同時に使えない

　特に2番目の「インスタンス当たり、最大で16CPUスレッドまでしか同時に使えない」制限について、アシストのサポートセンターへ以下のような問い合わせが多く寄せられました。

• どうやって制御しているのか
• 「16セッションまで」しか同時に接続できない、ということなのか
• バックグラウンドプロセスも影響を受けるのか
• 同一サーバ内で複数のデータベースを構築している場合はどのように制御されるのか
• Oracle RAC（Oracle Real Application Clusters）ではどのように制御されるのか

　今回はこれらの疑問を解消すべく、SE2のCPUスレッド数に関わる部分を確かめてみましょう。

　検証環境は以下の通りです。

検証環境

• サーバ：HPE ProLiant DL380e Gen8（8SFF SAS RDIMMモデル）
• CPU：インテル Xeon プロセッサー E5-2470×2（2.30GHz・16コア／32スレッド）
• メモリ：128GB
• ストレージ：HPE SAS HDD（1万rpm／600GB／SC 6Gbps）×5
• OS：Red Hat Enterprise Linux 6.6
• データベース：Oracle Database 12.1.0.2 Standard Edition 2（シングルインスタンス）

検証：1スレッドで17セッション以上占有する処理を行ってみる

　下記のように「1スレッドを占有する処理」を実行します。このセッションを1つずつ増やして、制限内となる16セッション目と、制限を超えた17セッション目以降でどのように変わるのかを確認します。

declare
     foo number;
 begin
     while (1=1) LOOP
     foo := 1+1;
     end loop;
 end;
 /

「1スレッドを占有する処理」のサンプル

　まず「mpstat」を確認しましょう（画像1）。すると、16セッションまで（画像1の左）はCPUを100％使っています。対して17セッションを超えた場合（画像1の右）には、何かしらの制限が掛かり、CPUが100％で使われなくなりました。

画像1　「mpstat」を確認　左が16セッション（範囲内）時、右が20セッション（超過）時

　このセッションがどのような状態になっているのかを「V$SESSION」で確認してみます。すると、「resmgr: cpu quantum」の待機イベントで「待機」が発生していることが分かりました（画像2）。

画像2　「v$session」を確認　左が16セッション（範囲内）時、右が20セッション（超過）時

　resmgr: cpu quantumは、「Oracle Databaseリファレンス 12cリリース1（12.1）」によると、「セッションは、CPU数を割り当てるために待機しています。このイベントは、Resource Managerが使用可能で、CPU消費量を抑えている場合に発生します。この待機イベントの発生を減らすには、セッションのカレント・コンシューマ・グループに割り当てるCPUを増やします」とあります。セッションがCPUリソースを割り当てるために待機している、つまり割り当てられるCPUリソースがないときに発生します。