ODP.NET 茶包連擊第二發,這回輪到 Managed ODP.NET,程式冒出 Unable to resolve ORA-12154: TNS:could not resolve the connect identifier specified 錯誤。

不需要安裝 Oracle Client,沒有亂七八糟的 32/64、11.2、12.1 版本鬼問題讓 Managed ODP.NET 在部署維運成本上狂勝 Unmanaged ODP.NET, 作業環境唯一要配合的只有提供 TNSNAMES.ORA 資料庫名稱對應檔(當然,將 Oracle 伺服器 IP 寫死在 web.config 也是做法, 但遇過資料庫 IP、名稱異動的人都這是個餿主意),依錯誤訊息,研判問題與 TNS_ADMIN 設定有關。

安裝人員回覆已在該主機設好 TNS_ADMIN,因無法實際登入主機驗證,再次祭出 Inline ASPX 線上快速檢測法

<%@Page Language="C#"%>
<script runat="server">
void Page_Load(object sender, EventArgs e)
{
	Response.Write("<li>TNS_ADMIN=" + Environment.GetEnvironmentVariable("TNS_ADMIN"));
	Response.Write("<li>" + typeof(Oracle.ManagedDataAccess.Client.OracleConnection).Assembly.CodeBase);
}
</script>

預期執行後會顯示當下的 TNS_ADMIN 環境變數及 Managed ODP.NET 版本(如下範例):

請相關人員將 test.aspx 放上問題主機,答案揭曉,TNS_ADMIN 原本只需指到 NETWORK/ADMIN 目錄即可,但被誤設指到 TNSNAMES.ORA 檔: x:\Oracle\Product\12.1.0\Client\Network\Admin\TNSNAMES.ORA。

有了明確事證,不必瞎猜不必多辱舌,請主機管理人員修改設定就對了。

不過,隨後出現驚人發展,歷經 AppPool 重啟、IISRESET,test.aspx 顯示的 TNS_ADMIN 變數居然還是修改前的錯誤內容, 其 Cache 的頑強超乎想像,最後靠著重新開機才解決。

由此再學到經驗 - 變更環境變數後,最好重啟作業系統以確保 ASPX on IIS 讀取新值。

註:依爬文找到的資料,有人主張 IISRESET 就夠了,但也有人遇到跟我一樣的狀況:

For me, neither stopping and starting IIS in the MMC snap-in, nor running iisreset was sufficient. I had to restart the entire server (VM).

I removed some machine environment variables. Only server restart helped to forget them (IIS 7.5).

而本次也幸好有 test.aspx 明確反映修改結果是否套用,否則當改了 TNS_ADMIN 環境變數 IISRESET 無效, 依照直覺反應,通常會胡思亂想,開始檢查其他環節做白工,不知要走多少冤枉路。

啊,Inline ASPX 線上檢測,我要為你輕輕唱首歌~

This article provide a example of using inline ASPX to check environment variable value in production environment and shares practical tips: you have to reboot Window to make sure ASPX will read the updated environment variable.


Comments

Be the first to post a comment

Post a comment


14 - 11 =