120 likes | 287 Views
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.
E N D
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 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 */ 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 */ 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: • 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.