摘要:《TNS-12500 - Part 1》
TNS-12500 是存在listener.log裡的錯誤訊息。
part 1 講述的是我還在當程式設計師時遇到的經驗，
也因此跨入oracle DBA這角色 (職務不變，工作加重 >"<)，
沒有這次的經驗應該一輩子不會考慮這條路吧！
約略是2006年左右，當時公司內部資料庫十分不穩，
經常出現 TNS-12500 的錯誤，線上新的session都無法連到資料庫，
每天幾乎都要重開機個一至兩次，當時的DBA經驗也不足，
資料庫以外的工作已經讓他忙翻，無法分身仔細的觀察資料庫的變化。
因為資料庫連線不穩定已經影響線上使用者的情緒及我們的程式，
偏偏 DBA 在這時候離職，事情總要解決，就利用空閒的時間觀察了資料庫的變化，
當然不小心解決 TNS-12500 無法連線的問題，也因緣際會踏入 DBA 的領域。
講了一些枯燥的歷史背景，但是都是筆者人生旅程中最重要的一步。
那就揭曉謎底吧！原因是筆者當時公司 oracle 所有使用者都用同一個 profile，
每個 session 都設定了 idle 時間 45 分鐘，同時有一外包商用 java 寫的程式，
斷線後會不斷重新連線，因為筆者對 java 不熟，不知道是否是 java 還是該
外包商的程式編寫問題，不過當時觀察 v$session 會看出每每在開始出現
TNS-12500 時的總 session 數，會一次比一次少，舉例來說就是第一次出現時，
假設是 500 個 session，過一陣子後 480 個 session 就會無法連線，
再過一陣子 450 個 session，一次比一次少，到最後不得已就只能重開機處理。
google 一陣子之後才知道還有個 v$process，除了 v$session，一併連 v$process
一起列入觀察名單中；這次中頭獎囉！
v$session 的總數雖然一次比一次少，但是 v$process 卻是一次比一次多，
每次資料庫重新開機後， v$session 的總數與 v$process 的總數都差不多，
大約是 1:1 但是重開機前的 v$session 與 v$process 的總數完全不成比例，
猜測該 java 程式在 idle 時間到被斷線後， server process 看起來將 user process
切斷了，但是 process 卻一直仍在連線的狀態；久而久之就超過了參數中設定的
processes 數量，所以嘗試將該外包商帳號的 idle time 設成 unlimit，
出乎意料之外的解決了；一戰成名卻還是十足毛頭小子，不知是幸還是不幸。
-----------------------
既然是 part 1 當然還有 part 2囉！ 因為有了第二次 TNS-12500 的經驗，
也就順便將第一次遇到的問題寫出來，也因此覺得日常的觀察及見微知著的重要，
part 2就是要介紹第二種 TNS-12500 的原因囉。