近期发现alert日志中出现如下信息，通过翻阅资料 大都是讲由于同步时间引起的错误，但本人并不是十分确定还是手动亲自试了一下，果然系统立即重新启动。


Thu Jul  8 01:14:17 2010
 LMS 0: 7903 GCS shadows traversed, 4001 replayed
Thu Jul  8 01:14:17 2010
 LMS 2: 7977 GCS shadows traversed, 4001 replayed
Thu Jul  8 01:14:17 2010
 LMS 1: 7888 GCS shadows traversed, 4001 replayed
 LMS 1: 7957 GCS shadows traversed, 4001 replayed
 LMS 1: 6164 GCS shadows traversed, 3120 replayed
Thu Jul  8 01:14:17 2010
 LMS 3: 7984 GCS shadows traversed, 4001 replayed
 LMS 3: 8025 GCS shadows traversed, 4001 replayed
 LMS 3: 4929 GCS shadows traversed, 2489 replayed
Thu Jul  8 01:14:17 2010
 LMS 0: 8069 GCS shadows traversed, 4001 replayed
Thu Jul  8 01:14:17 2010
 LMS 2: 7947 GCS shadows traversed, 4001 replayed
Thu Jul  8 01:14:17 2010
 LMS 0: 5631 GCS shadows traversed, 2811 replayed
Thu Jul  8 01:14:17 2010
 LMS 2: 7957 GCS shadows traversed, 4001 replayed
 LMS 2: 5716 GCS shadows traversed, 2875 replayed
Thu Jul  8 01:14:17 2010
 Submitted all GCS remote-cache requests
 Post SMON to start 1st pass IR
 Fix write in gcs resources
Reconfiguration complete
Thu Jul  8 01:28:20 2010
db_recovery_file_dest_size of 9400 MB is 6.65% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Thu Jul  8 01:58:35 2010
ALTER SYSTEM SET service_names='SYS$SYS.KUPC$S_1_20100708010002.EASRAC','easrac' SCOPE=MEMORY SID='easrac1';
Thu Jul  8 02:00:03 2010
The value (30) of MAXTRANS parameter ignored.
Thu Jul  8 02:00:05 2010
ALTER SYSTEM SET service_names='easrac' SCOPE=MEMORY SID='easrac1';
Thu Jul  8 02:00:06 2010
ALTER SYSTEM SET service_names='easrac','SYS$SYS.KUPC$C_1_20100708020005.EASRAC' SCOPE=MEMORY SID='easrac1';
Thu Jul  8 02:00:06 2010
ALTER SYSTEM SET service_names='SYS$SYS.KUPC$C_1_20100708020005.EASRAC','easrac','SYS$SYS.KUPC$S_1_20100708020005.EASRAC' SCOPE=MEMORY SID='easrac1';