Contenção TempDB no SQL 2005 sysmultiobjrefs

3

Temos tido problemas causados pelo que acreditamos ser uma contenção dentro do tempDB.

Sempre que estamos tendo problemas, nosso sistema está sempre esperando por um recurso em particular: 2: 1: 103, que quando o pesquisamos (usando DBCC PAGE (2,1,103)) retorna para object_id 75, que é o tabela do sistema sysmultiobjrefs.

Para resolver esse problema, às vezes podemos nos livrar do uso de spids suspensos esperando por esse recurso ... nos piores casos, precisamos parar o SQL e reiniciá-lo.

Alguma idéia de como aliviar isso?

Estamos executando o SQL 2005 SP3 x64 em um servidor quad / quad com 128 GB de RAM. Os discos também estão em uma SAN com log / tempdb / data, cada um em sua própria unidade RAID 1/0.

O TempDB tem 16 arquivos de dados (um para cada núcleo) e um arquivo de log.

Obrigado antecipadamente.

    
por Rob 10.06.2009 / 18:57

5 respostas

2

Você tem muitas instruções SELECT INTO no seu código SQL? Isso causará o bloqueio em vários objetos do sistema tempdb até que a instrução SELECT INTO seja concluída.

    
por 20.06.2009 / 04:18
2

Rob,

Em nosso ambiente, temos lidado com a sua questão 2: 1: 103 por cerca de um mês. Uma das maneiras de evitar esse problema foi reiniciar o Serviço SQL periodicamente, se isso for uma opção. Não houve resposta clara em muitos dos fóruns para este problema específico. T1118 bandeira não foi considerada eficaz em argumentos apresentados por Linci Shea (MVP) e um par de outros em seus blogs.

Um cenário de produção em que eu pessoalmente vi o problema acontecer e desaparecer foi quando o servidor SQL teve a oportunidade de aumentar a memória de 24 Gb para 27 GB. A 24gb, havia aproximadamente 40 processos pendurados em 2: 1: 103 enquanto um trabalho de tarefa não relacionado estava sendo executado no servidor db. Eu matei essa tarefa e SQL começou a tomar mais memória dos 30 GB disponíveis, a contenção de Tempdb desapareceu gradualmente em 27 GB em cerca de um minuto ou mais depois de ter 27 GB. Essa é uma área que você pode tentar testá-lo sozinho. Reduza as pegadas de outros serviços no servidor de banco de dados e aumente a memória máxima disponível para SQL.

Deixe-me saber se você encontrar alguma outra solução para o mesmo.

Singh.

    
por 04.08.2009 / 17:00
2

Eu percebo que estou atrasado para a festa aqui, mas minha equipe teve uma corrida com 2: 1: 103 esta semana. Essencialmente, a contenção neste recurso indica contenção com operações DDL no tempdb e é causada pela criação / destruição de muitas tabelas temporárias ou variáveis de tabela temporária. Eu bloguei sobre isso em link A contenção aqui não será aliviada pelo sinalizador de traço T1118 ou pela adição de arquivos ao tempDb. A chave é reduzir o uso de tabelas temporárias e variáveis de tabela temporária ou avaliar o contexto de seu uso para ver se estão sendo armazenadas em cache. Consulte o link para obter bons detalhes aqui.

    
por 11.09.2011 / 08:12
1

Você verificou se não está apenas obtendo impasses de transações que interferem no trabalho um do outro? Você verificou as consultas SQL em execução / bloqueadas quando o bloqueio ocorreu?

    
por 18.06.2009 / 09:48
1

Você tentou ativar o sinalizador de traço T1118?

artigo do KB da MS

Cite o artigo:

Note Trace flag -T1118 is also available and supported in Microsoft SQL Server 2005 and SQL Server 2008. However, if you are running SQL Server 2005 or SQL Server 2008, you do not have to apply any hotfix.

Increase the number of tempdb data files to be at least equal to the number of processors. Also, create the files with equal sizing. For more information, see the "More Information" section.¨

Costumava haver um problema de desempenho com o traceflag T1118 no SP2, mas o Ms lançou um hotfix, e ele deve ser corrigido no SP3, como no seu caso.

Concordo com o mrdenny sobre como as tabelas temporárias são criadas, você nunca deve criar uma tentação com SELECT * INTO #x FROM TableA, a menos que você tenha uma cláusula WHERE como esta:

ONDE 1 = 2

Mas minha recomendação é usar a sintaxe CREATE TABLE #x. Por quê? O SQL colocará muitos bloqueios nas tabelas do sistema, desde que sua consulta tente buscar seus dados para inserir em sua tabela temporária. Se você usar uma cláusula where que óbvia não retornará nenhuma linha ou a sintaxe de criação de tabela, os bloqueios serão mantidos por um curto período de tempo.

/ Håkan Winther

    
por 25.06.2009 / 08:29