本文由 dbaplus 社羣授權轉載。
背景
去年Oracle 19C發佈，作爲最新的Oracle發佈版，我們的客戶也開始有計劃將數據庫從11G之類的舊版本慢慢遷移到19C上。最近，在客戶的現場環境下進行了19C的安裝和配置，經歷了一系列的坑與填坑過程，本文分享給大家。
先介紹環境：
- 操作系統：Redhat 7.6
- Oracle數據庫版本：19.7
- 是否RAC：是
奇妙的網絡配置
安裝硬件分配入手，先按慣例將操作系統相關參數配置修改了一遍。一切準備就緒，開始安裝GI。前面一段相安無事，結果在運行root.sh的時候，問題來了：
運行root.sh在第18步進行節點配置時報啓動ora.qosmserver失敗。
查看rootcrs日誌如下：
日誌也只顯示qosmserver打不開，並沒有其它有效的信息，上網搜索也沒有什麼相關的案例。另一臺機器安裝GI也報相同的錯誤，沒辦法只好求助於MOS了。
結果還真找到一篇類似的12.2 root.sh fails with CLSRSC-1102: failed to start resource ‘qosmserver’ (Doc ID 2253718.1)。
但是報錯跟我們有點區別：
該文章介紹由於ipv6 ::1/128地址未配置導致，配置即可解決。
看到這裏，想到會不會是由於網絡配置的原因呢？當即查看了/etc/hosts，發現::1這一行被註釋了。
嘗試把註釋取消，重新運行root.sh成功。
詭異的文件權限
安裝完成後，需要安裝相應的補丁。安裝補丁前，按照多年來因喫過的虧養成的習慣，將OraInventory、Oralce_home、GI_HOME等相關目錄統統打個包備份一遍。事後發現這個習慣非常有用，因爲在安裝補丁這一步又卡住了。
報錯如下：
從以上信息我們可以看到補丁在DB HOME已經成功應用，但是在GI HOME應用時失敗，報/oracle/app/oraInventory/ContentsXML/oui-patch.xml文件權限問題。我們查看文件權限發現問題所在，同組grid用戶該文件無寫權限。
將補丁回滾失敗後，把之前備份還原回來發現補丁安裝之前是沒有這個文件的。由此我們可以估計oui-patch.xml是在DB HOME進行補丁升級時派生的。
再次進行補丁升級時，發現oui-patch.xml已生成，用root緊急給oui-patch.xml賦予664權限（注：只要文件一旦生成，需立即賦權），補丁升級成功。
此外，在CRS alert日誌中我們發現節點會去檢查所有節點的文件。日誌中發現部分文件不存在報錯信息。前往各節點查看這些文件，確認在所有節點都不存在。
信息如下：
通過覈查集羣及數據庫均確認正常的情況下，估計是我們沒用上的一些功能，這些報錯暫時先忽略。
IPV6
客戶網絡很快開始着手改造爲IPV6，趁着這個機會，我們也配置Oracle的IPV6網絡。先確認一下操作系統層面是否打開IPV6，下面是Linux下兩種常見的方法：
1、通過查看網卡屬性確定
ifconfig-a
命令輸出有“inet6…“的表示開啓了IPV6功能。
2、通過內核模塊加載信息查看
lsmod| grep ipv6
確認打開IPV6後，需要自定義地址，修改網卡配置文件，新增內容如下：
我們這裏設置了兩個地址，一個主用，一個備用。
重啓網絡生效，通過ping6命令測試是否可以連通，也可以使用ping-6：
查找監聽文件listener.ora並進行修改，新增IPV6的監控地址與端口。需要注意監聽中IPV6端口須與IPV4端口不一致：
LISTENER=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER))(ADDRESS= (PROTOCOL = TCP)(HOST = 2020:db8:1000::200)(PORT =1601)(IP=FIRST))))
重啓監聽之後查看結果如下：
接下來我們配個TNS連接串並進行測試連接成功：
至此，IPV6的網絡配置完成。
小結
在可見的未來，其實越來越多的數據庫會遷移到雲上，Oracle近幾年也在大張旗鼓地進行雲化。這些傳統DBA的安裝、配置工作量慢慢在減少，但是作爲一種基礎能力我們還是需要熟練掌握的。
作者介紹：
梁銘圖，新炬網絡首席架構師，十多年數據庫運維、數據庫設計、數據治理以及系統規劃建設經驗，擁有Oracle OCM、Togaf企業架構師（鑑定級）、IBM CATE等認證，曾獲dbaplus年度MVP以及華爲雲MVP等榮譽，並參與數據資產管理國家標準的編寫工作。在數據庫運維管理和架構設計、運維體系規劃、數據資產管理方面有深入研究。
原文鏈接：