【Oracle Database 12c】Oracleライセンス「SE2」検証 スレッド数制限、“Oracle RAC環境”ではどのように制御されるのか：データベースサポート最前線の現場から（14）（1/2 ページ）

データベース管理システムの運用でトラブルが発生したらどうするか。データベースサポートスペシャリストが現場目線の解決Tipsをお届けします。Oracleの新ライセンス形態「Standard Edition 2」の機能制限がどのように行われるのか、今回は「Oracle RAC環境の場合のCPUスレッド数制限」を検証します。

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

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

連載バックナンバー

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

　今回はその続きとして、「スレッド数の制限は、Oracle Real Application Clusters（以下、Oracle RAC）環境ではどのように制御されるのか」を検証します。

Oracle RAC環境の片ノードのインスタンスが停止したらCPUスレッド数制限はどうなるのか

　Oracleの新ライセンス体系「SE2（Standard Edition 2）」におけるCPUスレッド数は、シングルインスタンス環境ではデータベース単位で「16」まで、Oracle RAC環境では「8」までに制限されます。

　Oracle RACは、ロードバランス（負荷分散）型のクラスタリング構成をOracle Databaseで実現し、冗長性を確保する方式です。では、2クラスタのOracle RAC構成で運用しているシステムで片方のインスタンスが停止したとしたら、他方のインスタンスのCPUスレッド数制限はどうなるのでしょう。「8」のままなのでしょうか、それともシングルインスタンスになるので「16」に変わるのでしょうか。以下の環境で検証してみましょう。

検証環境

• サーバ：IBM Power System E850
• CPU：IBM POWER 8 E850（3.72GHz・16コア／32スレッド）
• メモリ：480GB
• ストレージ：IBM Storwize V3700（1万rpm／900GB／SAS HDD）×12
• OS：IBM AIX 7.1
• ソフトウェア：Oracle Grid Infrastructure 12.1.0.2、Oracle Database 12.1.0.2 Standard Edition 2（Oracle RAC）

検証1　両ノードのインスタンスが起動した状態で、9セッションでCPUを使う処理を実行する

　まず、Oracle RAC環境ではCPUスレッドが「8」で上限に達することを確認します。前回、前々回と同様にCPUを使うセッションを増やしていくと、両ノードともセッション数が8を超えたところで「resmgr:cpu quantum」の待機イベントが発生しました。規定動作の通りです（画像1〜2）。

画像1　7セッション（制限内）時「gv$session」の結果

画像2　9セッション（制限越え）時「gv$session」の結果（「resmgr:cpu quantum」の待機イベントが発生）

検証2　片ノードのインスタンスを停止させ、9セッションでCPUを使用する処理を実行するとどうなるか

　続いて、片方のノードを停止して同様に検証してみます（画像3〜4）。

画像3　片方のノードを停止した状態で、7セッション（制限内）がCPUを使った場合

画像4　同じく、9セッション（制限越え）まで増やした場合（「resmgr:cpu quantum」の待機イベントが発生）

　7セッションならば、もちろん制限は掛かりません。しかし、制限を超える9セッションに増やすと「resmgr:cpu quantum」の待機イベントが発生しました。

　片側のノードを停止したことで、システムとしてはシングルインスタンスと同じ状態なのですが、残念ながら上限が「16」に変わるわけではありませんでした。