Buscar este blog

lunes, 13 de diciembre de 2010

Startup Procedures

El día de hoy explicare el funcionamiento de una caracteristica desconocida por muchos pero puede ser de mucha utilidad especialmente al momento de administrar un servidor. SQL Server ofrece el procedimiento almacenado de sistema "sp_procoption" que permite asignar la propiedad de ejecutarse cuando el servicio de SQL Server se inicie, a otro procedimiento almacenado creado por el usuario.

Una de las utilidades que se le puede dar a esta caracteristica es ejecutar un procedimiento almacenado que envie correos a los administradores de la aplicacion indicandoles que el servidor de base de datos ha sido reiniciado. Tambien se le puede usar para poder iniciar una traza automaticamente para monitoriar el uso de la base de datos, asi como este se pueden hacer muchas otras cosas al iniciar el servicio de base de datos.

La sintaxis de este procedimiento se puede verificar aqui. Pero este procedimiento tambien tiene algunas restricciones las cuales se detallan a continuacion:
  • Debes estar logueado como sysadmin para usar el procedimeinto "sp_procoption".
  • Solo se pueden desigar como "startup procedures" a procedimientos almacenados standard, procedimientos almacenados extendidos y procedimientos almaceados CLR.
  • El procedimiento almacenado debe estar localizado dentro de la base de datos Master.
  • El procedimiento almacenado no debe tener ningun parametro, ni de entrada ni de salida.
Para consultar los procedimientos almacenados que han sido activados como "startup procedures", podemos ejecutar el siguiente query sobre la base de datos Master:

select name
from sys.objects
where type = 'p'
and OBJECTPROPERTY(object_id, 'ExecIsStartup') = 1


Como punto final se debe tener en cuenta que si se re-crea el procedimiento almacenado marcado como "startup procedure", se debe volver a marcar debido a que esta configuracion se pierde al hacerse un drop al procedimiento. Adicionalmente se debe tener en cuenta que la opcion de configuracion "scan for startup procs" debe estar encendida para que esto funcione, pero para facilitarnos la vida, SQL Server, al momento de ejecutar el procedimiento "sp_procoption", automaticamente esta opcion se activara. Para verificar esta si esta opcion esta encendida podemos ejecutar las siguiente sentencias:

USE master;
GO
EXEC sp_configure 'show advanced option', '1';
RECONFIGURE
EXEC sp_configure 'scan for startup procs', '1';
RECONFIGURE

En conclusión esta es una nueva caracteristica de SQL Server que nos puede traer beneficios al momento de administrar nuestro servidor de base de datos o incluso nuestra aplicacion dependiendo del uso que se le de a esta caracteristica.

domingo, 12 de diciembre de 2010

Controlar crecimiento del archivo Log de una base de datos SQL Server

Actualmente aun hay muchas personas que preguntan ¿Cómo puedo reducir mi archivo de log? ¿Por qué mi log está creciendo? Estas preguntas son muy comunes en los foros y en los lugares de trabajo debido a que la mayoría considera al archivo log de la base de datos como un archivo inútil que lo único que hace es ocupar espacio y dar preocupaciones cuando este se desborda en su crecimiento y llena todo el disco duro en el cual se encuentra.

Pero que es realmente ese archivo molesto de extensión ldf, bueno pues este archivo molesto es el que contiene todas las transacciones que se han realizado dentro de la base de datos. Es mas cuando alguien realiza alguna operación DML dentro de la base de datos, los registros que inserto, actualizo, o elimino, no se encuentran guardados directamente en el archivo de datos de la base de datos (mdf) sino que la transacción ya se encuentra físicamente en el archivo de log para que posteriormente esta pueda ser realizada dentro de el o los archivos de datos de la base de datos.


Alguien se puede preguntar ¿Por que cuando se hace commit a una operación DML no se guardan los cambios directamente en el archivo de datos sin pasar por el log? La respuesta es muy simple y es rapidez, mientras que el archivo de log se escribe de formar serializada y secuencial, el archivo de datos se escribe de manera random debido a que la tabla donde se grabaron los registros puede tener muchas páginas (unidad mínima de almacenamiento) y estas a su vez pueden estar distribuidas físicamente muy dispersas dentro del archivo de datos, lo cual haría que el grabar en el archivo de datos sea muy lento; es debido a esta razón que la grabación al archivo de datos se hace de manera asíncrona replicando las transacciones del archivo log.


Las base de datos cuentan con 3 modelos de recuperación, los cuales determinan el comportamiento final del archivo log. Estos 3 modelos de recuperación son: "Simple", "Full" y "Bulk Logged". Cuando una base de datos se crea, por defecto el motor de base de datos le asigna el modelo "Full" el cual hace parecer que el log crece y crece sin control, a menos que se tenga una buena estrategia de backups de log de base de datos, lo cual en la mayoría de casos no se conoce siquiera que existe este tipo de backup.


La solución simple para no tener una base de datos con un archivo de log gigantesco es cambiar su modelo re recuperación a "Simple" el cual hace que se reúsen las porciones del log inactivas, evitando así su crecimiento desmesurado. Para colocar este tipo de modelo de recuperación a nuestra base de datos debemos ir a las propiedades de la misma desde el SQL Server Management Studio, y situarnos en "Opciones" aquí se podrá cambiar el modelo de recuperación. Una vez que se haga este cambio nuestro archivo de log no crecerá mas, salvo contadas ocasiones que en otro post explicare.


Bueno pero todo esto también tiene sus desventajas y la principal desventaja con esta estrategia es la recuperación de los datos, digamos que todos los días a las 3 a.m., se saca un backup full de la base de datos, pero que sucede si justo el archivo de datos de nuestra base de datos se corrompe a las 10 p.m., entonces la única forma de rescatar nuestra información es restaurar el ultimo backup que se hizo a las 3 a.m., lo cual nos lleva a perder 19 horas de trabajo o 1 día entero de información. En otros modelos de recuperación si se podría recuperar hasta la última transacción realizada en la base de datos, pero también se tendría que mantener una buena estrategia de backups para poder lograrlo.


En conclusión, si lo que haces regularmente para respaldar tu información es sacar backups full de la base de datos y luego hacer un truncado del archivo log para que este no crezca desmesuradamente, entonces el modelo de recuperación "Simple" es para ti. Si se desea tener una estrategia de recuperación mas compleja que ofrezca más seguridad para respaldar los datos de la empresa, entonces lo que se recomienda es buscar a un DBA para que pueda configurar completamente la estrategia de recuperación y además pueda hacer el proceso de recuperación en un caso de desastre.

martes, 30 de noviembre de 2010

Que inserte, actualice o elimine??

Desde hace unos días atrás estoy publicando varias cosas nuevas con respecto a la base de datos MS SQL Server que existían y no lo sabía, y si quizás lo hubiera sabido antes, me hubiera ahorrado muchas horas de codificación o de análisis de cómo sacarle la vuelta a la herramienta.

El día de hoy aprendí que las sentencias insert, update y delete, cuentan con una clausula opcional llamada "OUTPUT", esta clausula es muy útil cuando luego de un insert, uno desea saber que registros fueron afectados por la operación DML.

Para obtener este resultado, antes yo hacia un select antes de la operación y lo guardaba en una tabla temporal y luego utilizaba esta data para hacer otras operaciones, pero esto no es bueno para la performance de la base de datos debido a que se está ejecutando el mismo comando select 2 veces, 1 para guardar los resultados de los registro, y otra vez para ejecutar la operación DML. Otro de los defectos de esta técnica es que hay la posibilidad de que los datos no calcen debido a que en la ejecución del primer select, la base de datos me arroje 3 registros, luego justo antes del insert otra sesión inserta un registro más en la tabla y esto hace que el select que se ejecutara en la sesión original para la operación DML ya no arroje 3 registros sino 4, y entonces nuestra técnica fallo.

No sería bueno que la base de datos nos de la posibilidad de tener los registros afectados por una operación DML, sin afectar la performance y sin la posibilidad de error en el numero de registros. Pues si la hay y es la clausula OUTPUT que tienen todas las operaciones DML (insert, delete, update y merge). Para dar más detalle de esta clausula opcional y su funcionamiento, recomiendo leer este
link que contiene la documentación oficial y es bastante completa.

Bueno espero seguir aportando con característica, funciones, sps, etc. que se encuentran ahí pero aun no los vemos.

martes, 23 de noviembre de 2010

Soundex y Difference

Hay ocaciones que uno se siente que le falta tanto por conocer, cuando descubres funciones que ya existen y tu nunca las conociste y que quizas te pudieron salvar de muchas horas de codificacion o de malas respuestas que pudiste haber dado.

Este es el caso de las funciones SOUNDEX y DIFFERENCE, estas dos funciones en SQL Server son muy potentes al momento de estandarizar data que quizas se tiene de forma plana en un texto.

Bueno les dejo el siguiente link que describe muy bien el uso de estas funciones. Espero sea de ayuda.

domingo, 21 de noviembre de 2010

Excel query pierde valores

Hace relativamente corto tiempo tuve un problema un poco dificil de resolver con MS excel. Estaba realizando cargas masivas a una base de datos SQL Server a partir de un archivo excel en mi PC de desarrollo (32 bits), aparentemente la carga pasaba correctamente y no se presentaban problemas. Pero al llevar mi script para la carga al servidor del cliente (64 bits) y luego ejecutar otro script de verificacion de duplicados, detecte mas de 300 registros duplicados, lo cual me parecio muy extraño.

Revise mi archivo excel para comprobar los duplicados reportados en el cliente y efectivamente habian varios registros duplicados. Entonces me apresure a ejecutar un query directo sobre el archivo excel en mi pc de desarrollo y vi que una columna siempre aparecia con valores null a pesar que en algunas celdas si tenia valores numericos.

Luego de investigar un poco me encontre con que el driver de MS Excel para 32 bits intenta obtener el tipo de dato de la columna que se esta seleccionando a partir de un numero determinado de filas definido en el regedit. Al parecer si no encuentra valores en esa columna hasta alcanzar el numero de fila definido en el regedit le asigna un valor texto, y cuando mas adelante en el query encuentra numeros los coloca como null. Esto me di cuenta porque edite el archivo excel y coloque como tipo de dato de la columna, texto, y modifique el valor de una celda hasta que apareciera el bendito triangulo verde en la esquina de la celda. Volvi a lanzar el query y solo me mostro valor en esa columna para la celda que habia modificado.

Para solucionar este problema tuve que modificar el parametro del regedit que se encuentra en el siguiente key "
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Excel ", el nombre del parametro es "TypeGuessRows" el valor de este parametro por defecto es 8, lo tuve que colocar en 0 para que tome todas las filas del excel para determinar el tipo de dato de la columna. Con este cambio realizado ya no perdi los valores que se encontraban en las celdas del excel.

viernes, 18 de septiembre de 2009

Sinonimos SQL Server

Para la creacion de sinonimos de objetos en otro servidor de sql server se debe tener mucho cuidado en cuando a colocar el nombre del servidor en el sinonimo.

Hace poco tenia mi ambiente de desarrollo una base de datos conectada a otra que se encontraba en un ambien te de QA y los sinonimos de la base de desarrollo apuntaban a la de QA con el nombre del servidor incluido pór ejemplo [Server].[BaseDatos].[dbo].[Objeto], todo funcionaba OK, cuando traslade mi aplicacion al servidor de QA, los sinonimos no funcionaban debido a que al estar las dos bases de datos dentro del mismo servidor fisico por algun motivo el SQL no los reconocia tuve que cambiar los sinonimos a [BaseDatos].[dbo].[Objeto], para poder ejecutarlos sin problema. Esto es importante tener en cuanta.

martes, 23 de junio de 2009

Error de Impresión SQL Server Reporting Services

Recientemente estuve desplegando una aplicacion de Reporting Services, todo iba de maravilla hasta que un día un usuario me llamo muy molesto indicandome que cuando deseaba imprimir el reporte directamente desde el browser de internet, le salia un error que describia como "No se pudo cargar el control de cliente".

Me parecio muy extraño ya que yo habia probado la impresion de los reportes desde el browser de mi maquina de desarrollo pero ahi no aparecia ningun error. Despues de mucho buscar en google, finalmente di con la solucion es un cumulative update que soluciona el problema. El enlace es: SQLServer2005-KB953752-x86-ENU.exe

A penas lo instale y reinicio el servidor todo funciono perfecto. Espero sea de utilidad esta informacion.