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 en
la migración de
la versión 6 a
la versión 7 de
Oracle Database, fué la incorporación de
la optimización basada en “Costo”.
Esto implicó para los desarrolladores, hacer ajustes importantes a nivel de las sentencias que tomaban gran
cantidad de tiempo en ejecutarse y aplicar reglas de
“hints” para obligar a la
base de datos a comportarse como lo hacía en
la versión
anterior.
Por su
parte, los DBA’s, sorteaban el problema, utilizando técnicas que implicaban configurar el parámetro del modo de empleo del optimizador a optimizer_mode=rule
y ajustar
el 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 se
mejora la recopilación de estadísticas para el
CBO.
Se introduce el DBMS_STATS, que permite una mejor colección de datos de
la metadata, que le permite al
CBO ser más inteligente a la
hora de tomar la decisión de optimización, para la elaboración del
explain plan.
Aparecen los
indexes basados en funciones, que alivian en
gran parte los problemas de acceso
total 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 en
SQL
Sin embargo el cambio
más
sobresaliente fué, la sustitución
del utilitario BSTAT-ESTAT
por
el STATSPACK, que
permitió
el almacenamiento
histórico
de estadísticas
de funcionamiento
de la base de datos,
indispensable para el trabajo
proactivo.
Oracle9i – En
esta versión, vimos
la nueva
vista v$sql_plan con
el fin de
ayudar a afinar los
SQL’s de
forma proactiva y el paquete DBMS_STATS fue mejorado para
ser más inteligente. Sin embargo, el DBA se vió obligado con frecuencia para
optimizar sus SQL´s,
emplear ajustes a los parámetros del optimizador.
También
recibimos el paquete DBMS_REDEFINITION para permitir una reorganización en
línea de tablas fragmentadas.
Oracle 10gR1
ayudó
enormemente a la optimización de las grandes cargas de trabajo de SQL’s con
la introducción de muestreo dinámico.
Se
introdujeron
mejoras en DBMS_STATS para permitir la creación automática de histogramas
y el
procedimiento gather_system_stats,
para recoger toda la información
importante de factores externos,
sobre todo
información de discos, sus promedios en
tiempos de
acceso para barrer
los índices (lecturas
secuenciales) y de exploración completa de acceso (lecturas
dispersas ).
Oracle 10g Release
2
A
partir
de esta
versión, Oracle
no recomienda establecer el parámetro db_file_multiblock_read_count, ya
que el motor de la base de datos Oracle, permite determinar empíricamente
el ajuste óptimo.
En
Oracle
11g,
vemos la promesa de un paquete mejorado en gran medida por
el DBMS_STATS, así
como la promesa de correr más
rápido “2x”
y
automáticamente recoger una muestra estadísticamente significativa.
También
se incorpora una mejor
detección de histogramas
para las columnas.
Oracle
afirma
que el ajuste de soporte técnico de las estadísticas de la CBO mejora
la ejecución y los
cambios para
el optimizer_index_cost_adj son
"rara vez necesarios. Sin
embargo, el DBA todavía tiene que establecer el valor para el optimizer_mode de
la 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".
