升級到 11.2.0.3/11.2.0.4 GI/ASM 前需要考慮的事情 (文件 ID 1623280.1)
文件內容
|
用途 |
|
適用範圍 |
|
詳細資訊 |
A. 執行 CVU 預升級檢查工具 |
B. 確保一致的網路設定 |
C. 升級必須/推薦的補丁 |
D. 安裝升級前需要的補丁 |
E. ASM memory_max_target 和 memory_target |
F. 以真正的 root 使用者執行 rootupgrade.sh – 不是透過 sudo 等 |
G. HACMP/PowerHA 特殊考慮 |
附件 1. 已知的問題 |
|
參考 |
適用於:
Oracle Database - Enterprise Edition - 版本 10.2.0.4 到 11.2.0.4 [發行版 10.2 到 11.2]本文件所含資訊適用於所有平臺
用途
為保證平穩升級到 11.2.0.3/11.2.0.4GI,本文件列出了需要檢查的事情、可以規避的已知問題和需要考慮的領域。
文件包含對預升級執行 CVU 檢查的介紹和升級 GI、ASM 前所必須或者推薦應用的補丁列表。
適用範圍
文件適用於 Oracle 叢集管理員和 Oracle 技術支援工程師。
對 Exadata 使用者,請參考如下文章檢視詳情:
Document 1373255.1 - 11.2.0.1/11.2.0.2 to 11.2.0.3 Database Upgrade on Exadata Database Machine
詳細資訊
11.2.0.3/11.2.0.4 是一個完整版本,任何 11.2 之前的 CRS 叢集都可以直接升升級到 11.2.0.3/11.2.0.4; 同時從 11.2 開始 in-place 的補丁集升級不再支援,任何補丁集都必須被安裝到一個新的 HOME(out-of-place 升級)。
A. 執行 CVU 預升級檢查工具
以 grid 使用者登入,執行解壓後的 GI 安裝介質中的 runcluvfy.sh 指令碼,以確認這個環境是否適合升級:
-src_crshome -dest_crshome -dest_version
[-fixup [-fixupdir]] [-verbose]
例如,以 rolling 的方式將一個 3 節點的 Oracle 叢集從 /u01/app/11.1 升級到 11.2.0.3 的 /u01/app/grid 目錄下,執行如下:
在升級前,任何 CVU 的錯誤都應該被修復的。對於 CVU 能夠修復的錯誤,使用 "-fixup"選項獲取修復錯誤的可執行指令碼,其他不能被 CVU 修復的錯誤應該被手工修復。
如果預先要求的 patch 沒被安裝,那麼執行 rootupgrade.sh 時將會報有以下錯誤:
These patches need to be installed before the upgrade can proceed.
The pre-upgrade checks failed, aborting the upgrade
然而,很多時候以上錯誤是由於 CVU 自身問題導致的,請參考 Document 1452184.1 檢視詳情。
B. 確保一致的網路設定
參考 Document 1386709.1 確保 Oracle 叢集的網路資訊在所有節點上都與 OS 層的設定相符。
C. 升級必須/推薦的補丁
下表列出了在升級前,需要/推薦應用到要升級的 GI HOME 的補丁資訊。該表按照 Exadata 和非 Exadata 環境來分類。
“Minimum source version”是必須應用的補丁,在安裝強制補丁前就要安裝這些補丁,否則應用補丁或安裝可能會失敗。
“Required PSU or one off patch”是升級前必須應用的強制補丁。
Source Oracle Clusterware version | Minimum source version | Required PSU or one off patch |
---|---|---|
10.2.0.4 | NULL | - 10.2.0.4.2 CRS PSU |
10.2.0.5 | NULL |
- 10.2.0.5.2 CRS PSU |
11.1.0.7 | NULL | - 11.1.0.7.7 CRS PSU |
11.2.0.1 | NULL |
或 適用於 AIX, Solaris 或 HP平臺 或 適用於 Windows 平臺, 在 Patch 6 及以上 版本 |
11.2.0.2 | NULL |
這也是 GI PSU6 的一部分 這個補丁必須被應用到 GI HOME,它是 11.2.0.2 DB HOME 推薦應用的補丁。這個補丁在所有 DB PSU 中存在,並且也是相應的 GI PSU 的一部分。推薦使用最新版本的 11.2 Opatch(patch 6880880) 以"opatch auto"的方式透過 root 使用者執行: # $GRID_HOME/OPatch/opatch auto <PATH_TO_PATCH_DIRECTORY> -oh <GRID_HOME> # $GRID_HOME/OPatch/opatch auto <PATH_TO_PATCH_DIRECTORY> -oh <DB_HOME> 當opatch要求回答以下問題時:輸入無引號的'yes': Enter 'yes' if you have unzipped this patch to an empty directory to proceed (yes/no):yes 如果opatch失敗,請手工應用: 1. 以資料庫使用者手工停止所有的資料庫: <DB_HOME>/bin/srvctl stop database -d <dbname> 2. 以 root 使用者對 GI HOME 解鎖: 對 GI 叢集環境: # $GRID_HOME/crs/install/rootcrs.pl -unlock 對 GI 單機環境 (Oracle Restart): # $GRID_HOME/crs/install/roothas.pl -unlock 3. 將 patch 應用到 GI 和 DB HOME: 以grid使用者:$ $GRID_HOME/OPatch/opatch napply -oh <GRID_HOME> -local <UNZIPPED_PATH_LOCATION>/12539000 以資料庫使用者: <DB_HOME>/OPatch/opatch napply -oh <DB_HOME> -local <UNZIPPED_PATH_LOCATION>/12539000 4. 以 root 使用者鎖住 GI HOME: 對 GI 叢集環境: # $GRID_HOME/rdbms/install/rootadd_rdbms.sh # $GRID_HOME/crs/install/rootcrs.pl -patch 對 GI 單機環境 Standalone (Oracle Restart): # $GRID_HOME/rdbms/install/rootadd_rdbms.sh # $GRID_HOME/crs/install/roothas.pl -patch 5. 以資料庫使用者手工啟動所有的資料庫:<DB_HOME>/bin/srvctl start database -d <dbname> 由於 1/15/2012 故障, patch readme 檔案在 PSU1/2/3 的"manual steps to apply" 部分是錯誤的,patch readme 檔案在 PSU4/5(11.2.0.2.4/5) 是錯誤的。 |
如果強制補丁沒有應用,將會有以下報錯:
PRVG-1253 : Required Oracle patch is not found on node "racnode1" in home "/ocw/b201".
- Cause: Required Oracle patch is not applied. - Cause: Required Oracle patch is not applied.
- Action: Apply the required Oracle patch.
OUI error/log
Oracle patch:9413827
INFO: Oracle patch:9706490 or 9413827: This test ensures that Oracle patch "9706490 or 9413827" has been applied in home "/ocw/b201".
INFO: Severity:CRITICAL
INFO: OverallStatus:VERIFICATION_FAILED
D. 安裝升級前需要的補丁
在 11.2.0.3/11.2.0.4, CVU/OUI 基於 CVU pre-req xml 的說明驗證已存在的設定,推薦使用“Software Update Option”去下載並應用最新的 pre-req xml 來確保正確的檢查,參考 Document 1289738.1 檢視該特性的更多細節。
注意:Software Update Option 使用的 OUI patch 和普通的 patch 打包不同。
E. ASM memory_max_target 和 memory_target
在 11.2.0.3/11.2.0.4,初始化引數 "processes"的預設值為“可用的 CPU 核數*80+40”.
初始化引數"memory_target" 的預設值是基於"processes"的,如果有大量的 CPU
核數或者磁碟組,這可能導致預設的"memory_target"不足,並導致各種問題(例如:GI stacks 由於 ORA-04031
錯誤無法啟動)。推薦在升級到 11.2.0.3/11.2.0.4 之前增加 memory_max_target 和 memory_target
的值(不適用於 10g ASM):
登入到 ASM:
SQL> show parameter memory_target
如果這個值比 1536m 小,執行如下命令:
SQL> alter system set memory_max_target=4096m scope=spfile;
SQL> alter system set memory_target=1536m scope=spfile;
1536m 的大小已被證明足夠適合大多數的環境,以上操作需要重啟才能生效。
如果 rootupgrade.sh 已經因為 memory_target 太小而失敗,請參考 Document 969254.1 繼續操作。
F. 以真正的 root 使用者執行 rootupgrade.sh – 不是透過 sudo 等
當切換到 root 使用者執行 rootupgrade.sh 時,"su -" 或者 "su - root"提供了完整的 root 環境,但 sudo,pbrun,"su root" 或者 "su"或類似工具則不會。為避免出現以下文章中描述的問題,建議以完整的 root 環境執行 rootupgrade.sh:
- Document 1315203.1 - ACFS Drivers Fail To Install During Root.Sh Execution Of 11.2.0.2 GI Standalone On AIX
- Document 1235944.1 - 11gR2 root.sh Fails as crsd.bin Does not Come up due to Wrong ulimit
- Document 1210883.1 - 11gR2 GI HAIP - Section "bug 12674817"
- Document 1259874.1 - root.sh Fails as the ora.asm resource is not ONLINE or PROTL-16 due to Wrong umask
G. HACMP/PowerHA 特殊考慮
如果升級一個帶有 IBM HACMP/PowerHA 的叢集,請參考 Document 1443814.1 來檢視需要特別注意的地方。
附件 1. 已知的問題
- note 1379498.1 - 11.2.0.3 VIP/SCAN VIP is Not Pingable After Failover Leads to Connection Issue
- note 1493255.1 - Random Node Eviction When Upgrading 10.2.0.5 CRS to 11.2.0.3 GI
- note 1392633.1 - Things to Consider Before Upgrading to 11.2.0.3 to Avoid Poor Performance or Wrong Results
參考
NOTE:1312225.1 - Things to Consider Before Upgrading to 11.2.0.2 Grid Infrastructure/ASMNOTE:1373255.1 - 11.2.0.1/11.2.0.2 to 11.2.0.3 Grid Infrastructure and Database Upgrade on Exadata Database Machine
NOTE:1386709.1 - The Basics of IPv4 Subnet and Oracle Clusterware
- SET ASM MEMORY_TARGET TO BE AT LEAST 1536M WHILE UPGRADING TO 11.2.0.3
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31393455/viewspace-2130396/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- oracle rac 11.2.0.3 升級到11.2.0.4Oracle
- oracle資料庫升級11.2.0.3升級到11.2.0.4Oracle資料庫
- oracle資料庫11.2.0.3升級到11.2.0.4Oracle資料庫
- 如何升級Oracle Grid Infrastructure和RAC從11.2.0.3到11.2.0.4?OracleASTStruct
- 探索Oracle之資料庫升級二 11.2.0.3升級到11.2.0.4完整步驟Oracle資料庫
- 11.2.0.3 database異機升級至11.2.0.4Database
- 單例項環境下Oracle 11.2.0.3升級到11.2.0.4的過程單例Oracle
- SAP版本升級,企業需要考慮評估哪些問題?
- Oracle 11.2.0.1 升級到11.2.0.3Oracle
- ORACLE 11.2.0.1升級到11.2.0.3Oracle
- Oracle 11.2.0.1升級到11.2.0.3Oracle
- Oracle 11.2.0.4升級到12.2.0.1Oracle
- oracle11.2.0.3升級到11.2.0.4出現查詢效能問題,分析處理Oracle
- 10g升級至11g需要考慮的引數優化優化
- ORACLE11.2.0.1升級到11.2.0.3Oracle
- 一種遷移式升級的方案考慮
- 探索Oracle之資料庫升級三 回退升級操作(11.2.0.4Downgrade 11.2.0.3)Oracle資料庫
- oracle for windows 11.2.0.1升級到11.2.0.4OracleWindows
- RAC升級11.2.0.1到11.2.0.4的實戰
- oracle版本升級:從11.2.0.1到11.2.0.3Oracle
- 網站在架構時要考慮的事情網站架構
- 資料庫從9升級到10,考慮部分引數調整資料庫
- 論資料倉儲架構前需要考慮的問題架構
- Consider Before Upgrading to 11.2.0.3/11.2.0.4 Grid Infrastructure/ASM_1363369.1IDEASTStructASM
- 靜默升級oracle 11g (從11.2.0.1升級到11.2.0.4)Oracle
- Oracle RAC 10.2.0.5升級到11.2.0.4遇到的問題Oracle
- MongoDB分片需要考慮的事項MongoDB
- PSU的GI升級,ERROR: This patch is not applicable to GI home.ErrorAPP
- oracle 資料庫從10.2.0.4升級到11.2.0.3Oracle資料庫
- 伺服器選購前的考慮伺服器
- 技術分享 | tidb 2.1升級到4.0操作文件TiDB
- 圖形化升級單機oracle 11.2.0.1 到 11.2.0.4Oracle
- 圖形化升級單機oracle 11.2.0.4 到 12.2.0.1Oracle
- 單機升級11.2.0.4到12.1.0.2的實戰__catupgrd.sqlSQL
- 單機升級11.2.0.1到11.2.0.4的實戰__DBUA視窗
- Windows 10升級前需要注意的13問答Windows
- 2021年您應該考慮的網路升級問題
- 開發網校系統原始碼前,需要考慮哪些關鍵點?原始碼