Arquitetura Oracle

UNIVERSIDADE LUTERANA DO BRASIL
CURSO DE CIÊNCIA DA COMPUTAÇÃO

CÂMPUS CANOAS
ANÁLISE DE DESEMPENHO DO
BANCO DE DADOS ORACLE 9i
Felipe Marin Flores
Monografia desenvolvida durante a disciplina de Trabalho

de Conclusão de Curso em Informática II e apresentada ao
Curso de Ciência da Computação da Universidade
Luterana do Brasil, câmpus Canoas, como pré-requisito
para a obtenção do título de Bacharel em Ciência da
Computação.
Orientador: Prof. Miguel Rodrigues Fornari
Canoas, dezembro de 2003.

2
Universidade Luterana do Brasil – ULBRA

Curso de Ciência de Computação – Câmpus Canoas
Reitor:
Pastor Ruben Eugen Becker
Vice-Reitor:
Eng. Leandro Eugênio Becker
Diretor da Faculdade de Informática:
Prof. Gilberto Fernandes Marchioro
Coordenador de Curso (Câmpus Canoas):
Prof. Gilberto Fernandes Marchioro
Coordenador das Disciplinas de Trabalho de Conclusão de Curso (Câmpus Canoas):
Prof. Denise Salvadori Virti
Banca Avaliadora composta por: Data da defesa: 22/12/2003.

Prof. Miguel Rodrigues Fornari (Orientador)
Prof.ª Denise Salvadori Virti
Prof.ª Tanisi Pereira de Carvalho
CIP – Catalogação na Publicação

Flores, Felipe Marin
Análise de desempenho do banco de dados Oracle 9i / Felipe Marin

Flores; [orientado por] Miguel Rodrigues Fornari. – Canoas: 2003.
70 p.: il.
Trabalho de Conclusão de Curso (Graduação em Ciência da

Computação). Universidade Luterana do Brasil, 2003.
1. Banco de Dados. 2. Análise de desempenho. 3. Oracle 9i. I.

Fornari, Miguel Rodrigues. II. Título.
Endereço:
Universidade Luterana do Brasil – Câmpus Canoas
Av. Miguel Tostes, 101 – Bairro São Luís
CEP 92420-280 Canoas-RS – Brasil
3
Dedico este trabalho a meus pais e à minha namorada

Alessandra. A eles, todo meu amor, carinho e mais
profundos agradecimentos pelo apoio estendido, nos
momentos mais difíceis desta vencida jornada.
AGRADECIMENTOS
Agradeço, primeiramente a Deus, por estar sempre comigo em todos momentos de
minha vida. Agradeço aqui, de uma forma geral, a todos aqueles que contribuiram de alguma
maneira para que esta tão esperada colação de grau pudesse ser realizada. A todos, meus mais
sinceros agradecimentos.
SUMÁRIO
LISTA DE FIGURAS............................................................................................................... 6
LISTA DE TABELAS.............................................................................................................. 7
LISTA DE QUADROS............................................................................................................. 8
RESUMO................................................................................................................................... 9
ABSTRACT ............................................................................................................................ 10
1 INTRODUÇÃO.................................................................................................................. 11
2 ORACLE 9i ........................................................................................................................ 13
2.1 PARÂMETROS .............................................................................................................. 13
2.1.1 Desempenho ........................................................................................................ 14
2.1.2 Concorrência ....................................................................................................... 16
2.1.3 Recuperação de Dados ........................................................................................ 18
2.2 ALTERAÇÃO DE PARÂMETROS DO ORACLE ................................................................. 20
3 FERRAMENTAS............................................................................................................... 23
3.1 EXPLAIN PLAN ............................................................................................................. 23
3.2 TRACE.......................................................................................................................... 25
3.3 GRÁFICOS DE ACOMPANHAMENTO .............................................................................. 29
4 SISTEMA DE AVALIAÇÃO ........................................................................................... 31
4.1 TRANSACTION PROCESSING PERFORMANCE COUNCIL ................................................ 31
4.2 PROJETO DO SISTEMA DE AVALIAÇÃO......................................................................... 33
4.2.1 Execução do Projeto............................................................................................ 33
4.2.2 Aplicativo Delphi ................................................................................................ 34
4.3 CONSULTAS ................................................................................................................. 40
4.4 ALTERAÇÕES ............................................................................................................... 41
5 ANÁLISE DOS RESULTADOS ...................................................................................... 43
6 CONCLUSÃO.................................................................................................................... 56
ANEXO A – TABELAS DO MODELO TPC...................................................................... 59
ANEXO B – CONSULTAS E ATUALIZAÇÕES UTILIZADAS ..................................... 63
ANEXO C – GRÁFICOS POR PARÂMETRO E CONJUNTO....................................... 67
REFERÊNCIAS ..................................................................................................................... 70
LISTA DE FIGURAS
Figura 1 – Transações e consistência de leitura ....................................................................... 17
Figura 2 – Configuração dos parâmetros de inicialização........................................................ 21
Figura 3 – Parâmetros de inicialização do Oracle .................................................................... 22
Figura 4 – Gráfico de acompanhamento .................................................................................. 30
Figura 5 – Diagrama representativo ......................................................................................... 32
Figura 6 – Modelo de BD para TPC......................................................................................... 32
Figura 7 – Diagrama de Sequência........................................................................................... 34
Figura 8 – Interface do Software “Lançador de Aplicações”................................................... 35
Figura 9 – Subdiretórios envolvidos......................................................................................... 36
Figura 10 – Configuração do parâmetro LOG_CHECKPOINT_TIMEOUT .......................... 37
Figura 11 – Seleções utilizadas no conjunto 1 ......................................................................... 39
Figura 12 – Atualizações utilizadas no conjunto 1................................................................... 39
Figura 13 – Arquivo Resultado.txt ........................................................................................... 40
Figura 14 – Consultas envolvidas no Conjunto 1..................................................................... 63
Figura 15 – Atualizações envolvidas no Conjunto 1................................................................ 64
LISTA DE TABELAS
Tabela 1 – Exemplo de tabela montada pelo TKPROF............................................................ 28
Tabela 2 – Número de processos concorrentes de Atualizações X Consultas ......................... 42
LISTA DE QUADROS
Quadro 1 – Parâmetros envolvidos no desempenho do BD ..................................................... 15
Quadro 2 – Parâmetros envolvidos na concorrência de dados ................................................. 18
Quadro 3 – Parâmetros envolvidos na recuperação de falhas .................................................. 20
Quadro 4 – Colunas da tabela PLAN_TABLE ........................................................................ 24
Quadro 5 – Parâmetros do TKPROF........................................................................................ 26
Quadro 6 – Descrição dos campos da tabela TKPROF............................................................ 28
Quadro 7 – Parâmetros e valores utilizados ............................................................................. 38
Quadro 8 – Conclusões sobre o uso dos parâmetros ................................................................ 57
Quadro 9 - Layout da tabela DEPÓSITO................................................................................. 59
Quadro 10 - Layout da tabela DISTRITO – traduzido de TPC (2002) .................................... 59
Quadro 11 - Layout da tabela CLIENTE.................................................................................. 60
Quadro 12- Layout da tabela HISTÓRICO.............................................................................. 60
Quadro 13 - Layout da tabela NOVO_PEDIDO ...................................................................... 61
Quadro 14 - Layout da tabela PEDIDO.................................................................................... 61
Quadro 15 - Layout da tabela PEDIDO_LINHA ..................................................................... 61
Quadro 16 - Layout da tabela ITEM ........................................................................................ 62
Quadro 17 - Layout da tabela ESTOQUE................................................................................ 62
RESUMO
Este estudo tem por objetivo primordial demonstrar a importância dos parâmetros
sobre o conjunto de consultas e atualizações, utilizando como teste uma base de dados no
Oracle 9i. Os parâmetros são de extrema importância, pois determinam, entre outros fatores, o
desempenho do banco de dados. O Oracle 9i é um SGBD que se destaca no mercado por ser
robusto e muito eficaz. Na primeira etapa, foram identificados os parâmetros a serem
estudados através de testes de desempenho. Neste estudo, a primeira etapa contém uma visão
geral do banco de dados Oracle 9i, assim como a identificação dos parâmetros que envolvem
concorrência, desempenho e recuperação de dados. Na segunda etapa, são demonstradas as
ferramentas que foram utilizadas para medir e avaliar o desempenho do banco de dados. É
apresentado o sistema de avaliação, os parâmetros que foram analisados, assim como os
softwares que realizam esta análise. Finalmente, é feita uma análise dos resultados obtidos.
Por fim, são apresentadas as conclusões.
Palavras-chaves: Banco de Dados; Análise de Desempenho; Oracle 9i.

ABSTRACT
Title: “Performance analisys of the Oracle 9i database system”
This study has as main goal demonstrate the importance of the parameters on the
Database Management System Oracle 9i. The parameters has extreme importance, because
determine, between other factors, the database performance. Oracle 9i is a SGBD that the
market considers robust and very efficient. On the first stage, is defined the parameters to be
studied through performance tests. In this study, the first step contains a description of Oracle
9i, as well as the parameters identification that involves concorrency control, performance
and recovery. On second step are demonstrated the tools that are used to measure and
evaluate the database performance. It’s presented the evaluation system, the analyzed
parameters, as well as the software that realized this analysis.
Key-words: Database System; Performance Analysis; Oracle 9i.

1 INTRODUÇÃO
Um banco de dados rápido e robusto é o que as empresas atuantes no mercado de
trabalho desejam. Mas será que é realmente necessário um alto investimento em tecnologia de
ponta?
Um banco de dados é projetado de maneira que se adapte a qualquer situação, de

modo que nem sempre atingem o máximo de desempenho que o banco pode oferecer em uma
situação específica. A melhor maneira de melhorar o desempenho do banco de dados é
realizando testes, que poderão verificar onde o banco se comporta de maneira mais eficaz e
onde apresenta o pior desempenho. Para tanto, basta alterar os parâmetros de inicialização do
banco, e medir seu desempenho quando são executadas consultas e atualizações.
Com o auxílio de software especialmente desenvolvido é possível medir o tempo de

execução. Assim, teremos diferentes tempos para diferentes parâmetros. Além disso, podemos
utilizar programas para analisar o plano de execução de uma sentença SQL, verificando
exatamente onde estão presentes os processos mais demorados, permitindo que o comando
SQL possa ser modificado de maneira que reduza o tempo de resposta. No decorrer deste
estudo, será relatado como proceder para realizar estes testes, assim como a relação completa
dos resultados obtidos na análise de desempenho do banco de dados Oracle 9i sobre uma base
de dados artificial, descrita pelo Transaction Processing Performance Council (TPC) para o
benchmark TPC-C1.
No segundo capítulo são estudados os conceitos relacionados ao ajuste de parâmetros

do banco de dados Oracle 9i. Também é descrita a maneira como estes parâmetros são
modificados e quais estão mais diretamente ligados ao desempenho.
1
TPC BENCHMARK™ C. Standard Specification, Rev.5.0 , fev. 2001. Disponível em : <http://www.tpc.org> Acesso em:
5 jun. 2002.
12
No terceiro capítulo, são estudadas as ferramentas utilizadas para analisar o

desempenho do banco, o SQL Trace e o TKPROF.
No capítulo 4, são abordados os assuntos relativos ao sistema de avaliação, ou seja, é

relatado o projeto de execução, o modelo TPC utilizado como base, o aplicativo que foi
desenvolvido para computar os tempos de execução de cada conjunto de dados e os
parâmetros que foram analisados.
No seguinte, são apresentados os resultados obtidos na análise de desempenho,

avaliando tempo de resposta de acordo com a variação dos parâmetros para o SGBD Oracle
9i.
Por fim, são apresentadas as conclusões deste estudo e algumas sugestões de futuros
trabalhos.
2 ORACLE 9i
Este capítulo tem como objetivo explicar os parâmetros do Oracle relacionados a
controle de desempenho, concorrência e recuperação de dados. Há outros subconjuntos de
parâmetros não abordados neste trabalho. Uma descrição completa pode ser encontrada no
manual de referencia2 da Oracle
2.1 PARÂMETROS
O Oracle possui aproximadamente 250 parâmetros que configuram o sistema. O
Administrador da Base de Dados (DBA), é responsável por fazer com que o banco de dados
obtenha o máximo em desempenho, através da modificação dos valores de cada parâmetro.
Alguns deles exigem a reinicialização do banco de dados, enquanto para outros, isto não se
faz necessário. Um dos motivos pelo qual o Oracle tornou-se um poderoso e complexo
SGBD, é o fato de possuir a habilidade de mudar dinamicamente sua configuração em tempo
de execução.
Existem três tipos gerais de parâmetros, que são caracterizados de acordo com o tipo
de interrupções necessárias para mudar seu valor: (Lemke3)
• Parâmetros Estáticos: É um pequeno subconjunto de parâmetros que não pode
ser modificado sem que a base de dados seja completamente reinicializado. Um
exemplo deste tipo de parâmetro é o DB_BLOCK_SIZE. O tamanho do bloco da
base de dados é estático, pois as tabelas e os índices não podem ser movidos com
diferentes tamanhos de blocos. Sua alteração exige uma recriação completa da
base de dados;
2
ORACLE CORPORATION. Oracle9i Database Reference. Release 2 (9.2). Redwood Shores:Oracle Press, 2002.
3
LEMKE, Vilson Z. Análise Comparativa dos Parâmetros Envolvidos no Ajuste de Desempenho dos Bancos de Dados
Oracle9i e Interbase 6.5. Gravataí:ULBRA, 2002. (Trabalho de Conclusão de Curso).
14
• Parâmetros Semi-Dinâmicos: Não exigem que a base de dados seja totalmente

reinicializada, mas as mudanças exigem que a base de dados permaneça
indisponível por algum período de tempo;
• Parâmetros Dinâmicos: Esta classe de parâmetro permite alterar o tamanho e a
configuração do sistema, com ele em funcionamento pleno;
Estes parâmetros atuam em duas diferentes áreas: parâmetros do System Global Area
(SGA) e parâmetros de processo.
• Parâmetros do SGA: Quando um destes parâmetros é alterado, o Oracle

dinamicamente reconfigura as regiões da memória, fazendo umas áreas menores e
tornando outras maiores.
• Parâmetros de Processo: Afetam o comportamento dos processos internos. Por

exemplo, é possível mudar o número de processos paralelos quantas vezes for
desejado, pois o Oracle cria e destrói automaticamente processos internos sem
afetar sua disponibilidade.
2.1.1 Desempenho
A arquitetura de processamento de um SQL possui os seguintes componentes
principais:
• Parser: Um parser possui duas funções: análise sintática, que verifica a sintaxe da
sentença SQL. Como exemplo, uma consulta SQL poderia estar referenciando
uma coluna inexistente em uma tabela; e análise semântica, que verifica, por
exemplo, se o objeto do banco atual e os atributos referenciados pelo objeto estão
corretos;
• Otimizador: O otimizador utiliza regras internas ou métodos de custo para
determinar a maneira mais eficiente de produzir resultados em uma consulta. O
Oracle fornece dois métodos de otimização: baseado em custo (CBO – Cost-
Based Optimizer) e baseado em regras (RBO – Rule-Based Optimizer)4
• Gerador de Linha: Recebe o melhor plano que foi gerado pelo otimizador e gera
a saída para a sentença SQL. A execução do plano é uma coleção de linhas
4
LEMKE, Vilson Z. Análise Comparativa dos Parâmetros Envolvidos no Ajuste de Desempenho dos Bancos de Dados
Oracle9i e Interbase 6.5. Gravataí:ULBRA, 2002. (Trabalho de Conclusão de Curso).
15
estruturadas no formato de árvore. Cada linha retorna um conjunto de linhas para

cada passo.
• Execução do SQL: Componente que opera na execução do plano associado com
a sentença SQL, produzindo os resultados da consulta. Cada linha produzida pelo
gerador de linha é executada por este componente.
No quadro 1, estão descritos os parâmetros mais diretamente ligados ao desempenho

do banco de dados:
Quadro 1 – Parâmetros envolvidos no desempenho do BD

Nome do Parâmetro Descrição Padrão
ARCHIVE_LAG_ Quantidade de dados que pode ser perdida. Valores muito 0
TARGET baixos, resultam em LOGs freqüentes, o que diminui o
desempenho.
BITMAP_MERGE_ Tamanho da memória usada para a união de bitmaps 1MB
AREA_SIZE
CREATE_BITMAP_AREA_ Tamanho da memória alocada para criação de bitmaps 1MB
SIZE
DB_BLOCK_SIZE Tamanho padrão dos blocos de dados. Esse parâmetro é No NT é
estabelecido na criação do BD e não deve ser alterado 8MB
DB_CACHE_SIZE Tamanho padrão para blocos de buffers de cache No NT é
24MB
DB_nK_CACHE_SIZE Tamanho para blocos de buffers de cache para caches 8
adicionais de n Kbytes. Como o DB_BLOCK_SIZE é 8MB,
o parametro a ser utilizado deve ser o
DB_8K_CACHE_SIZE.
HASH_JOIN_ Informa se o otimizador deve ou não deve usar Hash TRUE
ENABLED
LARGE_POOL_SIZE Tamanho da large pool da SGA para servidores 8MB
compartilhados
LOG_ARCHIVE_XXX Disponibiliza os arquivamentos de log e de redo. Neste caso
XXX representa os vários parâmetros de uma mesma família,
ou seja, LOG_ARCHIVE_DEST,
LOG_ARCHIVE_DEST_n, LOG_ARCHIVE_STATE_n,
LOG_ARCHIVE_DUPLEX_DEST, ...,
LOG_ARCHIVE_TRACE. Por este motivo, não há um valor
padrão, pois cada parâmetro pode assumir um valor
diferente.
OPTIMIZER_DYNAMIC_ Controla o nível de amostra dinâmica realizada pelo 1
SAMPLING otimizador (de 0 a 10)
OPTIMIZER_FEATURES_ Habilita características do otimizador, conforme a versão do 9.2.0
ENABLE Oracle
OPTIMIZER_INDEX_ Comportamento da otimização baseada em custo. Favorece 0
CACHING junções de loop aninhado e iteração IN-list (de 0 a 100)
OPTIMIZER_INDEX_ Permite o ajuste do comportamento do otimizador para 100
COST_ADJ seleção de caminhos de acesso, fazendo-o mais ou menos
propenso a usar um caminho de acesso pelo índice ao invés
de fazer uma pesquisa, na tabela inteira (de 1 a 10000)
16
Quadro 1 – Parâmetros envolvidos no desempenho do BD (cont.)

Nome do Parâmetro Descrição Padrão
OPTIMIZER_MAX_ Número de permutações da tabela que o otimizador vai 2000
PERMUTATIONS considerar em buscas com junção
OPTIMIZER_MODE Comportamento padrão para a escolha de uma abordagem de CHOOSE
otimização para a instância
PGA_AGGREGATE_ Meta de memória PGA agregada disponível aos processos do No NT é
TARGET servidor pertencentes à instância 24MB
PRE_PAGE_SGA Traz (TRUE) ou não traz (FALSE) a SGA inteira para a FALSE
memória ao iniciar a instância
QUERY_REWRITE_ Define o uso (TRUE) ou não (FALSE) de reescrita nas FALSE
ENABLED operações de busca
QUERY_REWRITE_ Usa índices baseados em função para obter valores somente Enforced
INTEGRITY de expressões SQL. O parâmetro padrão, ou seja,
ENFORCED, significa que o Oracle reforça e garante a
integridade e a consistência dos dados.
SGA_MAX_SIZE Tamanho máximo para a SGA. Se a soma de seus 130MB
componentes for maior, esse parâmetro é ignorado.
SHARED_POOL_ Espaço da shared pool reservado para grandes requisições No NT é de
RESERVED_SIZE contíguas de memória aproxima-
damente
2,4MB ou
2516582
Bytes
SHARED_POOL_SIZE Tamanho da shared pool da SGA No NT é
48MB
SORT_AREA_SIZE Tamanho máximo para operações de ordenação 64KB
SQL_TRACE Habilita (TRUE) ou desabilita (FALSE) a facilidade de trace FALSE
para SQL. Estando habilitado, esse parâmetro provê
informações para o ajuste de desempenho.
2.1.2 Concorrência
Uma das principais preocupações de um SGBD multiusuário é como controlar a
concorrência, ou seja, o acesso simultâneo do mesmo dado por muitos usuários. Sem o devido
controle de concorrência, os dados podem ser atualizados ou modificados de maneira
imprópria. Uma maneira de controlar concorrência pode estabelecer que caso muitos usuários
estejam acessando o mesmo dado, cada usuário deve esperar por um curto período de tempo.
Além deste método, o Oracle usa vários tipos de chaveamento e um modelo de

consistência multiversão. Ambas tecnologias são baseadas no conceito de transação.
Uma transação impede que seja executado o comando insert em uma tabela cuja onde
esteja sendo executada outra transação. Quando uma transação começa, os dados que serão
alterados são copiados para outros segmentos de memória, antes que seja completada a
transação. Assim, se um usuário solicitar uma pesquisa antes da transação ter sido finalizada,
os dados são lidos destes segmentos. A Figura 1 representa o conceito de transações,
demonstrando como o banco faz a consistencia de leitura e atualização de dados.
17
Figura 1 – Transações e consistência de leitura
Em uma transação, existem três níveis de isolamento: (Oracle Corporation5)

• Read Committed: Este é o nível padrão. Cada consulta executada pela transação,
só vê os dados que foram gravados antes da consulta começar.
• Serializable: Só tem acesso às mudanças que foram gravadas na hora em que a

transação começou e às realizadas pela própria transação.
• Read-Only: Só tem acesso às mudanças que foram feitas no momento em que a

transação começou. Não é permitido INSERT, DELETE ou UPDATE.
Para prevenir uma interação destrutiva entre usuários acessando dados concorrentes,
são usados bloqueios (locks), que travam os dados da tabela ao nível de linha.
Existem diferentes tipos de bloqueios, dependendo do tipo de operação estabelecida.

Estes bloqueios, podem ser de dois tipos: exclusivos ou compartilhados. O modo exclusivo é
solicitado para modificar dados, já o compartilhado permite que os dados sejam lidos, por
transações concorrentes. Isto evita conflito com outras transações de escrita.
O quadro 2, descreve os principais parâmetros do Oracle envolvidos na concorrência

de dados, cujos valores foram consultados na configuração do Oracle.
5
ORACLE CORPORATION. Oracle9i Database Concepts. Release 2 (9.2). Redwood Shores:Oracle Press, 2002.
18
Quadro 2 – Parâmetros envolvidos na concorrência de dados

Nome do Parâmetro Descrição Valor Padrão
ENQUEUE_ Número de recursos que podem ser bloqueados 968
RESOURCES concorrentemente pelo gerenciador de bloqueios (de 10 a
ilimitado)
JOB_QUEUE_ Número máximo de processos que podem ser criados para 10
PROCESSES execução de jobs (de 0 a 1000)
MAX_SHARED_ Número máximo permitido de processos de servidor 20
SERVERS compartilhado que podem rodar simultaneamente
PROCESSES Número máximo de processos concorrentes no BD 150
ROW_LOCKING Define se bloqueios de linha são adquiridos durante operações ALWAYS
de UPDATE
TRANSACTIONS Número máximo de transações concorrentes 187
TRANSACTIONS_ Número de transações concorrentes que se espera que cada 5
PER_ ROLLBACK_ segmento de rollback trate
SEGMENT
2.1.3 Recuperação de Dados

Muitos problemas podem interromper o funcionamento do BD, afetando as operações
de E/S. Alguns destes problemas não necessitam da intervenção do administrador do banco,
mas existem outros, em que este se torna indispensável. Tais erros podem ser: (Oracle
Corporation6)
• Falha de Mídia: Um erro pode ocorrer na tentativa de ler ou escrever em um
arquivo do disco que é necessário para operar o sistema. Este erro ocorre porque
há um problema físico no meio de gravação.
• Erro de Usuário: Um exemplo deste erro é um usuário apagar uma tabela

acidentalmente. Atualmente, este tipo de erro pode ser evitado concedendo ou
revogando privilégios a usuários.
• Falha em uma instância do BD: Ocorre quando um problema impede uma

instância de continuar sua execução normal. Este tipo de falha ocorre quando é
detectada uma falha de software ou de hardware.
• Falha de sintaxe: Ocorre quando, por exemplo, é detectado algum erro de sintaxe
ou semântica em um comando SQL
6
ORACLE CORPORATION. Oracle9i Backup and Recovery Concepts. Release 2 (9.2). Redwood Shores:Oracle Press,
2002.
19
• Falha de Processo: É quando ocorre uma falha no processo do usuário, uma falha
no servidor ou no processo interno do BD. Então, esta falha termina de forma
anormal ou é desconectada.
• Falha da Rede: É quando falhas na rede de comunicação, interrompem a operação

normal de um sistema.
É inevitável falarmos de cópias de segurança quando o assunto é a recuperação de

dados. Ambas são estratégias para proteger o banco contra eventuais perdas de dados.
Trata-se de uma cópia dos dados originais contendo partes importantes do banco de
dados como, por exemplo, o arquivo de controle e o arquivo de dados. Caso os dados
originais sejam perdidos ou apagados, o BD pode recuperá-los através da cópia de segurança.
As cópias de segurança são divididas em:
• Físicas: São copias físicas dos arquivos de dados.
• Lógicas: São aquelas que contém os dados lógicos (tabelas, procedimentos). As

lógicas são usadas para complementar as físicos.
Para recuperar o backup físico do arquivo de dados ou do arquivo de controle é

necessário recuperar o archived redo log e o Online Redo Logs, que são os registros das
mudanças feita na base de dados depois que a cópia de segurança foi realizada. Depois dos
arquivos serem localizados, a recuperação dos dados deve ser iniciada pelo administrador do
banco.
Uma outra estrutura de dados que define um processo de Redo no BD é chamado de

checkpoint. Os Checkpoints são gravados no arquivo de controle e no cabeçalho do arquivo de
dados, e são elementos imprescindíveis na recuperação de falhas.
O SCN (System Change Number), é uma estampa que define uma confirmação de
gravação em um dado período de tempo. O Oracle atribui para cada transação efetuada, um
único SCN.
O quadro 3 descreve os parâmetros que estão envolvidos na recuperação de falhas.

20
Quadro 3 – Parâmetros envolvidos na recuperação de falhas

Nome do Parâmetro Descrição Valor
Padrão
CONTROL_FILES_ Número de cópias para o arquivo de controle (de 1 a 8) No NT é 7
RECORD_KEEP_TIME
DB_CREATE_ Diretório onde os arquivos são criados.
FILE_DEST
FAST_START_ Tempo (em segundos) que se espera que o Oracle leve para 300
MTTR_TARGET realizar a recuperação de uma instância e iniciá-la (de 0 a 3600)
LOG_ARCHIVE_ Número (inteiro) de cópias para um redo log. Não possui valor
DEST_n padrão, pois existem muitos parâmetros derivados tais como:
LOG_ARCHIVE_DEST_1, LOG_ARCHIVE_DEST_2,
LOG_ARCHIVE_DEST_3, ..., LOG_ARCHIVE_DEST_10.
LOG_ARCHIVE_ Estado de disponibilidade do destino n correspondente (de 1 a ENABLED
DEST_STATE_n 10)
LOG_ARCHIVE_ Configura processos para múltiplos archives, como utilizado em 2
MAX_PROCESSES carga de grandes volumes de dados (1 a 10)
LOG_ARCHIVE_ Configura (TRUE) ou não (FALSE) o arquivamento automático FALSE
START na inicialização de uma instância. O Oracle inicia processos
ARCn especificados por LOG_ARCHIVE_MAX_PROCESSES
LOG_BUFFER Tamanho do buffer de redo log na SGA 512KB
LOG_CHECKPOINT_ Número máximo de blocos de redo gerados entre o registro de 0
INTERVAL redo mais recente e o checkpoint
LOG_CHECKPOINT_ Tempo máximo (em segundos) entre o registro de redo mais 1800
TIMEOUT recente e o checkpoint segundos
MAX_ROLLBACK_ Número máximo de segmentos de rollback na SGA (de 2 a 37
SEGMENTS 65535)
RECOVERY_ Número de processos de recuperação concorrentes a serem 0
PARALLELISM usados em uma recuperação mídia
ROLLBACK_ Aloca um ou mais segmentos de rollback para uma instância.
SEGMENTS Caso não seja declarado, a instância utiliza os segmentos de
rollback públicos.
UNDO_ Forma de gerenciamento do espaço nas tablespaces de undo AUTO
MANAGEMENT
UNDO_ Tempo (em segundos) que se deseja manter informações 10800
RETENTION confirmadas de undo no BD
2.2 ALTERAÇÃO DE PARÂMETROS DO ORACLE

Para alterar os parâmetros do Oracle pode-se utilizar comandos SQL que alterem os
parâmetros textualmente, ou utilizar o pacote de ferramentas da Oracle chamado Oracle
Enterprise Manager (OEM). Pode-se verificar um exemplo de como alterar estes parâmetros
via SQL na seção 3.2 que fala de trace . Para utilizarmos o OEM, será necessário termos
privilégios de administrador. Os passos a seguir, descrevem como proceder para realizar a
alteração dos parâmetros utilizando a interface gráfica.
• Clicar em Iniciar Programas Oracle Oracle Enterprise Manager;
• Informar usuário e senha e conectar como SYSDBA
• Expandir a ramificação Rede;

21
• Expandir a ramificação Banco de Dados;
• Expandir a ramificação do banco de dados escolhido;
• Expandir a ramificação Instancia;
• Clicar em Configuração (ver Figura 2)
Figura 2 – Configuração dos parâmetros de inicialização
• Na janela da direita, no pé da página tem um botão que torna visível todos os parâmetros
de inicialização do Oracle, como mostra a Figura 3.
22
Figura 3 – Parâmetros de inicialização do Oracle
• Basta clicar sobre o item que deseja alterar e clicar no botão “Aplicar” para o parâmetro
ser alterado. Em seguida, uma mensagem do BD informará que os parâmetros foram
alterados.
3 FERRAMENTAS
A Oracle desenvolveu uma vasta ramificação de aplicativos específicos para avaliação
de desempenho. Entre estes aplicativos estão o EXPLAIN PLAN e o TKPROF, que foram os
dois aplicativos escolhidos para a avaliação de desempenho do banco de dados neste trabalho.
Neste capítulo, são descritas as ferramentas utilizadas para avaliar o desempenho do banco de
dados Oracle quando este é submetido a uma carga elevada de dados concorrendo entre vários
processos de usuários.
3.1 EXPLAIN PLAN

Esta seção explica o funcionamento do EXPLAIN PLAN, que é bastante utilizado
para visualizar o plano de execução gerado pelo otimizador.
O EXPLAIN PLAN mostra a execução das sentenças SQL, onde o otimizador Oracle
faz uma escolha para a seleção e atualização dos dados do banco de dados. É a seqüência de
operações necessárias executadas pelo otimizador para realizar uma consulta. Quando
executado, seus dados que descrevem o plano, são armazenados em uma tabela na base de
dados. Seus resultados ajudam a entender as decisões tomadas pelo otimizador e explicar o
desempenho de uma consulta. O uso isolado do EXPLAIN PLAN não é totalmente eficiente,
sendo necessário o uso de uma outra ferramenta para que se possa analisar a real situação do
problema. Uma ferramenta muito utilizada é o Trace, que rastreia, com detalhes, valores de
desempenho do SGBD.
Antes de usar o EXPLAIN PLAN, é necessário criar uma tabela onde serão
armazenados seus dados de saída.
O banco Oracle mantém um arquivo chamado UTLXPLAN.SQL – que deve estar

localizado em $ORACLE_HOME\rdbms\admin, que cria esta tabela com o nome de
24
PLAN_TABLE. Nesta tabela, o EXPLAIN PLAN irá inserir as linhas que descrevem a
execução do plano.
Para gerar os dados na tabela PLAN_TABLE, basta digitar:
EXPLAIN PLAN FOR
<Comando SQL>
Também é possível especificar identificadores para em um outro momento usá-los,

para identificar execuções específicas do plano como, por exemplo:
EXPLAIN PLAN SET STATEMENT_ID=<<identificador>> FOR
<comando SQL>
Um outro recurso, é utilizar diferentes tabelas através da cláusula INTO
EXPLAIN PLAN INTO <<nome_tabela>> FOR
<comando SQL>
O banco Oracle também mantém dois arquivos SQL para mostrar a saída mais recente
da tabela PLAN_TABLE. O Arquivo UTLXPLS.SQL mostra a saída da tabela para
processamento serial, enquanto o arquivo UTLXPLP.SQL mostra a saída da tabela para
colunas paralelas. O Quadro 4, descreve as colunas da tabela PLAN_TABLE
Quadro 4 – Colunas da tabela PLAN_TABLE

Nome da Coluna Tipo Descrição
STATEMENT_ VARCHAR2(30) Valor do parâmetro opcional STATEMENT_ID especificado na
ID sentença EXPLAIN PLAN
TIMESTAMP DATE Data e hora que o EXPLAIN PLAN foi iniciado
REMARKS VARCHAR(80) Qualquer comentário que se queira associar com cada passo do
EXPLAIN PLAN
OPERATION VARCHAR2(30) Nome da operação interna executada pelo passo: INSERT,
DELETE, SELECT ou UPDATE.
OBJECT_NODE VARCHAR2(128) Nome do Database usado para referenciar o objeto (Nome da
Tabela ou Visão). Para consultas locais, esta coluna descreve a
ordem de saída para a operação FROM.
OBJECT_OWNER VARCHAR(30) Nome do usuário proprietário
OBJECT_NAME VARCHAR(30) Nome da tabela ou índice
OBJECT_ NUMERIC Número correspondente a posição do objeto, como aparece na
INSTANCE sentença original
OBJECT_TYPE VARCHAR(30) Informação descritiva sobre o objeto. Exemplo: NON-UNIQUE
para índices
OPTIMIZER VARCHAR2(255) Estado atual do otimizador
ID NUMERIC Número atribuído para cada passo da execução
PARENT_ID NUMERIC O ID do próximo passo da execução
25
Quadro 4 – Colunas da tabela PLAN_TABLE (cont.)

Nome da Coluna Tipo Descrição
POSITION NUMERIC Para a primeira linha da saída, indica o custo estimado da
execução para o otimizador. Para as demais linhas, indica a
posição relativa dos outros filhos para o mesmo pai.
COST NUMERIC Custo da operação estimada pelo otimizador. O valor desta
coluna é uma função das colunas CPU_COST e IO_COST
CARDINALITY NUMERIC Número aproximado de linhas acessadas pela operação.
BYTES NUMERIC Número aproximado de bytes acessados pela operação.
OTHER_TAG VARCHAR2(255) Conteúdo da coluna OTHER.
PARTITION_ VARCHAR2(255) Partição inicial de um intervalo de partições acessadas. Pode
START assumir um destes valores:
n: Indica que a partição identificou o compilador SQL
e seu valor foi dado por n.
KEY: Indica que a partição inicial será identificada em
tempo de execução
ROW LOCATION: Indica que a partição inicial será
computada em tempo de execução, a partir da localização de
cada registro.
INVALID: Indica que o intervalo das partições
acessadas está vazio.
PARTITION_ VARCHAR2(255) Partição final de um intervalo de partições acessadas. Pode
STOP assumir um destes valores:
n: Indica que a partição identificou o compilador SQL
e seu valor foi dado por n.
KEY: Indica que a partição final será identificada em
tempo de execução
ROW LOCATION: Indica que a partição final será
computada em tempo de execução, a partir da localização de
cada registro.
INVALID: Indica que o intervalo das partições
acessadas está vazio.
PARTITION_ID NUMERIC Passo que computou o par de valores das colunas
PARTITION_START e PARTITION_STOP.
OTHER LONG Informações específicas que o usuário achar importante.
DISTRIBUTION VARCHAR(30) Grava o método usado para distribuir linhas do servidor para o
usuário.
CPU_COST NUMERIC Custo da operação estimada pelo otimizador. O valor desta
coluna é proporcional ao número de ciclos de máquina
necessários para a operação.
IO_COST NUMERIC O custo de E/S estimado pelo otimizador. O valor desta coluna
é proporcional ao número de blocos de dados lidos por
operação.
TEMP_SPACE NUMERIC Espaço temporário (em bytes) usado pela operação. Este tempo
é estimado pelo otimizador. Para sentenças que não usam
nenhum espaço temporário, o valor desta coluna é nulo.
3.2 TRACE
Para um melhor monitoramento de aplicações rodando em servidores Oracle, foram
desenvolvidas algumas ferramentas para diagnóstico de desempenho: SQL TRACE e
TKPROF. Para um melhor desempenho, usa-se estas ferramentas em conjunto com o
EXPLAIN PLAN. A seguir, será detalhado o funcionamento de cada uma destas ferramentas.
26
SQL TRACE é uma ferramenta que fornece informações de desempenho de um SQL

individual. O SQL Trace pode ser programado para atuar sobre uma seção. Quando isto
acontece, todas informações estatísticas de desempenho executadas na seção do usuário, são
copiadas para arquivos específicos. Porém, as informações contidas nestes arquivos são
ilegíveis, de modo que é necessário usar a ferramenta de TKPROF para formatar estas
informações e gerar uma saída de dados legível. O TKPROF reporta cada sentença executada
com cada pesquisa que foi usada. Também reporta o número de vezes que a pesquisa foi
chamada e o número de linhas que foram processadas. Assim, é possível localizar facilmente
as sentenças que estão utilizando os maiores recursos.
Primeiramente, deve-se habilitar o serviço de SQL Trace, e logo após executando a

sentença SQL. Por exemplo:
alter session set SQL_TRACE=true;
É importante salientar que o SQL TRACE gera uma sobrecarga no SGBD, sendo
imprescindível desabilitá-lo ao término das operações que se deseja monitorar. Para
desabilitar, basta digitar:
alter session set SQL_TRACE=false;
Cada vez que um usuário conecta-se BD Oracle com o parâmetro SQL_TRACE ativo,
é gerado um arquivo de trace, onde os dados estarão constantemente sendo monitorados e
agrupados até que o usuário se desconecte do banco. Ao se conectar novamente, um novo
arquivo é gerado.
De posse deste arquivo, é possível utilizar a ferramenta de TKPROF para que se possa
analisar o plano de execução do banco de dados para as consultas ou atualizações que foram
feitas.
Os parâmetros que o TKPROF requer, são passados na própria linha de comando. No

quadro 5, são descritos os parâmetros desta ferramenta.
Quadro 5 – Parâmetros do TKPROF

Parâmetro Significado
Filename1 Arquivo de entrada contendo as estatísticas geradas pelo SQL Trace.
Filename2 Arquivo no qual o TKPROF irá escrever a saída formatada. É um arquivo em formato texto.
SORT Ordena as sentenças executadas em ordem decrescente, de acordo com a variável escolhida. As
mais usadas são: EXECPU (que é o tempo de CPU gasto na execução) e o FCHCPU (que é o
tempo de CPU gasto com fetch).
27
Quadro 5 – Parâmetros do TKPROF (cont.)

Parâmetro Significado
Print Lista somente a primeira sentença SQL ordenada no arquivo de saída. Se este parâmetro for
omitido, então são listados todos os valores.
Agregate Se for especificado AGREGATE=NO, então o TKPROF não agrega os múltiplos usuários do
mesmo comando SQL
Insert Cria um script SQL que grava as estatísticas do arquivo trace na base de dados. Este script é
criado com o nome de filename3. Ele cria uma tabela e insere linhas de estatísticas para cada
sentença SQL gerados pela ferramenta SQL TRACE
SYS Habilita e desabilita a listagem de sentenças SQL executadas pelo usuário SYS.
Table Especifica o nome da tabela em que o TKPROF coloca temporariamente a execução do plano,
antes de escrevê-lo em um arquivo de saída.
EXPLAIN Determina a execução do plano para cada sentença SQL no arquivo trace e escreve a execução
do plano no arquivo de saída. O TKPROF determina a execução do plano depois de conectar ao
Oracle com o usuário e a senha especificados no parâmetro.
RECORD Cria um script SQL com um nome de arquivo especificado, contendo todos SQL não-recursivos
no arquivo trace.
Exemplo de Uso:
TKPROF tcc_ora_2546.trc texto_de_saida.txt EXPLAIN=scott/tiger

TABLE=scott.temp_plan_table_a INSERT=STOREA.SQL SYS=NO SORT=(EXECPU,FCHCPU)
No exemplo acima:
• tcc_ora_2546.trc é o arquivo trace contendo o resultado da avaliação;
• texto_de_saida.txt é o arquivo de saída, ou seja, o arquivo com a saída de dados

legível gerado pelo TKPROF a partir do arquivo de trace;
• EXPLAIN=scott/tiger significa que o TKPROF irá se conectar ao Oracle

informando a sigla do usuário e a senha, no caso, usuário=scott e senha=tiger;
• TABLE=scott.temp_plan_table_a é a tabela onde o tkprof coloca temporariamente

seus planos de execução antes de escreve-lo no arquivo de saída;
• INSERT cria um script SQL que grava as estatísticas do arquivo trace na base de
dados;
• SYS=NO significa que não serão listadas as sentenças SQL do usuário SYS;
• SORT=(EXECPU, FCHCPU) significa que o arquivo trace será ordenado de

forma decrescente de acordo como o especificado na opção sort.
O TKPROF lista estatísticas para sentenças SQL retornadas pelo SQL TRACE em
colunas e linhas. Cada linha corresponde a um dos três passos processados:
28
• PARSE: Traduz sentenças SQL para planos de execução, incluindo checagem de

autorização de segurança, existência de tabelas, colunas e outros objetos
referenciados.
• EXECUTE: Execução atual da sentença pelo Oracle. Para INSERT, DELETE a

UPDATE, os valores são modificados. Para SELECT, somente identifica as linhas
selecionadas.
• FETCH: Recupera as colunas executadas por uma query. Fetch são executados
somente em sentenças SQL.
As outras colunas são estatísticas combinadas de todas sentenças fetch, execute e

parse. O quadro 6 descreve os campos da tabela do TKPROK.
Quadro 6 – Descrição dos campos da tabela TKPROF

Nome da Coluna Descrição
COUNT Numero de vezes que uma sentença é analisada, buscada ou executada.
CPU Tempo total de CPU (em segundos) para todas chamadas ao parse, execute ou fetch.
Este valor é zero se o parâmetro TIMED_STATISTICS não é acionado.
ELAPSED Tempo total expirado (em segundos) para todas chamadas ao parse, execute ou fetch.
Este valor é zero se o parâmetro TIMED_STATISTICS não é acionado.
DISK Número total de blocos de dados fisicamente lidos do arquivo de dados no disco para
chamadas parse, execute e fetch.
QUERY Número total de buffers recuperados de modo consistente para todas chamadas a fetch,
execute e parse.
CURRENT Número total de buffers recuperados no modo atual. Os buffers são recuperados no
modo corrente para sentenças INSERT., DELETE e UPDATE.
Estatísticas sobre linhas processadas aparecem na coluna ROWS. Este número total
não inclui linhas processadas por subqueries. A tabela 1 representa um exemplo de uma
análise realizada pelo Tkprof.
Tabela 1 – Exemplo de tabela montada pelo TKPROF

Call Count Cpu Elapsed Disk Query Current Rows
Parse 11 0,08 0,18 0 0 0 0
Execute 11 0,23 0,66 0 3 6 0
Fetch 35 6,7 6,83 100 12326 2 824
Total 57 7,01 7,67 100 12329 8 826
Perdas na biblioteca durante a analise: 0
O exemplo acima indica que a sentença foi analisada 57 vezes, levando 7,01 segundos
de tempo total com 100 blocos de dados lidos fisicamente, sendo que 8 blocos de dados foram
29
recuperados do buffer no modo atual e 826 linhas foram processadas, lembrando que as linhas
das subconsultas envolvidas não são contadas.
3.3 GRÁFICOS DE ACOMPANHAMENTO

Embora o uso do EXPLAIN PLAN e das ferramentas de TRACE possam fornecer
informações precisas sobre o desempenho do banco de dados, até mesmo um especialista
pode ficar confuso com resultados expressos em números, pois a quantidade de dados
analisados torna-se muito grande. Uma solução bastante adequada para o problema é a
representação gráfica dos dados analisados, uma vez que gráficos são muito mais fáceis de
visualizar do que uma planilha de valores numéricos.
Preocupada com este problema, a Oracle desenvolveu pacotes que monitoram o

desempenho do banco. Um destes pacotes é denominado de ORACLE ENTERPRISE
MANAGER. Nele, estão disponíveis sistemas de gerenciamento como o Oracle Diagnostic
Pack, que é um conjunto sofisticado de ferramentas de fácil uso que podem fazer com que o
cliente obtenha um ganho extraordinário em termos de produtividade.
Um dos aplicativos existentes no pacote Oracle Diagnostic Pack é o Oracle

Performance Manager, que permite monitorar o desempenho do banco, suas aplicações
relacionadas e sistemas operacionais em tempo real. Ele permite ao sistema e ao
administrador do BD monitorar estatísticas, gravá-las e executá-las novamente mais tarde.
Estas estatísticas podem ser mostradas de inúmeras maneiras, como: tabelas verticais e
horizontais, barras horizontais e verticais, gráfico no formato de torta e outros tipos de
gráficos pré-definidos. Uma vez que o Oracle Performance Manager é integrado com o
Oracle Capacity Planer, uma visão histórica dos dados também pode ser montada.
O Oracle Performance Manager é capaz de analisar o desempenho do SGBD através

de uma interface gráfica. Quando os pacotes são instalados, o instalador cria um atalho para
Performance Manager. A partir do menu principal, é possível escolher um CHART e
visualizá-lo (SHOW CHARTS). Os dados são analisados e os gráficos são gerados
automaticamente, uma vez que um script SQL, que faça uma consulta ou atualização no BD,
seja executado. A Figura 4 representa um exemplo de gráfico realizado pelo aplicativo Oracle
Performance Manager.
30
Figura 4 – Gráfico de acompanhamento7
7
Figura obtida atravéz de uma tela do ORACLE PERFORMANCE MANAGER
4 SISTEMA DE AVALIAÇÃO
Este capítulo demonstra algumas técnicas utilizadas na avaliação de desempenho do
BD Oracle 9i. Também são apresentados os parâmetros observados na análise de
desempenho, assim como os softwares que realizaram esta análise.
4.1 TRANSACTION PROCESSING PERFORMANCE COUNCIL

Para avaliar o desempenho do banco de dados Oracle 9i, é necessário submetê-lo a
diversos testes para que se possa avaliar o seu comportamento sob uma situação real de
trabalho. Para realizar estes testes, foi adotada uma base de dados padrão proposto por TPC8.
TPC é uma entidade que define processos de transações e bases de dados destinados às
indústrias.
O modelo escolhido foi o TPC-C, pois é o que melhor se adapta ao plano de testes que
é baseado em um sistema cliente-servidor.
A empresa que representa o modelo de benchmark é um fornecedor atacadista com um

número de distritos associados e depósitos distribuídos geograficamente. Conforme os
negócios aumentam, novos distritos e depósitos vão sendo criados. Cada depósito cobre 10
distritos. Cada distrito atende a 3.000 clientes. Cada depósito mantém estoque para 100.000
itens vendidos pela empresa. A figura 5 ilustra os depósitos, os distritos e os clientes.
8
TPC BENCHMARK™ C. Standard Specification, Rev.5.0 , fev. 2001. Disponível em : <http://www.tpc.org> Acesso em:
5 jun. 2002.
32
Figura 5 – Diagrama representativo
Os clientes ligam para a empresa para fazer novos pedidos ou saber a situação de seus
pedidos existentes. Cada pedido tem uma média de dez itens. Um por cento dos pedidos são
para itens não-estocados e precisam ser repostos por outro depósito. O sistema da empresa
também é usado para receber pagamento de clientes, processar ordens para compras, e
examinar os níveis de estoque para identificar depósitos que possam suprir os demais. Os
componentes do BD consistem em nove tabelas individuais separadas. O relacionamento
entre estas tabelas estão definidas no diagrama ER mostrado na figura 6, e estão sujeitas as
regras especificadas na cláusula 1.4 de TPC(2002).
Figura 6 – Modelo de BD para TPC

33
Na figura 6, os números ilustram a exigência populacional do BD, o número nos

blocos de entidade representa a cardinalidade da tabela, o número próximo às setas representa
a cardinalidade dos relacionamentos e o símbolo mais (+) ilustra que o número esta sujeito a
pequenas variações.
Nesta base de dados foram executadas leitura e escrita de diversos processos,

abrangendo desde pequenas informações, até grandes movimentações de dados. Estes
processos serão mais bem detalhados no decorrer deste capítulo. As tabelas que representam o
modelo acima descrito, encontram-se no anexo A.
4.2 PROJETO DO SISTEMA DE AVALIAÇÃO

O projeto consiste em medir o desempenho do banco de dados para consultas e
atualizações, conforme os parâmetros de inicialização do Oracle são alterados. Estes
parâmetros são definidos quando o sistema é instalado.
Para uma melhor avaliação da situação, se faz necessário a construção de um

aplicativo que possa rodar estas consultas ou atualizações concorrentemente através do uso de
threads. Este aplicativo foi desenvolvido em Delphi, que possui os componentes essenciais
para tal sistema, facilitando o desenvolvimento do software. Este aplicativo deve ser
executado em um cliente, onde as threads irão simular um sistema multiusuário. São
disparados 10 processos que irão realizar consultas e atualizações na base de dados
concorrentemente, simulando um sistema multiusuário com 10 clientes conectados ao banco.
4.2.1 Execução do Projeto

O primeiro passo é criar na base de dados o esquema relacional correspondente,
conforme definição do benchmark TPC-C.
Definido o esquema, o software de teste pode ser executado. Assim, os arquivos

contendo os planos de execução das consultas e alterações, são criados para uma posterior
análise através do EXPLAIN PLAN e SQL Trace.
Com o auxílio destas ferramentas, verifica-se claramente o nível de desempenho do

banco para cada situação. Caso seja necessário, ainda é possível obter uma interface gráfica
da situação utilizando-se a ferramenta Oracle Performance Manager.
34
Devido ao grande volume de dados envolvido e às várias proporções entre consultas e

atualizações testadas, para cada valor de um parâmetro, o tempo total de execução de todo
teste resulta em muitas horas, contudo, só este processo não torna o resultado confiável.
Ao final do processo, é obtida a execução dos planos para todos os parâmetros, e só

então pode-se chegar a uma conclusão que define o efeito dos parâmetros sob o SGBD.
4.2.2 Aplicativo Delphi

Avaliar o desempenho de um banco de dados é uma tarefa árdua tanto para o DBA
quanto para o BD. As operações realizadas sobre ao banco de dados para análise, levam
horas para serem completamente executadas, e ficar cronometrando o tempo de execução de
cada uma delas no relógio não é razoável.
Para minimizar o trabalho, podem ser utilizados softwares de avaliação de

desempenho. Estes programas calculam o tempo de execução de cada consulta ou alteração,
gravando o resultado em um arquivo texto. Mais tarde o DBA poderá avaliar o desempenho
do BD verificando o resultado computado pelo software.
A figura 7 ilustra um diagrama de seqüência do modelo UML, descrevendo o

funcionamento dos aplicativos Lançador e TCC.
Figura 7 – Diagrama de Sequência

35
Software Lançador:
Quando o lançador é chamado, ele percorre o diretório de parâmetros montando uma

lista com o nome dos parâmetros disponíveis a escolha do DBA para executar os testes no
BD. Uma vez escolhido o parâmetro e o número de conjuntos a ser executado (1, 2 ou 3),
basta clicar no botão “Iniciar Teste no Banco” e aguardar ate que ele compute todos
resultados. A figura 8 mostra a tela utilizada pelo usuário.
Figura 8 – Interface do Software “Lançador de Aplicações”
O lançador chama o TCC, passando o nome do arquivo texto cujo parâmetro deve ser
alterado e a quantidade de conjuntos que este deve executar. Quando termina, o TCC salva os
resultados dos tempos de execução e passa o controle para o lançador, que irá encerrar sua
execução.
Software TCC:
O programa TCC é composto de um formulário, dez instâncias da classe Thread e um

DataModule, que é um formulário que guarda dois tipos de componentes: TDataBase e
TQuery, onde o componente TDataBase controla a conexão com o BD, inclusive é nele que
são definidos os parâmetros, e o componente TQuery é o responsável pela execução das
consultas e atualizações. Não necessita da intervenção do usuário, pois se auto-executa e
encerra automaticamente após o término.
A lógica do programa é bastante simples: quando o formulário principal é ativado, o

arquivo de parâmetros especificado é atribuído para a propriedade params do componente
DataBase e este é ativado. Desta maneira, o componente já está trabalhando com as novas
definições de parâmetros do banco. Então, é obtida a hora inicial e inicia-se a execução das
threads para o primeiro conjunto.
Uma variável do tipo inteiro, que controla o número de threads que estão rodando, é
definida inicialmente como dez. Outras duas variáveis também são definidas. A variável
Selects, que controla o numero de seleções, é definida como 10. A variável Updates, recebe o
36
número de seleções subtraído de dez. Assim, é estabelecida a proporção de seleções e

atualizações executando concorrentemente. Quando as threads são criadas, é passado por
parâmetro o valor false, indicando que devem iniciar imediatamente sua execução, sem
interromper a execução dos próximos passos. Quando uma thread termina sua execução, ela
ativa um procedimento chamado ThreadsDone, que decrementa o número de threads
rodando. Quando o numero de threads chegar a zero, é chamado um procedimento com o
nome de NovoProcesso. Este procedimento verifica se a variável Selects chegou a zero, ou
seja, se toda a proporção foi executada. Caso não tenha chegado a zero, é disparado o
procedimento Salva, que obtém a hora naquele instante, e grava em um arquivo os valores de
todos parâmetros, o conjunto que está sendo testado, a proporção de seleções e atualizações, o
tempo de resposta e o parâmetro que foi alterado. Então, reinicia todo o processo para uma
nova proporção, setando o número de threads para 10 e reiniciando todas as threads. Quando
a variável selects chegar a zero, ele simplesmente salva os resultados no arquivo e encerra seu
funcionamento. Então, o controle do processamento volta a ser do Lançador, que finalmente
termina sua execução.
Configuração:
O sistema é configurado através de um conjunto de arquivos, mantidos em

subdiretórios, ilustrado na figura 9.
Figura 9 – Subdiretórios envolvidos
No subdiretório Exec, ficam os arquivos executáveis do programa e os demais

diretórios constituem-se de arquivos texto.
37
No subdiretório parâmetros são armazenados os arquivos de configuração de

parâmetro do SGBD. O nome de cada arquivo corresponde ao nome do parâmetro do banco
que será alterado, seguido de um underline "_" e o número da seqüência do valor testado.
Neste trabalho, optou-se por testar quatro valores diferentes para cada parâmetro considerado.
O software de testes permite alterar outros parâmetros dinâmicos e, para cada parâmetro, um
número de alternativas maior, se for desejado pelo usuário. Os arquivos de parâmetros são
arquivos-texto comuns, que podem ser criados em qualquer editor simples. Por exemplo, o
parâmetro LOG_CHECKPOINT_TIMEOUT possui como valor padrão 1800 segundos. Uma
alternativa de alteração deste valor, é de 1500 segundos, logo, seu arquivo de configuração é
demonstrado na figura 10.
DATABASE NAME=
USER NAME=marin
ODBC DSN=Teste1
OPEN MODE=READ/WRITE
SCHEMA CACHE SIZE=8
SQLQRYMODE=
LANGDRIVER=
SQLPASSTHRU MODE=SHARED AUTOCOMMIT
SCHEMA CACHE TIME=-1
MAX ROWS=-1
BATCH COUNT=200
DB_BLOCK_BUFFERS=50
DB_CACHE_SIZE=25165824
DB_FILE_MULTIBLOCK_READ_COUNT=16
GLOBAL_CONTEXT_POOL_SIZE=1
LOCK_SGA=FALSE
LOG_CHECKPOINT_TIMEOUT=1500
OPTIMIZER_INDEX_CACHING=0
OPTIMIZER_INDEX_COST_ADJ=100
OPTIMIZER_MAX_PERMUTATIONS=2000
OPTIMIZER_MODE=CHOOSE
PRE_PAGE_SGA=FALSE
QUERY_REWRITE_ENABLED=FALSE
QUERY_REWRITE_INTEGRITY=ENFORCED
ROW_LOCKING=ALWAYS
SGA_MAX_SIZE=135338868
SORT_AREA_SIZE=524288
ENABLE SCHEMA CACHE=FALSE
SCHEMA CACHE DIR=
BLOB SIZE=32
ENABLE BCD=FALSE
ROWSET SIZE=20
BLOBS TO CACHE=64
PASSWORD=marin
Figura 10 – Configuração do parâmetro LOG_CHECKPOINT_TIMEOUT
Tabelas são
numeradas
No quadro 7, todos parâmetros com as respectivas alternativas de valor, utilizados
neste trabalho, estão descritas. Esta relação atende a sugestão da Oracle sobre os principais
38
parâmetros que podem afetar o desempenho do SGBD9. O valor padrão está destacado em
Providencia o
negrito. negrito. Sempre do menor para o
maior valor.
Quadro 7 – Parâmetros e valores utilizados

Parâmetros Valor 1 Valor 2 Valor 3 Valor 4
DB_BLOCK_BUFFERS 50 100 150 200
DB_CACHE_SIZE 12.582.912 25.165.824 37.748.736 50.331.648
DB_FILE_MULTIBLOCK_ 4 8 12 16
READ_COUNT
GLOBAL_CONTEXT_ 1 2 3 4
POOL_SIZE
LOCK_SGA TRUE FALSE
LOG_CHECKPOINT_ 1.200 1.500 1.800 2.100
TIMEOUT
OPTIMIZER_INDEX_ 0 25 50 75
CACHING
OPTIMIZER_INDEX_ 50 100 200 500
COST_ADJ
OPTIMIZER_ 2.000 50.000 80.000 100.000
MAX_PERMUTATIONS
OPTIMIZER_ FIRST_ ALL_ CHOOSE RULE
MODE ROWS ROWS
PRE_PAGE_SGA TRUE FALSE
QUERY_REWRITE_ TRUE FALSE
ENABLED
QUERY_REWRITE_ STALED_ TRUSTED ENFORCED
INTEGRITY TOLERATED
ROW_LOCKING ALWAYS DEFAULT INTENT
SGA_MAX_SIZE 135.338.868 67.669.434 203.008.302 270.677.736
SORT_AREA_SIZE 131.072 262.144 524.288 1.048.576
No diretório Queries, existem outros subdiretórios (Conj1, Conj2 e Conj3), que

representam os conjuntos de consultas e atualizações que serão utilizadas pelo software para
analisar o desempenho. Cada diretório possui diferentes combinações de seleções (select) e
atualizações (update). Isto permite analisar a influência de mecanismos de controle de
concorrência e recuperação de falhas no desempenho do SGBD, em diferentes cenários.. A
primeira linha de cada arquivo destes diretórios deve ser o número de vezes que esta será
executada. Este recurso foi desenvolvido para o caso de uma consulta ou atualização gerar um
valor em segundos menor ou igual a zero, visto que o Delphi não calcula os milésimos de
segundo. Assim, o mesmo comando pode ser repetido n vezes, até o tempo de resposta se
tornar mensurável pelo software.
9
ORACLE CORPORATION. Oracle9i Database Reference. Release 2 (9.2). Redwood Shores:Oracle Press, 2002.
39
Nas figuras 11 e 12, são apresentados os comandos de consulta e atualização utilizados

no conjunto1. A relação completa dos conjuntos encontra-se no anexo B.
select * from item where I_ID=240;

select * from estoque;
select * from cliente order by C_Last Desc;
select count(*), E_I_ID from estoque group by E_I_ID;
select e.*, i.I_Name, i.I_Price from estoque e, item I where
(e.E_I_ID=i.I_ID);
select * from estoque where E_I_ID>=50000;
select * from item;
select * from item order by I_Name;
select count(*), sum(E_Quantity), E_I_ID from estoque group by E_I_ID;
select W.W_Name, D.D_Name, C.C_First, C.C_Phone from deposito W, Distrito
D, Cliente C, Pedido P where (P.P_C_ID=C.C_ID) and (P.P_W_ID=W.W_ID) and
(P.P_D_ID=D.D_ID);
Figura 11 – Seleções utilizadas no conjunto 1
Update item set I_Price=I_Price*1.01 where I_ID=5246;

Update cliente set C_Discount=30;
Update estoque set E_Quantity=E_Quantity-1 where E_W_ID IN (select W_ID
from deposito where W_City='Canoas');
Update cliente set C_Credit='CB' where C_ID IN (select C_ID from pedido p
where (C_ID=P.P_C_ID) and (P.P_PL_CNT>1));
Update estoque set E_Quantity=E_Quantity+1 where E_I_ID IN (select E_I_ID
from item I where E_I_ID=I.I_ID);
Update item set I_Price=I_Price*1.15 where I_Price<200;
update cliente set C_City='POA';
update estoque set E_ORDER_CNT=125 where E_W_ID IN (select W_ID from
Deposito);
Update cliente set C_State='RS' where (C_City='Canoas') and (C_ID IN
(select C_ID from pedido p where (C_ID=P.P_C_ID) and (C_D_ID=P.P_D_ID) and
(C_W_ID=P.P_W_ID)));
Update distrito set D_Tax=15 where D_ID=10;
Figura 12 – Atualizações utilizadas no conjunto 1
Por último, no diretório Dados, é armazenado em um único arquivo, o resultado de

todas as execuções para todos os valores dos parâmetros testados. Cada linha deste arquivo
contem os valores, separados pelo delimitador “;”, de todos parâmetros listados nos arquivos
de parâmetros, o cenário que esta sendo executado (1, 2 ou 3), à proporção de selects x
updates (10x0, 9x1, 8x2, ..., 0x10), o tempo de resposta (em segundos) e qual foi o parâmetro
alterado. A partir deste arquivo, é possível importar para uma planilha do Microsoft Excel, e
utilizá-lo como ferramenta de análise dos dados. O MS Excel tem várias alternativas, como
cálculo de médias e totais, relatórios dinâmicos e criação assistida de gráficos, que podem
agilizar o processo. Pelo seu formato, o mesmo arquivo pode ser importado para outros
40
softwares de análise, como SPSS, ou para uma base de dados Oracle, de maneira simples. Na
figura 13 é apresentado o arquivo de resultados, obtidos para cada proporção.
50;25165824;16;1;FALSE;1800;0;100;2000;CHOOSE;FALSE;FALSE;ENFORCED;ALWA…
150;25165824;16;1;FALSE;1800;0;100;2000;CHOOSE;FALSE;FALSE;ENFORCED;ALW…
. . .
Figura 13 – Arquivo Resultado.txt
4.3 CONSULTAS
Esta sessão trata especificamente das consultas que serão geradas pelas threads,
baseando-se no modelo de TPC discutido na sessão 4.1.
São cinco tipos de consultas que serão realizadas:

• Consulta Pontual: Consulta os dados de uma tabela, tendo como chave de procura a
própria chave primária da tabela
Ex.: Selecionar todos dados da tabela ESTOQUE, onde o código do ítem seja
igual a 2437.
select * from ESTOQUE where E_I_ID=2437;
• Consulta Total: Consultas os dados de uma tabela

Ex.: Selecionar todos dados de todos da tabela ITEM.
Select * from ITEM;
• Consulta com Ordenação: Consulta os dados ordenando por alguma tupla

Ex.: Selecionar todos CLIENTES, ordenando-os de forma decrescente por
endereco.
Select * from CLIENTE order by C_Street2 DESC;
• Consulta com Agregação: Consulta os dados, agrupando o resultado por algum critério.
41
Ex.: Procurar a quantidade de clientes e o preco para cada um, onde o nome do
cliente seja algo como A100.
Select count(*), I_Price

From ITEM
Where I_Name like ‘A100%’
Group by I_Price;
• Consulta com Junção: União dos dados de duas tabelas

Ex.: Selecionar todos itens que estão em estoque
Select * from ITEM, ESTOQUE

where ITEM.I_ID=ESTOQUE.E_I_ID;
• Consulta com Junção Múltipla: União dos dados de duas ou mais tabelas
Ex.: Selecionar os itens em estoque em cada depósito
Select * from ESTOQUE, ITEM, DEPOSITO, DISTRITO

Where ESTOQUE.E_I_ID=ITEM.I_ID and
ESTOQUE.E_W_ID=DEPOSITO.W_ID and
DEPOSITO.W_ID=DISTRITO.D_W_ID;
4.4 ALTERAÇÕES
Esta sessão, trata especificamente das alterações que serão geradas pelas threads,
também baseadas no modelo de TPC da sessão 4.1
Assim como as consultas, as alterações também possuem três níveis de complexidade:

• Atualização Pontual: Altera o valor de uma tabela baseado na chave primária
Ex.: Aumentar em 1% o preço do item de código 5342
Update ITEM set I_PRICE=I_PRICE*0.01 where I_ID=5342;
• Atualização Total: Altera uma coluna de toda a tabela

Ex.: Fazer com que todos os clientes tenham o mesmo desconto
Update CLIENTE set C_DISCOUNT=30;
• Atualização com junção: Podem alterar dados de uma tabela, dependendo de uma
condição envolvendo outra tabela
Ex.: Aumentar uma quantidade no estoque para cada item estocado cujo preço
seja maior que 250
42
Update ESTOQUE set E_Quantity=E_Quantity+1 where E_I_ID IN

(select I_ID from item where I_Price>250);
A proporção entre seleções e atualizações foi configurada para variar de 10% em 10%,
isto é, a configuração inicial é de 100% de seleções, após 90% de seleções e 10% de
atualizações, e assim sucessivamente, até chegar a 100% de atualizações. Cada 10%
representa uma thread no sistema. A tabela 2 apresenta a proporção de processos concorrentes
em execução.
Tabela 2 – Número de processos concorrentes de Atualizações X Consultas

Num. Processos Executando Atualizações Num. Processos Executando Consultas
10 0
9 1
8 2
7 3
6 4
5 5
4 6
3 7
2 8
1 9
0 10
Embora o parâmetro SQL_TRACE não tenha sido mencionado, e seu valor padrão
seja FALSE, é importante que ele esteja sempre acionado (TRUE) para que monitorar o
desempenho do banco. Por este motivo, não foi mencionado até o momento.
5 ANÁLISE DOS RESULTADOS
Este capítulo apresenta a descrição dos resultados obtidos. Foram submetidos três
conjuntos de testes. Para cada parâmetro está colocado um conjunto de gráficos mostrando o
tempo de resposta para cada um dos três conjuntos de testes e cada um dos diferentes valores
testados.
Foi percebido, como regra geral, que o maior e o menor tempo de respostas foram
obtidos para o conjunto 1 utilizando-se o valor padrão, com exceção dos parâmetros
DB_CACHE_SIZE e LOG_CHECKPOIN_TIMEOUT, que alcançaram seu maior tempo de
resposta com o valor de 12MB e 2100 segundos respectivamente.
Conjunto 1 - Parâmetro Conjunto 2 - Parâmetro

DB_BLOCK_BUFFERS DB_BLOCK_BUFFERS
Tempo de resposta
Tempo de resposta
200 150
150 100
100
50 50
0
0
%
0%
0%
%
%
%
%
%
%
%
%
%
0%
0%
20
40
60
80
10
10
20
30
40
50
60
70
80
90
10
Proporção de seleções
50 100 150 200 50 100 150 200
Conjunto 3 - Parâmetro
DB_BLOCK_BUFFERS
Tempo de resposta
120
100
80
60
40
20
0
%
%
%
%
%
%
%
%
%
0%
0%
10
20
30
40
50
60
70
80
90
10
50 100 150 200

44
DB_BLOCK_BUFFERS (Padrão=50): O melhor desempenho ocorreu para o conjunto

3, utilizando-se no parâmetro, o valor de 150 Mb. Com esta mudança pode-se verificar que o
processo tornou-se cerca de 21,07% mais rápido do que quando fora executado como o valor
padrão. O pior desempenho, obteve-se com este mesmo valor de parâmetro para o conjunto 2.
Esta alteração, deixou o processo cerca de 42,68% mais lento do que quando executado com o
valor padrão. O esperado seria que o valor máximo representasse o menor tempo de resposta,
já que quanto maior o buffer, menor o número de operações de I/O. O aumento do número de
seleções tende a equalizar o desempenho, porque na atualização o Oracle deve primeiro ler o
bloco e depois gravá-los, o que torna o uso do buffer mais benéfico. Apenas em operações de
seleção, os dados não estão no buffer e devem ser igualmente buscados em disco, não
importando o tamanho do buffer.

DB_CACHE_SIZE DB_CACHE_SIZE
Tempo de resposta
Tempo de resposta
200 150
150 100
100
50 50
0
0
%
0%
0%
%
%
%
%
%
%
%
%
%
0%
0%
20
40
60
80
10
10
20
30
40
50
60
70
80
90
10
12 24 36 48 12 24 36 48
DB_CACHE_SIZE
Tempo de resposta
100
80
60
40
20
0
%
%
%
%
%
%
%
%
%
0%
0%
10
20
30
40
50
60
70
80
90
10
12 24 36 48
DB_CACHE_SIZE (Padrão=24): O melhor desempenho ocorreu para o conjunto 3,

utilizando-se no parâmetro o valor de 36 Mb. Com esta mudança pode-se verificar que o
padrão. O pior desempenho, obteve-se ajustando-se o parâmetro para 12Mb no conjunto 1.
45
valor padrão.

LOCK_SGA LOCK_SGA
Tempo de resposta
200
150 150
Tempo de
resposta
100 100
50 50
0
0
%
0%
0%
0%
20
40
60
80
0%
10
20
40
60
80
10
TRUE FALSE TRUE FALSE
LOCK_SGA
Tempo de resposta
100
80
60
40
20
0
%
%
%
%
%
%
%
%
%
0%
0%
10
20
30
40
50
60
70
80
90
10
TRUE FALSE
LOCK_SGA (Padrão=FALSE): O melhor desempenho ocorreu para o conjunto 1,

utilizando-se no parâmetro, o valor de TRUE. Com esta mudança pode-se verificar que o
padrão. O pior desempenho, obteve-se com este mesmo valor de parâmetro para o conjunto 1.
valor padrão. O tipo de bloqueio da SGA afetou, como se esperaria, as operações de
atualização, porém não ficou claro o seu efeito sobre o desempenho do SGBD.

DB_FILE_MULTIBLOCK_READ_COUNT DB_FILE_ MULTIBLOCK_READ_COUNT
Tempo de resposta
Tempo de resposta
200 150
150 100
100
50 50
0
0
%
0%
0%
%
%
%
%
%
%
%
%
%
0%
0%
20
40
60
80
10
10
20
30
40
50
60
70
80
90
10
4 8 12 16 4 8 12 16
46
DB_FILE_MULTIBLOCK_READ_COUNT
Tempo de resposta
100
80
60
40
20
0
%
%
%
%
%
%
%
%
%
0%
0%
10
20
30
40
50
60
70
80
90
10
4 8 12 16
DB_FILE_MULTIBLOCK_READ_COUNT (Padrão=16): O melhor desempenho

ocorreu para o conjunto 3, utilizando-se no parâmetro, o valor 12. Com esta mudança, o
processo tornou-se 17,86% mais rápido do que quando fora executado como o valor padrão.
O pior desempenho obteve-se utilizando o valor 8 para o conjunto 2. Esta alteração, deixou o
processo 63,33% mais lento do que quando executado com o valor padrão.

GLOBAL_CONTEXT_POOL_SIZE GLOBAL_CONTEXT_POOL_SIZE
Tempo de resposta
Tempo de resposta
200 150
150
100
100
50 50
0
0
%
0%
0%
20
40
60
80
%
%
%
%
%
%
%
%
%
0%
0%
10
10
20
30
40
50
60
70
80
90
10
1 2 3 4
1 2 3 4
GLOBAL_CONTEXT_POOL_SIZE
Tempo de resposta
120
100
80
60
40
20
0
%
%
%
%
%
%
%
%
%
0%
0%
10
20
30
40
50
60
70
80
90
10
1 2 3 4
47
GLOBAL_CONTEXT_POOL_SIZE (Padrão=1): O melhor desempenho ocorreu para

o conjunto 2, utilizando-se no parâmetro, o valor de 2 Mb. Com esta mudança o processo
tornou-se 10,42% mais rápido do que quando fora executado como o valor padrão. O pior
desempenho, obteve-se com o valor de parâmetro em 8 Mb para o conjunto 2. Esta alteração,
deixou o processo 75,95% mais lento do que quando executado com o valor padrão.

LOG_CHECKPOINT_TIMEOUT LOG_CHECKPOINT_TIMEOUT
Tempo de resposta
200 Tempo de resposta 150

150 100
100
50 50
0 0
%
0%
0%
%
%
%
%
%
%
%
%
%
0%
0%
20
40
60
80
10
10
20
30
40
50
60
70
80
90
10
Proporção de seleções Proporção de seleções
1200 1500 1800 2100 1200 1500 1800 2100
LOG_CHECKPOINT_TIMEOUT
Tempo de resposta
120
100
80
60
40
20
0
%
%
%
%
%
%
%
%
%
0%
0%
10
20
30
40
50
60
70
80
90
10
1200 1500 1800 2100
LOG_CHECKPOINT_TIMEOUT (Padrão=1.800): O melhor desempenho ocorreu

para o conjunto 3, utilizando-se no parâmetro, o valor de 1200 segundos. Com esta mudança
pode-se verificar que o processo tornou-se cerca de 16,61% mais rápido do que quando fora
executado como o valor padrão. O pior desempenho, obteve-se com o valor de parâmetro em
1500 segundos para o conjunto 1. Esta alteração, deixou o processo cerca de 15,01% mais
lento do que quando executado com o valor padrão.
48

OPTIMIZER_INDEX_CACHING OPTIMIZER_INDEX_CACHING
Tempo de resposta
Tempo de resposta
200 150
150 100
100
50 50
0
0
%
0%
0%
%
%
%
%
%
%
%
%
%
0%
20
40
60
80
0%
10
10
20
30
40
50
60
70
80
90
10
0 25 50 75 0 25 50 75
OPTIMIZER_INDEX_CACHING
Tempo de resposta
100
80
60
40
20
0
%
%
%
%
%
%
%
%
%
0%
0%
10
20
30
40
50
60
70
80
90
10
0 25 50 75
OPTIMIZER_INDEX_CACHING (Padrão=0): O melhor desempenho ocorreu para o

conjunto 2, utilizando-se no parâmetro, o valor 0. Este valor é o próprio valor padrão. O pior
desempenho, obteve-se com o valor de parâmetro em 75 para o conjunto 1. Esta alteração,
deixou o processo cerca de 18,85% mais lento do que quando executado com o valor padrão.

OPTIMIZER_INDEX_COST_ADJ OPTIMIZER_INDEX_COST_ADJ
Tempo de resposta
Tempo de resposta
200 150
150 100
100
50 50
0
0
%
0%
0%
%
%
%
%
%
%
%
%
%
0%
20
40
60
80
0%
10
10
20
30
40
50
60
70
80
90
10
50 100 200 500 50 100 200 500

49
OPTIMIZER_INDEX_COST_ADJ
Tempo de resposta
150
100
50
0
%
%
%
%
%
%
%
%
%
0%
0%
10
20
30
40
50
60
70
80
90
10
50 100 200 500
OPTIMIZER_INDEX_COST_ADJ (Padrão=100): O melhor desempenho ocorreu

para o conjunto 3, utilizando-se no parâmetro, o valor 500. Com esta mudança pode-se
verificar que o processo tornou-se cerca de 17,32% mais rápido do que quando fora executado
como o valor padrão. O pior desempenho, obteve-se com o valor de parâmetro em 50 para o
conjunto 2. Esta alteração, deixou o processo cerca de 40,08% mais lento do que quando
executado com o valor padrão. A utilização máxima de índice mostrou-se favorável, com o
valor definido para 500, pois obteve tempo de resposta mais baixo em quase todas situações.

OPTIMIZER_MAX_PERMUTATIONS OPTIMIZER_MAX_PERMUTATIONS
Tempo de resposta
Tempo de resposta
150
200
150 100
100
50 50
0 0
%
0%
0%
%
%
%
%
%
%
%
%
%
0%
0%
20
40
60
80
10
20
30
40
50
60
70
80
90
10
10
2000 50000 80000 100000 2000 50000 80000 100000
OPTIMIZER_MAX_PERMUTATIONS
Tempo de resposta
150
100
50
0
%
%
%
%
%
%
%
%
%
0%
0%
10
20
30
40
50
60
70
80
90
10
2000 50000 80000 100000

50
OPTIMIZER_MAX_PERMUTATIONS (Padrão=2.000): O melhor desempenho

ocorreu para o conjunto 1, utilizando-se no parâmetro, o valor de 8000. Com esta mudança
pode-se verificar que o processo tornou-se cerca de 23,96% mais rápido do que quando fora
executado como o valor padrão. O pior desempenho, obteve-se com o valor de parâmetro em
100000 para o conjunto 2. Esta alteração, deixou o processo cerca de 54,31% mais lento do
que quando executado com o valor padrão.

OPTIMIZER_MODE OPTIMIZER_MODE
Tempo de
200
Tempo de
150
resposta
resposta
150 100
100
50 50
0 0
%
0%
0%
0%
0%
20
40
60
80
20
40
60
80
10
10
FIRST_ROWS ALL_ROWS FIRST_ROWS ALL_ROWS

CHOOSE RULE CHOOSE RULE
OPTIMIZER_MODE
Tempo de
150
resposta
100
50
0
%
0%
0%
20
40
60
80
10
FIRST_ROWS ALL_ROWS
CHOOSE RULE
OPTIMIZER_MODE (Padrão=CHOOSE): O melhor desempenho ocorreu para o

conjunto 2, utilizando-se no parâmetro, o valor de CHOOSE. Este valor, é o próprio valor
padrão. O pior desempenho, obteve-se com o valor FIRST_ROWS para o conjunto 1. Esta
alteração, deixou o processo cerca de 13,73% mais lento do que quando executado com o
valor padrão.
51

PRE_PAGE_SGA PRE_PAGE_SGA
Tempo de resposta
Tempo de resposta
200 120
100
150 80
60
100 40
50 20
0
0
%
%
%
%
%
%
%
%
%
0%
0%
10
20
30
40
50
60
70
80
90
%
%
%
%
%
%
%
%
%
0%
0%
10
10
20
30
40
50
60
70
80
90
10 Proporção de seleções
PRE_PAGE_SGA
Tempo de resposta
100
80
60
40
20
0
%
0%
0%
20
40
60
80
10
TRUE FALSE
PRE_PAGE_SGA (Padrão=FALSE): O melhor desempenho ocorreu para o conjunto

2, utilizando-se no parâmetro, o valor FALSE. Este valor, é o próprio valor padrão. O pior
desempenho, obteve-se com o valor de parâmetro em TRUE para o conjunto 1. Esta alteração,
Para grandes quantidades de atualizações, o valor FALSE se mostrou mais favorável.

QUERY_REWRITE_ENABLED QUERY_REWRITE_ENABLED
Tempo de resposta
Tempo de resposta
200 150
150 100
100 50
50 0
0
%
0%
0%
20
40
60
80
10
%
%
%
%
%
%
%
0%
0%
10
20
30
40
50
60
70
80
90
10
52
QUERY_REWRITE_ENABLED
Tempo de resposta
100
80
60
40
20
0
%
0%
0%
20
40
60
80
10
TRUE FALSE
QUERY_REWRITE_ENABLED (Padrão=FALSE): O melhor desempenho ocorreu

para o conjunto 2, utilizando-se no parâmetro, o valor FALSE. Este valor, é o próprio valor
padrão. O pior desempenho, obteve-se com o valor de parâmetro em TRUE para o conjunto 1.
valor padrão.

QUERY_REWRITE_INTEGRITY QUERY_REWRITE_INTEGRITY
Tempo de
resposta
150
Tempo de
200
resposta
150 100
100 50
50 0
0
%
0%
0%
20
40
60
80
%
0%
0%
10
20
40
60
80
10
STALED_TOLERATED STALED_TOLERATED
TRUSTED TRUSTED
ENFORCED ENFORCED
QUERY_REWRITE_INTEGRITY
Tempo de
resposta
100
50
0
%
0%
0%
20
40
60
80
10
STALED_TOLERATED
TRUSTED
ENFORCED
53
QUERY_REWRITE_INTEGRITY (Padrão=ENFORCED): O melhor desempenho

ocorreu para o conjunto 3, utilizando-se no parâmetro, o valor STALED_TOLERATED. Com
esta mudança pode-se verificar que o processo ficou cerca de 17,86% mais rápido do que fora
quando executado com o valor padrão. O pior desempenho, obteve-se também com o valor de
parâmetro em STALED TOLERATED para o conjunto 2. Esta alteração, deixou o processo
cerca de 39,48% mais lento do que quando executado com o valor padrão.

ROW_LOCKING ROW_LOCKING
Tempo de resposta
Tempo de resposta
200 150
150 100
100
50 50
0
0
%
0%
0%
%
%
%
%
%
%
%
%
%
0%
0%
20
40
60
80
10
10
20
30
40
50
60
70
80
90
10
ALWAYS DEFAULT INTENT ALWAYS DEFAULT INTENT
ROW_LOCKING
Tempo de resposta
100
80
60
40
20
0
%
%
%
%
%
%
%
%
%
0%
0%
10
20
30
40
50
60
70
80
90
10
ALWAYS DEFAULT INTENT
ROW_LOCKING (Valor padrão=ALWAYS): O melhor desempenho ocorreu para o

conjunto 2, utilizando-se no parâmetro, o valor ALWAYS. Este valor, é o próprio valor
padrão. O pior desempenho, obteve-se com o valor de parâmetro DEFAULT para o conjunto
1. Esta alteração, deixou o processo cerca de 13,10% mais lento do que quando executado
com o valor padrão.
54

SGA_MAX_SIZE SGA_MAX_SIZE
Tempo de resposta
Tempo de resposta
200 150
150 100
100 50
50 0
0
0%
0%
20
40
60
80
10
%
%
%
%
%
%
%
%
%
0%
0%
10
20
30
40
50
60
70
80
90
10
128 64 192 256 128 64 192 256
SGA_MAX_SIZE
Tempo de resposta
150
100
50
0
%
0%
0%
20
40
60
80
10
128 64 192 256
SGA_MAX_SIZE (Padrão=128): O melhor desempenho ocorreu para o conjunto 2,

utilizando-se no parâmetro, o valor 128. Este valor, é o próprio valor padrão. O pior

SORT_AREA_SIZE SORT_AREA_SIZE
Tempo de resposta
Tempo de resposta
200 150
150 100
100
50 50
0
0
%
0%
0%
20
40
60
80
%
%
%
%
%
%
%
%
%
0%
0%
10
10
20
30
40
50
60
70
80
90
10
128 256 512 1024 128 256 512 1024

55
SORT_AREA_SIZE
Tempo de resposta
150
100
50
0
%
%
%
%
%
%
%
%
%
0%
0%
10
20
30
40
50
60
70
80
90
10
128 256 512 1024
SORT_AREA_SIZE (Padrão=512): O melhor desempenho ocorreu para o conjunto 2,

utilizando-se no parâmetro, o valor 512. Este valor, é o próprio valor padrão. O pior
6 CONCLUSÃO
Este trabalho apresentou um estudo sobre os parâmetros envolvidos na análise de
desempenho do banco de dados Oracle 9i. Foram estudadas as ferramentas utilizadas para
monitorar o desempenho da arquitetura interna do banco, assim como o software
desenvolvido para calcular o tempo gasto para executar as consultas e alterações utilizadas
como teste. Também foram apresentados gráficos minuciosos dos resultados obtidos na fase
de análise.
Verificou-se que os conjuntos de seleções e atualizações obtiveram desempenhos

diferentes devido a quantidade de dados que afetam. O conjunto 2 obteve o melhor
desempenho, pois seus campos de pesquisam referenciam principalmente campos que são
chave primárria da tabela. Isto se faz visível ao conjunto 1, que obteve o pior desempenho
devido ao fato, dentre outros, de fazer a ordenação de uma tabela usando um campo não-
chave muito longo. Atualizações com consultas que utilizam junções, fazem com que o banco
tenha de ler antes de gravar, tornando o processo mais lento. Por esse motivo, o conjunto 2 foi
muito mais rápido que os conjuntos 1 e 3, pois as tabelas não utilizam junções em tabelas
muito extensas. Consultas e atualizações utilizando a cláusula IN, devem obter utilizar como
campo de pesquisa a chave primária, pois assim o tempo de resposta tende a diminuir.
No quadro 8, são apresentadas as conclusões sobre o uso dos parâmetros para o

modelo proposto.
57
Quadro 8 – Conclusões sobre o uso dos parâmetros

Nome do Parâmetro Conclusão
DB_BLOCK_BUFFERS Apresentou melhor desempenho utilizando-se o valor 150, com exceção para o
conjunto 2, onde apresentou melhor resultado com o valor padrão 50.
GLOBAL_CONTEXT_ Apresentou o melhor desempenho, sendo mais rápido que o valor padrão em
POOL_SIZE todas as situações. Apresentou seu melhor desempenho com o valor 4, com
exceção do conjunto 2, onde seu melhor desempenho foi com o valor 2
OPTIMIZER_INDEX_ Apresentou melhor desempenho com o valor 500, com exceção para o conjunto
COST_ADJ 2, onde o melhor resultado foi obtido com o valor padrão 100
OPTIMIZER_MAX_ Apresentou melhor desempenho com o valor 80.000, com exceção para o
PERMUTATIONS conjunto 2, onde o melhor resultado foi obtido com o valor padrao 2.000
Os parâmetros LOCK_SGA, DB_FILE_MULTIBLOCK_READ_COUNT,

LOG_CHECKPOINT_TIMEOUT, QUERY_REWRITE_ENABLED, PRE-PAGE_SGA e
ROW_LOCKING não devem ser modificados, pois apresentam, para a maioria dos conjuntos,
um desempenho pior do que o valor utilizado como valor padrão. A troca de parâmetros para
o conjunto 2 apresentou-se totalmente ineficaz, pois 87,5% os casos resultaram em tempos de
resposta maiores do que os computados com o valor padrão. Por esse motivo, são
apresentadas algumas exceções no processo conclusivo, descritas no quadro 10. Para os
demais parâmetros, foram verificadas situações diversas, porém não conclusivas.
Outro fato importante é que aumentando a quantidade de seleções em relação a

atualizações, alterar os valores dos parâmetros resultou em menos variação no tempo de
resposta. Ou seja, quando o número de seleções é mais alto, o Oracle apresenta um
desempenho mais estável. Ao contrário, quanto maior o número de atualizações, mais
importante é o efeito da troca de valores dos parâmetros, o que obriga os DBA a estarem mais
atentos.
Utilizando-se dos recursos de Trace e do Tkprof foi possível observar que o SGBD
possui uma grande dificuldade em atualizar e pesquisar tabelas muito grandes. Isto se deve, ao
fato de que estas tabelas não podem ser completamente armazenadas na memória, não
restando outra alternativa senão fazer a leitura e escrita no disco. Como o disco é muitas vezes
mais lento que a memória, cada vez que o SGBD necessita de um dado que está em disco, é
necessário que o processador interrompa o processamento para carregar do disco para o
buffer. O Oracle possui um parâmetro que permite que se aumente o tamanho do buffer
padrão, mas mesmo assim, dependendo do tamanho da tabela, este tamanho de bloco tende a
ser pequeno. Por esse motivo, tamanha oscilação nos tempos de resposta dos conjuntos de
dados.
58
Infelizmente, um trabalho de análise de desempenho não é totalmente conclusivo, pois

a quantidade de parâmetros envolvidos e a quantidade de valores que estes podem assumir é
muito grande, de forma que não é possível testar toda a variação. Um outro problema
diagnosticado é o fato de plataformas diferentes obterem valores diferenciados. Ambientes de
teste diferentes, também podem resultar em diferentes valores. O software desenvolvido é
altamente parametrizável, podendo ser utilizado para realizar novas análises no Oracle, e
constitui-se em uma contribuição complementar deste trabalho.
Como trabalhos futuros, sugere-se a continuação deste, utilizando-se diferentes

parâmetros que não puderam ser testados devido a enorme quantidade destes, presente na
arquitetura Oracle.
ANEXO A – TABELAS DO MODELO TPC
Quadro 9 - Layout da tabela DEPÓSITO

Atributo Definição Comentário
W_ID 2 * IDs únicos de W W é o número de depósitos
populados
W_NAME Texto variável, tamanho 10
W_STREET_1 texto variável, tamanho 20
W_STREET_2 texto variável, tamanho 20
W_CITY texto variável, tamanho 20
W_STATE texto fixo, tamanho 2
W_ZIP texto fixo, tamanho 9
W_TAX Numérico, 4 dígitos Imposto
W_YTD Numérico, 12 dígitos Saldo no ano
Chave primária: W_ID
Quadro 10 - Layout da tabela DISTRITO – traduzido de TPC (2002)

D_ID 20 IDs únicos São 10 por Depósito
D_W_ID 2 * IDs únicos de W
D_NAME texto variável, tamanho 10
D_STREET_1 texto variável, tamanho 20
D_STREET_2 texto variável, tamanho 20
D_CITY texto variável, tamanho 20
D_STATE texto fixo, tamanho 2
D_ZIP texto fixo, tamanho 9
D_TAX numérico, 4 dígitos Taxa de vendas
D_YTD numérico, 12 dígitos Saldo no ano
D_NEXT_O_ID 10.000.000 de IDs únicos Próximo número de Pedido
disponível
Chave primária: (D_W_ID, D_ID)
D_W_ID Chave estrangeira: refere W_ID
60
Quadro 11 - Layout da tabela CLIENTE

C_ID 96.000 IDs únicos 3.000 por Distrito
C_D_ID 20 IDs únicos
C_W_ID 2 * IDs únicos de W
C_FIRST texto variável, tamanho 16
C_MIDDLE texto fixo, tamanho 2
C_LAST texto variável, tamanho 16
C_STREET_1 texto variável, tamanho 20
C_STREET_2 texto variável, tamanho 20
C_CITY texto variável, tamanho 20
Quadro 11 - Layout da tabela CLIENTE (cont.)

C_STATE texto fixo, tamanho 2
C_ZIP texto fixo, tamanho 9
C_PHONE texto fixo, tamanho 16
C_SINCE data e hora
C_CREDIT texto fixo, tamanho 2 "CB"=bom, "CR"=ruim
C_CREDIT_LIM Numérico, 12 dígitos
C_DISCOUNT Numérico, 4 dígitos
C_BALANCE Numérico signed, 12 dígitos
C_YTD_PAYMENT numérico, 12 dígitos
C_PAYMENT_CNT numérico, 4 dígitos
C_DELIVERY_CNT numérico, 4 dígitos
C_DATA texto variável, tamanho 500 Informações variadas
Chave primária: (C_W_ID, C_D_ID, C_ID)
(C_W_ID, C_D_ID) Chave estrangeira: refere (D_W_ID, D_ID)
Quadro 12- Layout da tabela HISTÓRICO

H_C_ID 96.000 IDs únicos
H_C_D_ID 20 IDs únicos
H_C_W_ID 2 * IDs únicos de W
H_D_ID 20 IDs únicos
H_W_ID 2 * IDs únicos de W
H_DATE data e hora
H_AMOUNT numérico, 6 dígitos
H_DATA texto variável, tamanho 24 Informações variadas
Chave primária: nenhuma
(H_C_W_ID, H_C_D_ID, H_C_ID) Chave estrangeira: refere (C_W_ID, C_D_ID, C_ID)
(H_W_ID, H_D_ID) Chave estrangeira: refere (D_W_ID, D_ID)
61
Quadro 13 - Layout da tabela NOVO_PEDIDO

NP_P_ID 10.000.000 IDs únicos
NP_D_ID 20 IDs únicos
NP_W_ID 2 * IDs únicos de W
Chave primária: (NP_W_ID, NP_D_ID, NP_P_ID)
(NP_W_ID, NP_D_ID, NP_P_ID) Chave estrangeira: refere (P_W_ID, P_D_ID, P_ID)
Quadro 14 - Layout da tabela PEDIDO

P_ID 10.000.000 IDs únicos
P_D_ID 20 IDs únicos
P_W_ID 2 * IDs únicos de W
Quadro 14 - Layout da tabela PEDIDO (cont.)

P_C_ID 96.000 IDs únicos
P_ENTRY_D data e hora
P_CARRIER_ID 10 IDs únicos, ou null
P_PL_CNT de 5 a 15 Contagem de Pedido_Linha
P_ALL_LOCAL numérico, 1 dígito
Chave primária: (P_W_ID, P_D_ID, P_ID)
(P_W_ID, P_D_ID, P_C_ID) Chave estrangeira: refere (C_W_ID, C_D_ID, C_ID)
Quadro 15 - Layout da tabela PEDIDO_LINHA

PL_P_ID 10.000.000 IDs únicos
PL_D_ID 20 IDs únicos
PL_W_ID 2 * IDs únicos de W
PL_NUMBER 15 IDs únicos
PL_I_ID 200.000 IDs únicos
PL_SUPPLY_W_ID 2 * IDs únicos de W
PL_DELIVERY_D data e hora, ou null
PL_QUANTITY numérico, 2 dígitos
PL_AMOUNT numérico, 6 dígitos
PL_DIST_INFO texto fixo, tamanho 24
Chave primária: (PL_W_ID, PL_D_ID, PL_P_ID, PL_NUMBER)
(PL_W_ID, PL_D_ID, PL_P_ID) Chave estrangeira: refere (P_W_ID, P_D_ID, P_ID)
(PL_SUPPLY_W_ID, PL_I_ID) Chave estrangeira: refere (E_W_ID, E_I_ID)
62
Quadro 16 - Layout da tabela ITEM

I_ID 200.000 IDs únicos 100.000 itens são populados
I_IM_ID 200.000 IDs únicos Image ID associada a Item
I_NAME texto variável, tamanho 24
I_PRICE numérico, 5 dígitos
I_DATA texto variável, tamanho 50 Informação sobre a marca
(brand)
Chave primária: I_ID
Quadro 17 - Layout da tabela ESTOQUE

E_I_ID 200.000 IDs únicos 100.000 populados por Depósito
E_W_ID 2 * IDs únicos de W
E_QUANTITY numérico, 4 dígitos
E_DIST_01 texto fixo, tamanho 24
Quadro 17 - Layout da tabela ESTOQUE (cont.)

E_YTD numérico, 8 dígitos
E_ORDER_CNT numérico, 4 dígitos
E_REMOTE_CNT numérico, 4 dígitos
E_DATA texto variável, tamanho 50 Informação
Chave primária: (E_W_ID, E_I_ID)
E_W_ID Chave estrangeira: refere W_ID
E_I_ID Chave estrangeira: refere I_ID
ANEXO B – CONSULTAS E ATUALIZAÇÕES UTILIZADAS
select * from item where I_ID=240;
select * from estoque;
select * from cliente order by C_Last Desc;
select count(*), E_I_ID from estoque group by E_I_ID;
select e.*, i.I_Name, i.I_Price from estoque e, item I where

(e.E_I_ID=i.I_ID);
select * from estoque where E_I_ID>=50000;
select * from item;
select * from item order by I_Name;
select count(*), sum(E_Quantity), E_I_ID from estoque group by E_I_ID;
select W.W_Name, D.D_Name, C.C_First, C.C_Phone from deposito W, Distrito

D, Cliente C, Pedido P where (P.P_C_ID=C.C_ID) and (P.P_W_ID=W.W_ID) and
(P.P_D_ID=D.D_ID);
Figura 14 – Consultas envolvidas no Conjunto 1
64
Update item set I_Price=I_Price*1.01 where I_ID=5246;
Update cliente set C_Discount=30;
Update estoque set E_Quantity=E_Quantity-1 where E_W_ID IN (select W_ID

from deposito where W_City='Canoas');
Update cliente set C_Credit='CB' where C_ID IN (select C_ID from pedido p
where (C_ID=P.P_C_ID) and (P.P_PL_CNT>1));
Update estoque set E_Quantity=E_Quantity+1 where E_I_ID IN (select E_I_ID

from item I where E_I_ID=I.I_ID);
Update item set I_Price=I_Price*1.15 where I_Price<200;
update cliente set C_City='POA';
update estoque set E_ORDER_CNT=125 where E_W_ID IN (select W_ID from

Deposito);
Update cliente set C_State='RS' where (C_City='Canoas') and (C_ID IN

(select C_ID from pedido p where (C_ID=P.P_C_ID) and (C_D_ID=P.P_D_ID) and
(C_W_ID=P.P_W_ID)));
Update distrito set D_Tax=15 where D_ID=10;

Figura 15 – Atualizações envolvidas no Conjunto 1
select * from cliente where C_CREDIT_LIM<30000;
select * from pedido;
select P.*, C.C_First, C.C_Last from pedido P, Cliente C where

(P.P_C_ID=C.C_ID) order by C.C_Last, C.C_First;
select count(*), C_D_ID, C_W_ID from cliente group by C_D_ID, C_W_ID;

select * from estoque where E_I_ID IN (select I_ID from item);
select * from item where I_ID<30000;
select * from cliente;
select * from estoque order by E_Quantity Desc;
select count(*), P_C_ID, P_D_ID from pedido group by P_C_ID, P_D_ID;
select e.* from estoque e, item i, distrito d where (e.E_I_ID=i.I_ID) and

(e.E_W_ID=d.D_W_ID);
65
update estoque set E_YTD=123456 where E_Quantity<10;
Update item set I_Price=22;
Update cliente set C_Discount=C_Discount-(C_Discount*0.02) where C_ID IN

(select H_C_ID from historico where H_Date<H_Data);
Update estoque set E_Dist_01=E_Dist_02 where E_Order_CNT=123;
Update estoque set E_Remote_CNT=450 where E_I_ID IN (select E_I_ID from

item I where (E_I_ID=i.I_ID) and (i.I_price<12));
Update pedido set P_Carrier_ID=12 where P_ID=520;
Update cliente set C_Since='22/10/03 07:48:30,000000';
Update cliente set C_State='RS' where C_D_ID IN (select C_D_ID from

distrito D where (C_D_ID=D.D_ID) and (C_W_ID=D.D_W_ID) and
(D.D_State='RS'));
Update Estoque set E_YTD=654321 where E_W_ID IN (select W_ID from

deposito);
Update item set I_Price=I_Price*1.12;

Select * from Cliente where C_ID=230;
select * from Item;
Select * from Pedido order by P_ID Desc;
Select count(*), P_W_ID from Pedido group by P_W_ID;
Select e.*, D.W_Name from estoque E, Deposito D where (E.E_W_ID=D.W_ID);
Select * from Estoque where E_I_ID=2437;
Select * from Item;
Select * from Cliente Order by C_Street_2;
Select count(*), I_Price from Item where I_Name like 'A100%' group by
I_Price;
Select * from Estoque E, Distrito D where (E.E_W_ID=D.D_W_ID);

66
Update pedido set P_PL_CNT=3 where P_ID>25000;
Update item set I_Price=25;
Update cliente set C_Street_1=C_Street_2 where C_D_ID IN (Select D_ID

from Distrito where D_Street_1=D_Street_2);
Update Estoque set E_Quantity=E_Quantity+1 where E_I_ID IN (select E_I_ID

from item I where (E_I_ID=i.I_ID) and (i.I_Price>250));
Update Cliente set C_Credit_Lim=60000000 where C_ID IN (Select C_ID from

pedido P where (C_ID=P.P_C_ID) and (P.P_PL_CNT>=1));
Update item set I_Price=29 where I_ID=42673;
Update Estoque set E_Quantity=E_Quantity+1;
Update cliente set C_State='RS';
Update cliente set C_Delivery_CNT=779 where C_D_ID IN (Select D_ID from

distrito where D_Tax=15);
Update Estoque set E_Quantity=E_Quantity-1 where E_I_ID IN (select E_I_ID

from pedido_linha PL where (E_I_ID=PL.PL_I_ID) and
(E_W_ID=PL.PL_Supply_W_ID));
ANEXO C – GRÁFICOS POR PARÂMETRO E CONJUNTO
DB_BLOCK_BUFFERS DB_CACHE_SIZE
800 800
600 600
400 400
200 200
0 0
Conj1 Conj2 Conj3 Conj1 Conj2 Conj3
Valor 1 Valor 2 Valor 3 Valor 4 Valor 1 Valor 2 Valor 3 Valor 4
LOCK_SGA DB_FILE_MULTIBLOCK_READ_COUNT
800 1000
600 800
600
400
400
200 200
0 0
Valor 1 Valor 2 Valor 1 Valor 2 Valor 3 Valor 4

68
GLOBAL_CONTEXT_POOL_SIZE LOG_CHECKPOINT_TIMEOUT
1000 800
800 600
600
400
400
200 200
0 0
OPTIMIZER_INDEX_CACHING OPTIMIZER_INDEX_COST_ADJ
800 800
600 600
400 400
200 200
0 0
OPTIMIZER_MAX_PERMUTATIONS OPTIMIZER_MODE
800 800
600 600
400 400
200 200
0 0

69
PRE_PAGE_SGA QUERY_REWRITE_ENABLED
800 800
600 600
400 400
200 200
0 0
Valor 1 Valor 2 Valor 1 Valor 2
QUERY_REWRITE_INTEGRITY ROW_LOCKING
800 800
600 600
400 400
200 200
0 0
Valor 1 Valor 2 Valor 3 Valor 1 Valor 2 Valor 3
SGA_MAX_SIZE SORT_AREA_SIZE
800 800
600 600
400 400
200 200
0 0

REFERÊNCIAS
DATE, C. J. Introdução a Sistemas de Bancos de Dados. 4.ed. Rio de Janeiro:Campus,
1991.
HEUSER, Carlos Alberto. Projeto de Banco de Dados. Porto Alegre:Sagra Luzzatto, 2000.
LEMKE, Vilson Z. Análise Comparativa dos Parâmetros Envolvidos no Ajuste de
Desempenho dos Bancos de Dados Oracle9i e Interbase 6.5. Gravataí:ULBRA, 2002.
(Trabalho de Conclusão de Curso).
ORACLE CORPORATION. Oracle9i Backup and Recovery Concepts. Release 2 (9.2).
Redwood Shores:Oracle Press, 2002.
ORACLE CORPORATION. Oracle9i Database Administrator´s Guide. Release 2 (9.2).
ORACLE CORPORATION. Oracle9i Database Concepts. Release 2 (9.2). Redwood
Shores:Oracle Press, 2002.
ORACLE CORPORATION. Oracle9i Database New Features. Release 2 (9.2). Redwood
ORACLE CORPORATION. Oracle9i Database Online Documentation. Release 9.0.1.
ORACLE CORPORATION. Oracle9i Database Reference. Release 2 (9.2). Redwood
ORACLE CORPORATION. Oracle9i Getting Started With Oracle Diagnostics Pack.
Release 9.0.1. Redwood Shores: Oracle Press, 2002.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de Banco de
Dados. 3.ed. São Paulo:Makron Books, 1999.
TPC BENCHMARK™ C. Standard Specification, Rev.5.0 , fev. 2001. Disponível em :
<http://www.tpc.org> Acesso em: 5 jun. 2002.
UNIVERSIDADE LUTERANA DO BRASIL
FACULDADE DE INFORMÁTICA
CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO
DECLARAÇÃO
Declaro, para os devidos fins, que o presente Trabalho de Conclusão está apto para
publicação e contém as alterações sugeridas pela banca de avaliação.
Canoas, 29 de dezembro de 2003.
__________________________________
Prof. Miguel Rodrigues Fornari
__________________________________
Felipe Marin Flores

Arquitetura Oracle

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Arquitetura Oracle

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE LUTERANA DO BRASIL

CURSO DE CIÊNCIA DA COMPUTAÇÃO

Felipe Marin Flores

Monografia desenvolvida durante a disciplina de Trabalho

Canoas, dezembro de 2003.

Universidade Luterana do Brasil – ULBRA

Banca Avaliadora composta por: Data da defesa: 22/12/2003.

CIP – Catalogação na Publicação

Análise de desempenho do banco de dados Oracle 9i / Felipe Marin

Trabalho de Conclusão de Curso (Graduação em Ciência da

1. Banco de Dados. 2. Análise de desempenho. 3. Oracle 9i. I.

Dedico este trabalho a meus pais e à minha namorada

Palavras-chaves: Banco de Dados; Análise de Desempenho; Oracle 9i.

Key-words: Database System; Performance Analysis; Oracle 9i.

Um banco de dados é projetado de maneira que se adapte a qualquer situação, de

Com o auxílio de software especialmente desenvolvido é possível medir o tempo de

No segundo capítulo são estudados os conceitos relacionados ao ajuste de parâmetros

No terceiro capítulo, são estudadas as ferramentas utilizadas para analisar o

No capítulo 4, são abordados os assuntos relativos ao sistema de avaliação, ou seja, é

No seguinte, são apresentados os resultados obtidos na análise de desempenho,

• Parâmetros Semi-Dinâmicos: Não exigem que a base de dados seja totalmente

• Parâmetros do SGA: Quando um destes parâmetros é alterado, o Oracle

• Parâmetros de Processo: Afetam o comportamento dos processos internos. Por

estruturadas no formato de árvore. Cada linha retorna um conjunto de linhas para

No quadro 1, estão descritos os parâmetros mais diretamente ligados ao desempenho

Quadro 1 – Parâmetros envolvidos no desempenho do BD

Quadro 1 – Parâmetros envolvidos no desempenho do BD (cont.)

Além deste método, o Oracle usa vários tipos de chaveamento e um modelo de

Figura 1 – Transações e consistência de leitura

Em uma transação, existem três níveis de isolamento: (Oracle Corporation5)

• Serializable: Só tem acesso às mudanças que foram gravadas na hora em que a

• Read-Only: Só tem acesso às mudanças que foram feitas no momento em que a

Existem diferentes tipos de bloqueios, dependendo do tipo de operação estabelecida.

O quadro 2, descreve os principais parâmetros do Oracle envolvidos na concorrência

Quadro 2 – Parâmetros envolvidos na concorrência de dados

2.1.3 Recuperação de Dados

• Erro de Usuário: Um exemplo deste erro é um usuário apagar uma tabela

• Falha em uma instância do BD: Ocorre quando um problema impede uma

• Falha da Rede: É quando falhas na rede de comunicação, interrompem a operação

É inevitável falarmos de cópias de segurança quando o assunto é a recuperação de

• Lógicas: São aquelas que contém os dados lógicos (tabelas, procedimentos). As

Para recuperar o backup físico do arquivo de dados ou do arquivo de controle é

Uma outra estrutura de dados que define um processo de Redo no BD é chamado de

O quadro 3 descreve os parâmetros que estão envolvidos na recuperação de falhas.

Quadro 3 – Parâmetros envolvidos na recuperação de falhas

2.2 ALTERAÇÃO DE PARÂMETROS DO ORACLE

• Informar usuário e senha e conectar como SYSDBA

• Expandir a ramificação Rede;

• Expandir a ramificação Banco de Dados;

• Expandir a ramificação do banco de dados escolhido;

• Expandir a ramificação Instancia;

• Clicar em Configuração (ver Figura 2)

Figura 2 – Configuração dos parâmetros de inicialização

Figura 3 – Parâmetros de inicialização do Oracle

3.1 EXPLAIN PLAN

O banco Oracle mantém um arquivo chamado UTLXPLAN.SQL – que deve estar

Para gerar os dados na tabela PLAN_TABLE, basta digitar:

EXPLAIN PLAN FOR

Também é possível especificar identificadores para em um outro momento usá-los,

EXPLAIN PLAN SET STATEMENT_ID=<<identificador>> FOR

Um outro recurso, é utilizar diferentes tabelas através da cláusula INTO

EXPLAIN PLAN INTO <<nome_tabela>> FOR

Quadro 4 – Colunas da tabela PLAN_TABLE