排查IIS ASP.NET網站應用程式記實

- 6月 30, 2026

事情發生在windows domain controller (DC)伺服器的硬碟故障導致我們直接放棄該台DC並將所有DC工作全部轉移到另一台DC之後。登入網域驗證的工作沒有問題的移轉了, 但問題出在DNS: client若使用DHCP取得IP的, 基本沒什麼問題。問題在固定IP的電腦或伺服器, 基本上若有變慢或卡住的情形, 檢查其DNS設定做更改就是。但有些情況是比較難排查的:

我們注意到內部一套使用ASP.NET開發的系統, 之前都流暢運行, 現在在登入或操作數分鐘之後, 會出現卡住10多秒的情形, 但之後又可以持續正常運行一段時間。

一開就懷疑是名稱解析問題, 但該伺服器的DNS已改成正確的, 狀況還是沒有改善。問Copilot意見，由它的建議中，找到查IIS Log的方法:

📑 檢查 IIS 日誌

日誌位置
- 預設路徑：
  程式碼
  %systemroot%\system32\LogFiles\W3SVC1\
  （不同網站會有不同的 W3SVC 編號資料夾）

打開最可能的日誌檔後，複製全部的內容，再貼回給Copilot去分析。它告訴我幾個要注意的地方, 其中出現302重導, POST請求的問題, 可能是登入流程, session驗證, 或後端SQL查詢延遲。這讓我將注意力放到登入的部份, 確實問題是在登入或操作數分鐘之後, 會出現卡住10多秒的情形。而我們的ASP.NET應用程式, 也是在登入時必須和後端資料庫比對資料成功後才發給session。先看看是否連線到資料庫正常, 用tnsping:

C:\Documents and Settings\ops>tnsping xxx

TNS Ping Utility for 32-bit Windows: Version 9.2.0.1.0 - Production on 25-6月 -2 026 10:53:52

已使用的參數檔案:

使用 TNSNAMES 介面程式來解析別名 Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = tf-or11g.princo.com.tw)(PORT = 1521))) (CONNECT_DATA = (SERVER = SHARED) (SERVICE_NAME = orclXDB))) OK (0 msec)

Copilot說: "你跑的 tnsping xxx 測試結果顯示 Oracle Net 連線非常快 (0 msec)，代表網路、Listener、TNS 解析都沒有問題。這樣一來，IIS /salary/login.aspx 多次 302 延遲就不是「連線建立」的問題，而更可能是應用程式與 Oracle DB 互動的效能瓶頸。接下來可以從以下幾個角度深入檢查：" 然後列了一大堆可能的檢查方向。我先試個人覺得比較有可能的:

慢查詢 / Index 問題

登入驗證通常會查詢使用者表，若缺少索引或 SQL 效能差，會造成延遲。

檢查：

sql

SELECT sql_id, executions, elapsed_time/executions AS avg_ms
FROM v$sql
WHERE sql_text LIKE '%LOGIN%';

SQL_ID        EXECUTIONS     AVG_MS
------------- ---------- ----------
059zr3n1302hh         10    14287.3
04zbxydx7zr42          1      15098

Copilot看到這個結果後說: "你查到的 SQL 結果非常關鍵：這代表登入相關的 SQL 平均執行時間 14~15 秒，這正好對應到 IIS /salary/login.aspx 出現的 10 秒以上延遲。也就是說，問題不是 Oracle Net 連線或 Dispatcher，而是登入驗證 SQL 本身效能差。"

找出 SQL 內容

sql

SELECT sql_text
FROM v$sql
WHERE sql_id='059zr3n1302hh';

INSERT INTO mgmt_db_dbNInstanceInfo_ecm
(BANNER, CHARACTERSET, DATABASE_NAME, DEFAULT_TEMP_TABLESPACE, DV_STATUS_CODE,
 ECM_SNAPSHOT_ID, GLOBAL_NAME, HOST_NAME, INSTANCE_NAME, LOGINS, LOG_MODE,
 NATIONAL_CHARACTERSET, OPEN_MODE, STARTUP_TIME)
VALUES (:1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13, :14)

可惜的是, 這個平均執行時間 14~15 秒的SQL, 並不是單純的登入驗證查詢而是不知道在何時觸發的管理性 INSERT! 因此這個方向不對。

Copilot也叫我去檢查v$lock裡是否有大量鎖定, 這也個條死巷子。

最後我問了Copilot一個問題: how to find the long rurn sql query?

它的回答, 給了我找到root cause的契機。

To identify long‑running SQL queries in Oracle, you can use several dynamic performance views. Here are the most effective approaches:

🔎 Methods to Find Long‑Running SQL

1. Active Sessions Currently Running

sql

SELECT s.sid,
       s.serial#,
       s.username,
       s.machine,
       q.sql_id,
       q.sql_text,
       q.elapsed_time/1000000 AS elapsed_sec,
       q.executions
FROM   v$session s
JOIN   v$sql q ON s.sql_id = q.sql_id
WHERE  s.status = 'ACTIVE'
ORDER BY elapsed_sec DESC;

我在網站應用程式卡住的時候去跑這支SQL查詢, 就看到一個可疑的長執行SQL: select * from dual@yyy

而yyy正是我們網站應用程式有用到的database link名稱, 再去檢查該資料庫連結名稱的定義, 發現其定義只是一個簡單的名稱, 應該是以前用手動指定在(現已故障放棄不用的)Domain Controller的DNS對應。

因此, 將該資料庫連結名稱定義修改後, 問題就解決了。

搜尋此網誌

雨恩的生活日誌