資訊專欄INFORMATION COLUMN
親愛滴伙伴們！本萎專家又來了，今天咱來實(shí)踐19C的GI升級(jí)。
前面提到過，Oracle19C替代12C將成為oracle線條接下來這兩年的主要工作。本萎大濕所在客戶現(xiàn)場(chǎng)后續(xù)數(shù)據(jù)庫集成安裝都將以19C為標(biāo)準(zhǔn)版本。本篇就19C打最新的GIRU(19.7.0.0.200414)步驟及遇到的問題做總結(jié)分享。
補(bǔ)丁升級(jí)均采取滾動(dòng)升級(jí)方式進(jìn)行
打GIRU(19.7.0.0.200414)所需要的opatch版本為12.2.0.1.19及以上最新版本。建議使用19C版本進(jìn)行補(bǔ)丁升級(jí)，所以我們這次使用的opatch是19C，具體命令如下：
更換GI HOME的opatch版本:
su - grid
cd /oracle/app/19.3.0/grid/
cp /oraclelog/pa/opatch_20200622/p6880880_190000_Linux-x86-64.zip ./
mv OPatch OPatch_20200622
unzip p6880880_190000_Linux-x86-64.zip
chown -R grid:oinstall OPatch
chmod -R 775 OPatch
/oracle/app/19.3.0/grid/OPatch/opatch version
更換DB HOME的opatch版本:
su - oracle
cd /oracle/app/oracle/product/19.3.0/db
cp /oraclelog/pa/opatch_20200622/p6880880_190000_Linux-x86-64.zip ./
mv OPatch OPatch_20200622
unzip p6880880_190000_Linux-x86-64.zip
/u01/app/oracle/product/12.2.0.1/dbhome_1/OPatch/opatch version
該備份將作為補(bǔ)丁升級(jí)出錯(cuò)，rollback也報(bào)錯(cuò)時(shí)的最后救命稻草。備份app及oraInventory兩目錄即可。
ps -ef|grep LOCAL=NO|awk {print $2}|xargs kill -9
srvctl stop instance -d racdb -n racdb1
su - root
/oracle/app/19.3.0/grid/bin/crsctl stop crs
/oracle/app/19.3.0/grid/bin/crsctl stat res -t
tar -cvf /oraclelog/pa/opatch_20200622/gi_home_`hostname`_20200622.tar /oracle/app
tar -cvf /oraclelog/pa/opatch_20200622/oraInventory_`hostname`_20200622.tar /oracle/app/oraInventory
備份目錄為啥要停庫停CRS？部分看官們估計(jì)會(huì)有疑問。這個(gè)還得從很早之前一次Oracle11G GI PSU升級(jí)說起，當(dāng)時(shí)本萎大濕碰到這樣一種情況，在確認(rèn)當(dāng)時(shí)備份命令運(yùn)行正常，備份出來的文件大小正常情況下，在不停CRS的情況下備份出來的文件竟然不可用......還好當(dāng)時(shí)值得慶幸的是補(bǔ)丁回滾成功了。。所以這次“驚魂動(dòng)魄”之后這個(gè)備份都“唯經(jīng)驗(yàn)論”了。
啟動(dòng)crs,不起db
/oracle/app/19.3.0/grid/bin/crsctl start crs
/oracle/app/19.3.0/grid/bin/crsctl stat res -t
tail -100f /oracle/app/grid/diag/crs/*/crs/trace/alert*.log
補(bǔ)丁沖突分析
su - grid
opatch prereq CheckConflictAgainstOHWithDetail –phBaseDir /oraclelog/pa/opatch_20200622/30899722/30869156
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/30894985
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/30869304
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/30898856
su - oracle
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/30869156
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/30894985
su - root
cd /oraclelog/pa/opatch_20200622/30899722
/oracle/app/19.3.0/grid/OPatch/opatchauto apply /oraclelog/pa/opatch_20200622/30899722 -analyze
預(yù)計(jì)這里有的看官又有疑問了，為啥啟動(dòng)crs,不起db？升級(jí)過程GI會(huì)自動(dòng)把DB及CRS停下來并進(jìn)行目錄升級(jí)，這樣不是多此一舉嗎。各位看官應(yīng)該清楚，繁忙生產(chǎn)庫的DB因?yàn)椴l(fā)和繁忙程度是沒這么容易停下來的，一般作為老鳥來說，為了最大限度的萬無一失，都會(huì)手動(dòng)kill會(huì)話及手動(dòng)做checkpoint，switch logfile讓系統(tǒng)在自己眼皮子底下順利停下來。這樣做一來讓系統(tǒng)停機(jī)可控，二來避免因讓系統(tǒng)自動(dòng)去停DB可能導(dǎo)致的各種各樣的問題（如導(dǎo)致打補(bǔ)丁需要很長(zhǎng)的時(shí)間等）。
沖突分析部分截圖：
su - root
cd /oraclelog/shsnc/opatch_20200622/30899722
/oracle/app/19.3.0/grid/OPatch/opatchauto apply /oraclelog/shsnc/opatch_20200622/30899722
在所有節(jié)點(diǎn)補(bǔ)丁實(shí)施完成后，拉起實(shí)例，開始數(shù)據(jù)字典更新
su - oracle
cd $ORACLE_HOME/OPatch
./datapatch -verbose
--檢查補(bǔ)丁
./opatch lsinventory
sqlplus / as sysdba
set line 300 pages 100
col ACTION_TIME for a30
col DESCRIPTION for a60
select PATCH_ID, FLAGS,ACTION,STATUS,INSTALL_ID,ACTION_TIME,DESCRIPTION from DBA_REGISTRY_SQLPATCH order by ACTION_TIME;
補(bǔ)丁升級(jí)成功截圖：
報(bào)錯(cuò)截圖如下：
從以上截圖我們可以看到補(bǔ)丁在DB HOME已經(jīng)成功應(yīng)用，但是在GI HOME應(yīng)用時(shí)失敗，報(bào)/oracle/app/oraInventory/ContentsXML/oui-patch.xml文件權(quán)限問題。我們查看文件權(quán)限發(fā)現(xiàn)問題所在，同組grid用戶該文件無寫權(quán)限
補(bǔ)丁回滾失敗后，把之前備份的目錄tar回來發(fā)現(xiàn)數(shù)據(jù)庫安裝之后是沒有這個(gè)文件的。由此我們可以知道oui-patch.xml是在DB HOME進(jìn)行補(bǔ)丁升級(jí)時(shí)派生的。
再次進(jìn)行補(bǔ)丁升級(jí)時(shí)，發(fā)現(xiàn)oui-patch.xml已生成
緊急給oui-patch.xml賦予664權(quán)限(注：只要文件一旦生成，需立即賦權(quán))，補(bǔ)丁升級(jí)成功
Warning是告知實(shí)例未啟動(dòng)，需要手動(dòng)啟動(dòng)并運(yùn)行腳本進(jìn)行數(shù)據(jù)字典更新，可忽略。
在節(jié)點(diǎn)1 CRS alert日志中我們發(fā)現(xiàn)節(jié)點(diǎn)1會(huì)去檢查所有節(jié)點(diǎn)的這些文件。當(dāng)發(fā)現(xiàn)文件不存在時(shí)就報(bào)該錯(cuò)。前往各節(jié)點(diǎn)查看這些文件，確認(rèn)在所有節(jié)點(diǎn)都不存在。
核實(shí)部分截圖：
這些jackson開頭的jar包均是Jackson工具所屬jar包。從當(dāng)前來看這個(gè)應(yīng)該是Oracle為以后版本新功能準(zhǔn)備的，但是當(dāng)前目錄又沒有添加對(duì)應(yīng)的jar包，所以報(bào)錯(cuò)。通過核查集群及數(shù)據(jù)庫均確認(rèn)正常的情況下，該報(bào)錯(cuò)可忽略。
以上2個(gè)報(bào)錯(cuò)在MOS均查不到詳細(xì)信息，對(duì)于本來就是吃螃蟹的嘗新過程，或多或少會(huì)遇到各種未知BUG，這個(gè)過程我們遇山開路，逢水搭橋，依托自己深厚的擼功，相信自己，總會(huì)找到問題導(dǎo)致原因及解決方案。本次分享到此結(jié)束，謝謝大家，咱們下回再見。
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://m.hztianpu.com/yun/130228.html
集成安裝之Oracle12C補(bǔ)丁升級(jí)數(shù)據(jù)字典更新報(bào)錯(cuò)處理 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; ...
摘要：?jiǎn)栴}九庫控制文件擴(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)，歡迎大家閱讀分享。 問答集萃 接下來，...
19C?DG?Broker配置和測(cè)試 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; ...
閱讀 1459·2023-01-11 13:20
閱讀 1812·2023-01-11 13:20
閱讀 1263·2023-01-11 13:20
閱讀 2005·2023-01-11 13:20
閱讀 4226·2023-01-11 13:20
閱讀 2879·2023-01-11 13:20
閱讀 1488·2023-01-11 13:20
閱讀 3807·2023-01-11 13:20
