Usuário com melhor resposta
BUG SQL 2005?

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
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!
Todas as Respostas
-
-
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;
-
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!
-
-
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!
-
-
-
-
-
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.
-
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.
-
-
-
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).
-
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 164bits 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 1Nã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
-
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 1COM PROBLEMAS:
ID columnValue periodo
----------- --------------------- -----------
1 10 1
2 20 1
3 30 1
4 40 1
5 25 1
6 125 1 -
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 ;))
-
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
-
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
-
-
-
-
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
-
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
-
-
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).
-
-
-
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!
-
-
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
-
-
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 -
-