oracle real application testing solution test oracle db before moving production
Chegamos à parte final do série de testes de banco de dados Oracle.
Até agora, lidamos com métodos de teste do banco de dados Oracle. Continuando com esse foco, iremos mergulhar em mais detalhes com relação ao Oracle Real Application Testing.
Hoje vamos aprender o Oracle Real Application Testing - um sistema de garantia de mudança eficaz que avalia a mudança do sistema no próprio ambiente de teste antes de apresentá-lo à produção.
Esta é a solução líder da Oracle para capturar a carga de trabalho de banco de dados do ambiente de produção real e substituí-la em é meio ambiente .
Como afirmado em várias ocasiões, sempre precisamos ter certeza de que testamos o banco de dados em todas as dimensões possíveis para erradicar as instabilidades e para garantir que não encontramos problemas imprevistos em nossa instância de produção.
Podemos categorizar Oracle Real Application Testing em duas grandes seções:
- SQL Performance Analyzer
- Repetição de banco de dados
Antes de prosseguirmos, observe que o SQL Performance Analyzer e o Database Replay requerem licenciamento adicional, ou seja, estão disponíveis por um custo extra e uma opção Enterprise Edition.
O que você aprenderá:
SQL Performance Analyzer
A GUI usada para acessar o SQL Performance Analyzer e o Database Replay é o Enterprise Manager, conforme mostrado abaixo:
Para acessar o SQL Performance Analyzer, basta clicar no link “SQL Performance Analyzer”
(Clique na imagem para ver ampliada)
O SQL Performance Analyzer nos permite avaliar o impacto no desempenho de qualquer mudança no sistema que possa ter um impacto na execução e no desempenho do SQL.
Eles são extremamente úteis em casos como:
- Atualização de banco de dados, patching
- Alterações de configuração no sistema operacional - Software ou hardware
- Alterações nas estatísticas do Oracle Optimizer
- Mudanças de usuário / esquema
É sempre aconselhável executar a SQL Performance Analyze em um teste ou UAT (Teste de Aplicativo do Usuário) sistema em vez de em um sistema de produção. Visto que, ao testar os efeitos da mudança em termos de desempenho, podemos afetar inadvertidamente os usuários em execução na instância de produção. Além disso, executá-lo em um teste garantirá que não adulteremos nenhum processo atualmente em execução na produção.
PARA A visão geral básica de um fluxo de trabalho do SQL Performance Analyzer é mostrada abaixo:
A análise de desempenho do SQL envolve as seguintes etapas.
Passo 1)Captura de carga de trabalho SQL
Determine as instruções SQL que fariam parte de sua carga de trabalho SQL de sua instância de produção que você gostaria de analisar. Idealmente, essa carga de trabalho deve representar a carga de trabalho que você pode ter em sua produção.
Capturamos essas instruções em um conjunto de ajuste SQL e alimentamos esse conjunto de ajuste SQL para o SQL Performance Analyzer.
Como o Analyzer consome muitos recursos do sistema, sempre recomendamos executá-los em um sistema de teste ou UAT. Para executá-lo em um sistema de teste, teríamos que exportar o conjunto SQL Tuning que já criamos na produção para o sistema de teste.
Passo 2)Criação de uma tarefa do SQL Performance Analyzer
Para executar o Analyzer, você precisa primeiro criar uma tarefa do SQL Performance Analyzer. Esta tarefa nada mais é do que um repositório que consolida todos os dados sobre a análise executada pelo SQL Performance Analyzer. Conforme indicado anteriormente, o SQL Tuning Set é alimentado como um estimulante para o Analyzer.
como fazer o makefile c ++
Etapa 3)Teste de desempenho do SQL antes da mudança
Depois de criar a tarefa SQL Performance Analyzer e o SQL Tuning Set, precisamos construir a infraestrutura no sistema de teste.
Observe que, quando planejamos usar um sistema para teste, precisamos ter certeza de que é muito semelhante ao sistema de produção em termos de hardware, software e armazenamento para que possamos replicar um ambiente semelhante.
Uma vez que o sistema de teste está configurado apropriadamente, podemos construir a versão anterior à alteração dos dados usando o SQL Performance Analyzer.
Isso pode ser alcançado usando o Enterprise Manager ou APIs (procedimentos embutidos).
Passo 4)Teste de desempenho do SQL pós-mudança
A avaliação Post-Change é realizada no sistema de teste depois de fazer algumas alterações no sistema.
Depois de concluído, teríamos dois testes SQL - um teste pré-mudança e um teste pós-mudança para comparar.
Semelhante ao teste de desempenho Pre-Change SQL, podemos criar um teste de desempenho Post-Change SQL usando Enterprise Manager ou APIs (procedimentos embutidos).
Etapa 5)Gerando um Relatório
Depois de executar os testes de pré-alteração e pós-alteração, os dados de desempenho coletados neles podem ser comparados executando uma análise de comparação usando o SQL Performance Analyzer.
Assim que esta tarefa de comparação for concluída, podemos gerar um relatório para identificar o desempenho da instrução SQL que fazia parte da carga de trabalho que pretendíamos testar.
Ao revisar o relatório, podemos julgar e tirar conclusões sobre o desempenho do SQL
Declarações e, em seguida, implantar as alterações do sistema na produção.
Da mesma forma, podemos testar várias cargas de trabalho com várias alterações de sistema e garantir que testamos cada uma delas antes de implementá-las na produção.
O fluxo de trabalho ilustrado acima pode ser representado graficamente conforme mostrado abaixo.
Repetição de banco de dados
Para executar a ferramenta por meio do Enterprise Manager:
(Clique na imagem para ver ampliada)
O Database Replay permite testes realistas de mudanças no sistema, essencialmente replicando seu ambiente de produção em um sistema de teste. Ele faz isso capturando uma carga de trabalho desejada no sistema de produção e reproduzindo-a em um sistema de teste com as características exatas dos recursos da carga de trabalho original, como execução de SQL, transações, extrações e procedimentos.
Isso é realizado para garantir que consideramos todos os impactos possíveis de qualquer alteração, incluindo resultados indesejados, como bugs do produto, resultados inadequados ou regressão de desempenho.
Análise extensiva e relatórios gerados também ajudam a identificar quaisquer problemas potenciais, como circunstâncias incorretas encontradas e divergências de desempenho.
Como resultado, as organizações podem ficar tranquilas ao lidar com mudanças e serem lucrativas ao avaliar o sucesso geral da mudança do sistema. Isso reduzirá significativamente qualquer risco quando quisermos implementar as mudanças na produção. A mudança é inevitável e certificar-se de que testamos todos os aspectos dessa mudança em todos os níveis tornará a produção mais robusta e robusta.
Um fluxo de trabalho básico da reprodução do banco de dados é mostrado abaixo:
As alterações suportadas pelo Database Replay são:
- Atualizações de banco de dados Oracle, patch de software
- Usuário / esquema, instância de banco de dados Parâmetros como memória, E / S
- Alterações de hardware / software em nós RAC (Real Application Cluster)
- Alterações do sistema operacional, patch do sistema operacional
- CPU, memória, armazenamento
O Database Replay nos permite testar vários efeitos de possíveis mudanças no sistema, reproduzindo a carga prática de um sistema de produção real em um sistema de teste antes de ser exposto ao anterior. A carga de trabalho na produção é monitorada, analisada e registrada em um período de tempo quantitativo fixo. Esses dados são registrados ao longo do tempo e são usados para reproduzir a carga de trabalho em sistemas de teste.
Fazendo isso, podemos testar com êxito as implicações da carga de trabalho antes de implementar quaisquer alterações que possam afetar negativamente a produção.
O fluxo de trabalho é o seguinte:
Passo 1) Captura de carga de trabalho
Registramos todas as solicitações feitas pelos clientes em arquivos denominados “Arquivos de captura” no sistema de arquivos (armazenamento). Esses arquivos contêm todas as informações vitais sobre as solicitações do cliente, como SQL, binds, procedimentos e informações de transação. Esses arquivos podem ser exportados para qualquer sistema, caso desejemos reproduzi-los em outro sistema.
Passo 2)Pré-processamento de carga de trabalho
Depois de capturar as informações nos “Arquivos de captura”, precisamos pré-processá-los. Nesta etapa, criamos metadados que fornecem uma descrição de todos os dados necessários para reproduzir a carga de trabalho.
Uma vez que esta etapa usa uma grande quantidade de recursos do sistema, é aconselhável executar em outro sistema além da produção, onde a carga pode ser reproduzida. No caso, você não tem outro sistema para testar e gostaria de executá-los em produção, certifique-se de executá-los fora dos horários de pico para que os usuários e processos em execução na produção não sejam afetados.
Etapa 3)Repetição de carga de trabalho
Agora, podemos reproduzi-los no sistema de teste. Neste momento, reproduzimos todas as transações, contexto, procedimentos e SQL que foram capturados inicialmente durante a fase de captura, acumulando dados conforme cada processo passa por essa transição.
Passo 4)Gerando relatórios
Semelhante ao Performance Analyzer, você também pode gerar e visualizar relatórios para comparar cada um dos testes que você executou.
Para concluir, oferecemos algumas dicas rápidas ao testar o Database Replay:
- Use o sistema de teste idêntico como e quando possível
- Teste uma mudança de cada vez para entender seu impacto
- Certifique-se de começar com as opções de reprodução padrão e, em seguida, faça as alterações, se necessário, com base em seus requisitos.
- Antes de realizar a segunda reprodução, certifique-se de compreender todos os aspectos de teste
- Certifique-se de salvar os resultados do teste e documentar todas as alterações / ações de teste necessárias
- Certifique-se de que nenhuma outra carga de trabalho ou usuários estejam usando o sistema durante qualquer uma das execuções de teste
Conclusão:
Com vários aspectos e vários métodos de banco de dados Oracle e teste de aplicativos, sempre certifique-se de testar com a maior freqüência e exaustividade possível; compreender o aplicativo e o ambiente do usuário antes de implantar quaisquer alterações ou introduzir novos parâmetros na produção.
Leitura recomendada
- Melhores ferramentas de teste de software 2021 (QA Test Automation Tools)
- Diferença entre Desktop, Teste de Servidor Cliente e Teste da Web
- Como testar o banco de dados Oracle
- Guia de teste de segurança de aplicativos da Web
- Teste de aplicativos - Noções básicas de teste de software!
- Instalando seu aplicativo no dispositivo e comece a testar no Eclipse
- Download do e-book do Testing Primer
- Tutorial de teste destrutivo e teste não destrutivo