はじめに
前回はDB起動に関して詳細に見ていきました。そのため今回は、DB起動後の動きについて詳細に見ていこうと思います。ここで一度、DBが起動できた後の流れについて軽く確認しておきましょう!
DBが正常に起動したら、次はクライアントからのSQL指示を受け取る準備が必要となります。この準備がクライアントのDB接続です。そして、DB接続が確立されるとセッションも開始され、その後やっとSQLの実行ができるようになります。つまり、データベースを使うためにはDB接続の方法やセッションについても知らなければいけませんね!
ということで今回は、DB接続とセッションについて解説します。
クライアントのDB接続について知ろう!
クライアントが発行するSQLをDBサーバが受け取るためには、両者間でそのやり取りの方法を定める必要があります。では、もしも両者間で何のやり取りの方法も定めていなかったらどうなるでしょうか?
発生する2つの問題を仕事発注者(クライアント)と工場の例を用いて解説します。
1. クライアントの仕事の依頼方法と工場での仕事の受け取り方法が食い違う
1つ目の問題は、クライアントの仕事依頼方法と工場での受け取り方法が異なることにより、正常に仕事が依頼できないということです。例えば、クライアントはLINEで工場に仕事を送ろうとしているのに、工場側では手紙の受け取りしかサポートしていないみたいな場合です。
このような問題を起こさないために、仕事の依頼方法と受け取り方法は合わせておく必要があります。
2. 仕事を依頼するための正しい場所がわからない
2つ目の問題は、クライアントが工場に仕事を依頼するときに、どこに依頼を出せば良いかわからないということです。このような問題が発生しないように、仕事の依頼を受け取る窓口のような存在が欲しいですね!

2つの問題を解決する受け取り窓口を置いてみよう!
上述した2つの問題を解決するために、工場の隣に受け取り窓口を設置してみましょう!
この受け取り窓口は、依頼の提出方法を公開しており、正しく依頼を受け取れると工場内からクライアント専用の担当者さんを連れてきてくれる役割を持ちます。そして一度クライアントからの依頼が受け取られた後は専用の担当者さんが相手してくれます。図で表すと以下の感じです。
はい、これでクライアントからの仕事をきちんと受け取る準備が整いましたね!
クライアントのDB接続においてもこれと同じことが行われています!!!
実際オラクルDBではどうなっているか見てみよう!
実はオラクルDBでは依頼者・受け取り窓口・担当者さんに相当する要素が存在しています。それらの要素は以下の3つです。
- 依頼者:ユーザプロセス
- 受け取り窓口:リスナープロセス
- 担当者さん:サーバプロセス
では、この3つのプロセス間でどのようにDB接続を行われるかを確認していきましょう。
1. リスナープロセスが起動される
まずは受け取り窓口の役割をするリスナープロセスが起動されます。リスナープロセスは依頼の提出方法に関する情報を持っており、それは「listener.ora」に保存されています。例えばlistener.oraの内容は以下のようになっています。
LISTNER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = LOCALHOST)(PORT = 1521))
(ADDRESS = (PROTOCOL = ---)(KEY = ------- ))
)
)
このファイルの内容について簡単に説明します。
LISTNER =
の部分はリスナープロセスくんの名前です。そしてそれ以下の
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = LOCALHOST)(PORT = 1521))
(ADDRESS = (PROTOCOL = ---)(KEY = ------- ))
)
)
の部分が仕事依頼の出し方と宛先を示しています。
具体的には依頼の提出方法が(PROTOCOL = TCP)で、宛先が(HOST=LOCALHOST)(PORT=1521)ですね!
ちょっと脱線
TCPって?
TCPとは、ざっくり言えば安心安全に通信を行うためのやり取りの方法です(何を持って安心安全と言うかはまちまちですが、、、)。TCPという通信方法を使えば、通信相手(DBとか)にちゃんとデータが届くんだなと思ってもらえれば良いです。今のところ、多分。
HOSTとかPORTって
簡単に言えばサーバの住所名です。HOST区PORT番地にサーバが住んでるんだな〜みたいに思ってもらえればいいと思います。
つまり、
(ADDRESS = (PROTOCOL = TCP)(HOST = LOCALHOST)(PORT = 1521))
というのは、
LOCALHOST区1521番地にいるLISTENERくんに、TCPという安全な方法で通信してほしい
ってことです。
脱線から戻ってつまり?
つまり、listener.oraに記された宛先や方法を用いて、窓口であるリスナープロセスが待ち受けを行うってことです!
2. ユーザプロセスからリスナープロセスに接続要求する
仕事の依頼者であるユーザプロセスがリスナープロセスに、「DB接続をしたい」旨の接続要求を行います。この際、接続したいDBに関する情報が書かれているのが「tnsnames.ora」です。こちらに関してもファイルの中身を見てみたいと思います。
XE =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = LOCALHOST)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = XE)
)
)
#以下にも内容が続く
ファイルの中身について簡単に説明します。
まず最初の行「XE=」の部分は接続識別子を定義しています。ユーザプロセスはここに書かれた接続識別子名を使ってDBにアクセスすることができます。
それ以下の内容である
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = LOCALHOST)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = XE)
)
)
の部分は接続記述子と呼ばれています。接続記述子内では、
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = LOCALHOST)(PORT = 1521))
)
によって、リスナープロセスへどのように接続するかを定義し、
(CONNECT_DATA =
(SERVICE_NAME = XE)
)
によって、どのデータベースに接続するかを定義しています。
このように、tnsnames.oraの内容をもとにユーザプロセスはリスナープロセスに接続要求を行います。
3. リスナープロセスが接続要求を受け入れてサーバプロセスを起動する
接続要求が受け入れられるとリスナープロセスがサーバプロセスの起動を行います。担当者さんの呼び出しを行う部分ですね!この流れによってユーザプロセスとサーバプロセスが直接通信できるようになり、やっとSQLの発行・実行をできるようになります。

DB接続のまとめ
では、ここまでのDB接続の流れを軽くまとめましょう。
- リスナープロセスが起動される
- ユーザプロセスからリスナープロセスに接続要求する
- リスナープロセスが接続要求を受け入れてサーバプロセスを起動する
はい、このようにまとめられます。ではここで質問です!
「リスナープロセスが起動される」と書きましたが、これを起動するのは一体誰でしょう?また、「ユーザプロセスからリスナープロセスに接続要求する」のも誰が行うのでしょうか?
正解はもちろんDB管理者ですね!
DB管理者が1や2の手順を実現するコマンドを入力することでDB接続ができると言うわけです!そのコマンドが例えばリスナープロセスの起動に関するものだったら「lsnrctl」だったり、接続要求だったら「connect」だったりと言う感じですね。さらにこれらのコマンドを扱って接続をするためには「listener.ora」や「tnsnames.ora」の内容が正しく設定されている必要もありますね!これらを整備するのもDB管理者の仕事になるということです。
詳しいコマンドやファイルの詳細は割愛しますが、ぜひDB接続テストもしてみてください!
セッションについて
最後にセッションについて軽く説明します。セッションとはユーザがDBに接続してから切断するまでの一連の活動のことを指します。言い換えれば、ユーザプロセスとサーバプロセスが通信しあっているときは1つのセッションとなります。セッションは、ユーザの認証や認可を行なっている他、さまざまなリソースが割り当てられる単位でもあるため、適切なセッション管理は重要なタスクです。
まとめ
最後に本日解説したことを箇条書きで記します。
- クライアントはSQL操作を行うためにDBへ接続する必要がある
- DB接続時の問題が発生しないように依頼受け取り窓口の役割を担うリスナープロセスが存在する
- 接続が受け入れられると、ユーザプロセスは専門の担当者の役割を担うサーバプロセスと直接通信可能となる
- 依頼の提出方法を示すlistener.oraや接続要求の内容を示すtnsnames.oraというファイルが存在する。これらはDB接続をできるようにするためDB管理者が設定する
- リスナープロセスの起動や接続要求の発行もDB管理者が適切に行う必要がある
- DBに接続してから切断するまでの一連の活動をセッションという




