Categorias
Monitoramento SQL Server Troubleshooting Virtual PASS BR

Monitorar Index Online com extended events

[bing_translator]

Recentemente eu precisei realizar uma movimentação de dados fisicamente, ou seja, retirar dados do arquivo1 e passar esses dados para o arquivo2.

A estratégia adotada foi a recriação do índice clustered em um novo filegroup;

CREATE CLUSTERED INDEX [IX_01] ON [dbo].[TEST]
(
   [ID] ASC
)
WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF,
      DROP_EXISTING = ON, ONLINE = ON, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
ON [NovoFileGroup](ID)
GO

Esse procedimento é bem simples e já tinha executado muitas vezes. Porem dessa vez tinha algumas variáveis que levei em consideração no meu ambiente de teste:

Primeira: quantidade de registros envolvidos nessa tabela, aproximadamente 2 bilhões.

Segunda: Essa mesma tabela possuía 3 índices non-clustered no qual no ambiente de teste eu pude apagar antes de recriar o meu índice non-clustered.

Realizei todos os meus testes e obtive um tempo de 5 horas para execução do comando. A minha janela de manutenção era de 8 horas. A criação dos outros dois índices non-clustered levaram em torno de 3h e meia conversei com a equipe de negócio e eles não viram problema em invadir por um pouco tempo, ou seja, eu estava tudo certo para executar a minha manutenção.

Antes de iniciar a manutenção em produção, eu decidi não apagar os índices non-clustered (meu erro fatal).
Iniciei a manutenção sem nenhuma preocupação e fiquei acompanhando através de algumas DMV (sys.dm_exec_requests, sys.dm_os_tasks, sys.dm_os_waiting_tasks entre outras) a execução do comando, porém não sei se existe, eu desconheço, uma forma de saber exatamente quanto tempo falta para o comando de CREATE INDEX terminar. No meu acompanhamento eu podia ver o que estava em execução porem muito lento!

Após 10 horas a criação do índice não havia terminado e a operação do dia-a-dia já havia iniciado e nesse momento a preocupação era em não impactar o negócio com possíveis bloqueios que poderiam gerar lentidão no sistema.

Nesse momento os ânimos estavam exaltados na área de negócio e na minha gerencia uma vez que a manutenção não terminou, porem eu estava “super” tranquilo porque não haveria impacto simplesmente pelo fato de eu ter tomado o cuidado e ter utilizado a clausura ONLINE = ON.

Como estávamos usando a versão Enterprise do SQL Server 2012 essa opção é uma das principais funcionalidades que tenho utilizado quando faço manutenção em índices.

A partir desse momento a área de negócio percebeu que eles não estavam sendo afetados pela minha manutenção e que o sistema estava sendo operado normalmente (Essa criação de índice era uma das principais tabelas do sistema)

Com os ânimos mais calmos agora vinham as perguntas: Quando irá terminar? Quanto tempo falta? O que realmente está fazendo? Está travado? Posso realizar rollback? Quanto tempo para o rollback terminar? E muitas outras perguntas referentes ao processo.

Para me auxiliar em relação a algumas dessas perguntas abri um caso na Microsoft e algumas das respostas eu já tinha:

P: Quando irá terminar?

R: Não tem como estimar

P: O que realmente está fazendo?

R: Está em execução realizando a criação do índice lentamente.

P: Posso realizar rollback? Quanto tempo para o rollback terminar?

R: Pode, como está sendo realizado a criação com a clausura ONLINE = ON e DROP_EXISTING = ON o rollback é para ser rápido, mas não é possível precisar o tempo

Basead0s nessas respostas e que não havia impacto para o negócio decidimos deixar a execução rodando e monitorar o que estava fazendo. Mas agora a pergunta era como monitorar!!??

Resolvi tentar achar algum evento via XE (extended events) e existe um REPORT com informações que realmente são valiosas para monitorar o processo.

O que a opção ONLINE = ON faz exatamente? Aqui você entra nos detalhes e sabe o que está acontecendo.

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

Através desse evento podemos monitorar todas as fases que o índice passa:

  • Fase 1: Preparation

  • Fase 2:  Build

  • Fase 3:  Final

Após saber como monitorar passamos a tentar estimar um tempo de finalização, o qual demorou 38 horas. Esse tempo todo  é completamente justificado pelo comportamento da opção ONLINE.

Usar XE é sempre uma boa opção…

Categorias
Monitoramento SQL Server Troubleshooting Virtual PASS BR

Suspect database – MSDTC in-doubt transaction

Em uma bela madrugada, onde todas as coisas obscuras aparecem, um dos servidores de um cluster falhou e executou um failover para um outro nó. Até esse momento nada de estranho e esse é o comportamento esperado.

Problema

Ao verificar os bancos de dados da instancia que sofreu o failover me deparei com o status de “suspect” em um deles. Nesse ponto começou a investigação de como isso aconteceu e como resolver!

Consegui encontrar no errorlog as seguintes mensagens:

Attempting to initialize Microsoft Distributed Transaction Coordinator (MS DTC). This is an informational message only. No user action is required.

QueryInterface failed for “DTC_GET_TRANSACTION_MANAGER_EX::ITransactionDispenser”: 0x80004005(failed to retrieve text for this error. Reason: 15105).

QueryInterface failed for “ITransactionDispenser”: 0x80004005(failed to retrieve text for this error. Reason: 15105).

Attempting to initialize Microsoft Distributed Transaction Coordinator (MS DTC). This is an informational message only. No user action is required.

SQL Server detected a DTC/KTM in-doubt transaction with UOW  {07372A47-24B9-4BC3-A651-0260624FFF8E}. Please resolve it following the guideline for Troubleshooting DTC Transactions.

An error occurred while recovering database ‘XXX’. Unable to connect to Microsoft Distributed Transaction Coordinator (MS DTC) to check the completion status of transaction (0:-222014414). Fix MS DTC, and run recovery again.

An error occurred during recovery, preventing the database ‘XXX’ (database ID 5) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.

A aplicação que utilizava essa database também utilizava Microsoft Distributed Transaction Coordinator (MSDTC) e tudo indicava que alguma coisa se perdeu no caminho da comunicação entre o MSDTC da aplicação e do banco de dados.

No meu caso eu tinha um agravante: o cluster não possuía uma instância do MSDTC, ou seja, utilizava o MSDTC local.

Quando uma instância do SQL Server 2008 ou superior é inicializada em um cluster, ela tenta encontrar uma instância do MSDTC para comunicação na seguinte ordem:

  • Dentro do grupo do cluster onde reside o recurso do SQL Server
  • Dentro de outros grupos do cluster
  • Instância MSDTC local

Resolução

Eu não sabia o que tinha acontecido com MSDTC e resolvi tomar uma ação para deixar meu banco de dados online e depois tentar resolver qualquer problema.

Utilizei o comando abaixo:

sp_configure ‘show advanced options’, 1
go
reconfigure
go
sp_configure ‘in-doubt xact resolution’, 2
go
reconfigure
go
sp_configure ‘show advanced options’, 0
go
reconfigure
go

E depois trouxe o banco de dados ONLINE.

Podem existir outras formas de resolver esse problema, porem essa ação permitiu que meu banco dados ficasse online e pude executar um DBCC CHECKDB que para meu alivio retornou sem nenhum erro!

Antes de liberar meu banco de dados para produção novamente voltei a configuração padrao

sp_configure ‘in-doubt xact resolution’, 0
go
reconfigure
go

Outra alterativa seria vizualizar a view sys.dm_tran_active_transactions, essa view mostra algumas informações sobre  as transações com uso do MSDTC.

Os campos: transaction_uow, transaction_state, dtc_state são campos que devem ser olhados com cuidado em uma analise pois contem informaçoes importantes.

MDCTS-01

O campo transaction_uow pode ser relacionado com o Unit of Work ID dentro da lista de transações do MSDTC.

MDCTS-02

Assim você pode identificar o status da sua transação e pode tomar a ação necessária que cabe ao seu ambiente.

Conclusão

Quando a instância SQL Server executou um failover para o outro nó do cluster, a instância passou a se comunicar com o MSDTC local do novo nó, que não tinha informações das transações registradas no nó anterior.

Ao tentar iniciar o processo de recovery do banco de dados, o SQL Server encontrou informações sobre transações distribuídas que não haviam sido terminadas (confirmadas ou abortadas) antes da falha. O SQL Server entrou no processo de validar as informações do LOG e questionou o MSDTC a respeito das transações, e o novo MSDTC local não tinha informações a respeito destas transações. Por esse motivo o SQL Server não foi capaz de resolve-las e desta forma interrompeu o processo de recovery ocasionando o estado de “suspect”

A melhor solução para que isso não ocorra é ter uma instancia do MSDTC dentro do cluster.

Referências:

How to configure DTC for SQL Server in a Windows 2008 cluster

Opção de configuração de servidor in-doubt xact resolution

sys.dm_tran_active_transactions

 

Categorias
Monitoramento Troubleshooting Virtual PASS BR

Configurar conexão DAC – Dedicated Administrator Connection

O SQL Server fornece uma conexão especial para administradores quando conexões padrão com o servidor não são possíveis.
Apenas um DAC é permitido por instância do SQL Server. Se uma conexão DAC já estiver ativa, qualquer nova solicitação de conexão via DAC será negada com o erro 17810.

Somentes membros da role SYSADMIN podem usar esse tipo e conexão. Não use o DAC para executar consultas com muitos recursos (por exemplo, um join complexo em uma tabela grande) ou consultas que podem ser bloqueadas e lembre-se sempre de desconectar sua sessão quando terminar.

Habilitar Conexão DAC

sp_configure ‘remote admin connections’, 1
GO
RECONFIGURE
GO

Usando conexão DAC

Utilizando SQLCMD

Para utilizar o SQLCMD, abra um prompt de comando em um computador que tenha o cliente do SQL Server instalado e digite o seguinte comando:
sqlcmd -A -d master -E -S instance_name

DAC-01

Figura 1

Onde:

-E trusted connection

-A dedicated admin connection

-S [protocol:]server[\instance_name][,port]

-d db_name

Utilizando o SSMS

Abra uma nova conexão com o Database Engine Query.

DAC-02

Figura2

Utilize a opção ADMIN:instance_name

DAC-03

Figura 3

A conexão DAC vai ajudar você em algum momento, pode ter certeza!!!

Referencia:

http://www.brentozar.com/archive/2011/08/dedicated-admin-connection-why-want-when-need-how-tell-whos-using/

http://technet.microsoft.com/pt-br/library/ms190468.aspx

http://technet.microsoft.com/pt-br/library/ms162773.aspx

Categorias
Monitoramento SQL Server Virtual PASS BR

Performance Counter: Rede

 

 

Comunicação de Rede

As requisições de cliente SQL utilizam o protocolo Tabular Data Stream (TDS) para comunicação com o servidor de banco de dados. Para saber mais sobre TDS, consulte o link.

Os contadores de performance utilizados são:

Network Interface: Bytes Sent/sec e Network Interface: Received/sec – medem respectivamente a quantidade de dados enviados e recebidos pelo servidor através da placa de rede correspondente.

Network-Throughput

Gráfico 1

A capacidade máxima de uma rede gira em torno de 60-80% da sua capacidade total. O gráfico 1 mostra que não tenho problemas de trafico de dados, isto porque minha placa de rede tem a capacidade de throughput de 1GB/s.

Nesse momentos estou validando apenas se não existe uma sobrecarga na minha placa de rede referente ao volume de dados trafegado. Em um proximo post irei detalhar No post – Problemas de Rede: ASYNC_NETWORK_IO detalho melhor um problema de rede que me deparei onde irei aprofundar melhor a analise.

Referencias:

Network Protocols and TDS Endpoints

http://technet.microsoft.com/en-us/library/ms191220(v=sql.105).aspx

Network Interface Object

http://msdn.microsoft.com/en-us/library/ms803962.aspx

Categorias
Monitoramento SQL Server Virtual PASS BR

Performance Counter: Subsistema de Discos

Os administradores de storages estão constantemente tentando maximizar o desempenho de acesso ao disco e problemas podem ser o resultado de qualquer coisa a partir de um componente configurado incorretamente até uma volume de carga extramamente grande. E aqui entra, na minha visão, a “briga” entre o DBA e o Administrator de Storage mas essa é uma historia longa. Voltando ao assunto, os bancos de dados estão armazenados em discos (ou pelo menos até a chegada do SQL Server 2014, o recurso de IN-Memory OLT, conhecido tambem por HEKATON, passa a armazenas dados em memoria) que ao contrário da memória RAM, são mídias não-voláteis.

Utilização de Disco

A utilização do recurso de disco pode ser medida através de:

  • Operações de I/O por segundo (IOPS) – Número de operações realizadas por segundo
  • Taxa de Transferência (Throughput) – Quantidade de dados (em Megabytes) transferidos

Os contadores utilizados para medir as informações são:

Logical Disk: Disk Reads/sec e Disk Write/sec – São respectivamente ao número de operações de leitura e escrita realizadas realizadas no volume ou disco. Valores abaixo de 100 IOPS são considerados baixos.
Logical Disk: Avg. Disk Read Bytes/Sec e Avg. Disk Write Bytes/Sec – Taxas de transferência para escrita e leitura no subsistema de disco. Valores abaixo de 20MB são considerados baixos.

TotalIOPSGráfico 1 – Total de IOPS

O gráfico 1 mostra o consumo de IO do subsistema de disco, onde a utilização maxima chega perto dos 20 mil IOPS. Também é possivel notar que a maior concentração na utilização do subsistema de disco para leitura, visto que a gravação de dados consome pouco recurso.

DiscoThroughput

Figura 2 – Total de Throughput

Tempo de Resposta

Podemos definir latência ou tempo tempo de resposta como: uma medida de dealy(tempo de atraso) desde o momento de uma requisição de IO é criado, até ao momento em que a requisição de IO é completada.

Através de indicadores abaixo é possível dimensionar o impacto da utilização do subsistema de disco.

Logical Disk: Avg. Disk sec/Read e Avg. Disk sec/Write – É o tempo médio gasto em leitura e escrita de uma operação de I/O no disco. Esse indicador corresponde ao tempo de resposta do disco, sendo recomendado valores inferiores a 0.020 – equivalente a 20 milissegundos.

Logical Disk: Current Disk Queue Lenght – Informa a fila de cada volume ou disco. O valor ideal da fila de disco é zero, porém, existe uma tolerância de até 2 operações de I/O por disco físico.

DiscoTempoResposta

Gráfico 3 – Tempo de Resposta

O gráfico 3 mostra que a fila de disco está alta porém o tempo de resposta do subsistema de disco nao ultrapassa 8 milisegundos ou 0.08. Nesse caso o enfileiramento de disco não está atrapalhando o tempo de resposta de IO.

Referências:

Windows Performance Monitor Disk Counters Explained

http://blogs.technet.com/b/askcore/archive/2012/03/16/windows-performance-monitor-disk-counters-explained.aspx

Measuring Disk Latency with Windows Performance Monitor (Perfmon)

http://blogs.technet.com/b/askcore/archive/2012/02/07/measuring-disk-latency-with-windows-performance-monitor-perfmon.aspx

Categorias
Monitoramento SQL Server Virtual PASS BR

Performance Counter: Memoria

Memória é um componente importante do seu hardware? Será que é necessario monitorar a memória? Com certeza a resposta para as perguntas é SIM. A tendência do mercado é que a maior quantidade de dados possível seja mantida em memória. O acompanhamento do consumo de memória pode ser realizado através dos seguintes contadores do Performance Monitor:

Memory: Committed Bytes – Quantidade de memória virtual comprometida, em bytes e a memória física que tem espaço reservado no arquivo de paginação em disco.

CommitedMemoryMB

Gráfico 1 

Memory: %Committed Bytes In Use – Porcentagem de Committed Memory utilizado dentro do limite dado pela soma da memória RAM e Page File. O recomendado é que não haja grandes variações nesse indicador.

PercentCommitedInUse Gráfico 2

Nos gráficos 1 e 2 observamos que a quantidade de % Committed Bytes in use se mantém estável assim como o Committed Memory.

Memory: Available Mbytes – Quantidade de memória física disponível para alocação. O valor ideal é que esse indicador seja superior a 2GB.

MemoryAvailable Gráfico 3

Memory: Free System Page Table Entries – Uma “page table” (ou tabela de página) é a estrutura de dados usada pelo Windows Virtual Memory Manager (VMM) para armazenar o mapeamento entre endereços virtuais e endereços físicos na memória. O contador Free System Page Table Entries é o número de entradas da tabela de página que não são utilizados atualmente pelo sistema. Esse indicador deve ser sempre superior a 5000-7000.

Obs: Em um ambiente 64-bits este parâmetro raramente estrapola seus limites ideais.

PTE-Available Gráfico 4

Memory: Pool Paged Bytes – Memória de Kernel que pode ser paginada. O recomendado é que esse valor se mantenha estável.

PoolPagedMemory Gráfico 5

Memory: Pool NonPaged Bytes – Memória de Kernel que não pode ser paginada. O recomendado é que esse valor se mantenha estável. NonPoolPagedMemory

Gráfico 6

Nos gráficos 5 e 6 observamos que a quantidade de Paged Pool e NonPaged Pool se manteve estável.

Referências:

Symptoms: Lack of Free System Page Table Entries (PTEs), system-wide delays (I/O request failures), and low on Paged Pool Memory and/or Non-paged Pool Memory on 32-bit Windows

http://blogs.technet.com/b/cotw/archive/2008/04/07/symptoms-lack-of-free-system-page-table-entries-ptes-system-wide-delays-i-o-request-failures-and-low-on-paged-pool-memory-and-or-non-paged-pool-memory-on-32-bit-windows.aspx

Uncover Memory-Related Bottlenecks

http://technet.microsoft.com/en-us/magazine/dd722744.aspx

Monitoring Memory Usage

http://msdn.microsoft.com/en-us/library/aa905152(SQL.80).aspx

Am overview of Troubleshooting Memory Issues

http://blogs.technet.com/b/askperf/archive/2008/01/25/an-overview-of-troubleshooting-memory-issues.aspx

Categorias
Monitoramento SQL Server Virtual PASS BR

Performance Counter: Processador

Além de saber o que monitorar em um ambiente (veja o post: Performance Counter: você sabe o que monitorar?“) é nessario saber o significado de cada contador e como relacionar um contador com outro.

Nesse primeiro momento vamos falar um pouco sobre processador.

O processamento é responsável pela execução de instruções de máquina, sendo limitado pelo número de processadores (CPU) e seu clock de operação. Qualquer comando no servidor requer uma cota mínima de processamento e a falta desse recurso pode causar enfileiramento de requições e espera em fila.

O Ivan Lima (@SQLInsane) está com uma serie sobre “Inside The Machine” que recomendo a leitura caso queira saber mais sobre hardware!

O acompanhamento do consumo de CPU pode ser realizado através dos seguintes contadores do Performance Monitor:

Processor: %Processor Time – Este é o principal indicador de processamento na máquina. Altos valores podem não ser necessariamente ruins, desde que reflitam o processamento de consultas ao banco de dados. Entretanto, fatores externos podem consumir o recurso do processador e degradar o desempenho do SQL Server. O valor ideal recomendado é abaixo de 80% do poder de processamento máximo disponível.

Processor: %Privilege Time – Privilege Time ou Kernel Time é o tempo gasto pelo processador servindo às atividades do núcleo do Sistema Operacional, que corresponde às operações internas do Windows e Drivers de sistema.  O valor ideal recomendado é que se mantenha abaixo de 30% em relação ao processamento de máquina indicado por “%Processor Time”. ProcessUtilzation

Gráfico 1 – Servidor com 32 CPU

O gráfico 1 mostra que temos um consumo de CPU razoavelmente alto com tendência de alta e em alguns periodos com quase 100% de utilização.  O tempo de Kernel se manteve dentro do esperado: abaixo do número máximo recomendado de 30% da utilização do processador.

Process(sqlservr): % Processor Time: Este contador mostra qual a percentagem de tempo de processador está sendo usado para executar o processo Sqlservr (database engine). Idealmente, o tempo do processador deve ter um média abaixo de 50%  Se exceder uma média de 80% por um tempo contínuo (cinco minutos ou mais), então existe um afunilamento de CPU durante esse tempo, e você deve investigar a causa raiz.

Process(sqlservr): % Privileged Time – Este contador mostra qual a percentagem de tempo de processador “em modo kernel” está sendo usado para executar o processo Sqlservr (database engine). A recomendação é a mesma do Processor: %Privilege Time, ou seja, menor que 30% of Total %Processor

System: Processor Queue Lenght – É o tamanho da fila do processador, que equivale ao número total de threads enfileiradas esperando pelo recurso de CPU. O enfileiramento ocorre como consequência do alto consumo de processador e se tornam um indicativo do impacto do SQL Server em relação a máquina. O valor ideal recomendado é que essa fila não ultrapasse 2 vezes o número de CPU. QueueLegth

Gráfico 2 – Servidor com 32 CPU

O gráfico 2 mostra que apesar do consumo alto de CPU, não há problemas relacionados ao enfileiramento no processador.

System: Context Switches/sec – A quantidade de troca de contexto em um SQL Server deve se manter baixa mesmo sob carga. Um aumento no indicador Context Switches/sec ocorre devido a execução de threads de alta prioridade, como as Interrupções (INT), Asynchronous Procedure Call (APC) e Deferred Procedure Call (DPC) ou se houver um grande número de chamadas ao Kernel (System Calls/sec) ou disparo de exceções (Exception Dispatches/sec). O valor ideal recomendado é de no máximo 10000 por CPU.

ContextSwitch Gráfico 3 – Servidor com 32 CPU

O número referente ao Context Switche se manteve dentro dos parametros esperados, sendo um valor aceitável até 320 mil trocas por segundo.

System: Exception Dispatches/sec – Corresponde ao mecanismo de controle de tratamento de erros. Sempre que um evento de exceção é gerado, ocorre uma interrupção em Kernel para iniciar esse tratamento. Esse indicador deve ser próximo de zero.

System: System Calls/sec – As chamadas de sistema ocorrem quando uma aplicação realiza uma chamada a uma rotina de sistema, realizando a troca de contexto entre uma thread em modo usuário para modo Kernel. Não encontrei um valor ideal para esse indicador.

Referências:

Monitoring CPU Usage

http://msdn.microsoft.com/en-us/library/aa173932(SQL.80).aspx

Establishing a Performance Baseline

http://msdn.microsoft.com/en-us/library/ms190943(v=sql.110).aspx

Categorias
Monitoramento Troubleshooting Virtual PASS BR

Performance Counter: você sabe o que monitorar?

Monitorar seu ambiente é sempre uma atividade legal, seja ela para achar a causa raiz de um problema (reativo) ou simplesmente para montar uma baseline (proativo). Mas o que eu devo monitorar? O que é importante coletar e como relacionar isso ao meu problema? Primeiramente tudo começa na escolha dos contadores de performance e isso concerteza irá fazer toda diferença no futuro. Aqui estão os contadores que utilizo para gerar uma baseline.

Performance Counter relacionados ao Sistema Operacional

Logical Disks
  • Avg Disk Bytes/Read
  • Avg Disk Bytes/Write
  • Avg Disk Sec/Read
  • Avg Disk Sec/Transfer
  • Avg Disk Sec/Write
  • Current Disk Queue Length
  • Disk Bytes/sec
  • Disk Read Bytes/sec
  • Disk Write Bytes/sec
  • Disk Reads/sec
  • Disk Transfers/sec
  • Disk Writes/sec
Memory
  • %Committed Bytes In Use
  • Available MB
  • Committed Bytes
  • Free System Page Table Entries
  • Pool Nonpaged Bytes
  • Pool Paged Bytes
Network Interfaces
  • Bytes Received/sec
  • Bytes Sent/sec
  • Bytes Total/sec
Processor
  • %Processor Time
  • %Privileged Time
System
  • Context Switches/sec
  • Exception Dispatches/sec
  • Processor Queue Length
  • System Calls/sec

Performance Counter relacionados ao SQL Server

Buffer Manager
  • Buffer cache hit ratio
  • Checkpoint Page/Sec
  • Database pages
  • Free list stalls/sec
  • Free pages (<= 2008R2)
  • Lazy writes/sec
  • Page life expectancy
  • Page lookups/sec
  • Page reads/sec
  • Procedure cache pages
  • Readahead pages/sec
  • Stolen pages (<= 2008R2)
  • Target pages 
  • Total pages (<= 2008R2)
General Statistics
  • Connection Reset/sec
  • Logins/sec
  • Logouts/sec
  • User   Connections
SQL Statistics
  • Batch Requests/sec
  • Safe Auto-Params/sec
  • Forced Parametrizations/sec
  • SQL Compilations/sec
  • SQL Re-Compilations/sec
Memory Manager
  • Free Memory (KB) (=2012)
  • Target Server Memory (KB) (=2012)
  • Stolen Server Memory (KB) (=2012)
  • Total Server Memory (KB) (=2012)

Com esses contadores, consigo montar uma visão geral de como está a saúde do meu ambiente. Esse foi o primeiro post de uma serie sobre monitoramento e o que tenho feito para monitorar meu ambiente.

Establishing a Performance Baseline
http://msdn.microsoft.com/en-us/library/ms190943(v=sql.110).aspx

Monitoring CPU Usage
http://msdn.microsoft.com/en-us/library/aa173932(SQL.80).aspx

Monitoring Memory Usage
http://msdn.microsoft.com/en-us/library/aa905152(SQL.80).aspx

SQL Server: Buffer Manager Object
http://msdn.microsoft.com/en-us/library/ms189628.aspx

SQL Server: General Statistics
http://msdn.microsoft.com/en-us/library/ms190697.aspx

SQL Server: SQL Statistics Object
http://msdn.microsoft.com/en-us/library/ms190911.aspx