一次斷電後的TNS-12535: TNS: 操作超時錯誤的處理
一次斷電後的TNS-12535: TNS: 操作超時錯誤的處理
-----------------------------------下邊是廢話,可以先繞過!---------------------------------
最近北京晚上一直大暴雨,昨晚4點起來還是大暴雨,還好早上上班時停住了,不過沒了賣早點的了,於是就買了包子和豆漿急匆匆的擠進地鐵(本來地鐵人就多,而且還週一,人更多)….
看來我是來早了,第一個進公司,由於上週五跑指令碼,我的機子一直沒關..有點浪費電力資源哈~~我按部就班的進行資料庫日檢….
過了一會,一個同事來了,一開燈,咔~~一個燈泡燒壞了…從此悲劇開始上演..
可能一個保險跳閘了,找了物業,派了一個不是很專業的電工師傅在我們硬體工程師的眼皮子底下關了我們的總閘…尼瑪,那可是總閘呀,是你說關就能關的….
頓時,我聽見了那個工程師的抱怨聲了…
所有伺服器停掉了…此刻8:50左右吧,離9:15不遠了
突然,一同事把我從公司的晨會上拉了出來,說高頻庫連不上了,要趕緊處理..
-----------------------------------問題處理過程---------------------------------
以下是錯誤:
C:\Users\wangyl>tnsping M1HFDATASERVER
TNS Ping Utility for 32-bit Windows: Version 11.2.0.1.0 - Production on 15-8月 -
2011 09:59:58
Copyright (c) 1997, 2010, Oracle. All rights reserved.
已使用的引數檔案:
E:\app\wangyl\product\11.2.0\client_1\network\admin\sqlnet.ora
已使用 TNSNAMES 介面卡來解析別名
嘗試連線 (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.1
68.1.5)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = m1hf)))
TNS-12535: TNS: 操作超時
很明顯,此時oem是不行了,pl/sql dev也是不行了……
經過檢視;
日警日誌無報錯,相關日誌也正確。
ping是通的。
監聽狀態也正常。
IP也沒人改呀。
就是報TNS-12535: TNS: 操作超時的錯誤
於是,就看伺服器防火牆了,丫的你丫是enable。尼瑪那是enable呀!!
顯然問題就在這了…
暈~~~誰改的呢?我沒改呀…
先把他改回去再說,畢竟沒時間了…
後來才發現,原來那linux的伺服器是重啟後自動開啟防火牆的….尼瑪,害老子忙活一早!
把防火牆改成disable後一切正常!如下:
從我機子連如下:
C:\Users\wangyl>tnsping M1HFDATASERVER
TNS Ping Utility for 32-bit Windows: Version 11.2.0.1.0 - Production on 15-8月 -
2011 10:56:41
Copyright (c) 1997, 2010, Oracle. All rights reserved.
已使用的引數檔案:
E:\app\wangyl\product\11.2.0\client_1\network\admin\sqlnet.ora
已使用 TNSNAMES 介面卡來解析別名
嘗試連線 (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.1
68.1.5)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = m1hf)))
OK (0 毫秒)
從公司低頻庫連如下:
Microsoft Windows [版本 6.0.6002]
版權所有 (C) 2006 Microsoft Corporation。保留所有權利
C:\Users\_system>tnsping 192.168.1.5
TNS Ping Utility for 32-bit Windows: Version 11.2.0.1.0 - Production on 15-8月 -
2011 10:54:59
Copyright (c) 1997, 2010, Oracle. All rights reserved.
已使用的引數檔案:
D:\app\oracle_11g\_admin\product\11.2.0\dbhome_1\network\admin\sqlnet.ora
已使用 HOSTNAME 介面卡來解析別名
嘗試連線 (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST
=192.168.1.5)(PORT=1521)))
OK (10 毫秒)
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/26143577/viewspace-704855/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- TNS-12535: TNS:操作超時 錯誤解釋
- TNS-12535 TNS-00505的處理方法
- TNS-12541: TNS:no listener錯誤處理
- 一次scheduler錯誤的處理
- 處理可能超時的非同步操作非同步
- 搭建dataguard時,錯誤處理
- 一次ORA-01548錯誤的處理
- PHP安裝後錯誤處理PHP
- go的錯誤處理Go
- 一次ORA-00257錯誤的處理過程
- ORA-19693錯誤後的處理辦法
- TNS-12520 TNS-12519 連線錯誤處理
- TNS-12520 TNS-12519 連線錯誤處理
- axios 的錯誤處理iOS
- COM的錯誤處理 (轉)
- JavaScript 處理WebSocket的超時JavaScriptWeb
- 錯誤處理
- 記一次ora-04030錯誤的處理過程
- 啟動監聽報TNS-01150錯誤處理
- 【故障處理】修改maxuproc引數解決TNS-00519錯誤
- 如何處理CloudFoundry應用部署時遇到的254錯誤Cloud
- 請教 Element 的錯誤處理
- Restful API 中的錯誤處理RESTAPI
- 【譯】RxJava 中的錯誤處理RxJava
- grpc中的錯誤處理RPC
- JavaScript的錯誤簡易處理JavaScript
- 【LISTENER】Oracle監聽TNS-12545及TNS-00515錯誤處理一例Oracle
- 記一次業務人員誤刪資料後的處理方法
- ALERT日誌中常見監聽相關報錯之三:ORA-609 TNS-12537 and TNS-12547 or TNS-12170 TNS-12535錯誤的排查
- 一次網路連線錯誤的診斷
- PHP 錯誤處理PHP
- php錯誤處理PHP
- Go 錯誤處理Go
- Swift錯誤處理Swift
- Zabbix錯誤處理
- mysqldump錯誤處理MySql
- SAP CRM點了附件的超連結後報錯的處理方式
- 【故障處理】ORA-12162 錯誤的處理