Eu tenho uma consulta que seleciona de várias exibições e é bastante pesada de E/S. Se eu executar esta consulta usando o Management Studio, ela usará paralelismo na maioria das 16 CPUs e será concluída em menos de 10 segundos. No entanto, ao executá-lo no SpotFire (um produto da Tibco), ele usa apenas 1 CPU e pode levar horas para ser concluído.
Consigo replicar o problema no Management Studio se estiver usando a dica de consulta OPTION (MAXDOP 1) .
Eu estava pensando que pode ser um problema do SpotFire, mas ele usa o driver Microsoft JDBC para conexão e não vejo propriedades de conexão em relação ao paralelismo. Eu confirmei usando o Profiler que as consultas do SpotFire e do Management Studio parecem exatas. a. mesmo. A única diferença parece ser a execução paralela.
Alguém pode oferecer uma visão de por que isso pode ocorrer?
!RESOLVIDO! [tipo de]
Corri novamente o rastreamento do SQL Profiler e descobri que as consultas são realmente as mesmas, mas a maneira como são executadas é diferente.
Do SpotFire:
declare @p1 int
set @p1=0
declare @p2 int
set @p2=0
declare @p7 int
set @p7=0
exec sp_cursorprepexec @p1 output,@p2 output,NULL,N'SELECT a, b, c , d FROM MyView',16,8193,@p7 output
select @p1, @p2, @p7
Do Management Studio:
SELECIONE a, b, c, d DO MyView
Em seguida, adicionei dois novos eventos ao SQL Profiler e executei novamente as consultas:
- Performance / Grau de Paralelismo
- Performance / Showplan All
Isso mostrou que a consulta do SpotFire estava usando DOP 0 (BinaryData = 0x00000000) e do Management Studio era DOP 12 (BinaryData = 0x1200000). Em seguida, o SHOWPLAN me mostrou que a consulta do SpotFire estava inserindo os resultados da exibição em uma tabela temporária antes de retornar os dados ao cliente.
Então, por que ele faz isso? Possivelmente por causa da instrução sp_cursorprepexec . Mas por que isso deveria fazer com que o DOP caísse para 0? Não sei.
Acho que a "solução" vai funcionar com o SpotFire e possivelmente ajustar a string de conexão JDBC.
Aqui está um artigo do MSDN sobre todos os parâmetros de conexão para JDBC.
Aqui está outro artigo de alguém que teve exatamente o mesmo problema que eu, também sem resolução.
Existem 2 maneiras padrão de afetar isso
O administrador de recursos do SQL Server 2008 e alguns sinalizadores de rastreamento o afetarão. Duvido que a Tibco esteja usando o administrador de recursos para que possa ser um sinalizador de rastreamento.
Mais uma opção que vi é SET IMPLICIT TRANSACTIONS ON.
Se nenhum sinalizador de rastreamento, nenhuma transação implícita e nenhuma dica MAXDOP, as consultas não são as mesmas.
Editar, após a atualização da pergunta
Você deve ser capaz de alterar algumas configurações de preparação e/ou cursor. Exemplo: http://www.streamreader.org/serverfault/questions/177391/impact-on-sql-2000-performance-of-jdbc-selectmethodcursor
Você pode tentar criar um guia de plano para a consulta especificando a dica maxdop; o artigo vinculado mostra seu uso quando você não tem controle sobre a consulta que está sendo executada e um exemplo para controlar uma consulta sp_cursorprepexec.