调整RAC主机时间

因为时钟服务器慢了27秒，需要调整时钟服务器时间，这将会影响到依赖于此时钟的所有服务器时间，包括10套左右的RAC数据库主机。

下面的文章（Metalink ID：220970.1）是我能找到的关于RAC中时间调整的比较直接的说明了：
Minor changes in time (in the seconds range) are harmless for RAC and the Oracle clusterware.(BUG除外)

Does RAC work with NTP (Network Time Protocol)?

YES! NTP and RAC are compatible, as a matter of fact, it is recommended to setup NTP in a RAC cluster, for Oracle 8i/9i and 10g.

From the Documentation:
Oracle? Database Oracle Clusterware and Oracle Real Application Clusters Installation Guide 10g Release 2 (10.2) for Linux B14203-05
page 2-21:
"Node Time Requirements
Before starting the installation, ensure that each member node of the cluster is set as closely as possible to the same date and time. Oracle strongly recommends using the Network Time Protocol feature of most operating systems for this purpose, with all nodes using the same reference Network Time Protocol server."

Each machine has a different clock frequency and as a result a slightly different time drift. NTP computes this time drift every about 15 minutes, and stores this information in a "drift" file, it then adjusts the system clock based on this known drift as well as compares it to a given time-server the sys-admins sets up. This is the recommended approach.

Keep the following points in mind:

Minor changes in time (in the seconds range) are harmless for RAC and the Oracle clusterware. If you intend on making large time changes it is best to shutdown the instances and the entire Clusterware stack on that node to avoid a false eviction, especially if you are using the 10g low-brownout patches, which allow really low misscount settings.

Backup/recovery aspect of large time changes are documented in note 77370.1, basically you can't use RECOVER DATABASE UNTIL TIME to reach the second recovery point, It is possible to overcome with RECOVER DATABASE UNTIL CANCEL or UNTIL CHANGE. If you are doing complete recovery (most of the times) then this is not an issue since the Oracle recovery code uses SCN (System Change Numbers) to advance in the redo/archive logs. The SCN numbers never go back in time (unless a reset-logs operation is performed), there is always an association of an SCN to a human readable timestamp (which may change forward or backwards), hence the issue with recovery until point in time vs. until SCN/Cancel.

If DBMS_SCHEDULER is in usage it will be affected by time changes, as it's using actual clock rather than SCN.

On platforms with OPROCD get fix for bug 5015469 "OPROCD REBOOTS NODE WHEN TIME IS SET BACK BY XNTPD"

Apart from these issues, the Oracle server is immuned to time changes, i.e. will not affect transaction/read consistency operations.

On Linux the "-x" flag can be added to the ntpd daemon to prevent the clock from going backwards.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10867315/viewspace-713893/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10867315/viewspace-713893/