最近處理了若干rac環境訪問sysdate錯誤的時間返回。而這個問題通常是乙個資料庫鏈結是由現在listener建立的情況下。並且。大部分情況下都是和時區設定相關的。在這篇文章中我們會針對怎樣診斷這樣的問題進行解釋。這篇文章適用於版本號11.2.0.2 及以上版本號。
首先，對問題其中涉及到的知識進行介紹。
1. 從版本號11.2.0.2 開始oracle 集群（gi）開始擁有了自己的時區和一些其它配置。這些配置儲存在配置檔案/crs/install/s_crsconfig_《節點名》_env.txt中。
比如：tz=asia/shanghai
nls_lang=american_america.al32utf8
tns_admin=
oracle_base=
我們能看到變數tz 用於定義集群的時區。當然，這個集群的時區是在安裝gi時從作業系統獲得的。
既然集群有了時區，那麼我們就須要保證gi的時區和作業系統的設定是一致的，而且當作業系統的時區發生改變時，gi的時區也須要改變。而改動集群時區的基本步驟是（改動/crs/install/s_crsconfig_《節點名》_env.txt檔案，重新啟動節點）。
2. 當資料庫或者listner 使用srvctl 命令或者隨著gi啟動被啟動時，環境變數會繼承gi的時區。您也能夠通過以下的命令來手動設定資料庫和listener資源的環境變數。
srvctl setenv database -d -t 'tz=《時區》'
srvctl setenv listener -l -t 'tz=《時區》'
3. sysdate返回的值並不依賴於資料庫的時區設定，oracle 僅僅是簡單的從作業系統獲取系統時間返回（比如：呼叫os 函式gettimeofday）。
所以，改動資料庫的時區對於這樣的問題並沒有幫助。而相應的server程序所使用的環境變數tz才會影響返回的系統時間。
接下來，我們簡介一下client通過listener 連線到資料庫時會經過那些過程。
我們會通過乙個詳細的樣例來解釋。
在這個樣例中，我們使用sqlplus 建立資料庫鏈結。並對listener程序蒐集truss 資訊
1.client連線資料庫
sqlplus scott/tiger@test
2.listner 程序收到了相應的鏈結。並產生了相應的server process.
......
524732: kfork() = 496094
496094: kfork() (returning as child ...) = 0
......
496094: kfork() = 483742
483742: kfork() (returning as child ...) = 0
3. 為server process指定環境變數。
483742: execve(0x0fffffffffff2660, 0x0000000110773730, 0x000000011077b670) argc: 2
483742: argv: oracle(local=no) <<<<<<<< server程序環境變數被指定
483742: __clsagent_incarnation=2 _ora_agent_action=true path=
483742: nls_lang=american_america.we8iso8859p1 __clsagent_user_name=oracle
......
......
483742: __clsagent_logdir_name=crsd pwd=/ tz=asia/shanghai <<<< 時區被指定。
我們能看到環境變數tz的值在建立伺服器程序時會被繫結到server process 中。
當然，假設您沒有對lisetner 蒐集truss 輸出。
您也能夠通過作業系統命令獲得相應程序的環境變數。比如：ps eauwww 。您能夠通過mos note 373303.1 中的內容獲得不同平台的命令。
另外。以上的資料庫是通過gi agent 啟動的，假設資料庫是手動啟動的（比如：startup 命令），那麼。輸出會不同。當然, pmon在註冊資料庫服務到listener時也會將自己的環境變數註冊到相應的service上。
所以，在診斷rac 環境下sysdate 返回錯誤時間的問題時，我們須要檢查下面資訊。
1. 作業系統級別的時區設定，並確保作業系統命令date 能返回正確的時間。對於怎樣檢視不同平台的時區設定，請參考note 1209444.1
2. 確認gi 配置檔案/crs/install/s_crsconfig_《節點名》_env.txt檔案裡的變數tz和作業系統的tz 設定一致。
3. 確認是否在database或listener資源層面設定了tz變數。假設設定了，是否和os，gi的設定是一致的。
4. 另外，server process的環境變數libpath 或 ld_library_path 也會對oracle訪問作業系統函式產生影響。並且gi 的agent程序（適用於版本號11.2.0.3 及以上的版本號）在啟動資源時（比如:database資源）會自己主動的將程序的下面環境變數清空
ld_library_path, shlib_path (hp-ux), ld_libpath_path_64 (solaris), libpath（aix）
所以，假設您的database是使用srvctl 命令啟動的，就須要確認上面的環境變數被設定正確。
比如：srvctl setenv database -d -t 'libpath='
注意：不同的unix平台，以上命令可能會不同。
所以，我們也去要確認database 資源的libpath 或 ld_library_path 變數是否被設定。
比如：srvctl getenv database -d
另外，在診斷這樣的問題時。須要蒐集下面資訊。
1. /crs/install/s_crsconfig_《節點名》_env.txt檔案
2. 作業系統時區設定（cat /etc/sysconfig/clock） 和環境變數tz的設定。以及pmon程序的環境變數。
3. database和 listener資源的環境變數
比如：srvctl getenv database -d
srvctl getenv listener -l
4. 假設以上的資訊沒有問題，那麼就須要蒐集listener 程序的truss（或strace） 輸出找到有問題的設定環境變數。
5. 假設1—4 中的資訊仍然無法找到問題的解決辦法，請蒐集client和server端的sqlnet trace，以便確認是否有不論什麼的』alter session set ...』命令改動了會話的時區或者相關的變數。
clientsqlnet trace:設定下面引數到client的sqlnet.ora 檔案裡。
trace_level_client=16
trace_directory_client=c:\tmp ==> 確保該路徑存在
trace_file_client=client
trace_unique_client=on
trace_timestamp_client=on
server端sqlnet trace：設定下面引數到server端的sqlnet.ora檔案裡
trace_level_server=16
trace_file_server=server
trace_directory_server=/tmp ==> 確保該路徑存在
trace_timestamp_server=on
我希望診斷範疇的上述解釋似這個問題將是有益的。
手動刪除RAC環境
最根本的原因就是上一次安裝錯誤後沒有完全解除安裝乾淨.導致目錄中快取資料錯誤.總結之下.在安裝crs失敗後,應該按以下步驟 1 直接刪除oracle base目錄,同時刪除 etc目錄下的oralnst.loc 和oratab兩個檔案 2 按照 shahand 提示 mv f etc init.d ...
RAC環境下負載均衡配置
典型配置 oralocal description load balance yes failover on address list address protocol tcp host 192.168.1.1 port 1521 address protocol tcp host 192.168....
RAC環境資料庫重啟例項
rac 應用越來越廣泛了。rac技術作為 oracle 資料庫集群環境，它的管理有自己的一整套知識，我在此來演示一下 rac的重啟過程。oracle常用管理命令 1 crs打頭的命令，主要使用者集群底層結構的管理，位於 oracle crs home bin下，一般在系統安裝完畢後只用到 crs s...