UTC与时区问题

刚才对vm进行snapshot操作的时候，发现时间全不对：
与现在正差了8个小时，猜到应该是UTC的原因。

这种情况大家应该经常遇到，就算时区、现在的时间设对了，时间仍然有问题。

我们开CRT连到ESXi的服务器上：
不过，我安装linux时都是去掉utc，关闭UTC情况就是这样。

当然如果你先装了一个windwos的话,linux也会自动关闭utc的：
下面说几个小知识：
GMT（Greenwich Mean Time，格林威治标准时间）：是指位于英国伦敦郊区的皇家格林尼治天文台的标准时间，因为本初子午线被定义在通过那里的经线。

UTC（Universal Time/Temps Cordonn 世界标准时间）
CST（Central Standard Time 国家标准时间，一说中原标准时间）;，中国标准时间（China Standard Time）
GMT + 8 = UTC + 8 = CST
GMT+8是什么意思？
GMT 就是格林威治标准时间的英文缩写（Greenwich Mean Time 格林尼治标准时间），是世界标准时间。

gmt+8 是格林威治时间+8小时。

中国所在时区就是gmt+8 。

CST时间
CST却同时可以代表如下 4 个不同的时区：
Central Standard Time （USA） UT-6：00
Central Standard Time （Australia） UT+9：30
China Standard Time UT+8：00
Cuba Standard Time UT-4：00
可见，CST可以同时表示美国，澳大利亚，中国，古巴四个国家的标准时间。

在中国特指CST China Standard Time UTC+8：00 中国沿海时间（北京时间）
我们在安装linux的时候在设置时间的时候有一个选项，system clock uses UTC，那么这个UTC是什么意思呢？
世界协调时间（Universal Time Coordinated，UTC）
GPS 系统中有两种时间区分，一为UTC，另一为LT（地方时）两者的区别为时区不同，UTC就是0时区的时间，地方时为本地时间，如北京为早上八点（东八区），UTC时间就为零点，时间比北京时晚八小时，以此计算即可
解决办法：
vi /etc/default/rcS
# Default settings for the scripts in /etc/rcS.d/
#
# For information about these variables see the rcS(5) manual page.
#
# This file belongs to the "initscripts" package.
TMPTIME=0
SULOGIN=no
DELAYLOGIN=no
UTC=yes //把yes改为no
VERBOSE=no
FSCKFIX=no
昨晚回去找了下以前给河北国家电网巡检时文档的一部分。

主要是时区的设置错误，导致了严重的性能问题。

这跟UTC一样，会导致数据库错误地判断现在的时间。

经检查，发现数据库时区为西5区，即纽约时区：
SQL> SELECT DBTIMEZONE FROM DUAL;
DBTIMEZONE
----------
-05:00
SQL> SELECT SESSIONTIMEZONE FROM DUAL;
SESSIONTIMEZONE
----------
+08:00
虽然时区的设置有误不影响管控日常的运作，但却严重影响ORACLE自身的优化器统计信息收集功能。

我们查找下dba_scheduler_job_log表（但dba_scheduler_jobs表报ORA-01882错误，需要修改日期格式），搜寻ORACLE以执行过的JOB信息，结果如下（7月21-7月31
绿色字体为：回收日志时间
蓝色字体为：任务正常结束时间
紫色字体为：任务非正常结束时间
褐色字体为：其他手动调动任务时间
我们惊讶地发现，本来应该晚上22：00至第二天06：00（周末全天）执行的ORACLE优化器统计信息收集竟然在白天执行。

再计算下上面所查询的时区问题，数据库服务器时区为西5区，即纽约时区，我们所在的时区为东8区，即北京时区，两者按世界时区计算规则，东8区早于西5区13个小时。

这样我们再来查看优化器统计信息收集的执行时间，晚22：00加13小时为白天11：00，早上06：00加13小时为晚19：00，这与我们上面所查询的数据完全吻合。

即优化器统计信息收集从下午11：00开始执行，正常结束于下午19：00（非正常结束即强行STOP，即2011-07-21 19:00:02的情况）。

我们知道，ORACLE优化器统计信息收集是为了提供给ORACLE查询时更好的执行计划，但同时也会由于其全库扫描带来大量的物理读（取7月25-27日的AWR采样）：
（出自2011/7/25 10：00-12：00 AWR报告）
（出自2011/7/26 10：00-12：00 AWR报告）
（出自2011/7/26 12：00-14：00 AWR报告）
（出自2011/7/26 14：00-16：00 AWR报告）
（出自2011/7/27 10：00-12：00 AWR报告）
（出自2011/7/27 12：00-14：00 AWR报告）
（出自2011/7/27 14：00-16：00 AWR报告）
从上样的采样已经发现，ORACLE优化器统计信息功能占用了数据库大半甚至绝大部分的物理读，这将非常严重影响管控数据库的数据读取功能。

而且由于ORACLE优化器统计信息的读取的查询优先级是较高的，亦可能导致行级锁，对性能的打击亦是严重的：
（出自2011/7/25 10：00-12：00 AWR报告）
前面亦提到查询dba_scheduler_jobs表时报ORA-01882错误，需要修改日期格式才可能查询，我们再对日志格式参数nls_date_format进行验证：
SQL> SHOW PARAMETER nls_date_format;
NAME TYPE VALUE
------------------------------------ ----------- ---------------------
nls_date_format string
发现nls_date_format亦未设置，导致查询某些时间时无法从ORACLE自带的系统表中获得正确的数据，需要进行设置。

因此，我们得出结论，数据库的时区设置不正确而导致的ORACLE优化器统计信息在客户正常工作时间运行，继而使数据库无法达到正常地读取数据文件的速度，是导致河北电力财务管控数据库日常正常工作时性能不高的主要原因。

建议科信部门将数据库时间更改为东八区，即time_zone='+08:00'，并重启数据库生效。