VB, accede a la programación
1. Se ralentiza gradualmente
2. Se ralentiza repentinamente
3. No se ralentiza a tiempo
En el primer caso, "de desaceleración gradual", debe establecerse un mecanismo de seguimiento a largo plazo. Por ejemplo, escriba un script de shell para recopilar información del sistema operativo, la red y la base de datos durante los períodos de mayor actividad todos los días (normalmente
9~10
etc.), y
Analizar la información recopilada y emitir informes cada semana. La acumulación de estos datos puede determinar decisiones de optimización posteriores y también puede convertirse en datos importantes para que los DBA persuadan a los gerentes a adoptar sus propias decisiones.
El valor de un DBA se refleja en los informes semanales.
La segunda situación
"Desaceleración repentina" también es la más fácil de solucionar. Primero, debemos examinar si el uso de la base de datos es diferente desde una perspectiva comercial y luego emitir más juicios. Las fallas de hardware/red a menudo causan una degradación repentina en el rendimiento de la base de datos.
Paso 1: Verifique el registro del sistema DB/OS/NETWORK para eliminar problemas de hardware/red
Paso 2: Verifique los eventos de espera de la base de datos y determine las posibles áreas problemáticas en función de la espera eventos. Si no hay tiempo de espera,
entonces puedes descartar problemas en la base de datos. Si hay un tiempo de espera,
basado en diferentes eventos de espera, encuentre la causa raíz de estos eventos.
Por ejemplo, si hay tiempos de espera relacionados con el análisis de SQL, como la liberación de pestillos, el sistema operativo verá un mayor uso de la CPU.
Si hay tiempos de espera relacionados con las lecturas de disco SQL , Tiempo de espera, como lectura dispersa de archivos db, el sistema operativo verá un aumento en el volumen de lectura y escritura del disco en iostat<
Paso 3: Verifique la CPU/IO/MEMORIA y otra información del Sistema operativo.
Este es el primer paso del proceso.
a. Uso de CPU
El uso de CPU no es inversamente proporcional al rendimiento de la base de datos. El uso elevado de CPU no significa un rendimiento lento de la base de datos. Normalmente, una base de datos
bien optimizada con una gran carga de trabajo
tendrá un uso elevado de CPU, que se distribuirá uniformemente a cada proceso. Por otro lado, un uso elevado de CPU no significa
que la base de datos esté funcionando bien,
por lo que debes observar los eventos de espera de tu base de datos para determinar si el uso elevado de CPU es razonable. .
Si un proceso tiene un alto uso de CPU, debe haber un problema con ese proceso. Si no es un proceso de Oracle, puede preguntarle a la aplicación si hay bucles o errores en el programa.
Si se trata de un proceso de Oracle, puede buscar el diccionario de datos de Oracle mediante pid para ver el iniciador del proceso, la instrucción
sql que se está ejecutando y los eventos que se están esperando. para. Luego,
puedes utilizar diferentes métodos para diferentes situaciones.
b. IO
Después de solucionar problemas de IO de hardware, la desaceleración repentina de la base de datos generalmente es causada por una o varias declaraciones SQL.
Si IO es muy frecuente, se puede solucionar optimizando TOP SQL para lecturas de disco elevadas. Esta es la forma más estúpida y eficaz de resolver problemas de IO.
El sistema operativo y la configuración de almacenamiento también tienen un impacto en IO.
Por ejemplo, el problema más común con IO asíncrono en HP-unix es que ORACLE no usará AIO si el grupo DBA no tiene permisos MLOCK
.
Esta configuración puede pasarse por alto fácilmente si el sistema operativo y los administradores de la base de datos no están bien coordinados.
c.Memoria
El segundo caso poco tiene que ver con la memoria siempre y cuando el área SGA esté correctamente configurada y no haya sido modificada, en términos generales, siempre y cuando sí lo haga. no existe
pérdidas de memoria de la aplicación,
no provocará ralentizaciones repentinas.
La tercera situación, la “desaceleración irregular”, es el problema más difícil de resolver. Hay muchas razones para este problema, lo más importante es capturar la mayor cantidad de información posible para analizar el problema lo antes posible cuando ocurra. Lo mejor de todo es que cuando se producen ralentizaciones,
podemos obtener la mayor cantidad de información para analizarla lo más rápido posible.
Ejemplo
Ralentización repentina de la base de datos
Antecedentes:
Paso 1: Investigar la nueva aplicación
Desarrolladores de datos afirma que la nueva aplicación accede a tablas recién creadas, tablas con volúmenes de datos más pequeños y no hay datos disponibles en la base de datos.
Según los desarrolladores, la nueva aplicación accede a tablas recién creadas con una pequeña cantidad de datos y sin consultas SQL complejas.
Consulta v$sqlarea ordenada por disk_reads / buffer_gets / ejecuciones, TOP SQL
No se aplica ningún SQL nuevo. Solucionar problemas de nuevas aplicaciones que acceden a bases de datos causados por problemas de rendimiento.
El segundo paso es ver el registro de la base de datos/registro del sistema operativo.
En el registro de la base de datos, puede ver una gran cantidad de errores ORA-7445, así como una gran cantidad de archivos de volcado. Analice el archivo de volcado (ha pasado mucho tiempo, pero no hay
archivo de volcado al que consultar,
no se pueden describir los detalles específicos.
Después de analizar el archivo de volcado (no
El archivo de volcado está disponible como referencia, pero los detalles específicos no se pueden describir.
No hay ningún mensaje de error en el registro del sistema operativo
El tercer paso es ver el informe del paquete de estadísticas
Desde Como puede ver en los eventos de espera, el evento superior es "búfer ocupado en espera"
"archivo db paralelo write"
El primer paso es ver el informe del paquete de estado "escritura paralela del archivo db."
Estos son eventos de espera relacionados con IO.
A juzgar por el búfer estadísticas de espera ocupada, parece estar esperando un bloque de datos.
También hay algunas lecturas físicas y otra información que no es muy diferente a la anterior.
No hay anomalías en. lectura/escritura de IO en el espacio de tabla, pero el tiempo de espera ha aumentado significativamente
El juicio inicial es ese
Paso 4, verifique la información del sistema operativo
<. p> 1. comando superior (la salida son datos de laboratorio, solo para referencia de formato)Valores promedio de carga: 0.05, 0.10, 0.09 10:18:32
307 procesos: 304 los procesos están inactivos, 1 proceso es zombie, 1 proceso está detenido, 1 proceso está ejecutando la CPU
Estado de la CPU: 96,0 % inactivo, 0,3 % usuarios, 2,6 % kernel, 1,1 % iowait, 0,0 % swap
Memoria: 4096M de memoria real, 2660M de memoria libre, swap en uso Memoria 1396M
Memoria: 4096M reales, 2660M libres, 3013M de swap en uso
Esta es la primera vez que he visto la CPU en uso.
3013M sin intercambio
NOMBRE DE USUARIO PID THR PRI NICE TAMAÑO RES ESTADO HORA COMANDO DE CPU
11928 a21562 1 0 0 3008K 2496K cpu/1 0:02 1,12% superior
14965 mpgj76 4 59 0 10M 3696K dormir 3:09 0.18% view_server
Los datos en tiempo real en ese momento mostraron que el valor de iowait era mucho mayor que antes y no hubo ningún proceso anormal
2. sar -d (La salida son datos de laboratorio, el formato es solo de referencia)
SunOS sc19 5.7 Generic_106541-42 sun4u 20/03/08
00 :00:00 dispositivo %ocupado avque r+w/ s blks/s avwait avserv
sd410 17 0.4 50 1628 0.1 7.1
sd410,a 0 0.0 0 0.0 0.0
sd410,b 0 0.0 0 0.0 0.0
sd410,c 0 0.0 0 0.0 0.0
sd410,g 17 0.4 50 1628 0.1 7.1
Los datos en tiempo real se muestran en ese momento, el dispositivo donde se colocó el archivo de datos Los valores de avwait, avque y blks/s son todos muy grandes
El quinto paso es verificar la espera eventos de la base de datos
Si el rendimiento de una base de datos empresarial grande no es bueno, generalmente habrá muchos eventos en espera, generalmente cientos de eventos en espera son muy comunes. Seleccione recuento (*), evento de v$session_wait donde el evento no está en ('smon
timer','pmon timer','rdbms ipc message','SQL*Net message from client')
agrupar por orden de eventos por 1 desc;
El resultado muestra que el evento más esperado es la espera de búfer ocupado.
Hacer más análisis para conocer el motivo de la espera.
Seleccione recuento (*), p1, p2, p3 de v$ session_wait donde evento = 'búfer ocupado
espera' agrupar por p1, p2, p3
<; p> en buffer ocupado espera evento de esperaP1 = file#
P2 = block#
P3 = id (este id corresponde al motivo de la espera)
Agrupar con p1, p2, p3 es para determinar en qué objetos se concentra la espera ocupada del búfer.
Metalink describe el evento de espera para la espera de búfer ocupado en el siguiente párrafo:
"Si P3 muestra "espera de búfer ocupado" esperando la lectura del bloque
Completado, entonces lo más probable es que la sesión de bloqueo esté esperando la espera de IO
(por ejemplo: "lectura secuencial de archivo db" o "lectura dispersa de archivo db", para el mismo
número de archivo y bloque #.
El resultado muestra que la espera se distribuye en varios objetos diferentes, el motivo de la espera es "esperar a que se complete la lectura del bloque" y un análisis más detallado es un problema de IO.
Por ejemplo, si la espera ocupada del búfer se concentra en un determinado objeto, esto significa que hay un bloque activo.
Puede aumentar la lista libre y el entorno RAC reconstruyendo el objeto. aumentar el grupo de lista libre para solucionar este problema.
Puede encontrar el motivo específico a través del siguiente comando SQL:
Seleccione propietario, nombre_segmento, tipo_segmento de dba_extents donde file_id=P1
y P2 entre block_id y block_id +blocks;
P1, P2 son los valores específicos verificados por v$session_wait arriba
Paso 6, descubra la causa y los pasos para resolver el problema
Análisis:
1. El tráfico IO al disco aumenta
2. El IO en espera al disco aumenta
3. El tráfico IO a la base de datos no aumenta
4. IO de la base de datos esperando aumentar
Se puede deducir de 1, 2, 3 y 4 que además del acceso de la base de datos al disco, existen otros IO.
Desde la perspectiva de la configuración del disco, VG solo almacena archivos de datos de la base de datos y archivos del sistema de la base de datos. Además de los archivos de datos, la E/S se genera mediante archivos
del sistema de bases de datos.
Los archivos del sistema de bases de datos generalmente no generan IO. Los únicos lugares donde se produce la lectura y escritura de IO son los archivos de registro y los archivos de volcado.
Conclusión: ora-7445 genera una gran cantidad de archivos de volcado de núcleo, bloqueando IO
Solución:
1. Eliminar ora-7445. (La aplicación no se puede resolver sin cambiar el caso)
2. El directorio de volcado apunta a otros VG
3. Deje que Oracle escriba la menor cantidad posible de archivos de volcado de núcleo
background_core_dump = parcial
shadow_core_dump = parcial
4.