連載
» 2017年08月02日 05時00分 UPDATE

データベースサポート最前線の現場から(13):【Oracle Database 12c】Oracleライセンス「SE2」検証 CPUスレッド数制限、“同一サーバ内に複数のDBがある場合”はどう動くのか (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)。

photo 画像1 データベース 1:12セッション時のV$SESSION
photo 画像2 データベース 2:12セッション時のV$SESSION
photo 画像3 データベース 3:12セッション時のV$SESSION

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

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

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

       1|2 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

この記事に関連するホワイトペーパー

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。