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

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.

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.

 

Nota DevMan 1. PL/SQL

PL/SQL é um acronismo para a expressão Procedural Language/Structured Query Language, sendo uma extensão da linguagem padrão SQL para o banco de dados Oracle.

É uma Linguagem Procedural da Oracle, estendida ao SQL. Permite que a manipulação de dados seja incluída em unidades de programas. Blocos de PL/SQL são passados e processados por uma PL/SQL Engine (máquina PL/SQL) que pode estar dentro de uma ferramenta Oracle ou do Servidor.

A PL/SQL Engine filtra os comandos SQL e o envia individualmente para o SQL Statement Executor (Executor de comandos SQL) no servidor Oracle, que processa o PL/SQL com os dados retornados do servidor.

 

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." [...] continue lendo...

Artigos relacionados