Condiciones de falla
El AWR informa lo siguiente:
Después de que detuvieran la mayor parte del negocio, los eventos de espera de sincronización de archivos de registro seguían siendo muy altos.
Al comparar el AWR a la misma hora ayer y hoy, el tiempo de espera sigue siendo muy alto cuando el volumen de negocios es muy pequeño.
proceso de diagnóstico
El evento de espera de sincronización del archivo de registro primero juzga si hay un problema con la E/S del sistema actual, verifica el registro del sistema operativo en busca de errores relacionados, ejecuta la prueba de E/S y también muestra que la E/S está en un estado normal y verifica el AWR. informe en detalle AWR muestra que la base de datos escribe IO y IO de lectura son relativamente buenos normales. Al comparar el informe AWR de ayer con el informe AWR de hoy, se puede ver que el rendimiento de lectura y escritura de IO no es muy diferente al de ayer. El período de tiempo recopilado hoy se debe a la suspensión de la mayor parte del negocio. El IO es mejor que ayer, pero la espera para el cambio de registro En cambio, el tiempo aumentará en 8 segundos.
De acuerdo con el flujo de sincronización de archivos de registro de Commit en el manual de diagnóstico "Sincronización de archivos de registro, LGWR" escrito por Tanel Poder senior
En la figura anterior, podemos ver claramente todo el proceso de confirmación.
1. Cuando el usuario inicia una confirmación;
2. El proceso front-end (es decir, el proceso del Servidor) enviará un mensaje al proceso lgwr, diciéndole que escriba el búfer de rehacer.
3. Cuando se instruye al proceso LGWR, comienza a llamar a la función del sistema operativo para realizar la escritura física.Durante el período de escritura física, habrá un archivo de registro en espera de escritura paralela.
4. Cuando LGWR complete la operación de escritura, el proceso LGWR devolverá un mensaje al proceso front-end (proceso del servidor), diciéndole que he terminado de escribir y que puede completar el envío.
5. El usuario completa la operación de confirmación.
Del diagrama de flujo anterior, combinado con el breve tiempo de espera de la escritura paralela del archivo de registro, la E/S del usuario y la E/S del sistema en AWR, podemos juzgar que el problema no radica en el rendimiento de la E/S. Entonces el problema debería estar en la etapa 2 y la etapa 5.
Según el artículo de mos:
《Solución de problemas: 'Sincronización de archivos de registro' espera (ID de documento 1376916.1) 》
《Optimización de sincronización de archivos de registro adaptable (ID de documento 1541136.1) 》
《El cambio adaptativo entre métodos de escritura de registros puede causar esperas de 'sincronización de archivos de registro' (Doc ID 1462942.1) 》
Después de descubrir Oracle11g, Oracle introdujo un nuevo método de sincronización de registros, llamado método adaptativo, que se habilita después de la versión 11.2.0.3 de Oracle.
Inicialmente, LGWR usa post/wait y, de acuerdo con un algoritmo interno, evalúa si el sondeo es mejor. En condiciones de alta carga del sistema, el sondeo puede funcionar mejor porque la implementación de post/espera normalmente no escala bien. Si la carga del sistema es baja, la publicación/espera funciona bien y proporciona mejores tiempos de respuesta que el sondeo. Oracle se basa en estadísticas internas para determinar qué método se debe utilizar. Debido a que el cambio entre post/espera y sondeo incurre en una sobrecarga, se implementan medidas de seguridad para garantizar que los cambios no ocurran con demasiada frecuencia.
De acuerdo con la descripción en el documento, verifiqué la carga del sistema y descubrí que el sistema comercial estaba bajo una carga alta a las 14 en punto de hoy, y el cambio de registro alcanzó 136 veces, después de lo cual el negocio volvió a la normalidad.
Verifique el sistema actual y descubra que el sistema actual LGWR está utilizando el método de sondeo.
SQL> seleccionar nombre, valor de v$sysstat donde nombre en ('rehacer escrituras de sincronización de encuestas', 'rehacer encuestas de sincronización');
la encuesta de sincronización de rehacer escribe 6248
rehacer sincronizar encuestas 8843
Análisis de causa de falla
Dado que la carga del sistema comercial se vuelve muy alta a las 14 en punto, Oracle cambia el modo de escritura LGWR al modo de sondeo para mantener un mayor rendimiento, pero cuando la carga comercial cae, en circunstancias normales, LGWR debería volver a la publicación original. método de espera , pero esta vez no hay cambio, y se ha utilizado el método de sondeo . Se considera que hay un error y no hay cambio, lo que conduce a un rendimiento deficiente ( el intervalo de sondeo en los artículos en línea es de 10 ms, y el intervalo de Publicación/espera es de 1 ~ 2 ms. No puedo encontrar artículos en mos que han escrito esta vez)
Errores relacionados:
En la versión 11.2.03, se puede aplicar la ACTUALIZACIÓN 11.2.0.3.14 DEL PARCHE DE BASE DE DATOS (INCLUYE CPUAPR2015) para resolver este ERROR.
solución
Solución alterna
Deshabilite la sincronización adaptativa de archivos de registro configurando "_use_adaptive_log_file_sync"=false
ALTER SYSTEM SET "_use_adaptive_log_file_sync"=FALSO;
O reiniciar la instancia también puede solucionarlo.