Bases de Datos Oracle Optimización oscarlin@dc.uba.ar

Temarios: 1- Uso eficiente de discos 2- Memoria SGA 3- Uso de índices 4- Oracle Optimizer 5- Hints 6- Compresión de tablas 7- Sorting

Uso eficiente de discos Separar Redo logs de datos. Deben estar aislados en sus propios dispositivos y controladores. Redo logs en dispositivos más rápidos. Por ej. nivel 0 o 1 en un raid de discos y datos en el nivel 5. Separar tablas de índices. Partición de tablas e índices. Balanceo de carga. Tablespaces temporales: Evitar extensiones desiguales. Múltiplo del tamaño de bloque. Esquema para reorganización de datos. Analizar periódicamente los objetos de BD. Permite actualizar las estadísticas.

Uso eficiente de discos (cont.) RollBack Segments. Deben ubicar estos segmentos en diferentes discos. En caso que la contención supera a 1% o 2% de waits/gets, crear más segmentos. sort_area_size Si se realiza muy frecuente los sort en discos, se debe incrementar sort_area_size de memoria de PGA o SGA en el ini.ora. Modificación Dinámica.

Memoria SGA Insuficiencia de Memoria SGA: Degrada enormemente el performance. Modificación Dinámica. Sobredimensionamiento de SGA: Utilización de memoria virtual (UNIX) también afectaría la performance. Uso de Shared Pool: Memoria disponible, reparseo, contención, fragmentación, pinning. Contención de buffer de datos o buffer de Redo Log. DBWR muy lento o LGWR mu lento. Agregar más instancias.

Uso de índices Mantenimiento de índices Index Skip Scan (9i). Cuándo se necesitan realizar Rebuilt (Reconstrucción) o Coalesce (unión): mucho niveles, muchos bloques hojas borrados lógicamente. Muchos valores repetidos: usar bitmapped index. Index Skip Scan (9i). Creación de subíndices en índices compuestos. Funciona en CBO. Bitmap based index. Function based index. Funciones desactiva el uso de índices. “Not” desactiva el uso de índices

Oracle Optimizer RBO (Optimizador basado en reglas) Reglas prefijadas para armar plan de ejecución. No soporta bitmap indexes, table partitions y function based indexes. CBO (Optimizador basado en costos) Calcular el costo de distintos plan de ejecución y elije el de menor costo. ANALYZE [TABLE, INDEX] <object_name> [COMPUTE,ESTIMATE] STATISTICS. Parámetros: FIRST_ROWS, ALL_ROWS y otros parámetros que puedan influir en la decisión de optimizador en usar índices, full scan, hash joins, sort, etc. Uso de hints para cambiar plan de ejecución. Ultimo recurso. Inválidos: ej /*+ first_rows parallel(emp,8) */.

Oracle Optimizer (cont.) Problema más común: Full-table scan para tablas muy grandes. Solución: agregar índice. Por falta de información, no elije el mejor método de join. Solución: usar hints tales como use_nl, use_hash, etc. o reanalizar las estatísticas de las tablas intervinientes. Métodos de joins disponibles: sort-merge join, nested loop join, hash join, star join, etc. Guardar tablas pequeñas e índices en buffer cache.

Hints /*+ CHOOSE */ /*+ RULE */ /*+ ALL ROWS */ /*+ FIRST ROWS */ Optimización por costos. /*+ RULE */ Optimización por reglas /*+ ALL ROWS */ Optimización por costos y trate de devolver todas las filas en menor tiempo. /*+ FIRST ROWS */ Optimización por costos y trate de devolver la primera fila lo antes posible. /*+ INDEX(tabla o índice) */ Fuerza la utilización de índice. /*+ ORDERED */ Indica que los joins se debe hacer respetando el orden de las tablas.

Hints (cont.) /*+ FULL */ /*+ PARALLEL */ Realiza un full-table scan. /*+ PARALLEL */ Sugiere una consulta paralela. /*+ USE_HASH(tablaA,tablaB) */ Sugiere usar hash join. /*+ USE_NL(tabla) */ Sugiere usar nested loop join. /*+ USE_MERGE(tabla … ) */ Sugiere usar sort-megre join.

Compresión de tablas Disponible a partir de 9i, release 2. Reduce el espacio de almacenamiento, también backup. create table … compress; alter table xxx compress; alter table xxx move compress/uncompress; select table_name,compression from user_tables; También permite manejar a nivel tablespace. Carga de datos Direct path SQL*Loader, serial insert con el hint /*+ APPEND */, parallel insert, create table xxx compress as ... Recomendable para tablas read-only de gran tamaño. No recomendable para tablas que hacen updates. No hay problema con deletes e inserts. Aplicables para vistas materializada y tablas particionadas Puede inclusive mejorar performance de las consultas.

Sorting Se produce cuando: Y tiene lugar en: creamos un índice. en la consulta se usa “order by” o “group by” . en la consulta se usa “distinct”, “unique”. operaciones de UNION, INTERSECT o MINUS efectuar un sort-merge join comando “analyze” Y tiene lugar en: memoria llamada “Sort Area”. En gral. de 64k a 256k. si se necesitan más espacios adicionales, se utilizan temporary segments ubicados en los discos.