Shulou(Shulou.com)06/01 Report--

The cause is:

Inconsistent data events in credit database lead to confusion of data (RAC cluster), inconsistency between PLSQL query time and database time, which seriously affects business. Because it was only a chance encounter before, coupled with the experience of MySQL time zone resolution, I feel that it can be solved very quickly, however, it is not as simple as I thought. The following is the story of the whole incident, which can be regarded as experience sharing. (there is vsp, so you can only take screenshots)

1. Check the local time and time zone of the two servers.

As you can see, Asia/Shanghai CST Beijing time East 8. (GMT stands for GMT)

2. Use sysdba to check the local time:

AM means morning and PM means afternoon. There's nothing unusual. 2.1) Log in with other ordinary accounts

2.2) use PLSQL to log in to an ordinary account and log in remotely to view

Notice the arrow: it becomes-8:00, 16 hours slow. GMT-8, but datatimezone is fine.

Tip: the values of SYSDATE and SYSTIMESTAMP are not affected by the database parameter DBTIMEZONE, and the environment variables of the operating system time zone (such as TZ) will affect their input, because SYSDATE and SYSTIMESTAMP actually return values directly by calling the underlying API of the operating system. The setting of TZ environment variables at the operating system level not only directly affects the values of sysdate and systimestamp, but also affects the timestamp of database log writing.

The setting of DBTIMEZONE affects the values of two data types in the database:

1) TimeStamp with Time Zone

2) TimeStamp with Local Time Zone.

3. Check the setting of environmental variables

Because you use the same account, PLSQL remote login-8:00, check other databases are + 8:00, local time is UTC:+8:00

Therefore, it can only be checked from the database.

# srvctl getenv listener-l LISTENER-envs "TZ"

3.1) Database time zone:

And I found nothing unusual.

Troubleshooting ideas:

No exception was found in terms of system time, database time, rac snooping and environment variables, and it is likely that someone has modified the parameters.

Solution:

Communicate with dba, modify the grid environment variable time zone "Asia/Shanghai", restart the database in batches, monitor the recovery, and solve the problem.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.