Gestión de fallos en Oracle® Solaris 11.2

Salir de la Vista de impresión

Actualización: Julio de 2014
 
 

Reparación de fallos o defectos

Puede configurar Oracle Auto Service Request (ASR) para que solicite automáticamente servicio a Oracle cuando se producen problemas de hardware específicos. Consulte http://www.oracle.com/asr para obtener más información sobre ASR.

Cuando se produce un fallo en un componente del sistema, el gestor de fallos puede reparar el componente de forma implícita, o usted puede reparar el componente de forma explícita.

Reparación implícita

Una reparación implícita se puede producir cuando el componente defectuoso se reemplaza o elimina, siempre y cuando el componente tenga información de números de serie mediante los cuales el daemon del gestor de fallos (fmd) pueda realizar un seguimiento. En muchos sistemas basados en SPARC, la información de números de serie se incluye en los FMRI a fin de que fmd pueda determinar cuándo se dejaron fuera de servicio los componentes, ya sea mediante el reemplazo u otros medios (por ejemplo, una lista negra). Cuando fmd determina que un componente se ha dejado fuera de servicio, el gestor de fallos ya no muestra ese componente en la salida de fmadm faulty. El componente se mantiene en la memoria caché de recursos interna del gestor de fallos hasta que el evento de fallo tenga 30 días de antigüedad.

Cuando fmd detecta recursos de CPU o memoria defectuosos, estos recursos se colocan en una lista negra. Los recursos defectuosos que se encuentran en la lista negra no se pueden reasignar hasta que fmd indique que se están reparando.

Reparación explícita

A veces no hay disponible información del número de serie FRU aunque el FMRI incluya un identificador de chasis. En este caso, fmd no puede detectar un reemplazo de FRU, y usted debe realizar una reparación explícita mediante el comando fmadm con el subcomando replaced, repaired o acquit, como se muestra en las siguientes secciones. Sólo debe realizar reparaciones explícitas si así lo indica un procedimiento de reparación documentado específico.

Estos comandos fmadm llevan los siguientes operandos:

  • El UUID, que también se muestra como EVENT-ID en la salida del gestor de fallos, identifica el evento de fallo. El UUID sólo se puede utilizar con el comando fmadm acquit. Puede especificar que todo el evento se puede ignorar sin problemas o puede especificar que un determinado recurso no es un sospechoso en este evento.

  • FMRI y label identifican el recurso sospechoso con fallos. En Example 2–1, se muestran ejemplos del FMRI y la etiqueta de un recurso. Normalmente, es más fácil utilizar la etiqueta que el FMRI.

Un caso se considera reparado cuando el UUID del evento de fallo se libera o cuando todos recursos sospechosos se han reparado, reemplazado, eliminado o liberado. Un caso que se repara pasa al estado FMD_CASE_REPAIRED, y el gestor de fallos genera un evento list.repaired.