Visão geral do SQL Server Distributed Replay
Aplica-se a: SQL Server 2016 (13.x) SQL Server 2017 (14.x) SQL Server 2019 (15.x)
Importante
O SQL Server Distributed Replay não está disponível no SQL Server 2022 (16.x).
O recurso Microsoft SQL Server Distributed Replay ajuda a avaliar o efeito de atualizações futuras do SQL Server. Também é possível usar esse recurso para ajudar a avaliar o efeito das atualizações de hardware e sistemas operacionais e ajuste do SQL Server.
Distributed Replay preterido no SQL Server 2022
O Distributed Replay foi preterido a partir do SQL Server 2022 (16.x), como observado em Recursos de mecanismo de banco de dados preteridos no SQL Server 2022 (16.x). O Distributed Replay tem uma dependência do SQL Server Native Client (SNAC), que foi removida do SQL Server 2022 (16.x). Essa alteração está documentada em Políticas de suporte para o SQL Server Native Client. Além disso, o Distributed Replay depende de arquivos .trc
, que são capturados com o Rastreamento do SQL e o SQL Server Profiler, que também foram preteridos.
O controlador do Distributed Replay foi removido da configuração do SQL Server 2022 (16.x), e o cliente Distributed Replay não está mais disponível no SQL Server Management Studio (SSMS) a partir da versão 18. Para obter o controlador do Distributed Replay, você deve instalar o SQL Server 2019 (15.x) ou uma versão anterior. Para obter o cliente Distributed Replay, você deve instalar o SSMS 17.9.1.
Para clientes no SQL Server 2022 (16.x), você pode usar utilitários de linguagem de marcação Replay (RML), que incluem ostress, para reproduzir uma carga de trabalho.
Benefícios do Distributed Replay
De modo semelhante ao SQL Server Profiler você pode usar o Distributed Replay para reproduzir um rastreamento capturado em um ambiente de teste atualizado. Diferentemente do SQL Server Profiler, o Distributed Replay não está limitado à reprodução da carga de trabalho de um só computador.
O Distributed Replay oferece uma solução mais escalonável do que o SQL Server Profiler. Com o Distributed Replay, é possível reproduzir uma carga de trabalho de vários computadores e simular melhor uma carga de trabalho de missão crítica.
O recurso Distributed Replay pode usar vários computadores para reproduzir dados de rastreamento e simular uma carga de trabalho de missão crítica. Use o Distributed Replay para teste de compatibilidade de aplicativo, teste de desempenho ou planejamento de capacidade.
Quando usar o Distributed Replay
O SQL Server Profiler e o Distributed Replay fornecem algumas funções sobrepostas.
Você pode usar o SQL Server Profiler para reproduzir um rastreamento capturado em um ambiente de teste atualizado. Também é possível analisar os resultados da repetição para procurar incompatibilidades de função e desempenho. No entanto, o SQL Server Profiler só pode reproduzir uma carga de trabalho de um só computador. Ao reproduzir um aplicativo com OLTP intensivo que tenha muitas conexões simultâneas ativas ou alta taxa de transferência, o SQL Server Profiler poderá se tornar um gargalo de recurso.
O Distributed Replay oferece uma solução mais escalonável do que o SQL Server Profiler. Use o Distributed Replay para reproduzir uma carga de trabalho de vários computadores e simular melhor uma carga de trabalho de missão crítica.
A tabela a seguir descreve quando usar cada ferramenta.
Ferramenta | Usar quando... |
---|---|
SQL Server Profiler | Você quiser usar o mecanismo de repetição convencional em um único computador. Em particular, você precisa de recursos de depuração linha a linha, como os comandos Etapa, Executar até o Cursore Ativar/Desativar Pontos de Interrupção . Você deseja repetir um rastreamento Serviços de análise . |
Distributed Replay | Você quiser avaliar a compatibilidade de aplicativo. Por exemplo, você deseja testar o SQL Server e os cenários de atualização de sistema operacional, atualizações de hardware ou ajuste de índice. A simultaneidade no rastreamento capturado é tão alta que um cliente de repetição não pode simular isso suficientemente. |
Conceitos do Distributed Replay
Os seguintes componentes fazem parte do ambiente do Distributed Replay:
Ferramenta de administração do Distributed Replay: um aplicativo de console, DReplay.exe, usado para se comunicar com o controlador de reprodução distribuída. Use a ferramenta de administração para controlar a reprodução distribuída.
Controlador do Distributed Replay: um computador que executa o serviço Windows denominado controlador Distributed Replay do SQL Server. O controlador Distributed Replay orquestra as ações dos clientes de reprodução distribuída. Cada ambiente de Distributed Replay pode conter apenas uma instância de controlador.
Clientes do Distributed Replay: um ou mais computadores (físicos ou virtuais) que executam o serviço Windows denominado Cliente do SQL Server Distributed Replay. Os clientes do Distributed Replay trabalham juntos para simular cargas de trabalho em uma instância do SQL Server do SQL Server. Pode haver um ou mais clientes em cada ambiente do Distributed Replay.
Servidor de destino: uma instância do SQL Server que clientes do Distributed Replay podem usar para reproduzir dados de rastreamento. Nós recomendamos que o servidor de destino seja localizado em um ambiente de teste.
A ferramenta de administração Distributed Replay, o controlador e o cliente podem ser instalados em diferentes computadores ou no mesmo computador. Só pode existir uma instância do serviço de cliente ou controlador do Distributed Replay em execução no mesmo computador.
A seguinte figura mostra para a arquitetura física do SQL Server Distributed Replay:
Tarefas do Distributed Replay
Descrição da tarefa | Artigo |
---|---|
Descreve como configurar o Distributed Replay. | Configurar o Distributed Replay |
Descreve como preparar os dados de rastreamento de entrada. | Preparar dados de rastreamento de entrada |
Descreve como reproduzir dados de rastreamento. | Reproduzir dados de rastreamento |
Descreve como revisar os resultados de dados de rastreamento de Distributed Replay. | Examinar os resultados da reprodução |
Descreve como usar a ferramenta de administração para iniciar, monitorar e cancelar operações no controlador. | Opções de linha de comando da ferramenta de administração (Distributed Replay Utility) |
Requisitos
Antes de usar o recurso Distributed Replay, considere os requisitos de produto que são descritos neste artigo.
Requisitos de rastreamento de entrada
Para repetir dados de rastreamento com êxito, ele deve atender os requisitos de versão e formato e conter os eventos e as colunas necessárias.
Versões de rastreamento de entrada
O Distributed Replay oferece suporte a dados de rastreamento de entrada que são coletados nas seguintes versões do SQL Server:
- SQL Server 2019 (15.x)
- SQL Server 2017 (14.x) (Atualização Cumulativa 1 e versões posteriores – confira Atualizações cumulativas do SQL Server 2017)
- SQL Server 2016 (13.x)
- SQL Server 2014 (12.x)
- SQL Server 2012 (11.x)
- SQL Server 2008 R2 (10.50.x)
- SQL Server 2008 (10.0.x)
- SQL Server 2005 (9.x)
Formatos de rastreamento de entrada
Os dados de rastreamento de entrada podem estar em qualquer um dos seguintes formatos:
Um único arquivo de rastreamento que tem a extensão
.trc
.Um conjunto de arquivos de rastreamento de substituição que siga a convenção de nomenclatura de substituição de arquivo, por exemplo:
<TraceFile>.trc
,<TraceFile>_1.trc
,<TraceFile>_2.trc
,<TraceFile>_3.trc
, ...<TraceFile>_n.trc
.
Eventos e colunas de rastreamento de entrada
Os dados de rastreamento de entrada devem conter eventos e colunas específicos a serem reproduzidos pelo Distributed Replay. O modelo TSQL_Replay no SQL Server Profiler contém todas as colunas e eventos necessários, além de informações extras. Para obter mais informações sobre esse modelo, consulte Replay Requirements.
Aviso
Se você não usar o modelo TSQL_Replay para capturar os dados de rastreamento de entrada, ou se os requisitos de rastreamento de entrada não forem atendidos, talvez receba resultados de reprodução inesperados.
Também é possível criar um modelo de rastreamento personalizado e usá-lo para reproduzir eventos com o Distributed Replay, desde que ele contenha os seguintes eventos:
- Auditar logon
- Audit Logout
- ExistingConnection
- RPC Output Parameter
- RPC:Completed
- RPC:Starting
- SQL:BatchCompleted
- SQL:BatchStarting
Se você estiver repetindo cursores de servidor, os seguintes eventos também serão necessários:
- CursorClose
- CursorExecute
- CursorOpen
- CursorPrepare
- CursorUnprepare
Se você estiver repetindo instruções SQL preparadas de servidor, os seguintes eventos também serão necessários:
- Exec Prepared SQL
- Prepare SQL
Todos os dados de rastreamento de entrada devem conter as seguintes colunas:
- Event Class
- EventSequence
- TextData
- Nome do Aplicativo
- LoginName
- DatabaseName
- ID do banco de dados
- HostName
- Binary Data
- SPID
- Start Time
- EndTime
- IsSystem
Rastreamento de entrada e combinações de servidor de destino com suporte
A tabela a seguir lista as versões com suporte dos dados de rastreamento e, para cada uma, as versões com suporte do SQL Server em que os dados podem ser repetidos.
Versão de dados de rastreamento de entrada | Versões com suporte do SQL Server para a instância do servidor de destino |
---|---|
SQL Server 2005 (9.x) | SQL Server 2008 (10.0.x), SQL Server 2008 R2 (10.50.x), SQL Server 2012 (11.x), SQL Server 2014 (12.x), SQL Server 2016 (13.x), SQL Server 2017 (14.x), SQL Server 2019 (15.x) |
SQL Server 2008 (10.0.x) | SQL Server 2008 (10.0.x), SQL Server 2008 R2 (10.50.x), SQL Server 2012 (11.x), SQL Server 2014 (12.x), SQL Server 2016 (13.x), SQL Server 2017 (14.x), SQL Server 2019 (15.x) |
SQL Server 2008 R2 (10.50.x) | SQL Server 2008 R2 (10.50.x), SQL Server 2012 (11.x), SQL Server 2014 (12.x), SQL Server 2016 (13.x), SQL Server 2017 (14.x), SQL Server 2019 (15.x) |
SQL Server 2012 (11.x) | SQL Server 2012 (11.x), SQL Server 2014 (12.x), SQL Server 2016 (13.x), SQL Server 2017 (14.x), SQL Server 2019 (15.x) |
SQL Server 2014 (12.x) | SQL Server 2014 (12.x), SQL Server 2016 (13.x), SQL Server 2017 (14.x), SQL Server 2019 (15.x) |
SQL Server 2016 (13.x) | SQL Server 2016 (13.x), SQL Server 2017 (14.x), SQL Server 2019 (15.x) |
SQL Server 2017 (14.x) | SQL Server 2017 (14.x), SQL Server 2019 (15.x) |
SQL Server 2019 (15.x) | SQL Server 2019 (15.x) |
Requisitos do sistema operacional
Os sistemas operacionais com suporte para a execução da ferramenta de administração e o controlador e os serviços cliente são os mesmos que sua instância do SQL Server . Para obter mais informações sobre quais sistemas operacionais têm suporte na instância do SQL Server , veja SQL Server 2016 e 2017: requisitos de hardware e software .
Os recursos do Distributed Replay têm suporte em sistemas operacionais x86 e x64. Para sistemas operacionais x64, somente há suporte para Windows no modo Windows (WOW).
Limitações de instalação
Qualquer computador pode ter apenas uma única instância de cada recurso do Distributed Replay instalado. A tabela a seguir lista a quantidade de instalações de cada recurso permitida em um único ambiente do Distributed Replay.
Recurso Distributed Replay | Máximo de instalações por ambiente de repetição |
---|---|
SQL Server Distributed Replay Controller | 1 |
SQL Server Distributed Replay Client | 16 (computadores físicos ou virtuais) |
Ferramenta de administração | Ilimitado |
Observação
Embora só uma instância da ferramenta de administração possa ser instalada em um único computador, você pode iniciar várias instâncias dessa ferramenta. Os comandos emitidos de várias ferramentas de administração são resolvidos na ordem em que são recebidos.
Provedor de dados do sistema
O Distributed Replay tem suporte apenas para o provedor de acesso a dados ODBC do SQL Server Native Client.
Requisitos de preparação do servidor de destino
Nós recomendamos que o servidor de destino seja localizado em um ambiente de teste. Para repetir dados de rastreamento em uma instância diferente do SQL Server da que foi originalmente registrada, verifique se as seguintes etapas foram executadas no servidor de destino:
Todos os logons e usuários contidos nos dados de rastreamento devem estar presentes no mesmo banco de dados no servidor de destino.
Todos os logos e usuários no servidor de destino devem ter as mesmas permissões que tinham no servidor original.
As IDs do banco de dados no destino devem, idealmente, ser idênticas àquela na origem. No entanto, se essas permissões não forem iguais, a correspondência poderá ser executada com base no DatabaseName se estiver presente no rastreamento.
O banco de dados padrão de cada logon contido nos dados de rastreamento deve estar configurado (no servidor de destino) para o respectivo banco de dados de destino do logon. Por exemplo, os dados de rastreamento a serem repetidos contêm atividade para o logon, Pedro, no banco de dados Pedro_Db na instância original do SQL Server. Portanto, no servidor de destino, o banco de dados padrão do logon Pedrodeve estar configurado para o banco de dados que corresponde a Pedro_Db (mesmo que o nome do banco de dados seja diferente). Para configurar o banco de dados padrão do logon, use o procedimento armazenado de sistema
sp_defaultdb
.
A repetição de eventos associados com logons faltantes ou incorretos resulta em erros de repetição, mas a operação de repetição continua.