国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

集成安裝之oracle19C GI升級遇坑分享

IT那活兒 / 1429人閱讀
集成安裝之oracle19C GI升級遇坑分享

親愛滴伙伴們！本萎專家又來了，今天咱來實踐19C的GI升級。


前面提到過，Oracle19C替代12C將成為oracle線條接下來這兩年的主要工作。本萎大濕所在客戶現場后續數據庫集成安裝都將以19C為標準版本。本篇就19C打最新的GIRU(19.7.0.0.200414)步驟及遇到的問題做總結分享。




●GIRU實施步驟●


補丁升級均采取滾動升級方式進行


01

19更新opatch版本

打GIRU(19.7.0.0.200414)所需要的opatch版本為12.2.0.1.19及以上最新版本。建議使用19C版本進行補丁升級，所以我們這次使用的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



02

目錄備份

該備份將作為補丁升級出錯，rollback也報錯時的最后救命稻草。備份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？部分看官們估計會有疑問。這個還得從很早之前一次Oracle11G GI PSU升級說起，當時本萎大濕碰到這樣一種情況，在確認當時備份命令運行正常，備份出來的文件大小正常情況下，在不停CRS的情況下備份出來的文件竟然不可用......還好當時值得慶幸的是補丁回滾成功了。。所以這次“驚魂動魄”之后這個備份都“唯經驗論”了。


03

拉起CRS進行補丁沖突分析

啟動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

補丁沖突分析

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


預計這里有的看官又有疑問了，為啥啟動crs,不起db？升級過程GI會自動把DB及CRS停下來并進行目錄升級，這樣不是多此一舉嗎。各位看官應該清楚，繁忙生產庫的DB因為并發和繁忙程度是沒這么容易停下來的，一般作為老鳥來說，為了最大限度的萬無一失，都會手動kill會話及手動做checkpoint，switch logfile讓系統在自己眼皮子底下順利停下來。這樣做一來讓系統停機可控，二來避免因讓系統自動去停DB可能導致的各種各樣的問題（如導致打補丁需要很長的時間等）。


沖突分析部分截圖：


04

實施補丁

su - root

cd /oraclelog/shsnc/opatch_20200622/30899722

/oracle/app/19.3.0/grid/OPatch/opatchauto apply /oraclelog/shsnc/opatch_20200622/30899722


05

 數據字典更新并檢查

在所有節點補丁實施完成后，拉起實例，開始數據字典更新

su - oracle

cd $ORACLE_HOME/OPatch

./datapatch -verbose

--檢查補丁

./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;



補丁升級成功截圖：





●問題匯總●


06

 補丁升級失敗，報oui-patch.xml文件沒有權限

報錯截圖如下：

從以上截圖我們可以看到補丁在DB HOME已經成功應用，但是在GI HOME應用時失敗，報/oracle/app/oraInventory/ContentsXML/oui-patch.xml文件權限問題。我們查看文件權限發現問題所在，同組grid用戶該文件無寫權限


補丁回滾失敗后，把之前備份的目錄tar回來發現數據庫安裝之后是沒有這個文件的。由此我們可以知道oui-patch.xml是在DB HOME進行補丁升級時派生的。


再次進行補丁升級時，發現oui-patch.xml已生成


緊急給oui-patch.xml賦予664權限(注：只要文件一旦生成，需立即賦權)，補丁升級成功

Warning是告知實例未啟動，需要手動啟動并運行腳本進行數據字典更新，可忽略。


07

補丁升級成功之后，節點1 CRS報錯如下


在節點1 CRS alert日志中我們發現節點1會去檢查所有節點的這些文件。當發現文件不存在時就報該錯。前往各節點查看這些文件，確認在所有節點都不存在。

核實部分截圖：


這些jackson開頭的jar包均是Jackson工具所屬jar包。從當前來看這個應該是Oracle為以后版本新功能準備的，但是當前目錄又沒有添加對應的jar包，所以報錯。通過核查集群及數據庫均確認正常的情況下，該報錯可忽略。




●總結●



以上2個報錯在MOS均查不到詳細信息，對于本來就是吃螃蟹的嘗新過程，或多或少會遇到各種未知BUG，這個過程我們遇山開路，逢水搭橋，依托自己深厚的擼功，相信自己，總會找到問題導致原因及解決方案。本次分享到此結束，謝謝大家，咱們下回再見。

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/130228.html

相關文章

  • 集成安裝之Oracle12C補丁升級數據字典更新報錯處理

    集成安裝之Oracle12C補丁升級數據字典更新報錯處理 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; ...

    IT那活兒 評論0 收藏795

  • DBASK問答集萃第四期

    摘要：問題九庫控制文件擴展報錯庫的擴展報錯，用的是裸設備，和還是原來大小，主庫的沒有報錯，并且大小沒有變，求解釋。專家解答從報錯可以看出，控制文件從個塊擴展到個塊時報錯，而裸設備最大只支持個塊，無法擴展，可以嘗試將參數改小，避免控制文件報錯。 鏈接描述引言 近期我們在DBASK小程序新關聯了運維之美、高端存儲知識、一森咖記、運維咖啡吧等數據領域的公眾號，歡迎大家閱讀分享。 問答集萃 接下來，...

    SKYZACK 評論0 收藏0

  • 19C?DG?Broker配置和測試

    19C?DG?Broker配置和測試 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; ...

    IT那活兒 評論0 收藏2941

發表評論

0條評論

IT那活兒

男|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<