資訊專欄INFORMATION COLUMN
最近工作中又遇到因時間問題導致的故障，這讓本新四有好青年想起了N年前的一個案例，今天整理分享一下。當時是應用反應主機時間與正確的時間相差有8分多鐘，影響了正常的業務，登錄發現主機的NTP服務是開啟的，查看NTP同步狀態：
可以看到offset是0.051s,基本沒有延遲，那么問題就出在Ntpserver時間存在不準確的可能，通過主機側查看，果然server端存在延遲的情況。
為盡快恢復業務，通過以下方式來處理時間延遲，停止NTP服務更改服務端到一個正常的NTP服務器，在不停庫的情況下，手工微調時間，來追平發生的延遲，步驟如下：
1.停止NTP服務修改服務器地址
#/etc/init.d/ntpd stop
#vi /etc/ntp.conf
# Enable writing of statisticsrecords.
#statistics clockstats cryptostatsloopstats peerstats
#server 172.72.20.131 prefer minpoll6 maxpoll 6
server 10.19.244.52 prefer minpoll 6maxpoll 6
logfile /var/log/dsware_ntp.log.0
2.每半分鐘調一次，等半分鐘，再調一次
date -s "10:41:002017-01-06";clock -w
date -s "10:42:002017-01-06";clock -w
date -s "10:43:002017-01-06";clock -w
date -s "10:44:002017-01-06";clock -w
date -s "10:45:002017-01-06";clock -w
date -s "10:46:002017-01-06";clock -w
date -s "10:47:002017-01-06";clock -w
date -s "10:48:002017-01-06";clock -w
date -s "10:49:002017-01-06";clock -w
date -s "10:50:002017-01-06";clock -w
date -s "10:51:002017-01-06";clock -w
date -s "10:52:002017-01-06";clock -w
date -s "10:53:002017-01-06";clock -w
date -s "10:54:002017-01-06";clock -w
date -s "10:55:002017-01-06";clock -w
date -s "10:56:002017-01-06";clock -w
date -s "10:57:002017-01-06";clock -w
date -s "10:58:002017-01-06";clock -w
3. 啟動NTP服務
#/etc/init.d/ntpd start
以上操作在一個數據庫主機上正常執行后，數據庫沒有發生任何異常的情況。
由于某種不便明說原因，在調整另一臺數據庫主機服務器時間時，主機工程師手動調整server時間到正確時間，然后又通過ntpdate調整數據庫服務器時間追平服務端。結果是數據庫主機調整了8分多鐘的時間跨度，當調整完成后，悲劇就發生了，數據庫宕機，如下：
ALERT報錯：
Fri Jan 06 11:33:30 2017
Errors in file/oracle_log/diag/rdbms/orcl/orcl2/trace/orcl2_asmb_67035.trc:
ORA-15064: communication failurewith ASM instance
ORA-03113: end-of-file oncommunication channel
Process ID:
Session ID: 90 Serial number: 56760
Fri Jan 06 11:33:30 2017
Errors in file/oracle_log/diag/rdbms/orcl/orcl2/trace/orcl2_asmb_67035.trc:
ORA-15064: communication failurewith ASM instance
ORA-03113: end-of-file oncommunication channel
Process ID:
Session ID: 90 Serial number: 56760
USER (ospid: 67035): terminating theinstance due to error 15064
Fri Jan 06 11:33:30 2017
opiodr aborting process unknownospid (22340) as a result of ORA-1092
Fri Jan 06 11:33:30 2017
ORA-1092 : opitsk aborting process
報錯無法與ASM實例發生通信，那么接下來我們查看ASM的ALERT日志。
2016-12-27 23:05:53.756000 +08:00
Warning: VKTM detected a time drift.
Time drifts can result in anunexpected behavior such as time-outs. Please check trace file formore details.
2017-01-06 11:33:30.143000 +08:00
WARNING: client[+ASM1:+ASM:c5ogx2-cluster] not responsive for 494s;state=0x1. pid 121601
NOTE: umbilicus traces dumped to/oracle_log/diag/asm/+asm/+ASM1/trace/+ASM1_gen0_97907.trc
WARNING: client[orcl2:orcl:c5ogx2-cluster] not responsive for 494s; state=0x1.killing pid 67039
NOTE: umbilicus traces dumped to/oracle_log/diag/asm/+asm/+ASM1/trace/+ASM1_gen0_97907.trc
WARNING: fencing client[orcl2:orcl:c5ogx2-cluster] after 494 seconds (mbr 1)
WARNING: ASMB has not responded for494 seconds
NOTE: ASM umbilicus running slowerthan expected, ASMB diagnostic requested after 494 seconds
NOTE: ASMB process state dumped totrace file /oracle_log/diag/asm/+asm/+ASM1/trace/+ASM1_gen0_97907.trc
ERROR: terminating instance becauseASMB is stuck for 494 seconds
System State dumped to trace file/oracle_log/diag/asm/+asm/+ASM1/trace/+ASM1_gen0_97907.trc
2017-01-06 11:33:32.261000 +08:00
報錯，客戶端-cluster在494s內無法響應，導致ASMB阻塞終止了ASM實例，順理成章的，DB實例無法連接ASM實例，之后宕機。
查看指定TRACE文件內容如下：
*** 2017-01-06 11:33:32.261
GEN0 (ospid: 97907): terminating theinstance due to error 15082
ksuitm: waiting up to [5] secondsbefore killing DIAG(97913)
查看錯誤官方解釋：
[/home/oracle] oerr ora 15082
15082, 00000, "ASM failed tocommunicate with client"
// *Cause: There was a failureor time out when ASM tried to communicate with
// aconnected RDBMS or Oracle ASM Dynamic Volume Manager
// (OracleADVM) client.
// *Action: Check the accompanyingerror messages and alert logs
// formore information on the reason for the failure.
// Checksystem specific logs (/var/log/messages on Linux,
// EventLog on Windows) for Oracle ADVM messages.
通過錯誤提示，表明是ASM無法與客戶端通信，或超時，檢查相關日志，包括網絡層面，OS層面等日志。
Jan 6 11:21:34 c5ogx2bntpd[18672]: ntpd 4.2.6p5@1.2349-o Fri Oct 11 03:18:05 UTC 2013 (1)
當然也就是主機工程師做的ntpupdate操作。
發現日志中的超時494s,換算成分鐘，也就是8.33分鐘，正好是修改的時間跨度?；究梢源_診是大跨度修改主機時間導致的宕機。按照本好青年理解，這里正常的timeout時間，應該是<1秒的時間，當時由于時間調整，兩次獲取操作系統的時間大于了允許的超時時間，導致ASM誤認為有問題，為了數據一致性等考慮，選擇宕機保護。
所以，當我們需要調整數據庫主機時間，還是建議微調，禁止一次跨度太大，以上證明以半分鐘為調整跨度是比較合理方式之一。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/130191.html
摘要：分析師們預測，從年至年，零售主機托管的增長率將達到，批發數據中心市場的增長率將達到零售主機托管服務目前占有的市場份額，批發服務占據剩余的份額。據預測，這兩個因素的結合會促使亞太區的主機托管數據中心市場份額到年有望超過北美。 超大規模云提供商正從傳統數據中心提供商那里搶占越來越多的客戶工作負載，同時在獲取越來越多的數據中心容量，以托管運行那些工作負載，因而大幅改變全球主機托管數據中心市場的格局...
摘要：在年，數據中心以及公共云和私有云將會有什么樣的變化以下是我們的一些猜測。下面是我對數據中心和云的個預測。然而，這意味著數據中心也正在被重新調整其用途。數據中心正在發生變化，變得更加通用和強大。在2019年，數據中心以及公共云和私有云將會有什么樣的變化？以下是我們的一些猜測。又到了一年中做度假計劃的時候了，去購物中心看起來就像是《勇敢的心》當中的場景，在門口臺階上偷錢包的行為猖獗，而人們則努力...
摘要：相反，它曾無人看好困難重重，整個團隊甚至數度瀕臨解散。從危在旦夕到浴火重生，這十年經歷了什么今天，我們一起了解它背后不為人知的故事。在陽振坤看來，如果一件事情幾乎所有的人都認為它很重要需要做，這件事情就已經不是創新了。 showImg(https://segmentfault.com/img/remote/1460000019001650); 阿里妹導讀：談及國產自研數據庫，就不得不...
摘要：類是一個抽象類，由安排為一次執行或重復執行的任務。也是自帶的一個基于線程池設計的定時任務類。問題，則可以直接使用類實現自定義的定時調度規則。 定時調度作為后端開發人員，我們總會遇到這樣的業務場景：每周同步一批數據；每半個小時檢查一遍服務器運行狀況；每天早上八點給用戶發送一份包含今日待辦事項的郵件，等等。 這些場景中都離不開定時器，就像一個定好時間規則的鬧鐘，它會在指定時間觸發，執行我們...
閱讀 1346·2023-01-11 13:20
閱讀 1684·2023-01-11 13:20
閱讀 1132·2023-01-11 13:20
閱讀 1858·2023-01-11 13:20
閱讀 4100·2023-01-11 13:20
閱讀 2704·2023-01-11 13:20
閱讀 1385·2023-01-11 13:20
閱讀 3597·2023-01-11 13:20
