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

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

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

検証結果：「Resource Manager」がスレッドを制御している

　これらの検証から「インスタンス当たり、最大で16CPUスレッドまでしか同時に使えない」ようにする制限は、「Resource Manager」が掛けていることが分かりました。Resource ManagerはこれまでのSEで利用可能だった機能ですが、内部的な制御のためにSE2でも使われているようです。

　20セッション時（画像2の右）は、SE2の制限を超える17スレッド以上を使用しているわけですが、内部の動きとしては、16スレッドを超えるとそれ以降は処理を行わなくなるのではなく、「同時に使用するスレッドが16まで」になるように「resmgr:cpu quantum」で待機させながら調節しているのです。ちなみに、Resource Managerはスレッド数の上限に達してから動作するため、15セッションまではresmgr:cpu quantumの待機イベントは発生しませんでした。

　続いてバックグラウンドプロセスはどうでしょう。Resource Managerによる制御であることを踏まえて、バックグラウンドプロセスの「V$SESSION.RESOURCE_CONSUMER_GROUP」を確認してみます（画像3）。

画像3　「V$SESSION.RESOURCE_CONSUMER_GROUP」を確認（v$sessionを抜粋）

　一般ユーザーのセッションは「OTHER_GROUPS」ですが、バックグラウンドプロセスは「_ORACLE_BACKGROUND_GROUP_」という、異なるグループに所属していました。これまでの検証結果で「ユーザーセッションのみ」で16スレッドを占有できていることから、バックグラウンドプロセスにおいては「スレッド数制限の適用外」となるようです。

　ちなみに、初期化パラメータ「RESOURCE_MANAGER_PLAN」などの変更でこの制限を無効にできないかを試してみましたが、もちろんダメでした（当たり前ですが）。

　ちなみに「resmgr: cpu quantum」は、従来のSE、SE1でも自動オプティマイザ統計収集の時などに出るケースはありましたが、ともあれ「V$SESSION」や「STATSPACK」などを使ってパフォーマンス監視をしている人は、Oracle Database 12c SE2の移行後に「resmgr: cpu quantum」の待機イベントを発見してドキッとしてしまわないように、Resource Managerで制御されることを前もって認識しておく必要がありそうです。

　次回はその他の疑問となる「同一サーバ内で複数のデータベースを構築している場合はどのように制御されるのか」についてを検証します。

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

筆者紹介

大野高志

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