Em relação à consulta abaixo que executo em um servidor físico com SQL Server 2019:
SELECT
memory_node_id,
SUM(pages_kb) / 1024.0/1024 AS TotalMemoryGB
FROM sys.dm_os_memory_clerks
GROUP BY memory_node_id
ORDER BY memory_node_id;
pois memory_node_id = 0mostra mais memória do que a disponível fisicamente no nó NUMA. Como pode ser?
Instalei um SQL Server 2022 Developer Edition em uma instância EC2 com Windows Server 2022 e instalei a atualização cumulativa mais recente (16.0.4115.5). Quando executo o DBCC TRACESTATUS, há 39 sinalizadores de rastreamento globais ativados e não consegui encontrar informações sobre nenhum deles em nenhum lugar, por exemplo, 4511. Não há sinalizadores de rastreamento como parâmetros de inicialização.
Na instalação eu escolho índices Fulltext e Polybase como recursos extras.
Se eu desligar todos os sinalizadores de rastreamento e reiniciar o servidor, eles serão ativados novamente automaticamente.
O que são esses sinalizadores de rastreamento? Parte da atualização cumulativa? Por que não consigo encontrar nenhuma informação sobre nenhum deles?
Quais são as razões pelas quais o otimizador escolhe inserir um operador de classificação no plano (para satisfazer uma agregação de fluxo ou uma junção de mesclagem, etc.) em vez de ir para correspondência de hash ou junção de hash?
Agora, vejo alguns exemplos em que obviamente comete um erro e insinuar que a consulta a tornará muito mais rápida.
Os exemplos que vi são do SQL Server 2016.
É possível que um AG abranja dois clusters de failover WSFC diferentes, ou seja, um dos nós faz parte de outro cluster de failover WSFC.
Então é possível que uma das réplicas esteja hospedada em um nó que não faz parte do cluster? Em outras palavras, uma réplica pode ser configurada como uma réplica em escala de leitura que não faz parte do cluster (mas talvez faça parte de outro cluster).
As versões do SQL Server são 2019.
O que acontece se a unidade (não a unidade C) onde os binários SQL estão localizados ficar sem espaço? Isso pode derrubar um servidor de produção?
Como posso consultar se uma instância é um secundário legível em um AG? Por exemplo, para verificar se a instância é primária para um AG, podemos usar: select sys.fn_hadr_is_primary_replica('AGDatabase'). Existe uma verificação semelhante para um secundário legível?
Eu estava executando alter index reorganizeem alguns índices columnstore no SQL Server 2016 e recebi uma mensagem de impasse.
Será reorganizesempre a vítima? Porque não quero fazer com que outros trabalhos falhem e estou pensando em adicionar um arquivo set deadlock_priority. Ou isso é embutido para a alter indexdeclaração?
Eu gostaria de ETL uma tabela de uma instância do SQL Server para outra instância do SQL Server. Não quero criar um pacote SSIS. eu tentei
SELECT INTO #Hello FROM MyExternalTable).SELECT * INTO #HELLO FROM MyLinkedServer.MyDB.dbo.MyTableOPENROWSET.Todos eles são executados em thread único, o que posso ver nos planos de execução. Eu não usei bcp, mas parece que primeiro preciso salvar a tabela em um arquivo e depois lê-la do arquivo e carregá-la. Portanto, não acho que seja a ferramenta correta para essa tarefa. Qual é a abordagem mais rápida para copiar uma tabela de uma instância do SQL Server para outra instância do SQL Server?
É possível fazer failover para um secundário legível (que sempre tem um modo de confirmação assíncrona) usando FORCE_FAILOVER_ALLOW_DATA_LOSS?
Desejo criar um banco de dados em uma réplica secundária não legível para coletar alguns dados para solução de problemas e monitoramento do AG. Li que não há custo de licença quando o servidor não é consultado (ou seja, quando a instância não é um secundário legível), mas o servidor precisa ser licenciado quando você o consulta.
Então minha pergunta é: Existe algum problema em criar um banco de dados separado em uma réplica secundária (obviamente o banco de dados não será incluído no AG)?
Como é determinada a concessão de memória para um DBCC checkdb (além do tamanho máximo para concessões de memória que é do administrador de recursos, possivelmente o pool padrão)?
Não estou tentando resolver um problema específico. Estou apenas curioso e tentando entender.
Qual é a fórmula para calcular o tamanho máximo do buffer pool (cache de dados) para SQL Server (quando houver apenas uma instância da máquina).
Digamos que a máquina tenha 1 GB de memória física, qual é o tamanho máximo do buffer pool nesse cenário?
Suponha que a memória máxima do servidor seja 0.
A pergunta surgiu ao ler sobre concessões de memória e li que o semáforo de recurso pode usar 75% do buffer pool para concessões de memória de consulta. Então a pergunta natural é como o buffer pool é calculado.
Obrigado
O registro de log para modificações de dados no log de transações: contém apenas os estados antes e depois das linhas e colunas afetadas ou contém os estados antes e depois de todas as colunas (para as linhas afetadas), ou seja, o log registro contém a linha inteira ou apenas parte da linha que é modificada?
Obrigado
Edit: agora criei um experimento e parece que o número de colunas na tabela não afeta o tamanho do log de transações para modificações de dados, ou seja, se eu atualizar col2em uma tabela então não importa se a tabela tem 5 colunas ou 100 colunas, o crescimento do log de transações será o mesmo.
Eu preciso dessa montagem Microsoft.SqlServer.RuntimeWrapper.dlle ela não está em <drive>:\Windows\Microsoft.NET\assembly. Eu tenho o SQL Server 2019 instalado (Developer Edition). De acordo com o link desta página os assemblies também devem estar nesta pasta: <drive>:\Program Files\Microsoft SQL Server\100\SDK\Assemblies.Mas no meu computador não tenho a pasta 100. Existem 80, 90, 110, 130, 150, Client SDK e MSSQL15.MSSQLSERVER. Acho que marquei as caixas relevantes ao escolher os recursos.
Como posso me apoderar Microsoft.SqlServer.RuntimeWrapper.dll?
Obrigado.
Editar: Ambas as pesquisas do PowerShell para não fornecer nenhum resultado. Eu também tentei essas pesquisas em servidores de produção com SQL Server e Integration Services instalados e sem acertos:
Get-ChildItem "$env:SystemRoot\Microsoft.NET\" -Filter *RuntimeWrapper.dll -Recurse -Force -ErrorAction Ignore
Get-ChildItem "C:\Program Files\Microsoft SQL Server\" -Filter *Wrapper.dll -Recurse -Force -ErrorAction Ignore
Edit: Na minha instalação do SQL Server, estão instalados os seguintes:
Extensão para SSIS:
Eu gostaria de encontrar o nome de um trabalho de agente, mas por exemplo
Select login_name,
program_name,
host_name,
nt_domain,
nt_user_name
From sys.dm_exec_sessions
Não mostra o nome, mas mostra:SQLAgent - TSQL JobStep (Job 0x"Some hexadecimal number" : Step 1)
Como posso encontrar o nome deste trabalho de agente?
Não estou tentando resolver um problema específico, mas apenas tentando entender.
Eu li vários lugares que o arquivo de dados (vamos supor apenas um arquivo mdf) é dividido em páginas de 8 KB. Mas quando eu soma ou total_pageso resultado não soma o tamanho do arquivo de dados e é menor. Há mais alguma coisa no arquivo de dados além de páginas de 8 KB?sys.system_internals_allocation_unitssys.allocation_units
Digamos que eu tenha uma coluna de tamanho fixo e estou SELECTpartindo dela, digamos 100 linhas. Ao ler diferentes linhas da coluna de comprimento fixo, o SQL Server verifica o comprimento da coluna para cada linha ou verifica uma vez e reutiliza essas informações para que as linhas subsequentes possam ser lidas mais rapidamente?
Por outro lado, para colunas de comprimento variável, o SQL Server precisa verificar o comprimento de cada coluna de comprimento variável para cada linha, usando a matriz de deslocamento.
Portanto, minha pergunta é: o SQL Server verifica o comprimento dos tipos de dados de comprimento fixo para cada linha (ou seja, após os bits de status A e B da linha)? Logicamente, quando ele precisa ler uma coluna de comprimento fixo, ele só precisa verificá-lo uma vez.
Essa sobrecarga é a razão pela qual os índices são melhores em colunas de comprimento fixo?
Não tentando resolver nenhum problema, apenas tentando entender.
Informações extras: em relação a que os índices são melhores em colunas de comprimento fixo: Toda essa questão começou para mim quando eu estava lendo este artigo Estratégias de indexação para desempenho do SQL Server . Em um ponto, ele diz: "Uma chave de índice clusterizado deve ser estreita, mas também usar um tipo de dados de largura fixa". Quais são as razões para esta afirmação? Só consigo pensar no motivo relacionado à minha pergunta, ou seja, colunas de comprimento fixo são mais baratas de ler, porque o comprimento só precisa ser verificado uma vez.
Como as instruções SELECT usam um bloqueio compartilhado em contraste X e U, parece-me que usar WITH(TABLOCK) em consultas de estilo de datawarehouse usadas para relatórios é a coisa correta a fazer para evitar o gerenciamento de bloqueios e o escalonamento de bloqueios.
Estou falando de casos em que os dados não são dados de produção ao vivo e a simultaneidade não é um problema. Por exemplo, eu não me importo em bloquear escritores usando um bloqueio de tabela compartilhada. É claro que não quero bloquear leitores, mas os bloqueios S não bloqueiam outros leitores.
Então, acho que posso formular minha pergunta como: Em um ambiente de data warehouse, todas as consultas não devem ser sugeridas com WITH (TABLOCK)? E, teoricamente, isso deve melhorar o desempenho. Se não, por quê?
Obrigado
Na execução de uma consulta, temos o custo estimado da subárvore de uma instrução e também podemos observar, por exemplo, o tempo de CPU ou leituras lógicas.
O custo estimado da subárvore incorpora o custo de aquisição de bloqueio e escalonamento de bloqueio em sua fórmula? Também acho que o processo de gerenciamento de bloqueios requer CPU. O tempo de CPU de uma consulta inclui o tempo de CPU usado para gerenciamento de bloqueio e tarefas relacionadas a bloqueio?
Alguém conhece uma ferramenta como esta página https://columnscore.com/ onde se pode determinar se uma tabela é uma boa candidata para compactação de linha ou página.
Também estou tentando entender os benefícios da compressão. Eu tenho lido sobre isso, mas ainda tenho essas dúvidas.
Um colega começou a compactar muitas tabelas (página). Não conheço a análise por trás dessa decisão. Eu sei que às vezes temos esperas de semáforos de recursos durante alguns horários de pico. Na verdade, acho que ele não sabe o que está fazendo. Eu posso ver que nossas esperas de rendimento do agendador sos aumentaram um pouco.
Eu acho que a compressão está causando mais danos e parece que as tarefas de manutenção ultrapassam mais agora (por exemplo, backups, checkdb...).