Eu tenho uma tabela em uma Instância SQL do Azure (12.0.2000.8) e encontrei esse comportamento estranho ao consultá-la.

A coluna é definida como Integer, mas não responde aos filtros "WHERE", também a conversão para varchar retorna resultados estranhos. Isso só acontece em uma tabela (até agora).

O que esta acontecendo aqui? é um bug? Estou fazendo algo errado? Devo descartar a tabela e criá-la novamente?

Mais informações: O problema acontece quando eu consulto a tabela. Se eu usar máquinas e clientes diferentes, tenho o mesmo problema (acontece com o JDBC também).

O agrupamento é SQL_Latin1_General_CP1_CI_AS

Obrigado!

Estou procurando um termo genérico, por exemplo, para uma abstração de banco de dados, que inclui todas as estruturas de dados tabulares, como tabelas de banco de dados, exibições, resultados de consultas tabulares também.

Pelo que entendi, 'entidade' não é o termo adequado, pois corresponderia a uma tabela, mas não a uma exibição ou mesmo a uma consulta. 'Resultado' seria contra-intuitivo em estruturas de dados modificáveis.

Qual seria o termo adequado no ambiente profissional?

Problema

Habilitamos sp_configure 'tempdb metadata memory-optimized' = 1, e agora os metadados tempdb estão ocupando mais de 400 GB em um de nossos servidores e continuam crescendo. Há algumas quedas no uso de memória, mas geralmente continua crescendo o uso de memória. Tivemos algumas vezes em que o servidor realmente trava porque não há memória suficiente para os outros processos do sistema modificarem o tempdb e isso desativa todo o servidor.

Pergunta que estou fazendo

Como faço para impedir que os metadados tempdb otimizados na memória do SQL Server cresçam continuamente e travem meu servidor? Se alguma coisa, quais são algumas outras informações que posso analisar para descobrir o que está consumindo tanta memória?

Dados sobre o problema

sys.dm_os_memory_clerks

A consulta a seguir retorna atualmente 438 GB.

SELECT SUM(domc.pages_kb / 1024.0 / 1024.0) AS pages_gb
FROM sys.dm_os_memory_clerks AS domc
WHERE domc.type LIKE 'MEMORYCLERK_XTP'

sys.dm_db_xtp_memory_consumers

A consulta a seguir fornece os dados de que o maior uso de memória (290 GB) é memory_consumer_id de 113 - 'LOB Page Allocator'. Ele não tem object_id ou xtp_object_id, então estou supondo que é um objeto de banco de dados.

SELECT ddxmc.memory_consumer_id
     , ddxmc.memory_consumer_type_desc
     , ddxmc.memory_consumer_desc
     , ddxmc.object_id
     , ddxmc.xtp_object_id
     , ddxmc.used_bytes / 1024.0 / 1024.0 / 1024.0 AS used_gb
FROM sys.dm_db_xtp_memory_consumers AS ddxmc
ORDER BY ddxmc.allocated_bytes DESC

Meio Ambiente

Versão: SQL Server 2019 CU9 -
Memória corporativa na caixa: 3 TB
Tipo de instância: Instância em cluster de failover
SO: Windows Server 2019 Standard
Número de núcleos de CPU: 80 núcleos físicos (tivemos que aumentar esse número ultimamente) Número de Tempdb Arquivos: 64 Replicação: Este servidor é um editor e assinante de replicação transacional.

Padrões de uso

Somos usuários pesados ​​de tempdb. Estamos continuamente criando e descartando tabelas temporárias e variáveis ​​de tabela o tempo todo em procedimentos armazenados. Precisamos trabalhar com grandes quantidades de dados, passando listas de dados que depois transformamos em tabelas para trabalhar com dados do conjunto de resultados em vez de trabalhar com uma informação de cada vez. Devido à grande rotatividade no tempdb, tivemos que implementar o tempdb otimizado na memória para aliviar as esperas de PAGELATCH_* que estávamos enfrentando.

Tenho certeza de que NÃO existem tabelas de usuário otimizadas para memória. Quando executo a seguinte consulta, vejo apenas SYSTEM_TABLEobjetos de tipo:

SELECT *
FROM sys.dm_db_xtp_index_stats AS ddxis
    JOIN sys.objects AS o ON o.object_id = ddxis.object_id

Coisas que eu conheço e o que eu tentei

A coleta de lixo na memória só pode limpar itens mais antigos que a transação mais antiga.

Estou ciente de que a coleta de lixo só pode ocorrer em linhas mais antigas que a transação mais antiga e, portanto, parei todos os nossos trabalhos de longa execução do SQL Agent e quaisquer outros processos com mais de 5 minutos. Infelizmente, nosso uso de memória não voltou a cair. Temos sessões antigas, mas nenhuma delas tem transações abertas de acordo com a consulta a seguir.

SELECT *
FROM sys.dm_exec_sessions AS des
WHERE des.open_transaction_count > 0

Replicação

Para descartar a replicação, interrompi temporariamente os agentes de publicação e assinatura deste servidor. Nenhuma mudança no uso da memória.

Ponto de verificação

Eu executei 'CHECKPOINT' no tempdb. O uso de memória não caiu.

DBCC FREEPROCCACHE - Livrando-se de tabelas temporárias antigas

Para descartar tabelas temporárias antigas que estão sendo armazenadas em cache, limpei o cache do plano de consulta e verifiquei se as tabelas temporárias foram recriadas executando a consulta a seguir. Isso não resultou na queda do uso de memória em qualquer quantidade substancial.

SELECT *
FROM sys.tables AS t
WHERE t.name LIKE '#%'
    AND t.create_date < 'TimeOfClearingPlanCache'

Outras soluções possíveis

Reiniciando o SQL Server

Podemos reiniciar o SQL Server e isso atenua o problema por um tempo, mas o uso de memória aumenta novamente depois de um tempo. Embora seja uma solução alternativa, essa é uma solução terrível da qual não gostamos muito.

Desativando o 'Tempdb Otimizado na Memória'

Poderíamos desativar o 'tempdb otimizado na memória', mas então estaríamos sujeitos às esperas pesadas de PAGELATCH_* que estávamos experimentando antes. Temos 64 arquivos tempdb para ajudar a reduzir a contenção que estávamos vendo, mas mesmo isso não foi suficiente durante nossos tempos difíceis. Esta poderia ser uma opção, mas seria melhor se pudéssemos descobrir por que o uso de memória está crescendo continuamente.

Digamos que eu esteja executando um backup de log e esse backup de log leve 10 minutos para ser concluído. Durante essa janela de 10 minutos, outras transações são executadas. Dado o exemplo abaixo, quais transações o backup de log realmente contém?

1. A transação A confirma
2. A transação B é aberta
3. O backup de log começa
4. A transação C é aberta
5. Confirmações da transação B
6. Backup de log concluído
7. Confirmações da transação C

O tipo de agrupamento padrão no SQL Server permite a indexação em cadeias de caracteres que não diferenciam maiúsculas de minúsculas, mas as maiúsculas e minúsculas dos dados são mantidas. Como isso realmente funciona? Estou procurando as porcas e parafusos reais, bits e bytes, ou um bom recurso que explica isso em detalhes.

create table casetest (fruitnames nvarchar(50) not null);
create unique index IX_fruitnames on casetest(fruitnames);

insert into casetest values ('apples');
insert into casetest values ('Pears');
-- this insert fails
insert into casetest values ('pears');

-- this yields 'Pears' as a result
select * from casetest (forceseek) where fruitnames = 'PEARS'

update casetest set fruitnames = 'pears' where fruitnames = 'pEArs'

-- this yields 'pears' as a result
select * from casetest (forceseek) where fruitnames = 'PEARS'

Perguntas sobre agrupamentos do SQL Server que você era muito tímido para perguntar por Robert Sheldon aborda como usar o agrupamento. Ele não cobre como funciona o agrupamento. Estou interessado em como um índice pode ser criado/consultado com eficiência, sem se importar com o caso, enquanto armazena simultaneamente os dados do caso.

Como você desativa esse recurso irritante? Eu não quero que meu gerente de banco de dados resmungue para mim o mais alto que puder.

O que quero dizer é o seguinte:

Se criar um índice em uma tabela com nlinhas leva ttempo. A criação de um índice na mesma tabela 1000*nlevará aproximadamente um 1000*ttempo.

O que estou tentando alcançar é estimar o tempo necessário para criar o índice no banco de dados de produção, criando o mesmo índice no banco de dados de teste muito menor.

Como descubro se existe um procedimento ou função em um banco de dados mysql? e existe alguma opção de descoberta? como um show procedures;(por exemplo, como show tables;)

Encontrei um novo título chamado SQL Server "Denali" na lista suspensa do MSDN, mas não encontrei muitas informações sobre ele:

• O que há de novo (esta documentação é apenas para visualização como eu vejo)
• Os 9 principais novos recursos do SQL Server "Denali"

Alguém tem informações mais detalhadas sobre novos recursos ou correções de bugs significativas nesta versão? Espero que alguém tenha usado ou testado.

Novas características

• Sequências
• FILESTREAM estendido (graças a Eric Humphrey )
• OFFSET & FETCH (Cláusula ORDER BY)
• Alterações no gerenciador de memória

• Cláusula LAG (..) e LEAD (..) .. OVER (Partition By..Order By) (graças a gbn )

• lista de Aaron

O servidor é Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit

Existe uma maneira fácil e rápida de alterar os SIDs dos bancos de dados de teste no servidor?

Descartar e recriar o banco de dados é uma opção para mim. Mas estou procurando algo que exija menos tempo.

A outra opção para atribuir nomes nos clientes tnsnames.ora é propensa a erros, porque eles não são administrados centralmente.

Comparado com o tempo para descartar e criar um banco de dados no SQL-Server, o tempo necessário para criar um novo banco de dados Oracle é excessivamente maior. Mais adiante no SQL-Server você pode renomear instâncias do SQL-Server. [ Normalmente você renomeia o servidor onde o SQL-Server está rodando e tem alguns problemas até renomear o servidor também ].