Técnicas “Avançadas” de DEBUG no Oracle SQL DEVELOPER : Breakpoints, Data/Smart Data/Watches e Code Reduction

DEBUG no Oracle SQL DEVELOPER

No meu velho blog, eu falei sobre a utilização básica do debugger de PL/SQL contida na ferramenta Oracle SQL Developer (um IDE de programação, mas que também tem utilidade para Administradores de banco, desenvolvido pela Oracle e distribuído como freeware gratuito), na ocasião, apresentei os pré-requisitos para uso do debugger e dei um exemplo simples, apenas executando o código linha-a-linha.

É claro, isso é só a ponta do iceberg, há muitas funcionalidades mais no debugador incorporado no SQL DEVELOPER, o objetivo deste artigo é demonstrar algumas – o “Avançadas” (entre aspas) se deve ao fato que na verdade não são nada de complexo ou de alta demanda, são simples itens complementares, mas como alguns colegas não os conheciam, vou os apresentar neste artigo, com exemplos.

Vou supor aqui que o usuário conectado recebeu os GRANTs de DEBUG necessários, há uma porta de rede habilitada para o debugador, o programa PL/SQL (e TODAS as suas dependências) ESTÃO compilados em DEBUG MODE, e todas as outras condições que indiquei.

Para maior facilidade de uso, recomendo que o número de linha no editor de códigos esteja sendo exibido (confirme a opção de exibição de número de linhas no menu preferências, item fluxo da linha) :

E que as opções de exibição desejadas no item de menu Depurador (especialmente watches) estejam também ativas :

Seguem os exemplos:

BREAKPOINTs (condicionais ou não) e exibição de variáveis: Todo debugador que se preze possui esta capacidade, é simplesmente você indicar uma linha, um ponto do programa em que a execução vai ser interrompida momentaneamente, permitindo que você examine variáveis e reveja o fluxo do processamento.

Exemplo :

Recebi um erro de variável com valor impróprio na linha 270, para setar um breakpoint nessa linha basta clicar com o mouse

Para executar a rotina PL/SQL em debug, não é obrigatório mas eu prefiro abrir uma janela nova e encapsular a chamada em um bloco BEGIN/END, aí seleciono com o botão direito do mouse a chamada à rotina, clico com o botão esquerdo e no menu que se abre , escolho a opção Depurar.

Será exibida a tela abaixo, mostrando que a depuração está sendo feita num bloco anônimo.

Entro no bloco com F7 ou o botão , executo a linha da chamada com novo F7 ou com o mesmo botão novamente, e assim que começar a ser executada a rotina PL/SQL a ser debugada, a execução vai continuar até o breakpoint em questão, quando então a execução é pausada para podermos exibir variáveis e status.

Notar PRIMEIRO que nessas abas de dados e watches é que você consegue ver QUALQUER tipo de variável PL/SQL (arrays/collections, record types, escalares, qualquer uma) e SEGUNDO, o que é exibido é o stack completo. Se eu tivesse uma procedure P1 que chama a P2 que chama a P3 eu poderia (selecionando o método apropriado na pilha) enxergar as variáveis de P1, de P2 e/ou de P3…

Vou terminar a sessão de DEBUG com o botão e encerraremos este tópico com um BREAKPOINT CONDICIONAL. De volta ao editor de código, removo o breakpoint que já criei (basta clicar nele com o botão esquerdo do mouse), aí crio um novo breakpoint clicando numa linha qualquer e o transformarei em condicional , clicando nele com o botão direito do mouse e escolhendo Editar no menu.

Digamos que a condição desejada é que a variável V_POS seja igual a 10, eu informo isso.

Assim que entramos na execução da rotina, como agora é condicional o breakpoint, não queremos mais executar até um dado número de linha, assim usando o botão executo o método em debug até o final e a janela de breakpoint é exibida logo após a minha condição ter sido satisfeita.

Code Reduction (também conhecido como Code Folding, ou Code Contracting): É uma funcionalidade built-in do editor de códigos do Oracle SQL Developer, presente também em outras IDEs – simplória mas extremamente útil ao lidarmos com rotinas PL/SQL muito grandes, da ordem de milhares de linhas.

Vejamos este caso:

Tenho uma longa série de INSERTs (poderiam ser IFs ou quaisquer outros comandos), que é tão grande, ocupando tantas linhas, que nem sequer podemos ver o código inteiro na tela do editor.

Suponhamos que nós tenhamos CERTEZA que o bug não está dentro desse trecho, nós podemos “fechar” esses códigos na tela, ie, temporariamente fazer com que as linhas dentro dele sejam colapsadas. Para isso, basta clicar no sinal de – entre o número da linha e o comando, obtendo:

INFINITAMENTE mais manipulável, muito mais fácil para enxergar sem essas linhas no momento desnecessárias atrapalhando… É um recurso muito simples, mas que pode ser extremamente útil…

Evidentemente esses itens apresentados não esgotam o assunto de forma alguma. Temos muitos mais recursos no debugador do Oracle SQL Developer, como Grupos de Breakpoints, Pass Count breakpoints, traduzidos não muito propriamente como Contagem no Editor de Breakpoints, mas enfim, é um recurso que permite definir QUANTAS vezes o breakpoint deve ser ativado para só então efetivamente ele entrar em ação. Útil para debugar LOOPs longos.

A opção de MODIFICAR um valor de variável durante a sessão de DEBUG para fins de testes, uso de BINDs, exibição de saída do buffer controlada pela package DBMS_OUTPUT em janela separada, e outros, mas esses pontos ficarão para serem discutidos em artigos futuros.

Observação de Última hora: Todos os testes (no blog e neste artigo) foram feitos com versões abaixo do 12c – por questões de segurança, a partir do 12c conexões por rede externas ao banco como é o caso da que é feita pela interface Java do debugador passaram a exigir permissões extras, os chamados ACLs (Access Control Lists). Veja aqui como as providenciar, se você estiver usando essas versões de RDBMS Oracle.

Abraços