Depurando instruções SQL

A arquitetura cliente/servidor é utilizada na maioria dos servidores de bancos de dados atuais, onde uma aplicação chamada de cliente envia requisições para o servidor de banco de dados por meio de instruções SQL e aguarda tanto a execução desta instrução como o retorno do conjunto de dados, caso a instrução SQL enviada gere tais dados.

Os mecanismos de acesso que permitem a uma aplicação se conectar ao servidor de banco de dados, e enviar instruções SQL, algumas vezes manipulam a instrução SQL enviada para o servidor de banco de dados. Em algumas situações esta manipulação tem como objetivo preparar a instrução SQL para se obter algum ganho de desempenho em sua execução. Neste artigo veremos como identificar e analisar as modificações feitas por alguns mecanismos de conexão nas instruções SQL enviadas para o SQL Server 2000 com o objetivo de facilitar a tarefa de depurar a instrução SQL que foi enviada para o servidor de banco de dados.

Capturando a instrução SQL

A maioria dos servidores de bancos de dados disponível no mercado, sejam eles de código livre ou não, possuem uma maneira de capturar as instruções que estão sendo enviadas pelas aplicações clientes, sejam elas páginas dinâmicas, componentes ou aplicações desktop.

O SQL Server possui uma aplicação própria chamada Profiler para a tarefa de capturar as instruções que estão sendo enviadas para o banco de dados. Já o MySQL e o Oracle trabalham com parâmetros que habilitam a gravação de logs que contêm as instruções enviadas pelas aplicações. A análise deste tipo de informação geralmente é feita durante o desenvolvimento da aplicação, onde os desenvolvedores ainda estão testando e depurando as instruções SQL que manipulam os dados armazenados no servidor de banco de dados. Neste artigo utilizaremos o Profiler, já abordado na revista SQL Magazine no artigo de duas partes chamado “Profiler: Criando um trace para análise de performance de um servidor SQL Server” escrito por Paulo Ribeiro nas edições 11 e 12 da SQL Magazine.

O Profiler permite que criemos um trace, isto é, uma definição de tipo de evento que desejamos capturar, e especificar alguns filtros sobre as propriedades dos eventos para evitar sobrecarga no servidor durante a execução do aplicativo. Para iniciar a captura de eventos no Profiler, basta iniciar a aplicação, que está dentro do conjunto de programas criado no momento da instalação do SQL Server, escolher o menu “File” e a opção “New...”, seguida da sub-opção “Trace...”. A seguir o Profiler solicita um login do SQL Server para se conectar. Devemos fornecer um login que pertença ao papel fixo de servidor (fixed server role) sysadmin, pois este tipo de captura de eventos pode relevar informações sensíveis como, nomes de stored procedures internas da aplicação ou valores de parâmetros não criptografados enviados ao servidor. A janela de configuração de propriedades do trace é apresentada a seguir, conforme mostra a Figura 1

Figura 1. Janela de configuração de propriedades do Trace.

Na janela apresentada na Figura 1 as abas “Events”, “Data Columns” e “Filters” permitem a especificação de filtros e ordenação dos eventos a serem capturados por este trace. Na aba “General” podemos indicar que os eventos capturados pelo trace podem ser armazenados em uma tabela do SQL Server ou mesmo em um arquivo texto, para análises posteriores.

A partir do momento em que este trace é iniciado, o Profiler captura todas as instruções SQL que estão chegando ao servidor proveniente das aplicações que acessam alguma base de dados no SQL Server. ...