Cuando te encuentras con la presión de entregar un producto en un tiempo determinado y, seamos sinceros, han pasado cosas que no estaban en el plan, de tal forma que llevas ya con retraso considerable, escribes código que no es optimo del todo, funciona, si, pero no esta optimizado y como pasa frecuentemente, cuando es probado ya con un volumen de datos decente, y en ambientes mas cercanos a los que encontraras en producción, simplemente se demora eternidades.
En ese momento, es cuando tienes que entrar a hacer lo que un programador con mucha mas experiencia realizaría desde el principio, escribir código optimo.
Pero, entremos en materia.
Para poder realizar la optimización de querys, es necesario que entandamos un poco el como funciona el optimizador del engine de Sybase, ello nos ayudará a comprender el por que en ocasiones las cosas no funcionan como deberían funcionar.
Claro esta, deberemos conocer los elementos que intervienen al momento de resolver una consulta, y los cuales pueden determinar si esta será optima o no.
De tal forma, empecemos analizando estos elementos.
Índices.
Los índices en sybase son fundamentales para la optimización de las consultas, se puede decir que todas las tablas requieren de por lo menos un índice, el cual deberá estar conformado por los campos de la llave primaria, y el cual garantice la unicidad de los registros.
Los índices pueden tener las siguientes características.
Único.
No permitirá la inserción de mas de un registro con la misma información en cuanto a los campos que lo componen, es ideal para garantizar la unicidad, una tabla puede tener mas de un índice único, por ejemplo la tabla que almacene la informaci�n de contribuyentes puede tener un �ndice �nico para el campo de RFC y otro �ndice �nico para el campo de CURP.
Clustered.
Esta caracter�stica define el orden en el cual es guardada la informaci�n dentro de la tabla, ejemplo, en una tabla que no contenga un �ndice clustered, cada vez que se inserta un registro, este es insertado en la ultima pagina de datos disponible, es decir, los registros no guardan un orden mas all� del de su inserci�n, sin embargo, si una tabla tiene un �ndice clusterd, al momento de insertar un registro, este es puesto en el lugar que le corresponda de acuerdo al orden definido por los campos que integran el �ndice clustered, esto es muy �til para agilizar las consultas mas comunes, por definici�n, una tabla solo puede tener un �ndice clusterd, y se conforma, por los campos que le den el orden a las consultas que las agrupen en un orden jer�rquico mas com�n, ejemplo: en una tabla que almacene las ventas diarias de productos por cliente, y que contenga los campos:
Fecha
Cliente
Producto
Venta
Precio
Descuento
Impuesto
El �ndice clustered deber�a estar compuesto por los campos Fecha, Cliente, Producto, no tendr�a caso ordenar la informaci�n dentro de la tabla basado en los campos de Venta, Descuento, toda vez que esta no seria la organizaci�n jer�rquica mas com�n.
Query Plan
El optimizador de sybase realiza un plan de ejecuci�n de cada consulta que va a resolver, este plan de ejecuci�n es el que determina la forma en la cual realizara la b�squeda de los datos, por ejemplo, puede determinar usar un �ndice en lugar de otro (asumiendo que la tabla contiene mas de un �ndice), si creara una tabla temporal para realizar un ordenaci�n o una agrupaci�n
En el caso de los procedimientos almacenados, el momento que se crean dentro del engine de sybase, se determina el plan de ejecuci�n de todas las consultas que lo componen, dicho plan de ejecuci�n es almacenado al igual que la definici�n del procedimiento, de tal forma, que al ser invocado, solo se realiza el plan de ejecuci�n definido durante su creaci�n, esto puede presentar problemas de optimizaci�n posteriores, por ejemplo, tenemos una tabla de empleados la cual tiene solo un �ndice por el campo RFC, creamos un procedimiento almacenado el cual solo contiene una consulta a esta tabla buscando a los registros cuya fecha de nacimiento sea igual a un valor determinado.
Al momento de crear el procedimiento, el engine optara por hacer un barrido de todos los registros de la tabla, toda vez que no tiene ning�n �ndice que pueda ayudar a filtrar la informaci�n solicitada, el plan de ejecuci�n es guardado junto con la definici�n del procedimiento, y cada vez que lo ejecute, utilizar� el mismo plan de ejecuci�n, que pasar�a, si a la tabla del ejemplo le creamos un �ndice secundario que contenga solo el campo fecha de nacimiento.
El procedimiento almacenado ignorara el nuevo �ndice, toda vez que no exist�a durante su creaci�n, por lo que no fue considerado por el optimizador de sybase al momento de crear el plan de ejecuci�n, para solucionar el problema, bastar� con regenerar el procedimiento almacenado.
Debido a este punto, puede presentarse muchos problemas de optimizaci�n, es recomendable regenerar los procedimientos almacenados cuando existan cambios en la definici�n de los �ndices, o cuando el volumen de datos contenidos en las tablas ha cambiado dr�sticamente.
Estad�sticas de Acceso.
Sybase lleva un registro estad�stico del n�mero de p�ginas que debe leer para poder obtener un registro solicitado, estas estad�sticas est�n ligadas a cada uno de los �ndices que contengan las tablas.
El hecho que el optimizador de sybase decida utilizar un �ndice o no, puede ser provocado por la estad�stica de acceso al mismo, por ejemplo, en una tabla que normalmente contiene un volumen reducido de informaci�n, al ser alimentada por medio de un BCP con volumen mucho mayor, los querys pueden optar por no utilizar el �ndice que ya que el optimizador considera que al tener pocos registros es mas r�pido hacer un barrido que utilizar el �ndice.
Es recomendable hacer una actualizaci�n a las estad�sticas de los �ndices como parte del mantenimiento de las bases de datos.
Continuaremos en el siguiente post con los demas elementos.
