Problemas con Inserción desde Procedimientos almacenados al recuperar las claves o cuando usar @@identity Scope_Identity() o Ident_Current()

Buenas a tod@s

Hoy voy a contaros un par de cosillas de los procedimiento almacenados que os puede ser de gran utilidad. Muchas veces, nosotros manejamos la base de datos a través de procedimientos almacenados, ya que es más seguro, ofrece buenas herramientas de análisis, separamos el grueso de acceso a datos del resto de aplicación, permite que modifiquemos sentencias sin tener que generar una nueva publicación… y cualquier otra razón que a vosotros os guste más.

Uno de los problemas que nos enfrentamos a la hora de insertar un nuevo registro, es al devolver la clave del registro insertado, ya que este puede ser que asigne de forma automática. Muchos de nosotros utilizamos el parámetro @@identity para este fin, pero puede que no sea buena idea, ya que es posible que no devuelva en índice correcto.

Existe tres formas de obtener la clave y cada una tiene sus particularidades:

Scope_Identity(): Devuelve  la clave de la última inserción dentro del procedimiento almacenado en el que lo estamos ejecutando.

@@Identity: Devuelve la clave de la última inserción, a nivel de sesión. Esto quiere decir que si después de la inserción se ejecuta un trigger, al recuperar el valor de la clave, devolverá la clave del trigger y no la del procedimiento almacenado donde lo ejecutamos.

Ident_Current(): Devuelve la última clave introducida sin tener en cuenta sesiones. Es decir, si por ejemplo estamos introduciendo datos con dos usuarios a la vez devolverá la clave de la última inserción independientemente del usuario que lo haya insertado. Es probable que ambos reciban el mismo valor si la inserción ha sido simultánea.

Como podéis comprobar, cada una de las funciones está delimitada de una forma muy concreta. Es posible que para ciertos casos nos interese una u otra, eso tendremos que verlo en su contexto. Lo que está claro es que en muchos casos utilizamos @@identity cuando no es correcto y puede producir un gran problema de coherencia en los datos.

La información a sigo extraída de http://technet.microsoft.com/es-es/library/ms187342.aspx

Espero que este tema haya resultado interesante, no muy aburrido, que ahorre un susto a más de uno y sobre todo que sirva para algo.

Muy importante, si decides comentar o republicar parte de este articulo porque te ha sido útil, por favor cita la fuente y el autor del mismo (vamos cítame) y pon un enlace al artículo de mi blog

Muchas gracias por leerme.

Saludetes a todos

P.D. Podéis seguirme en Twitter @jberron y LinkedIn

El fichero de transacciones (LDF) crece sin límite (SQL Server) Parte 2

Buenas a tod@s

Hoy voy a hablaros de un tema que ya trate hace un tiempo en el blog. Una base de datos SQL-Server cuyo fichero de LDF (transiciones) no deja de crecer.

Tras los intentos fallidos anteriores, encontré que el problema proviene del modo de recuperación de de la base de datos.
Las bases de datos que se encuentra en modo de recuperación total no vacían nunca el registro de transiciones para que se puedan deshacer todas las operaciones, Si el modo de recuperación es Simple al realizar la copia de seguridad este si se vacía como se describe en el enlace al articulo anterior.
La forma de vaciarlo es realizando una copia de seguridad del propio fichero de transiciones. Si realizas esta copia veras como a partir de este momento el espacio libre dentro del fichero será total. Por lo que no crecerá más.

Sinceramente para mi caso guardar el fichero de transiciones más de un día es un poco absurdo, por lo que tras realizar dicho backup realizo una limpieza de las copias de los ficheros de transacciones en las que guardo solamente las copias de 1 día.

De esta manera solucionamos el problema del crecimiento desmesurado y del mantenimiento de las copias.

Espero que os sea útil.

Muy importante, si decides comentar o republicar parte de este articulo porque te ha sido útil, por favor cita la fuente y el autor del mismo (vamos cítame) y pon un enlace al artículo de mi blog

Muchas gracias por leerme.

Saludetes a todos

P.D. Podéis seguirme en Twitter @jberron y linkedin

El fichero de transacciones (LDF) crece sin límite (SQL Server)

Buenos a tod@s.

Hace un tiempo llevábamos arrastrando un problema con nuestra base de datos SQL Server. Nuestro software realiza actualizaciones masivas en la base de datos y nos encontramos con que el fichero de transacciones crecía sin fin.

La primera solución que tomamos fue vaciar el fichero de transacciones y planteamos hacer una tarea programada para dicha causa. Para realizarla creamos una tarea programada dentro del SQL Server que se encargaba de ejecutar un Script como este.

USE BaseDeDatos;

GO

-- cambiamos el recovery a nodo simple

ALTER DATABASE NombreFicheroBBDD

SET RECOVERY SIMPLE;

GO

-- reducirmos el archivo log a 1 MB.

DBCC SHRINKFILE (NombreFicheroBBDD _Log, 1);

GO

-- devolvemos el nivel de recovery a full

ALTER DATABASE NombreFicheroBBDD

SET RECOVERY FULL;

GO

Con este código dejamos el fichero de transacciones vacío. Es una posible solución aunque no demasiado elegante, por lo que seguí investigando.

Pero ¿Por qué se originaba esto? ¿Dónde estaba realmente el problema?

Más tarde, descubrí que el problema se originaba al realizar las copias de seguridad de la base de datos en cuestión.

Cuando configuramos las copias de las bases de datos de SQL Server nos da dos opciones:

• Realizar copias completas: Realiza una copia completa de la base de datos
• Realizar copias diferenciales: solo realizan la copia de lo que ha cambiado desde la última copia completa

En nuestro caso las copia de seguridad fueron configuradas para que todos los días se realizara una copia de seguridad completa. En principio no tiene por qué implicar ningún problema, bueno pues no es del todo cierto. Si siempre realizamos una copia de seguridad completa el fichero de transacciones (LDF) no se vacía nunca y siempre acumula las transacciones.

Tras ver que el problema viene de las copias. Realice un cambio en la política de copias de seguridad realizando una completa a la semana y el resto de los días una diferencias. Y con esto el problema quedo solucionado de la forma más elegante y eficiente.

Espero que este pequeño articulo os sea de utilidad y os ahorre algún dolor de cabeza

Como siempre digo si queréis ponerlo en otro sitio, no os olvidéis de mencionarme y poner un link al blog

Muchas gracias por leerme, espero que tengáis un buen día

Saludetes a todos

Agradecimientos a http://www.helpdna.net de donde extraje la información para solucionar el problemas (exactamente del árticulo  http://www.helpdna.net/sqlserver_faq_01_reducir_log_transacciones.htm)