RAC下主機修改時區(qū)導(dǎo)致db無法open怎么辦

這篇文章主要介紹了RAC下主機修改時區(qū)導(dǎo)致db無法open怎么辦，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

11.2.0.4.rac 主機修改時區(qū)導(dǎo)致db無法open 

os:redhat linux

db:11.2.0.4 rac

desc:crs啟動后，除db外都可以正常啟動。

查看crs和db的log，文件最后修改時間跟主機時間一致，但log里的時間不一致，如下為crs和dblog里的日志

crs log

==========================================

2015-05-04 10:30:24.139:

[client(19430)]CRS-4743:File /u02/app/11.2.0/grid/oc4j/j2ee/home/OC4J_DBWLM_config/system-jazn-data.xml was updated from OCR(Size: 13365(New), 13378(Old) bytes)

2015-05-04 10:31:33.583:

[cssd(18287)]CRS-1601:CSSD Reconfiguration complete. Active nodes are gzsjdb1 gzsjdb2 .

2015-05-04 10:31:56.583:

[crsd(19096)]CRS-2772:Server 'gzsjdb2' has been assigned to pool 'Generic'.

2015-05-04 10:31:56.584:

[crsd(19096)]CRS-2772:Server 'gzsjdb2' has been assigned to pool 'ora.jzxn'. #出問題時日志

2015-05-04 16:31:02.619: #問題解決后的日志

[client(26295)]CRS-10051:CVU found following errors with Clusterware setup : PRVF-7573 : Sufficient swap size is not available on node "gzsjdb1" [Required = 16GB (1.6777216E7KB) ; Found = 10GB (1.0485752E7KB)]

PRVF-5415 : Check to see if NTP daemon or service is running failed

PRVG-1101 : SCAN name "scan-cl

db log

============================

Fri Jun 12 03:45:16 2015 #出問題時日志

Thread 1 advanced to log sequence 54 (LGWR switch)

  Current log# 3 seq# 54 mem# 0: /oradata/oradata/jzxn/redo03.log

Fri Jun 12 03:47:38 2015

Thread 1 cannot allocate new log, sequence 55

Checkpoint not complete

  Current log# 3 seq# 54 mem# 0: /oradata/oradata/jzxn/redo03.log

Fri Jun 12 03:47:43 2015

opidcl aborting process unknown ospid (29020) as a result of ORA-28

Fri Jun 12 05:13:24 2015

Thread 1 advanced to log sequence 55 (LGWR switch)

  Current log# 1 seq# 55 mem# 0: /oradata/oradata/jzxn/redo01.log

Fri Jun 12 14:31:04 2015  #問題解決后的日志

Starting ORACLE instance (normal)

************************ Large Pages Information *******************

Per process system memlock (soft) limit = UNLIMITED

Total Shared Global Region in Large Pages = 0 KB (0%)

解決過程：起初沒有注意這個時間問題，對crs重啟后，仍然是db的資源不正常，后發(fā)現(xiàn)日志時間不對，經(jīng)詢問項目組節(jié)點2由默認時間(Etc/GMT-1)改為東8區(qū)(Asia/Shanghai)的時區(qū)后，節(jié)點2就無法連接db，節(jié)點1修改時區(qū)后仍可連接。直至今天節(jié)點1也無法連接db.

出現(xiàn)db日志、crs日志等和主機時間不一致，是因為在rac新頒布中，grid也有屬于自己的時區(qū)，在安裝過程中，默認值與操作系統(tǒng)的TZ環(huán)境變量相同。

本例是因為時間不一致，導(dǎo)致db無法open，修改grid時區(qū)后，重啟crs，db可以正常open.

1.查看系統(tǒng)時區(qū)

$cat /etc/sysconfig/clock

ZONE=Asia/Shanghai

2.查看crs里配置的時區(qū)

[root@gzsjdb1 install]# cat s_crsconfig_gzsjdb1_env.txt.bak

### This file can be used to modify the NLS_LANG environment variable, which determines the charset to be used for messages.

### For example, a new charset can be configured by setting NLS_LANG=JAPANESE_JAPAN.UTF8 

### Do not modify this file except to change NLS_LANG, or under the direction of Oracle Support Services

TZ=Etc/GMT-1 #仍然為默認的美國時區(qū)

NLS_LANG=AMERICAN_AMERICA.AL32UTF8

TNS_ADMIN=

ORACLE_BASE=

3.修改crs的時區(qū)為Asia/Shanghai

[root@gzsjdb1 install]# cat s_crsconfig_gzsjdb1_env.txt

### This file can be used to modify the NLS_LANG environment variable, which determines the charset to be used for messages.

### For example, a new charset can be configured by setting NLS_LANG=JAPANESE_JAPAN.UTF8 

### Do not modify this file except to change NLS_LANG, or under the direction of Oracle Support Services

TZ=Asia/Shanghai

NLS_LANG=AMERICAN_AMERICA.AL32UTF8

TNS_ADMIN=

ORACLE_BASE=

[root@gzsjdb1 install]# pwd

/u02/app/11.2.0/grid/crs/install

[root@gzsjdb1 install]#

4.重啟crs

5.經(jīng)驗證crs日志，db日志等都與主機保持一致，通過plsqldev可以登錄數(shù)據(jù)庫。

[root@gzsjdb2 ~]# date

Fri Jun 12 15:12:58 CST 2015

感謝你能夠認真閱讀完這篇文章，希望小編分享的“RAC下主機修改時區(qū)導(dǎo)致db無法open怎么辦”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關(guān)注億速云行業(yè)資訊頻道，更多相關(guān)知識等著你來學(xué)習!