- Oracle Database
【Oracle Database】FAQで安定運用に貢献!サポートセンターのナレッジ公開の取り組み
アシストオラクルサポートセンターが公開しているFAQは、仕様に関するQAやエラー発生時の対処方法などはもちろん、不具合情報や障害発生時の情報取得方法といった安定運用に役立つ内容も扱っています。そのFAQをどのように作成しているのか、サポートセンターの取り組みをご紹介します。
|
【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を使用する処理を行います。
|
|
|
期待したとおり「resmgr:cpu quantum」の待機イベントは発生せず、Resource Managerでの制御は行われませんでした。このタイミングのmpstatからは、全てのCPU使用率が100%(99.00以上≒100%)でCPUリソースが全て使えている状況が確認できます。
|
このことより、各データベースでCPUを使用するセッションが16以内であれば、サーバに搭載しているCPUスレッド数を超えて同時にCPUを使用するセッションがあっても、Resource Managerによる制御はされないことがわかりました。
ここからが本番です。3つのデータベースの内、1つのデータベースでCPUを使用する処理を行うセッションを24まで増やします。残りのデータベースは12セッションのままで制限内のため、制限を超えたデータベースのみResource Managerで制御されることが期待される動作です。
24セッションがCPUを使用する処理を行っているデータベースでは16CPUスレッドの制限を超えたため、Resource Managerによって制御されています。残りの2つのデータベースではそれぞれ12セッションがCPUを使用する処理を行っていますが、制限内のため影響はありませんでした。
|
|
|
この状態でmpstatを確認すると、全てのスレッドが使用率が100%(99.00以上≒100%)でCPUリソースが全て使えている状況が確認できます。
|
こちらも期待通りの結果です。Resource Managerでの制御は制限を超えたデータベースに対してのみ行われています。
【検証 1】、【検証 2】の結果より、データベースごとに16CPUスレッドの制限が行われており、特定のデータベースで制限を超えた場合でも、他のデータベースのCPUスレッド数制限には影響がないことがわかりました。
データベース(Resource Manager)としての制限は検証結果のとおりですが、移行を検討する際には従来のSEではソケット数は最大4つ(OSにより異なる)までの制限が、SE2で「最大2つ」に変更されていることに注意が必要です。
|
|
既存の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. またはその関連会社の商標です。
文中の社名、商品名等は各社の商標または登録商標である場合があります。
アシストオラクルサポートセンターが公開しているFAQは、仕様に関するQAやエラー発生時の対処方法などはもちろん、不具合情報や障害発生時の情報取得方法といった安定運用に役立つ内容も扱っています。そのFAQをどのように作成しているのか、サポートセンターの取り組みをご紹介します。
Oracle Databaseのバージョン11g R2、12g.R1、12g.R2は既にすべてのメーカーサポートが終了しています。OCIのBase Database Serviceでも2024年1月中旬ころから11g R2、12g R1、12g R2での新規プロビジョニングができなくなりました。
アシストでは全社員にAIアシスタントGleanを導入しました。サポートセンターで2ヶ月間使ってみて感じた効果やメリットをお伝えします。