Peter's questions

Eu tenho uma DELETEdeclaração em execução em uma tabela com uma coluna indexada de texto completo, um punhado de chaves estrangeiras cascadehabilitadas. Se parece com isso:

DELETE FROM dbo.STUDENTS WHERE STUDENTID=@STUDENTID

Ocasionalmente, é compilado um plano que inclui estimativas de linha muito altas para todas as operações de índice, de modo que DELETEleva muito tempo e causa bloqueio.

Eu tentei forçar um bom plano no QueryStore, mas isso não funciona, last forced plan failure descriptionmostrando NO_PLAN.

Assegurei-me de que não há alterações de esquema que possam invalidar o plano.

Olhando para o plano de execução, vejo que DELETEenvolve uma junção a uma tabela do sistema que contém o índice FT:

Essa associação ao índice FT significa que a imposição de plano não é suportada?

Eu herdei um grupo de disponibilidade e descobri que um servidor vinculado foi configurado entre os dois nós do grupo de disponibilidade. Ele está usando sapara autenticação, infelizmente.

Simultaneamente, alguns dos desenvolvedores da equipe usam sapara consultar o banco de dados ativo. Eu quero que isso pare.

Minha pergunta é:

Os servidores vinculados são exigidos de alguma forma pelos grupos de disponibilidade? Eu sei que tenho algumas partes móveis sob medida, como trabalhos de agente que usam o servidor vinculado para sincronizar trabalhos entre os dois nós. Estou mais preocupado com algo interno ao SQL Server que talvez eu não esteja ciente. Há algo de errado em apenas fazer a devida diligência normal e alterar o usuário do servidor vinculado para usar non-sa e também alterar a sasenha?

Eu tenho uma coluna xml que se parece com isso:

<document>
      <item>
        <key>
          <string>Michael Burry</string>
        </key>
        <value>
          <string>CDO</string>
        </value>
      </item>
      <item>
        <key>
          <string>Adam Smith</string>
        </key>
        <value>
          <string>£20</string>
        </value>
      </item>
      <item>
        <key>
          <string>World Cup 2018</string>
        </key>
        <value>
          <string>football</string>
        </value>
      </item>......

Em vez de listar todo o conteúdo da coluna, quero listar apenas o valor de <string>football</string>quando o primeiro valor for <string>World Cup 2018</string>.

O uso value('(/document/item/key/string)[7]', 'nvarchar(max)')não é adequado, pois "Copa do Mundo 2018" pode aparecer em qualquer lugar.

Esta manhã, foi recebido o seguinte alerta por e-mail:

DATA/HORA: 28/02/2018 09:26:42

DESCRIÇÃO: A tentativa de buscar a página lógica (1:3948712) no banco de dados 9 falhou. Pertence à unidade de alocação 72057594045857792 e não a 72059184917512192.

COMENTÁRIO: (Nenhum)

JOB RUN: SQL Sentry 2.0 Alert Trap

Olhando no log de eventos da réplica secundária, há três ocorrências da mesma mensagem:

Fonte spid138

Mensagem Tentativa de buscar página lógica (1:3948712) no banco de dados 9 falhou. Pertence à unidade de alocação 72057594045857792 e não a 72059184917512192.

Executando o seguinte na réplica secundária (grupo de disponibilidade síncrono de 2 nós):

DBCC TRACEON(3604)
dbcc page (9, 1,3948712,3)
go
DBCC TRACEOff(3604)

Trecho dos resultados de qualquer réplica:

Page @0x00000070DAB8C000

m_pageId = (1:3948712)              m_headerVersion = 1               
m_type = 3 m_typeFlagBits = 0x0                m_level = 0            
m_flagBits = 0x8200 m_objId (AllocUnitId.idObj) = 129   m_indexId
(AllocUnitId.idInd) = 256  Metadata: AllocUnitId = 72057594046382080  
Metadata: PartitionId = 72057594040811520                             
Metadata: IndexId = 1 Metadata: ObjectId = 197575742      
m_prevPage = 0:0)                  m_nextPage = (0:0) pminlen = 0                 
m_slotCnt = 2                       m_freeCnt = 1634 m_freeData = 6568
m_reservedCnt = 0                   m_lsn = (46041:1506360:18)
m_xactReserved = 0                  m_xdesId = (0:0)                  
m_ghostRecCnt = 0 m_tornBits = -99702035              DB Frag ID = 1

Executando o seguinte na réplica primária:

select OBJECT_NAME (197575742)

plan_persist_plan

Perguntas

1. Estou certo em dizer que tenho uma corrupção de índice clusterizado da plan_persist_plantabela que faz parte do Query Store?

2. É a melhor/única correção para executar o seguinte:

   ALTER DATABASE MyDatabase SET QUERY_STORE CLEAR; 
   

3. Se o nº 2 for a melhor correção, existe alguma boa maneira de preservar os dados no Query Store que seriam excluídos?

4. Esse tipo de corrupção indica um problema com o subsistema de E/S?

Outras informações

• Eu tenho o QueryStore ativado obviamente, ele tem uma capacidade de 350 MB, está no modo Read-Write atualmente, intervalo de liberação de 15 minutos, coleta de estatísticas por hora, modo de captura TODOS, limpeza baseada em tamanho automático, limite de consulta obsoleto de 5 dias.
• DB id 9 é um banco de dados de usuários críticos para os negócios
• Os detalhes do erro são Erro: 605, Gravidade: 21, Estado: 3.

Verifiquei o log de eventos do sistema Windows conforme as orientações . Isso gerou apenas eventos "informativos", sem erros.

DBCC CHECKTABLE ('sys.plan_persist_plan');  

resultados:

DBCC results for 'sys.plan_persist_plan'.
There are 12562 rows in 240 pages for object "sys.plan_persist_plan". 
DBCC execution completed. 
If DBCC printed error messages, contact your system administrator.

Não consigo estabelecer o comando correto para reconstruir o índice, o seguinte não funciona:

ALTER INDEX PK_plan_persist_plan_cidx ON sys.plan_persist_plan REBUILD;

Eu tenho uma consulta que envolve uma pesquisa de texto completo como esta:

SELECT TOP 30 PersonId,
              PersonParentId,
              PersonName,
              PersonPostCode
FROM dbo.People
WHERE PersonDeletionDate IS NULL
      AND PersonCustomerId = 24
      AND CONTAINS(ContactFullText, '"mr" AND "ch*"')
      AND PersonGroupId IN(197, 206, 186, 198)
ORDER BY PersonParentId,
         PersonName;

Isso gera dois planos principais, um é muito rápido em todos os casos, o outro é muito lento na maioria dos casos.

Eu experimentei essa consulta de modo que a pesquisa do FT não seja incluída e o que descobri é que as estimativas de linha são sempre muito menores do que deveriam.

Se eu executar update statistics...with fullscan, ainda vejo estimativas de linha extremamente imprecisas das operações de busca do índice NC no plano de execução.

Quando as estimativas de linha são baixas o suficiente, uma junção de loop é selecionada, o que normalmente é muito lento (mais de 30 segundos). Estimativas mais altas parecem produzir um bom plano envolvendo uma junção de mesclagem em vez de uma junção de loop.

Por que o SQL Server ainda não estima as contagens de linhas, apesar de ainda ter estatísticas atualizadas?

O plano: https://www.brentozar.com/pastetheplan/?id=rkXtE0jzX

Quando removo a CONTAINSparte, omitindo assim a pesquisa FullText, a consulta é rápida, mas a estimativa de linha para a busca de índice ainda é 1 estimada, 2195 reais.

Seguindo o conselho de @Kin, usei CONTAINSTABLE, que funcionou instantaneamente e produziu o seguinte plano: https://www.brentozar.com/pastetheplan/?id=S1hKainzQ Interessante que não existe um operador de pesquisa Full Text.

O Containstable requer RANKpara produzir o mesmo conjunto de resultados neste caso que usei AND RANK > 0no WHEREpara produzir os resultados que quero, que produz este plano: https://www.brentozar.com/pastetheplan/?id=B1U7AA2zm

Minha única pergunta agora é sobre por que as estimativas de linha ainda são imprecisas, mas me importo menos agora que minhas consultas FT parecem significativamente mais rápidas e confiáveis. Muito satisfeito! https://www.brentozar.com/pastetheplan/?id=B1U7AA2zm

@EvanCarroll histograma de estatísticas aqui: https://pastebin.com/p7s0NvX5

Algumas informações de acompanhamento - planos de execução antes/depois de algumas consultas de pesquisa típicas do FT para o aplicativo que está sendo suportado

UMA

1. Antes: https://www.brentozar.com/pastetheplan/?id=SJlAAAN7X (5 segundos)
2. Depois: https://www.brentozar.com/pastetheplan/?id=H1ltkkSmm (<1 segundo)

B

1. Antes: https://www.brentozar.com/pastetheplan/?id=Sy-gxJBQm (40 segundos)
2. Depois: https://www.brentozar.com/pastetheplan/?id=Sy2VxJrm7 (1 segundo)

C

1. Antes: https://www.brentozar.com/pastetheplan/?id=r1z5e1rQ7 (2 segundos)
2. Depois: https://www.brentozar.com/pastetheplan/?id=r1oplkSQm (<1 segundo)

D

1. Antes: https://www.brentozar.com/pastetheplan/?id=B1kHf1BQQ (2 minutos e 20 segundos)
2. Depois: https://www.brentozar.com/pastetheplan/?id=r1D5z1SQm (11 segundos)

Recentemente, notei que o aplicativo da minha empresa estava usando AddWithValuepara passar valores de parâmetros para consultas dinâmicas e parametrizadas. Exemplo:

cmd.Parameters.AddWithValue("@VehicleId", Vehicles.VehicleId);

No banco de dados, o tipo de dados para VehicleIDé INT.

Pelo que entendi, como AddWithValue (que está obsoleto) não especifica o tipo/comprimento de dados, este '@VehicleID' é convertido e potencialmente convertido incorretamente. Essa conversão afeta o desempenho do SQL Server no caso de um 'INT'?

Isso causaria problemas além da poluição do cache do plano? Há um impacto no desempenho causado pela conversão?

falha de login para o usuário 'domain\localMachineName$'. Motivo: não foi possível encontrar um login correspondente ao nome fornecido. [CLIENTE: ]

Isso apareceu no meu novo SQL Server logo após adicioná-lo a um cluster do Windows existente. Ocorre exatamente a cada 5 minutos. Parece que um recurso local está tentando fazer login, mas não consigo ver com o que ele pode estar relacionado.

Se eu particionar uma tabela com ntext, textou tipos de imagedados e reconstruir um índice em uma única partição com online = off, isso bloqueará a tabela inteira ou apenas a partição em questão?

Grupo de disponibilidade Always On com dois nós, confirmação síncrona.

A contenção de thread de redo na réplica secundária cria regularmente uma fila de redo muito grande. Confirmei que os tipos de espera são semelhantes aos seguintes:

https://blogs.msdn.microsoft.com/alwaysonpro/2015/01/06/troubleshooting-redo-queue-build-up-data-latency-issues-on-alwayson-readable-secondary-replicas-using-the- wait_info-extended-event/

No meu caso, esta é uma saída de sessão de eventos estendida (capturada quando a fila de refazer era grande) agrupada e agregada como no link acima:

Minha pergunta:

Como posso descobrir a origem exata da operação DDL que está causando a espera LCK_M_SCH_M?

Tenho uma tabela assim:

Lat1 Lng1 Lat2 Lng2
---- ---- ---- ----
1 1 2 2
2 2 5 5
3 3 4 4
4 4 3 3
5 5 4 4

É possível retornar as linhas na seguinte ordem?

Lat1 Lng1 Lat2 Lng2
---- ---- ---- ----
1 1 2 2
2 2 5 5
5 5 4 4
4 4 3 3
3 3 4 4

Existe uma rowidcoluna única.

Os pares (Lat1,Lng1)e (Lat2,Lng2)sempre serão únicos.

lat1e long1de linha n+1deve ser igual a lat2e long2de linha n.

Recentemente, assumi a administração de um grupo de disponibilidade composto por dois nós, modo de confirmação síncrona.

A configuração do grupo fica assim:

Meu entendimento é que, com a opção Readable Secondary definida como Yesem ambas as réplicas, qualquer string de conexão com applicationIntent=ReadOnly será roteada para Node1.

Da mesma forma, se eu alterar a opção Readable Secondary do Node2 para 'Read-intent', qualquer string de conexão com applicationIntent=ReadOnly será roteada para o Node2.

Por que, então, essa string de conexão é roteada para o Node2 quando ambos os nós estão definidos como 'Readable Secondary = Yes':

'Fonte de dados=editado.domínio.com; Catálogo Inicial= MeuBanco de Dados; ApplicationIntent=ReadOnly; ID do usuário=Usuário; Senha=********; MultiSubnetFailover=True'

Basicamente, alterar o parâmetro 'ReadOnly' para 'ReadWrite' faz com que a conexão vá para Node1. Alterar de volta para 'ReadOnly' faz com que a conexão seja roteada para o Node2. Como isso é possível sem a opção 'Readable Secondary= Read-intent'?

EDIT: saída de SELECT ag.name as "Availability Group", ar.replica_server_name as "When Primary Replica Is", rl.routing_priority as "Routing Priority", ar2.replica_server_name as "RO Routed To", ar.secondary_role_allow_connections_desc, ar2.read_only_routing_url FROM sys.availability_read_only_routing_lists rl inner join sys.availability_replicas ar on rl.replica_id = ar.replica_id inner join sys.availability_replicas ar2 on rl.read_only_replica_id = ar2.replica_id inner join sys.availability_groups ag on ar.group_id = ag.group_id ORDER BY ag.name, ar.replica_server_name, rl.routing_priority

Para qualquer pessoa que precise de ajuda para entender isso, achei o seguinte útil:

Grupo de disponibilidade Always On de dois nós, uma réplica síncrona.

Minha réplica síncrona fica fora de sincronia com muita regularidade. Vejo um padrão em que, quando ocorre um backup de log na réplica secundária, ocorrerá um curto período de atraso durante o qual o redo_queue_size é preenchido rapidamente, assim:

Observando a orientação no link a seguir, parece que meu problema se deve principalmente à contenção que o thread de redo experimenta ao tentar proteger as transações:

https://technet.microsoft.com/en-us/library/dn135335(v=sql.110).aspx

A réplica fica ainda mais fora de sincronia quando um backup de log de transações é executado e esse problema é agravado pelos relatórios executados na réplica secundária também.

O tempo todo, meus backups de log de transações são enormes - em média 1,2 GB, mas podem ser maiores.

Até onde sei, meus backups de log serão grandes porque tenho o TDE habilitado no banco de dados, mas realmente não esperava que fossem tão grandes. Suspeito que isso seja o que mais contribui para as confirmações lentas na réplica secundária.

Existem contadores de desempenho recomendados para diagnosticar confirmações lentas em uma réplica síncrona? O que mais posso fazer para validar minha teoria?

Meu problema parece ser o mesmo descrito aqui: https://www.sqlservercentral.com/Forums/1871286/AlwaysOn-Missing-Redo-Thread

Posso apenas habilitar esse sinalizador de rastreamento na réplica secundária ou ele precisa ser aplicado a ambos os nós?

EDIT: verifiquei a fila de refazer às 6 da manhã e encontrei um número enorme, com um tempo de recuperação de 15 a 20 minutos e aumentando um pouco o tempo todo. Em seguida, apliquei o traceflag DBCC TRACEON (3459, -1)e descobri que, após alguns minutos, o número de comandos de refazer caiu extremamente rapidamente. Até agora, o problema parece ter sido mitigado por esse sinalizador de rastreamento, mas presumivelmente isso colocará todas as transações protegidas no log da réplica secundária no modo de thread único, como o SQL Server 2014 e, portanto, ainda há potencial para a réplica secundária ficar para trás como resultado do encadeamento não paralelo, quando o primário está sob carga de gravação pesada.

Eu tenho um AG de 2 nós com uma réplica síncrona. Desejo saber se posso adicionar com segurança outro banco de dados ao nó de réplica síncrona, sem adicioná-lo ao Grupo de Disponibilidade.

Fazer isso traz alguma ressalva?

Estive debatendo com o fornecedor de aplicativos da minha empresa sobre paralelismo. Eles sustentaram que Maxdop = 1 tem melhorias significativas de desempenho para o app/db, mas não forneceram absolutamente nenhuma prova disso.

Eu testei várias configurações de DOP/CT e encontrei uma melhoria geral de desempenho de 28% em testes automatizados, ao usar Maxdop 4 (8 núcleos hyperthreaded) e CT 150.

O DBA do fornecedor disse recentemente: "Há um problema com os processos internos do MSSQL que são capazes de usar esse valor mesmo que o DOP seja '1', há SPIDs menores que 51 em um servidor MSSQL que o está usando, limpezas fantasmas e afins isto."

Eu pesquisei isso e, apesar das informações bastante escassas, Paul Randall pelo menos diz que a limpeza fantasma é sempre de thread único, então, aparentemente, o dba do fornecedor está incorreto?

Alguma opinião sobre o efeito da TC quando Maxdop =1?

Entendo que o SQL Server 2005 não oferece suporte DATEe, portanto, não é possível converter uma data e hora como uma data.

O que eu quero fazer é listar todos os registros com data e hora em um dia inteiro da semana atual.

Portanto, preciso de todos os registros criados na segunda-feira da semana atual, ignorando o carimbo de data e hora. Atualmente, estou usando o seguinte, que mostra de segunda a sexta-feira da semana atual, mas inclui o carimbo de data/hora, o que significa que verei resultados diferentes dependendo de quando a consulta for executada:

set datefirst 1

select 
    DATEADD(day, 1 - DATEPART(dw, GETDATE()), CONVERT( DATETIME, GETDATE())) as Monday,
    DATEADD(day, 2 - DATEPART(dw, GETDATE()), CONVERT( DATETIME, GETDATE())) as Tuesday,
    DATEADD(day, 3 - DATEPART(dw, GETDATE()), CONVERT( DATETIME, GETDATE())) as wednesday,
    DATEADD(day, 4 - DATEPART(dw, GETDATE()), CONVERT( DATETIME, GETDATE())) as Thursday,
    DATEADD(day, 5 - DATEPART(dw, GETDATE()), CONVERT( DATETIME, GETDATE())) as Friday

Alguém pode ajudar?

Minha saída esperada seria uma coluna para cada dia da semana atual, onde a semana começa na segunda-feira (ou seja: Datefirst 1). Por fim, vou usá-lo em uma declaração de caso como:

CASE
WHEN DateColumn >= DATEADD(day, 1 - DATEPART(dw, GETDATE()), CONVERT( DATETIME, GETDATE())) and DateColumn < DATEADD(day, 2 - DATEPART(dw, GETDATE()), CONVERT( DATETIME, GETDATE()))
THEN IntegerColumn
ELSE 0
END AS Monday

...Repetindo para cada dia da semana. Preciso acomodar os valores IntegerColumn que são adicionados ao longo da segunda-feira. Se nenhuma entrada DateColumn ocorrer nas horas de segunda-feira, um zero será exibido.

Minha empresa usa um aplicativo que apresenta problemas de desempenho bastante importantes. Há uma série de problemas com o próprio banco de dados que estou trabalhando, mas muitos dos problemas são puramente relacionados ao aplicativo.

Em minha investigação, descobri que existem milhões de consultas no banco de dados do SQL Server que consultam tabelas vazias. Temos cerca de 300 tabelas vazias e algumas dessas tabelas são consultadas até 100-200 vezes por minuto. As tabelas não têm nada a ver com a nossa área de negócios e são essencialmente partes do aplicativo original que o fornecedor não removeu quando foi contratado pela minha empresa para produzir uma solução de software para nós.

Além do fato de suspeitarmos que nosso log de erros do aplicativo está sendo inundado com erros relacionados a esse problema, o fornecedor nos garante que não há impacto no desempenho ou na estabilidade do aplicativo ou do servidor de banco de dados. O log de erros é inundado na medida em que não podemos ver mais de 2 minutos de erros para fazer diagnósticos.

O custo real dessas consultas obviamente será baixo em termos de ciclos de CPU, etc. Mas alguém pode sugerir qual seria o efeito no SQL Server e no aplicativo? Eu suspeitaria que a própria mecânica de enviar uma solicitação, confirmá-la, processá-la, devolvê-la e confirmar o recebimento pelo aplicativo teria um impacto no desempenho.

Usamos SQL Server 2008 R2, Oracle Weblogic 11g para o aplicativo.

@Frisbee- Para encurtar a história, criei uma tabela contendo o querytext que atingiu as tabelas vazias no banco de dados do aplicativo e, em seguida, consultei todos os nomes de tabelas que sei que estão vazios e obtive uma lista muito longa. O maior sucesso foi de 2,7 milhões de execuções em 30 dias de tempo de atividade, tendo em mente que o aplicativo geralmente é usado das 8h às 18h, portanto esses números estão mais concentrados no horário operacional. Várias tabelas, várias consultas, provavelmente algumas relevantes por meio de junções, outras não. O maior sucesso (2,7 milhões na época) foi uma simples seleção de uma única tabela vazia com uma cláusula where, sem junções. Eu esperaria que consultas maiores com junções às tabelas vazias pudessem incluir atualizações para tabelas vinculadas, mas verificarei isso e atualizarei esta pergunta o mais rápido possível.

Atualização: Existem 1000 consultas com uma contagem de execução entre 1043 - 4622614 (mais de 2,5 meses). Terei que cavar mais para descobrir de onde o plano em cache se origina. Isso é apenas para lhe dar uma ideia da extensão das consultas. A maioria é razoavelmente complexa com mais de 20 junções.

@srutzky- sim, acredito que haja uma coluna de data relacionada a quando o plano foi compilado para que seja interessante, então vou verificar isso. Eu me pergunto se os limites de thread seriam um fator quando o SQL Server fica em um cluster VMware? Em breve será um Dell PE 730xD dedicado, felizmente.

@Frisbee - Desculpe pela resposta tardia. Como você sugeriu, executei um select * da tabela vazia 10.000 vezes em 24 threads usando SQLQueryStress (na verdade, 240.000 iterações) e atingi 10.000 solicitações de lote/s imediatamente. Em seguida, reduzi para 1.000 vezes em 24 threads e atingi pouco menos de 4.000 solicitações de lote/seg. Também tentei 10.000 iterações em apenas 12 threads (portanto, 120.000 iterações no total) e isso produziu 6.505 lotes/s sustentados. O efeito na CPU foi realmente perceptível, cerca de 5-10% do uso total da CPU durante cada execução de teste. As esperas de rede foram insignificantes (como 3 ms com o cliente em minha estação de trabalho), mas o impacto da CPU estava lá com certeza, o que é bastante conclusivo no que me diz respeito. Parece resumir-se ao uso da CPU e um pouco de arquivo de banco de dados desnecessário IO. O total de execuções/segundo chega a pouco menos de 3.000, o que é mais do que em produção, porém estou testando apenas uma das dezenas de consultas como esta. O efeito líquido de centenas de consultas atingindo tabelas vazias a uma taxa entre 300 e 4.000 vezes por minuto, portanto, não seria desprezível quando se trata de tempo de CPU. Todos os testes foram feitos em um PE 730xD inativo com dual flash array e 256 GB de RAM, 12 núcleos modernos.

@srutzky- bom pensamento. SQLQueryStress parece usar o pool de conexões por padrão, mas eu dei uma olhada de qualquer maneira e descobri que sim, a caixa para pool de conexões está marcada. Atualização a seguir

@srutzky- O pool de conexões aparentemente não está ativado no aplicativo - ou, se estiver, não está funcionando. Fiz um rastreamento do profiler e descobri que as conexões têm EventSubClass "1 - Nonpooled" para eventos de login de auditoria.

RE: Pool de conexão - verifiquei o weblogics e encontrei o pool de conexão ativado. Executei mais rastreamentos ao vivo e encontrei sinais de agrupamento que não estava ocorrendo corretamente/de forma alguma:

E aqui está o que parece quando executo uma única consulta sem junções em uma tabela preenchida; as exceções diziam "Ocorreu um erro relacionado à rede ou específico da instância ao estabelecer uma conexão com o SQL Server. O servidor não foi encontrado ou não estava acessível. Verifique se o nome da instância está correto e se o SQL Server está configurado para permitir conexões remotas. (provedor: Provedor de pipes nomeados, erro: 40 - Não foi possível abrir uma conexão com o SQL Server)" Observe o contador de solicitações em lote. Fazer ping no servidor durante o tempo em que as exceções são geradas resulta em uma resposta de ping bem-sucedida.

Atualização - duas execuções de teste consecutivas, mesma carga de trabalho (selecione*fromEmptyTable), pool ativado/desativado. Um pouco mais de uso da CPU e muitas falhas e nunca ultrapassa 500 solicitações em lote/seg. Os testes mostram 10.000 lotes/s e nenhuma falha com o pool ativado, e cerca de 400 lotes/s e muitas falhas devido à desativação do pool. Será que essas falhas estão relacionadas a falta de disponibilidade de conexão?

@srutzky- Selecione Count(*) em sys.dm_exec_connections;

• Pooling ativado: 37 de forma consistente, mesmo após o teste de carga parar

• Pooling desabilitado: 11-37, dependendo se as exceções estão
  ocorrendo ou não no SQLQueryStress, ou seja: quando essas depressões aparecem no
  gráfico de Lotes/seg, as exceções ocorrem no SQLQueryStress e o
  número de conexões cai para 11, depois volta gradualmente para 37 quando os lotes começam a atingir o pico e as exceções não estão ocorrendo. Muito, muito interessante.

Conexões máximas em ambas as instâncias de teste/ativas definidas no padrão de 0.

Verifiquei os logs do aplicativo e não consegui encontrar problemas de conectividade, no entanto, há apenas alguns minutos de log disponíveis devido ao grande número e tamanho dos erros, ou seja: muitos erros de rastreamento de pilha. Um colega do suporte de aplicativos informa que ocorre um número substancial de erros de HTTP relacionados à conectividade. Com base nisso, parece que, por algum motivo, o aplicativo não está agrupando corretamente as conexões e, como resultado, o servidor está ficando sem conexões repetidamente. Vou examinar mais os logs do aplicativo. Gostaria de saber se existe uma maneira de provar que isso está acontecendo na produção do lado do SQL Server?

@srutzky- Obrigado. Vou verificar a configuração do weblogic amanhã e atualizar. Eu estava pensando nas meras 37 conexões - se SQLQueryStress está fazendo 12 threads em 10.000 iterações = 120.000 instruções select não agrupadas, isso não deveria significar que cada select cria uma conexão distinta com a instância sql?

@srutzky- Weblogics estão configurados para agrupar conexões, então deve estar funcionando bem. O pool de conexões é configurado assim, em cada um dos 4 weblogics com balanceamento de carga:

• Capacidade Inicial: 10
• Capacidade Máxima: 50
• Capacidade Mínima: 5

Quando eu aumento o número de threads que executam a seleção da consulta de tabela vazia, o número de conexões atinge o pico em torno de 47. Com o pool de conexões desabilitado, vejo consistentemente um número máximo de solicitações de lote por segundo (de 10.000 para cerca de 400). O que acontecerá sempre é que as 'exceções' em SQLQueryStress ocorrem logo após os lotes/s entrarem em um vale. Está relacionado à conectividade, mas não consigo entender exatamente por que isso está acontecendo. Quando nenhum teste está sendo executado, #connections cai para cerca de 12.

Com o pool de conexões desativado, estou tendo problemas para entender por que as exceções ocorrem, mas talvez seja uma outra pergunta/pergunta stackExchange para Adam Machanic?

@srutzky Eu me pergunto então por que as exceções ocorrem sem o pooling ativado, mesmo que o SQL Server não esteja ficando sem conexões?

Alguém pode me dizer por que isso não vai funcionar para mim?

CREATE TABLE #UndistributedCmds
(
pendingcmdcount int,
estimatedprocesstime INT
)
INSERT INTO #UndistributedCmds

EXEC sp_replmonitorsubscriptionpendingcmds ...

O erro:

Msg 8164, nível 16, estado 1, procedimento sp_replmonitorsubscriptionpendingcmds, linha 152
Uma instrução INSERT EXEC não pode ser aninhada.

O erro parece implicar que a linha 152 da definição do procedimento armazenado é o problema, mas estou tendo problemas para entender isso. Isso está acontecendo porque o próprio procedimento armazenado tem vários procedimentos armazenados dentro dele?

Recentemente, restaurei um banco de dados para a mesma instância da qual foi feito o backup (SQL Server 2008 R2 Enterprise) e descobri que não conseguia acessar as propriedades do banco de dados.

Eu tenho feito o seguinte:

• Verificado se o proprietário do banco de dados foi definido corretamente usando sp_helpdb.
• Alterado o proprietário do banco de dados para sa. Não é uma correção.
• Mudou o proprietário do banco de dados de volta para o meu sysadminusuário. Não é uma correção.
• Emitido DBCC updateusageem relação ao banco de dados afetado. Não é uma correção.
• Execute DBCC CheckDBem uma cópia restaurada para outra instância. Nenhuma corrupção encontrada. A cópia restaurada (do mesmo arquivo de backup) não gerou nenhum erro ao acessar a janela de propriedades do banco de dados.

Alguém pode ajudar?

A mensagem de erro que recebo ao tentar visualizar as propriedades é:

Não é possível mostrar a caixa de diálogo solicitada. (SqlMgmt)
O tamanho da propriedade não está disponível para o banco de dados '[DBNAME]'.
Esta propriedade pode não existir para este objeto ou pode não ser recuperável devido a direitos de acesso insuficientes. (Microsoft.SqlServer.Smo)

Eu sou um sysadminnesta instância.

Atualização: Como sugerido, criei um novo usuário, tornei-o sysadmin e alterei o proprietário do banco de dados para ele. Não é uma correção infelizmente. Vou ver se um rastreamento de profiler produz algo útil.

Atualização: Aaron - o banco de dados original foi renomeado e colocado offline, mas ainda está nessa instância. O backup desse banco de dados foi então restaurado usando o nome original. Os nomes de arquivo dos novos arquivos de banco de dados são diferentes do original, pois estão na mesma pasta que o mdf/ldf original. O banco de dados restaurado está conduzindo nossos aplicativos críticos normalmente.

Quando o otimizador de consulta calcula o custo de um plano de execução, você pode esperar que o plano seja diferente dependendo da quantidade de recursos disponíveis para ele?

Considere o seguinte cenário:

• Você tem uma máquina virtual VMware executando o SQL Server 2008 R2 com 32 GB de RAM, 8 núcleos de CPU conectados a uma SAN. Existem 7 VMs compartilhando a caixa do host.
• Você descobre que o uso da CPU atinge um pico de 130% regularmente, então você move a maioria das VMs para fora do host, deixando apenas 3 das 7 VMs originais, incluindo a caixa do SQL Server.
• Você descobre imediatamente que o desempenho real é mais lento agora que há mais espaço de CPU disponível para ele. Você pode ver que a utilização da CPU no convidado está muito maior (porque mais recursos da CPU estão disponíveis para uso) do que os 30% que poderia reunir antes. Apesar disso, os usuários do aplicativo percebem uma desaceleração acentuada no desempenho.

Minha interpretação de por que uma VM SQL tem um desempenho mais lento quando mais recursos de CPU estão disponíveis para ela é que o cache de procedimento contém planos calculados abaixo/otimizados para um ambiente com menos disponibilidade de CPU. Quando o recurso extra estiver disponível, o cache de procedimento fornecerá planos abaixo do ideal que podem ter um desempenho inferior.

Isso faz sentido? Tivemos esse cenário exato algumas semanas atrás e recebemos muitas reclamações sobre o desempenho assim que interrompemos a surra da CPU no host. Executei o dbcc freeprocache e, a partir daí, o desempenho pareceu melhorar - ou isso ou os usuários se acostumaram com isso.

Pensamentos? Obrigado

SQL Server 2005, estou vendo cerca de 100 'trabalhos' no nó SQL Agent>jobs no SSMS. Eles aparecem como strings hexadecimais não com seus nomes reais:

Se eu consultar msdb..sysjobs, vejo uma lista muito menor de trabalhos e seu JobName correspondente.

Então, quais são esses trabalhos e como posso fazê-los aparecer como o nome real do trabalho em oposição ao JobID?

Obrigado, Pedro