Coletando e Aplicando Workloads com Replay Trace

Olá pessoal,

Hoje vou falar de um recurso que considero muito interessante disponível com o SQL Server Profiler chamado Replay Trace, de qual consiste de reproduzir um trace gerado, ou seja, com o trace coletado a partir de uma instancia SQL Server é possível reproduzi-lo em outro servidor ou no servidor local de forma que este irá executar todas as instruções armazenadas no arquivo ou tabela trace, simulando conexões e autenticação de usuários, o que permite reproduzir a atividade no momento do rastreamento. Isto é basicamente o conceito de Replay Trace!

Onde isso seria útil ? Podemos pensar na utilidade do Replay Trace em diversas situações das quais irei listar algumas abaixo:

  • Aplicar uma Workload coletada pelo Replay Trace em um novo Hardware com o objetivo de testar qual será seu desempenho.
  • Testar a compatibilidade do sistema antes de aplicar um novo Service Pack ou Hotfix, assim coletaria uma carga de trabalho com o Replay Trace e aplicaria em um servidor de simulação verificando e analisando os resultados antes de colocar em produção.
  • Testar qual será o desempenho e compatibilidade de uma aplicação diante a uma nova versão do produto.

São inumeras as situações onde o Replay Trace pode ser útil. Para começar a utilizar o Replay Trace inicialmente precisamos definir algumas colunas que precisam obrigatoriamente constar no arquivo trace para que este possa ser reproduzido. O Profiler disponibiliza um template chamado TSQL_Replay onde todas as colunas e eventos necessários ao Replay Trace já estão selecionados, para a visualização das colunas e eventos necessários clique aqui.

Antes de colocar a mão na massa vou fazer algumas considerações sobre o uso do Replay Trace em um servidor diferente, de qual será o foco do nosso artigo.

Para que o Replay Trace tenha sucesso precisamos assegurar que todos os logins e usuários sejam criados no servidor secundário e estejam no banco de dados correspondente, tenham as mesmas permissões, mesmas senhas e estejam configurados para utilizar o mesmo banco de dados como banco de dados padrão. Além dos logins o ID dos bancos de dados devem ser os mesmos,ao menos que a coluna DatabaseName esteja selecionada.

Agora que conhecemos o conceito e vimos algumas considerações podemos iniciar nossos testes, em nosso exemplo irei criar 4 conexões com o banco de dados e cada conexão irá executar uma instrução SQL aleatória para demonstrar atividade na base de dados, as instruções serão coletadas com o Replay Trace, após isso iremos reproduzir o Replay Trace em uma segunda instancia para analisar os resultados e verificar as conexões criadas na instancia no momento da execução do trace.

Em nossa instancia primária chamada SERV-SQLPRODUCAO vamos criar 4 conexões. A minha primeira conexão recebeu o SPID 52 (lembre-se dos SPID´s iremos nos referenciar a eles mais adiante), estou logado com o login sa e vou executar o seguinte lote de instruções SQL para criar no banco de dados Northwind e nossa tabela de teste.

USE Northwind

–Criando a tabela ReplayTeste.
CREATE TABLE ReplayTeste
(
     COD INT IDENTITY(1,1)
    ,TEXT VARCHAR(50) DEFAULT ‘REPLAY’
    ,DATE DATETIME DEFAULT GETDATE()
)

Após criar a tabela ainda na mesma conexão insira a instrução SQL abaixo para povoar a tabelas e simular a atividade na base, nao a EXECUTE iremos executa-la no momento do Trace.

–Lote de registros
INSERT INTO ReplayTeste VALUES(DEFAULT,DEFAULT)
GO 50000

Agora abra mais uma nova conexão,altere o contexto do banco de dados para Northwind e insira a instrução abaixo, mas não a execute agora,note que o spid desta conexão é 53.

–Comando DBCC Checkdb para simular atividade na base.
DBCC CHECKDB(‘Northwind’)

Repita os passos anteriores para criar uma nova conexão, o spid desta conexão é 54.

–simulando acesso simultaneo a base de dados.
SELECT     O.OrderID
        ,Od.ProductID
        ,Od.UnitPrice
        ,Od.Quantity
        ,P.ProductID
        ,P.ProductName
FROM Orders O
INNER JOIN [Order Details] Od
ON O.OrderID = Od.OrderID
INNER JOIN Products P
ON Od.ProductID = Od.ProductID
WHERE P.ProductName = ‘Chang’

Em nossa última conexão vamos inserir a instrução SQL abaixo, o spid desta conexão é 55.

–Simulando atividade na base.
UPDATE Employees
SET BirthDate = GETDATE() – 1

Pronto agora com as nossas conexões preparadas vamos inciar nosso Replay Trace e executar cada uma, para coletar os dados. Antes de iniciar nosso trace vamos dar uma olhada nas conexoes ativas no momento utilizando a Store Procedure SP_WHO2, conforme a imagem abaixo.

imagem4

Podemos observar as 4 conexões ativas através dos SPID´s 52,53,54,55. Para iniciar o Replay Trace iremos abrir o SQL Server Profiler criar um novo Trace especificando o template TSQL_Replay, especifique para salvar o trace em um arquivo como mostrado na imagem abaixo:

imagem1

Podemos visualizar após a definição do template TSQL_Replay as colunas e eventos selecionados por padrão, conforme mencionei acima clicando na aba Events Selection como mostrado na figura abaixo:

imagem2

Especifique um filtro para o DatabaseName Northwind, no botão Column Filters conforme abaixo.

imagem3

Após definir o Filtro clique em Run para iniciar o trace. Com o trace iniciado vamos executar todas as instruções em cada conexão começando pelo SPID 52 para começar a coletar os dados. Durante a execução do Trace a tela do Profile irá ficar conforme a imagem abaixo, espere até o Loop terminar e pare o trace. Para visualizar as outras instruções utilize a opção Find no menu Edit para localizar as instruções dentro da saída.

imagem5

Agora que temos o arquivo trace, precisamos importa-lo no segundo servidor para reproduzir o trace. Como mencionei acima para o Replay Trace ter sucesso em sua execução é preciso satisfazer algumas considerações como mesmos logins e senhas, banco de dados padrão para cada login utilizado no Trace, Database ID iguais ou coluna DatabaseName selecionada. Para reproduzir o trace faça um backup do Banco de dados Northwind e restaure o mesmo no segundo servidor, transfira o arquivo trace de qual será importado no SQL Server Profiler do nosso segundo servidor. Neste artigo não irei mostrar os detalhes de Backup e Restore, para uma completa informação veja no post SQL Server 2005 Backup e Recover.

Com o Banco de dados Northwind restaurado, iremos truncar a tabela ReplayTeste para eliminar os registros inseridos a partir do Loop. Com as outras instruções não precisamos nos preocupar pois o SPID 53 executa o comando DBCC CHECKDB para testar a integridade da base de dados, o SPID 54 executa uma instrução SELECT na tabela Orders, Order Details e Products e o SPID 55 executa um UPDATE na tabela Employees definindo sempre um valor diferente para a coluna Birthdate.

TRUNCATE TABLE ReplayTeste

Antes de importar o arquivo trace e reproduzi-lo vamos executar a store procedure SP_WHO2 para visualizarmos as conexões ativas conforme a imagem abaixo.

imagem6

Repare que apenas o SPID 52 estar ativo pois foi esta conexão que utilizamos para Restaurar Backup do Banco de dados Northwind, Truncar a tabela ReplayTeste e executar a store procedure SP_WHO2, agora vamos iniciar o SQL Server Profiler e importar o arquivo trace para reproduzir o trace. Após importar o arquivo trace clique no botão Start Trace para iniciar o trace, se conecte ao segundo servidor (no meu exemplo é SERVER02) e é aberto a tela Replay Configuration. Neste momento podemos especificar se queremos salvar o resultado de saída do trace para um arquivo ou uma tabela, se iremos executar o trace na sequencia exata de qual os eventos ocorreram no servidor, esta opção habilita Debugging ou se iremos utilizar multiplas threads para executar os eventos trace de qual otimiza a performance do servidor, podemos também definir quantas threads serão utilizadas e a ultima opção podemos selecionar se será exibido o resultado do trace. Deixei as configurações padrão conforme a imagem abaixo pois quero simular a mesma carga do servidor original.

imagem7

Na aba Advanced Replay Options podemos especificar algumas opções interessantes sobre o Replay Trace como definir se serão executados SPID´s do sistema e ainda especificar apenas um SPID em particular para executar, ou seja, podemos especificar que apenas uma conexão de usuário será executada. A imagem abaixo lista os SPID´s envolvidos no trace, reparem que é exatamente as mesmas conexões que abrimos para simular a atividade no banco de dados SPID 52,53,54 e 55. Abaixo temos a opção para limitar a execução do replay de acordo com uma determinada data e hora. Não irei selecionar para executar um SPID em particular para visualizarmos a atividade real com todas as conexões envolvidas. Desmarque a opção Replay one SPID only e clique em OK para iniciar o Replay Trace.

imagem8

Durante a execução do Trace a janela do SQL Server Profiler irá ficar mais ou menos conforme a imagem abaixo, notem que é exibido uma porcentagem da conclusão do Replay Trace, o painel é divido exibindo em sua parte superior o bloco de instruções sendo executadas, no meio os resultados.

imagem10

Antes de concluir a execução do trace alterne para o SQL Server Management Studio e execute a store procedure SP_WHO2 para visualizar as conexões existentes no momento da execução do trace, reparem na coluna ProgramName de qual indica as conexões através do SQL Server Profiler conforme imagem abaixo.

imagem9

Após a conclusão do Replay Trace é exibido os resultados no painel inferior como total de eventos executados, tempo gasto durante o Replay, total de erros, erros internos, etc.imagem11 

Para verificarmos que o Replay Trace foi executado com sucesso, podemos executar a seguinte instrução SELECT de qual irá retornar o número de linhas armazenadas na tabela ReplayTeste.

SELECT COUNT(*)
FROM ReplayTeste

———–
50000

(1 row(s) affected)

Pronto ! O Replay Trace foi executado com sucesso, foram inseridos as 50 mil linhas em nossa tabela de teste. Com isso concluo meu artigo sobre Replay Trace, mostrando algumas vantagens em utilizar essa poderosa feature disponível no SQL Server.

Até o próximo.

Advertisements

One Response to Coletando e Aplicando Workloads com Replay Trace

  1. Eleanore says:

    Way cool! Some very valid points! I appreciate you penning this article plus the rest of the website is extremely good.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: