Cuando se una reinstalación de un servidor Windows con SQL Server o una migración de las bases de datos a otro servidor se darán cuenta que los login que tenían en el servidor original ha dejado de funcionar.

La explicación de éste fenómeno es sencilla, para SQL Server los Login son objetos del servidor y los usuarios son objetos de las bases de datos. Cuando hacemos un backup y restauramos en otro servidor con el mismo se van los usuario pero no los login (La nueva versión de SQL Server Denali tendrá una opción para embeber los logins como objetos de la base de datos, lo que evitará este típico problema). Por lo tanto debemos crear de nuevo estos login en el nuevo servidor, pero eso no es todo. (Continuar Leyendo sobre Reparar los usuarios huérfanos en SQL Server al restaurar la Base de Datos)

Si bien este es un tema que todo DBA debe conocer obligatoriamente para poder realizar el tunning de su base de datos quiero usarlo para explicar algunos conceptos básico para los siguientes artículos que estoy preparando sobre optimización del rendimiento de los querys SQL y comprensión de los planes de ejecución.

Lo que veremos aplica a las versiones 2005 y 2008 de SQL Server, aunque una gran parte también para la versión 2000. De hecho que varios de los conceptos también aplica a otros motores del mercado, unos con menos y otros con más opciones de tunning. (Continuar Leyendo sobre Diferencias entre Indices Clustered y Non-Clustered en SQL Server)

Ver query’s con la cláusula OVER no es muy común, normalmente la mayoría de los programadores o DBA crean sub-query’s para obtener los mismos resultados, lo que en sí no es malo ya que logran visualizar los mismos datos. El problema principal se encuentra en el rendimiento que tiene uno y otro método.

El motor que sea que estés utilizando optimiza el tiempo de ejecución y los bloqueos de las filas cuando se escribe scripts con OVER ya que el mismo trabaja sobre los datos ya obtenidos, en vez de volver a recuperarlos de origen.

La cláusula OVER está definida en el estándar ISO de SQL, (Continuar Leyendo sobre Como utilizar la cláusula OVER [Partition By / Order by] en SQL [Optimización])

Leer la metadata de SQL Server no es para nada complejo, y tiene una buena documentación. Una tarea útil y que es bastante buscada en los foros es listar las columnas de las tablas, con sus tipos de datos, Foreing Keys, Primary Keys, etc.

No es muy común hacer estas lecturas, pero si sirve para un DBA, o un desarrollador que quiere automatizar procesos o incluso crearse alguna especie de IDE personalizado.

En el siguiente query verán listados los nombres, el id, tipo de dato, precision, si soporta nulo, si es identity, sus FK entre otros. (Continuar Leyendo sobre Listar las columnas y sus características de una tabla en SQL Server)

Las transacciones son un conjunto de operaciones que se deben completar el conjunto completo de instrucciones o ninguna normalmente. Pero existen los casos en donde tenemos varios pasos y si se ejecuta hasta cierto punto queremos hacer COMMIT de las operaciones, y simplemente deshacer el resto que arroja error.

Las circunstancias de uso no son muy comunes pero tampoco demasiado escasas. Para lograr esto podemos crear savepoints en nuestra transacción, es cuestión de agregar un poco más de control y líneas de código a lo que estamos acostumbrados.

En el siguiente script SQL verán un ejemplo simple y (Continuar Leyendo sobre Como utilizar los SavePoints en las transacciones de SQL Server)

A través de un cursor podemos recorrer filas de un conjunto de resultados, es decir, lo que devuelva una sentecia SELECT, y el mismo tiene una manera única de operar basada en su declaración, apertura, lectura, cierre y destrucción.

En muchos casos es la única manera de resolver un problema, pero no en todos ya que hay contextos en donde pueden ser resueltos de más de una forma evitando los cursores. Personalmente recomiendo usar la menor cantidad de estos ya que consumen muchos recursos del servidor y no se destaca precisamente en su velocidad de ejecución. Además que si trabajamos una regla larga de negocio es luego dificil mantenerlo (ya recuerdo un caso de un SP con 14 Cursores anidados, era la destrucción!) . (Continuar Leyendo sobre Como crear cursores en SQL Server)

Cuando hacemos sistemas medianos a grandes es común encontrarse con que necesitamos cubrir reglas de negocios, accionando contra algunos eventos o validando situaciones, en muchos casos necesitaremos conocer si valor de una columna (más atómico que saber si se agrego o eliminó un registro) fue alterado o no.

Lo que hagamos ante este evento ya depende del contexto en el que se encuentra el sistema, pero puedo mostrarles como saber si esto sucede y existe 2 maneras ortodoxas de hacerlo, también veremos cual nos conviene utilizar en cada caso.

En SQL Server los triggers (desencadenadores) nos ayudarán a ello, siempre y cuando los eventos que reacciones tales triggers sean de INSERT o UPDATE.

La primer forma que tenemos de evaluar es preguntando si los valores de las columnas de las (Continuar Leyendo sobre Como verificar si se actualizó o no una columna en SQL Server)

Ya conociamos y veniamos hablando del SubVersion para algunos IDE’s de desarrollo e instalación de los servidores sobre Windows y Linux.

Es también sabidos que subversionar nuestros proyectos en el lenguaje que estén hechos es muy sencillo, y nos aporta muchas ventajas. Pero que sucede a la hora de versionar la Base de Datos?

Aquí casi siempre tendremos problemas, especialmente si trabajan como estoy acostumbrado. Todo el desarrollo posible sobre la BD en vez de la App. Esto nos lleva a mayor tiempo y trabajo invertido sobre la base de datos no subversionada que la aplicación que sí lo está (un poco paradójico en cierto modo).

Oracle tiene su propia herramienta de versionado de código (que podremos verlo más adelante, más vale que lo tenga con lo que cuesta también este motor). Pero los otros motores? Especificamente con SQL Server podemos versionar el código con Team Foundation Server si configuramos bien las cosas.

Otra alternativa que he encontrado hace muy poco y me ha gustado más que todas las existentes (al menos que conozco) es el producto de Red Gate, la misma es de paga, pero me parece un precio justo por la herramienta que es y no representa casi nada con lo que podemos salvar utilizando. Aunque si hubiera sido bueno tener una gamma más amplia de productos para subversionar bases de datos con opciones libres y abiertas (si encuentro alguna no duden que lo postearé, o si conocen alguna haganmelo saber que lo comento). (Continuar Leyendo sobre Como llevar un control de versiones del código DDL en SQL Server)

Ya he escuchado muchas veces personas preguntando por como reiniciar los valores de un campo que es Identity en SQL Server. Es muy común ésta tarea en migraciones, reimplementaciones y otros.

Existen varias maneras de lograr éste cometido, una es directa y otras “efectos colaterales” de ciertas acciones. La manera explicita de lograr sólo el reinicio de sus valores es la siguiente: (Continuar Leyendo sobre Como reiniciar un campo Identity en SQL Server)

Cuando trabajamos con SQL Server como motor de Base de Datos para nuestra producción, notaremos que éste crece rápidamente, ocupando mucho espacio en disco, uno de los tantos puntos que hace crecer su tamaño es el historial de sistema, que se almacena dentro de la BD llamada MSDB.

Los datos más importantes que se guardan aquí es la historia de las restauraciones y backups hechos, así que cuanto más usemos éstos recursos, la BD crecerá más. Es muy importante tener la data de esto por muchos motivos, pero también tenemos que tener en cuenta que es sólo útil por cierto tiempo (la cantidad depende de nuestro objetivo, uso, necesidad). Por ello es (Continuar Leyendo sobre Limpieza del historial de SQL Server)