时间莫名奇妙的慢了

ccshu

遇到故障了，各位帮忙参谋一下。RAC的node2昨天因asm故障发生重启，现在alert的日志慢了14个小时，可是sqlplus  select sysdate 是正常的，主机时间也正常，有人遇到过么？

[ 本帖最后由 ccshu 于 2012-2-17 15:45 编辑 ]

ccshu

时区是正常的。

Maclean Liu(刘相兵

action plan:

date
echo $TZ

cluvfy stage -post crsinst  -n all -verbose


check ntpd on your OS

check ctssd

crsctl status res -t -init

select dbtimezone from dual
/

select sessiontimezone from dual
/

ccshu

SQL> show parameter time_zone
SQL> select dbtimezone from dual
/


select sessiontimezone from dual
/
2

DBTIME
------
+08:00


SQL> SQL>
2



SESSIONTIMEZONE
---------------------------------------------------------------------------
+08:00



env|grep -i tz
TZ=BEIST-8

cameldba

感觉是客户端的时区有问题，比如GRID用户的时区设置和ORACLE用户的时区设置

Maclean Liu(刘相兵

"sqlplus  select sysdate 是正常的"

就你截的图来看 当时的OS时间是15:36  而 sysdate 返回的是 01:36 ， 何以得出select sysdate from dual 是正常的这个结论？


群中 沧海明月的 建议 mos  227334.1

1. My Alert.log has wrong time for some or all entry's.
   
2. 
   
3. The time used for the message in the alert.log is the same as "sysdate" for the process that is writing to the alert.log. Alert.log messages are not written by "Oracle" they are written by the Oracle proces that is responsible for that error/message (including user sessions). Most messages in the Alert.log are written by background processes like Pmon, the used "sysdate" for the background processes is defined (on unix) by the TZ variable set when the database was started.
   
4. If however a other process (like a user process/session encountering an error or doing a shutdown of the database) writes to the Alert.log and that user session uses a other TZ setting then the time for the error or parts of the shutdown sequence will be using a different time compared to the entry's written by the background processes (like log switches).
   
5. 
   
6. Note that:
   
7. a)if you do a "select to_char(sysdate,'DD-MON-YY HH24:MI:SS') from dual;" will give a correct result, even with a ORACLE_SID connection because here the environment is set by the executable that is spawning the process and that is sqlplus (or the listener if it's a listener connection), not the database kernel.
   
8. You need to see what is actually "off", if this is the shutdown time for example or the time for a application error then simply use the correct TZ for the session (which can be batch job) that does the shut down. If entry's like logswitches are "off" from the expected time then you need to restart the database and listener with the required TZ setting.
   
9. b) This has nothing to do with the database timezone, session time etc.

复制代码

与以上描述不符合的是 这里 sysdate返回的时间也是错误的



建议

1. 确认TZ 变量，从第一张截图来看 是 远程登录 ， 所以你确认该变量 要在多台服务器上。 不要再截图了 ！

2. 上传 该 oracle实例 最新的 vktm 后台进程的trace文件 及 alert.log 告警日志