
- Oracle Cloud
- Oracle Database
Oracle Cloud VMware SolutionでのVMware HCX環境構築手順(後編)
前回の記事でOCVS)でHCXを利用するための前提となる手順の前半をお伝えしました。本記事では後続の手順であるサービスメッシュ作成・L2延伸手順を記載し、仮想マシンを移行できる状態、つまりHCX環境の構築完了までを説明します。
|
【Oracle SE2】CPUスレッド数制限の動作検証結果~その1~ より、SE2のCPUスレッド数制限はResource Managerで制御されることがわかりました。今回は同一サーバ内で複数のデータベースが存在する場合に、CPUスレッドがどのように制御されるか検証しましたので、その結果を紹介します。
Oracle JapanのFAQ"
Oracle Database Standard Edition 2で制限される「CPUスレッド」とは何ですか?
"には、スレッド数制限はデータベース単位で行われ、各データベースごとに使用するCPUスレッドが16(RACの場合は8)までに制限されると記載されています。
"各データベースごとに制限される"という点について「1つのデータベースで制限を超えても、本当に他のデータベースのセッションには影響がないのか」というお問い合わせをいただきましたので、検証結果を紹介します。
検証環境は動作検証結果~その1~と同じ、ハイパースレッドを有効にした32CPUスレッドあるサーバを使用します。データベースを3つ構築して以下2パターンで検証しています。
【検証 1】全てのデータベースで制限内
CPUを使用する処理を行うセッションを12:12:12で実行
【検証 2】1つのデータベースだけ制限超え
CPUを使用する処理を行うセッションを24:12:12で実行
3つのデータベースでそれぞれ12セッションずつCPUを使用する処理を実行します。各データベースで16CPUスレッドの制限内のためResource Managerで制御されないことが期待される動作です。しかし、サーバに搭載しているCPUスレッド数を超えているためどのように動作するのかがポイントです。
早速、各データベースで12セッションずつCPUを使用する処理を行います。
▲[DB1]12セッション時のV$SESSION |
▲[DB2]12セッション時のV$SESSION |
▲[DB3]12セッション時のV$SESSION |
期待したとおり「resmgr:cpu quantum」の待機イベントは発生せず、Resource Managerでの制御は行われませんでした。このタイミングのmpstatからは、全てのCPU使用率が100%(99.00以上≒100%)でCPUリソースが全て使えている状況が確認できます。
▲各データベースで12セッションがCPUを使用している際のmpstat |
このことより、各データベースでCPUを使用するセッションが16以内であれば、サーバに搭載しているCPUスレッド数を超えて同時にCPUを使用するセッションがあっても、Resource Managerによる制御はされないことがわかりました。
ここからが本番です。3つのデータベースの内、1つのデータベースでCPUを使用する処理を行うセッションを24まで増やします。残りのデータベースは12セッションのままで制限内のため、制限を超えたデータベースのみResource Managerで制御されることが期待される動作です。
24セッションがCPUを使用する処理を行っているデータベースでは16CPUスレッドの制限を超えたため、Resource Managerによって制御されています。残りの2つのデータベースではそれぞれ12セッションがCPUを使用する処理を行っていますが、制限内のため影響はありませんでした。
▲[DB1]24セッション時のV$SESSION |
▲[DB2]12セッション時のV$SESSION |
▲[DB3]12セッション時のV$SESSION |
この状態でmpstatを確認すると、全てのスレッドが使用率が100%(99.00以上≒100%)でCPUリソースが全て使えている状況が確認できます。
▲CPUを使用するセッションが24:12:12の際のmpstat |
こちらも期待通りの結果です。Resource Managerでの制御は制限を超えたデータベースに対してのみ行われています。
【検証 1】、【検証 2】の結果より、データベースごとに16CPUスレッドの制限が行われており、特定のデータベースで制限を超えた場合でも、他のデータベースのCPUスレッド数制限には影響がないことがわかりました。
データベース(Resource Manager)としての制限は検証結果のとおりですが、移行を検討する際には従来のSEではソケット数は最大4つ(OSにより異なる)までの制限が、SE2で「最大2つ」に変更されていることに注意が必要です。
SE2のソケット数制限 |
SE2のCPUスレッド数制限 |
既存のSE環境(12.1.0.1まで)で同一サーバ内に複数のデータベースを構築されている場合には、移行前のCPUリソースの使用状況や今後の拡張を考慮した上で移行先のライセンスを検討する必要があります。ソケット数制限によってサーバに搭載するCPUスレッド数を下げざるを得ないケースがあるため、安易にSE2に移行してしまうと【検証 1】のようにデータベースとしては制御されなくてもCPUリソースを使い果たしてしまい期待した性能を得ることができないかもしれません。
制限の内容を見ると、SE1/SEからの移行先としてはSE2ではなく、拡張性の高いOracle CloudやOracle Database Applianceを…という意図が見えなくもないですね。SE1/SE環境からの移行先でお困りのお客様はぜひ一度ご相談ください。
【Oracle SE2】CPUスレッド数制限の動作検証結果は次回が最終回です。RAC環境での動作をご紹介します。
![]() |
---|
サービス事業部 サポートセンター
2007年にアシスト入社後、Oracle Databaseのサポート業務に従事、現在はサポート対応を行いながら、データベースの運用で発生するトラブルを未然に防げるよう、サポートセンターに蓄積されているノウハウを社内外に伝える活動を行っている。
■本記事の内容について
本記事に示した定義及び条件は変更される場合があります。あらかじめご了承ください。
■商標に関して
・Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
文中の社名、商品名等は各社の商標または登録商標である場合があります。
前回の記事でOCVS)でHCXを利用するための前提となる手順の前半をお伝えしました。本記事では後続の手順であるサービスメッシュ作成・L2延伸手順を記載し、仮想マシンを移行できる状態、つまりHCX環境の構築完了までを説明します。
23aiで読取り専用モードの機能が拡張されました。ユーザー/セッション単位で読み書き可能/読取り専用モードの使い分けができるようになり、今まで以上にメンテナンス操作やアプリケーションからの接続の権限管理が柔軟にできるようになっています。
Oracle Database 23aiの新機能であるロックフリー予約により、トランザクション同士がブロックすることなく、効率的なデータ更新を実現できます。本記事では、ロックフリー予約の使い方をご紹介します。