摘要：問題九庫控制文件擴(kuò)展報(bào)錯(cuò)庫的擴(kuò)展報(bào)錯(cuò)，用的是裸設(shè)備，和還是原來大小，主庫的沒有報(bào)錯(cuò)，并且大小沒有變，求解釋。專家解答從報(bào)錯(cuò)可以看出，控制文件從個(gè)塊擴(kuò)展到個(gè)塊時(shí)報(bào)錯(cuò)，而裸設(shè)備最大只支持個(gè)塊，無法擴(kuò)展，可以嘗試將參數(shù)改小，避免控制文件報(bào)錯(cuò)。

鏈接描述引言

近期我們?cè)贒BASK小程序新關(guān)聯(lián)了運(yùn)維之美、高端存儲(chǔ)知識(shí)、一森咖記、運(yùn)維咖啡吧等數(shù)據(jù)領(lǐng)域的公眾號(hào)，歡迎大家閱讀分享。

問答集萃

接下來，我們分享本期整理出的問題和診斷總結(jié)，供大家參考學(xué)習(xí)，詳細(xì)的診斷分析過程可以通過標(biāo)題鏈接跳轉(zhuǎn)到小程序中查看。

問題一、對(duì)于temp表空間爆滿情況，怎么處理？
undo temp表空間很大，我的思路是增大表空間大小或者，新建個(gè)temp1，然后默認(rèn)的制定新建temp1，但是我感覺這樣還會(huì)滿。正常思路怎么處理這種undo temp表空間大問題？
診斷結(jié)論：最根本的方法是去優(yōu)化占用temp和undo多的sql，比如排序多的、執(zhí)行時(shí)間長的sql等等。結(jié)合自己的環(huán)境設(shè)置合理的temp和undo空間，一般是給核心業(yè)務(wù)用戶多帶帶的temp表空間，以免其他誤操作對(duì)核心業(yè)務(wù)影響。另外這兩個(gè)表空間是不會(huì)釋放的，也就是隨著業(yè)務(wù)的運(yùn)行使用率會(huì)越來越大，最后接近100%，一般如果沒有報(bào)ora-01555和無法擴(kuò)容temp表空間的錯(cuò)誤可以忽略表空間使用率。

問題二、extended cluster在一個(gè)站點(diǎn)故障時(shí)，存活站點(diǎn)內(nèi)實(shí)例的處理流程
存活站點(diǎn)實(shí)例處理此故障的流程，以及預(yù)估一般需要多長時(shí)間恢復(fù)服務(wù)能力。
診斷結(jié)論：以兩種典型故障為例，1、兩邊數(shù)據(jù)庫均承載業(yè)務(wù)，任何一邊發(fā)生故障，則由另一邊承載所有業(yè)務(wù)，無須進(jìn)行主備站點(diǎn)切換。故障站點(diǎn)原先承載的用戶會(huì)話在幾分鐘內(nèi)由其他存活節(jié)點(diǎn)接管，體驗(yàn)上會(huì)有一些卡頓，這個(gè)與普通RAC節(jié)點(diǎn)故障一樣，某個(gè)實(shí)例發(fā)生故障后，集群reconfiguration，應(yīng)用TAF。2、若站點(diǎn)間的心跳線中斷，則由第三站點(diǎn)的仲裁盤決定驅(qū)逐哪個(gè)站點(diǎn)，哪個(gè)站點(diǎn)存活。被驅(qū)逐站點(diǎn)原先承載的用戶在體驗(yàn)上會(huì)有幾分鐘的卡頓。

問題三、Oracle 12c OEM upgrade to 13c
升級(jí)本端服務(wù)器agent 流程。
診斷結(jié)論：這個(gè)要看具體的版本，就算從12.1.0.1到12.1.0.5都需要先升級(jí)到12.1.0.3再升級(jí)到12.1.0.5，12到13直接升級(jí)支持最低版本是12.1.0.5，其他都需要先升級(jí)到中間版本。GC升級(jí)完之后，直接在GC管理頁面升級(jí)agent即可。

問題四、Oracle數(shù)據(jù)庫第一次訪問卡死
系統(tǒng)頁面后臺(tái)連接oracle數(shù)據(jù)庫，第一次訪問系統(tǒng)時(shí)候，頁面框架都能出來，但是需要調(diào)數(shù)據(jù)庫顯示數(shù)據(jù)的地方一直在轉(zhuǎn)圈，也不報(bào)錯(cuò)，再次刷新頁面的時(shí)候數(shù)據(jù)就出來，請(qǐng)問一下這是數(shù)據(jù)庫什么參數(shù)設(shè)置影響的嗎？
診斷結(jié)論：這個(gè)還是得從應(yīng)用著手，debug打開看下哪里出現(xiàn)了問題。對(duì)于數(shù)據(jù)庫來說，只是存在第一次執(zhí)行SQL需要解析、讀取磁盤數(shù)據(jù)緩存到內(nèi)存，第二次執(zhí)行就直接從內(nèi)存取數(shù)據(jù)，速度上會(huì)快一些。另外這個(gè)現(xiàn)象很有可能是連接到數(shù)據(jù)庫的長連接由于長時(shí)間未進(jìn)行數(shù)據(jù)交互，被網(wǎng)關(guān)或防火墻斷開，因此第一次訪問的時(shí)候會(huì)等待一個(gè)TNS超時(shí)。可以讓應(yīng)用增加日志的輸出，看看問題是否發(fā)生在獲取數(shù)據(jù)庫連接后運(yùn)行第一個(gè)SQL的地方。如果是這個(gè)問題，解決思路是修改網(wǎng)關(guān)或防火墻的配置，避免中斷空閑連接。或者在數(shù)據(jù)庫中配置死連接檢查DCD。

問題五、卸載完DB，如何完全卸載GI
卸載grid，運(yùn)行第二個(gè)root腳本報(bào)錯(cuò)，估計(jì)是因?yàn)閍sm實(shí)例沒有關(guān)閉必須是有一個(gè)要保持開啟。之手用sysasm關(guān)閉所有asm實(shí)例再運(yùn)行還是報(bào)錯(cuò)，執(zhí)行./crsctl stat res -t 發(fā)現(xiàn).dg .proxy_advm .asm等資源雖然變offline但是ora.ASMNET1LSNR_ASM.lsnr還是online，crsctl stop crs也執(zhí)行不了如何解決？
診斷結(jié)論：嘗試強(qiáng)制停止：crsctl stop crs -f，再deconfig -force和deinstall，詳細(xì)步驟請(qǐng)查看詳情。

問題六、9.2.0.8 aix 升級(jí)11.2.0.4 aix升級(jí)后需要檢查什么
參考《手動(dòng)升級(jí)到 Oracle Database 11gR2 (11.2)的完整核對(duì)清單 (文檔 ID 1674333.1)》進(jìn)行升級(jí)，其中timezone不升級(jí)。升級(jí)后除了檢查升級(jí)日志，后臺(tái)日志，用戶對(duì)象。
診斷結(jié)論：優(yōu)化器從RBO到CBO，改變很大，確保應(yīng)用在生產(chǎn)數(shù)據(jù)庫升級(jí)前已經(jīng)做過了充分的SPA測(cè)試。

問題七、win安裝10g報(bào)錯(cuò)Ora-12546 tns:permission denied
Windows 2012 r2 64位系統(tǒng)安裝10.2.0.4的數(shù)據(jù)庫64位，總會(huì)出現(xiàn)這個(gè)報(bào)錯(cuò)，要么是dbca的時(shí)候，要么就是建完數(shù)據(jù)庫，一重啟服務(wù)器之后，sqlplus也登陸不了報(bào)錯(cuò)。嘗試了一下安裝了10.2.0.5的補(bǔ)丁的話就沒在出現(xiàn)這問題，反復(fù)試了幾次，這個(gè)是bug么？
診斷結(jié)論：這個(gè)是因?yàn)镺racle 10.2.0.4發(fā)行的時(shí)候，Windows 7都還沒有出，而從Windows 7開始（甚至是更早的Windwos Vista開始），Windows的權(quán)限體系出現(xiàn)了非常大的變化，而早期的Oracle版本并不能適應(yīng)這種新環(huán)境，所以會(huì)出各種各樣的問題。用新版本就好了，如你說的Oracle 10.2.0.5，該小版本正好解決這個(gè)環(huán)境問題，所以就沒問題了。

問題八、oracle數(shù)據(jù)庫平臺(tái)兼容性列表
Oracle各個(gè)版本操作系統(tǒng)兼容性列表
診斷結(jié)論：可以參考https://docs.oracle.com/en/da...，每個(gè)版本都有不同的支持列表，在官方文檔上可以查到。

問題九、dg庫控制文件擴(kuò)展報(bào)錯(cuò)
dg庫的control1擴(kuò)展報(bào)錯(cuò)，用的是裸設(shè)備，2和3還是原來大小，主庫的沒有報(bào)錯(cuò)，并且大小沒有變，求解釋。
專家解答：從ALERT報(bào)錯(cuò)可以看出，控制文件從8050個(gè)塊擴(kuò)展到13168個(gè)塊時(shí)報(bào)錯(cuò)，而裸設(shè)備最大只支持8050個(gè)塊，無法擴(kuò)展，可以嘗試將參數(shù)CONTROL_FILE_RECORD_KEEP_TIME改小，避免控制文件報(bào)錯(cuò)。

問題十、sql調(diào)條件中where1=1，基于不同的優(yōu)化器cbo會(huì)走索引，而rbo則不會(huì)
應(yīng)用中經(jīng)常能夠看到where1=1的條件。請(qǐng)問，為什么在不同的優(yōu)化器下，rbo不會(huì)走索引而是全掃？
診斷結(jié)論：與where 1=1沒有關(guān)系，這個(gè)SQL相當(dāng)于沒有where條件。RBO是定義死的一套規(guī)則，只有在MAX和MIN索引列時(shí)才會(huì)走索引全掃，也不會(huì)去看統(tǒng)計(jì)信息。

問題十一、OGG 11.2無法使用format release 12.3
高版本OGG傳遞文件到11.2，傳遞失敗，試過加參數(shù)format release，不行，高版本OGG傳遞文件到12.1，應(yīng)用失敗，試過加參數(shù)format release，不行。求一份OGG版本兼容。
診斷結(jié)論：建議源端、目標(biāo)端最好用同一版本。目前從官方文檔來看，10、11、12都可以通過FORMAT RELEASE參數(shù)來兼容，除了CDB必須要求12.3以上外。

想了解更多知識(shí)點(diǎn)嗎？
那就登錄“墨天輪”了解學(xué)習(xí)吧~