Tengo una base de datos muy grande en nuestro almacén de datos donde hemos implementado particiones para administrar el mantenimiento y las copias de seguridad. Los registros de cierta edad eventualmente se migran a un grupo de archivos de solo lectura una vez al mes.
Ocasionalmente, nuestro proceso ETL intenta actualizar registros antiguos que ya se han migrado al archivo y esperamos que estos fallen. Sin embargo, tengo al menos dos ejemplos recientes donde el registro en la prueba se actualiza incluso cuando parece estar en una partición en el grupo de archivos de solo lectura en nuestro entorno de prueba (consulta sys.partition_functionsy sys.partition_range_values).
Un registro idéntico en producción causa la falla esperada al intentar actualizar el registro. Las dos veces que hemos captado esto hasta ahora, la actualización falla en la producción pero tiene éxito en la prueba (nunca al revés).
Datos ambientales relevantes:
- SQL Server 2012 SP3 CU3 (compilación 11.0.6537.0)
- La prueba es la edición para desarrolladores, la producción es empresarial
- Puede proporcionar otros según lo solicitado: Gravemente perplejo en este momento ...
ACTUALIZACIÓN 2016-08-19
Tenía nuevos registros actualizados de alguna manera durante la noche. Confirmó que estaba en el grupo de archivos de solo lectura. Descubrí que puedo actualizar los registros que se insertaron al mismo tiempo (es decir, también están en la misma partición en el grupo de archivos de solo lectura). Identifiqué un único registro en la misma partición y pude actualizar el registro varias veces. Intenta actualizar el registro que se actualizó de la noche a la mañana en el error esperado.
ACTUALIZACIÓN 2016-08-11
Las actualizaciones continúan ocurriendo durante el procesamiento nocturno en la prueba en la partición de solo lectura. Intentar actualizar los mismos registros del proceso falla. Intentar actualizar los mismos registros mientras está conectado como el usuario que lo actualizó anteriormente falló. Tampoco puedo duplicar el problema actualizando un registro similar que aún no ha sido tocado por el proceso nocturno.
ACTUALIZACIÓN 2016-08-04
Descubrí hoy que no se limita a esa única tabla, ya que descubrí otra ocurrencia del mismo comportamiento en una tabla diferente usando el mismo esquema de partición.
ACTUALIZACIÓN 2016-08-03
La ejecución del script desde este script de MSDN confirma lo que obtengo cuando uso las vistas de ayuda de partición de Kendra Little ph.FilegroupDetaily ph.ObjectDetailde esta demostración . El registro en cuestión vive en la partición n. ° 2 (el valor de la columna de partición para el registro en cuestión es 2015-03-18)
Filegroup Low Boundary UpperBoundary
Archive (RO) NULL 1900-01-01
Archive (RO) 1900-01-01 2015-04-01
ActiveFG (RW) 2015-04-01 2015-07-01
ActiveFG (RW) 2015-07-01 2015-10-01
ActiveFG (RW) 2015-10-01 2015-01-01
ActiveFG (RW) 2016-01-01 2016-04-01
ActiveFG (RW) 2016-04-01 2016-07-01
ActiveFG (RW) 2016-07-01 2016-10-01
ActiveFG (RW) 2016-10-01 2017-01-01
ActiveFG (RW) 2017-01-01 2115-01-01
ActiveFG (RW) 2115-01-01 NULL
Código para poner la tabla en la partición (no hay otros índices)
ALTER TABLE [dbo].[TABLE_NAME] ADD CONSTRAINT [pk_TABLE_NAME] PRIMARY KEY CLUSTERED
(
[ETL_VERS_START_DTM] ASC,
[ACCT_NO] ASC,
[ACCT_TYPE] ASC
) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON ps_SmallTablesDate(ETL_VERS_START_DTM)
La declaración de actualización que debería fallar (a través de Informatica):
UPDATE TABLE_NAME SET ETL_JOB_SEQ_NUM = ?, ETL_IUD_CD = ?, ETL_UPD_DTM = ?, ETL_DEL_DTM = ? WHERE ETL_VERS_START_DTM = ? AND ACCT_NO = ? AND ACCT_TYPE = ?
ETL_VERS_START_DTM (ETL_VERS_START_DTM:Date:): "03/17/2015 23:30:02.140000000"
ETL_JOB_SEQ_NUM (ETL_JOB_SEQ_NUM:Int:): "1173651"
ETL_IUD_CD (ETL_IUD_CD:Char.1:): "D"
ETL_UPD_DTM (ETL_UPD_DTM:Date:): "08/02/2016 02:32:45.000000000"
ETL_DEL_DTM (ETL_DEL_DTM:Date:): "08/02/2016 00:10:03.567000000"
ACCT_NO (ACCT_NO:Char.12:): "1234567890"
ACCT_TYPE (ACCT_TYPE:Char.3:): "OLN"
ACTUALIZACIÓN 2017-02-21
Entonces, después de todo este tiempo, descubrimos que, de alguna manera, cuando la partición activa más antigua se fusionó con el archivo, una sección de registros no se movió en el disco del grupo de archivos activos al grupo de archivos de archivo. La siguiente consulta muestra que los registros de la partición 2 se asignaron a ActiveFG, mientras que la inspección del esquema de partición real muestra que esos mismos registros deben clasificarse en el grupo de archivos de archivo por la función de partición.
SELECT OBJECT_NAME(P.[object_id]) ,
P.index_id ,
P.partition_number ,
F.name ,
F.filegroup_guid
FROM sys.allocation_units AU
JOIN sys.partitions P ON P.partition_id = AU.container_id
JOIN sys.filegroups F ON F.data_space_id = AU.data_space_id
WHERE P.partition_number IN ( 1, 2, 3 )
AND P.[object_id] = OBJECT_ID('TABLE_NAME')
ORDER BY P.partition_number;
Hice una copia de seguridad de todas las particiones en las bases de datos en uso y mantuve una versión de la que estaba rota para trabajar con el ticket de Microsoft. Necesito revisar el plan de partición con nuestro equipo de DW, pero admitiré ser un poco tímido para intentarlo nuevamente.
Microsoft no ha podido duplicar este comportamiento y, por lo tanto, se ha terminado con el ticket en este momento. ¿Parecen listos para ignorarlo y asumir que no está presente en 2014/2016? Parece que no pueden replicarlo en sus laboratorios a pesar de mi capacidad para que siga existiendo en la base de datos, incluso después de que lo restaure de mi sistema.