OPTIMIZACIÓN DEL RENDIMIENTO

1. OPTIMIZACIÓN DEL RENDIMIENTO

2. OBJETIVOS DEL RENDIMIENTO • El objetivo de ajustar rendimiento consisten en proporcionar un tiempo de respuesta aceptable en las consultas al minimizar : • Tráfico de red. • Operaciones de E/S • Tiempo del CPU. • Se debe entender la estructura física y lógica . • Analizar los usos conflictivos de la BD.

3. Tiempo de Respuesta (Tiempo que demora el usuario en recibir datos). • MAXIMIZAR RENDIMIENTO PARA TODOS LOS PROCESOS DE LOS USUARIOS. • Equilibrar recursos entre los usuarios. • RENDIMIENTO=Nro consultas que puede consultar el Servidor • Depende de Arquitectura Hardware Software, carga

4. FACTORES QUE AFECTAN EL RENDIMIENTO • Recursos del sistema (Memoria, Procesador, Disco Duro, Red, etc.) • Sistema Operativo. • Gestor de Base de Datos. • Aplicación de BD. • Aplicación Cliente. • Tráfico en la red.

5. FACTORES DEL SISTEMA OPERATIVO • Subprocesos. • Archivos de paginación (memoria virtual). • Servicios. • Administración de Discos. • Actividades simultaneas.

6. SISTEMA DE GESTION DE BASE DE DATOS • Configuración. • Bloqueos (disputa por recursos de la BD, tablas, páginas individuales) en entornos multiusuarios. • Registro. • Actividades de auditoría, registro de transacciones. • Actividades simultáneas (backups, restauraciones,etc.)

7. APLICACIONES DE LA BD • Diseño Lógico y Físico. • Nivel de normalización y desnormalización. • Índices. • Evitar interbloqueos. • Control de transacciones. • Las transacciones, bloqueos e interbloqueos. • Consultas. • Forma de escribir las consultas.

8. INTERBLOQUEOS • La transacción A tiene un bloqueo compartido de la fila 1. • La transacción B tiene un bloqueo compartido de la fila 2. • La transacción A ahora solicita un bloqueo exclusivo de la fila 2 y se bloquea hasta que la transacción B finalice y libere el bloqueo compartido que tiene de la fila 2. • La transacción B ahora solicita un bloqueo exclusivo de la fila 1 y se bloquea hasta que la transacción A finalice y libere el bloqueo compartido que tiene de la fila 1.

9. OPTIMIZAR CONSULTAS • Tablas de “suministradores” (S) y “pedidos”(P) con 100. • suministradores y 10.000 pedidos. • Consideraremos que sólo 50 tuplas de P corresponden al artículo P2 (se hace pedido por artículo). • Consulta: “Obtener los nombres de los suministradores que nos sirven el artículo P2”.

10. OPTIMIZAR CONSULTAS • El producto cartesiano S x P 100 x 10.000 = 1.000.000 de tuplas leídas y almacenadas en memoria intermedia (probablemente). • De la igualdad de join. • 1.000.000 leídas y 10.000 tuplas escritas en memoria intermedia. • Selección según la cláusula WHERE, 10.000 tuplas leídas, resultado reducido a 50 tuplas.

11. APLICACIÓN CLIENTE - Requisitos del Cliente. requisitos para ejecutar consultas y modificar datos. - Tratamiento de Interbloqueos. • Control de Transacciones. • Cursores. (Un cursor se utiliza para el procesamiento individual de las filas devueltas por el sistema gestor de base de datos para una consulta. Es necesario debido a que muchos lenguajes de programación sufren de lo que en inglés se conoce como impedancemismatch)

12. PASOS A REALIZAR • Agregar más hardware. • Ajustar SGBD. • Ajustar la B.D.(diseño lógico físico, índices, consultas, etc.) • Resolver problemas de continuidad. • Ajustar el cliente. • Desarrollar procedimientos almacenados. • Supervisar rendimiento. • Evaluar desnormalización.

13. EXPLAIN MYSQL • EXPLAINSELECT*FROM`localidades`WHERE id =1 • type: Esta columna indica el tipo de unión que se está usando (de más a menos óptimo). • Donde SIMPLE (Es cuando no se usan Uniones o SubConsultas) • Donde UNION (Es cuando usamos la clausula UNION en 2 tablas) • Donde SubQUERY ( Es cuando usamos Subconsultas) • 2. const: Es la más óptima y se dá cuando la tabla tiene como máximo una fila que coincide. Como solo hay una fila coincidente, MySQL la considerará como constante por el optimizador. • 3. eq_ref: Una fila será leída de la tabla A por cada combinación de fila de la tabla B. Este tipo es usada cuando todas las partes de un índice son usados para la consulta y el índice es UNIQUE o PRIMARY • 4. ref: Todas las filas con valores en el índice que coincidan serán leídos desde esta tabla por cada combinación de filas de las tablas previas. Si la clave que es usada coincide sólo con pocas filas, esta unión es buena.

14. 5. range: Sólo serán recuperadas las filas que estén en un rango dado, usando un índice para seleccionar las filas. La columna key indica que índice se usará, y el valor key_len contiene la parte más grande de la clave que fue usada. La columna ref será NULL para este tipo. • 6. index: Este es el mismo que ALL, excepto que sólo el índice es escaneado. Este es usualmente más rápido que ALL, ya que el índice es usualmente de menor tamaño que la tabla completa. • 7. ALL: Realiza un escaneo completo de tabla por cada combinación de filas de las tablas previas. Este caso es el peor de todos. • 8. possible_keys: Esta columna indica los posibles índices a utilizar en la consulta • 9. key: Esta columna indica el indice que MySQL actualmente está usando. Esta columna es NULL si no se ha elegido ninguno. Es interesante saber que podemos forzar a MySQL a usarlo (y también a ignorarlo) mediante el uso de FORCE INDEX, USE INDEX o IGNORE INDEX • 10. key_len: El tamaño del índice usado. A menor valor mejor. • 11. ref: La columna ref muestra que columna o constante es usada junto a la key para seleccionar las columnas de la tabla • 12. rows: Indica el número de columnas que MySQL cree necesario examinar para ejecutar la SQL. • 13. extra: Indica información adicional de como MySQL ha resuelto la SQL y hay que prestar atención si aparece USING FILESORT o USING TEMPORARY. En el primer caso, indica que MySQL debe hacer un paso extra para recuperar la información. En el segundo, MySQL necesita generar una tabla extra para mantener la información y después mostrarla y es típico al usar GROUP BY u ORDER BY.

15. EXPLAIN PLAN ORACLE • SINTAXIS GENERAL. • EXPLAIN PLAN [SET STATEMENT_ID = 'text'] FOR sentencia; • EXPLAIN PLAN [SET STATEMENT_ID = 'text'] INTO [esquema.]tabla@dblink FOR sentencia; • Si no definimos nuestra propia tabla se usa la tabla PLAN_TABLE. • Ejemplo: • DELETE PLAN_TABLE; • EXPLAIN PLAN FOR SELECT * FROM T_PEDIDOS WHERE CODPEDIDO = 5; • Para ver el resultado: • SELECTSUBSTR (LPAD(' ', LEVEL-1) || OPERATION || ' (' || OPTIONS || ')',1,30 ) "OPERACION", OBJECT_NAME "OBJETO" FROM PLAN_TABLE START WITH ID = 0 CONNECT BY PRIOR ID=PARENT_ID; FULL TABLE SCAN

16. CREATE TABLE PLAN_TABLE ( STATEMENT_ID VARCHAR2 (30), TIMESTAMP DATE, REMARKS VARCHAR2 (80), OPERATION VARCHAR2 (30), OPTIONS VARCHAR2(30), OBJECT_NODE VARCHAR2(128), OBJECT_OWNER VARCHAR2 (30), OBJECT_NAME VARCHAR2 (30), OBJECT_INSTANCE INTEGER, OBJECT_TYPE VARCHAR2 (30), OPTIMIZER VARCHAR2 (255), SEARCH_COLUMNS INTEGER, ID INTEGER, PARENT_ID INTEGER, POSITION INTEGER, COST INTEGER, CARDINALITY INTEGER, BYTES INTEGER, OTHER_TAG VARCHAR2 (255), OTHER LONG);

17. Referencias • http://www.microsoft.com/latam/technet/articulos/200005/art02/ • http://ora.u440.com/dba/explain%20plan.html