1. ESTABLECER ADVERTENCIAS Y ALERTAS DE UMBRALES CRITICOS
Reglas de umbral
Una regla de umbral
es una regla que se establece en un contador de rendimiento individual
para supervisar el uso de recursos del sistema durante una prueba de
carga. Las definiciones de conjuntos de contadores contienen reglas de
umbral predefinidas para muchos contadores de rendimiento clave.
Hay
dos tipos de umbrales: de advertencia y críticos. Un mensaje de alerta
le notifica si se infringe la regla de umbral. Al analizar la ejecución
de una prueba de carga, puede ver las infracciones de umbral.
Reglas y niveles de umbral
Al crear reglas de umbral en las pruebas de carga, hay que elegir entre dos tipos de reglas:
- Comparar con constante
- Compara un valor de contador de rendimiento con un valor constante.
- Comparar con contadores
- Compara un valor de contador de rendimiento con otro valor de contador de rendimiento.
Ejemplo:
Otro ejemplo:
Activar Notificaciones de Alertas: si desea
que el usuario SYSMAN (el superadministrador por defecto y propietario
del esquema del repositorio de gestión) reciba notificaciones de alerta
cuando una métrica para una condición especificada alcance un umbral
crítico o de advertencia. Si no se definen los parámetros de servidor
de correo saliente (SMTP) y dirección de correo electrónico, se podrán
definir o cambiar estos valores de notificación de alerta utilizando la
Consola de Enterprise Manager cuando termine la instalación.
2. RECOLECTAR Y USAR METRICAS DE REFERENCIA
Metricas de Negocio
Una métrica de negocio es cualquier tipo de instrumento de medición usado para calcular los componentes cuantificables del
rendimiento de una compañía, como el retorno de
la inversión, los ratios de rotación
de empleados y clientes,
el
beneficio
antes
de impuestos, etc.
Las métricas
de negocio constituyen gran
parte del área de business intelligence, que
comprende un alto número de aplicaciones y tecnologías
para
recoger, almacenar, analizar y proporcionar acceso a los datos para ayudar a las empresas
a realizar mejores
decisiones
de
negocio. Existen
aproximaciones sistemáticas como los cuadros de valoración que pueden ser empleados para transformar los objetivos de la organización dentro de objetivos cuantificables y así monitorizar el rendimiento
de la organización en términos de
la consecución de dichos objetivos.
A partir de la definición anterior y aplicada al entorno tecnológico del Servicio
Andaluz de Salud, se presentan las métricas que se aplicarán como
parámetros de entrada a las pruebas de carga que validan
un nuevo desarrollo o una nueva
funcionalidad de aplicación. Las métricas
de negocio tomadas como parámetros de entrada establecerán la tipología de
las pruebas de carga y serán los valores sobre los que se calculen los ratios resultantes al cruzarlos con las métricas de productos Oracle en los que se ejecutan las aplicaciones.
Oracle Soporte ha
establecido las siguientes métricas de negocio.
#user – valor numérico, define el número de usuarios con
los que se ejecutarán las
pruebas
de
carga.
%concurrencia_usuarios – valor numérico, define el porcentaje de
usuarios sobre el
número total de usuarios, que ejecutan
la lógica de las pruebas de carga de forma concurrente.
#iteraciones_casouso_i_transaccional – valor numérico, define el número de iteraciones que un Caso de Uso
transaccional es ejecutado por un usuario.
%ejecucion_casouso_i - valor numérico, es el porcentaje de ejecuciones del
caso de uso i sobre
el total de ejecuciones del resto de casos de uso de las pruebas de
carga
#registros_procesados_casouso_i_masivo
– valor numérico, define
el número de registros que un Caso de Uso masivo tiene que procesar correctamente durante las pruebas.
%concurrencia_casouso – valor numérico, dado
un caso de uso i, el porcentaje de concurrencia define el número de ejecuciones concurrentes de un caso de uso i sobre el total de ejecuciones de dicho caso de uso.
tiempo_in – valor
numérico, tiempo que
estarán ejecutándose las pruebas.
tiempo_out – valor numérico, tiempo empleado
en procesar los casos de uso establecidos en la definición de las pruebas.
ORACLE NET LISTENER
ORACLE DATABASE SINGLE INSTANCE
ORACLE REAL APPLICATION CLUSTER
ORACLE STREAMS
ORACLE DATAGUARD
ORACLE JVM JROCKIT Y WEBLOGIC SERVER
3. USAR EL OPTIMIZADOR Y HERRAMIENTAS DE DIAGNOSTICO
El Optimizador de Oracle
Oracle dispone de un
elemento, llamado optimizador, que planifica la ejecución de las
consultas a los datos. Es el elemento clave para que las consultas sean
eficientes.
Puede funcionar de dos maneras:
- Basado en reglas. En este caso, el proceso servidor elige el camino a los datos, examinando la SELECT, de acuerdo a un ranking definido mediante unas reglas internas. No se recomienda su uso, pues el plan de ejecución de la sentencia SQL no tiene en cuenta la distribución de los datos entre los bloques, y es habitual, por ejemplo, que se usen índices que están disponibles, pero que no devuelven la mayoría de las filas, ralentizando así las consultas. El diseñador del SQL ha de tener en cuenta este hecho y desactivar índices explícitamente o colocar las tablas en el orden adecuado en la cláusula WHERE, dependiendo de la distribución de los datos.
- Basado en coste. Es el modo recomendado. Consiste en que el optimizador examina cada sentencia e identifica todos los accesos posibles a los datos. Después, calcula el coste para cada camino y elige el de menor coste. El cálculo se hace basado en el número de lecturas lógicas y, para ello, se utilizan las estadísticas generadas para las tablas e índices.
- ALL_ROWS tiene en cuenta en tiempo de respuesta total.
- RULE es para que funcione en modo regla.
- FIRST_ROWS calcula los costes, minimizando el tiempo de respuesta inmediato.
Las estadísticas que usa el optimizador basado en costes se recopilan en dba_tables, dba_indexes, dba_tab_cols, etc., mediante los comandos ANALYZE TABLE/INDEX o con el procedimiento almacenado dbms_stats.gather_schema_stats.
Otros parámetros que afectan al optimizador:
- DB_FILE_MULTIBLOCK_READ_COUNT: Si tiene un valor alto, el optimizador basado en costes reconoce que las lecturas multibloque son más baratas en coste que las lecturas secuenciales, tendiendo a realizar full-scan sobre las tablas.
- PARALLEL_AUTOMATIC_TUNING: Si tiene el valor ON, paraleliza los full-scan.
- SORT_AREA_SIZE: Si tiene un valor alto, es más probable que el optimizador decida realizar una ordenación del conjunto resultado, en lugar de un acceso por índice.
- HASH_AREA_SIZE: Si tiene valor, el optimizador es más propenso a realizar hash-joins en vez de nested-loop o sort-merge.
Herramientas de diagnóstico
El sistema incluye herramientas de diagnóstico basadas en firmware y en software para facilitar la identificación y aislamiento de los problemas del hardware. Estas herramientas son:
-
Pruebas automáticas durante el encendido (POST)
-
Pruebas de diagnóstico de OpenBoot (OBDiag)
-
Software SunVTS
-
Software Sun Enterprise SyMON
Las pruebas de diagnóstico POST (Power-on
Self-test) verifican el funcionamiento de los componentes centrales del
sistema, lo que incluye la placa lógica principal, la memoria del
sistema y los dispositivos de E/S. Es posible ejecutar POST aunque el
sistema no pueda arrancar.
Las pruebas de OBDiag se centran en la E/S del sistema y en los
dispositivos periféricos. Al igual que POST, es posible ejecutar las
pruebas de diagnóstico de OpenBoot aunque el sistema no pueda arrancar.
SunVTS es una aplicación UNIX orientada a gráficos que permite
examinar continuamente los recursos del sistema, así como sus
dispositivos internos y externos.
El software Sun Enterprise SyMON basado
en UNIX permite supervisar el estado del hardware del sistema y el
rendimiento del sistema operativo del servidor.
El método o la herramienta utilizada para diagnosticar los problemas del sistema depende de la naturaleza de esos problemas:
-
Si la máquina no puede arrancar su sistema operativo, es preciso ejecutar las pruebas de POST y OBDiag.
-
Si la máquina es capaz de iniciar y cargar su sistema operativo,
pueden utilizarse las aplicaciones Sun Enterprise SyMON y SunVTS para
diagnosticar los problemas del sistema.
-
El esquema siguiente ofrece una idea
general de cuándo deben utilizarse las distintas herramientas de
diagnóstico para detectar problemas del hardware.
Automatic Database Diagnostic Monitor (ADDM)
The Automatic Database Diagnostic Monitor (ADDM) analiza los datos en
el repositorio de carga de trabajo automática (AWR) para identificar
posibles cuellos de botella de rendimiento. Para cada uno de los problemas identificados, localiza la causa raíz y proporciona recomendaciones para corregir el problema.
Una tarea de análisis ADDM se lleva a cabo y sus conclusiones y
recomendaciones almacenada en la base de datos cada vez que se toma una
instantánea de AWR proporciona el parámetro se establece en
STATISTICS_LEVEL TYPICAL o ALL. El análisis ADDM incluye:
- Carga de la CPU
- Uso de la memoria
- E / S de uso
- Uso intensivo de recursos de SQL
- Uso intensivo de recursos de PL / SQL y Java
- RAC Problemas
- Problemas de aplicación
- Problemas de base de datos de configuración
- Problemas de simultaneidad
- Objeto de contención
Los informes ADDM son mucho más sencillos de leer que los de RMA o
Statspack, por lo que un método útil para identificar gran cantidad de
recursos de SQL y PL / SQL.
Hay varias formas para producir informes de los análisis ADDM que se
explicará más adelante, pero todos siguen el mismo formato.
Los resultados (problemas) se enumeran en orden de potencial impacto en
el rendimiento de base de datos, junto con recomendaciones para
resolver el problema y los síntomas que conducen a su descubrimiento. Un hallazgo ejemplo se muestra a continuación.
Resultado 1: el impacto del 59% (944 segundos)
-----------------------------------
El buffer cache fue inferior a la causa de lectura adicional y significativa de I / O.
-----------------------------------
El buffer cache fue inferior a la causa de lectura adicional y significativa de I / O.
RECOMENDACIÓN 1: Configuración de base de datos, el beneficio del 59% (944 segundos)
ACCIÓN: Aumentar el tamaño de SGA de destino mediante el aumento del valor del parámetro "SGA_TARGET" antes del 28 M.
Síntomas que condujeron a la conclusión:
Espere la clase "Usuario de E / S" fue mucho tiempo la base de datos importante. (83%
impacto [1336]) segundo
Las recomendaciones para una conclusión en particular pueden incluir:
- Los cambios de hardware
- Cambios de base de datos de configuración
- Los cambios de esquema
- Cambios en las aplicaciones
- Uso de otros asesores
El análisis del rendimiento de E / S se ve afectado por el parámetro
dbio_expected que se debe establecer en el promedio de tiempo (en
microsegundos) que tarda en leer un bloque de base de datos única del
disco con los valores típicos van desde 5000 a 20000 microsegundos.
EXECUTE DBMS_ADVISOR.set_default_task_parameter ('ADDM', 'DBIO_EXPECTED', 8000);
En dbconsole Enterprise Manager, el "Análisis de rendimiento" en la
página "Home" es una lista de los cinco mejores resultados de la tarea
ADDM último análisis. Los informes específicos se pueden producir haciendo clic en el "Asesor de Centroamérica", luego en el vínculo "ADDM".
La página resultante permite la selección de una imagen de inicio y
fin, la creación de una tarea ADDM y la pantalla del informe resultante
haciendo clic en algunos enlaces.
Por otra parte, un informe de ADDM puede ser generada a partir de SQL *
Plus mediante el script addmrpt.sql situado en el $ ORACLE_HOME / RDBMS
/ admin.
Cuando se ejecuta, el script muestra todas las instantáneas disponibles
y pide al usuario que introduzca el principio y la instantánea final
junto con el nombre del informe.
También es posible crear y ejecutar tareas ADDM asesor utilizando el paquete dbms_advisor, como se muestra a continuación.
COMENZAR
- Crear una tarea ADDM.
DBMS_ADVISOR.create_task (
advisor_name => 'ADDM',
nombre_tarea => '970_1032_AWR_SNAPSHOT ',
TASK_DESC => 'Asesor para las instantáneas de 970 a 1032.');
- Crear una tarea ADDM.
DBMS_ADVISOR.create_task (
advisor_name => 'ADDM',
nombre_tarea => '970_1032_AWR_SNAPSHOT ',
TASK_DESC => 'Asesor para las instantáneas de 970 a 1032.');
- Establecer el inicio y el final instantáneas.
DBMS_ADVISOR.set_task_parameter (
nombre_tarea => '970_1032_AWR_SNAPSHOT ',
parámetro => 'START_SNAPSHOT',
= valor> 970);
DBMS_ADVISOR.set_task_parameter (
nombre_tarea => '970_1032_AWR_SNAPSHOT ',
parámetro => 'START_SNAPSHOT',
= valor> 970);
DBMS_ADVISOR.set_task_parameter (
nombre_tarea => '970_1032_AWR_SNAPSHOT ',
parámetro => 'END_SNAPSHOT',
valor => 1032);
nombre_tarea => '970_1032_AWR_SNAPSHOT ',
parámetro => 'END_SNAPSHOT',
valor => 1032);
- Ejecutar la tarea.
DBMS_ADVISOR.execute_task (nombre_tarea => '970_1032_AWR_SNAPSHOT ');
END;
/
END;
/
- Mostrar el informe.
SET DE LARGO 100000
SET PAGESIZE 50000
SELECT DBMS_ADVISOR.get_task_report ('970_1032_AWR_SNAPSHOT ') Según el informe de
De la doble;
SET PAGESIZE 24
El valor para el comando SET largo debe ser ajustada para permitir que todo el informe que se mostrará.
SET DE LARGO 100000
SET PAGESIZE 50000
SELECT DBMS_ADVISOR.get_task_report ('970_1032_AWR_SNAPSHOT ') Según el informe de
De la doble;
SET PAGESIZE 24
El valor para el comando SET largo debe ser ajustada para permitir que todo el informe que se mostrará.
Los siguientes puntos de vista se puede utilizar para mostrar la salida
de ADDM sin necesidad de utilizar Enterprise Manager o la función
get_task_report:
- dba_hist_snapshot - Muestra una lista de todas las instantáneas válidos.
- dba_advisor_tasks - Información básica sobre las tareas existentes.
- dba_advisor_log - La información de estado acerca de las tareas existentes.
- dba_advisor_findings dictámenes identificados para una tarea existente.
- dba_advisor_recommendations - Recomendaciones para los problemas identificados por una tarea existente.
La sección de nido a explicar cómo el Administrador corporativo se refiere a las secciones anteriores.
Al utilizar Oracle Enterprise Manager
En las últimas versiones de la base de datos, Oracle ha llevado a
Oracle Enterprise Manager (OEM) como la herramienta principal de
administración de la base de datos.
Dependiendo de la versión utilizada, ya sea de consola que proporciona
una interfaz gráfica de usuario Java o HTML basado en navegador que
permite el acceso simplificado a una serie de las características
descritas anteriormente.
No me parece mal Enterprise Manager, pero no ocultar algunos detalles de los mecanismos subyacentes. Yo prefiero entender la tecnología, en lugar de estar protegidos de ella.
En
lugar de lanzarse a una larga discusión sobre las características que
son compatibles con cada versión de OEM, me limitaré a decir que si
usted entiende que el material se discutió anteriormente, el uso de OEM
para acceder a las funciones será sencillo e intuitivo.
5. ADMINISTRAR EL REPOSITORIO DE CARGA AUTOMATICA DE TRABAJO
Tiene las funciones de recopilar, procesar y mantener estadisticas y metricas de la base de datos.
AWR se forma a base de Snapshot o capturas de determinados datos de la base de datos. Considerarmos una BASELINE como un conjunto de snapshots que
representan un determiando estado de la base de datos. Se utilizaran
para comparar con estados futuros de la base de datos.
Características de AWR
AWR se utiliza para recopilar las estadísticas de rendimiento, incluyendo:
AWR se utiliza para recopilar las estadísticas de rendimiento, incluyendo:
- Eventos de espera problemas de performance.
- Estadísticas que indican la cantidad de tiempo de la base de datos asociado a un proceso.
- Historia de sesión activa (ASH).
- Estadísticas de sesión
- Estadísticas de uso de objetos.
- Uso intensivo de recursos SQL.
Los datos almacenados en AWR se encuentran es estructuras de memoria llamadas fixed tables.Existen dos tipos de estadisticas:
a) Performance Stadistics
b) Optimized Stadistics.
b) Optimized Stadistics.
PERFORMANCE STADISTICS
Nos muestran el funcionamiento de la Base de Datos a lo largo del
tiempo. Analizando estas estadisticas veremos una posible degradacion
del funcionamiento de la base de datos.
Categorias:
a) Cumulative values: Estadisticas que se actualizan constantemente.
b) Metrics: Muestran rangos de variacion.
c) Sampled: Muestran el estado de todas las sesiones activas.
AWR almacena estadisticas de diferentes tipos:
a) Tiempo
b) Sistema operativo
c) Tiempo de Espera.
b) Sistema operativo
c) Tiempo de Espera.
Workload Repository pertenece a SYS y se almacena en SYSAUX.
Para habilitar AWR tenemos que configurar el parametro
STATISTICS_LEVEL a alguno de estos valores TYPICAL(por defecto)|ALL. En
BASIC,AWR no funciona de forma automatica.
sql> ALTER SYSTEM SET STATISTICS_LEVEL=TYPICAL SCOPE=BOTH
El espacio que ocupara AWR dependera del numero de sesiones que
tengamos activas, de SNAPSHOT INTERVAL y RETENTION PERIOD. Sera MMON el
encargado de liberar espacio.
ASH buffer es una pila FIFO de la que MMON estrae estadisticas para
alimentar AWR. ASH es una estructura de memoria que se encuentra en la
Shared Pool ocupando un espacio que sera el numero de procesadores por
2M o el 5% de la Shared Pool. Cojeremos el menor. MMON se encargara de
vaciar este buffer cada 30 min si ASM se llena cada menos sera MMNL el
que se encarge de liberar parte.
