Evolución Optimizador de Oracle Database de V6 a V11g

Evolución Optimizador de Oracle Database de V6 a V11g:

Algunos de ustedes, tal vez en alguna ocasión, han escuchado hablar de como se hacía un "tuning" en una base de datos Oracle, hace unos 10 o 15 años atrás.

Sinceramente, las condiciones eran otras muy distintas a las actuales.

Mientras mi primer contacto con una base de datos Oracle, fue en un superpoderoso AST 386 DX 33Mhz, con 32Mb de RAM y 80MB SCSI de disco duro, con Sco Unix y Oracle V5.5; hoy un servidor de base de datos, es varios cientos de veces más rápido y robusto.

Recién escuchamos a M. Hurd, Presidente de Oracle, hablar sobre el nuevo producto de base de datos Oracle, "El Oracle Database Appliance", una mezcla de software y hardware enlatados, que permite de una manera ágil, poner al alcance de las pequeñas empresas y medianas, una solución de HA a "bajo precio". Y digo "bajo precio" entre comillas, porque aún no tenemos ni idea, cuánto costará el hardware básico de este producto.

Muy posiblemente, en la próxima semana durante el OOW 2011, tendremos el panorama más claro, sobre este tema.

Pero volviendo a lo que hoy nos trae, me gustaría entregarles, cuáles han sido las principales características relacionadas con la optimización del motor de la base de datos Oracle, partiendo de la versión 6 a la actual.

Así, ustedes podrán ser testigos de más de 20 años de evolución y por lo tanto, tener claro, que el tema de "optimización", no es una receta escrita en una hoja de papel o guardada en un archivo de nuestra portátil o tableta, en un formato que me permite fácilmente, consultar y obtener, las curas a todos los males.

El afinamiento o tuning como lo quieran llamar, lleva mucha "malicia indígena", experiencia, conocimiento profundo de la arquitectura del motor de la base de datos que estamos utilizando y sobre todo, un análisis adecuado de todos los factores que intervienen en el entorno.

Antes de hacer cambios a lo loco, el procedimiento adecuado, lleva consigo, el realizar lo que yo defino, con palabras muy a lo CSI, "Análisis Forense", es sólo en este punto, donde en realidad, podemos obtener información precisa y clara, de que es lo que esta sucediendo a nivel de la base de datos y que cambios debemos realizar, para mitigar el impacto, del bajo rendimiento de un procedimiento o de la base de datos en global.

Les entrego entonces a manera de resumen, las principales novedades que han surgido a lo largo de cada uno de estos 20 años de historia.

Oracle6 - Oracle7 – El cambio más importante enla migración dela versión 6 ala versión 7 deOracle Database, fué la incorporación dela optimización basada en “Costo”.

Esto implicó para los desarrolladores, hacer ajustes importantes a nivel de las sentencias que tomaban grancantidad de tiempo en ejecutarse y aplicar reglas de“hints” para obligar a labase de datos a comportarse como lo hacía enla versiónanterior.

Por suparte, los DBA’s, sorteaban el problema, utilizando técnicas que implicaban configurar el parámetro del modo de empleo del optimizador a optimizer_mode=ruley ajustarel optimizer_index_cost_adj.

Oracle8 - Oracle8i – En este cambio de versiones, es cuando alcanza su madurez el optimizador basado en costo y vemos la aparición de las vistas materializadas y semejora la recopilación de estadísticas para elCBO.

Se introduce el DBMS_STATS, que permite una mejor colección de datos dela metadata, que le permite alCBO ser más inteligente a lahora de tomar la decisión de optimización, para la elaboración delexplain plan.

Aparecen losindexes basados en funciones, que alivian engran parte los problemas de accesototal a tablas (FTS). Sin embargo a pesar de todos estos cambios, la optimización basada en regla, aún era utilizada, al igual que los parámetros optimizer_mode, optimizer_index_cost_adj y otpimizer_index_caching.

También aquí vimos nacer las famosas tablas temporales globales, para la optimización de consultas mutipasos enSQL

Sin embargo el cambiomássobresaliente fué, la sustitucióndel utilitario BSTAT-ESTATporel STATSPACK, quepermitióel almacenamientohistóricode estadísticasde funcionamientode la base de datos,indispensable para el trabajoproactivo.

Oracle9i – Enesta versión, vimosla nuevavista v$sql_plan conel fin deayudar a afinar losSQL’s deforma proactiva y el paquete DBMS_STATS fue mejorado paraser más inteligente. Sin embargo, el DBA se vió obligado con frecuencia paraoptimizar sus SQL´s,emplear ajustes a los parámetros del optimizador.

Tambiénrecibimos el paquete DBMS_REDEFINITION para permitir una reorganización enlínea de tablas fragmentadas.

Oracle 10gR1ayudóenormemente a la optimización de las grandes cargas de trabajo de SQL’s conla introducción de muestreo dinámico.

Seintrodujeronmejoras en DBMS_STATS para permitir la creación automática de histogramasy elprocedimiento gather_system_stats,para recoger toda la informaciónimportante de factores externos,sobre todoinformación de discos, sus promedios entiempos deacceso para barrerlos índices (lecturassecuenciales) y de exploración completa de acceso (lecturasdispersas ).

Oracle 10g Release2

Apartirde estaversión, Oracleno recomienda establecer el parámetro db_file_multiblock_read_count, yaque el motor de la base de datos Oracle, permite determinar empíricamenteel ajuste óptimo.

EnOracle11g,vemos la promesa de un paquete mejorado en gran medida porel DBMS_STATS, asícomo la promesa de correr másrápido “2x”yautomáticamente recoger una muestra estadísticamente significativa.

Tambiénse incorpora una mejordetección de histogramaspara las columnas.

Oracleafirmaque el ajuste de soporte técnico de las estadísticas de la CBO mejorala ejecución y loscambios parael optimizer_index_cost_adj son"rara vez necesarios. Sinembargo, el DBA todavía tiene que establecer el valor para el optimizer_mode dela manera manual, así como también, el valor del optimizer_index_caching.

Ahora sí, podemos teniendo claro, como se comporta cada optimizador en cada versión de la base de datos, valorar de una mejor manera, que impacto, podríamos tener a la hora de migrar de una versión a otra.

Los invito entonces, a continuar leyendo mis aportes posteriores sobre el tema de "Consideraciones a la hora de migrar de una versión de base de datos a otra".

http://feed.ticoblogger.com