【Oracle Database 12c】Oracleライセンス「SE2」検証 CPUスレッド数制限、“同一サーバ内に複数のDBがある場合”はどう動くのか：データベースサポート最前線の現場から（13）（2/2 ページ）

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

検証2　1つだけ制限超え／CPUを使用する処理を行うセッションを24：12：12で実行する

　ここからが本番です。3つのデータベースのうち、データベース 1だけCPUスレッド数の制限を超える「24」まで増やしてみます。制限を超えた「データベース 1のみ」Resource Managerで制御される動きになるかどうかを検証します（画像5〜7）。

画像5　データベース 1：24セッション時のV$SESSION

画像6　データベース 2：12セッション時のV$SESSION

画像7　データベース 3：12セッション時のV$SESSION

　データベース 1では、16スレッドの制限を超える24セッションで同時処理を行っているので、その通りにResource Managerによってリソースが制御されました。その一方で、制限を超えていない残り2つのデータベースでは「影響なし」でした。

　なお同時点の「mpstat」を確認すると、全てのCPU使用率がほぼ100％（99.00以上≒100％）で、CPUリソースを全て使えている状況を確認できました（画像8）。

画像8　CPUを使うセッションが24：12：12のときの「mpstat」の結果

　こちらも期待通りの結果です。Resource Managerでの制御は「制限を超えたデータベースに対してのみ」行われます。つまり、同一サーバ内で動作する複数のデータベースのうち、どれかが制限を超えていたとしても、他のデータベースには制限の影響が及ばないことを確認できました。

「ソケット数の制限」も厳しい

　SE、SE1からSE2への移行においては、ソケット数の制限にも気を付ける必要があります。これまでのSEでは（OSによって異なりますが）「最大4つ」だったソケット数の制限が、SE2では「最大2つ」になります。ソケット数とスレッド数は、以下のように数えます（図1）。クラスタ化するOracle RAC環境では特にややこしいので注意が必要です。

図1　SE2におけるソケット数とスレッド数の数え方

　具体的には、これまでの（12.1.0.1までの）SEライセンスで、同一のサーバ内に複数のデータベースを構築している場合は、「移行前のCPUリソースの使用状況」や「今後の拡張を考慮」した上で移行先のライセンスを検討する必要があります。SE2にはソケット数の制限にも変更があることから、CPUスレッド数を下げざるを得ず、場合によってはサーバの性能を生かしきれなくなるケースがあります。安易にSE2に移行してしまうと、データベースとしては制限内だとしても、そのソケットでCPUリソースを使い果たしてしまう可能性があります。

　こういった制限などを考慮すると、SE、SE1からの移行先としては、より高機能なEnterprise Editionを拡張性高く、比較的安価に利用できる「Oracle Cloud」や「Oracle Database Appliance」が次の選択肢となってくるのではないでしょうか。

　次回は「SE2は、Oracle RAC環境ではどのように制御されるのか」を検証します。

※初出：2016年4月5日 Database Support Blog「【Oracle SE2】CPUスレッド数制限の動作検証結果〜その2〜」

筆者紹介

大野高志

株式会社アシスト サービス事業部 サポートセンター所属。2007年にアシスト入社後、Oracle Databaseのサポート業務に従事。現在はサポート業務の傍ら、未解決のトラブルを1つでも多く減らせるよう、サポートセンターに蓄積されている調査のノウハウを社内外に伝える活動を行っている。