故事最开始的起因，是监控发现v$log中的first_time时间，显示的是昨天的时间。而登录数据库检查sysdate是正常的时间。

我们可以模拟出来下面的故障：

session 1，用 TZ=EST5EDT起库，此时，可以看到v$log中的FIRST_TIME是12小时之前的。

[oracle11g@testdb2 ~]$  export TZ=EST5EDT
[oracle11g@testdb2 ~]$ 
[oracle11g@testdb2 ~]$ 
[oracle11g@testdb2 ~]$ 
[oracle11g@testdb2 ~]$ sqlplus "/ as sysdba"

SQL*Plus: Release 11.2.0.4.0 Production on Tue Oct 25 00:19:39 2016

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining
and Real Application Testing options

SQL>               
SQL> 
SQL> alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';

Session altered.

SQL> alter system switch logfile;
alter system switch logfile;

System altered.

SQL> alter system switch logfile;
alter system switch logfile;

select * from v$log;
System altered.

SQL> 
System altered.

SQL> 
System altered.

SQL>  select * from v$log
SQL> /

    GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIME          NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------------- ------------ -------------------
         1          1       5118   52428800        512          1 YES INACTIVE              13498701 2016-10-25 00:19:51     13498704 2016-10-25 00:19:52
         2          1       5119   52428800        512          1 YES INACTIVE              13498704 2016-10-25 00:19:52     13498707 2016-10-25 00:19:52
         3          1       5120   52428800        512          1 NO  CURRENT               13498707 2016-10-25 00:19:52   2.8147E+14

SQL> 
SQL> 
SQL> 
SQL> 
SQL> /

    GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIME          NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------------- ------------ -------------------
         1          1       5118   52428800        512          1 YES INACTIVE              13498701 2016-10-25 00:19:51     13498704 2016-10-25 00:19:52
         2          1       5119   52428800        512          1 YES INACTIVE              13498704 2016-10-25 00:19:52     13498707 2016-10-25 00:19:52
         3          1       5120   52428800        512          1 NO  CURRENT               13498707 2016-10-25 00:19:52   2.8147E+14

SQL> 
SQL> 
SQL> 
SQL> /

    GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIME          NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------------- ------------ -------------------
         1          1       5118   52428800        512          1 YES INACTIVE              13498701 2016-10-25 00:19:51     13498704 2016-10-25 00:19:52
         2          1       5119   52428800        512          1 YES INACTIVE              13498704 2016-10-25 00:19:52     13498707 2016-10-25 00:19:52
         3          1       5120   52428800        512          1 NO  CURRENT               13498707 2016-10-25 00:19:52   2.8147E+14

SQL>

新开一个session 2登录进去。可以看到sysdate是当前时间：

SQL> alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';

Session altered.

SQL> select sysdate from dual;

SYSDATE
-------------------
2016-10-25 12:20:25

SQL>

进一步发现，发生问题的原因是起库的时候，由于之前有一步操作是启动OGG，启动OGG时因为某些特别的原因，需要进行了unset TZ操作，所以导致使用了默认的TZ=EST5EDT。操作完之后，没有再TZ=EAT-8，所以变成以TZ=EST5EDT启库了

处理方案：
加载正确的TZ环境变量，重启数据库。
另外，检查数据库中是否存在dba_tab_column中的data_type字段是否存在timestamp with local time zone的应用的表，如果没有，则不影响应用。注意这里是with local time zone才有影响，如果是with time zone则不受影响。