antecedentes:
Una persona a cargo del proyecto me informó que en las primeras horas de esta mañana, había un trabajo 30 minutos más lento en el sistema y necesitaba diagnosticar que había un problema.
problema:
¿Cuál es la razón por la que el tiempo de funcionamiento del sistema es 30 minutos más lento de lo habitual?
Idea principal:
Lo que ves no es la verdad y todos los hechos, tal vez solo fenómenos o solo pistas.
Para buscar la verdad y todos los hechos, debe ser paciente y realizar análisis científicos de manera sistemática.
¡O integral, o primaria y secundaria!
Metodología:
El análisis del problema es tridimensional:
- Percepción específica del usuario: tiempo de ocurrencia, sistema de ocurrencia, descripción del evento (no disponible, utilizable pero lento, qué tan lento)
1) Recopilación de datos: informe de AWR, uso de recursos del sistema operativo, base de datos y registro del sistema operativo, registro de la aplicación
- Análisis de datos: análisis comparativo, análisis de signos, avance progresivo (pensamiento lógico causal recursivo).
Después de procesar:
1) Concretar la percepción del usuario
1.1 Hora de ocurrencia: 1:30 de la mañana-04:00
1.2 Sistema de generación: sistema informático X
1.3 Descripción del evento: el tiempo de cálculo es 30 minutos más lento que el ciclo anterior, el volumen de datos no tiene cambios obvios y el código del programa es el más
No se han hecho cambios.
2) Recopilación de datos:
2.1 Informe AWR: Genere un informe de 01:00 a 04:00.
2.2 OSWATCH: Genera informes de 01:00 a 04:00
2.3 Recopilar registros de DB, OS, APP
3) Análisis de datos:
3.1 Métodos comunes para el análisis rápido de logotipos de procesamiento:
a) Verifique DBTIME, DBCPU, perfil de carga, TOP EVENT, TOP SQL de AWR
y
busque el evento principal de señal importante:
Tiempo de espera de eventos (s) Promedio de espera (ms)% de tiempo de base de datos Clase de espera CPU de base de datos
28,103 47,79 sincronización de archivo de registro 787 3,187 4049 5,42
Espacio de búfer de registro de compromiso 108 3,026 28022 5,15 Finalización de
cambio de archivo de registro de configuración 816904 1108 1,54 Cambio de
archivo de registro de configuración (punto de control) incompleta) 52767 14745 1,30 Configuración
b) El tiempo de espera promedio, el más largo es de 28 segundos, de los cuales la sincronización del archivo de registro es de 4 segundos, lo cual es muy importante y sospechoso.
En la actualidad, después de que el almacenamiento de nuestra base de datos adopta la memoria flash, el promedio de espera normal (ms) es dentro de 1ms. Incluso el tiempo de espera no se puede capturar.
<<<<<<<< Análisis comparativo
c) ¿Piensa en las circunstancias en las que ocurrirán estos eventos de espera? También hay un tiempo de espera promedio tan largo.
c-1: pensamiento convencional:
El tamaño del archivo de registro rehacer no es lo suficientemente grande >>> Confirmación adicional, se encuentra que el registro cambia 70 veces por hora >>> archivo de registro escritura en paralelo promedio esperar 1 ms
El búfer de registro no es lo suficientemente grande >>> El tamaño del registro de rehacer es de 22 m por segundo, y el búfer de registro actual es mucho menor que
Los 22m * 600,
(1) Comprometerse >>>> con frecuencia para verificar el código,
(2) IO se vuelve lento >>> marque la opción awr io stat, en la columna tablesace io stat, se encuentra que el sistema AVG BUFFER WAIT (ms) es 200 >> ¿Cuál es el motivo de la seria espera del sistema? , pero no hay otras >>>> Hay una gran cantidad de IO escritas en el SISTEMA, pero los datos muestran que solo hay más de 900 solicitudes de escritura, lo cual obviamente no es cierto. >>>>> el sistema está en el mismo grupo de discos que otros espacios de tabla, por qué solo el espacio del sistema está esperando tan obvio >> >> Dijo que obviamente no se debe a la lectura y escritura de otros espacios de tabla que causaron competencia IO. Entonces, ¿hay otros nodos? >>>> Verifique otros nodos al mismo tiempo y vea eventos de cansancio, pero después de comparar awrddrpt a través de la generación, se encuentra que no aparece SQL adicional >>> Entonces, ¿cuál es la razón? >>>> Otros análisis auxiliares de datos.
d) Al analizar el registro de la base de datos, no se encontró ningún error ORA obvio. Analizar el registro del sistema operativo (no tenían derecho a ver el registro del sistema operativo en ese momento y el análisis no estaba en su lugar). De hecho, puede ver un error de múltiples rutas aquí (o mirar el almacenamiento de los registros de software de múltiples rutas) . Más tarde, con la ayuda del administrador de almacenamiento, realmente encontré uno. El conmutador de fibra óptica está dañado. Cuando la base de datos envía una solicitud de E / S y el sistema la distribuye al conmutador dañado, la respuesta de E / S se ralentizará, porque el conmutador puerto está abierto, es decir, los datos no se pueden reenviar al almacenamiento. Cuando recibe los datos enviados por el sistema operativo y el reenvío falla dentro del tiempo especificado, utilizará otro reenvío, por lo que los datos en la base de datos están completos, pero el tiempo de respuesta general se ralentiza.
Hasta ahora, la verdad ha salido a la luz. . . De hecho, antes de que apareciera la verdad. . . . . He tomado muchos desvíos.
solución:
1. Hay dos conmutadores de fibra óptica de almacenamiento que utilizan sondeo para formar una arquitectura de alta disponibilidad. En la actualidad, solo uno está dañado y el otro es normal, por lo que el puerto del conmutador dañado está cerrado y el sistema operativo reenvía automáticamente la solicitud de E / S de la base de datos a la normal, en el conmutador, luego en el almacenamiento.
La prueba se verifica e implementa en producción.
- Notifique al fabricante que reemplace el hardware.
Suplemento: En este incidente, no tuve ninguna deficiencia. No verifiqué el sistema operativo ni la ruta de almacenamiento. Este fue un descuido importante. Espero tomar este incidente como una advertencia.