資訊專欄INFORMATION COLUMN
環(huán)境介紹：
操作系統(tǒng)：Redhat7.6
數(shù)據(jù)庫版本：19.9
是否RAC：是
是否CDB：否
ASM或文件系統(tǒng)：ASM
ADG主備庫節(jié)點數(shù)：均為2個
先簡單介紹下故障，某天發(fā)現(xiàn)主庫的節(jié)點1的日志無法傳輸至備庫，而節(jié)點2傳輸正常。在經(jīng)過相互ping，telnet及tnsping驗證之后，確認網(wǎng)絡正常。那究竟是咋回事呢？請聽下文詳細分解。
在主庫查看傳輸通道狀態(tài)，發(fā)現(xiàn)節(jié)點1的通道報ORA-01034:ORACLE not available：
去查看備庫狀態(tài)，確認都正常。為啥連不上呢？
是不是網(wǎng)絡有問題？于是在經(jīng)歷兩個節(jié)點相互ping，telnet及tnsping驗證，確認網(wǎng)絡網(wǎng)絡正常，排除網(wǎng)絡導致的問題。
我們嘗試在主庫節(jié)點sqlplus備庫節(jié)點發(fā)現(xiàn)異常。
主庫節(jié)點1sqlplus 備庫節(jié)點1時報ORA-01034:ORACLE not available，跟通道報錯一致。
并且從主庫節(jié)點1sqlplus 備庫節(jié)點2也一樣的報ORA-01034。這就解釋了為啥節(jié)點1為啥日志傳輸不過去了。但凡主庫節(jié)點1能連上一個備庫節(jié)點，都能把日志傳輸過去。因為通道里面設置的tnsname開啟了failover，連接備庫兩個節(jié)點的VIP。
在主庫節(jié)點2去sqlplus備庫節(jié)點1時連接正常：
但是主庫節(jié)點2去sqlplus備庫節(jié)點2時也報ORA-01034。
通過多次sqlplus我們發(fā)現(xiàn)偶爾會報ORA-12637。
既然主備庫都正常，網(wǎng)絡也正常。初步懷疑是客戶端出現(xiàn)問題。決定開啟sqlnetlevel 16進行跟蹤一下。
發(fā)現(xiàn)如下異常：
初步判斷是由于OOB導致。
OOB是啥?其是19C客戶端的新功能，如果網(wǎng)絡上允許超出范圍的中斷，將觸發(fā)服務器自動測試。
默認情況下處于啟用狀態(tài)。因此，當19c客戶端連接到服務器時，它將觸發(fā)服務器測試OOB，這可以在服務器端跟蹤中看到。nsaccept：檢查OOB支持。如果網(wǎng)絡不支持OOB，則OOB檢查將失敗。連接也會失敗。
故障解決方法：
在DB的sqlnet.ora中添加DISABLE_OOB=ON即可禁掉OOB自動檢測。主備庫所有節(jié)點添加之后，重啟通道恢復正常。
文章版權歸作者所有，未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/130043.html
摘要：李飛飛花名飛刀，阿里巴巴集團副總裁，高級研究員，達摩院首席數(shù)據(jù)庫科學家，阿里云智能事業(yè)群數(shù)據(jù)庫產(chǎn)品事業(yè)部負責人，杰出科學家。是阿里云的云原生數(shù)據(jù)庫，目前已有非常深厚的技術積累。 阿里妹導讀：云計算大潮來襲，傳統(tǒng)數(shù)據(jù)庫市場正面臨重新洗牌的情境，包括云數(shù)據(jù)庫在內(nèi)的一批新生力量崛起，動搖了傳統(tǒng)數(shù)據(jù)庫的壟斷地位，而由云廠商主導的云原生數(shù)據(jù)庫則將這種改變推向了高潮。 云時代的數(shù)據(jù)庫將面臨怎樣的...
DG備庫讀寫測試方案 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; margin:0...
閱讀 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
