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

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

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

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

連載バックナンバー

　前回は、Oracle Databaseの新ライセンス体系「Standard Edition 2（SE2）」で多くのデータベース管理者が気になる、「CPUスレッド数の制限」がどう制御されているのか、その仕組みを検証しました。

　今回はその続きとして、「同一サーバ内で複数のデータベースを構築している場合はどのように制御されるのか」の検証を行います。

CPUスレッド数制限は「データベース単位」で制御される

　日本オラクルによるFAQ「Oracle Database Standard Edition 2で制限される「CPUスレッド」とは何ですか？」によると、スレッド数の制限は「データベース単位」で行われ、データベースごとに使用するCPUスレッドが16（Oracle Real Application Clustersの場合は8）までに制限されるとあります。

　制限はデータベース単位で行われます。それならば、「あるデータベースでCPUスレッド数の制限を超えてしまったとしても、本当に他のデータベースのセッションには影響がない」のでしょうか。前回と同じ検証環境へデータベースを3つ構築して、以下の2パターンを検証してみます。

検証1　全データベースで制限内／CPUを使用する処理を行うセッションを12：12：12で実行する

　3つのデータベースで、それぞれ12セッションずつCPUを使う処理を実行します。あらためて、SE2のCPUスレッド数は「16」なので、データベース単位ではResource Managerで制御されない範囲ですが、サーバ単位では合計で「24」と、制限数を超えます。この状況ではどのように動作するでしょうか（画像1〜3）。

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

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

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

　いずれのデータベースにも「resmgr:cpu quantum」の待機イベントは発生せず、Resource Managerでのスレッド制御は行われませんでした。ちなみにこの同時点の「mpstat」からは、全てのCPU使用率がほぼ100％（99.00以上≒100％）で、CPUリソースを全て使えている状況も確認できました（画像4）。

画像4　各データベースで12セッションがCPUを使用しているときの「mpstat」の結果

　これらのことから、「データベース単位」でCPUを使用するセッションが制限である「16」以内ならば、仮にサーバに搭載しているCPUスレッド数を超える数のセッションが同時に存在するとしても、Resource Managerでのスレッド制御は行われないことが分かりました。