死連線_linux_OS處理機制
在複雜的應用環境下,我們經常會遇到一些非常複雜並且有意思的問題,例如,我們會遇到網路異常(網路掉包、無線網路斷線)、客戶端程式異常(例如應用程式崩潰Crash)、作業系統藍屏、客戶端電腦掉電、當機重啟等異常情況,此時資料庫連線可能都沒有正常關閉(Colse)、事務都沒有提交,連線(connections)就斷開了。如果遇到這些情況,你未提交的一個事務在資料庫中是否會回滾? 如果回滾,什麼條件才會觸發回滾?需要多久才會觸發回滾(不是回滾需要多少時間)?如果是一個查詢呢,那麼情況又是怎麼樣呢?ORACLE資料庫是否提供某些機制來解決這些問題呢?
處理死事務(死掉但沒有斷開的session),這個跟Linux系統的TCP keepalive有關係,我們先來看看TCP keepalive概念,如下
顧名思義,TCP keepalive它是用來儲存TCP連線的,注意它只適用於TCP連線。系統會替你維護一個timer,時間到了,就會向remote peer傳送一個probe package,當然裡面是沒有資料的,對方就會返回一個應答,這時你就知道這個通道保持正常。與TCP keepalive有關的三個引數tcp_keepalive_time、tcp_keepalive_intvl、tcp_keepalive_probes
[root@myln01uat ~]# cat /proc/sys/net/ipv4/tcp_keepalive_time
7200
[root@mylnx01uat ~]# cat /proc/sys/net/ipv4/tcp_keepalive_intvl
75
[root@mylnx01uat ~]# cat /proc/sys/net/ipv4/tcp_keepalive_probes
9
/proc/sys/net/ipv4/tcp_keepalive_time 當keepalive起用的時候,TCP傳送keepalive訊息的頻度。預設是2小時。
/proc/sys/net/ipv4/tcp_keepalive_intvl 當探測沒有確認時,keepalive探測包的傳送間隔。預設是75秒。
/proc/sys/net/ipv4/tcp_keepalive_probes 如果對方不予應答,keepalive探測包的傳送次數。預設值是9。
那麼在Oracle沒有啟用DCD時,系統和資料庫如何判斷一個連線是否異常,需要關閉呢?這個時間是這樣計算的,首先它等待了7200,然後每隔75秒傳送探測包,一共傳送了9次後(7200+ 75*9 = 7875 ),都沒有收到客戶端應答,那麼它就判斷這個連線死掉了,可以關閉了。所以這個值是一個固定值, 具體為7875, 當然不同的作業系統可能有所不同,取決於上面三個tcp_keepalive引數,過了7875秒後, 這個時候PMON程式就會回收與它相關的所有資源(例如回滾事務,釋放lock、latch、memory)。
處理死事務(死掉但沒有斷開的session),這個跟Linux系統的TCP keepalive有關係,我們先來看看TCP keepalive概念,如下
顧名思義,TCP keepalive它是用來儲存TCP連線的,注意它只適用於TCP連線。系統會替你維護一個timer,時間到了,就會向remote peer傳送一個probe package,當然裡面是沒有資料的,對方就會返回一個應答,這時你就知道這個通道保持正常。與TCP keepalive有關的三個引數tcp_keepalive_time、tcp_keepalive_intvl、tcp_keepalive_probes
[root@myln01uat ~]# cat /proc/sys/net/ipv4/tcp_keepalive_time
7200
[root@mylnx01uat ~]# cat /proc/sys/net/ipv4/tcp_keepalive_intvl
75
[root@mylnx01uat ~]# cat /proc/sys/net/ipv4/tcp_keepalive_probes
9
/proc/sys/net/ipv4/tcp_keepalive_time 當keepalive起用的時候,TCP傳送keepalive訊息的頻度。預設是2小時。
/proc/sys/net/ipv4/tcp_keepalive_intvl 當探測沒有確認時,keepalive探測包的傳送間隔。預設是75秒。
/proc/sys/net/ipv4/tcp_keepalive_probes 如果對方不予應答,keepalive探測包的傳送次數。預設值是9。
那麼在Oracle沒有啟用DCD時,系統和資料庫如何判斷一個連線是否異常,需要關閉呢?這個時間是這樣計算的,首先它等待了7200,然後每隔75秒傳送探測包,一共傳送了9次後(7200+ 75*9 = 7875 ),都沒有收到客戶端應答,那麼它就判斷這個連線死掉了,可以關閉了。所以這個值是一個固定值, 具體為7875, 當然不同的作業系統可能有所不同,取決於上面三個tcp_keepalive引數,過了7875秒後, 這個時候PMON程式就會回收與它相關的所有資源(例如回滾事務,釋放lock、latch、memory)。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/30126024/viewspace-2134379/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- tomcat連線處理機制和執行緒模型Tomcat執行緒模型
- Redis處理客戶端連線的內部實現機制RXRedis客戶端
- 異常處理機制
- Java——事件處理機制概要Java事件
- Java異常處理機制Java
- redis的事件處理機制Redis事件
- postgresql連線失敗如何處理SQL
- 行連線的處理方式指引
- windows 處理bat連線本地mysqlWindowsBATMySql
- Java 的異常處理機制Java
- 8.異常處理機制
- 08.異常處理機制
- java中的垃圾處理機制Java
- SpringMVC異常的處理機制SpringMVC
- java異常的處理機制Java
- C++異常處理機制C++
- Mysql如何處理死鎖MySql
- APM RUEI processor處理程式hang死處理方法
- 【Ansible】Ansible 連線主機顯示報錯的處理方案
- linux如何處理多連線請求?Linux
- Nginx 超時事件的處理機制Nginx事件
- Go語言錯誤處理機制Go
- Flink的視窗處理機制(一)
- Java 中的異常處理機制Java
- goang 錯誤&異常處理機制Go
- mysql事務處理與鎖機制MySql
- 異常處理機制(二)之異常處理與捕獲
- nodejs 連線 mysql 查詢事務處理NodeJSMySql
- 資料庫連線異常處理思路資料庫
- JDBC連線批量處理資料入庫JDBC
- SAP Connection inbound郵件接收處理機制
- 58同城 反爬蟲機制及處理爬蟲
- C#中的異常處理機制C#
- 原始碼分析:Android訊息處理機制原始碼Android
- Android應用程式訊息處理機制Android
- kafka 副本機制和容錯處理 -2Kafka
- 作業系統4——處理機排程與死鎖作業系統
- 部分藍芽耳機 電腦 連線 不暢 的處理辦法藍芽
- Netty(一) SpringBoot 整合長連線心跳機制NettySpring Boot