如何诊断rac环境下sysdate 返回错误时间问题

最近处理了一些rac环境下访问sysdate返回错误时间的问题,而这种问题往往出现在数据库链接是通过Listener创建的情况下,而且,大部分情况下都是和时区设置相关的。在这篇文章中我们会针对如何诊断这种问题进行解释。这篇文章适用于版本11.2.0.2 及以上版本。

首先,对问题当中涉及到的知识进行介绍。1. 从版本11.2.0.2 开始oracle 集群(GI)开始拥有了自己的时区和一些其他配置,这些配置保存在配置文件<gi_home>/crs/install/s_crsconfig_<节点名>_env.txt中。例如:TZ=Asia/ShanghaiNLS_LANG=AMERICAN_AMERICA.AL32UTF8TNS_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)。所以,修改数据库的时区对于这种问题并没有帮助。而对应的服务器进程所使用的环境变量TZ才会影响返回的系统时间。

接下来,我们简单介绍一下客户端通过listener 连接到数据库时会经过那些过程。我们会通过一个具体的例子来解释。在这个例子中,我们使用sqlplus 创建数据库链接,并对listener进程搜集truss 信息

1.客户端连接数据库sqlplus scott/tiger@test2.listner 进程收到了对应的链接,并产生了对应的server process.524732: psargs: /u01/app/11.2.0/grid/bin/tnslsnr LISTENER -inherit……524732: kfork() = 496094496094: kfork() (returning as child …) = 0……496094: kfork() = 483742483742: kfork() (returning as child …) = 03. 为server process指定环境变量。483742: execve(0x0FFFFFFFFFFF2660, 0x0000000110773730, 0x000000011077B670) argc: 2483742: argv: oracle<sid name> (LOCAL=NO) <<<<<<<< 服务器进程环境变量被指定483742: envp: _=/u01/app/11.2.0/grid/bin/oraagent.bin LANG=en_US LOGIN=root483742: __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 <<<< 时区被指定。

我们能看到环境变量TZ的值在创建服务器进程时会被绑定到server process 中。当然,如果您没有对lisetner 搜集truss 输出。您也可以通过操作系统命令获得对应进程的环境变量,例如:ps eauwww <pid from above>,您可以通过MOS note 373303.1 中的内容获得不同平台的命令。另外,以上的数据库是通过GI agent 启动的,如果数据库是手动启动的(例如:startup 命令),那么,输出会不同。当然, pmon在注册数据库服务到listener时也会将自己的环境变量注册到对应的service上。

所以,在诊断RAC 环境下sysdate 返回错误时间的问题时,,我们需要检查以下信息。1. 操作系统级别的时区设置,并确保操作系统命令date 能返回正确的时间。对于如何查看不同平台的时区设置,请参考note 1209444.12. 确认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 中的信息仍然无法找到问题的原因,请搜集客户端和服务器端的sqlnet trace,以便确认是否有任何的’alter session set …’命令修改了会话的时区或者相关的变量。客户端sqlnet trace:设置以下参数到客户端的sqlnet.ora 文件中。trace_level_client=16trace_directory_client=c:\tmp ==> 确保该路径存在trace_file_client=clienttrace_unique_client=ontrace_timestamp_client=on服务器端sqlnet trace:设置以下参数到服务器端的sqlnet.ora文件中trace_level_server=16trace_file_server=servertrace_directory_server=/tmp ==> 确保该路径存在trace_timestamp_server=ON

希望以上的解释对大家诊断类似问题会有所帮助。

我们一路上兴致勃勃地参观,当夕阳西下时,才恋恋不舍地离开。

如何诊断rac环境下sysdate 返回错误时间问题

相关文章:

你感兴趣的文章:

标签云: