En el grupo SQL Server Si! de Linkedin, me han hecho una consulta sobre un funcionamiento anormal de los campos Identity de una base de datos SQL Server. La traslado aquí porque es algo que a mi nunca me ha pasado.
En un SQL Server 2012 sp1 las claves primarias definidas como campos identity, en distintas tablas, y de manera aleatoria, cada semana en una, por ejemplo, se saltan 1000 registros de la secuencia.
Como digo es algo que nunca me he encontrado, así que si alguien tiene idea de lo que puede estar ocurriendo en esta base de datos le agradezco que lo comparta.
- Printer-friendly version
- Log in to post comments
Desde Twitter, Daniel Trabas
Submitted by Carlos on Thu, 05/29/2014 - 09:51
Desde Twitter, Daniel Trabas (@DaniT20), ha sugerido que podrían ser registros que se eliminen, o transacciones sucias.
Lo de los registros que se eliminen parece demasiado simple, pero tiene mucho sentido, podría haber algún proceso, procedure, aplicación etc. que por alguna razón fuera eliminando esos 1.000 registros, ¿habéis comprobado si os faltan datos o están todos y el hueco está sólo en la numeración?
Yo nunca he visto algo así, pero otra opción que se me ocurre es que por bloqueos o algo así os estén fallando algunas operaciones de insert, pero el contador se incremente igual. ¿Tenéis definidos triggers en las tablas o son todo inserts sin más? Con los triggers podrían pasar cosas de este tipo..
En otros foros ha realizado
Submitted by Hans (not verified) on Wed, 01/21/2015 - 12:38
En otros foros ha realizado la misma consulta, y es un problema que trae sqlserver 2012 sp1, se de colocar en el parametro del trace flag 272, (-t272) con ello desaparece el problema
Gracias Hans, ya tenemos otro
Submitted by Carlos on Wed, 01/21/2015 - 23:20
In reply to En otros foros ha realizado by Hans (not verified)
Gracias Hans, ya tenemos otro misterio de SQL Server resuelto :)
Enlazo uno de los blogs que he encontrado al buscar 'trace flag 272' donde explican cómo utilizar el parámetro, y también otra manera de evitar el problema, gracias a la opción NOCACHE en la creación de la secuencia:http://jamessql.blogspot.com.es/2013/07/gap-issue-in-sql-server-2012-id…
Tengo este problema y no he
Submitted by Lopez (not verified) on Thu, 09/03/2015 - 19:30
Tengo este problema y no he podido solucionarlo alguien me puede comentar si ya lo pudieron solucionar y como?
saludos
Esto sucede siempre que se
Submitted by Giorgio (not verified) on Tue, 11/28/2017 - 22:24
Esto sucede siempre que se reinicia el computador mientras está funcionando (grabando o leyendo datos) el motor de SQL, y se daña la secuencia de las tablas que estaban en uso. Hasta ahora no he encontrado solución. Me ha tocad siempre que sucede esto, reparar los datos y reinicializar la numeración.
Buenas tardes Respecto al uso
Submitted by Anonimo (not verified) on Tue, 03/20/2018 - 23:24
Buenas tardes
Respecto al uso de columnas con propiedad Identity.
Valores consecutivos después de un reinicio del servidor u otros errores: SQL Server podría almacenar en memoria caché los valores de identidad por motivos de rendimiento y algunos de los valores asignados podrían perderse durante un error de la base de datos o un reinicio del servidor. Esto puede tener como resultado espacios en el valor de identidad al insertarlo.
Si no es aceptable que haya espacios, la aplicación debe usar mecanismos propios para generar valores de clave. El uso de un generador de secuencias con la opción NOCACHE puede limitar los espacios a transacciones que nunca se llevan a cabo. https://docs.microsoft.com/es-es/sql/t-sql/statements/create-table-transact-sql-identity-property
Tiene mucho sentido, desde
Submitted by Carlos on Wed, 03/21/2018 - 07:15
In reply to Buenas tardes Respecto al uso by Anonimo (not verified)
Tiene mucho sentido, desde luego si no hay manera de garantizar que nunca se generen estos saltos y es crítico que los id's sean siempre consecutivos, hay que pensar en utilizar otras soluciones, como un mantenimiento independiente de las secuencias en estructuras, o una consulta del último valor para poder generar el siguiente antes de cada inserción, más ineficiente, pero más seguro, gracias por las dos sugerencias.