banco de dados oracle

FACULDADE DE AMERICANA
CURSO DE CIÊNCIA DA COMPUTAÇÃO
CAIO FELIPE GOMES GERMANO
RODRIGO BRONSELLI
BANCO DE DADOS ORACLE:
Conceitos de SGBD e análise de desempenho
AMERICANA, SP
2015
CAIO FELIPE GOMES GERMANO
RODRIGO BRONSELLI
BANCO DE DADOS ORACLE:
Conceitos de SGBD e análise de desempenho
Trabalho de Conclusão de Curso apresentado a
Faculdade de Americana como requisito parcial para
obtenção do Título de Bacharel em Ciência da
Computação.
Orientador: Prof. Gustavo Gomes
AMERICANA, SP
2015
AGRADECIMENTOS
Primeiramente a Deus que permitiu que tudo isso acontecesse, ao longo de
nossas vidas, e não somente nestes anos como universitários, mas que em todos os
momentos é o maior mestre que alguém pode conhecer.
A FAM, seu corpo docente e direção, que nos proporcionaram vislumbrar
esse horizonte superior.
Aos nossos orientadores professores Alexandre Ferreira e Gustavo Gomes,
pelo suporte no pouco tempo que lhes coube, pelas suas correções e incentivos.
Aos nossos pais pelo amor, incentivo e apoio incondicional.
E a todos que direta ou indiretamente, fizeram parte da nossa formação, o
nosso muito obrigado.
"Para se ter sucesso, é necessário amar de
verdade o que se faz. Caso contrário,
levando em conta apenas o lado racional,
você simplesmente desiste. É o que
acontece com a maioria das pessoas."
(Steve Jobs)
RESUMO
O armazenamento de informações em bancos de dados se tornou ponto
crucial de muitos sistemas e empresas. A informação pode ser considerada o
recurso mais valioso da empresa, portanto, conhecer um sistema gerenciador de
banco de dados, ou SGBD, é fundamental para empresas que necessitem
esclarecer dúvidas pertinentes ao tema, juntamente com a importância de uma
analise comparativa entre exemplos de sistemas conceituados presentes no
mercado. Um SGBD possui varias funções como, por exemplo, garantir que as
informações sejam armazenadas de forma segura e eficaz. Assim como a
computação em geral, o SGBD evoluiu de uma arquitetura apenas centralizada para
distribuída, explorando novos conceitos de arquitetura cliente/servidor, onde parte é
executado no computador do usuário e parte é executado no servidor do banco de
dados. Seguindo essa linha, surgiram vários sistemas no mercado, como o Oracle
que, por sua vez, surgiu da empresa de mesmo nome fundada em 1977, suas
características são de um sistema robusto e seguro que conta com diversos
benefícios de quem o adquirir, mas o ponto fraco principal é o custo, que uma
empresa pequena muitas vezes não poderá arcar de início. Um teste de
benchmarking de desempenho de transações feito no programa Benchmark Factory,
mostrou que mesmo processando cargas iguais, o PostgreSQL conseguiu
resultados melhores que o Oracle, que por sua vez, obteve resultado satisfatório se
igualando em muitos steps ao desempenho do PostgreSQL.
Palavras-chave: Informação. Dados. Sistema. Oracle. PostgreSQL.
ABSTRACT
The storage of information in databases has become crucial point of many
systems and businesses. Information can be considered the most valuable resource
of the company, therefore, to know a database management system, or DBMS, it is
critical for companies that need answer questions relevant to the subject, along with
the help of a comparative analysis of examples of systems highly regarded in the
market. A DBMS has various functions such as, for example, ensure that the
information is stored securely and effectively. As general computing, the DBMS has
evolved from a centralized to distributed architecture just by exploring new concepts
of client / server architecture, where part runs on the user's computer and part runs
on the database server. Following this line, there were several systems on the
market, such as Oracle, which in turn came from the eponymous company founded
in 1977, its features are a robust and secure system that has several benefits who
acquire, but the main weakness is the cost, that a small business often cannot afford
to start. A transaction performance benchmark test performed in the benchmark
factory software, the same processing showed that equal loads, PostgreSQL
achieved better results than Oracle, which in turn, obtained satisfactory result in
many steps equaling the performance of the PostgreSQL.
Key-words: Information. Data. System. Oracle. PostreSQL.
LISTA DE FIGURAS
Figura 1 - Diagrama Lógico do SGBD ....................................................................... 13
Figura 2 - Arquitetura Centralizada ........................................................................... 16
Figura 3 – Arquitetura Cliente/Servidor modelo lógico .............................................. 16
Figura 4 - Arquitetura Cliente/Servidor Duas Camadas ............................................ 17
Figura 5 - Arquitetura Cliente/Servidor de Três Camadas ......................................... 18
Figura 6 - Arquitetura do Banco de Dados ................................................................ 23
Figura 7 - Tablespaces e Arquivos de Dados............................................................ 24
Figura 8 - Diagrama do banco de dados TPC-C ....................................................... 30
Figura 9 - Configurações das máquinas virtuais ....................................................... 32
Figura 10 - Conexão do Benchmark Factory com SGBD .......................................... 34
Figura 11 - Resumo dos parâmetros e configurações do Job TPC-C ....................... 35
Figura 12 - Tamanho de objetos. .............................................................................. 36
Figura 13 - Dinâmica de execução. ........................................................................... 37
Figura 14 - Transações executadas pelo Job............................................................ 38
Figura 15 - Criação dos usuários. ............................................................................. 38
Figura 16 - Configuração dos usuários. .................................................................... 39
Figura 17 - Melhor desempenho de Throughput na carga de trabalho do Oracle ..... 42
Figura 18 - Melhor desempenho de Throughput na carga de trabalho do PostgreSQL
.................................................................................................................................. 42
LISTA DE GRÁFICOS
Gráfico 1 - Métricas da execução do Job no SGBD Oracle ...................................... 40
Gráfico 2 - Métricas da execução do Job no SGBD PostgreSQL.............................. 41
LISTA DE ABREVIATURAS E SIGLAS
SGBD
Sistema de Gerenciamento de Banco de Dados
SQL
Structured Query Language
DBA
Database Administrator
ODBC
Open Database Connectivity
API
Application Programming Interface
SGA
System Global Area
OLTP
Online Transaction Processing
TPC
Transaction Processing Performance Council
RAM
Random Acess Memory
SUMÁRIO
1
INTRODUÇÃO ................................................................................................... 11
2
SGBD ................................................................................................................. 12
2.1 Conceitos básicos ...................................................................................................................... 12
2.1.1 Banco de Dados ................................................................................................................. 12
2.1.2 Sistema Gerenciador de banco de dados ....................................................................... 12
2.1.3 Principais recursos de um SGBD..................................................................................... 14
2.2 Arquitetura de um SGBD ........................................................................................................... 15
2.2.1 Arquitetura Centralizada ................................................................................................... 15
2.2.2 Arquitetura Cliente/Servidor ............................................................................................. 16
2.3
SGBDs mais conhecidos ........................................................................................................... 19
3
BANCO DE DADOS ORACLE .......................................................................... 22
3.1
A história da Oracle .................................................................................................................... 22
3.2
Arquitetura do Banco de Dados Oracle ................................................................................... 23
3.3 Principais Vantagens/Desvantagens ........................................................................................ 25
3.3.1 Vantagens do Oracle ......................................................................................................... 25
3.3.2 Desvantagens do Oracle ................................................................................................... 27
4
ESTUDO DE CASO: ANÁLISE DE DESEMPENHO DO ORACLE .................. 28
4.1
Descrição do estudo de caso .................................................................................................... 28
4.2 O Benchmarking ......................................................................................................................... 28
4.2.1 Conceito de ambiente OLTP ............................................................................................. 29
4.2.2 Carga de trabalho TPC-C .................................................................................................. 30
4.2.3 Configuração do SGBD e ambiente de execução .......................................................... 32
4.2.4 Configuração do Benchmark Factory .............................................................................. 33
4.3
Resultados obtidos Oracle x PostgreSQL ............................................................................... 39
CONCLUSÃO ........................................................................................................... 43
REFERÊNCIAS ......................................................................................................... 44
11
1 INTRODUÇÃO
Entender o conceito de Sistemas de Gerenciamento de Bando de Dados
(SGBD), conhecer sua importância e analisar quais vantagens e desvantagens de
implantar esse tipo de sistema é fundamental para qualquer empresa que possua a
necessidade de armazenar e buscar grandes volumes de dados, sejam eles
cadastros de produtos, clientes ou demais informações imprescindíveis para o bom
funcionamento da empresa e seu crescimento e organização.
Quando se fala em um novo sistema, esse termo gera diversas dúvidas
quanto a sua real importância e até mesmo se irá trazer benefícios notáveis após
sua implantação e uso. Diante de inúmeros SGBDs disponíveis no mercado, tais
dúvidas dificultam uma escolha e apenas uma análise mais precisa pode esclarecer
as interrogações e auxiliar na escolha mais adequada.
Dentre os SGBDs mais conhecidos podemos citar o Oracle que se
encontra entre os mais usados do mercado atualmente, juntamente com o MySQL,
SQLServer, PostreSQL, e outros.
Esse trabalho tem como objetivo conhecer a arquitetura geral de um
SGBD, conceituando como é seu funcionamento, além de abordar as vantagens e
desvantagens desse tipo de sistema.
Uma vez compreendido tais conceitos, iremos estudar um dos principais
SGBDs disponíveis, o Oracle, descrevendo uma breve historia de seus
desenvolvedores e mostrar como é composto seu sistema de banco de dados.
Como o foco proposto está em torno de seu uso em empresas de
pequeno ou médio porte, serão apontados quais pontos positivos e negativos nesse
ambiente empresarial.
Através de um estudo de caso, será realizada uma analise comparativa
entre dois sistemas de banco de dados muito usados, o Oracle, que se trata de um
sistema pago, e o PostgreSQL, considerado o melhor entre as soluções gratuitas.
Uma comparação muito útil para qualquer empresa que esteja buscando uma
solução para sua empresa, e se encontra na dúvida se opta por um SGBD pago ou
gratuito.
12
2 SGBD
2.1 Conceitos básicos
2.1.1 Banco de Dados
Armazenar informações em bancos de dados nas últimas décadas se tornou
ponto crucial de muitos sistemas. A informação é muitas vezes considerada o
recurso mais valioso da empresa, e possuir esse material e poder acessá-lo sempre
que for necessário chega a ser primordial para a tomada de decisões importantes.
Assim, ter controle de acesso a essas informações garante a segurança dos dados e
confiabilidade naquilo que está sendo armazenado.
Banco de Dados ou Base de Dados se trata de um conjunto de dados
relacionados armazenados, de forma a permitir a manipulação de tais dados, como
alterar, inserir, remover e realizar consultas. SIEBRA (2010).
De acordo com SIEBRA (2010; p.8):
“Os tipos de “coleções de dados” são ilimitados (ex: dados de um produto,
de um estudante, mapas, dados sobre genes humanos, etc), ou seja,
quaisquer aplicações do mundo real que possam ser representadas através
de dados computáveis poderão ser armazenadas em um banco de dados”.
DATE (2000), descreve: “Um Banco de Dados é uma coleção de dados
operacionais armazenados, sendo usados pelos sistemas de aplicação de uma
determinada organização”.
2.1.2 Sistema Gerenciador de banco de dados
Segundo ELMASRI e NAVATHE (2011), um sistema gerenciador de banco de
dados se trata de uma coleção de programas que tornam possível os usuários de
criarem e manterem um banco de dados. Esse software facilita a construção,
definição, manipulação e compartilhamento do banco através de diferentes
aplicações.
A definição de um banco de dados está relacionada à especificação dos tipos,
estruturas e regras de restrições de dados que serão armazenadas, tais informações
são guardadas pelo SGBD, gerando uma espécie de catálogo, denominado de
13
metadados.
O acesso às informações contidas no banco de dados é feita por uma
aplicação, que fica responsável pelo envio das consultas ou solicitações de dados
ao SGBD. A figura a seguir representa um diagrama de ambiente simples de um
SGBD:
Figura 1 - Diagrama Lógico do SGBD
Fonte: ELMASRI e NAVATHE (2011; p.4).
Outras funções primordiais do SGBD são a proteção e manutenção do banco
de dados. ELMASRI e NAVATHE (2011; p.4) descrevem:
“A Proteção inclui proteção do sistema contra defeitos (ou falhas) de
hardware e software e proteção de segurança contra acesso não autorizado
ou malicioso. Um banco de dados grande pode ter um ciclo de vida de
muitos anos, de modo que o SBGD precisa ser capaz de manter o sistema,
permitindo que ele evolua à medida que os requisitos mudam com o tempo.”
Como supracitado, um SGBD possui funções que vão além de apenas
criação do banco e manipulação dos dados armazenados em uma base. O sistema
garante que as informações sejam armazenadas de forma segura e eficaz e fica a
cargo do administrador do banco de dados ou Database Administrator (DBA), criar e
executar as regras e rotinas referentes às politicas de acesso e manutenções
preventivas, como backup periódico da base.
14
2.1.3 Principais recursos de um SGBD
ELMASRI e NAVATHE (2011) levantam os seguintes recursos que
descrevem algumas das funções de um SBGD:
Segurança lógica:
proteger a base de dados contra acessos não
autorizados conforme regras que definem quais os utilizadores do sistema podem
acessar a base ou não. Também separa dentro dos usuários autorizados, as quais
arquivos podem ter acesso e que tipos de operações podem executar (gravar, ler,
modificar, apagar, etc.), assim como oferecer um subsistema que somente o DBA
tem acesso a fim de criar restrições ou novas contas de usuário.
Controle de redundância: prevenir que uma mesma informação seja
gravada em dois locais diferentes, gerando assim inconsistência. Por exemplo,
usuários distintos criando dois cadastros separados de um mesmo produto ou
cliente.
Processamento eficiente de consultas: oferecer estruturas de dados e
técnicas de pesquisas para agilizar a busca de registros, normalmente utilizando
índices para auxiliar no processo. Como o banco de dados é gravado em um disco
no servidor, quando uma informação é retornada, necessariamente precisa ser
copiada na memória principal do servidor. O SGBD conta com um módulo de
buffering de dados, que mantem partes do banco de dados nos buffers de memoria
principal, Em geral, o sistema operacional fica encarregado do buffering entre disco
e memória, entretanto, a maioria dos SGBDs realizam essa tarefa visando melhor
desempenho.
Backup e Recuperação: ser capaz de se recuperar de falhas de software ou
hardware. Por exemplo, se houver falha durante uma transação, garante que o
banco de dados seja restaurado ao seu estado exatamente como era antes da
transação ser realizada. Já o backup é essencial, pois se ocorrer problemas no
disco, o SGBD fica encarregado de executar as rotinas de backup estabelecidas
pela equipe de DBA.
15
Múltiplas interfaces de usuário: o sistema inclui diversas interfaces de
usuário, para atender diferentes níveis de conhecimento técnico. Por exemplo,
linguagens de consultas para usuários casuais, interfaces de linguagens de
programação para programadores de aplicação, e menus de linguagem natural para
usuários isolados.
Integridade: grande parte das aplicações de banco de dados possuem regras
que especificam, por exemplo, um tipo de dado para cada item em determinado
registro, como gravar um dado numérico em um campo referente a um nome de
indivíduo. Deste modo, o SGBD oferece a capacidade para definir e impor tais
restrições de dados e tratamento de inserção de forma automática.
2.2 Arquitetura de um SGBD
2.2.1 Arquitetura Centralizada
ELMASRI e NAVATHE (2011) relatam que antigamente o processamento de
todas as funções dos programas de aplicação, interface com o usuário e as
funcionalidades do SGBD, eram executadas por grandes computadores centrais, os
mainframes, portanto, estabelecia uma arquitetura centralizada. O acesso ao banco
era realizado por terminais que recebiam apenas as imagens sendo que todo o
processo era executado no computador central. A figura 2 ilustra os componentes
que fazer parte da arquitetura centralizada.
16
Figura 2 - Arquitetura Centralizada
Fonte: ELMASRI e NAVATHE (2011; p.30).
2.2.2 Arquitetura Cliente/Servidor
ELMASRI e NAVATHE (2011) descrevem que esse tipo de arquitetura foi
desenvolvida em ambientes que necessitavam lidar com números expressivos de
estações de trabalho, outros servidores como de e-mail, Web, servidores de
arquivos e do próprio banco de dados, além de outros dispositivos conectados na
rede. Cada servidor fica encarregado de funções específicas e o computador do
usuário oferece interfaces para utilização dessas funções bem como passa executar
o processamento local de aplicações locais.
A figura 3 representa um modelo lógico desse tipo de arquitetura, destacando
que é possível ligar n clientes acessando n servidores através da rede.
Figura 3 – Arquitetura Cliente/Servidor modelo lógico
Fonte: ELMASRI e NAVATHE (2011; p.30).
17
A arquitetura Cliente/Servidor possui dois tipos principais: duas camadas e
três camadas.
Arquitetura Cliente/Servidor de Duas Camadas:
Segundo ELMASRI e NAVATHE (2011), os programas de interface de usuário
e aplicações permanecem no lado cliente e funções de consultas e transações de
dados ficam do lado servidor. Dessa forma, tais recursos do servidor podem ser
acessados do cliente usando a linguagem SQL (Structured Query Language),
comumente utilizada como padrão em SGBDs.
Quando é necessário acessar o SGBD (lado servidor), o programa estabelece
uma conexão virtual que oferece uma interface de programação de aplicações,
também conhecida como Application Programming Interface (API), também
permitindo aos programadores chamarem o SGBD através de máquinas cliente que
possuam um driver instalado compatível para estabelecer a conexão com o banco.
A figura 4 publicada em um artigo escrito por MERSCHMANN, demonstra um
exemplo de arquitetura de duas camadas destacando como a conexão entre cliente
e servidor é estabelecida por um software de comunicação de rede.
Figura 4 - Arquitetura Cliente/Servidor Duas Camadas
Fonte: <http://www.decom.ufop.br/luiz/site_media/uploads/arquivos/bcc321/slides02_bdi.pdf >
18
Arquiteturas Cliente/Servidor de Três Camadas:
De acordo com ELMASRI e NAVATHE (2011), esse tipo de arquitetura conta
com uma camada intermediária entre o cliente e o servidor de banco de dados,
chamada Servidor de Aplicação ou Servidor Web.
Essa camada adicional desempenha um papel de armazenar as restrições ou
procedimentos de validação dos dados. Também auxilia na incrementação à
segurança do banco de dados, verificando as credenciais do cliente antes de enviar
uma solicitação ao servidor.
O servidor de aplicação também pode atuar de forma que recupera os
resultados do servidor do banco de dados, e realiza uma formatação das
informações para páginas web dinâmicas, que por sua vez, estão sendo acessadas
pelo cliente.
A figura 5 representa um diagrama de SGBD em três camadas.
Figura 5 - Arquitetura Cliente/Servidor de Três Camadas
Fonte: ELMASRI e NAVATHE (2011; p.32).
19
2.3 SGBDs mais conhecidos
SIEBRA (2010) descreve os principais Sistemas de Gerenciamento de Banco
de Dados, de acordo com os sites oficiais dos sistemas. Segue abaixo uma breve
descrição de cada SGBD.
Oracle
Sistema principalmente comercial, possuindo versões gratuitas para uso
acadêmico. Foi o primeiro Banco de Dados Corporativo (cliente/servidor) que foi
disponibilizado a grande variedade de sistemas (Macintosh, Windows, Linux,
FreeBSD, Unix) além de claro, para computadores de grande porte, os mainframes.
Foi um dos pioneiros a integrar o mercado web. A linguagem padrão usada é
a SQL, entretanto faz uso de uma linguagem própria para desenvolvimento de
aplicações, a PL/SQL4.
A participação da Oracle no mercado de Banco de Dados é influente,
principalmente em grandes empresas trabalhando em conjunto com sistemas de
médio e grande porte, pois se trata de um SGBD robusto e seguro.
Alguns exemplos de clientes Oracle no Brasil: CPFL Energia, Seguros
Unimed, Claro Telefonia, Emissora Rede Globo e Caixa Econômica Federal.
Microsoft SQL Server
Banco de dados comercial da Microsoft, considerado um dos principais
concorrentes do Oracle. Tem como uma das vantagens o fato de se integrar
nativamente com produtos e linguagens da Microsoft. As versões atuais são
independentes e operam exclusivamente sobre Windows. É um software pago,
assim como a maioria dos produtos lançados pela empresa Microsoft.
Alguns exemplos de empresas que usam o Microsoft SQL Server e são
consideradas casos de sucesso no Brasil são a Hipercard, o Banco Itaú e a ANEEL
(Agencia Nacional de Energia Elétrica).
20
MySQL
Um dos bancos de dados mais populares, com mais de 10 milhões de
instalações pelo mundo, possuindo versões para Windows, Solaris, Unix, FreeBSD,
Linux. E seu uso é gratuito para uso não-comercial.
Algumas das empresas mais famosas que fazem uso deste banco podemos
citar: NASA, Banco Bradesco, Dataprev, HP, Nokia e Sony. O MySQL é usado
principalmente para desenvolvimento web como servidor de dados para comércio
eletrônico. Tornou-se um SGBD com recursos de transações a partir da versão 5.
PostgreSQL
SGBD desenvolvido como projeto de código aberto pela PostgreSQL Global
Development Group. Ele é considerado o sistema gerenciador de bancos de dados
de código aberto mais avançado disponível, sendo que sua distribuição é gratuita e
possui uma boa aceitação no mercado.
Originalmente, foi criado para plataforma Linux, entretanto conta com versões
para Windows atualmente. Seu o foco é, principalmente, para comércio eletrônico,
trabalhando juntamente com a linguagem PHP.
DB2
Sistema Gerenciador de Banco de Dados produzido pela IBM. Existem
diferentes versões do DB2 que rodam desde num simples PDA (computador de
mão) e nos potentes mainframes, e funcionam em servidores baseados em sistemas
Unix, Windows ou Linux.
DB2 é vendido em diversos tipos de edições ou licenças. A IBM evita que
seus consumidores paguem por recursos que não iriam usar, oferecendo opções de
versões com menos recursos, de acordo com aquilo que atende a demanda do
cliente.
21
Interbase
Sistema gerenciador de banco de dados relacionais da Borland. Foi incluído,
pela Borland, nas suas ferramentas de desenvolvimento (Delphi, C++ Builder e
JBuider).
O Interbase possibilita instalação em sistemas operacionais Microsoft
Windows, Linux, Mac OS X e Sun Solaris. Não é um sistema pesado e se apresenta
desempenho relativamente rápido, suportando bancos de dados de tamanho
considerável, acima que 2 Gigabytes.
Em 2000 a Borland liberou o código da versão 6.0, entretanto posteriormente
voltaram a ter licença proprietária do sistema. Desta versão 6.0 liberada, foi criado o
Banco de Dados open source Firebird.
Firebird
Foi desenvolvido seguindo a proposta da Borland de liberar o código do
InterBase 6.0. O Firebird, também conhecido como FirebirdSQL, tem distribuições
para Linux, Windows, Mac OS e para uma série de plataformas Unix.
A Fundação FirebirdSQL é responsável pelo desenvolvimento e manutenção
do Firebird. O produto é bastante seguro e confiável, podendo suportar sistemas
com centenas de usuários simultâneos, além de bases de dados com dezenas de
gigabytes.
O SGBD conta com suporte gratuito online através de sites colaboradores,
uma vez que é seu código é aberto, o Firebird é amplamente utilizado em todo o
mundo, com destaque para usuários no Brasil, Rússia e pela Europa.
22
3 BANCO DE DADOS ORACLE
3.1 A história da Oracle
De acordo com informações divulgadas em um documento no site oficial da
empresa, a companhia foi fundada em 1977 pelos americanos Larry Ellison, Robert
Miner e Ed Oates.
Anteriormente, Larry, Robert e Ed ficaram responsáveis por desenvolver um
sistema para a CIA (agência de inteligência americana), que usaria como base a
linguagem recentemente criada SQL nos computadores IBM. O projeto era
denominado Oracle, ou “oráculo” em inglês, uma vez que seria um sistema que teria
resposta pra tudo segundo a agência.
O projeto acabou fracassando, contudo, os desenvolvedores seguiram o
conceito adiante fundando em 1977 a Software Development Laboratories.
Tratava-se de uma empresa especializada em sistema de gestão de banco de
dados relacional como uma solução alternativa ao IBM System R. Em 1979 a
companhia mudou o nome para Relational Software, Inc Anos depois, em 1982,
passou a usar o nome Oracle System Corporation após uma conferência que reuniu
os clientes da empresa, sendo um marco para a Oracle ficar conhecida
mundialmente. No ano seguinte, por fim adotou o nome apenas de Oracle
Corporation.
Atualmente, no site oficial da Oracle é possível encontrar soluções que vão
muito além de banco de dados, abrangendo produtos como, por exemplo, softwares
de gerenciamento empresarial, comunicação corporativa, servidores, os sistemas
operacionais Oracle Solaris e Oracle Linux, além de serviços como suporte 24 horas
e também computação na nuvem.
23
3.2 Arquitetura do Banco de Dados Oracle
De acordo com informações descritas no manual do banco de dados Oracle
10g, o sistema de banco de dados Oracle é composto de vários arquivos que são
organizados de acordo como mostra a figura 6 a seguir:
Figura 6 - Arquitetura do Banco de Dados
Fonte: ORACLE 10G (2004; p.3-3)
Arquivos de controle: informações sobre o banco de dados (metadados),
fundamentais para acessar os dados armazenados.
Arquivos de dados: contém os dados do banco de dados. Uma base de
dados é dividida em unidades lógicas de armazenamento, chamadas tablespaces,
usadas para agrupamento de arquivos de dados.
Cada banco de dados é dividido logicamente em uma ou mais tablespaces,
sendo que um ou mais arquivos de dados são criados para cada tablespace
específica.
A figura 7 a seguir, demonstra um exemplo da tablespace USERS contendo
dois arquivos de dados.
24
Figura 7 - Tablespaces e Arquivos de Dados
Fonte: ORACLE 10G (2004; p.3-7)
Arquivos de parâmetros: Utilizado para definir o modo de configuração da
instância do Oracle durante a inicialização.
Uma instância Oracle é composta de um grande bloco de memória alocado
em uma área chamada System Global Area (SGA), juntamente com alguns
processos em segundo plano que interagem entre SGA e os arquivos de banco de
dados no disco. Somente após iniciar uma instância e o banco de dados for aberto,
será possível ter acesso às informações.
Arquivo de senha: Ficam armazenadas as senhas de acesso para que seja
possível conectar remotamente no banco e executar tarefas de nível administrativo.
Arquivos de log arquivados: Fica armazenado um histórico contínuo do
“redo” gerado pela instância. Esse arquivo permite a recuperação do banco de
dados usando em conjunto com o backup da base.
Arquivos de redo log on-line: São arquivos que registram as alterações no
banco, como transações e outras ações no servidor. Sendo assim, sua tarefa
consiste na proteção contra perda de integridade devido a falhas do sistema, como
falta de energia, erros de disco, etc.
Através do conteúdo desses arquivos o banco pode ser recuperado.
25
3.3 Principais Vantagens/Desvantagens
Para se analisar quais pontos fortes e pontos fracos do SGBD Oracle, iremos
considerar dois principais quesitos: a viabilidade de sua aquisição em uma empresa,
levando em consideração seu porte (pequeno/médio), e mais adiante, seu
desempenho diante de outro sistema do segmento.
3.3.1 Vantagens do Oracle
CORRÊA e MARCONDES (2003) expõem uma análise desses pontos em um
artigo científico, realizando uma pesquisa sobre quais aspectos importantes devem
ser considerados referentes o uso do Oracle em empresas de pequeno e médio
porte.
Primeiramente, os autores destacam as principais vantagens do Oracle:
Suporte aos usuários: por se tratar de uma ferramenta robusta e complexa,
é necessário apoio técnico para tratar de dúvidas e até mesmo questões de
desempenho e incidentes do sistema. A Oracle oferece um serviço de assistência 24
horas por dia e sete dias por semana sobre seus produtos, possuindo cobertura
global e mais de 50 mil engenheiros e especialistas em suporte aos clientes.
Mais opções para o cliente: A Oracle conta com várias opções de edições
de seu banco de dados, a fim de atender as necessidades de cada empreendimento
ou finalidade.
A Express Edition é uma versão gratuita, porém limitada, voltada para estudos
acadêmicos ou como forma de avaliação da qualidade do sistema.
O Standard Edition One é otimizado para implementação em pequenas
empresas, departamentos de linha de negócios e ambientes distribuídos de
agências. De acordo com o site oficial de produtos Oracle, o valor inicial da licença
gira em torno de 180 dólares por usuário (no máximo cinco usuários).
26
A versão Standard Edition, se trata de uma solução de gerenciamento de
dados mais completa ideal para empresas de médio porte. Incluindo um banco de
dados pronto para conexão com a nuvem, além de oferecer o serviço Oracle Real
Application Clusters, possibilitando ser escalado facilmente à medida que a empresa
cresce. A licença atual está em torno de 350 dólares por usuário (máximo cinco),
segundo a página de produtos Oracle.
Já a Enterprise Edition se mostra como carro chefe das distribuições de
banco de dados Oracle. Oferece uma administração robusta, confiável e segura do
banco de dados para qualquer tipo de aplicação: como datawarehouse e aplicações
de alta demanda via web. Conta com todas as ferramentas e funcionalidades para
atender os requisitos de disponibilidade e escalabilidade das aplicações críticas para
as empresas de hoje.
Segurança das informações: Segundo CORRÊA e MARCONDES (2003), o
Oracle oferece segurança de forma unificada, reduzindo riscos e demais custos
relacionados à manutenção e gerenciamento de sistemas heterogêneos.
Por possuir pelo menos um arquivo de controle em sua composição, garante
que antes mesmo que o banco de dados seja instanciado, todos os programas e
serviços essenciais estejam sendo executados de acordo com os parâmetros
necessários, evitando falhas em tempo de execução.
Performance e escalabilidade: De acordo com CORRÊA e MARCONDES
(2003), o SGBD Oracle é detentor de recordes mundiais de processamento de
transações em benchmarks TPC, até mesmo com performance recorde em servidor
único.
O serviço Oracle Real Application Clusters incluso na versão Standard
Edition, apresenta um sistema em nuvem de banco de dados, bem como uma
infraestrutura compartilhada, o que garante alta disponibilidade, escalabilidade e
agilidade para qualquer aplicação.
Solidez da empresa Oracle: Como descrito anteriormente, a empresa Oracle
está presente no mercado a mais de 30 anos, foi pioneira em desenvolver um SGBD
para execução em computadores mainframes. Conta com serviços confiáveis de
27
proteção a informação, recuperação rápida por falhas e suporte técnico
especializado, tudo para garantir que seus produtos estejam sempre disponíveis.
3.3.2 Desvantagens do Oracle
Em seu artigo, CORRÊA e MARCONDES (2003) também descrevem as
desvantagens de se obter um sistema robusto e complexo como o Banco de Dados
Oracle,
analisando
três
fatores
primordiais
que
implicam
diretamente
na
administração da empresa:
Custo: A participação de custos de TI dentro das empresas é uma crescente.
Cada vez mais é necessário investir em tecnologia e na informação. O valor para
aquisição de uma licença Oracle para uso é alto se compararmos com outras opções
disponíveis no mercado, até mesmo incluir soluções gratuitas, que apresentam
recursos semelhantes, como é o caso do SGBD open source PostgreSQL. Nesse
momento o administrador deverá avaliar os custos a serem gastos para a
implantação da ferramenta em questão, comparar os benefícios que ela trará,
considerando as aspirações futuras de crescimento do empreendimento.
Disponibilidade de Recursos Humanos: Uma vez que o custo de aquisição
do Oracle é elevado, consequentemente cursos de especialização e treinamento
seguem o mesmo patamar. Sua robustez exige mão de obra capacitada, em outras
palavras, essa exigência possibilita que profissionais com conhecimento em Oracle
sejam mais valiosos que os demais, aumentando assim, os custos à empresa.
Estrutura de hardware que suporte a ferramenta: Ferramentas complexas
necessitam de infraestruturas robustas para sustentar os diversos serviços
agregados. O Banco de Dados Oracle, portanto, necessita de equipamento com boa
capacidade de processamento, e esse quesito deve ser considerado pelo
administrador de acordo com seus aspectos econômicos, uma vez que terá que
adquirir novos dispositivos computacionais.
28
4 ESTUDO DE CASO: ANÁLISE DE DESEMPENHO DO ORACLE
4.1 Descrição do estudo de caso
Existem algumas peculiaridades e características que diferem os principais
SGBDs existentes no mercado, principalmente no que diz respeito ao tamanho
(espaço de utilização) dos dados que serão administrados. Por exemplo, banco de
dados MySql é característico de aplicações web, pela facilidade em adquirir e
instalar a ferramenta, além de sua boa performance para tamanhos reduzidos de
base. Outro exemplo é o PostgreSQL, muito utilizado com aplicações nas empresas
de pequeno e médio porte, que normalmente compreende o tamanho da base de
dados entre 5 e 15 GB, segundo informações
fornecidas pela NWSoftware,
empresa especializada em sistemas de gestão empresarial, localizada em
Americana. Sua instalação também é simples e gratuita, o sistema é performático e
muito utilizado também por aplicações web.
O banco de dados Oracle é muito utilizado em bases de dados de empresas
de grande porte, pois nele, existem ferramentas que possibilitam funcionalidades
para suportar um número alto de dados para gerenciamento. Porém, apesar de
famoso por possibilitar o gerenciamento de bases enormes, ele também é uma
opção para utilização em base de dados menores, nas empresas de pequeno e
médio porte, sendo assim, foi realizado um estudo de caso através de benchmarking
baseando-se na comparação de desempenho do Oracle com outro SGBD famoso, já
citado, PostgreSQL, realizando execuções para simulação de cargas de trabalho
nas empresas de pequeno e médio porte, com tamanho aproximado de 8GB.
4.2 O Benchmarking
Para entender como foi estruturado e construído o Benchmarking de
comparação entre dois grandes SGBD do mercado, primeiramente vamos entender
o conceito dessa palavra. Segundo SOUZA (2003), o processo de comparação do
desempenho entre dois ou mais sistemas é chamado de benchmarking, e as cargas
usadas são chamadas de benchmark.
De acordo com essa definição, podemos perceber no que consiste um
29
Benchmarking em TI, e seu objetivo, que se resume em comparar o desempenho
entre sistemas (também entre hardwares), neste caso, SGBD Oracle e PostgreSQL.
Para a prática das execuções de teste e gerenciamento de cargas, foi
utilizado o programa Benchmark Factory em sua versão trial, desenvolvido pela
empresa Dell Software.
O Benchmark Factory permite a execução de diversos tipos de cargas, para
efetuar transações reais existentes nos sistemas de muitas empresas. Para a
demonstração e comparação de desempenho do Oracle e PostgreSQL, será
utilizado o tipo de carga TPC-C (Transaction Processing Performance Council
Benchmark C), que simula as atividades existentes em um ambiente OLTP (Online
Transaction Processing) complexo.
É necessário entender o conceito de ambiente OLTP para direcionar os
estudos ao Benchmarking propriamente dito.
4.2.1 Conceito de ambiente OLTP
Como seu próprio nome já diz, “Online Transaction Processing” ou
“Processamento de transações on-line” é exatamente a definição de um sistema
baseado em transações de usuários.
De acordo com site da SYMANTEC CORPORATION:
“Os sistemas OLTP são projetados para responder imediatamente às
solicitações do usuário, e cada solicitação é considerada uma única
transação. As solicitações podem envolver adicionar, recuperar, atualizar ou
remover dados”.
Para associar essa definição com o mundo real, pode-se exemplificar
ambientes OLTP como: sistemas de reserva de passagem aérea, sistemas
bancários, sistemas de acompanhamento de mercado de ações, etc.
Os sistemas OLTP, comumente suportam uma grande quantidade de
usuários logados e trabalhando, tem disponibilidade 24 horas por dia, 7 dias na
semana e suas transações são basicamente compostas por leituras e escritas de
dados.
30
4.2.2 Carga de trabalho TPC-C
Criado pela organização independente e sem fins lucrativos TPC (Transaction
Processing Performance Council), que tem como parceira empresas como: IBM,
Microsoft, Oracle, dentre outros, a carga chamada TPC-C consiste na mistura de
transações que simulam o trabalho de uma empresa atacadista, realizando
transações para controlar a produção, venda e distribuição dos seus produtos.
O sistema é utilizado para:

Registrar solicitações de compras de clientes;

Consultar a situação de pedidos feitos previamente;

Registrar pagamentos dos clientes;

Processar entregas de pedidos;

Consultar o nível de estoque de produtos;
Isso significa que cada uma dessas ações, representam as transações
executadas pela carga quando executadas através de programas de Benchmarking.
O banco de dados do sistema é constituído de nove tabelas relacionadas
entre si, conforme mostra a figura 8.
Figura 8 - Diagrama do banco de dados TPC-C
Fonte: Própria

Os números próximos às linhas de relacionamento representam a
cardinalidade dos relacionamentos;

A tabela de armazéns (Warehouses) e distritos (Districts) são as que
31
indicam geograficamente que as vendas da companhia estão divididas de
acordo com os valores contidos nessas tabelas. A proporção existente
entre essas duas tabelas são de 1 armazém para cada 10 distritos, desta
forma, o restante das tabelas estão proporcionadas de acordo com essas
duas entidades.
Os itens abaixo descrevem as cinco transações existentes na carga de
trabalho do TPC-C:

New Order – Executa a operação de compra de um cliente. Essa
atividade consiste em: Inserção de registros nas tabelas Order, New
Order e Order_Line e consequentemente atualiza o nível de estoque
(tabela Stock) para cada venda, além de fazer a consulta de informações
nas tabelas Warehouse, District, Customer e Item.

Payment – Esta transação realiza o registro de pagamento de uma
compra. Para que isso ocorra, ela executa a atualização de informações
de saldo do cliente (tabela Customer), do distrito (tabela District) e do
armazém (tabela Warehouse). E como consequência de registrar o
pagamento, insere um novo registro na tabela History.

Delivery – Consiste em registrar uma entrega feita para um determinado
pedido. Para cada distrito de um armazém ela realiza a busca e exclusão
do registro mais antigo da tabela New Order que esteja associado ao
distrito em questão e para manter a consistência, faz a atualização nas
tabelas Order, Order_Line e Customer. Não é uma transação executada
muitas vezes durante a carga.

Order Status – Consiste em fazer a consulta da situação da última
compra de um cliente. Sendo assim, seleciona informações do cliente na
tabela Customer e a partir daí, busca informações de compra nas tabelas
Order e Order_Line.
32

Stock Level – Determina a medida do estoque dentre os itens vendidos
recentemente, ou seja, consulta as últimas vinte compras de um distrito
(tabela District) e faz a contagem
dos itens que se encontram abaixo
do limite estabelecido (tabelas Stock e Order_Line). Essa transação tem
como principal característica ser somente leitura, porém, impõe uma
carga pesada ao sistema.
4.2.3 Configuração do SGBD e ambiente de execução
Para que seja o mais consistente possível os testes realizados entre os dois
bancos de dados, foram criadas e configuradas igualmente duas máquinas virtuais,
destinadas cada uma a um SGBD. Essas máquinas foram criadas através do
programa Oracle VM VirtualBox, fabricado pela Oracle.
Nas duas máquinas, foram instalados a versão Enterprise do Windows 7 (32bits), e com as características exibidas de acordo com a figura 9:
Figura 9 - Configurações das máquinas virtuais
Fonte: Própria
Podemos destacar na figura, que a memória principal ou memória RAM
(Random Access Memory) está configurada em 2048 Mb ou 2 GB, habilitado para
rodar com 2 processadores (considerando a instalação das maquinas em um
computador com processador Intel Core i7) e espaço em disco de 25 Gb.
Como já citado anteriormente, o sistema instalado para a execução da carga,
foi o Benchmark Factory em sua versão trial (gratuita).
Cada máquina além do software Benchmark Factory, recebeu a instalação do
seu SGBD destinado ao teste, sendo:
33

PostgreSQL – Instalado a versão 9.3.10 32 bits do sistema, e
configuração manteve-se a standard da instalação, ou seja, nenhuma
alteração foi realizada para algum tipo de melhoria no desempenho. É
valido considerar também, que o PostgreSQL é open source, isso significa
que tem código aberto e qualquer um pode adquirir a ferramenta
gratuitamente.
Para se comunicar com o programa Benchmark Factory, foi necessária a
instalação do driver ODBC do banco de dados PostgreSQL.

Oracle – Instalado a versão 11g Express (gratuita para estudante 32 bits)
sem nenhum tipo de alteração do padrão habilitado pela instalação inicial
que possa influenciar no desempenho. O único ponto a ser destacado, é
que foi estendido a tablespace SYSTEM.DBF (utilizada para carga), pois
com o seu tamanho inicial, não era possível executar a carga TPC-C.
Para a comunicação com o programa Benckmark Factory, foi instalado o
Oracle client 11.2.0.1.0 for windows em sua versão 32 bits também.
4.2.4 Configuração do Benchmark Factory
O programa Benchmark Factory, possibilita algumas funcionalidades, por
exemplo, aumentar o volume de carga standard, aumentar ou diminuir a quantidade
de usuários simultâneos, e até mesmo o agendamento da execução de um Job.
Com isso, foi realizada a parametrização das execuções das cargas de acordo com
os itens exibidos abaixo.
Configuração de conexão entre o programa e a base de dados dos dois
SGBD, figura 10:
34
Figura 10 - Conexão do Benchmark Factory com SGBD
Fonte: Própria
 Resumo das configurações e preferências dos Jobs, exibindo as
informações
relevantes
para
a
sua
execução.
Pode-se
perceber
principalmente a escala configurada (78) e a quantidade de usuários que
utilizará o sistema durante a carga (10). A Figura 11 destaca a os detalhes
dos dois Jobs.
35
Figura 11 - Resumo dos parâmetros e configurações do Job TPC-C
Fonte: Própria

Na figura 12 é exibido o detalhamento das informações de
tamanho dos objetos. É ilustrado o tamanho das tabelas, respectivos
índices e tamanho total da base de dados que será de 7,96 GB devido a
escala aumentada 78 vezes ao seu tamanho tradicional.
Como as duas execuções são iguais, na imagem, pode-se perceber que é
36
exibida somente uma configuração, neste caso, considerá-las para as duas
execuções.
Figura 12 - Tamanho de objetos.
Fonte: Própria

Na figura 13, é ilustradoo roteiro do Job. A opção selecionada
logo abaixo, indica ao Job que ele deve recriar os objetos
(tabelas e índices), recarregá-los (alimentando-os com dados)
para qualquer execução que iniciar, e depois deste processo,
iniciar as simulações de trabalho.
37
Figura 13 - Dinâmica de execução.
Fonte: Própria
 Ao final das configurações, serão exibidas as transações do Job TPC-C
que serão executadas são elas: New Order, Payment, Order-Status,
Delivery e Stock Level (Figura 14), a quantidade de usuários habilitados
para simular cargas no sistema, que neste caso serão 10 (Figura 15) e uma
configuração importante, indicando que deve-se iniciar os usuários, o mais
rápido possível após finalizar cada execução (Figura 16).
A figura 14 mostra as transações a serem executadas pelo Job:
38
Figura 14 - Transações executadas pelo Job.
Fonte: Própria
Figura 15 - Criação dos usuários.
Fonte: Própria
39
Figura 16 - Configuração dos usuários.
Fonte: Própria
4.3 Resultados obtidos Oracle x PostgreSQL
Após os testes de cargas nos SGBD Oracle e PostgreSQL, as execuções
tiveram tempos parecidos, e os resultados podem ser avaliados de acordo com a
análise do tempo de resposta e quantidade de transações em um espaço de tempo
em cada caso. Para entender melhor estes parâmetros, eles serão definidos abaixo:
 Tempo de resposta – É o tempo que leva a partir de quando o SQL é
enviado ao servidor, até o primeiro retorno do mesmo. Ou seja, se, por
exemplo, um comando SELECT foi enviado ao servidor, o tempo de
resposta está sendo calculado a partir daí até o momento que o banco de
dados retorna a primeira linha.
 Transações por segundo (TPS) – Consiste na quantidade de transações
processadas por segundo. É necessário destacar que uma transação, pode
não ser somente um comando enviado ao banco de dados, mas um grupo
de comandos enviados para alcançar o objetivo. Por exemplo, no caso da
carga TPC-C transação New Order, é criado uma nova ordem através da
inserção de um novo registro para a tabela New_Order e de alguns
registros (dependendo da quantidade de itens da nova ordem de compra)
na tabela Order_line.
Definidos os parâmetros de avaliação utilizados para análise, pode-se
analisar os gráficos obtidos após as duas execuções. O gráfico 1 mostra a execução
da carga no Oracle:
40
Gráfico 1 - Métricas da execução do Job no SGBD Oracle
Fonte: Própria
E logo abaixo no gráfico 2, a mesma carga, porém agora executada no
PostgreSQL:
41
Gráfico 2 - Métricas da execução do Job no SGBD PostgreSQL
Fonte: Própria
A média de tempo de resposta, mais à direita, está sendo medido por
milissegundos e a média das transações, medidas por segundo. A tabela na parte
inferior das duas imagens exibe o desempenho de cada usuário durante a avaliação
das cargas.
Visualizando as duas imagens, conclui-se que o primeiro usuário (User Load
1), nas duas execuções, tiveram a mesma média de transações por segundo, 0,07,
ou seja, na maioria das vezes, aproximadamente 6.9% da transação foi executada
em 1 segundo. Porém, a diferença está no tempo de resposta, pois a do Oracle foi
muito maior, 600 milissegundos, contra a do PostgreSQL, que foi de 260, isso
significa que para o usuário 1, o desempenho do PostgreSQL foi melhor que a do
Oracle no que diz respeito ao tempo de resposta. Podemos observar com essa
avaliação, que um resultado ótimo para uma carga, seria um valor alto para
transações por segundo, e um valor baixo para tempo de resposta.
No decorrer da execução, para os outros 9 usuários a diferença nas
42
transações por segundo se mantém baixa, e o Oracle desempenha muito bem e
melhora gradativamente no tempo de resposta, sendo em sua maioria, valores
parecidos e em alguns casos até melhores do que o PostgreSQL.
Ao final do teste, o Benchmark Factory exibe um resultado que destaca qual
usuário teve o melhor throughput durante a carga. Essa palavra significa, segundo
IKEMATU:
“Throughput define a capacidade do computador de processar os dados.
Ele é uma composição de velocidade de I/O, velocidade da CPU,
capacidades de paralelismo da máquina e a eficiência do sistema
operacional e o software básico envolvido.”.
Ou seja, em qual momento da carga, foi possível trafegar mais dados de
transferência tendo mais agilidade dos recursos de hardware.
Obteve-se o seguinte resultado para a execução da carga no Oracle (figura
17):
Figura 17 - Melhor desempenho de Throughput na carga de trabalho do Oracle
Fonte: Própria
E para o PostgreSQL, conforme a figura 18:
Figura 18 - Melhor desempenho de Throughput na carga de trabalho do PostgreSQL
Fonte: Própria
Nos dois casos, o melhor desempenho de throughput foi no usuário 10. Isso
pode ser explicado pela ótima capacidade que os dois sistemas tem de “bufferizar”
resultados de pesquisas anteriores em sua memória, pois, como eles são os últimos
usuários e suas seleções são iguais os dos anteriores, a tendência é que o sistema
grave os resultados na memória, para resgatar esses dados mais rapidamente de lá
ao invés de ir até o disco buscá-las.
43
CONCLUSÃO
Neste trabalho, foi abordado o assunto relacionado à importância do SGBD
de modo geral nas empresas ou organizações, as arquiteturas existentes dentre os
SGBDs mais conhecidos, tendo seu foco principal no SGBD Oracle, seu
funcionamento e oportunidade de utilização por empresas de pequeno e médio
porte. Com isso, foi possível concluir que cada SGBD tem suas próprias
particularidades, por este motivo, existem vantagens e desvantagens na utilização
de todos eles. Além disso, com o estudo aprofundado no Oracle, pode-se perceber
que de fato é um SGBD robusto, com grandes funcionalidades e sua utilização não
deve ser restrita a bases de dados maiores (como é mais conhecido), mas pode ser
aproveitado também com bases menores.
Os objetivos propostos no trabalho foram cumpridos, visto que na
comparação
de
desempenho
do
Oracle
com
o
PostgreSQL
através
de
Benchmarking, os resultados foram satisfatórios em provar que o Oracle atende a
boas expectativas quando utilizado em base de dados, entre 5 e 15 GB. A decisão
pela comparação com o PostgreSQL se deve a comumente utilização deste por
empresas de pequeno e médio porte, ao contrário do Oracle.
O estudo do desempenho foi baseado nos tempos de resposta das
transações do Benchmark TPC-C e quantidade de transações por segundo desta
carga. Isso também possibilitou o aprofundamento no estudo e avaliação de
ambientes de execução, e configuração da carga para chegar ao resultado
esperado.
O trabalho foi muito importante para o nosso conhecimento em SGBDs,
principalmente no que diz respeito a arquitetura desses sistemas, pois foi feito um
estudo mais aprofundado neste aspecto. Em relação ao Oracle, os conhecimentos
adquiridos serão de grande proveito, pois é um banco de dados muito conhecido e
importante, utilizado em muitas empresas conceituadas.
44
REFERÊNCIAS
CORRÊA,
Juliano
Soares;
MARCONDES
Marcos
Roberto.
Vantagens
e
Desvantagens da Utilização do Banco de Dados Oracle 2003, Salvador - Artigo
Científico (Escola de formação complementar do exército).
DATE, C. J. Introdução a sistemas de bancos de dados. Rio de Janeiro: Campus,
2000.
ELMASRI, R. & NAVATHE, S. B. Sistemas de Banco de Dados. 6ª ed. São Paulo:
Pearson Education do Brasil, 2011.
HEUSER, Carlos Alberto. Projeto de Bancos de Dados. 4ª ed. Porto Alegre: Sagra
Luzzatto, 2001.
IKEMATU, Ricardo Shoiti. Realizando Tuning na Base de Aplicações. Disponível
em:
<http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=1592>.
Acesso em: 30 out 2015.
MERSCHMANN, Luiz Henrique. Conceitos e Arquitetura de Sistemas de Banco
de Dados. Disponível em: <
http://www.decom.ufop.br/luiz/site_media/uploads/arquivos/bcc321/slides02_bdi.pdf
> Acesso em: 26 set 2015.
NWSOFTARE. Disponível em: <http://www.nwsoftware.com.br/>. Acesso em: 1 nov
2015.
ORACLE. Oracle's History: Innovation, Leadership, Results. Disponível em:
<http://www.oracle.com/us/corporate/history/index.html>. Acesso 26 out 2015.
ORACLE 10G.
Manual Banco de Dados Oracle 10g: Workshop de
Administração. Oracle University, 2004.
45
SIEBRA, Sandra de Albuquerque. Banco de Dados. Recife: Universidade Federal
Rural de Pernambuco, 2010.
SOUZA, Michel. Benchmark. Disponível em:
<http://imasters.com.br/artigo/1590/gerencia-de-ti/benchmark/ >. Acesso em: 23 out
2015.
SYMANTEC.
OLTP
(Online
Transaction
Processing).
Disponível
em:
<https://www.symantec.com/pt/br/security_response/glossary/define.jsp?letter=o&wo
rd=oltp-online-transaction-processing>. Acesso em 30 out 2015.