8：30點接到一線支援兄弟電話，生產線出現個別線別部分工站disconnect現象、用戶暴跳......接到電話後、聯繫一線現象描述、根據應用的特性，初步判斷為應用回應時間過長、出現等待佇列，當佇列過多時就會出現disconnect、並自動連接上的問題。

       判斷確認步驟：

1、第一步還是檢查伺服器硬體資源是否充裕，Table segment所在tablespace使用率，UNDO空間。（良好）

2、Check alert.ora文件。（無警告資訊）

3、利用AWR分析7:45---8:30 之間DB效能，發現該應用INSERT數據830000次、回應時間平均為0.17S  （注意點，正常情況下該SQL回應時間<0.05S）----與初步判斷基本吻合

4、查看該TABLE SEGMENT大小（在OLTP COMPRESS情況下150GB）、資料量（恐怖的資料25億）、INDEXES SEGMENTS  （4個INDEXES共200GB）

       電話聯繫應用開發部門以及用戶，瞭解到最近趕貨，資料量會大量提升。跟開發部兄弟瞭解4個INDEXES的用途、發現該表主要用來記錄資訊查詢很少；大膽提議為不影響生產，將INDEXES DISABLE處理。

至此基本解決disconnect問題，跟用戶協商將該表線上資料由線上3個月降低到2個月