ORACLE小話その１５ 共有サーバプロセス

こないだは共有サーバプロセス関連で
トラブルがあったみたいです。

現象としては共有サーバプロセスが
MAX_SHARED_SERVERS接続数まで使い切っちゃって
全然応答が返ってこなくなった、
というもの。

根本的な原因は、MAX_SHARED_SERVERSの設定値が低かった（４０）
という基本的なことなんですけどね。



Oracleのマニュアルも見たんですけど、
そもそも共有サーバプロセスの見積もりって結構難しいらしい。
以下はマニュアルの抜粋。

まず、psコマンドなどでシステムの使用可能なRAM容量を調べて
追加できる共有サーバプロセスの数を見積もる。
その後、少しずつMAX_SHARED_SERVERSの値を増加していって
スワッピングが発生したところが一杯一杯なので
そこから最適な設定を見つけだす

こんな感じで書かれてました。
普通そこまでするの？



あと、共有サーバープロセスについて
ちょっと疑問があるんですよね。
それは
　１つのセッション（SQL文）に対し、
　１つのサーバープロセスが対応するのか？

というもの。要は１対１になっているか。

コネクション自体はディスパッチャで
複数の接続に対応してくれるのはわかるけど、
その後、要求キューに入れられた１つの処理は
１つのサーバープロセスが対応するものなの？
とすると結局、重いSQL処理がMAXまで（今回の場合は４０個）発行されて
すべての共有サーバプロセスがお仕事中だとしたら、
その後に入ってきたSQLは待たされちゃうって事？
それもなんだかなぁって感じがするんだけど…


また、Oracleマニュアルには
「ユーザーが比較的少数の要求しか行わない場合、
　１０～２０ユーザーに対し１つの共有サーバプロセスで十分」
と記述されております。


今回共有サーバプロセスが溢れた時は約２００セッションだったんですけど
すべてのセッションが要求中だったとしても
共有サーバプロセスは２０で十分っていう計算なんですけど…
まあ要求が重かったからって事ですかね。


さっきも書きましたけど、個々のシステムによって最適な
プロセスの数があるみたいですしね。
こんなに単純な計算では行かないって事か。


■共有サーバの診断
V$SHARED_SERVER_MONITOR
V$SHARED_SERVER
V$SESSION
V$CIRCUIT

■ディスパッチャの診断
V$DISPATCHER
V$DISPATCHER_RATE
V$QUEUE