SQL Server - Apresentando WAIT_AT_LOW_PRIORITY

Os administradores de banco de dados geralmente têm a tarefa de gerenciar o tamanho de um banco de dados SQL Server. O comando DBCC SHRINKDATABASE é uma ferramenta poderosa em seu arsenal, permitindo reduzir o tamanho físico dos dados e arquivos de log no banco de dados especificado. No entanto, como acontece com todas as ferramentas poderosas, deve ser usado criteriosamente para evitar potenciais problemas de desempenho. Nesta postagem do blog, exploraremos o comando DBCC SHRINKDATABASE e suas opções, com foco no recurso WAIT_AT_LOW_PRIORITY introduzido no SQL Server 2022 e versões posteriores.

Compreendendo o DBCC SHRINKDATABASE

O comando DBCC SHRINKDATABASE ajuda a reduzir o tamanho dos dados e os arquivos de log em um banco de dados especificado. Ele usa o nome ou ID do banco de dados como argumento, com uma porcentagem alvo opcional que denota o espaço livre que você gostaria de manter no arquivo de banco de dados após ele ter sido reduzido.

O comando também fornece duas opções especiais: NOTRUNCATE e TRUNCATEONLY. A opção NOTRUNCATE move as páginas atribuídas do final do arquivo para páginas não atribuídas na frente do arquivo, compactando efetivamente os dados dentro do arquivo, mas não liberando o espaço livre no final de volta para o sistema operacional. Por outro lado, a opção TRUNCATEONLY libera todo o espaço livre no final do arquivo para o sistema operacional sem mover nenhuma página do arquivo.

Apresentando WAIT_AT_LOW_PRIORITY

A opção WAIT_AT_LOW_PRIORITY é um recurso que pode ser usado junto com o comando DBCC SHRINKDATABASE para gerenciar a contenção de bloqueio de forma mais eficaz. Esse recurso é especialmente útil quando uma operação de redução precisa adquirir um bloqueio de modificação de esquema (Sch-M), que muitas vezes pode causar bloqueio significativo no banco de dados.

Quando um comando de redução é executado no modo WAIT_AT_LOW_PRIORITY, novas consultas que exigem bloqueios de estabilidade de esquema (Sch-S) não são bloqueadas pela operação de redução em espera até que a operação de redução pare de esperar e comece a ser executada. Se uma nova operação de redução no modo WAIT_AT_LOW_PRIORITY não puder obter um bloqueio devido a uma consulta de longa execução, a operação de redução eventualmente atingirá o tempo limite após 1 minuto por padrão e será encerrada sem erros.

A opção WAIT_AT_LOW_PRIORITY assume dois valores possíveis para o argumento ABORT_AFTER_WAIT: SELF e BLOCKERS. A opção SELF é o padrão e permite que a operação de redução saia sem realizar nenhuma ação se estiver sendo bloqueada. A opção BLOCKERS, por outro lado, elimina todas as transações do usuário que estão bloqueando a operação de redução, permitindo que ela continue.

DBCC SHRINKDATABASE (Database, 100) 
WITH WAIT_AT_LOW_PRIORITY (ABORT_AFTER_WAIT = BLOCKERS);

Considerações finais

Gerenciar o tamanho de um banco de dados SQL Server é uma parte essencial do trabalho de um administrador de banco de dados. DBCC SHRINKDATABASE, quando usado criteriosamente, pode ajudar a gerenciar o tamanho físico do banco de dados de maneira eficaz. A opção WAIT_AT_LOW_PRIORITY aprimora ainda mais isso, gerenciando a contenção de bloqueio de maneira eficaz e garantindo que as operações de redução do banco de dados não bloqueiem desnecessariamente outras consultas.

No entanto, também é importante notar que a redução e o crescimento constantes do banco de dados podem levar à fragmentação e impactar negativamente o desempenho. Portanto, é essencial ter uma estratégia bem pensada para gerenciar o tamanho do banco de dados, e ferramentas como DBCC SHRINKDATABASE devem fazer parte dessa estratégia, e não de toda a estratégia.

Impacto da Alteração do Nível de Compatibilidade no Cache - SQL Server

        No mundo do SQL Server, o nível de compatibilidade do banco de dados desempenha um papel vital na determinação de como um banco de dados se comporta quando se trata de executar consultas e otimizar planos de execução. O SQL Server se esforça constantemente para melhorar o desempenho e a otimização de consultas, adotando novos algoritmos e aprimoramentos a cada novo lançamento. Como resultado, alterar o nível de compatibilidade torna-se necessário para aproveitar os recursos e melhorias mais recentes. Nesta postagem do blog, exploraremos como a alteração do nível de compatibilidade afeta o cache de consulta e por que é essencial estar ciente de seu impacto. 

Compreendendo o cache de consulta

      Antes de aprofundar nos efeitos da alteração do nível de compatibilidade, vamos discutir brevemente o cache de consulta no SQL Server. O cache de consulta, também conhecido como cache de plano, armazena os planos de execução gerados pelo otimizador de consulta do SQL Server. Quando uma consulta é executada, o SQL Server primeiro verifica o cache para ver se existe um plano de execução para essa consulta específica. Se encontrado, o plano em cache é usado, economizando a sobrecarga de gerar um novo plano. Isso melhora significativamente o desempenho da consulta e reduz o tempo de processamento da consulta.

Verificando o status do cache: 

-- Check the buffer cache usage
SELECT
    COUNT(*) AS CachedPagesCount,
    COUNT(*) * 8 / 1024 AS CachedSizeMB
FROM sys.dm_os_buffer_descriptors
WHERE database_id = DB_ID();
GO
-- Check the plan cache usage
SELECT
    objtype AS CacheObjectType,
    COUNT(*) AS CachedPlansCount,
    SUM(size_in_bytes) / 1024 AS CachedSizeKB
FROM sys.dm_exec_cached_plans
GROUP BY objtype;
GO
-- Check the procedure cache usage
SELECT
    cacheobjtype AS CacheObjectType,
    COUNT(*) AS CachedObjectsCount
FROM sys.dm_exec_cached_plans
GROUP BY cacheobjtype;
GO

-- For SQL Server 2008:
ALTER DATABASE [Banco_Homolog] SET COMPATIBILITY_LEVEL = 100;

Aqui, 100 significa SQL Server 2008. Se você deseja alterar o nível de compatibilidade para SQL Server 2022, pode usar 160 em vez de 100. Da mesma forma, pode usar 140 para SQL Server 2017.

Depois de alterar o nível de compatibilidade e verificar o cache de consulta novamente, 
você verá que ele está quase vazio.


Em conclusão, o nível de compatibilidade de um banco de dados SQL Server desempenha um papel crucial na determinação do comportamento e desempenho da otimização de consulta. Alterar o nível de compatibilidade pode influenciar os planos de execução em cache e, por sua vez, afetar o desempenho geral da consulta. Como parte da verificação abrangente de integridade do desempenho do banco de dados , sempre considero o nível de compatibilidade do banco de dados para garantir que os clientes aproveitem todo o potencial de seus bancos de dados SQL Server.

referencias Pinal Dave: comprehensive-database-performance-health-check

Grande abraços 
Gustavo Damatto
MCSD - Microsoft Certified Solutions Developer

linkedin.com/in/damatto
Ribeirão Preto-SP

Lançamento - Microsoft SQL Server 2022

  

Lançado oficialmente em novembro,  durante o evento anual Microsoft  Ignite  foi anunciado o grande lançamento do SQL Server 2022, a mais nova versão do principal banco de dados da Microsoft.

" Hoje estamos anunciando a prévia do SQL Server 2022, a versão mais integrada do SQL Server com Azure disponível, com inovação contínua em desempenho, segurança e disponibilidade." - Peter Carin CVP da Microsoft

O SQL Server 2022 se integra ao Azure Synapse Link e ao Azure Purview para permitir que os clientes obtenham insights, previsões e governança mais profundas a partir de seus dados em escala. A integração da nuvem é aprimorada com recuperação de desastres (DR) para a instância gerenciada do Azure SQL, junto com conexões sem ETL (extrair, transformar e carregar) para análise de nuvem, que permite que os administradores de banco de dados gerenciem suas propriedades de dados com maior flexibilidade e impacto mínimo para o usuário final. O desempenho e a escalabilidade são aprimorados automaticamente por meio de inteligência de consulta integrada. Há opções e flexibilidade entre linguagens e plataformas, incluindo Linux, Windows e Kubernetes.

Habilitado para Azure

HA/DR bidirecional para Azure SQL

Para garantir o tempo de atividade, o SQL Server 2022 está totalmente integrado ao novo recurso de link na instância gerenciada do Azure SQL. Com o novo recurso de link para a instância gerenciada SQL do Azure, agora você obtém todos os benefícios de executar um ambiente PaaS aplicado à recuperação de desastres - permitindo que você gaste menos tempo na configuração e gerenciamento, mesmo quando comparado a um ambiente IaaS. Isso funciona usando um Grupo de Disponibilidade Distribuída (DAG) interno para replicar dados para uma Instância Gerenciada SQL do Azure previamente implantada como um site de réplica de DR. A instância está pronta e esperando sempre que você precisar - nenhuma configuração ou manutenção demorada é necessária. Você também pode usar este recurso de link em cenários de escalabilidade horizontal de leitura para descarregar solicitações pesadas que podem afetar o desempenho do banco de dados. E estamos trabalhando para desenvolver mais recursos para dar suporte à movimentação bidirecional de dados.

Link de sinapse do Azure

Anteriormente, mover dados de bancos de dados locais, como SQL Server, para o Synapse exigia o uso de ETL. Como todos sabemos, configurar e executar um pipeline de ETL dá muito trabalho e os insights ficam para trás em relação ao que está acontecendo a qualquer momento. O Azure Synapse Link para SQL Server 2022 fornece feeds de alteração automática que capturam as alterações no SQL Server e as alimentam no Azure Synapse Analytics. Ele fornece análise quase em tempo real e processamento transacional e analítico híbrido com impacto mínimo nos sistemas operacionais. Depois que os dados chegam ao Synapse, você pode combiná-los com muitas fontes de dados diferentes, independentemente de seu tamanho, escala ou formato e executar análises poderosas sobre tudo isso usando sua escolha de Azure Machine Learning, Spark ou Power BI. Uma vez que os feeds de mudança automatizados apenas empurram o que é novo ou diferente,

Integração do Azure Purview

Recentemente, anunciamos a disponibilidade geral do Azure Purview como um serviço unificado de governança e gerenciamento de dados. Estamos empolgados em destacar que o SQL Server também está integrado ao Azure Purview para maior descoberta de dados, permitindo que você divida os silos de dados. Por meio dessa integração, você será capaz de:

• Verifique automaticamente seu SQL Server local gratuitamente para capturar metadados.
• Classifique os dados usando classificadores integrados e personalizados e rótulos de sensibilidade da Proteção de Informações da Microsoft.
• Configure e controle direitos de acesso específicos ao SQL Server.

Aprimoramentos de desempenho, segurança e disponibilidade

atuação

O SQL Server oferece desempenho diferenciado, com desempenho OLTP número um 1 e desempenho DW não agrupado número um em 1 TB 2 , 3 TB 3 , 10 TB 4 e 30 TB 5, de acordo com o Transaction Processing Performance Council independente. A inteligência de consulta integrada na inovação do SQL Server 2022 inclui:

• Para Query Store, estamos adicionando suporte para réplicas de leitura e permitindo dicas de consulta para melhorar o desempenho e mitigar problemas rapidamente sem ter que alterar a fonte T-SQL.
• Para o Intelligent Query Processing, estamos expandindo mais cenários com base em problemas comuns do cliente. Por exemplo, o problema do “plano sensível a parâmetros” se refere a um cenário em que um único plano em cache para uma consulta parametrizada não é ideal para todos os valores de parâmetros de entrada possíveis. Com o recurso de otimização Parameter Sensitive Plan do SQL Server 2022, habilitamos automaticamente a geração de vários planos ativos em cache para uma única instrução parametrizada. Esses planos de execução em cache irão acomodar diferentes tamanhos de dados com base nos valores de parâmetro de tempo de execução fornecidos.

Segurança

Nos últimos dez anos, o SQL Server teve menos vulnerabilidades do que a concorrência. 6 Com base nisso, o novo recurso de razão cria um registro de controle imutável de modificações de dados ao longo do tempo. Isso protege os dados contra adulteração por agentes mal-intencionados e é benéfico para cenários como auditorias internas e externas.

Disponibilidade

Com a mudança para uma distribuição mais global de funcionários e clientes, muitas organizações estão mudando para um ambiente de multi-gravação que permite que mudanças sejam feitas no banco de dados local e enviadas para outras réplicas em um fluxo bidirecional de atualizações. No entanto, se várias pessoas alterarem a mesma linha no banco de dados e as diferentes réplicas de gravação contiverem informações diferentes, anteriormente esse conflito de réplica ponto a ponto paralisaria toda a operação até que fosse resolvido. Com o SQL Server 2022, estamos automatizando a regra do último gravador vence. Agora, quando um conflito for detectado, a hora da modificação mais recente será escolhida para persistir em todas as réplicas. Isso ajuda a manter seus cenários de exibição múltipla funcionando sem problemas.

saiba mais

Saiba mais sobre o lançamento do SQL Server 2022 na  página da Web  e assistindo a sessões de aprofundamento no  Microsoft Ignite  , com o  Microsoft Mechanics  e no próximo  PASS Data Community Summit  virtual gratuito .

Grande abraços 

Gustavo Damatto - dba

Compatibilidade (suporte) Windows Server x SQL Server

Suporte do sistema operacional para versões do SQL Server

Introdução

Existem atualmente três versões principais do SQL Server (SQL Server 2016, SQL Server 2017 e SQL Server 2019) que ainda são totalmente compatíveis com a Microsoft, junto com cinco versões mais antigas que estão fora do suporte Main stream ou fora do suporte estendido. Existem também quatro versões principais relativamente recentes do Windows Server, apenas duas das quais (Windows Server 2016 e Windows Server 2019) ainda têm suporte total da Microsoft.

Idealmente, você deseja a versão mais recente com suporte do Windows Server que pode ser usada com a sua versão do SQL Server, mas às vezes isso não é possível.

Apenas certas combinações de SQL Server e Windows Server são oficialmente suportadas pela Microsoft, mas rastrear essas informações é um pouco tedioso. Deixaremos um guia para vocês, conforme imagem abaixo:

Se você está se preparando para implantar uma nova instância do SQL Server 2019, SQL Server 2017 ou SQL Server 2016, deve preferir o Windows Server 2019, embora todos eles também tenham suporte em alguns sistemas operacionais mais antigos.

Para uma nova instância do SQL Server 2014 ou SQL Server 2012, você deve preferir o Windows Server 2016, embora ambos também tenham suporte em alguns sistemas operacionais mais antigos. Tanto o SQL Server 2012 quanto o SQL Server 2014 estão fora do suporte Mainstream.

Se você está se preparando para implantar uma nova instância do SQL Server 2008 ou SQL Server 2008 R2, deve preferir o Windows Server 2012 R2, embora ambos tenham suporte em determinados sistemas operacionais mais antigos. Tanto o SQL Server 2008 quanto o SQL Server 2008 R2 estão sem suporte estendido.

Por fim, se você está se preparando para implantar uma nova instância do SQL Server 2005, sinto muito por você! O SQL Server 2005 está sem suporte estendido e estão faltando muitos recursos úteis que foram adicionados nas versões mais recentes do SQL Server. Se você simplesmente precisa implantar uma nova instância do SQL Server 2005, deve preferir o Windows Server 2008 R2.

Administração do Linux para DBA's do SQL Server: Verificando I/O De Disco

SQL Server on Linux - Administration

Administração do Linux para DBA's SQL Server: Verificando o uso da CPU

Administração do Linux para DBA's do SQL Server: Verificando Network I/O

      Com o lançamento do SQL Server, a Microsoft decidiu expandir o suporte do sistema operacional para servidores Linux. Nós, como administradores de banco de dados, precisamos saber o desempenho dos subsistemas de discos subjacentes. Como a maioria dos administradores do SQL Server não está acostumada a trabalhar com Linux, você pode não saber como fazer esta tarefa. Nessa dica vou mostrar algumas ferramentas que vão te ajudar.

Uma das funções de um administrador de banco de dados é garantir que o subsistema de armazenamento que suporta nossos bancos de dados esteja funcionando corretamente. Obviamente, temos as visualizações e funções de gerenciamento dinâmico de I/O, como sys.dm_io_pending_io_requests e sys.dm_io_virtual_file_stats , mas às vezes isso não é suficiente. Na verdade, estamos acostumados a olhar para contadores de desempenho relacionados ao disco em servidores em execução no Windows e até mesmo usar outras ferramentas.

Ferramentas Linux Disponíveis

Agora que o SQL Server também funciona no Linux, devemos nos familiarizar com as ferramentas existentes que nos permitirão fazer nosso trabalho exatamente como fazemos no Windows.

iostat

Este é o comando mais básico para verificar a I / O do disco e geralmente você o instalará por padrão, mas se não, poderá instalar o pacote sysstat que inclui a ferramenta iostat.

apt-get install sysstat
   

Basicamente, este comando mostra estatísticas de CPU e I / O para dispositivos e partições como dois relatórios separados, mas com os argumentos –c e –d você pode forçá-lo a exibir apenas o relatório de CPU ou de dispositivos, respectivamente. Para os fins desta dica, vou concentrar a atenção no relatório de I / O.

Como você pode ver na imagem anterior o comando mostra uma tabela com uma linha para cada dispositivo instalado e quatro colunas que nos informa sobre a Transferência por Segundo (tps), leituras e gravações por segundo expressas em kilobytes e a quantidade de kilobytes lidos e escrito.

Até agora, vimos uma imagem estática de nosso desempenho de I / O, mas este comando também nos permite mantê-lo em execução em um intervalo de tempo especificado (em segundos). Quando executamos iostat com um intervalo, ele muda seu comportamento e, para cada execução, mostra o delta de leituras e gravações da execução anterior. O comando a seguir mostra a cada quatro segundos o relatório de uso do dispositivo até que Control + C seja pressionado.

iostat –d 4
   

Na captura de tela a seguir é o resultado da execução do comando anterior.

Mas essa ferramenta já possui mais recursos. Quando iostat é executado com o parâmetro –x, ele retorna estatísticas estendidas. As estatísticas mais úteis estão nas colunas avgqu-sz, que é o comprimento médio da fila; e uma espera que se refere ao tempo gasto na fila e no atendimento a uma solicitação. Abaixo estão duas capturas de tela com a saída deste comando.

Na próxima tabela, copiei a descrição da página de manual de cada coluna das imagens.

	Descrição
rrqm / s	O número de solicitações de leitura mescladas por segundo que foram enfileiradas no dispositivo.
wrqm / s	O número de solicitações de gravação mescladas por segundo que foram enfileiradas no dispositivo.
r / s	O número de solicitações de leitura emitidas para o dispositivo por segundo.
w / s	O número de solicitações de gravação emitidas para o dispositivo por segundo.
rkB / s	O número de kilobytes lidos do dispositivo por segundo.
wkB / s	O número de kilobytes gravados no dispositivo por segundo.
avgrq-sz	O tamanho médio (em setores) das solicitações que foram emitidas para o dispositivo.
avgqu-sz	O comprimento médio da fila de solicitações emitidas para o dispositivo.
await	O tempo médio (em milissegundos) para solicitações de E / S emitidas para o dispositivo a ser atendido. Isso inclui o tempo gasto pelas solicitações na fila e o tempo gasto atendendo-as.
r_await	O tempo médio (em milissegundos) para que as solicitações de leitura emitidas para o dispositivo sejam atendidas. Isso inclui o tempo gasto pelas solicitações na fila e o tempo gasto atendendo-as.
w_await	O tempo médio (em milissegundos) para que as solicitações de gravação emitidas para o dispositivo sejam atendidas. Isso inclui o tempo gasto pelas solicitações na fila e o tempo gasto atendendo-as.
svctm	O tempo médio de serviço (em milissegundos) para solicitações de E / S que foram emitidas para o dispositivo. Atenção! Não confie mais neste campo. Este campo será removido em uma versão futura do sysstat.
%util	Porcentagem de tempo de CPU durante o qual as solicitações de E / S foram emitidas para o dispositivo (utilização da largura de banda do dispositivo). A saturação do dispositivo ocorre quando este valor está próximo a 100%.

iotop

Este utilitário exibe o uso de I/O por processo ou threads em uma grade interativa que se assemelha ao utilitário htop.

Como você pode ver na imagem anterior, este utilitário mostra os threads ou processos (mostrarei como alternar entre os dois quando descrever seus argumentos). A maioria das colunas é autoexplicativa, apenas para mencionar que a coluna IO lista a I / O total para cada processo, incluindo uso de disco e troca; e SwapIn lista a atividade de troca para cada processo.

A seguir está uma tabela com os parâmetros mais usados.

	Descrição
-o	Mostra apenas processos ou threads que estão realmente fazendo I / O, em vez de mostrar todos os processos ou threads. Isso pode ser alternado dinamicamente pressionando o.
-b	Ative o modo não interativo (modo em lote). Útil para registrar o uso de I / O ao longo do tempo.
-P	Mostrar apenas processos. Normalmente o iotop mostra todos os tópicos.
-a	Mostra I / O acumulada em vez de largura de banda. Nesse modo, o iotop mostra a quantidade de processos de I / O realizados desde que o iotop foi iniciado.

Mas sendo iotop um utilitário interativo, existem alguns atalhos de teclado que são úteis.

	Descrição
setas esquerda e direita	Altera a coluna de classificação.
r	Inverte a ordem de classificação.
o	Mostra apenas processos ou threads que estão realmente fazendo I / O.
p	Mostre processos em vez de threads.
a	Exibir I / O acumulada em vez de largura de banda.
Eu	Altera a prioridade de um thread ou processo.

Fique ligado para mais dicas do SQL Server no Linux .

Administração do Linux para DBA's SQL Server: Verificando o uso da CPU

SQL Server on Linux - Administration

Administração do Linux para DBA's do SQL Server: Verificando I/O De Disco

Administração do Linux para DBA's do SQL Server: Verificando Network I/O

       Com o lançamento de 2016 do SQL Server, a Microsoft decidiu expandir o SQL Server para rodar em servidores Linux. Como a maioria dos DBAs do SQL Server não está acostumada a trabalhar com Linux, há tarefas comuns, como verificar o espaço livre em disco ou o consumo de CPU, que podem ser difíceis. Nesta dica, farei uma pequena lista do que precisamos saber sobre a administração do Linux para começar a usar o SQL Server no Linux.

Comando TOP

O comando de console mais básico para verificar o consumo de CPU é o TOP. A saída deste comando consiste em um cabeçalho que mostra informações gerais e uma grade com as informações por processo. Dê uma olhada na próxima captura de tela.

Para aqueles de nós acostumados com o Windows, é importante entender o que cada linha significa, então irei linha por linha descrevendo seu significado.

Linha 1

• Hora atual do sistema
• Tempo desde que o sistema foi ligado
• Número de usuários conectados
• Média de carga medida em intervalos de 5, 10 e 15 minutos

Em sistemas Linux, a média de carga mede a porcentagem de tarefas enfileiradas (CPU ou E / S) em um período de tempo específico. Este valor também depende do número de núcleos da CPU. Por exemplo, um sistema com um núcleo com uma carga média de 1 tem uma carga total, mas se o sistema tiver dois núcleos, ele tem uma meia carga. Como regra geral, se a média de carga for um número maior que o número de núcleos de seu sistema, isso significa que seu sistema está sob estresse. Lembre-se de que a média de carga pode ser um número muito maior do que o número de núcleos em seu sistema devido a tarefas em espera.

Linha 2

• Número total de tarefas
• Número de tarefas realmente em execução
• Número de processos à espera de um evento para continuar a execução
• Número de tarefas paradas
• Número de processos em estado zumbi

Aqui precisamos explicar o que é um processo zumbi. Em um sistema Linux, quando um processo filho termina, ele mantém o id do processo na tabela de processos, para que o processo pai possa ler o status de saída do processo filho. Esse processo filho concluído é chamado de zumbi. Depois que o processo pai lê o status de saída filho, o zumbi é removido. O problema com zumbis é que o Linux tem um número limitado de ids de processo (que você pode encontrar lendo o arquivo / proc / sys / kernel / pid_max) e em circunstâncias muito raras isso pode levar à falta de recursos.

Linha 3

Esta linha mostra informações sobre o uso do tempo de CPU.

• Porcentagem de tempo de CPU no modo de usuário
• Porcentagem de tempo de CPU no modo de sistema
• Porcentagem de tempo de CPU no modo de usuário de baixa prioridade (o Linux chama de Nice Priority)
• Porcentagem de tempo ocioso da CPU
• Porcentagem de tempo de CPU aguardando E / S
• Porcentagem de interrupções de hardware de manutenção de tempo de CPU
• Porcentagem de interrupções de software de manutenção de tempo de CPU
• Porcentagem de tempo de CPU A CPU virtual espera por uma CPU real enquanto o hipervisor está atendendo a outro processador virtual (isso é chamado de tempo roubado)

Linha 4

Esta linha nos fornece informações sobre a memória física do nosso sistema.

• Memória total
• Memoria livre
• Memoria usada
• Memória usada pelo Buffer Cache

Linha 5

Esta linha mostra informações sobre as partições de troca, o equivalente ao arquivo de paginação do Windows.

• Espaço de partição de troca total.
• Espaço de partição de troca livre.
• Espaço de troca usado.
• Memória física disponível.

Grade de Processo

O painel inferior do comando superior exibe uma grade com informações sobre os processos em execução.

.

	Descrição
PID	O Identificador do Processo
USER	Usuário que possui o processo
PR	Prioridade do processo. Se você vir RT nesta coluna, significa que o processo está sendo executado em tempo real.
NI	Boa prioridade. Se for um valor negativo, significa que o processo está sendo executado em alta prioridade. Um valor positivo significa que o processo está sendo executado em baixa prioridade.
VIRT	Quantidade de memória virtual usada pelo processo, expressa em kilobytes.
RES	Quantidade de memória física usada pelo processo expressa em kilobytes.
SHR	Quantidade de memória compartilhada expressa em kilobytes.
S	Status do processo D = ininterrupto hibernação R = executando S = hibernando T = interrompido pelo sinal de controle de trabalho t = interrompido pelo depurador durante o rastreamento Z = zumbi
%CPU	A porcentagem de uso da CPU por determinada tarefa. Se você vir um número maior que 100%, não entre em pânico, é porque o comando top não está sendo executado no modo thread.
% MEM	A porcentagem de memória física usada pelo processo.
TIME +	Quantidade de tempo de CPU usado pelo processo.
COMMAND	O comando que iniciou o processo.

HTOP como alternativa

Existe uma alternativa ao top, que é uma ferramenta de monitoramento do Linux chamada htop ( http://hisham.hm/htop/ ). A vantagem dessa ferramenta é que ela usa cores e mostra informações sobre CPU, Memória e Troca como barras gráficas.

Normalmente esta ferramenta não está disponível nas instalações básicas do Linux, então você terá que instalá-la de seus repositórios de distribuição ou baixar os pacotes do site htop .

Se você estiver usando o Ubuntu, o seguinte comando instalará o htop.

sudo apt-get  install htop

Fique ligado para mais dicas do SQL Server no Linux .