首先，对问题其中涉及到的知识进行介绍。
1. 从版本号11.2.0.2 開始oracle 集群（GI）開始拥有了自己的时区和一些其它配置。这些配置保存在配置文件<gi_home>/crs/install/s_crsconfig_<节点名>_env.txt中。
比如：
TZ=Asia/Shanghai
NLS_LANG=AMERICAN_AMERICA.AL32UTF8
TNS_ADMIN=
ORACLE_BASE=
我们能看到变量TZ 用于定义集群的时区。当然，这个集群的时区是在安装GI时从操作系统获得的。
既然集群有了时区，那么我们就须要保证GI的时区和操作系统的设置是一致的，而且当操作系统的时区发生改变时，GI的时区也须要改变。而改动集群时区的基本步骤是（改动<gi_home>/crs/install/s_crsconfig_<节点名>_env.txt文件，重新启动节点）。
2. 当数据库或者listner 使用srvctl 命令或者随着GI启动被启动时，环境变量会继承GI的时区。您也能够通过以下的命令来手动设置数据库和listener资源的环境变量。
srvctl setenv database -d <dbname> -t 'TZ=<时区>'
srvctl setenv listener -l <listenername> -t 'TZ=<时区>'
3. sysdate返回的值并不依赖于数据库的时区设置，oracle 仅仅是简单的从操作系统获取系统时间返回（比如：调用os 函数gettimeofday）。
所以，改动数据库的时区对于这样的问题并没有帮助。而相应的server进程所使用的环境变量TZ才会影响返回的系统时间。
我们会通过一个详细的样例来解释。
在这个样例中，我们使用sqlplus 创建数据库链接。并对listener进程搜集truss 信息
sqlplus scott/tiger@test
2.listner 进程收到了相应的链接。并产生了相应的server process.
524732: psargs: /u01/app/11.2.0/grid/bin/tnslsnr LISTENER -inherit
......
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<sid name> (LOCAL=NO) <<<<<<<< server进程环境变量被指定
483742: envp: _=/u01/app/11.2.0/grid/bin/oraagent.bin LANG=en_US LOGIN=root
483742: __CLSAGENT_INCARNATION=2 _ORA_AGENT_ACTION=TRUE PATH=
483742: NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1 __CLSAGENT_USER_NAME=oracle
......
483742: ENV_FILE=/u01/app/11.2.0/grid/crs/install/s_crsconfig_<node name>_env.txt
......
483742: __CLSAGENT_LOGDIR_NAME=crsd PWD=/ TZ=Asia/Shanghai <<<< 时区被指定。
当然，假设您没有对lisetner 搜集truss 输出。
您也能够通过操作系统命令获得相应进程的环境变量。比如：ps eauwww <pid from above>。您能够通过MOS note 373303.1 中的内容获得不同平台的命令。
另外。以上的数据库是通过GI agent 启动的，假设数据库是手动启动的（比如：startup 命令），那么。输出会不同。当然, pmon在注冊数据库服务到listener时也会将自己的环境变量注冊到相应的service上。
所以，在诊断RAC 环境下sysdate 返回错误时间的问题时，我们须要检查下面信息。
1. 操作系统级别的时区设置，并确保操作系统命令date 能返回正确的时间。对于怎样查看不同平台的时区设置，请參考note 1209444.1
2. 确认GI 配置文件<gi_home>/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 <db_name> -t 'LIBPATH=<gi_home/lib>'
注意：不同的Unix平台，以上命令可能会不同。
所以，我们也去要确认database 资源的LIBPATH 或 LD_LIBRARY_PATH 变量是否被设定。
比如：srvctl getenv database -d <db_name>
另外，在诊断这样的问题时。须要搜集下面信息。
1. <gi_home>/crs/install/s_crsconfig_<节点名>_env.txt文件
2. 操作系统时区设置（cat /etc/sysconfig/clock） 和环境变量TZ的设置。以及pmon进程的环境变量。
3. database和 listener资源的环境变量
比如：srvctl getenv database -d <db_name>
srvctl getenv listener -l <listener name>
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: mp ==> 确保该路径存在
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
我希望诊断范畴的上述解释似这个问题将是有益的。
版权声明：本文博客原创文章。博客，未经同意，不得转载。