Início / dba / Perguntas / 55194
Accepted
SteLoe
Asked: 2013-12-18 09:06:27 +0800 CST

Falha estranha da instância do SQL Server ao converter para numérico

  • 772

Enquanto trabalhava com o C# Entity Framework, notei uma falha na minha instância do SQL Server.

Eu fui capaz de rastreá-lo para esta declaração:

SELECT * FROM dbo.[TestTable]
where mpnr in (1099059904,
1038139906,
1048119902,
1045119902,
1002109903,
1117109910,
1111149902,
1063149902,
1117159902,
1116109904,
1105079905,
1012079906,
1129129904,
1103059905,
1065059905,
1091059906,
1110149904,
1129149903,
1083029905,
1080139904,
1076109903,
1010019902,
1058019902,
1060019903,
1053019902,
1030089902,
1018149902,
1077149902,
1010109901,
1011109901,
1000119902,
1023049903,
1107119909,
1108119909,
1106119909)

A tabela fica assim:

CREATE TABLE dbo.[TestTable]([MPNR] [numeric](9, 0) NOT NULL)

A falha ocorre toda vez que inicio a consulta. Se eu reduzir o número de valores dentro da INcláusula, funciona. (Ele não retorna nenhuma linha, é claro.)

Estou ciente de que os valores na INcláusula são números de 10 dígitos e a coluna tem apenas 9 dígitos, mas isso não deve levar a uma falha de toda a instância do SQL Server.

A versão do meu SQL Server é 2008 R2 em um Windows Server 2003 de 32 bits.

Isto é um erro conhecido? Existe um patch para o SQL Server?

sql-server sql-server-2008-r2

1 respostas

  1. Best Answer

    Consegui reproduzir em 2008 R1 SP3 10.00.5512, mas a instalação da CU mais recente (14) corrigiu.

    Revendo os bugs corrigidos nas versões intermediárias, parece que você precisa atualizar para uma compilação que inclui a seguinte correção.

    Violação de acesso ao executar uma consulta que contém muitos valores constantes em uma cláusula IN no SQL Server 2008 ou no SQL Server 2012

    Como você está no 2008 R2, precisará de pelo menos CU 9 para SP1 ou CU 5 para SP2.

    A descrição dos sintomas é um tanto breve, mas menciona tipos de dados incompatíveis

    Quando você executa uma consulta que contém muitos valores constantes em uma cláusula IN no Microsoft SQL Server 2008, Microsoft SQL Server 2012 ou no Microsoft SQL Server 2008 R2, pode ocorrer uma violação de acesso.

    Observação Para que o problema ocorra, as constantes na cláusula IN não podem corresponder exatamente ao tipo de dados da coluna.

    Não define "muitos". Pelos testes que fiz, suspeito que isso possa significar "20 ou mais", pois parece ser o ponto de corte entre dois métodos diferentes de estimar a cardinalidade.

    A falha estava acontecendo dentro de alguns métodos chamados por CScaOp_In::FCalcSelectivity()com nomes como LoadHistogramFromXVariantArray()e CInMemHistogram::FJoin() -> WalkHistograms().

    Para 19 ou menos itens distintos na lista, esses métodos não eram chamados. Um bug semelhante do SQL Server 2000 também menciona esse ponto de corte como significativo.

    Preenchendo uma tabela de teste com 100.000 linhas de dados de teste aleatórios com valores entre 0 e 1.047 e um histograma começando da seguinte maneira

    +--------------+------------+---------+---------------------+----------------+
| RANGE_HI_KEY | RANGE_ROWS | EQ_ROWS | DISTINCT_RANGE_ROWS | AVG_RANGE_ROWS |
+--------------+------------+---------+---------------------+----------------+
|            0 |          0 |     104 |                   0 | 1              |
|            8 |        672 |     118 |                   7 | 96             |
|           13 |        350 |     118 |                   4 | 87.5           |
|           18 |        395 |     107 |                   4 | 98.75          |
|           23 |        384 |      86 |                   4 | 96             |
|           28 |        371 |      85 |                   4 | 92.75          |
+--------------+------------+---------+---------------------+----------------+

    A pergunta

    SELECT * FROM dbo.[TestTable]
where mpnr in (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19)
option (maxdop 1)

    Mostra linhas estimadas de 1856.

    Isso é exatamente o que seria esperado obtendo as linhas estimadas para os 19 predicados de igualdade individualmente e adicionando-as.

    +-------+----------------+-------+
| 1-7   | AVG_RANGE_ROWS | 96    |
| 8     | EQ_ROWS        | 118   |
| 9-12  | AVG_RANGE_ROWS | 87.5  |
| 13    | EQ_ROWS        | 118   |
| 14-17 | AVG_RANGE_ROWS | 98.75 |
| 18    | EQ_ROWS        | 107   |
| 19    | AVG_RANGE_ROWS | 96    |
+-------+----------------+-------+

7*96 + 118 + 4*87.5 + 118 + 4*98.75 + 107 + 1*96 = 1856

    A fórmula não funciona mais depois que 20é adicionada à lista (linhas estimadas 1902.75em vez da 1952que a adição de outra 96ao total geraria).

    BETWEENparece usar ainda outro método de cálculo de estimativas de cardinalidade.

    where mpnr BETWEEN 1 AND 20estima apenas 1829,6 linhas. Não tenho ideia de como isso é derivado do histograma mostrado.

    • 20

relate perguntas