none
BUG SQL 2005? RRS feed

  • Pergunta

  • Caríssimos,
     
     
    Entre as query's descitas abaixo a única alteração é a posição das colunas do "INSERT SELECT", entretanto os resultados obtidos no SQL 2005 são diferentes!!! Testei a mesma query no SQL 2000 e o comportamento foi normal.
     
    Alguém tem alguma dica?
     
     

    SELECT @@Version

     

    SELECT 'SEM PROBLEMAS:'

     

    DECLARE @varTable table(

          ID int,

        columnValue int,

          periodo int);

     

    INSERT INTO @varTable (ID, columnValue, periodo) VALUES (1, 10, 1)

    INSERT INTO @varTable (ID, columnValue, periodo) VALUES (2, 20, 1)

    INSERT INTO @varTable (ID, columnValue, periodo) VALUES (3, 30, 1)

    INSERT INTO @varTable (ID, columnValue, periodo) VALUES (4, 40, 1)

     

    INSERT INTO @varTable (ID, columnValue, periodo)

    SELECT 5, SUM(columnValue) / COUNT(id), periodo FROM @varTable

    GROUP BY periodo

     

    UNION

     

    SELECT 6, SUM(columnValue), periodo FROM @varTable

    GROUP BY periodo

     

     

    SELECT * FROM @varTable ORDER BY ID

     

    SELECT 'COM PROBLEMAS:'

     

    DECLARE @varTableProblem table(

          ID int,

        columnValue int,

          periodo int);

     

    INSERT INTO @varTableProblem (ID, columnValue, periodo) VALUES (1, 10, 1)

    INSERT INTO @varTableProblem (ID, columnValue, periodo) VALUES (2, 20, 1)

    INSERT INTO @varTableProblem (ID, columnValue, periodo) VALUES (3, 30, 1)

    INSERT INTO @varTableProblem (ID, columnValue, periodo) VALUES (4, 40, 1)

     

    INSERT INTO @varTableProblem (periodo, ID, columnValue)

    SELECT periodo, 5, SUM(columnValue) / COUNT(id) FROM @varTableProblem

    GROUP BY periodo

     

    UNION

     

    SELECT periodo, 6, SUM(columnValue) FROM @varTableProblem

    GROUP BY periodo

     

    SELECT * FROM @varTableProblem ORDER BY ID

    quarta-feira, 23 de agosto de 2006 14:36

Respostas

  • Resposta definitiva da Microsoft: É bug e será corrigido em uma próxima atualização / service pack.

    E-mail (cópia literal) da Microsoft:

    Bom dia, Felipe.

     

                Sobre o seu caso, ele já foi registrado como bug pela Microsoft.

     

                O que podemos fazer são “workarounds” para trabalhar enquanto este mesmo bug não é corrigido em um próximo Service Pack / Atualização.

     

                Eles seriam:

     

    1.       Usar

    INSERT INTO @varTableProblem (periodo, ID, columnValue)

    SELECT periodo, 5, SUM(columnValue) / COUNT(id) FROM @varTableProblem

    GROUP BY periodo

    UNION

    SELECT periodo, 6, SUM(columnValue) FROM @varTableProblem

    GROUP BY periodo

    OPTION(MERGE UNION)

                Em vez de:

     

    INSERT INTO @varTableProblem (periodo, ID, columnValue)

    SELECT periodo, 5, SUM(columnValue) / COUNT(id) FROM @varTableProblem

    GROUP BY periodo

    UNION

    SELECT periodo, 6, SUM(columnValue) FROM @varTableProblem

    GROUP BY periodo

     

    2.       Você pode colocar SET FORCEPLAN ON no começo da sua procedure.

    Grande abraço e obrigado a todos pela força!

    sexta-feira, 25 de agosto de 2006 15:01

Todas as Respostas

  • Diferente como?
    quarta-feira, 23 de agosto de 2006 16:20
  •  

     

     testei as duas, a segunda query o retorno esta igual nos dois sql 200p e 2005, o problema nao esta na union ?

    troque o union por union all, o union all nao exlui linhas, mais realmente tambem achei estranho. vou procurar analisar melhor isso mais experimente tambem ai com o union all nos dois server 2000 e 2005.

     

    Abs;

     

     

    quarta-feira, 23 de agosto de 2006 16:38
  • Trocar o union por union all vai resolver o problema...

    Entretanto "union" de coisas diferentes é igual a "union ALL", concorda?

    Analise melhor, não retorna a mesma coisa no SQL 2000 e no SQL 2005... observe que a query tem DUAS "sub" querys... a primeira exectua igual em ambos (possui as colunas em ordem) a segunda tem as colunas diferentes.

    Abraço!

    quarta-feira, 23 de agosto de 2006 17:15
  • Observe que a linha 6 da segunda query retorna valores difrentes no sql 2000 e no sql 2005.
    quarta-feira, 23 de agosto de 2006 17:18
  • Vou tentar explicar o que está acontecendo; Na primeira, (comportamento CORRETO) ele não considera a primeira inclusão do UNION no cálculo. Na segunda, ele faz isso, mas NÃO deveria. A diferença entre as duas é APENAS a mudança entre colunas.

    Até agora, estou considerando este problema como um BUG no SQL 2005.

    "UNION ALL" retorna os resultados esperados assim como "mudar a posição das colunas" retorna os resultados esperados.

    Alterar a clausula para UNION ALL, NÃO pode ser adotado como solução até seja provado que não há outra solução. Estamos fazendo uma migração e esperávamos que a migração fosse transparente.

    Obrigado pela atenção!

     

     

    quarta-feira, 23 de agosto de 2006 17:27
  • entao foi isso que eu nao entendi, quando colocado o union all a query fica igual nas duas versoes.

     

    Abs;

    quarta-feira, 23 de agosto de 2006 17:28
  • É estranho mesmo... estou em contato com o suporte da microsoft pra tentar trabalhar o problema... Quando tiver alguma resposta, eu repasso aqui, mas acho que só teremos solução em algum fix.

    Abraço e valeu pela atenção...

    quarta-feira, 23 de agosto de 2006 17:43
  • chegou a testar com o union all ?, e realmente se puder postar aqui a resposta do suporte sera de grande ajuda.

    obrigado.

    Abs;

    quarta-feira, 23 de agosto de 2006 17:47
  • Oquendo,

    Este também fiz os testes e cheguei as mesmas conclusões que todos, isso é algo estranho realmente de se acontecer.

     

    quarta-feira, 23 de agosto de 2006 17:58
  • Sim, testei com o union all... funciona perfeitamente.

    Mas observe o seguinte: Tirar o agrupamento resolve o problema, ordenar as colunas resolve o problema, sem o insert o problema não acontece, utilizar union all resolve o problema.

    Não faço a menor idéia do que possa estar acontecendo. Quando tiver uma resposta do suporte, vou postar aqui.

    quarta-feira, 23 de agosto de 2006 18:03
  • Junior e Marcelo,

     

    Bastante estranho... Tenho certeza de que eu não fui o único que migrou o sistema, por isso fico preocupado que outras pessoas estejam tendo problemas de inconsistência e não estejam notando...

    Se isso entrasse em produção, nós teríamos prejuízos incalculáveis.

     

    Abraço e mais uma vez, obrigado pela atenção.

    quarta-feira, 23 de agosto de 2006 18:08
  • Fiz o teste tb e achei  muito estranho mesmo.......  estou estudando para ver oque  pode ser... se acharem a resposta poste ai
    quarta-feira, 23 de agosto de 2006 18:43
  • Andre Hass,

    Bem vindo ao clube! ;)

    O suporte da microsoft ficou de me dar alguma posição até amanhã a tarde.

    quarta-feira, 23 de agosto de 2006 18:58
  • NOVIDADES:

    No enterprise edition, ambas as querys retornam 125 para a linha 6 (inconsistente), quando deveriam retornar 100. O que torna a primeira query inconsistente no SQL Server 2005 Enterprise Edition com SP1.

    Na SQL Server 2005 Standard Edition com SP1, a primeira retorna 100 na linha 6 (consistente) e a segunda continua retornando 125 na linha 6 (inconsistente). 

    quarta-feira, 23 de agosto de 2006 19:45
  • Olá Oquerendo,

    Eu diria o seguinte....muito interessante e intrigante isso. Mas para apimentar um pouco mais vai uma pergunta....Vc nã oestá com o SP1 do SQL Server 2005 está? Quando executo seu script em um SQL Server 32Bits sem SP1 tenho, realmente tenho o resultado <> para as duas queries, no entanto, quando executo a sua query no SQL Server 2005 64bits com SP1..... o resultado é o mesmo!! POREM....é o mesmo resultado da segunda query, ou seja, 125.

    Veja os resultados abaixo:

    32bits sem SP1:
    Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86)
    Oct 14 2005 00:33:37
    Copyright (c) 1988-2005 Microsoft Corporation
    Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 1)

    --------------
    SEM PROBLEMAS:

    ID          columnValue periodo
    ----------- ----------- -----------
    1           10          1
    2           20          1
    3           30          1
    4           40          1
    5           25          1
    6           100         1


    --------------
    COM PROBLEMAS:

    ID          columnValue periodo
    ----------- ----------- -----------
    1           10          1
    2           20          1
    3           30          1
    4           40          1
    5           25          1
    6           125         1

    64bits com SP1:
    Microsoft SQL Server 2005 - 9.00.2047.00 (X64)
    Apr 14 2006 01:11:53
    Copyright (c) 1988-2005 Microsoft Corporation
    Enterprise Edition (64-bit) on Windows NT 5.2 (Build 3790: Service Pack 1)

    --------------
    SEM PROBLEMAS:

    ID          columnValue periodo
    ----------- ----------- -----------
    1           10          1
    2           20          1
    3           30          1
    4           40          1
    5           25          1
    6           125         1


    --------------
    COM PROBLEMAS:

    ID          columnValue periodo
    ----------- ----------- -----------
    1           10          1
    2           20          1
    3           30          1
    4           40          1
    5           25          1
    6           125         1

    Não sei se isto é bom ou ruim para vc mas se vc passar o SP1 terá o mesmo resultado em ambas as queries!! Como a plataforma não deve influenciar neste tipo de resultado, acredito que a diferença entre o SQL 2000 e o SQL 2005 possa estar em uma possível mudança no comportamento do UNION

    um abraço e nos deixe saber o resultado disso junto ao suporte ok

     

     

    quarta-feira, 23 de agosto de 2006 20:29
  • Muitíssimo interessante estas considerações... vou estar anexando ao suporte da Microsoft pra que eles considerem este tipo de teste também!

    Entretanto, tenho o SP1 instalado e tenho os resultados diferentes... A propósito, utilizo o 32 bits também. 

    Segue o resultado do meu management studio:

     

    Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86)
    Oct 14 2005 00:33:37
    Copyright (c) 1988-2005 Microsoft Corporation
    Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 1)

    SEM PROBLEMAS:

    ID           columnValue    periodo
    -----------    ---------------------    -----------
    1             10                     1
    2             20                     1
    3             30                     1
    4             40                     1
    5             25                     1
    6             100                   1

    COM PROBLEMAS:

    ID           columnValue    periodo
    -----------    ---------------------    -----------
    1             10                     1
    2             20                     1
    3             30                     1
    4             40                     1
    5             25                     1
    6             125                   1

    quarta-feira, 23 de agosto de 2006 20:50
  • Nilton, Você tem certeza que o SQL Server 32 bits onde você testou está sem SP1?

    Observe o resultado do "SELECT @@Version" que você postou:

    32bits sem SP1:
    Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86)
    Oct 14 2005 00:33:37
    Copyright (c) 1988-2005 Microsoft Corporation
    Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 1)

     

    ats;

    Felipe Oquendo (não Oquerendo ;))

    quarta-feira, 23 de agosto de 2006 21:01
  • Olá Felipe,

    Absoluta !! Na verdade vc vê o  build do SQL Server através dos números após o Microsoft SQL Server 2005  , ou seja,  9.00.1399.06 (Intel X86). Atualmente temos 3 principais builds do SQL 2005:

    a versão RTM (original) com build 9.00.1399
    a versão com SP1, que eleva  o build para 9.00.2047
    a versão com cumulative hotfix (instalado após o SP1, que eleva o build para 9.00.2153 (http://support.microsoft.com/kb/918222)

    Este que vc está informando (Build 3790: Service Pack 1) é na verdade o build do Windows e não do SQL Server!!

    Analisando o resultado do seu Management Studio, indica que vc não está com o SP1. Mas sim com um SQL Server Standard de build RTM.

    Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86)  --- versão RTM
    Oct 14 2005 00:33:37
    Copyright (c) 1988-2005 Microsoft Corporation
    Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 1) -- SQL Server 2005 Standard.

    Para vc não se confundir, uma boa é  disparar a query abaixo no Query Editor:

    SELECT SERVERPROPERTY('edition'),
    SERVERPROPERTY('productversion'),
    SERVERPROPERTY('productlevel')

    qualquer coisa retorne.

    um abraço 

     

    quarta-feira, 23 de agosto de 2006 23:05
  • Caro Nilton,

     

    O SP1 me confundiu, obrigado pelas informações! Fiquei até esperançoso de que isso pudesse vir a resolver os meus problemas, mas encontrei uma lista do que foi modificado no sp (http://support.microsoft.com/?kbid=913090) e não há nada relacionado... Também olhei alguns rot fixes que vieram depois da RTM e não encontrei nada.

     

    Abraço!

    Felipe Oquendo

     

    quinta-feira, 24 de agosto de 2006 03:15
  • Felipe, nao esqueca de comentar o caso do union all, na verdade isso tambem esta me deixando em duvida.

    pode ser um bug do union, procurei tambem e nao achei nada relativo a esse problema

     

    Abs;

    quinta-feira, 24 de agosto de 2006 10:10
  • Marcelo,

     

    Quando eu reportei o problema entramos em uma "live meeting" e eu demonstrei que o UNION ALL calculava corretamente.

    Aproveitei para mostrar também esta thread já que haviam tantas pessoas interessadas no problema.

     

    Abraço!

    quinta-feira, 24 de agosto de 2006 11:32
  • Considerando que da versão RTM para o SP1 houve uma mudança no resultado (todos passaram a ser 125), ainda acredito que seja uma mudança no comportamento do UNION!!

    um abraço

    quinta-feira, 24 de agosto de 2006 12:52
  • Nilton  eu tb aposta em uma mudança de comportamento do union ..... mas vc disse que executou em 32 Bits e 64 Bits e o resultado foi diferente.......   estranho  eu procurei muito e não achei nada..... se fosse um bug provavelmente ja estaria no site da MS....  vou tentar falar com o Ricardo para ver se ele sabe de algo

     

    abs

     

    quinta-feira, 24 de agosto de 2006 14:37
  • Olá André,

    Na verdade a diferença no resultado não está no fato da plataforma ser diferente, mas sim porque no 32bits eu estou SEM o SP1 e no 64bits eu estou COM o SP1. A diferença está no SP1!!

    SEM SP1 o resulta é 100 p/ a primeira query e 125 para a segunda.

    COM o SP1 o resultado é 125 para as duas queries!! Ou seja, temos então 3 alternativas:

    1. Na versão RTM temos o problema e este foi corrigido no SP1, no entanto, os resultados são definidos como 125 e não 100.

    2. Se o SP1 realmente resolve o problema, então o resultado obtido no SQL 2000, sempre esteve errado.  Lá, ambas as queries retornam 100. (acho este muito pouco provável).

    3. O SP1 do SQL 2005 ao invés de corrigir, acabou de ferrar tudo.

    Apenas acrescentando... fiz os testes em uma máquina 32bits COM SP1 e o resultado é 125 para as duas queries!! Isso mostra que a plataforma não tem influência sobre o resultado.

    um abraço

    quinta-feira, 24 de agosto de 2006 17:32
  • muito estranho estou curioso para tentar descobrir o que é ..... ... vou fazer mais testes e procurar mais coisas...

     

    abs

     

    quinta-feira, 24 de agosto de 2006 19:06
  • Conforme prometido, resposta do suporte:

     

    Ainda não é definitivo, mas o suporte da MS considerou como um BUG no SQL Server 2005.

    Particularmente, fico feliz porque se fosse uma mudança de comportamento, eu teria bastante trabalho tendo que revisar 5 anos de desenvolvimento.

    A migração "deveria" ser transparente e se fosse uma mudança de comportamento no UNION, a cláusula executada sem o insert deveria retornar 125 e não 100.

    Atualizei o meu SQL Server 2005 para SP1 e de fato obtive 125 para ambas as querys (obrigado pela dica Nilton).

    Estarei entrando em conferência amanhã ou na próxima segunda com o pessoal da MS e talvez consigamos chegar a um workaround para esse problema (provavelmente teremos que esperar um hotfix).

    quinta-feira, 24 de agosto de 2006 20:39
  • Legal Felipe, valeu pelo feedback !!

    um abraço

    sexta-feira, 25 de agosto de 2006 00:44
  • show, ao meu ver o problema esta no operador union mesmo. mais muito obrigado pelo retorno.
    sexta-feira, 25 de agosto de 2006 10:10
  • Resposta definitiva da Microsoft: É bug e será corrigido em uma próxima atualização / service pack.

    E-mail (cópia literal) da Microsoft:

    Bom dia, Felipe.

     

                Sobre o seu caso, ele já foi registrado como bug pela Microsoft.

     

                O que podemos fazer são “workarounds” para trabalhar enquanto este mesmo bug não é corrigido em um próximo Service Pack / Atualização.

     

                Eles seriam:

     

    1.       Usar

    INSERT INTO @varTableProblem (periodo, ID, columnValue)

    SELECT periodo, 5, SUM(columnValue) / COUNT(id) FROM @varTableProblem

    GROUP BY periodo

    UNION

    SELECT periodo, 6, SUM(columnValue) FROM @varTableProblem

    GROUP BY periodo

    OPTION(MERGE UNION)

                Em vez de:

     

    INSERT INTO @varTableProblem (periodo, ID, columnValue)

    SELECT periodo, 5, SUM(columnValue) / COUNT(id) FROM @varTableProblem

    GROUP BY periodo

    UNION

    SELECT periodo, 6, SUM(columnValue) FROM @varTableProblem

    GROUP BY periodo

     

    2.       Você pode colocar SET FORCEPLAN ON no começo da sua procedure.

    Grande abraço e obrigado a todos pela força!

    sexta-feira, 25 de agosto de 2006 15:01
  • Show.... Valeu.
    sexta-feira, 25 de agosto de 2006 15:12
  • Olá Felipe..

    hehe...quemdiria hein, um simples SET FORCEPLAN resolve o problema !!

    Legal e valeu pelo feedback..

    Obs: Se me permite gostaria de colocar este seu caso como um artigo em meu site...acho que pode ajudar outras pessoas e servir como ponto de observação importante para quem está migrando para o SQL Server 2005.

    Bom, se quiser vc mesmo pode fazer um resuminho do caso e colocar no meu site como um artigo.Assim ficará tendo vc mesmo como autor (o que ao meuver seria mais legal).Segue olink para isso...http://www.mcdbabrasil.com.br/modules.php?name=Submit_News

    um abraço

     

    sábado, 26 de agosto de 2006 00:23
  • O prazer será todo meu!
    segunda-feira, 28 de agosto de 2006 20:24
  • Artigo:

     

    Trabalho em uma empresa que desenvolve um ERP onde estava avaliando a migração do SQL Server 2000 para o SQL Server 2005.

     

    A expectativa inicial era de que a migração fosse transparente e que pudéssemos migrar todos os nossos clientes o mais rápido possível.

     

    Com pouco tempo, uma inconsistência começou a nos preocupar. Iniciamos uma investigação e descobrimos uma falha causada por uma query na aplicação.

     

    Suspendemos temporariamente o plano de migração para recorrer ao suporte da Microsoft.

     

    A query a baixo reproduz o problema:

     

    SELECT @@Version

     

    DECLARE @varTable table(

          ID int,

          columnValue int,

          periodo int);

     

    INSERT INTO @varTable (ID, columnValue, periodo) VALUES (1, 10, 1)

    INSERT INTO @varTable (ID, columnValue, periodo) VALUES (2, 20, 1)

    INSERT INTO @varTable (ID, columnValue, periodo) VALUES (3, 30, 1)

    INSERT INTO @varTable (ID, columnValue, periodo) VALUES (4, 40, 1)

     

    INSERT INTO @varTable (periodo, ID, columnValue)

    SELECT periodo, 5, SUM(columnValue) / COUNT(id) FROM @varTable

    GROUP BY periodo

     

    UNION

     

    SELECT periodo, 6, SUM(columnValue) FROM @varTable

    GROUP BY periodo

     

    SELECT * FROM @varTable ORDER BY ID

     

    Se esta query for executada no SQL Server 2000 e no SQL Server 2005 os resultados serão diferentes. No SQL Server 2000 o resultado para a sexta linha será 100 enquanto no SQL Server 2005, o resultado obtido para a mesma linha será 125.

     

    O suporte da Microsoft foi incrivelmente rápido em resolver o nosso problema. Em pouco tempo, conseguimos atestar que de fato, o bug existia e nos foi garantido que em uma próxima atualização, o problema estaria resolvido. Até que esta atualização seja lançada, o suporte sugeriu duas possíveis soluções:

     

    1.       Utilizar

    INSERT INTO @varTableProblem (periodo, ID, columnValue)

    SELECT periodo, 5, SUM(columnValue) / COUNT(id) FROM @varTableProblem

    GROUP BY periodo

    UNION

    SELECT periodo, 6, SUM(columnValue) FROM @varTableProblem

    GROUP BY periodo

    OPTION(MERGE UNION)

     

    Ao invés de:

     

    INSERT INTO @varTableProblem (periodo, ID, columnValue)

    SELECT periodo, 5, SUM(columnValue) / COUNT(id) FROM @varTableProblem

    GROUP BY periodo

    UNION

    SELECT periodo, 6, SUM(columnValue) FROM @varTableProblem

    GROUP BY periodo

     

     

    2.       Utilizar SET FORCEPLAN ON.

     

    Nós não queríamos fazer qualquer tipo de alteração de código para a migração, então decidimos simplesmente aguardar a atualização que resolverá o problema.

     

    Paralelo ao contato com a Microsoft estava dividindo o problema com profissionais extremamente competentes no Fórum da MSDN Brasil. A comunidade foi fundamental para que conseguíssemos chegar ao ponto exato de onde estava o problema. Tudo que era descoberto pelos membros da comunidade, era repassado para o acompanhamento do problema por parte da Microsoft. Por isso, finalizo este meus comentários agradecendo a todos que fazem parte da Microsoft Developers Network!

     

    Felipe Oquendo
    MCAD

    segunda-feira, 28 de agosto de 2006 21:01
  • O SQL 2005 SP2 resolve este problema :)
    segunda-feira, 5 de março de 2007 15:04
  • Olá Oquedo...testei isso logo no SP2 CTP e o realmente já solucionado

    um abraço
    Nilton Pinheiro
    www.mcdbabrasil.com.br

    terça-feira, 6 de março de 2007 00:39