最近、リリースしたばかりの環境で接続関連のエラーが頻発したので原因調査を行いました。
構成は以下の通りです。
クライアント側にORA-03113またはORA-03135が発生しているとの連絡ですが、このシステムでは80近くのDBがあり、同システム内のAPサーバだけでなく、他システムからの接続もあって対象クライアントの数が多すぎるので、まずはDBのアラートログにORA-609が発生している事象について調査しました。
ORA-609はクライアントからの接続要求を受けてからデータベースにセッションが確立されるまでの間に何らかの問題が発生した場合にアラートログに記録され、SQLNET.INBOUND_CONNECT_TIMEOUTで制限時間（デフォルトで60秒）を設定します。
アラートログとリスナーログを突き合わせると、監査証跡を収集するツールがエラー発生時に接続しに来ていました。
担当部署の協力を得、そのツールでテスト的にDBに接続を試みたところ、ORA-609が多発する事が確認できました。
が、開発環境や他のシステムの本番環境ではエラーが発生しません。
エラーの発生する環境と発生しない環境の差を確認したところ、エラーになる環境では複数リスナーに対するロードバランス接続となっています。
そのツールではJdbcドライバを使用しているのですが、Oracle社のドライバではなく、独自ドライバらしきもので接続プールを使用しているようです。
どうやらそのドライバでは複数リスナーに対する接続に対処しきれていないようで、単一のリスナーに対する接続に修正してもらったところ、エラーは発生しなくなりました。
これとは別に特にORA-3136が多発しているDBがあり、AWRを確認したところ、Failed Logon Delayが待機時間の上位を占めています。
Top 10 Foreground Events by Total Wait Time
| Event | Waits | Total Wait Time (sec) | Wait Avg(ms) | % DB time | Wait Class |
|---|---|---|---|---|---|
| DB CPU | 102.1 | 34.3 | |||
| Failed Logon Delay | 67 | 67.1 | 1000.86 | 22.6 | Other |
| db file sequential read | 6,950 | 13.3 | 1.91 | 4.5 | User I/O |
| control file sequential read | 6,896 | 6 | 0.87 | 2.0 | System I/O |
| db file scattered read | 448 | 1.6 | 3.65 | .5 | User I/O |
| db file parallel read | 165 | 1.4 | 8.69 | .5 | User I/O |
| log file sync | 338 | 1.1 | 3.38 | .4 | Commit |
| utl_file I/O | 100,491 | 1.1 | 0.01 | .4 | User I/O |
| Disk file operations I/O | 447 | .7 | 1.63 | .2 | User I/O |
| SQL*Net message from dblink | 252 | .4 | 1.68 | .1 | Network |
この待機の原因は間違ったユーザ／パスワードで接続を繰り返している事であり、多い時ではDB Timeの約20%の負荷になっています。
リスナーログで確認したところ、パフォーマンス用のツールから間違ったユーザ名で接続に来ていました。
これも担当部署に対処してもらい、エラーは解消しました。
上記2つの対処でエラーはかなり減ったのですが、それでもまだ時々発生するとの事。
ファイアウォールやその他OS周りの設定など、旧環境との差異を調査してもらっていたのですが、MOS資料で以下のドキュメントを見つけました。
12c Client Applications can Hang or Disconnect (Doc ID 2109671.1)
Oracle Net ServicesのVersionが12.1.0.2 以降で、Juniper社のファイアウォール使用し、SQL ALG機能を有効にしている時に、接続がハングするという事象です。
Juniper社のサイトに詳しい説明がありますが、12c以降、TNSパケットの長さが変更になった為、SRXがヘッダを解析できずにパケットの破棄が発生するという内容です。
[SRX] Oracle 12c fails to communicate when SQL ALG is enabled - Juniper Networks
Juniper製のファイアウォールを使用している（SRXより古いバージョンのもの）事はすぐに判明しましたが、SQL ALG機能が有効か否かの確認になぜか数週間かかってしまいました・・・
結果として、SQL ALG機能は有効である事が判り、無効にする事で対処となりました。
尚、上記Juniper社のドキュメントによれば、SQL ALGは不要な機能であり、無効にする事が推奨されているそうです。
これで全てのエラーが解消されれば良いのですが、実は別のシステムでORA-03135が発生しています。
それに関してはまた別の機会でまとめたいと思います。
