Archive

Archive for the ‘Performance’ Category

Conhecendo um pouco de performance

Fala Galera, boa noite.

Tudo bem? Faz tempo neh!? Hoje não colocarei o desafio de T-SQL (não ainda..rs). Hoje vim pra divulgar um assunto que também estava ficando um pouco desatualizado ,mas, como algumas pessoas não conseguiram comparecer e algumas não ficaram sabendo, estou divulgando aqui no blog.

No dia 03/12 tivemos a última reunião, do ano de 2015, do SQLManiacs  organizada pelo Vitor Fava, onde eu falei um pouco de performance e tuning (novidade..) utilizando alguns cenários práticos do dia-a-dia.

Para quem tiver interesse em reproduzir todos os cenários descritos na reunião, basta fazer o download dos scripts através do link abaixo:

Reunião do SQLManiacs – Conhecendo um pouco de performance

Ou ir até o blog do Fava, pois, lá possui mais algumas informações, fotos e etc.

https://vfava.wordpress.com/2015/12/08/reuniao-do-sqlmaniacs-conhecendo-um-pouco-de-performance-3/

Muito Obrigado e até a próxima

 

 

Advertisements

Criando Relatório de Performance e Tuning

Olá pessoal.

Durante o evento do SQL Saturday gostaria de ter mostrado como nós criamos relatórios de performance utilizando arquivos .blg gerados pelo Perfmon. Como não foi possível, estou escrevendo essa dica aqui no blog.

Primeiramente é muito comum em uma análise de performance nós utilizarmos o perfmon para coletar contadores de performance, pois, o mesmo não gera um alto “overhead” para o ambiente e pode lhe mostrar de forma clara aonde está o problema (se você souber relacionar os dados do Perfmon, é claro), no entanto, não mostra qual é a causa raiz do problema. Para esse artigo, não temos a intenção de mostrar como é criado a coleta e o PORQUE dos contadores (ver as referências no fim do artigo), isso será feito em artigos adiantes que irei escrever aqui. O principal objetivo deste post é mostrar: COMO CRIAR UM RELATÓRIO em uma coleta já realizada com o Perfmon.

No meu exemplo utilizarei o arquivo TracePerfmon.blg que deixei realizando uma coleta na minha máquina, conforme pode ser visto abaixo:

 

Figure 1 – Gráfico do Perfmon padrão

 

Agora imagine o presidente da sua empresa ou o seu gerente olhando para esse gráfico para tentar relacionar os dados! Você não verá uma cena muito agradável…rs.

Como posso transformar essas informações de uma maneira que seja fácil para ler? Para quem ainda não conhece, existe uma ferramenta via linha de comando chamada “relog” a qual utilizaremos nesse artigo.

 

 

Utilizando o relog.

O relog extrai informações dos contadores de performance do perfmon e pode transformá-los em outros formatos como text-TSV, text-CSV, SQL e etc.

Abra o prompt de comando do SQL Server e digite o seguinte comando: relog/?

 

Figure 2 – Instrução “Help” do relog

Aperte “Enter“. Será exibido um help dos parametros do relog e algumas sintaxes de como você pode utilizar o comando.

 

Figure 3 – Exemplos de utilização do relog.

Obs: Nesse post não entraremos no mérito de explicar o que significa cada parâmetro, no entanto, existe uma referência do relog no fim do artigo.

Transformando o binário em CSV

Agora que sabemos utilizar o relog, precisamos ir até a pasta onde encontra-se nosso arquivo .blg para poder transformar o arquivo em .CSV.

Figure 4 – Caminho de onde está o arquivo .blg

 

Agora que naveguei até a pasta basta apenas digitar o comando abaixo e apertar o “Enter” para que o arquivo .CSV seja gerado.

 

Figure 5 – Transformação do .blg para .csv, após o relog

 

A hora da Mágica

Com o arquivo .CSV gerado nós iremos importá-lo no excel, para isso, abra o excel e clique em “Data” e “From Text“.

 

Figure 6 – Importando dados no excel através de fontes de texto.

 

Localize o arquivo .CSV que foi gerado através do comando relog e clique em “Importar“. Aparecerá uma tela com o primeiro passo da importação do arquivo, mude para “Delimited” e clique em next, sua tela deve ficar como a imagem abaixo:

 

Figure 7 – Passo 1 da importação

 

A tela seguir irá definir quais caracteres são os seus “delimitadores“, deixe a tela como a tela a seguir:

 

Figure 8 – Passo 2 da importação

O ultimo passo apenas determina a formatação das colunas, deixe como está, no caso “General” e clique em “Advanced“. Uma tela irá se abrir:

 

Figure 9 – Definindo separadores.

Esse é um ponto extremamente importante, pois, dependendo do idioma utilizado essas infomrações podem vir divergentes, causando uma pequena mudança no momento da formatação dos dados. Deixe o separador de decimal como “Ponto” e o separador de milhares como “virgula” e clique em “OK” e “Finish“.

Criando os Gráficos

Após o arquivo ser importado para o excel, remova a segunda linha da planilha, conforme pode ser visto na imagem abaixo:

Figure 10 – Removendo a segunda linha da planilha

 

Após a linha ser removida, formate a primeira coluna da planilha excel para data utilizando o “Custom Format” das células. Sua data deve ficar algo parecido como no “Sample“.

 

Figure 11 – Formatação Excel da coluna de Data.

 

No momento que a nossa data estiver formatada, apenas precisamos adicionar uma nova coluna no arquivo excel, que será chamada de “Hora“.

Nós iremos extrair da coluna da data formatada anteriormente apenas as horas para que possamos fazer nosso relatório de “hora-em-hora“. Poderíamos fazer também de “minutos-em-minutos“. Lembrando que as colunas que serão transformadas em “Horas” deve estar como “General“, conform imagem:

Figure 12 – Aplicando a função de hora para a nova coluna

 

Após o passo anterior realizado, seu arquivo de excel deverá ficar mais o menos com o arquivo abaixo:

 

Figure 13 – Arquivo Excel “pronto” com a coluna de minutos incluso.

 

No momento que as colunas estão criadas, apenas precisamos criar um “Pivot Chart e Pivot Table” para montar os gráficos:

 

Figure 14 – Criando a Pivot Table e o Gráfico

A seguinte tela aparecerá, apenas informe o “Range” das informações que farão parte do gráfico, no nosso caso, todas as células. Deixe como a seguir e clique em “OK“.

 

Figure 15 – Determinando quais informações farão parte do gráfico e da tabela.

 

Agora os Mestres em Excel podem utilizar a sua imaginação para fazer relatórios necessários com os contadores de performance. Como não faço parte deste grupo seleto de mestres, apenas criei um relatório básico que: mostra as informações da “Média de Batch Requests/sec por hora” do período da coleta.

 


Espero que tenham gostado!!!

Até a próxima

Thiago Carlos [TC] de Alencar

 

 

Referências

Relog:

http://technet.microsoft.com/en-us/library/bb490958.aspx

Performance Counters PDF

http://www.quest.com/techbrief/sql-server-perfmon-counters-poster811635.aspx

Criando coletores de performance

http://technet.microsoft.com/en-us/library/cc749337.aspx


 

Web Cast – Estatísticas no SQL 2012/2014- Arquivos e Video

Pessoal boa tarde.

Para quem não pode comparecer no Web Cast sobre estatísticas que apresentamos ontem, estou disponibilizando o link do video no Youtube que foi feito upload pelo Marcos Freecia.

https://www.youtube.com/watch?v=7jSPo6HKMog&feature=youtu.be&list=UUI4WHxHE8xRAnhCbCBiGbzQ

Espero que gostem.

WebCast_Estatisticas2014 – PPT

Bom fim de semana a todos.

Categories: Performance

Erro – STATISTICS IO em Planos Paralelos.

Fala pessoal, beleza?

Estava otimizando uma query nessa tarde, onde a mesma utiliza uma clausula TOP e o seu respective plano era um plano paralelo. Visando identificar onde estavam as maiores leituras dos objetos dessa query utilizei o comando SET STATISTICS IO ON.

Quando fui avaliar na guia “messages” do SSMS (SQL Server Management Studio) percebi que a quantidade de leituras lógicas retornadas pelo comando SET STATISTICS IO ON era um pouco menor do que eu realmente esperava, simplificando: A minha query retornava “X” registros de uma tabela “Y”, no entanto, a quantidade de leituras eram muito menor do que eu tinha no meu retorno do SSMS.

Nesse meio tempo ouvi uma voz me dizendo: “Thiago tenta colocar o MAXDOP(1) pra ver se a query executa mais rápido”. Levando em consideração o conselho, executei a mesma query com o MAXDOP(1), portanto, esperaria ver a mesma quantidade de leituras lógicas que vi anteriormente, correto? Errado.

Quando executei a query utilizando o MAXDOP(1) percebi que a quantidade de registros eram a mesma, no entanto, as leituras lógicas eram diferentes. Pesquisando sobre esse comportamento no BING, encontrei um “Connect Item” da Microsoft que realmente isso é uma comportamento inesperado dentro do produto, conforme abaixo:

https://www.beta.microsoft.com/SQLServer/feedback/details/767250/statistics-io-under-reports-logical-reads-for-parallel-plans

Execute os comandos abaixo para poder similar o mesmo problema que encontrei:

USE AdventureWorks2012;

GO

 

SET NOCOUNT ON;

SET STATISTICS IO ON; –Liga as Estatisticas de IO

DBCC SETCPUWEIGHT(1000) WITH NO_INFOMSGS –O comando garante que o plano paralelo seja utilizado.

GO

SELECT TOP 15000 * FROM Sales.SalesOrderHeader WHERE OrderDate < ‘20080101’;

SELECT TOP 15000 * FROM Sales.SalesOrderHeader WHERE OrderDate < ‘20080101’ OPTION (MAXDOP 1);

DBCC SETCPUWEIGHT(1) WITH NO_INFOMSGS;

Mais porque esse comportamento acontece?

Quando um plano paralelo tem uma clásusula TOP, por algum motive o SQL Server pode encerrar “threads” anteriormente se existem linhas suficientes (não possuo o valor desse threshold) para serem retornadas para o usuário. Esse encerramento interfere com a coleta de estatisticas do comando SET STATISTICS IO, ao contrário, do que acontece com plano sem paralelismo. Quando isso acontece, possivelmente nós veremos a quantidade reportada de IO para um plano paralelo menor do que a quantidade de IO reportado para um plano serial

Obs: Esse comportamento foi corrigido no SQL Server 2014.

Espero que tenham gostado.

Categories: Performance

Parallel SELECT… INTO – SQL Server 2014

Hoje apareci aqui no blog apenas para dar uma dica bem básica. Atualmente o Microsoft SQL Server está na versão 2014. Essa nova versão trouxe muitas features FANTÁSTICAS que possivelmente justifica uma migração da versão anterior (SQL 2012) para a versão atual (SQL 2014).

Uma das deficências das versões anteriores é que não era possível realizar operações de SELECT… INTO em paralelo e em algumas situações pode degradar um pouco do desempenho dessa operação.

Imagine um cenário onde você deve realizar uma operação de inserção de milhões de linhas em uma tabela de “stage” toda noite. E o resultado dessa tabela será trasnformado para um ambiente de data warehouse. Provavelmente essa operação de INSERT seria mais eficiente se fosse feito de forma paralela. Á partir do SQL 2014 esse tipo de operação é possivel, como podemos ver no link abaixo:

http://blogs.technet.com/b/italian_premier_center_for_sql_server/archive/2013/07/24/sneak-peek-on-sql-2014.aspx

A pergunta é: O paralelismo sempre vai me ajudar? A principio eu diria que DEPENDE, pois, pode haver alguns problemas se o paralelismo for utilizado de forma incorreta. Na internet existem diversas “threads” sobre o assunto,mas, recentemente li um artigo que explica de forma muito clara a questão do paralelismo dentro do SQL Server conforme podemos ver no link abaixo:

http://blogs.msdn.com/b/pfebrasilsql/archive/2014/08/21/max-degree-of-parallelism-cxpacket-maxdop.aspx

O principal ponto que gostaria de mostrar aqui é que, caso, exista um cenário onde possivelmente a “feature” de Parallel SELECT… INTO pode estar me prejudicando eu posso “desligar” esse comportamento.

O trace flag 9492 pode ser utilizado para o próposito de desabilitar essa nova feature dentro do SQL Server, lembrando que apenas utilize essa opção avançada se você REALMENTE SABE o que está fazendo. Pois, novas features geralmente sempre trazem melhorias e não o comportamento contrário. Lembre-se, TESTEs são VITAIS.

Obs: Para banco de dados de nível de compatibilidade 110 e superiores o Parallel SELECT … INTO podem ser automaticamente paralelizada se necessário.

Espero que tenham gostado.

Até a próxima.

Categories: Performance

Problemas de Performance com Tabelas variáveis?

Tabelas variavéis apareceram no SQL Server com a intenção de reduzir compilações tornando-se bem popular com sua frequente utilização e em alguns casos mais do que as tabelas temporárias.

A sua famosa utilização deu-se devido ao mito que: “Tabela variável fica na memória e tabela temporária fica no tempdb”. Execute o código abaixo e verifique que mesmo para a tabela variável o SQL Server aloca espaço no tempdb fisicamente.

USE tempdb

go

declare @Tabela table (cod int not null primary key clustered (cod))

insert into @Tabela values(1),(2)

select sys.fn_PhysLocFormatter(%%physloc%%) FROM @Tabela

No entanto, ambos tipos de tabela possuem suas particularidades, pós e contras. Existem diferença entre tabela variável e tabela temporária? Sim várias.

O objetivo desse post não é falar sobre a diferença de ambas, mas, no final do post tem algumas referências sobre o assunto. Recomendo a leitura

O principal problema que já tive com tabelas variáveis foi devido a criação de planos de execução ineficiente, pois, quando uma query é compilada no SQL Server o número de linhas da tabela variável é “desconhecido”. Esse comportamento pode fazer com que o otimizador de consulta realize uma estimativa que pode não ser a melhor trazendo problemas no momento da geração do plano de execução já que a cardinalidade para tabelas variáveis são sempre 1. Eu escrevi sobre isso neste artigo.

A partir do SQL Server 2012 SP2 uma nova trace flag foi adicionada para ajudar nesse ponto.A trace flag 2453 faz com que o SQL Server detecta “linhas suficientes” sendo inseridas em uma tabela variável e faz com que seja disparado uma recompilação da instrução T-SQL para produzir um plano de execução mais eficiente.

Em que cenário a utilização dessa trace flag se aplicaria? Imagine em um ambiente que existem diversos objetos de programação criados e muitos deles apresentam problemas de desempenho devido a utilização da tabela variável. Para ter que alterar todos, isso pode demandar uma boa quantidade de tempo, nesse caso, seria interessante avaliar a utilização do Trace Flag 2453. Ou até mesmo em um ambiente onde o código fonte é disponibilizados por fábricas de softwares terceira e você não possui permissão para alteração do código fonte para mudar as tabelas variáveis para tabelas temporárias

 

Referências:

http://blogs.msdn.com/b/psssql/archive/2014/08/11/if-you-have-queries-that-use-table-variables-sql-server-2012-sp2-can-help.aspx

 

http://epmxperts.wordpress.com/2010/06/23/myth-sql-server-table-variables-vs-temp-tables/

 

http://blogs.msdn.com/b/psssql/archive/2012/08/22/10053781.aspx

Até mais.

 

Categories: Performance

WebCast sobre Estatísticas – Convite

Pessoal, bom dia.

Gostaria de convidá-los para participar do WebCast sobre estatísticas no dia 4 de Setembro ás 21 horas. Esse WebCast tem como objetivo demonstrar de como o SQL Server estima a quantidade de registro para uma determinada query e o que problemas podem ocorrer quando as estimativas não são feitas de forma correta. Vem muita coisa legal por aí. Nos vemos lá, basta apenas se escrever no link abaixo:

https://attendee.gotowebinar.com/register/8985229173189713410

Se houver algum problema, por favor, me avisem!!!

 

Categories: Performance