Usando el siguiente ejemplo, los predicados son los mismos, sin embargo, la declaración superior (correctamente) devuelve 0 filas, la declaración inferior devuelve 1, aunque los predicados NO coincidan:
declare @barcode nchar(22)=N'RECB012ZUKI449M1VBJZ'
declare @tableId int = null
declare @total decimal(10, 2) = 5.17
SELECT 1
FROM
[dbo].[transaction] WITH (INDEX([IX_Transaction_TransactionID_PaymentStatus_DeviceID_DateTime_All]))
WHERE
Barcode = @barcode
AND StatusID = 1
AND TableID = @tableID
AND @total <= Total
SELECT 1
FROM
[dbo].[transaction]
WHERE
Barcode = @barcode
AND StatusID = 1
AND TableID = @tableID
AND @total <= Total
¿Por qué podría estar pasando esto?
Informacion adicional:
- El índice no agrupado en la declaración superior NO se filtra
- CheckDB devuelve 0 problemas
- Versión del servidor:
Microsoft SQL Azure (RTM) - 12.0.2000.8 Dec 19 2018 08:43:17 Copyright (C) 2018 Microsoft Corporation
Pegue el enlace del plan:
https://www.brentozar.com/pastetheplan/?id=S1w_rU68E
Informacion adicional:
Han corrido lo dbcc checktable ([transaction]) with all_errormsgs, extended_logical_checks, data_purity
que indica que no hay problemas.
Puedo reproducir de manera confiable el problema en esta tabla al restaurar una copia de seguridad de esta base de datos.
sql-server
azure-sql-database
columnstore
Uberzen1
fuente
fuente
Respuestas:
Este error no requiere soltar o renombrar columnas.
También verá el mismo comportamiento para el
statusId = 100
que nunca estuvo presente en ninguna versión de la columna.Requisitos
Ejemplo
Cualquiera de los siguientes evitará el error:
= NULL
db <> demostración de violín .
Este error se corrigió en CU15 para SQL Server 2017 (y CU7 para SQL Server 2016 SP2):
REVISIÓN: la consulta en la tabla con el índice de almacén de columnas agrupado y el índice de almacén de filas no agrupado puede devolver resultados incorrectos en SQL Server 2016 y 2017
fuente
Este es un error con SQL Server. Si se elimina una columna de una tabla con un índice de almacén de columnas en clúster, y luego se agrega una nueva columna con el mismo nombre, parece estar usando la antigua columna eliminada para el predicado. Aquí está el MVCE:
Este script comienza con
10000
filas constatusId
of1
ystatusId2
of5
, luego suelta lastatusID
columna y cambia el nombrestatusId2
astatusId
. Entonces, al final, todas las filas deben tener unstatusId
5.Pero la siguiente consulta golpea el índice no agrupado ...
... y devuelve
2
filas (con el seleccionadostatusId
diferente del implícito en laWHERE
cláusula) ...... mientras que este accede al almacén de columnas y devuelve correctamente
0
MVCE
También he planteado un problema en el portal de comentarios de Azure :
Y para cualquier otra persona que se encuentre con esto, la reconstrucción del índice de almacén de columnas en clúster soluciona el problema:
La reconstrucción de CCI solo corrige los datos existentes. Si se agregan nuevos registros, el problema surge nuevamente en estos registros; así que actualmente la única solución conocida para la tabla es recrearla por completo.
fuente
and id2 = @id2
deben garantizar cero filas de todos modos como@id2
esnull
, pero que aún así obtener el 2REORGANIZE WITH (COMPRESS_ALL_ROW_GROUPS = ON);
el trabajo? Eso borrará el deltastore: ¿el problema aún ocurre para las nuevas filas agregadas después de eso?Según los planes, parece que el índice Columnstore se creó con SET ANSI_NULLS OFF. Las tablas e índices conservan la configuración tal como era cuando se creó el índice. Puede verificarlo creando un índice de Columnstore duplicado mientras se asegura de que ANSI_NULLS esté ENCENDIDO, luego descarte el original o desactívelo.
Pero, a menos que haya descubierto un error de SQL Server, esta es la única forma en que los resultados podrían ocurrir.
fuente