操作系统的时区设置会影响数据库查询SYSDATE和SYSTIMESTAMP的值

SYSDATE和SYSTIMESTAMP的值并不受数据库参数DBTIMEZONE的影响,操作系统时区的环境变量(如TZ)会影响它们的输入,因为SYSDATE和SYSTIMESTAMP实际是调用操作系统底层接口直接返回值。

DBTIMEZONE的设置只会影响数据库内两种数据类型的值:一种是TimeStamp with Time Zone,另一种是TimeStamp with Local Time Zone。

操作系统层面TZ环境变量的设置直接影响sysdate和systiestamp的值,同时也会影响数据库日志写入的时间戳。

先来以下一段官方相关解释:

SYSTIMESTAMP is the timestamp on the server machine itself and is obtained on Unix platforms by calling "
GetTimeOfDay " and on Windows by calling "GetSystemTime" to get the servers local time.

This means that SYSTIMESTAMP, just like SYSDATE depends on Unix platforms on the UNIX time configuration (= Unix TZ variable) for the Unix session when the database and listener where started.

The SYSDATE and SYSTIMESTAMP function simply performs a system-call to the Operating System to get the time (a "gettimeofday" call).

以下通过简单的实验来证明:

SQL> select to_char(sysdate,‘DD-MON-YY HH24:MI:SS‘) from dual;

TO_CHAR(SYSDATE,‘DD-MON-YYHH24:MI:SS‘)

------------------------------------------------------

17-OCT-14 11:51:25             <<<<<这里输出日期为17号

SQL> connect sys/[email protected] as sysdba

Connected.

SQL> select to_char(sysdate,‘DD-MON-YY HH24:MI:SS‘) from dual;

TO_CHAR(SYSDATE,‘DD-MON-YYHH24:MI:SS‘)

------------------------------------------------------

17-OCT-14 11:51:33

SQL> !

[[email protected] ~]$ date

Fri Oct 17 11:51:38 CST 2014    <<<<<这里输出日期为17号

以上输出正常的时间,接下来修改时区环境变量之后做对比

export TZ=America/Anchorage

SQL> select to_char(sysdate,‘DD-MON-YY HH24:MI:SS‘) from dual;

TO_CHAR(SYSDATE,‘DD-MON-YYHH24:MI:SS‘)

------------------------------------------------------

16-OCT-14 19:53:50                        <<<<<这里输出日期为16号

SQL> connect sys/[email protected] as sysdba

Connected.

SQL> select to_char(sysdate,‘DD-MON-YY HH24:MI:SS‘) from dual;

TO_CHAR(SYSDATE,‘DD-MON-YYHH24:MI:SS‘)

------------------------------------------------------

16-OCT-14 19:53:58

SQL> !

[[email protected] ~]$ date

Thu Oct 16 19:54:06 AKDT 2014      <<<<<这里输出日期为16号

查看数据库alert日志:

Fri Oct 17 11:51:57 CST 2014      
<<<停库日期为17号

ALTER DATABASE DISMOUNT

Completed: ALTER DATABASE DISMOUNT

ARCH: Archival disabled due to shutdown: 1089

Shutting down archive processes

Archiving is disabled

Archive process shutdown avoided: 0 active

ARCH: Archival disabled due to shutdown: 1089

Shutting down archive processes

Archiving is disabled

Archive process shutdown avoided: 0 active

Thu Oct 16 19:53:32 AKDT 2014       <<<启库日期为16号

Starting ORACLE instance (normal)

LICENSE_MAX_SESSION = 0

LICENSE_SESSIONS_WARNING = 0

Picked latch-free SCN scheme 3

结合以上实验做阐述,请一定正常设置操作系统环境变量,避免不必要的麻烦。

-------------------------------------------------------------------------------------------------

本文来自于我的技术博客 http://blog.csdn.net/robo23

转载请标注源文链接,否则追究法律责任!

时间: 2024-10-10 15:27:45

操作系统的时区设置会影响数据库查询SYSDATE和SYSTIMESTAMP的值的相关文章

MySQL性能管理及架构设计(一):什么影响了数据库查询速度、什么影响了MySQL性能

一.什么影响了数据库查询速度 1.1 影响数据库查询速度的四个因素 1.2 风险分析 QPS:Queries Per Second意思是"每秒查询率",是一台服务器每秒能够相应的查询次数,是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准. TPS:是TransactionsPerSecond的缩写,也就是事务数/秒.它是软件测试结果的测量单位.客户机在发送请求时开始计时,收到服务器响应后结束计时,以此来计算使用的时间和完成的事务个数. Tips:最好不要在主库上数据库备份,

经验:什么影响了数据库查询速度、什么影响了MySQL性能 (转)

一.什么影响了数据库查询速度 1.1 影响数据库查询速度的四个因素 1.2 风险分析 QPS:Queries Per Second意思是“每秒查询率”,是一台服务器每秒能够相应的查询次数,是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准. TPS:是TransactionsPerSecond的缩写,也就是事务数/秒.它是软件测试结果的测量单位.客户机在发送请求时开始计时,收到服务器响应后结束计时,以此来计算使用的时间和完成的事务个数. Tips:最好不要在主库上数据库备份,大型活动前

bboss持久层设置数据库查询fetchsize参数方法

jdbc驱动程序api提供了指定了查询语句fetchsize的方法,有些数据库(比如oracle)本身提供了fetchsize的默认值,这样进行大量数据查询时,不会因为返回的结果集太大导致jvm爆掉,有些数据库可能没有默认设置fetchsize,因此需要手动指定.bboss持久层设置数据库查询fetchsize参数方法很简单,只要在poolman.xml文件的datasource中指定一个queryfetchsize参数即可,如果不指定就采用数据库驱动提供的默认值. 设置queryfetchsi

数据库查询超级慢,数据库死锁的查看与解决

今天帮同事解决问题,页面报“等待的操作过时”,设置断点发现数据库查询语句处异常,检查了数据库一通,发现连接数据库也连接不上了,搜了一圈找到解决办法.留着备用啦 首先查出死锁,可用sql语句 SELECT blocking_session_id '阻塞进程的ID', wait_duration_ms '等待时间(毫秒)', session_id '(会话ID)' FROM sys.dm_os_waiting_tasks 或者创建以下存储过程,查询出来 USE [master] GO /******

oracle、mysql时区设置对timestamp的不同影响

因最近国际去Oracle上MySQL,这就不可避免的涉及到时区和timestamp问题.做一下实验,总结一下. Oracle 首先看下oracle concepts对timestamp的定义: The TIMESTAMP data type is an extension of the DATE data type. It stores fractional seconds in addition to the information stored in the DATE data type.

【数据库运维】数据库(服务器)的时区设置及世界主要地区的时区

[时区设置不当会有什么问题] 当进行海外项目运维的时候,经常会遇到时区设置的问题,如果时区设置不当 或者 相同项目的服务器之间的时区不一致,都会有导致项目的数据异常的风险. 如果数据表的字段使用了date类型的字段,字段的默认值是sysdate,并且程序插入记录的时候使用了字段的默认值,那么就有可能导致数据异常.在修改数据库服务器的时区时,也是需要谨慎操作的. [服务器时间同步的方法] # 时间同步服务器请修改为要求的地址(建议使用Windows的地址,因为世界上大部分个人电脑使用的是Windo

优化SQL Server数据库查询方法

SQL Server数据库查询速度慢的原因有很多,常见的有以下几种: 1.没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷) 2.I/O吞吐量小,形成了瓶颈效应. 3.没有创建计算列导致查询不优化. 4.内存不足 5.网络速度慢 6.查询出的数据量过大(可以采用多次查询,其他的方法降低数据量) 7.锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷) 8.sp_lock,sp_who,活动的用户查看,原因是读写竞争资源. 9.返回了不必要的行和列 10.查询语句不好,没有优

SQL Server数据库查询速度慢的原因和解决方法

问 SQL Server数据库查询速度慢的原因有很多,常见的有以下几种: 1.没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷) 2.I/O吞吐量小,形成了瓶颈效应. 3.没有创建计算列导致查询不优化. 4.内存不足 5.网络速度慢 6.查询出的数据量过大(可以采用多次查询,其他的方法降低数据量) 7.锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷) 8.sp_lock,sp_who,活动的用户查看,原因是读写竞争资源. 9.返回了不必要的行和列 10.查询语句不好,没

转载 50种方法优化SQL Server数据库查询

原文地址 http://www.cnblogs.com/zhycyq/articles/2636748.html 50种方法优化SQL Server数据库查询 查询速度慢的原因很多,常见如下几种: 1.没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷) 2.I/O吞吐量小,形成了瓶颈效应. 3.没有创建计算列导致查询不优化. 4.内存不足 5.网络速度慢 6.查询出的数据量过大(可以采用多次查询,其他的方法降低数据量) 7.锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷