兩個Oracle配置問題的記錄

realkid4發表於2014-06-15

 

Oracle資料庫無論是在安裝還是執行,都涉及到與周邊軟硬體的各種聯絡。一套健康的資料庫系統,要想順利安裝並且平穩執行,都需要各方面周邊元件的配置調整。一旦某個方面存在問題,一些想當然的過程都會出現問題。

本篇記錄了最近遇到的兩個問題,記錄下來,留待不時之需。

 

1Oracle OCM作業執行報錯ORA-29280

 

一個同事系統中出現小故障,筆者協助幫助檢視。由於系統總體負載很低,也沒有明顯的功能影響點,筆者也沒有直觀的思路。一般而言,從alert log中我們可以按照時間關係檢視到Oracle的重要問題現象。

從日誌情況中,卻發現了一些其他問題。

 

Mon Jun 02 22:00:08 2014

Errors in file /u01/app/oracle/diag/rdbms/dt/MM/trace/MM_j001_43954.trc:

ORA-12012: error on auto execute of job "ORACLE_OCM"."MGMT_CONFIG_JOB_2_1"

ORA-29280: invalid directory path

ORA-06512: at "ORACLE_OCM.MGMT_DB_LL_METRICS", line 2436

ORA-06512: at line 1

 

在系統資料庫執行過程中,基本每天夜間22點都會有這個報錯出現。系統負載很低(日誌切換並不頻繁),除此之外沒有明顯的錯誤。

22點對於Oracle而言是一個重要的時間點,進入10g之後,Oracle夜間都會自動排程一些維護作業,來確保資料庫順利高效執行。這些作業中,最有名的就是統計量自動收集作業,夜間對新物件或者變化頻繁物件進行資料統計量收集。

進入11g之後,這種夜間作業機制在不斷的強化,但是執行時間視窗有了變化,起始時間調整為夜間2200開始。我們在日誌中看到的報錯,就是Oracle OCMOracle Configuration Manager)夜間執行的作業之一。

OCMOracle內部的一個工作元件,用於提供一些配置引數協助方面的工作。我們安裝資料庫後,會看到使用者schema列表中包括一個名稱為ORACLE_OCM的使用者名稱,就是這個元件的內部對應資料使用者集合。

根據Oracle MOS的介紹,出現這樣的錯誤是由於Oracle資料庫升級過程中的不完全造成的。在OCM進行度量(instrument)過程中,會自動往一些directory目錄位置寫入資訊。如果目錄配置有問題,就會引起報錯。

一般系統中,我們也可以看到這些預設的目錄的。

 

SQL> select directory_name, directory_path from dba_directories;

 

DIRECTORY_NAME                 DIRECTORY_PATH

------------------------------ --------------------------------------------------------------------------------

XMLDIR                         /u01/app/oracle/rdbms/xml

ORACLE_OCM_CONFIG_DIR          /u01/app/oracle/ccr/hosts/SimpleLinux.localdomain/state

DATA_PUMP_DIR                  /u01/app/admin/ora11g/dpdump/

ORACLE_OCM_CONFIG_DIR2         /u01/app/oracle/ccr/state

 

在很多情況下,ORACLE_OCM_CONFIG_DIR2目錄中是會寫入一些資料的。如果這個目錄配置有問題或者不存在,就會出現作業報錯的情況。

瞭解了問題原因,解決之道就比較容易了。和其他後設資料損壞處理方法相同,或者執行安裝指令碼,重新安裝元件,或者禁用元件執行。

下面是進行OCM目錄配置的方法步驟。說明:由於環境所限,筆者沒有進行實際測試,下列指令碼在第三方環境中進行。

首先執行指令碼檢查OCM配置安裝情況。

 

[oracle@SimpleLinux ~]$ cd $ORACLE_HOME/ccr/bin

[oracle@SimpleLinux bin]$ ls -l | grep deploy

-rw-r--r--. 1 oracle oinstall 48758 Jun  5  2013 deployPackages

 

[oracle@SimpleLinux bin]$ chmod 755 deployPackages

[oracle@SimpleLinux bin]$ ./deployPackages -l

The Oracle Configuration Manager state/writeable directory structure is incomplete.

OCM is not configured for this host or ORACLE_CONFIG_HOME. Please configure OCM first.

 

根據筆者環境的提示,OCM沒有在筆者伺服器進行配置,如果配置了,就會顯示如Step2的提示內容。

第二步是執行指令碼建立OCM directory物件和授予許可權。

 

SQL> conn / as sysdba

Connected.

@ORACLE_HOME/ccr/admin/scripts/ocmjb10.sql

@ORACLE_HOME/ccr/admin/scripts/execute execocm.sql

 

最後確定directory建立情況。

 

SQL> select directory_name, directory_path from dba_directories where DIRECTORY_NAME like '%OCM_CONFIG%';

 

DIRECTORY_NAME                 DIRECTORY_PATH

------------------------------ --------------------------------------------------------------------------------

ORACLE_OCM_CONFIG_DIR          /u01/app/oracle/ccr/hosts/SimpleLinux.localdomain/state

ORACLE_OCM_CONFIG_DIR2         /u01/app/oracle/ccr/state

 

注意:要求DIR2是存在的。

 

第二種方法更加簡單,如果確定系統不需要OCM執行,可以關閉這個作業執行。畢竟多一事不如少一事,當然這個需要確認系統不需要OCM的執行。

刪除ORACLE_OCM使用者schema,或者禁用job作業。

 

exec dbms_scheduler.disable('ORACLE_OCM.MGMT_CONFIG_JOB')
exec dbms_scheduler.disable('ORACLE_OCM.MGMT_STATS_CONFIG_JOB')

 

這個案例並不難解決,但是告訴我們一點:對系統的維護過程,要是全方面的。定期檢視系統執行日誌,及時發現潛在問題,解決問題很重要。讓資料庫“帶傷”執行,未來會帶來一些意想不到的問題。

 

2Windows環境下網路卡驅動缺失引發的INS-30131安裝錯誤

 

在各種系統安裝過程中,Windows版本的Oracle是最好安裝的,也是操作步驟最容易的一個版本。即不需要配置單獨的使用者,也不需要調整系統配置引數。環境變數、使用者角色、目錄規劃基本上Oracle都為我們配置好了。

但是,也正是因為如此。Windows環境下的Oracle,是通常管理最散漫、管理員瞭解最少、出現問題最無助的一個環境。我們對Windows環境下系統執行的瞭解,很多情況下甚至不如Linux/AIX環境下的瞭解。

筆者在安裝一個全新的物理機,由於網路配置問題,只能現在機房進行安裝。複製安裝介質解壓之後,執行資料庫安裝軟體安裝。進行安裝的版本為11.2.0.4

進行檢查過程中,出現錯誤如下:

 

兩個Oracle配置問題的記錄

 

系統報錯INS-30131,安裝過程驗證錯誤。點開細節Details,可以檢視內容:

 

兩個Oracle配置問題的記錄

 

無法訪問建立臨時檔案目錄。這個錯誤在windows上面很少見,而且我們是使用administrator進行系統安裝,理論上沒有許可權限制問題。

檢查MOS,雖然有這個錯誤的提示,但是主要在12c安裝過程中出現的。問題的根源在C$預設共享上。經過檢查,也沒有發現明顯的故障問題點。於是問題就又回到原點。

一個很偶然的情況,筆者和同事發現這臺Sun物理伺服器上雖然安裝了作業系統Windows 2008R2,但是並沒有網路卡顯示。裝置管理器上顯示不能識別網路卡裝置,也就是說網路卡驅動沒有安裝。

C$共享和網路卡驅動也許是有關係的,但是這種關係是不是造成問題出現的根源,筆者並不確認。但是有一個是確定的,網路卡驅動是必須要安裝上。

經歷一些波折,總算安裝好伺服器啟動,雖然沒有連線,但是再次執行之後,問題消失。

這個案例給筆者的教訓是:資料庫的安裝、配置和執行,並不是獨立的,而是與作業系統、網路和整體環境緊密相關。在一些不可思議問題出現的時候,正是我們要檢查一下基本環境是否有變化問題的時候。

 

3、結論

 

實際工作過程中,我們會遇到多種多樣的問題故障。逐步進行解決的過程,也就是我們不斷成長、積累經驗和豐富閱歷的過程。


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

相關文章