API-BridgeやMONO-X Oneが実行したSQLにより、基幹業務がパフォーマンスダメージを受けないようにしたい場合の参考例となります。
（１）IBM i (AS400) のCPU割当ては、実行プライオリティ（Execution Priority）とメモリー活動化レベルで制御
例えば、基幹業務を、対話型（実行プライオリティ＝20）、バッチ（実行プライオリティ＝50）で稼働している場合、
API-BridgeやMONO-X Oneの投入のSQLを実行プライオリティ＝51で動かせば、基幹への影響を最小化することが可能かと思います。
この場合、夜間のバッチが数十多重とかで動く場合、API-BridgeやMONO-X One投入のSQLへのCPUサービスが大幅に低下する可能性があります。
これをどうしても許容できない場合は、API-BridgeやMONO-X One投入のSQLの実行プライオリティをバッチと同じ50にする必要があります。
同じ50のプライオリティでは、ダイナミックプライオリティ*1が働き、基幹のI/OバウンドJOBに優先権を与えることができます。
*1 ダイナミックプライオリティ＝TIME SLICE毎に0.008(=125分の一)ずつCPUバウンドJOBのプライオリティが下がる機能
（２）API-BridgeやMONO-X One投入のSQLが極端に多く、基幹への影響が懸念される場合
- API-BridgeやMONO-X One投入のSQLのサブシステムのメモリー活動化レベルを「*NOMAX」ではなく「10」とかに制限し、10を超えるものはSWAP OUTし実行を抑制する。
- LPARの割当コアを１コア増強し、API-BridgeやMONO-X One投入のSQLのジョブは増強１コア分以内でうごくようにCPU割当を制限。（ワークロード・グループ機能）
【参考】