Este problema afecta ambos servidores.
Durante la conmutación por error de SP, cuando un SP se convierte en el SP activo, debe volver a rellenar el conjunto actual de fallos guardados en la base de datos de fallos. Si otras áreas del sistema solicitan información sobre fallos antes de que se complete este proceso, es posible que se observen los siguientes comportamientos.
Es posible que se publique un fallo duplicado. Se identifica la misma clase de informe electrónico, la misma clase de fallo y el mismo recurso para ambos fallos. La única diferencia es el registro de hora para cada fallo.
Es posible que se publique fault.fruid.replay para una FRU que ya presenta un fallo.
No se muestran algunos o ninguno de los fallos que diagnostica Oracle ILOM en el host después de una conmutación por error de SP, pero todos los fallos se muestran si se restablece la conexión de ip-transport de FMA.
Solución alternativa: para evitar este problema, se deben resolver todas las condiciones de fallo y se deben realizar todas las acciones de servicio antes de iniciar una conmutación por error de SP.
Si ocurre un fallo no planificado y se dispara este problema, use el siguiente comando en la petición de datos de Oracle Solaris:
root@host-name:~# fmadm reset ip-transport
Recuperación: use el siguiente comando en la petición de datos de Oracle Solaris para restablecer la conexión de ip-transport y hacer que se vuelva a reproducir la lista de fallos.
root@host-name:~# fmadm reset ip-transport