Oracleのリスナーってなんだろう？１

Oracle databaseに絶対必要なプロセス(サービス)であるリスナーサービス。 何をしているのか今ひとつ分かりにくいですね。 正式には「Oracle Net Listener」と呼ばれるリスナーですが…そもそもリスナーって何でしょうか？

Oracle11gの「Database Net Services管理者ガイド」によると

【Oracle Net Listener】
サーバー上で実行される独立したプロセスです。
クライアントの着信接続要求をリスニングし、サーバーへの通信量を管理します。
クライアントがデータベース・サーバーとのネットワーク・セッションをリクエストするときに、リスナーは実際のリクエストを受け取ります。
クライアント情報がリスナー情報と一致した場合、リスナーはデータベース・サーバーへの接続を許可します。

と、定義されていました。 ここでのポイントは２つです。

1.「独立したプロセス」

Oracle Databaseの一部ではありますが、OracleDatabaseサービスとは別のプログラム（プロセス、サービス）です。OracleDatabaseサービスの起動、停止とは関係無く存在できますし、OracleDatabaseサービスが起動していてもリスナーが起動していない可能性もあります。

2.「着信接続要求をリスニング」

クライアントプログラムはOracleDatabaseサービス本体ではなく、リスナーにdatabaseに接続したい旨を要求します。リスナーが取り次いでくれないとdatabaseのIDやパスワードが分かっていても接続できません。

ちなみに、SQL ServerやDB2等他のdatabaseはサービス自体がリスニングする構成のため似たような機構は持っていないようです。 このような構成になっているメリット・デメリットを考えます。

メリット

負荷分散が容易

待ち受け（リッスン）処理が独立しているため、実際のdatabaseサービスの稼働状況によってレプリケーションされている別サービスへの振分が容易に行える。（いわゆるRACを実現する重要なプロセス）

databaseが接続待ち受けする必要が無い

外部からの接続待ち受けをするためには接続ポートの監視という処理が必要となります。これをリスナープロセスが専門でやってくれるのでdatabase本体は自分の仕事を全力でこなすことが出来ます。

対DoS攻撃に強くなる

あるサービスに対して膨大な量のアクセスを発生させることでサービスをダウンさせるのがDos攻撃です。（WebサーバにF5連打とかね）Dos攻撃を受けるのはあくまでリスナーであってdatabase本体では無いため、Dos攻撃によってdatabase本体がダウンする恐れはありません。(OS自体がポートへのアクセスを捌けず落ちる可能性はありますが）

デメリット

リスナー用のリソースが必要

独立したプロセスであるが故に、リスナー専用のメモリおよびCPUリソースが必要となります。上記の通りリスナーは幾つも作れるので作れば作るほどリソースは必要になります。

トラブル時の切り分け、調査対象が増える。

接続ができないというときに、リスナーの稼働状況や設定値も調査する必要があり原因の究明が難しくなる可能性が考えられます。

メリットから鑑みるに、databaseを安定稼働させるための仕組みと考えてもよさそうですね。仕組みはややこしくなりますが、このアーキテクチャからデータはなんとしても守るという強い意思を感じます。

でも、実際運用するとリスナーにまつわるトラブルは絶えないんですよね…。

絵で見てわかるOracleの仕組み (DB Magazine SELECTION)