增量資料丟失的原因分析（三)
今天開發的同事找到我說，他們發現一個應用今天應該會同步過來一部分資料，但是今天卻沒有，所以想讓我幫忙看看到底是怎麼回事。
對於這類需求也算是輕門熟路，不光維護管理資料，補資料也在行。看來今天又不可避免要修復資料了，不過還是得明白原因是什麼。
首先檢視了近幾天的資料同步情況，時間範圍是5月1日~5月6日，但是檢視卻唯獨缺少了5月5日的資料，因為是計算前一天的資料變化情況，所以5月6日應該會同步5月5日的資料變化。
TRUNC(UPDATE_DATE) COUNT(*)
------------------- ----------
2016-05-02 00:00:00 6724
2016-05-03 00:00:00 6198
2016-05-04 00:00:00 5772
2016-05-01 00:00:00 7268
至於資料為什麼沒有同步，確實有些奇怪，這個時候先來理一理資料同步的原理，其實這個庫是一個OLAP的庫，會從OLTP的庫中抓取變化的資料情況更新到OLAP的統計庫中。而同步的驅動方式是透過scheduler的方式來完成，每天凌晨會定時同步。
使用下面的方式來檢視最近10天的scheduler job的執行情況，發現只有今天執行失敗。
select log_date,owner,job_name,status,ADDITIONAL_INFO from DBA_SCHEDULER_JOB_LOG where log_date>sysdate-10 and owner='TEST' and job_name like '%USER%' ORDER BY 1 ;
LOG_DATE OWNER JOB_NAME STATUS
----------------------------------- -------------------------- -----------
27-APR-16 03.28.14.044366 AM +08:00 TEST SYN_USERCENTER SUCCEEDED
。。。
05-MAY-16 03.28.32.538013 AM +08:00 TEST SYN_USERCENTER SUCCEEDED
06-MAY-16 03.28.23.809575 AM +08:00 TEST SYN_USERCENTER FAILED
那麼問題就看起來有了方向，是由於scheduler job失敗導致的資料同步失敗。
到底是什麼原因導致的呢，可以檢視一個檢視來得到一些相關的資訊。
select log_date,owner,job_name,status,ADDITIONAL_INFO from DBA_SCHEDULER_JOB_RUN_DETAILS where log_date>sysdate-10 and owner='TEST' and job_name like '%USER%' ORDER BY 1 ;
得到的資訊是一個ORA錯誤：ORA-12170: TNS:Connect timeout occurred
這個時候使用tnsping的方式來連線那個目標庫，發現沒有了響應，超時退出。
而這個問題明白了原因之後，依然很蹊蹺，這個環境一直沒有動過，也沒有做過系統層面的網路變化，到底是什麼原因導致的呢。
對於這個問題，從資料庫層面，系統層面還真分析不出來什麼特別之處。所以就求助網路組的同學。
目前是10.11.133.128的伺服器去telnet 10.11.65.112的伺服器，但是透過幾次簡單的測試，在65.112端看到133.128的ip卻會有多種變化。有時候是10.11.133.128，有時候是10.11.134.129
# tcpdump -i eth0 host 10.11.133.128 and port 1528 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:49:57.314010 IP 10.11.133.128.51355 > 10.11.65.112.1528: Flags [F.], seq 1003407519, ack 3632754879, win 49640, length 0
16:49:57.314095 IP 10.11.65.112.1528 > 10.11.133.128.51355: Flags [F.], seq 1, ack 1, win 115, length 0
16:49:57.316199 IP 10.11.133.128.51355 > 10.11.65.112.1528: Flags [.], ack 2, win 49640, length 0
16:49:59.098833 IP 10.11.133.128.51382 > 10.11.65.112.1528: Flags [S], seq 1012926596, win 49640, options [mss 1460,nop,wscale 0,nop,nop,sackOK], length 0
16:49:59.098877 IP 10.11.65.112.1528 > 10.11.133.128.51382: Flags [S.], seq 233530546, ack 1012926597, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:49:59.101376 IP 10.11.133.128.51382 > 10.11.65.112.1528: Flags [.], ack 1, win 49640, length 0
# tcpdump -i eth0 host 10.11.134.129 and port 1528 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:41:25.055791 IP 10.11.134.129.50758 > 10.11.65.112.1528: Flags [S], seq 778963631, win 49640, options [mss 1460,nop,wscale 0,nop,nop,sackOK], length 0
16:41:25.055848 IP 10.11.65.112.1528 > 10.11.134.129.50758: Flags [S.], seq 3056729568, ack 778963632, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:41:30.126448 IP 10.11.65.112.1528 > 10.11.134.129.50758: Flags [S.], seq 3056729568, ack 778963632, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:41:30.211652 IP 10.11.134.129.50758 > 10.11.65.112.1528: Flags [R], seq 778963632, win 49640, length 0
對於這種情況，檢視了133.128的網路卡配置情況，e1000g0存在一個漂移的IP,即10.11.133.128，而另外一個IP 10.11.134.129則來自一個新的網路卡e1000g1
e1000g0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 10.11.133.129 netmask ffffff00 broadcast 10.11.133.255
e1000g0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 10.11.133.128 netmask ffffff00 broadcast 10.11.133.255
e1000g1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 10.11.134.129 netmask ffffff00 broadcast 10.11.134.255
檢視路由的資訊，可以看到目前是存在兩個預設路由，分別從133,134網段進行過濾。
$netstat -rn
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ---------- ---------
default 10.11.133.254 UG 1 28179
default 10.11.134.254 UG 1 28129
10.11.133.0 10.11.133.128 U 1 7961 e1000g0:1
10.11.133.0 10.11.133.129 UG 1 0
10.11.134.0 10.11.134.129 U 1 1308 e1000g1
224.0.0.0 10.11.133.129 U 1 0 e1000g0
而這個也是目前導致測試中發現源端的IP一會是133.128，一會又是134.129
當然還有更多的網路內容我也沒接受得了。不過可以看出網路這塊還是存在著一小竅門。
最終在65.112開通了這兩個IP的防火牆之後，看起來問題是初步解決了，後續還需要更多的驗證。
而留給我的就是修復資料，這個還是需要結合裡面的業務來根據需求來補充那部分沒有同步的資料。
對於這類需求也算是輕門熟路，不光維護管理資料，補資料也在行。看來今天又不可避免要修復資料了，不過還是得明白原因是什麼。
首先檢視了近幾天的資料同步情況，時間範圍是5月1日~5月6日，但是檢視卻唯獨缺少了5月5日的資料，因為是計算前一天的資料變化情況，所以5月6日應該會同步5月5日的資料變化。
TRUNC(UPDATE_DATE) COUNT(*)
------------------- ----------
2016-05-02 00:00:00 6724
2016-05-03 00:00:00 6198
2016-05-04 00:00:00 5772
2016-05-01 00:00:00 7268
至於資料為什麼沒有同步，確實有些奇怪，這個時候先來理一理資料同步的原理，其實這個庫是一個OLAP的庫，會從OLTP的庫中抓取變化的資料情況更新到OLAP的統計庫中。而同步的驅動方式是透過scheduler的方式來完成，每天凌晨會定時同步。
使用下面的方式來檢視最近10天的scheduler job的執行情況，發現只有今天執行失敗。
select log_date,owner,job_name,status,ADDITIONAL_INFO from DBA_SCHEDULER_JOB_LOG where log_date>sysdate-10 and owner='TEST' and job_name like '%USER%' ORDER BY 1 ;
LOG_DATE OWNER JOB_NAME STATUS
----------------------------------- -------------------------- -----------
27-APR-16 03.28.14.044366 AM +08:00 TEST SYN_USERCENTER SUCCEEDED
。。。
05-MAY-16 03.28.32.538013 AM +08:00 TEST SYN_USERCENTER SUCCEEDED
06-MAY-16 03.28.23.809575 AM +08:00 TEST SYN_USERCENTER FAILED
那麼問題就看起來有了方向，是由於scheduler job失敗導致的資料同步失敗。
到底是什麼原因導致的呢，可以檢視一個檢視來得到一些相關的資訊。
select log_date,owner,job_name,status,ADDITIONAL_INFO from DBA_SCHEDULER_JOB_RUN_DETAILS where log_date>sysdate-10 and owner='TEST' and job_name like '%USER%' ORDER BY 1 ;
得到的資訊是一個ORA錯誤：ORA-12170: TNS:Connect timeout occurred
這個時候使用tnsping的方式來連線那個目標庫，發現沒有了響應，超時退出。
而這個問題明白了原因之後，依然很蹊蹺，這個環境一直沒有動過，也沒有做過系統層面的網路變化，到底是什麼原因導致的呢。
對於這個問題，從資料庫層面，系統層面還真分析不出來什麼特別之處。所以就求助網路組的同學。
目前是10.11.133.128的伺服器去telnet 10.11.65.112的伺服器，但是透過幾次簡單的測試，在65.112端看到133.128的ip卻會有多種變化。有時候是10.11.133.128，有時候是10.11.134.129
# tcpdump -i eth0 host 10.11.133.128 and port 1528 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:49:57.314010 IP 10.11.133.128.51355 > 10.11.65.112.1528: Flags [F.], seq 1003407519, ack 3632754879, win 49640, length 0
16:49:57.314095 IP 10.11.65.112.1528 > 10.11.133.128.51355: Flags [F.], seq 1, ack 1, win 115, length 0
16:49:57.316199 IP 10.11.133.128.51355 > 10.11.65.112.1528: Flags [.], ack 2, win 49640, length 0
16:49:59.098833 IP 10.11.133.128.51382 > 10.11.65.112.1528: Flags [S], seq 1012926596, win 49640, options [mss 1460,nop,wscale 0,nop,nop,sackOK], length 0
16:49:59.098877 IP 10.11.65.112.1528 > 10.11.133.128.51382: Flags [S.], seq 233530546, ack 1012926597, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:49:59.101376 IP 10.11.133.128.51382 > 10.11.65.112.1528: Flags [.], ack 1, win 49640, length 0
# tcpdump -i eth0 host 10.11.134.129 and port 1528 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:41:25.055791 IP 10.11.134.129.50758 > 10.11.65.112.1528: Flags [S], seq 778963631, win 49640, options [mss 1460,nop,wscale 0,nop,nop,sackOK], length 0
16:41:25.055848 IP 10.11.65.112.1528 > 10.11.134.129.50758: Flags [S.], seq 3056729568, ack 778963632, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:41:30.126448 IP 10.11.65.112.1528 > 10.11.134.129.50758: Flags [S.], seq 3056729568, ack 778963632, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:41:30.211652 IP 10.11.134.129.50758 > 10.11.65.112.1528: Flags [R], seq 778963632, win 49640, length 0
對於這種情況，檢視了133.128的網路卡配置情況，e1000g0存在一個漂移的IP,即10.11.133.128，而另外一個IP 10.11.134.129則來自一個新的網路卡e1000g1
e1000g0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 10.11.133.129 netmask ffffff00 broadcast 10.11.133.255
e1000g0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 10.11.133.128 netmask ffffff00 broadcast 10.11.133.255
e1000g1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 10.11.134.129 netmask ffffff00 broadcast 10.11.134.255
檢視路由的資訊，可以看到目前是存在兩個預設路由，分別從133,134網段進行過濾。
$netstat -rn
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ---------- ---------
default 10.11.133.254 UG 1 28179
default 10.11.134.254 UG 1 28129
10.11.133.0 10.11.133.128 U 1 7961 e1000g0:1
10.11.133.0 10.11.133.129 UG 1 0
10.11.134.0 10.11.134.129 U 1 1308 e1000g1
224.0.0.0 10.11.133.129 U 1 0 e1000g0
而這個也是目前導致測試中發現源端的IP一會是133.128，一會又是134.129
當然還有更多的網路內容我也沒接受得了。不過可以看出網路這塊還是存在著一小竅門。
最終在65.112開通了這兩個IP的防火牆之後，看起來問題是初步解決了，後續還需要更多的驗證。
而留給我的就是修復資料，這個還是需要結合裡面的業務來根據需求來補充那部分沒有同步的資料。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-2095153/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 增量資料丟失的原因分析
- 增量資料丟失的原因分析（二)
- 硬碟資料丟失原因和解決方案/資料恢復方法硬碟資料恢復
- 虛擬機器未知原因丟失的資料恢復案例虛擬機資料恢復
- 磁碟陣列資料丟失的7個常見原因介紹陣列
- 建站失敗的原因分析
- Kafka零資料丟失的配置方案Kafka
- 如何找回分割槽丟失的資料
- 資料檔案丟失的恢復
- JavaScript精度丟失原因以及解決方案JavaScript
- Session莫名丟失的原因及解決辦法Session
- dg丟失歸檔，使用rman增量備份恢復
- 利用增量備份恢復gap歸檔丟失DG
- 硬碟資料丟失如何恢復？硬碟
- 資料檔案損壞、丟失
- 模擬資料檔案丟失
- 分割槽丟失資料恢復資料恢復
- chkdsk 後資料丟失的恢復方法
- Verdaccio publish 時包含 deprecated 導致歷史版本丟失問題原因分析
- 儲存互斥失敗導致資料丟失的資料恢復成功案例資料恢復
- 利用增量備份恢復因歸檔丟失造成的DG gap
- TSPITR方式資料庫找回誤操作丟失的資料資料庫
- 華納雲：防止資料庫資料丟失的幾個方法資料庫
- RMAN完全恢復丟失的資料檔案
- 普通資料檔案丟失的恢復方法
- 恢復REDO Log丟失的Oracle資料庫Oracle資料庫
- 資料檔案丟失損壞的恢復--
- session丟失與解決辦法的資料Session
- SQLServer複製到execl丟失資料SQLServer
- Elasticsearch如何保證資料不丟失？Elasticsearch
- dfm檔案資料丟失問題
- 資料檔案丟失如何恢復
- 如何找回U盤分割槽丟失的資料？詳細演示三步驟
- 使用RMAN增量備份處理Dataguard因歸檔丟失造成的gap
- 伺服器xfs資料丟失的資料恢復過程伺服器資料恢復
- ． 資料庫臨時表空間的資料檔案的丟失資料庫
- 織夢資料庫連線失敗的原因資料庫
- 如何從SSD固態硬碟救援丟失的資料硬碟