クライアントからリスナー経由でデータベースに接続する手続き(共有サーバー構成)

クライアントからリスナー経由でデータベースに接続する手続き(専用サーバー構成) - ablog
Oracleの専用サーバ構成についてまとめたが、共有サーバー構成についてもまとめてみた。

  • どういうケースで使うか
    • 多数のクライアント端末から同時に接続するクライアントサーバシステムで有効だと思う。
    • 専用サーバー構成で同時接続数が多いとメモリを大量に使うから。
    • Webだったら専用サーバー構成でコネクションプーリングを使ったほうが良いと思う。
    • 専用サーバー構成だとサーバー・プロセスのみで処理するけど、共有サーバー構成だとディスパッチャとサーバー・プロセスで処理する(キューを使って中継)のでパフォーマンスは落ちるから。
  • クライアントとの接続手続き
    • クライアントはリスナーにCONNECTパケットを送る。
    • リスナーはディスパッチャとDirect Hand-Off接続して、プロセスの初期化情報を渡して、接続をクローズする。
    • ディスパッチャはリスナーからTCPソケットを継承する。
    • ディスパッチャからクライアントにRESENDパケットを送る。
    • クライアントからディスパッチャにCONNECTパケットを送る。
    • ディスパッチャからクライアントにACCEPTパケットを送り、接続を確立する。
    • ディスパッチャは複数のクライアントからの接続を処理することができる(プラットフォーム固有)。
  • SQL処理の手続き
    • クライアントからディスパッチャに処理要求が届く。
    • ディスパッチャはそれを要求キューに入れる。
    • サーバー・プロセスが要求キューから取出して処理して応答キューに入れる。
    • ディスパッチャは応答キューから取出してクライアントに返す。
    • 要求キューは1つ(共有)、応答キューはサーバー・プロセスごとにある。
    • UGA(セッションデータ、カーソル情報)は専用サーバー構成の場合はPGAに、共有サーバー構成の場合SGAにおかれる。
    • たぶん、ディスパッチャとサーバー・プロセスで情報共有するからだと思う。
  • 初期化パラメータ
    • DISPATCHERSで指定した数のディスパッチャが生成され、MAX_DISPATCHERSまで増やすことができる。自動では増えない。手動で増やせる。
    • サーバー・プロセスはSHARED_SERVERSで指定しただけ生成され、必要に応じてMAX_SHARED_SERVERSまで自動で増やしてくれる。
    • MAX_SHARED_SERVERSが少なすぎると人工デッドロックが発生するので注意。
    • SHARED_SERVER_SESSIONSをSESSIONSより小さくしておくと、専用サーバー接続用にリソースを確保しておくことができる。
  • その他
    • 情報はlsnrctl servicesやv$表で確認することができる。
    • tnsnames.oraでSERVER=DEDICATEDにすれば、専用サーバー接続で接続することができる。
    • SYSDBA権限で起動・停止などをする時は専用サーバー接続を使わないといけない。
    • バッチ処理も専用サーバー接続が向いている。


[参考]
オラクルマスター教科書 Platinum DBA 2(試験科目:1Z0‐032J)
http://otndnld.oracle.co.jp/document/products/oracle11g/111/doc_dvd/server.111/E05771-03/toc.htm