對於診斷Oracle Clusterware CRS或GI和Real Application Cluster RAC問題的資料收集

mosdoc發表於2016-12-14
對於診斷 Oracle Clusterware(CRS 或 GI)和 Real Application Cluster(RAC)問題的資料收集 (文件 ID 2017246.1)

文件內容


用途
  上傳到 oracle support 的資料檔案型別

排錯步驟
  1. 對於 oracle 叢集問題的資料收集
  2. 對於節點重啟/驅逐問題的資料收集
  3. 對於 RAC 問題的資料收集
  4. 對於 RAC 效能/Hang 問題的資料收集
  5. 對於 oracle 叢集安裝問題的資料收集
  5.1. 對於執行 root 指令碼前的錯誤:
  5.2. 對於執行 root 指令碼過程中或之後的錯誤:
  附錄: A RDA
  附錄:B 系統日誌
  附錄:C 叢集中的 systemstat 和 hanganalyze

參考


適用於:

Oracle Database - Enterprise Edition - 版本 10.1.0.2 到 11.2.0.3 [發行版 10.1 到 11.2]
本文件所含資訊適用於所有平臺

用途

該文件是臨時性的,以後會被淘汰,強烈建議使用 TFA 收集所有節點檔案:

參考: note 1513912.1TFA Collector - Tool for Enhanced Diagnostic Gathering

11.2.0.4 或更高版本 TFA Collector 會預設安裝在的 GI HOME下,11.2.0.3 或以下版本請參考 note 1513912.1 關於下載和安裝。

 

$GI_HOME/tfa/bin/tfactl diagcollect -from "MMM/dd/yyyy hh:mm:ss" -to "MMM/dd/yyyy hh:mm:ss"
 
舉例:如果問題發生在"7/1/2014 21:00:00"
我們可以透過:
"from time" 收集問題發生前4小時錯誤資訊
"to time" 收集問題發生後4小時錯誤資訊

 

這篇文件列出瞭如何蒐集不同型別叢集和 RAC 問題的資料資訊,對於新建 SR 不強制上傳所有檔案,但如果所有相關資訊都已上傳,將加快問題的分析與處理。

上傳到 oracle support 的資料檔案型別


Oracle support 希望客戶按節點壓縮相關檔案並使用標準格式,如: .tar, .gz, .Z 或 .zip。

過期的診斷資訊或檔案(如果是幾天或幾周前的診斷收集資訊)不包含當前發生問題的日誌資訊,則可能延緩我們的分析結果。

排錯步驟

 

1. 對於 oracle 叢集問題的資料收集

提供叢集中所有節點的當前診斷資訊輸出:

Note 330358.1 - CRS 10gR2/ 11gR1/ 11gR2 Diagnostic Collection Guide
Note 272332.1 - CRS 10gR1 Diagnostic Collection Guide

2. 對於節點重啟/驅逐問題的資料收集

請提供“對於 Oracle 叢集問題的資料收集”以及提供下面資訊:

  • 重啟發生的日期和時間,以及重啟節點的主機名字。
  • 取樣頻率20秒並覆蓋重啟時間的 OSW 私有網路監控資訊。
Note 301137.1 - OS Watcher User Guide
Note.433472.1 - OS Watcher For Windows (OSWFW) User Guide
  • 對於 11.2 以前版本,壓縮(zip)並上傳以下目錄檔案 /var/opt/oracle/oprocd/* 或 /etc/oracle/oprocd/*。
  • 對於 11.2 以前版本,OS logs –請參考附錄B。
  • 對於 11gR2+ 版本,壓縮並上傳以下檔案資訊 /etc/oracle/lastgasp/* 或 /var/opt/oracle/lastgasp/*。
  • 覆蓋重啟時間的 CHM/OS 資料,請參考文件 Note 1328466.1 "How do I collect the Cluster Health Monitor data" 中的內容。
  • 如果第三方叢集軟體被使用,則需上傳相應日誌資訊。

 

3. 對於 RAC 問題的資料收集

對於所有節點:

  • 提供 alert_{$ORACLE_SID}.log,lmon, lmd*,lms*,ckpt,lgwr,lck*,dia*,lmhb(11g only), 和所有其它問題發生時相關的跟蹤檔案,使用下面的舉例可以快速找出相關跟蹤檔案:
$ grep "2010-09-02 03" *.trc | awk -F: '{print $1}' | sort -u |xargs tar cvf trace.`hostname`.`date +%Y%m%d%H%M%S`.tar

$ gzip trace*.tar

對於 11g 以前版本,在 bdump 和 udump 目錄下執行。

對於 11g+ 版本,在目錄${ORACLE_BASE}/diag/rdbms/$DBNAME/${ORACLE_SID}/trace下執行 。
  • 發生問題時間段裡alert.log 提到的Incident files/packages
  • 如果 ASM 包含在內,則提供相應的 ASM 日誌資訊。
  • OS logs – 參考附件 B。

 

4. 對於 RAC 效能/Hang 問題的資料收集

提供"對於 Oracle 叢集問題的資料收集"以及以下資訊:

  • systemstate and hanganalyze – 參考附錄 C。
  • awr,addm 和 ash 報告,每個報告取樣時間不要超過60分鐘。
  • OSWatcher 覆蓋 hang 發生的時間段的日誌。
Note 301137.1 - OS Watcher User Guide
Note.433472.1 - OS Watcher For Windows (OSWFW) User Guide
  • 覆蓋發生問題時間段的 CHM/OS 資料,參考文件 Note 1328466.1 關於"How do I collect the Cluster Health Monitor data"部分。

 

5. 對於 oracle 叢集安裝問題的資料收集

5.1. 對於執行 root 指令碼前的錯誤:

針對於 11gR2 版本:note 1056322.1 - Troubleshoot 11gR2 Grid Infrastructure/RAC Database runInstaller Issues

針對於 11.2 以前版本:note 406231.1 - Diagnosing RAC/RDBMS Installation Problems

5.2. 對於執行 root 指令碼過程中或之後的錯誤:

請提供“對於 Oracle 叢集問題的資料收集”以及下面檔案:

  • root 指令碼(root.sh 或 rootupgrade.sh)螢幕輸出資訊。
  • 對於 11gR2 版本:請壓縮並上傳目錄 <$ORACLE_BASE>/cfgtoollogs 下的檔案和目錄 <$ORACLE_BASE>/diag 下針對於 grid 使用者的資料輸出。
  • 對於 11.2 以前版本:Note 240001.1 - Troubleshooting 10g or 11.1 Oracle Clusterware Root.sh Problems


附錄: A RDA

建議提供叢集中所有節點最近的 RDA 資料收集。

Note 314422.1 - Remote Diagnostics Agent (RDA)

附錄:B 系統日誌

根據 OS 平臺日誌在下面對應的目錄中:

Linux: /var/log/messages

AIX: /bin/errpt -a (redirect this to a file called messages.out)

Solaris: /var/adm/messages

HP-UX: /var/adm/syslog/syslog.log

Tru64: /var/adm/messages

Windows: save Application Log and System Log as .TXT files using Event Viewer


注意:對於11gR2,在 linux, solaris,hp-ux 平臺,診斷收集資訊已包含系統日誌。

附錄:C 叢集中的 systemstat 和 hanganalyze


為在 RAC 中搜集 hanganalyze 和 systemstate 資訊,在 RAC 中的一個例項執行下面命令來產生叢集 dump 檔案。

a - 使用 sysdba 使用者連線資料庫:”sqlplus /as sysdba”
如果 sqlplus 不能正常工作,就使用”sqlplus –prelim /as sysdba”

b - 執行下面命令:

  • 在 11g + 版本:
SQL> oradebug setospid <ospid of diag process>
SQL> oradebug unlimit
SQL> oradebug -g all hanganalyze 3
##..Wait about 2 minutes
SQL> oradebug -g all hanganalyze 3
SQL> oradebug -g all dump systemstate 258


如果可能,請使用 266 級別再進行一次收集。


If SGA is large or fix for (fixed in 11.2.0.2 DB PSU5, 11.2.0.3 and above) is not applied, level 266 could take very long time and generate a huge trace file and may not finish in hours.
  • 在 10g 版本:
SQL> oradebug setospid <ospid of diag process>
SQL> oradebug unlimit
SQL> oradebug -g all dump systemstate 266##..Wait about 2 minutes
SQL> oradebug -g all dump systemstate 266

請從 bdump 或 trace 目錄上傳 diag trace 檔案。
  • 如果 diag trace 非常大或者“oradebug -g all….” 命令 hang 請在每個例項上相近的時間分別蒐集系統 dump 檔案:
SQL> oradebug setmypid
SQL> oradebug unlimit
SQL> oradebug hanganalyze 3
##..Wait about 2 minutes
SQL> oradebug hanganalyze 3
SQL> oradebug dump systemstate 258
SQL> oradebug tracefile_name

      請上傳以上的 trace 檔案。

  • 如果“sqlplus –prelim /as sysdba” 不能正常工作,請參考 note 121779.1 使用系統的 debuggers 工具在所有的節點上執行 dbx 或 gdb 命令。

 如果 ASM 包含在內,上面的命令同樣使用於 ASM 上搜集 hanganalyze 和 systemstate。

參考

NOTE:406231.1 - Diagnosing RAC/RDBMS Installation Problems
NOTE:272332.1 - CRS 10g Diagnostic Collection Guide
NOTE:433472.1 - OS Watcher For Windows (OSWFW) User Guide
NOTE:1328466.1 - Cluster Health Monitor (CHM) FAQ
NOTE:240001.1 - Troubleshooting 10g or 11.1 Oracle Clusterware Root.sh Problems
NOTE:330358.1 - Oracle Clusterware 10gR2/ 11gR1/ 11gR2/ 12cR1 Diagnostic Collection Guide
NOTE:942166.1 - How to Proceed from Failed 11gR2 Grid Infrastructure (CRS) Installation
NOTE:969254.1 - How to Proceed from Failed Upgrade to 11gR2 Grid Infrastructure on Linux/Unix
NOTE:1056322.1 - Troubleshoot Grid Infrastructure/RAC Database installer/runInstaller Issues

NOTE:736752.1 - Introducing Cluster Health Monitor (IPD/OS)
NOTE:314422.1 - Remote Diagnostic Agent (RDA) - Getting Started
NOTE:301137.1 - OSWatcher (Includes: [Video])

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31393455/viewspace-2130457/,如需轉載,請註明出處,否則將追究法律責任。

相關文章