Q&A
closeでlanの接続を検知しなければならない理由があればそれも質問に書いていただけませんか？
こちらの質問にて、ODP.netでOracleをCloseした場合、その際にLANの接続が切れているなど明らかに異常の状態でもエラーはスローされないようなのですが、
ODP.netのCloseメソッドに対して、処理失敗のエラーは存在しないのでしょうか？
https://teratail.com/questions/96097?whotofollow=
逆に言えば、Oracleを明示的にCloseしないデメリットというのは何かあるのでしょうか？
例えば、システム起動と同時に接続し、システム終了時に切断させるようなシステムの場合、明示的にcloseさせる場合とさせない場合で、何か違うのでしょうか？
すいません。質問の仕方が悪かったようです。私が知りたかったのは、LAN切断やシステム終了時はcloseしなくても、自動的に切断されるかどうかだったんです。このスレッドいったん終了して別スレッド立てます。
回答3件
0
世の習いとして、OPENしたものはきちんとCLOSEしなければなりません。
カーソルを OPEN したまま CLOSE しないと初期化パラメータ open_cursors の上限を超えるとエラーに
なります。
手を抜くことより、ちゃんと運用できるシステムを作ることを心掛けてください。
投稿2017/10/14 04:04
総合スコア16417
ストアドに使うカーソルのことを言っておられるのですか？
質問は ODP.NET の OracleConnection を Open した後 Close しないとどういうデメリットがあるかということなのですが、カーソルとどういう関係があるのでしょう？
カーソルはストアド以外にも使われます。V$OPEN_CURSOR などの動的パフォーマンス・ビューを覗いてみると、あれえ？何これ？っていろいろ発見があります。
OracleConnection を CLOSE しないと V$SESSION の幽霊セッションとして残ることが考えられますから、 初期化パラメータ sessions を超えてしまい、 ALTER SYSYTEM KILL SESSION ... が必要にかもしれません。
最近は何か月も稼働を続けなければならないシステムも多いですから、shutdownしなければならなくなると障害として扱われ、お客様からクレームを受けることもあるのでご注意を。
質問者さんのケースは「ODP.NET」←→「LAN 等の通信路」←→「Oracle」という構成で、OracleConnection.Close は ODP.NET 側に限った話のはずです。
Orlosky さんの言われるカーソルというのが理解できていませんが、それは Oracle 内部に限った話ではないのでしょうか？
私のレスで紹介した記事「.NETの例外処理 Part.2」の図を見てください。記事は SQL Server + SqlClient の話ですが、たぶん Oracle + ODP.NET も同様に、OracleConnection の Open / Close は ODP.NET 側にある Connection Pool にある Connection の貸し出し / 戻しを行うのみで、DB サーバー側には何も影響を与えないと思います。
質問者さんのケースは差支えなければ OracleConnection.Open しとた時とOracleConnection.Close後のV$OPEN_CURSORのSID,SERIAL, MACHINE, STATUS, PROGRAM 列を確認していただけますか？
たしかに、この質問ではカーソルはあまり適切ではありませんね。
カーソルをOPENしたままCLOSEを故意に省略するモラルのない人が残念ながら少なくないです。EXCEPTIONでカーソルがOPENされていたらCLOSEする記述も漏れていることもしばしば。
> 確認していただけますか？
ご自分で確認した結果を書いていただくようお願いします。
ODP.NET環境を用意していません。
ごめんなさい。質問の仕方が悪かったようです。私が知りたかったのは、LAN切断やシステム終了時はcloseしなくても、自動的に切断されるかどうかだったんです。このスレッドいったん終了して別スレッド立てます。
0
ベストアンサー
Closeしないとconnectionリーク(connection poolのconnectionの枯渇)が起こりやすくなります。結果、DBに接続できないということになります。webアプリで多数のユーザーが同時アクセスするようなケースではどうなるかを考えれば、必ずCloseするという結論になるかと思いますが？
【追伸】
SQL Server / SqlClient の場合ですが、connection リーク防止のため必ず Close する、そのためにはどういうコードを書くべきかの記事を紹介しておきます。
.NETの例外処理 Part.2
https://blogs.msdn.microsoft.com/nakama/2009/01/02/net-part-2/
Oracle / ODP.NET の場合でも、ADO.NET の基本を守って ODP.NET が実装されていれば、同じことが当てはまるはずです。
投稿2017/10/14 04:30
編集2017/10/15 04:06退会済みユーザー
総合スコア0
ごめんなさい。質問の仕方が悪かったようです。私が知りたかったのは、LAN切断やシステム終了時はcloseしなくても、自動的に切断されるかどうかだったんです。このスレッドいったん終了して別スレッド立てます。
0
不要なセッションが切断されずに残ることによるリスクとしては、同時接続数の上限に達する可能性が上がることが考えられます。
そのため、DBMSにはタイムアウト値を設定して一定期間無通信のセッションを切断する実装もあります。
また、なんらかのロックを確保したセッションが残り続け、システムの稼働に支障をきたす可能性もあるかもしれません。
ただし、もし長期的に接続し続けることに明確なリスクがあるのであれば、コネクションプーリング等は実施できないことになるものと考えられます。
ですので、同時接続数制限に達する心配がなく、クライアントからの要求を適切に返せるのでしたら問題は少ないのではないかと思います。
追記：
本件では、ネットワーク接続としてのコネクションと、Oracle Databaseとの接続であるセッションを同時に考えようとしているために複雑となっているのかもしれません。
私の説明も、クライアントとサーバー、システムとデータベース、接続やセッション、コネクション等の表記ゆれがあるため、混乱させてしまっているかもしれません。
このような場合、OSI基本参照モデルをもとに理解するとわかりやすいかもしれません。
| レイヤー | レイヤー名 |
|---|---|
| L7 | アプリケーション層 |
| L6 | プレゼンテーション層 |
| L5 | セッション層 |
| L4 | トランスポート層 |
| L3 | ネットワーク層 |
| L2 | データリンク層 |
| L1 | 物理層 |
ここで、Oracle Databaseとの接続に相当するのはL5のセッション層です（たぶん）。
L6やL7は実際に発行するSQL等のことだと思って頂いて問題無いかと思います。
LANケーブルの抜線はL1の切断になります。
LANケーブルをすぐに挿し直すと、上位層でのリカバリ処理によりネットワーク接続は維持されることが期待されます。
このようなリカバリが可能なのは、上位層では接続が維持されていると認識しているためでもあります。
そのため、どちらか一方が強制的に接続を打ち切ったり、低レイヤー層でのネットワーク切断を認識できていなかったりする場合、使用されないセッションが残ってしまうということになります。
投稿2017/10/14 03:29
編集2017/10/22 01:47退会済みユーザー
総合スコア0
ごめんなさい。質問の仕方が悪かったようです。私が知りたかったのは、LAN切断やシステム終了時はcloseしなくても、自動的に切断されるかどうかだったんです。このスレッドいったん終了して別スレッド立てます。
DBMSが接続断を認識していなければDB側にはセッションが残ったままとなります。
クライアント側（システム等）のコネクションは無くなっている場合と、そうではない場合があります。システム終了時はシステム側は接続を一方的になくしているかもしれませんが、ネットワーク切断時はDBMSとの通信が発生するまでは、システム側、DBMS側ともに、お互いに接続は維持されていると判断するでしょう。
なるほど。難しいですね。。。
DBMS側としては、そうなった時の為のごみセッションのクリーニングなどが必要という事なのでしょうか。。。
はい、そのためにセッションタイムアウト値が設定されています。
前述とは逆に、クライアント側はコネクションが継続していると思っていても、データベース側ではセッションを破棄している場合もあります。他にもネットワーク経路上にあるFW等のネットワーク機器によるセッション切断も発生し得ます。
このような場合には、Oracle DBとの接続であれば通信時にORA-03113やORA-03135といったエラーが発生することになります。
あなたの回答
tips
プレビュー
