Criando um ambiente real de testes com o Oracle Real Application Testing “caseiro” no Oracle 10g

Esse artigo faz parte da revista SQL Magazine edição 67. Clique aqui para ler todos os artigos desta edição

Criando um ambiente real de testes com o Oracle Real Application Testing “caseiro” no Oracle 10g

A Oracle criou o Real Application Testing na versão 11g, uma funcionalidade realmente bastante interessante que irá, com certeza, economizar muito de seu tempo quando você precisar efetuar testes dos códigos sql de sua aplicação, principalmente quando se tratar de upgrades, aplicação de patchs, migrações, etc.

O Real Application Testing, com o Oracle Database 11g Enterprise Edition, permite que as empresas adotem novas tecnologias de maneira rápida enquanto elimina os riscos associados com mudanças. Ele combina captura de carga de trabalho no banco de dados e funcionalidade de repetições (replay) com o SQL Performance Analyzer para ajudar o DBA a testar qualquer mudança em um ambiente exatamente como o ambiente real de produção.

Com este ambiente devidamente montado, será efetivo o trabalho de ajuste fino (fine tune) das alterações antes mesmo de implementá-las em produção, reduzindo assim um série de dores de cabeça”no ambiente real de trabalho da aplicação.

Ele suporta ainda versões anteriores do banco de dados. Empresas que possuam bases de dados nas versões 9i ou 10g podem usufruir do Real Application Testing para acelerar o processo de upgrade para a versão 11g.

Podemos destacar como grandes benefícios do Real Application Testing:

·     Uso de carga de trabalho real: Repetição de carga de trabalho efetivamente real, sem utilizar amostragens ou cargas artificiais;

·     Abrangente: Cobre 100% do ciclo de vida das alterações;

·     Escalável: Requer esforço similar tanto em pequenos quanto em grandes ambientes;

·     Prognosticável: Transfere a solução exata das mudanças do teste para a produção;

·     Redução de custos: Reduz os esforços de teste em até 80%.

Como o Real Application Testing funciona?

Basicamente ele captura a carga de trabalho (comandos SQL e DML) no seu ambiente de produção e executa tudo novamente em outra instância (seu ambiente de testes), permitindo que você possa comparar tempos de execução, utilização de I/O, CPU e também os planos de execução.

O Oracle permite também que você utilize esta ferramenta entre um banco de dados na versão 10g (release 10.2.0.4) em um banco de dados 11g, o que significa dizer que você pode capturar a carga de trabalho de um banco de dados 10g e testá-la em um banco de dados 11g, mas não é possível utilizar a ferramenta para testar entre dois bancos de dados 10g.

Porém, considerando que a versão 11g ainda possui pouco “tempo de estrada” e ainda levará um certo tempo até que façamos o upgrade para esta versão, mas inspirados com esta nova funcionalidade da versão 11g, decidimos criar o nosso próprio Real Applicatoin Testing que nos permitirá fazer praticamente a mesma coisa entre bancos de dados 10g ou 11g. O banco de dados em si não fará diferença.

A ferramenta Oracle é baseada em PL/SQL (Nota DevMan 1) e um novo binário, que é capaz de não só repetir a carga de trabalho mas também é possível simular cenários diferentes, como aumentar o número de usuários executando as consultas.

Neste primeiro desenvolvimento que fizemos, criamos apenas o repetidor de carga de trabalho (workload replay) baseado no dobro de execuções, para cada consulta, o que significa dizer que se a consulta foi executada 10 vezes no ambiente de produção, iremos executá-la 20 vezes no ambiente de testes.

Existem duas razões básicas para isso: a primeira é para “estressar” o ambiente de testes e a segunda é para minimizar o aumento de utilização de recursos que o processo de replay pode causar ao executar as consultas. O que queremos dizer é que durante a fase de replay, quando ligando e processando as consultas, podemos ter um aumento de 10% a 200% na utilização de recursos, dependendo do número de bind variables (Nota DevMan 2) portanto, aumentando a estatística, as execuções são minimizadas e a utilização de recursos se torna praticamente insignificante.

Até este momento isto é o suficiente para efetuarmos uma boa carga de testes e fazer com que as mudanças no ambiente de produção sejam exaustivamente testadas.

Pretendemos, num futuro próximo, incluir outros tipos de replay exatamente como a versão 11g faz, capturando inclusive outros tipos de estatísticas para termos um relatório de comparações mais detalhado.

Antes de iniciar

Antes de qualquer coisa, precisamos preparar os ambientes de produção e teste. Consideramos aqui que o banco de dados de teste é um clone do banco de dados de produção, vamos apenas criar os devidos links e instalar as procedures necessárias. Para isso, siga os passos abaixo:

1)     Adicione uma entrada no arquivo tnsnames.ora nos dois lados, banco de dados de produção e teste, um apontando para o outro, ou seja, no tnsnames.ora do servidor do banco de dados de produção adicione uma entrada para o banco de dados de teste e vice-versa;

2)     Execute o script SQL67_RapInstall.sql nos dois ambientes, como usuário com privilégios de DBA, como mostra a Listagem 1. Todos os scripts utilizados neste artigo estão disponíveis para download no portal da SQL Magazine.

Listagem 1. Executando o script SQL67_RapInstall.sql como usuário DBA.

SQL> conn SYSTEM/******

SQL> @SQL67_RapInstall.sql

O script SQL67_RapInstall.sql irá criar um usuário chamado “RAP”, concedendo os devidos privilégios e finalmente criar as tabelas/índices necessários para a captura da carga de trabalho.

...