Embed Size (px)
Citation preview
Curso de Engenharia de Computação
TESTES DE DESEMPENHO REALIZADOS NA
ATUALIZAÇÃO DE VERSÕES DOS SOFTWARES DE
BANCO DE DADOS ORACLE 9I PARA VERSÃO 10G
Vinícius Vieira Heringer
Itatiba – São Paulo – Brasil
Dezembro de 2008
ii
Curso de Engenharia de Computação
TESTES DE DESEMPENHO REALIZADOS NA
ATUALIZAÇÃO DE VERSÕES DOS SOFTWARES DE
BANCO DE DADOS ORACLE 9I PARA VERSÃO 10G
Vinícius Vieira Heringer
Monografia apresentada à disciplina Trabalho de Conclusão de Curso, do Curso de Engenharia de Computação da Universidade São Francisco, sob a orientação do Prof. Dr. Adalberto Nobiato Crespo, como exigência parcial para conclusão do curso de graduação. Orientador: Prof. Dr. Adalberto Nobiato Crespo
Itatiba – São Paulo – Brasil
Dezembro de 2008
iii
TESTES DE DESEMPENHO REALIZADOS NA
ATUALIZAÇÃO DE VERSÕES DOS SOFTWARES DE
BANCO DE DADOS ORACLE 9I PARA VERSÃO 10G
Vinícius Vieira Heringer
Monografia defendida e aprovada em 10 de Dezembro de 2008 pela Banca Examinadora
assim constituída:
Prof. Dr. Adalberto Nobiato Crespo (Orientador)
USF – Universidade São Francisco – Itatiba – SP.
Prof. Ms. Raimundo Claudio da Silva Vasconcelos
USF – Universidade São Francisco – Itatiba – SP.
Prof. Angelo Amaral
USF – Universidade São Francisco – Itatiba – SP.
iv
"Eu errei mais de 9000 arremessos durante minha carreira. Eu perdi quase 300 jogos. Em 26 ocasiões fui encarregado de acertar o último arremesso, que tornaria nosso time vencedor... mas eu errei. Eu tenho errado mais e mais durante minha vida. E esse é o motivo que me fez ser um vencedor". (Michael Jordan)
v
SUMÁRIO
Lista de Siglas............................................................................................................................vi Lista de Figuras ........................................................................................................................vii Resumo ....................................................................................................................................viii Abstract....................................................................................................................................viii 1 INTRODUÇÃO..................................................................................................................1
1.1 Desenvolvimento de software ....................................................................................1 1.1.1 Modelo em cascata .............................................................................................1
1.2 Teste de software ........................................................................................................3 1.2.1 Técnicas de Teste................................................................................................3 1.2.2 Níveis de Teste ...................................................................................................4
1.3 Banco de dados Oracle ...............................................................................................5 1.4 SQL.............................................................................................................................5 1.5 Motivações .................................................................................................................6 1.6 Objetivo ......................................................................................................................6
2 ESTUDO DE CASO ..........................................................................................................7 2.1 Ambientes do sistema.................................................................................................8 2.2 Diferenças entre as versões do software.....................................................................9
2.2.1 Descrição dos parâmetros e funções.................................................................10 3 TESTES............................................................................................................................13
3.1 Primeiros procedimentos ..........................................................................................13 3.2 Upgrade do banco de dados......................................................................................14 3.3 Documentação do upgrade .......................................................................................15 3.4 Cenários de Testes ....................................................................................................15 3.5 Baseline ....................................................................................................................16 3.6 Teste inicial...............................................................................................................16 3.7 Teste final .................................................................................................................17 3.8 Resultados dos testes ................................................................................................17 3.9 Handoff.....................................................................................................................18
4 CONCLUSÃO..................................................................................................................19 4.1 Extensões ..................................................................................................................19
Anexo 1 – Comparação de parâmetros.....................................................................................20 Anexo 2 – Documento de Handoff...........................................................................................22 Anexo 3 – Resultados dos Testes .............................................................................................24 Referências Bibliográficas........................................................................................................26 Bibliografias Consultadas.........................................................................................................27
vi
Lista de Siglas
ANSI American National Standards Institute CPU Central Processing Unit CRM Customer Relationship Management DB2 Database 2 DBA Database Administrator DBUA Database Upgrade Assistant ERP Enterprise Resource Planning IBM International Business Machines Corporation ISO International Organization for Standardization LCR logical change record NIST National Institute of Standards & Technology SGA System Global Area SGDBR Sistema Gerenciador de Banco de Dados Relacional SMS Short Message Service SQL Structured Query Language TI Tecnologia da Informação
vii
Lista de Figuras
FIGURA 1 – Ciclo de Vida de Desenvolvimento.......................................................................2 FIGURA 2 – Relação entre Ciclos de Desenvolvimento e Níveis de Teste...............................5 FIGURA 3 – Esboço da arquitetura do Sistema.........................................................................8 FIGURA 4 – Ambientes do PageIT............................................................................................9
viii
HERINGER, Vinicius Vieira. Testes de Desempenho Realizados na Atualização de Versões
dos Softwares de Banco de Dados Oracle 9i para Versão 10g. Monografia – Curso Engenharia
de Computação da Universidade São Francisco, Campus Itatiba.
Resumo
Esta monografia aborda os principais conceitos de teste e através de um estudo de caso
apresenta os testes de desempenho realizados na atualização de versões de software do Banco
de Dados Oracle versão 9i para versão 10g.
PALAVRAS-CHAVE: ORACLE, TESTE, ATUALIZAÇÃO
Abstract
This monograph covers the main concepts of software testing and through a case study
presents the performance tests conducted on a Oracle Database Server software upgrade from
version 9i to 10g.
KEY-WORDS: ORACLE, TEST, UPGRADE
1
1 INTRODUÇÃO
Neste capítulo são apresentados o contexto, uma breve explicação técnica, as
motivações e os objetivos deste trabalho - Testes de Desempenho Realizados na Atualização
de Versões dos Softwares de Banco de Dados Oracle 9i para Versão 10g.
Nos demais capítulos serão apresentados o estudo de caso referente ao tema
proposto e sua conclusão.
1.1 Desenvolvimento de software
O processo de software pode ser caracterizado em atividades baseadas em estrutura
de processos, que são aplicadas em projetos de software. Estas estruturas são subdivididas em
conjunto de tarefas, e estas tarefas englobam as atividades de especificação dos requisitos do
software, da criação das estruturas do projeto, da instalação do software, dos testes e a
integração entre usuários, ferramentas e métodos.
Modelo de processos são estratégias de desenvolvimento utilizadas para gerenciar e
acompanhar a evolução do desenvolvimento do software. Cada modelo é escolhido de acordo
com a natureza do software. Os modelos de processos mais conhecidos são: Modelos ciclo de
vida, Seqüencial ou Cascata, Desenvolvimento iterativo e incremental, Evolucional ou
Prototipação, V-Model, Espiral, Componentizado e Quarta geração.
O modelo utilizado para o desenvolvimento deste trabalho foi o modelo em cascata,
por ser utilizado na empresa no qual foi realizado o estudo de caso.
1.1.1 Modelo em cascata
Segundo Rakitin o modelo em cascata é o mais familiarizado dentre os modelos de
desenvolvimento de software [1].
Este modelo é constituído de um modelo seqüencial onde cada fase depende do
término da fase anterior, para que a próxima se inicie. Estas fases podem ser dividas em
subfases, cada qual com seus requisitos e objetivos, porém sempre obedecendo à regra de
seqüencialidade. A eficácia deste modelo depende da precisão na documentação criada de
2
uma fase para outra, quanto mais informações detalhadas este documento possuir maior será a
chance de sucesso do seu ciclo de vida. Ao término de cada fase é realizada uma revisão dos
dados de entrada e saída para determinar se as informações estão adequadas.
Figura 1 Ciclo de Vida de Desenvolvimento
A figura 1 apresenta as 6 fases do ciclo de vida de desenvolvimento do modelo em
cascata. Abaixo estão descritas cada uma delas:
• Análise de Requisitos: Esta fase tem como objetivo coletar todas as
informações referentes às regras e funções que o software deverá possuir,
quais as interfaces, a performance exigida pelo produto e como o software
deverá se comportar. Estes requisitos são coletados através de entrevistas
com os clientes e também pelos processos de negócio. Após colher estas
informações, os dados são analisados e documentados para serem usados
como guia na próxima fase.
3
• Projeto: Esta fase tem como objetivo processar os requisitos coletados e
transformá-los em modelos e estruturas de software, os quais serão utilizados
posteriormente pela fase de codificação. Após a documentação desta fase, a
mesma torna-se parte da configuração do software.
• Codificação: A fase de codificação tem como objetivo transformar os
modelos e estruturas de software em linguagem de máquina.
• Testes: Após a finalização da codificação inicia-se o processo de testes. Este
processo tem como objetivo assegurar que a lógica do software esteja
correta, testando toda a codificação desenvolvida, para que as informações
inseridas retornem o resultado esperado, e para que este resultado esteja de
acordo com os requisitos desejados.
• Implementação: é a fase em que os módulos são integrados e o software é
instalado.
• Manutenção: é a fase que vem após a instalação do software, é nesta fase que
são corrigidos os defeitos, onde variáveis de ambiente são ajustadas para que
o software se adéqüe a um novo hardware e/ou a um novo sistema
operacional, é nesta fase também que são adicionadas novas funcionalidades
e realizadas melhorias em relação ao seu desempenho.
1.2 Teste de software
Teste de Software está localizado dentro do escopo de Qualidade de Software, esta
etapa é extremamente crítica e tem como objetivo assegurar que requisitos, projeto e
codificação realizada no ciclo de desenvolvimento [2] se comportem de acordo com o que era
esperado.
1.2.1 Técnicas de Teste
Existem duas técnicas de teste, a técnica estrutural conhecida como caixa-branca e
técnica funcional conhecida como caixa-preta. A técnica estrutural leva em consideração a
estrutura interna da codificação do software, seu objetivo é identificar os defeitos nesta
4
estruturas. A técnica funcional verifica se os valores de entrada e saída atendem aos requisitos
do software.
1.2.2 Níveis de Teste
Conforme ilustra a figura 1-2, os Testes de Softwares possuem quatro níveis
relacionados à fase de Testes:
• Teste de Unidade tem como foco garantir que o módulo corresponda ao seu
projeto, testa os módulos do software;
• Teste de Funcionalidade tem como foco verificar se as principais funções do
software funcionam corretamente;
• Teste de Sistema tem como foco verificar o sistema como um todo,
enxergando-o como uma única entidade [3], testar todas as suas
funcionalidades uma a uma de uma forma mais completa que o Teste de
Funcionalidade, fazendo carga de dados, testes de estresse, teste de
segurança, teste de desempenho;
• Teste de Integração tem como foco testar a integração de todos os módulos
do sistema, se cada módulo está produzindo os parâmetros de entrada e saída,
e se eles comunicam-se de acordo com o que foi projetado.
A figura 1-2 apresenta também um quinto nível relacionado à fase de Manutenção
que pertence ao Ciclo de Desenvolvimento. Ele é conhecido como Teste de Regressão, este
nível tem como objetivo avaliar o produto em suas condições reais de funcionamento, testar
as novas funcionalidades desenvolvidas após a entrega do software, testar códigos
desenvolvidos para correções de falhas, avaliar se novas versões de software ou
funcionalidades são compatíveis com as versões anteriores.
5
Figura 2 Relação dos Ciclos de Desenvolvimento e Níveis de Teste
1.3 Banco de dados Oracle
Banco de Dados Oracle é um banco de dados objeto relacional, onde os dados são
armazenados em tabelas bi-dimensionais compostas por linhas e colunas [4]. O Banco de
Dados Oracle, além do armazenamento de dados, permite sua consulta e atualização através
da linguagem SQL.
O gerenciamento do banco de dados Oracle é realizado através de um software
conhecido como Servidor Oracle. Este software é composto por um Banco de Dados e por
uma instância Oracle. Uma instância Oracle por sua vez é uma combinação entre estruturas de
memória e processos em segundo plano [5].
1.4 SQL
SQL é uma linguagem que foi desenvolvida pela IBM Research, e redefinida pela
ISO/ANSI como linguagem padrão para os SGDBRs. Ela é utilizada para acessar e manipular
os dados armazenados nas tabelas.
6
1.5 Motivações
Segundo um estudo realizado pelo NIST em 2002 [6], o governo dos Estados
Unidos teve prejuízo anual de 59,5 bilhões de dólares causados somente com falhas ou erros
encontrados nos softwares. Mais de um terço deste valor poderia ser poupado se houvesse
uma melhoria na infra-estrutura que realiza a previsão, detecção e remoção destes defeitos.
Atualmente mais da metade dos erros são detectados apenas no final do processo de
desenvolvimento e na pós-venda.
A principal motivação desta monografia sobre atualização de versões de software do
servidor de banco de dados Oracle é estudar a teoria relacionada aos testes de regressão, e
através de um estudo de caso, entender porque são utilizados os testes de desempenho.
1.6 Objetivo
Este trabalho tem como objetivo apresentar um estudo de caso relacionado aos testes
de desempenho, realizado no nível de teste de regressão, e sua importância na atualização de
versões do software de Banco de Dados Oracle.
7
2 ESTUDO DE CASO
O estudo de caso analisado é baseado em um sistema de gerenciamento de
mensagens.
O sistema completo é divido em duas aplicações, ambas com interface WEB,
conhecidas como PageIT e Datapoint. A aplicação PageIT é responsável pelo envio e
recebimento das mensagens que tem como destino os profissionais de TI da empresa. O texto
enviado pelo PageIT pode ser originado por mensagens enviadas por rádio, SMS, por usuários
que acessam a aplicação via WEB ou podem ser originadas pela aplicação Datapoint.
O conteúdo destas mensagens varia de acordo com o destinatário, podendo ser
convocações para reuniões de última hora, problemas detectados nos sistemas suportados por
estes profissionais, mensagem com solicitações de reparos em hardware, suporte em
software, suporte em banco de dados etc. O PageIT armazena no seu banco de dados apenas
as mensagens recebidas nos últimos 7 dias, armazena também todas as informações referentes
ao números de rádios, seus donos e departamentos.
O Datapoint é uma aplicação que monitora todos os servidores da empresa que estão
conectados a rede. Estes servidores podem ser de plataformas distintas e para fins distintos,
como servidores Windows, Unix, Mainframe, servidores para banco de dados Oracle, SQL
Server, DB2, ou servidores de aplicações como Oracle 11i, aplicações WEB, ERP, CRM, etc.
Todos estes sistemas são monitorados em tempo real e se qualquer um deles apresentar mau
funcionamento, uma mensagem referente ao problema é enviada com as informações do
problema a ser verificado. A mensagem é enviada para o PageIT e este redireciona a
mensagem para o seu destinatário. O meio de transmissão é por uma central de rádio e celular.
O Datapoint permite também o envio de mensagens via WEB. Estas mensagens não são
armazenadas no banco de dados do PageIT, elas são armazenadas no banco de dados do
próprio Datapoint.
O PageIT é extremamente crítico para a empresa, pois é o único responsável pelas
mensagens enviadas para o suporte de TI, caso o sistema fique indisponível o suporte
oferecido por estes profissionais fica comprometido.
8
A figura 2 mostra um esboço da arquitetura do sistema. O PageIT e o Datapoint
utilizam a arquitetura multi-tier ou multicamadas, sendo que a primeira camada são os
usuários, eles conectam na internet e através de um browser acessam a aplicação WEB. A
segunda camada é aplicação em si. A terceira camada é o servidor WEB. O servidor WEB
fornece os serviços para a aplicação WEB e é nesta camada que está a lógica de negócio, é no
servidor WEB também que estão instalados os clientes para a conexão com o banco de dados.
A quarta camada é a camada do Servidor de Banco de Dados. A central de Radio e Celular
são hardwares separados do sistema e a comunicação entre eles é feita através da rede.
Figura 3 Esboço da arquitetura do Sistema
2.1 Ambientes do sistema
O PageIT possui três tipos de ambientes: ambiente de Desenvolvimento, ambiente
de Testes e ambiente de Produção. A figura 2-1, apresenta os três tipos de ambientes, que
possuem a mesma configuração de hardware e software.
9
Ambiente de Desenvolvimento é o local onde são desenvolvidos os novos
aplicativos ou novas funções que serão incorporadas ao sistema em produção. Ambiente de
Teste é o ambiente onde são realizados os testes das novas funções ou novas versões de
software. O ambiente de Produção é o ambiente que está em operação e é por este ambiente
que os usuários fazem suas conexões e acessam suas informações.
Figura 4 Ambientes do PageIT
2.2 Diferenças entre as versões do software
Houve diversas mudanças entre as versões do Oracle 9i e 10g, parâmetros foram
descartados, falhas foram corrigidas e novas funções foram adicionadas.
Dentre as novas funções estão os parâmetros: streams_pool_size, statistics_level e
recyclebin, como também a adição de uma nova tablespace SYSAUX para a instalação dos
novos objetos. Há também alguns parâmetros que deverão ser alterados para que novas
funções entrem em vigor, são os parâmetros compatible, java_pool_size, large_pool_size e
session_max_open_files. Há também alguns parâmetros que foram descartados, dentre eles
destacam-se três: enqueue_resources, log_archive_start e sql_trace. Estes parâmetros
estavam em uso pelo sistema PageIT na versão Oracle 9i. Todos estes parâmetros podem ser
verificados no anexo 1.
10
Todas as funções e parâmetros descartados na versão 10g continuam em
funcionamento apenas por uma questão de compatibilidade com os softwares mais antigos,
porém eles não deverão ser referenciados na configuração dos parâmetros de inicialização do
Servidor Oracle.
2.2.1 Descrição dos parâmetros e funções
Arquivo de inicialização é um arquivo que possui todos os parâmetros de
inicialização de uma instância de banco de dados. Todas as vezes que o Servidor Oracle,
inicializa uma instância, ele lê os parâmetros contidos neste arquivo e inicializa esta instância
de acordo com as configurações contidas nele.
Abaixo estão todos os parâmetros de inicialização que foram modificados para a
realização dos testes. Os cinco parâmetros que geram um grande impacto, tanto na atualização
do software como nos testes de desempenho, caso não sejam configurados corretamente são:
Compatible, Java_pool_size, large_pool_size, session_max_open_files, optimizer_mode e
statistics_level. Os demais parâmetros são importantes, mas só causariam impactos caso a
aplicação não fosse compatível com eles.
ENQUEUE_RESOURCES parâmetro que define o número de recursos que serão
reservados (lock) para uso em concorrência, utilizando o lock manager. O enqueue é um
mecanismo de lock, que permite que vários processos concorrentes compartilhem os mesmos
recursos.
LOG_ARCHIVE_START só funciona quando o banco de dados for inicializado em
archivelog mode. Ele indica se o processo de archive dos arquivos de redo é manual ou
automático.
SQL_TRACE habilita a função de trace de SQL. Permite gerar informações para
serem utilizadas no aperfeiçoamento de desempenho do código.
COMPATIBLE: Este parâmetro especifica em qual versão o Oracle deverá manter
compatibilidade. Se o banco de dados for criado na versão 10g, porém o compatible=9.2.0,
todas as funções que precisam que o compatible seja do 10g, retornarão uma mensagem de
11
erro. Uma vez modificado o parâmetro para a versão corrente, não é possível retroceder, a não
ser que se faça uma recuperação do banco de dados.
Exemplo, banco versão 9.2.0.8 (compatible=9.2.0), realizou o upgrade para a versão
10.2.0.4 (compatible=10.2.0), não é possível retornar para a versão 9.2.0.8 (downgrade), a
não ser que se faça uma recuperação utilizando os arquivos de backup.
JAVA_POOL_SIZE especifica o tamanho da memória para comandos Java, é através
deste parâmetro que o gerenciador de memória alocará os comandos durante a execução do
Java. Esta memória inclui definição de métodos e classes, como também os objetos que são
chamados no final da execução do Java.
LARGE_POOL_SIZE especifica o tamanho da alocação de memória utilizado para a
sessão de memória para servidores compartilhados, no buffer de mensagens em sistema de
execução paralela, e pelos processos de backup e recuperação de dados.
SESSION_MAX_OPEN_FILES especifica o número máximo de arquivos binários
que podem ser abertos por uma sessão.
RECYCLEBIN é usado para controlar se a função Flashback Drop capability esta
ligada ou desligada. Se estiver desligada, e alguma tabela for removida, ela não irá para a área
de recycle bin (lixeira). Se estiver ligado, a tabela removida ficará na lixeira e poderá ser
recuperada posteriormente.
OPTIMIZER_MODE é um novo parâmetro adicionado na versão 10g, que indica
qual o tipo de otimização o banco de dados deverá utilizar no algoritmo de leitura das queries.
Ele possui três opções, ALL_ROWS esta opção aperfeiçoa a query para que use a menor
quantidade de recursos possível, FIRST_ROWS_n otimiza para retornar as primeiras n linhas
no menor tempo de resposta (onde n pode ser 1, 10, 100 ou 1000) e FIRST_ROWS otimiza
para encontrar o melhor plano de execução e retornar as primeiras linhas da query.
A tablespace SYSAUX foi instalada como uma tablespace auxiliar à tablespace
System. Alguns componentes do banco de dados agora utilizam esta nova tablespace. Se esta
tablespace ficar indisponível, funções essenciais do banco de dados continuam em operação.
As outras funções não essenciais poderão falhar.
12
STREAMS_POOL_SIZE especifica o tamanho de memória a ser utilizado pelo
Stream pool caso o SGA_TARGET não seja definido em zero. A Stream pool é uma porção de
memória da SGA e guarda na memória as filas de mensagens de buffer e provê memória para
a coleta de processos e aplicação de processos. Isto é, o Streams pool sempre armazena os
LCRs capturados pelo processo de captura, e armazena estes LCRs e as mensagens
requisitadas pelos usuários e pela aplicação em forma de filas dentro do buffer.
STATISTICS_LEVEL especifica o nível de coleta de estatísticas para o banco de
dados e para o sistema operacional. Estas estatísticas são coletadas para diversos fins, entre
estes fins os de auto-gestão de decisões. Este parâmetro possui três níveis de coleta: Basic,
Typical e All. O Typical assegura que todas as informações principais para a funcionalidade
da auto-gestão sejam coletadas. O All coleta todas as informações, porém esta opção impacta
no desempenho do banco de dados. O Basic coleta as informações básicas e desabilita
algumas coletas importantes impossibilitando o funcionamento de algumas funções
importantes. As alterações destes parâmetros afetam o desempenho do banco de dados.
13
3 TESTES
Neste estudo de caso, foram realizados 2 tipos de testes de desempenho:
O primeiro teste tem como objetivo testar a atualização do Software do Servidor
Oracle. Cada etapa deste teste deverá conter o tempo que demorou em realizá-lo, os erros e
dificuldades encontrados, a ação tomada para correção destes erros e comentários necessários.
Este teste serve para detectar qualquer problema que o DBA poderá enfrentar na atualização
do software, no ambiente de produção. Qual será o tempo mínimo necessário para a
realização desta manutenção, e da mesma forma saber por quanto tempo este sistema ficará
indisponível para seus usuários.
O segundo teste tem como objetivo testar o desempenho das funcionalidades da
aplicação. Neste teste são coletadas as informações de referência ou baseline do banco de
dados de produção, e logo após a atualização do software do Servidor Oracle, deverá ser
executado o teste inicial. Caso algum código apresentar má funcionalidade, serão realizados
alguns ajustes, os quais poderão ser parâmetros de inicialização, modificações no código, ou
nos planos de execução dos SQLs. Logo após os ajustes é executado o teste final. Este tem
como objetivo testar os ajustes realizados após o teste inicial. Todos estes testes deverão ser
documentados detalhadamente no documento de Handoff. (vide anexo 2).
3.1 Primeiros procedimentos
Para a realização dos testes foi feito um backup lógico onde as informações do
banco de dados de Produção foram transferidas para o banco de dados de Testes.
Foram coletadas as estatísticas referente a um mês, o que equivale a trinta dias
corridos. Baseados nessas informações foram coletados e classificados os Top 20 SQLs.
Os top 20 SQLs são as 20 funções/SQLs que permaneceram por mais tempo
utilizando os recursos da CPU, durante o período analisado que foi de trinta dias.
Logo após a coleta destas informações, são apontadas as diferenças entre os
parâmetros de inicialização dos bancos de dados de teste e produção. (vide anexo 1). Com
todas estas informações documentadas, inicia-se o processo de testes.
14
3.2 Upgrade do banco de dados
O upgrade ou atualização do Software de Banco de Dados é a próxima etapa neste
ciclo. A partir deste ponto todas as informações devem ser documentadas com o máximo de
precisão possível.
Para a realização do upgrade o Administrador de Banco de Dados deve consultar a
documentação referente à atualização de software. Há quatro maneiras de atualizar um Banco
de Dados Oracle [7]:
• Via DBUA – ferramenta gráfica e automática que auxilia o DBA na
realização da atualização;
• Atualização Manual - consiste em executar scripts SQL via linha de
comando, obedecendo a uma ordem determinada;
• Export/Import – Através da ferramenta Export é possível fazer uma cópia
parcial ou uma copia total dos dados do banco de dados, o arquivo gerado
com as informações é transferido através da ferramenta Import para o banco
de dados na nova versão, esta maneira é mais utilizada quando se deseja
manter uma cópia do banco de dados na versão anterior;
• Via Cópia dos Dados – A cópia dos dados é realizada através de links entre
os bancos de dados das diferentes versões, utilizando scripts SQL para a
leitura e gravação destas informações. A diferença entre esta maneira e a de
Export/Import, é que via Copia dos Dados é possível fazer a copia de apenas
um registro da tabela.
A forma utilizada pelo DBA foi à atualização manual, pois provê um maior controle
no processo de atualização, e também é o método utilizado pelo DBA de produção. O DBA
de teste deve sempre realizar os passos de acordo com o DBA de produção para prever os
possíveis erros e para evitá-los no dia da implementação.
O primeiro passo do upgrade foi executar os scripts pré-atualização. Estes scripts
verificam se há necessidade de fazer alguma correção no banco de dados antes da realização
do upgrade. Estas correções variam de acordo com o Banco de Dados, mas neste caso foi
necessário aumentar alguns parâmetros de memória, adicionar novos parâmetros e remover os
parâmetros que foram descartados pela nova versão.
15
Após a alteração dos parâmetros o DBA deverá atualizar o ORACLE_HOME, este
parâmetro é uma variável de ambiente do Sistema Operacional, ela aponta o caminho (PATH)
em que o software Oracle esta instalado. Depois de realizados estes passos, o DBA faz um
backup do banco de dados para garantir a integridade dos dados, caso seja encontrado algum
erro durante a atualização, e para que seja possível a recuperação destas informações.
Depois de finalizado o primeiro passo, o DBA de teste, inicia a atualização. A
atualização consiste em executar scripts especifico para a atualização. Finalizado a
atualização, o DBA deverá executar os scripts pós-atualização. Tais scripts verificam se a
atualização ocorreu com sucesso e se é necessário algum ajuste ou correção. Estas correções
variam de acordo com a mensagem de erro reportada, se o erro não é possível de ser corrigido
pelo DBA, o mesmo deverá abrir um chamado na Oracle reportando o erro encontrado de
acordo com as mensagens de erro relacionadas e solicitar uma correção ou um diagnóstico
para a solução deste problema.
3.3 Documentação do upgrade
Cada passo ou script SQL executado no processo do upgrade deve ser documentado
pelo DBA de teste, que deverá documentar todos os passos que foram realizados e quanto
tempo foi necessário para realizá-los. Este documento é extremamente útil para o DBA de
produção, pois baseado neste documento é possível prever quanto tempo é necessário para a
realização do upgrade, e quanto tempo o sistema ficará indisponível para seus usuários no dia
da implementação.
3.4 Cenários de Testes
Há cinco tipos de testes realizados para upgrade de versões [7]:
• Teste Mínimo - consiste em mover parte ou todos os dados de um banco de
produção para o banco de dados de testes e realizar os testes sem que as
novas funções estejam habilitadas.
• Teste Funcional consiste em testar as novas e antigas funcionalidades do
sistema após a atualização do software. Este teste inclui todos os tipos de
informações como conexão de rede, componentes de hardware e teste da
16
aplicação. O objetivo é verificar se as funções antigas e as novas estão
funcionando corretamente.
• Teste de Integração analisa a integração de cada um dos componentes do
sistema, testa interface gráfica, subsistemas desenvolvidos em outras
linguagens de programação, se o sistema é compatível com as novas
bibliotecas, como por exemplo, bibliotecas de rede. Teste de Desempenho
compara o desempenho de vários scripts SQL do banco de dados atual com
os mesmos scripts sendo executados no banco de dados com a nova versão
de software.
• Teste de Volume de Carga de Dados ou Teste de Stress consiste em testar se
os dados estão acessíveis pela aplicação e se as aplicações que executam os
SQLs sobre o banco de dados estão funcionando corretamente. Deve reunir
todos os dados de desempenho do banco de dados de produção num período
normal e no período de pico, e baseado nestas informações fazer os testes de
volume de dados no banco de dados que foi atualizado. Comparar as
informações entre os testes realizados para saber se o desempenho do banco
de dados de teste se saiu melhor ou teve o mesmo desempenho do banco de
dados de produção.
Com as informações coletadas anteriormente pelos tops 20 SQL, foi possível montar
29 casos de teste, onde cada caso avalia o desempenho de um determinado script no banco de
dados. Para cada caso foi comparado o desempenho obtido quando executado na versão
Oracle 9i com desempenho obtido na versão Oracle 10g.
3.5 Baseline
O baseline é o top 20 SQLs coletados na versão 9i, que é referência utilizada em
cada caso de teste. É a partir deste baseline que faremos as comparações.
3.6 Teste inicial
O teste inicial é o primeiro teste realizado após a atualização, isto é, após a
atualização da versão do banco de dados os scripts coletados deverão ser executados em cima
desta nova versão. Deve-se verificar o desempenho obtido pelos scripts, e compará-los com o
Baseline. Anotar os valores obtidos e fazer uma média, caso os valores do Teste Inicial forem
iguais ou melhores que o Baseline, o teste teve sucesso. Caso contrário o banco de dados deve
17
ser ajustado para um melhor desempenho, para isso o DBA deverá utilizar as ferramentas do
banco de dados para esta melhoria, como também ajustar o scripts para que estes possam ter
um melhor desempenho. São três os tipos de valores analisados: quantidade de acessos ao
buffer de memória, quantas vezes o SQL foi executado, e quanto tempo demorou cada
execução. Estes valores foram coletados no baseline e na execução do Teste Inicial.
3.7 Teste final
O teste final é realizado caso seja identificado uma anormalidade, isto é, um ou mais
scripts executados no Teste Inicial apresentarem um desempenho fora do normal. Se houver
qualquer intervenção, seja ela no parâmetro do banco de dados ou em qualquer um dos scripts
analisados no Teste Inicial, novos testes serão realizados para que comprovem se houve ou
não uma melhora no desempenho destes scripts.
3.8 Resultados dos testes
O anexo 3, apresenta seis dos vinte e nove cenários analisados pelo DBA de Teste.
Como pode ser verificado, no caso 1 se comparado o desempenho do teste inicial em relação
ao Baseline, o tempo gasto por execução obteve uma melhora de 54,99%.
No caso 7, o teste inicial apresentou um desempenho inferior de 80,77% em relação
ao baseline, isto é, o SQL estava 80,77% mais lento em relação ao baseline, o teste final por
sua vez obteve um desempenho 10% melhor em relação ao baseline. Comparando o teste final
e o teste inicial o SQL obteve um desempenho 39,15% melhor.
O caso 14 apresenta uma anomalia, pois o teste inicial teve um desempenho muito
inferior chegando a 1438,65% em relação ao baseline, e após alguns ajustes, mudanças de
parâmetros e do plano de execução, o teste final apresentou um desempenho melhor chegando
a 188,04% em relação ao baseline, comparando o teste final em relação ao teste inicial o
desempenho do SQL ficou 81,28% melhor.
O caso 29, o mais interessante, pois comparando o teste inicial com o baseline houve
desempenho inferior de 237,69%, após os ajustes dos parâmetros, o teste final mudou e
obteve uma melhora no desempenho de 73,59% em relação ao baseline, comparando o Teste
Final em relação ao teste inicial o desempenho foi 92,18% melhor.
18
Analisando todos os 29 casos de teste, o DBA de produção tem uma noção dos
desafios que o aguardarão após o upgrade do banco de dados de produção, quais os
problemas que poderão ocorrer e quais scripts ele deverá concentrar seus esforços para
otimização do banco de dados.
3.9 Handoff
Handoff no futebol significa passar a bola [8]. Esta etapa resume exatamente nisso, o
DBA de Teste faz uma reunião com o DBA de Produção e passa todas as informações e
documentos relacionados aos testes realizados, e se dispõe para a solução de qualquer dúvida
em relação a estes testes. Esta etapa finaliza o ciclo de testes.
19
4 CONCLUSÃO
Testar as atualizações de versão de software no ambiente de teste é extremamente
importante, pois o DBA consegue visualizar todos os problemas que poderão ocorrer, e assim
construir um plano de ação para que estes problemas sejam evitados quando for implementar
no ambiente de produção. O DBA também consegue saber qual o tempo médio gasto na
realização do processo de atualização do software, evitando que o sistema fique indisponível
por um longo período de tempo e cause prejuízos financeiros para a companhia. Outro
beneficio dos testes de atualização de software é poder prever o comportamento do sistema
em relação ao sistema atual, fornecendo argumentos para atualização ou não da versão do
software.
4.1 Extensões
Através deste trabalho podem ser feitos estudos comparando os testes realizados na
atualização de versão de banco de dados de outras tecnologias, como DB2, MySQL, Firebird,
SQL Server. Pode-se ainda estudar os demais tipos de testes não abordados por este trabalho,
como o Teste Mínimo, Teste Funcional, Teste de Integração e Teste de Volume de Carga de
Dados tanto para banco de dados Oracle como para os bancos de dados das demais
tecnologias.
20
Anexo 1 – Comparação de parâmetros O anexo 1 apresenta a comparação entre os parâmetros de inicialização do banco de dados de produção, na versão 9i, e os parâmetros do banco de dados de teste na versão 10g. PageIT - Production PROD01 PageIT - Development/Test TEST01
Parameter Value Parameter Value
audit_file_dest (default) audit_file_dest /oracle/g01/admin/ TEST01/adump
background_dump_dest /oracle/g01/admin/ PROD01/bdump background_dump_dest /oracle/g01/admin/ TEST01/bdump
compatible 9.2.0 compatible 10.2.0
control_files /oracle/g01/redo01/PROD01/ PROD01.ctrl_01.dbf, /oracle/g01/redo02/PROD01/ PROD01.ctrl_02.dbf, /oracle/g01/db01/PROD01/ PROD01.ctrl_03.dbf
control_files /oracle/g01/redo01/TEST01/ TEST01.ctrl_01.dbf, /oracle/g01/redo02/TEST01/ TEST01.ctrl_02.dbf, /oracle/g01/db01/TEST01/ TEST01.ctrl_03.dbf
core_dump_dest /oracle/g01/admin/PROD01/ cdump core_dump_dest /oracle/g01/admin/TEST01/ cdump
cursor_sharing Force cursor_sharing force
db_block_size 8192 db_block_size 8192
db_cache_size 838860800 db_cache_size 419430400
db_domain (default) db_domain world
db_file_multiblock_read_count 16 db_file_multiblock_read_count 16
db_files 1000 db_files 1024
db_name PROD01 db_name TEST01
dml_locks 1000 dml_locks 1000
enqueue_resources 3020
<-----deprecated enqueue_resources
global_names global_names FALSE
java_pool_size java_pool_size 167772160
job_queue_processes 4 job_queue_processes 4
large_pool_size large_pool_size 16777216
log_archive_dest /oracle/g01/arch01/ PROD01/arch log_archive_dest /oracle/g01/arch01/ TEST01
log_archive_format PROD01.arch_%t_%s.dbf log_archive_format TEST01.arch_%t_%s_%r.dbf
log_archive_start TRUE <-----deprecated log_archive_start
log_buffer 131072 log_buffer 14282752
log_checkpoint_interval 20000 log_checkpoint_interval 20000
log_checkpoint_timeout 1800 log_checkpoint_timeout 0
21
log_checkpoints_to_alert TRUE log_checkpoints_to_alert TRUE
max_dump_file_size 10240 max_dump_file_size 10240
nls_date_format DD-MON-RR nls_date_format DD-MON-RR
open_cursors 1000 open_cursors 1000
optimizer_mode CHOOSE optimizer_mode all_rows
pga_aggregate_target 524288000 pga_aggregate_target 262144000
processes 500 processes 250
----> new for 10g recyclebin off
session_max_open_files 10 session_max_open_files 20
session_cached_cursors 100 session_cached_cursors 100
sga_max_size 2098172888 sga_max_size 2097152000
shared_pool_size 419430400 shared_pool_size 218103808
sql_trace FALSE <-----deprecated sql_trace
----> new for 10g statistics_level typical
----> new for 10g streams_pool_size 67108864
timed_statistics TRUE timed_statistics TRUE
undo_management AUTO undo_management AUTO
undo_retention 900 undo_retention 900
undo_tablespace Rbs undo_tablespace rbs
user_dump_dest /oracle/g01/admin/ PROD01/udump user_dump_dest /oracle/g01/admin/TEST01/udump
recommended by utlu102i
updated for 10g
difference is okay due to being dev db
suggested for prod
22
Anexo 2 – Documento de Handoff Apresenta o documento utilizado na reunião entre os DBAs para transmitir as etapas realizadas na atualização e a duração de cada uma delas.
CERTIFICATION SECTION
Values Are Required for Each Item
DBA Certifying Handoff Nome de DBA de Teste
DBA Accepting Handoff Nome de DBA de Produção
Certification / Handoff Date Data em que houve a reunião - 1/10/2008
Certification of Backout Plan Testing n/a
Environment (server, instance) DEV01, TEST01
Applid (ie EAS) Identificação da aplicação
Application Name PageIT
Application Contact Nome do responsável da aplicação
Release (ie NOV07GBL) Data em que o projeto será implementado na produção
Request For Change (RFC) Number Controle de mudanças
Database Growth Considerations Se necessitar alguma modificação do espaço em disco
Location of captured DDL n/a
Application Testing Results Location Doc-Share link that references where application test plan and results are located
SQL Tuning Actions no SQL tuning actions required Location of other relevant documentation
Comments n/a
Implementation Plan Implementation plan should be executable for any and all environments as it is defined in this section
Duration Implementation Comments Role
5 minutes Verify that 10.2.0.4 binaries loaded on server DBA
20 minutes
PREPARATION STEPS: Follow the steps in Chapter 3 Upgrading to the New Oracle Database 10g Release in the manual Oracle Database Guide 10g Release 2 - do preparation steps only including utlu102i.sql
steps include creating sysaux tablespace, running catalog stats, resolving invalid objects.
DBA
23
5 minutes
Update database parameter file for 10g Remove parameters: enqueue_resources, log_archive_start, sql_trace Update parameters: compatible=10.2.0 log_archive_format=TEST01.arch_%t_%s_%r.dbf optimizer_mode=ALL_ROWS Add parameters: recyclebin=off statistics_level=typical audit_file_dest=/oracle/g01/admin/TEST01/adump (make sure adump directory exists on server) Make parameter changes or additions as specified by utlu102i: java_pool_size, large_pool_size, session_max_files, streams_pool_size
DBA
5 minutes
Run grants due to change in CONNECT role privileges GRANT ALTER SESSION to R_TELALERT_APP; GRANT CREATE SYNONYM to R_TELALERT_APP; GRANT CREATE VIEW to R_TELALERT_APP;
DBA
15 minutes
Dev db started with restored 9i hot backup, saving backup in case of further use. Then had to run catpatch since we only have 9.2.0.6 binaries (as compared to 9.2.0.5 as in production).
(for Prod, take final 9i Hot Backup after application is down and "save" it)
DBA
30 minutes
UPGRADE STEPS: Follow the steps in Chapter 3 Upgrading to the New Oracle Database 10g Release in the manual Oracle Database Guide 10g Release 2
Catupgrade took 20 minutes DBA
5 minutes Take Hot Backup then turn over to app team for testing DBA
Backout Plan -- to be completed if Implementation not done correctly.
Backout plan is to be defined based on the configuration of the production environment. Outage windows available for the production environment must be considered by the Dev DBA when developing the backout plan.
Duration Implementation Comments Role
30 minutes Restore to version 9i using Hot Backup (or could export using 9i binaries) DBA
24
Anexo 3 – Resultados dos Testes Apresenta 6 casos dos 29 casos analisados pelo DBA de Teste.
Caso SQL
Tempo médio
por Execução
(s)
Buffer
Gets Execuções
Tempo
Gasto
(s)
Buffer
Gets Execuções
Tempo Gasto
(s)
Buffer
Gets Execuções
Tempo Gasto
(s)
Teste Inicial
vs Baseline
Teste Final
vs Baseline
Teste Final vs
Teste Inicial
1
select * from msg_log where msg_sender_user_id=51567 and
INITD_TMST>=TO_DATE('09/17/2008 11:25:08', 'MM/DD/YYYY HH24:MI:SS')
order by initd_tmst asc 0,0216 222 4 0,0862 111 1 0,0097 111 1 0,0097 54,99 54,99 0,00
7
select this.VIEW_TYP_CD as
VIEW_TYP1_0_, this.VIEW_TYP_NME as VIEW_TYP2_0_
from VIEW_TYP this where 1=1 order by this.VIEW_TYP_CD asc 0,0013 4 2 0,0026 4 2 0,0047 23 10 0,0143 -80,77 -10,00 39,15
9
SELECT E.metadir_uniq_id, D.DEST_NME
FROM DEST D, ENTRP_PG_USER EWHERE E.USER_ID = D.USER_ID
AND D.STUS_ID=1AND E.STUS_ID=1
AND D.PREFERRED_ORDR_NBR = 1AND UPPER(E.METADIR_UNIQ_ID)
!='NONE' 0,0334 298 1 0,0334 298 1 0,0313 298 1 0,0322 6,29 3,59 -2,88
14
select newsitems0_.NEWS_CAT_CD as NEWS_CAT9___,
newsitems0_.NEWS_ITEM_ID as NEWS_ITE1___,
newsitems0_.NEWS_ITEM_ID as
NEWS_ITE1_0_, newsitems0_.NEWS_ITEM_TITLE_NME
as NEWS_ITE2_0_, newsitems0_.NEWS_ITEM_TXT as
NEWS_ITE3_0_, newsitems0_.NEWS_ITEM_TXT2 as N 0,0005 80 36 0,0163 166 3 0,0209 460 48 0,0626 -1438,65 -188,04 81,28
Desempenho (%)Baseline Teste Inicial Teste Final
25
Caso SQL
Tempo médio
por Execução
(s)
Buffer
Gets Execuções
Tempo
Gasto
(s)
Buffer
Gets Execuções
Tempo Gasto
(s)
Buffer
Gets Execuções
Tempo Gasto
(s)
Teste Inicial
vs Baseline
Teste Final
vs Baseline
Teste Final vs
Teste Inicial
23
INSERT INTO
MSG_LOG(MSG_SENDER_USER_ID,MSG_TXT,TELALERT_ALRT_ID,TELALERT
_HOST_SRVR_CD,TELALERT_CLIENT_SRVR_CD,VIEW_TYP_CD,INITD_TMST,
CMPLTD_TMST,LAST_UPDT_DT) 0,1625 163 1 0,1625 460 1 0,1365 221 1 0,0526 16,00 67,63 61,47
29
SELECT d.dest_id, DEST_NME, E.COMN_NME, S.CFGRN_NME, D.PIN
FROM DEST D LEFT OUTER JOIN ENTRP_PG_USER
E ON E.USER_ID = D.USER_ID
LEFT OUTER JOIN SRVC_PRVDR_CFGRN S ON
S.CFGRN_ID = D.CFGRN_IDWHERE D.STUS_ID=1 0,1454 487 1 0,1454 458 1 0,491 290 1 0,0384 -237,69 73,59 92,18
Desempenho (%)Baseline Teste Inicial Teste Final
26
Referências Bibliográficas [1] RAKITIN, S. R., Software Verification and Validation: A Practitioner's Guide. Artech House. 1997. [2] PRESSMAN, R. S., Software Engineering: a Practitioner’s Approach. 5th Ed. McGraw-Hill. 2001. [3] LOVELAND, S., Software Testing Techniques: Finding the Defects that Matter. Cengage Charles River Media. 2005. [4] MCGREGOR, C., Oracle Database 2 Day DBA. 10g Release 2 (10.2). Part Number B14196-02. Oracle Corporation. December 2005 [5] GELAIS, M. S., Oracle 9i Database Administration Fundamentals I. Part Number D37265. Oracle Corporation. September 2002 [6] Software Errors Cost U.S. Economy $59.5 Billion Annually http://www.nist.gov/public_affairs/releases/n02-10.htm, Recuperado em 03/10/2008. [7] RICH, K.; SCHUPMANN, V. Oracle Database Upgrade Guide. 10g Release 2, Part Number B14238-02. Oracle Corporation. January 2008. [8] Definition of Handoff by The Free Dictionary http://www.thefreedictionary.com/handoff, Recuperado em 03/10/2008.
27
Bibliografias Consultadas KOSSIAKOFF A., SWEET W. N., Systems Engineering Principles and Practice. John Wiley & Sons. 2003. RUBIN J., Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests. John Wiley & Sons. 1994. White Paper, NetStars Systems, The Database Life Cycle. http://www.netstarit.com/resources/white_papers/white_papers.html, Recuperado em 03/10/2008 CHAN, I., Oracle Database Performance Tuning Guide, 10g Release 2, Part Number B14211-03. Oracle Corporation. March 2008. ALBIN S. T., The Art of Software Architecture: Design Methods and Techniques. John Wiley & Sons. 2003. BURNSTEIN I., Practical Software Testing: A Process-Oriented Approach. Springer. 2003. CYRAN , M., Oracle Database Concepts. 10g Release 2 (10.2). Part Number B14220-02. Oracle Corporation. December 2003 RICH, K., Oracle Database Reference. 10g Release 2 (10.2). Part Number B14237-03. Oracle Corporation. December 2007 Rule Based Optimizer is to be Desupported in Oracle10g
https://metalink2.oracle.com/metalink/plsql/f?p=130:14:7558554183017128588::::p14_database_id,p14_docid,p14_show_header,p14_show_help,p14_black_frame,p14_font:NOT,189702.1,1,1,1,helvetica, Recuperado em 03/10/2008
