UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO DESENVOLVIMENTO DE UMA FERRMANENTA PARA ANÁLISE DE AJUSTE DE DESEMPENHO DO BANCO DE DADOS ORACLE Área de Banco de Dados por Jonas Rosa Adriana Gomes Alves, M.Eng. Orientadora Itajaí (SC), junho de 2005

2 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO DESENVOLVIMENTO DE UMA FERRMANENTA PARA ANÁLISE DE AJUSTE DE DESEMPENHO DO BANCO DE DADOS ORACLE Área de Banco de Dados por Jonas Rosa Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Adriana Gomes Alves, M.Eng. Itajaí (SC), junho de 2005 i

3 SUMÁRIO LISTA DE ABREVIATURAS...v LISTA DE FIGURAS...vi LISTA DE TABELAS...vii RESUMO...viii ABSTRACT...ix 1. INTRODUÇÃO OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA BANCO DE DADOS ORACLE A Historia do Banco de Dados Oracle SISTEMA DE GERENCIADOR DE BANCO DE DADOS ORACLE Estrutura Física Estrutura da Memória Estrutura Lógica Seqüência de UNDO CONCEITO DE AJUSTE DE DESEMPENHO Localização de Gargalos Parâmetros Ajustáveis Ajuste de Esquemas Ajuste de Índices Ajuste de Transações Simulação de Desempenho AJUSTE DE DESEMPENHO Administração Básica de Banco de Dados Performance Tuning FERRAMENTAS DE TUNING PARA ORACLE Oracle Enterprise Manager (OEM) Oracle SQL Scratchpad TOAD ESTUDO SOBRE SISTEMAS E PROJETOS SIMILARES GURU - Uma ferramenta Para Administrar Banco de Dados Através da Web Análise de Desempenho do Banco de Dados Oracle 9i... 41

4 2.7. CONCLUSÕES DA FUNDAMENTAÇÃO TEÓRICA PROJETO REQUISITOS DIAGRAMA DE CONTEXTO DIAGRAMAS DE FLUXO DE DADOS Solicita Acesso ao Banco de Dados Solicita Instalação da Ferramenta Solicita Visualização da Estrutura Lógica da Memória Solicita Visualização do Shared Pool Solicita Análise do Plano de Execução Solicita Reconstrução de Índices do Banco de Dados Solicita Ajuste de Esquemas Solicita Consulta de Acessos ao Banco de Dados Solicita Consulta de Análise de Índices MODELAGEM ENTIDADE RELACIONAMENTO FERRAMENTAS UTILIZADAS VALIDAÇÃO ESTRUTURA LÓGICA DA MEMÓRIA Shared Pool Database Buffer Cache Redo Log Buffer Java Pool Large Pool VISUALIZAÇÃO DA SHARED POOL Shared Pool Dictionary Cache Library Cache RECONSTRUÇÃO DE ÍNDICES PLANO DE EXECUÇÃO AJUSTE DE ESQUEMAS Visualização de Tabelas Criação de Tabelas Visualização de Índices Criação de Índices COMPARATIVO ENTRE PROJETOS ESTUDADOS E PROJETO IMPLEMENTADO CONCLUSÕES...80 REFERÊNCIAS BIBLIOGRÁFICAS...83 APÊNDICE A MODELAGEM DE DADOS...85 APÊNDICE B ESPECIFICAÇÃO DAS FUNÇÕES...87 iii

5 APÊNDICE C INSTALAÇÃO DA FERRAMENTA ANEXO I RESUMO PUBLICADO NO CRICTE ANEXO II ARTIGO iv

6 LISTA DE ABREVIATURAS CBO CKPT CPU DBA DBWR DDL DML DSS I/O LGWR LRU OLTP PC PGA PMON RAM RBO SGA SGBD SMON TCC UNIVALI Cost Based Optimizer Recover Central Processing Unit Database Administrator Database Write Data Definition Language Data Manipulation Language Decision Support System Input/Output Log Write Least Recently Used On-line Transaction Processing Personal Computer Process Global Area Process Monitor Random Access Memory Rule Based Optimizer System Global Area Sistema de Gerenciamento de Banco de Dados System Monitor Trabalho de Conclusão de Curso Universidade do Vale do Itajaí

7 LISTA DE FIGURAS Figura 1: Estrutura Física Fonte: Adaptado de Fanderuff (2003)...11 Figura 2. Estrutura de memória utilizada pelo banco de dados Oracle Fonte: Adaptado de Zegger (2001)...12 Figura 3. Inicialização de uma instância no Oracle Fonte: Adaptado de Ramalho (1999)...14 Figura 4. Estrutura Lógica Fonte: Adaptado de Fanderuff (2003)...15 Figura 5. Estrutura de um bloco de dados Fonte: Adaptado de Ramalho (1999)...16 Figura 6. Análise de Explain Plan...31 Figura 7. Ferramenta Oracle Enterprise Manager...32 Figura 8. Funcionalidades da Pasta Instância...33 Figura 9. Funcionalidades da Pasta de Armazenamento...34 Figura 10. Ferramenta SQL Scratchpad...35 Figura 11. Ferramenta TOAD...36 Figura 12. Diagrama de Contexto...45 Figura 13. Solicita Acesso ao Banco de Dados...46 Figura 14. Tela do Controle de Acesso ao Banco de Dados...48 Figura 15. Solicita Instalação da Ferramenta...49 Figura 16. Tela de Configuração da Ferramenta...50 Figura 17. Solicita Visualização da Estrutura Lógica da Memória...51 Figura 18. Tela de Visualização da Estrutura Lógica da Memória...52 Figura 19. Solicita Visualização da Shared Pool...53 Figura 20. Tela de Visualização da Shared Pool...54 Figura 21. Solicita Análise do Plano de Execução...55 Figura 22. Tela de Análise do Plano de Execução...56 Figura 23. Solicita Reconstrução de Índices do Banco de Dados...57 Figura 24. Tela de Reconstrução de Índices...58 Figura 25. Solicita Ajuste de Esquemas...59 Figura 26. Tela de Ajustes de Esquemas...60 Figura 27. Visualização de Tabelas...60 Figura 28. Tela de Visualização de Tabelas...61 Figura 29. Criação de Tabelas...62 Figura 30. Tela de Criação de Tabelas...63 Figura 31. Visualização de Índices Figura 32. Tela de Visualização de Tabelas...65 Figura 33. Criação de Índices...66 Figura 34. Tela de Criação de Tabelas...67 Figura 35. Consulta de Acessos ao Banco de Dados Figura 36. Tela de Consulta de Acessos...69 Figura 37. Consulta de Análise de Índices...70 Figura 38. Tela de Consulta de Índices Reconstruídos...71 Figura 39. Diagrama de Entidade/Relacionamento...72

8 LISTA DE TABELAS Tabela 1. Parâmetros envolvidos no desempenho do banco de dados...19 Tabela 2. Quadro de vantagens e desvantagens...40 Tabela 3. Quadro de vantagens e desvantagens...42 Tabela 4. Descrição das tabelas utilizadas no sistema...71 Tabela 5. Tabela de vantagens e desvantagens entre ferramentas...78 Tabela 6. Dicionário de dados da tabela acoes...85 Tabela 7. Dicionário de dados da tabela esquemas...85 Tabela 8. Dicionário de dados da tabela indices...85 Tabela 9. Dicionário de dados da tabela instancias...85 Tabela 10. Dicionário de dados da tabela memoria_logicas...86 Tabela 11. Dicionário de dados da tabela plano_execucoes...86 Tabela 12. Dicionário de dados da tabela shared_pools...86

9 RESUMO ROSA, Jonas. Desenvolvimento de uma Ferramenta para Análise de Ajuste de Desempenho do Banco de Dados Oracle. Itajaí, f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) - Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, A finalidade de um banco de dados é auxiliar na organização e na recuperação de dados. Em um banco de dados, há dois tipos distintos de acessos, um quando não há um SGBD (Sistema de Gerenciamento de Banco de Dados) e, no outro caso, quando o acesso a um banco de dados é realizado através de um SGBD. É justamente nessa segunda situação que o gerenciador assume a responsabilidade de buscar todas as informações necessárias controlando, assim, os dados e tendo o DBA (Database Administrator) como responsável por esse controle. Um DBA, por sua vez, tem diversas funções e, entre essas está a de ajustar o sistema para obter o melhor desempenho do banco de dados. O ajuste de desempenho (performance tuning) de um banco de dados pode ser feito de duas formas: através da elaboração de projetos que visam melhorar o desempenho de uma aplicação especifica; e/ ou através de ajustes de vários parâmetros. Ao se aprofundar nessas formas de ajuste de desempenho, fica evidente a necessidade de utilizar ferramentas para ajuste de desempenho que viabilizem e auxiliem esse processo de ajuste de desempenho. Sendo assim, este trabalho visa desenvolver uma ferramenta que auxilie no ajuste de desempenho do banco de dados Oracle. Entre as suas funcionalidades, estão: mostrar dados estatísticos através de gráficos; apresentar formas de melhorar a performance de um banco de dados; gerar scripts para realização da manutenção de um banco de dados e, por fim, manter um histórico das ações desta ferramenta. Palavras-chave: Ajuste de Desempenho. Sistema Gerenciador de Banco de Dados. Oracle.

10 ABSTRACT The aim of a database is to aid in the organization and the recovery of data. And, in a database, there are two distinct Kinds of accesses, one when there is not a database management system (DMS), and, in other case, when the access is accomplished through the DMS. It is just in the second situation that the administrator takes over the responsibility of searching all the necessary information controlling, then, the data and being the database administrator (DBA) as responsible by this control. However, a DBA has several functions and among these there is the function of adjusting the system to get the best performance of database.the adjust of performance (performance tuning) of a database can be done of two forms: throught the elaboration of projects that aim to improve the performance of a scientific application, and/ or thought regulations of several parameters. When it is made a profound study of these regulation forms of performance, it is evident the necessity of using tools (optimizers) that turn possible and aid this process of performance regulation of Oracle database. Among its functions are: to show statistics data throught the graphics, to present forms of improving the performance of a database, to generate scripts to the accomplishment of database maintenance and lastly to keep description of the actions of this tool. Keywords: Performance Tuning, Database Management System and Oracle.

11 1. INTRODUÇÃO Um banco de dados tem a finalidade de auxiliar na organização e na recuperação de dados. Não necessariamente um sistema de processamento de dados utiliza um SGBD (Sistema de Gerenciamento de Banco de Dados) para recuperação de informações, sendo que nesse caso, cabe ao desenvolvedor criar formas dessa recuperação. Porém, quando o acesso a um banco de dados é realizado através de um SGBD, cabe ao gerenciador assumir a responsabilidade de buscar todas as informações especificadas. (FANDERUFF, 2003). Sendo assim, a principal função de um SGBD é ter o controle centralizado dos dados, tendo o DBA (Database Administrator), como responsável por esse controle. Entre as funções de um DBA, de acordo com Fanderuff (2003), estão: definir quais dados serão armazenados e quais os acessos mais freqüentes; disponibilizar os dados desejados pelo usuário; fazer regras de acessos e os backups e como realizar a recuperação de informação quando da perda ou danificação dos dados; e ajustar o sistema para obter o melhor desempenho do banco de dados. É justamente essa última função, que consiste no ajuste do sistema para melhorar o desempenho do banco de dados, o foco desse trabalho. Fanderuff (2003) relata que quando o desempenho de um banco de dados não é o esperado, então há dois motivos que resultam nesse problema de desempenho: utilização de recursos inadequados; e realização de um projeto inadequado. De acordo com Silberschatz & Korth (1999), o ajuste de desempenho (performance tuning) de um banco de dados pode ser feito das seguintes formas: através de ajustes de vários parâmetros; e/ou através da elaboração de projetos que visam melhorar o desempenho de uma aplicação especifica. O mesmo autor destaca seis passos para que seja realizado o ajuste de desempenho de um banco de dados: (i) localização de gargalos; (ii) ajuste do banco de dados; (iii) ajuste de esquemas; (iv) ajuste de índices; (v) ajuste de transações; e (vi) simulação de desempenho. Quanto ao primeiro passo, localização de gargalos, Silberschatz & Korth (1999) cita que um programa pode estar gastando muito do seu tempo de execução em pequenos laços, enquanto que o restante do código consome muito pouco. São justamente esses pequenos laços que compõem o gargalo. Se um gargalo consome 80% do tempo total do sistema, mesmo que

12 seja apenas um pequeno laço, melhorá-lo irá aumentar muita a performance do programa. Resumindo, o primeiro passo é detectar gargalos e procurar melhorar o seu desempenho. Quando um gargalo é então neutralizado, um novo gargalo pode ser encontrado e melhorado. O segundo passo consiste em ajudar o banco de dados, o que pode ser feito em três níveis: O nível mais baixo é o de hardware, onde com uma simples inclusão de memória no buffer do banco de dados pode representar melhoras no SGBD.O segundo nível é uma relação aos parâmetros do sistema do banco de dados, como o tamanho do buffer, porém, alguns bancos já ajustam esse buffer automaticamente. Por último, então, é o de mais alto nível, o qual diz respeito a índices, esquemas e transações. A combinação desses três níveis é de grande importância. O ajuste de esquema é o terceiro passo para o ajuste de desempenho de um banco de dado. Esses esquemas são restrições impostas pela normalização adotada, sendo que o seu ajuste irá resultar em uma melhor distribuição dos registros, utilizando menos espaços no buffer do banco de dados. Como quarto passo, tem-se o ajuste de índices. Esse ajuste é realizado quando o índice é o gargalo, podendo ser acelerado com a criação de novos índices ou da sua exclusão, quando se faz necessário. Há casos em que o tipo de índice pode ser alterado de arvore-b para hash, ou vice-versa. O quinto passo diz respeito ao ajuste de transações. Muitos SGBDs já possuem embutidos um otimizador de transações que, de acordo com Silberschatz & Korth(1999), até mesmo consultas mal escritas podem ser realizadas com eficiência. Por fim, o sexto e ultimo passo diz respeito á simulação de desempenho, a qual se refere a criação de um modelo de simulação, para que seja mostrada uma diversidade de serviços, como CPU (Central Processing Unit), discos, buffer e controles de concorrência. Nessa simulação, diferentes experimentos podem ser feitos, de forma que o ajuste de desempenho seja realizado antes da sua real implantação. Vendo esses aspectos e esses passos importantes para o gerenciamento de um SGBD, fica evidente a necessidade de utilizar ferramentas para ajustes de desempenho que viabilizem e auxiliem este processo de ajuste de desempenho. 2

13 Porém, uma ferramenta para ajuste de desempenho tem que usar diversos recursos. Date (2000) relata que uma boa ferramenta deve ter uma grande quantidade de informações disponíveis de forma estatística, como, por exemplo, o numero de valores em cada domínio e o número atual de tuplas em cada variável de relação básica. Uma tupla é um registro inserido em uma tabela de banco de dados. Date (2000) ainda cita que essas informações ficam guardadas no catalogo do sistema, permitindo a ferramenta fazer uso e avaliar essas informações, de forma que possa projetar estratégias de ação e escolher a implementação mais eficiente. Em suma, uma ferramenta para ajuste de desempenho tem que ter recursos que possibilite avaliar uma centena de possíveis estratégias para execução de uma requisição. Além disso. Conforme são alteradas as estatísticas armazenadas, a mesma estratégia já não satisfaz a mesma realização da requisição. Este trabalho se insere no contexto acima apresentado e visa o desenvolvimento de uma ferramenta que auxilie no ajuste de desempenho do banco de dados Oracle. Para isso, será feito um estudo sobre SGBDs buscando: (i) definir o que é um tuning de banco de dados; (ii) mostrar dados estatísticos; (iii) apresentar formas de melhorar a performance de um banco de dados. (iv) gerar scripts para realização da manutenção de um banco de dados e, por fim, (v) manter um histórico das ações desta ferramenta OBJETIVOS Objetivo Geral Desenvolver uma ferramenta que auxilie no ajuste de desempenho do banco de dados Oracle, cuja função principal é captar dados estatísticos do banco de dados, gerar scripts para realização da sua manutenção e manter um histórico de atuação desta ferramenta Objetivos Específicos Os objetivos específicos deste projeto de pesquisa são: Pesquisar sistemas ou projetos similares; Especificar requisitos; 3

14 Realizar um levantamento de quais recursos o Oracle dispõe para tratamento do seu ajuste de desempenho; Realizar a modelagem conceitual do projeto para a busca de informações dos dados estatísticos e como disponibilizar estes dados de modo gráfico; Realizar a modelagem conceitual do projeto para gerar script de ajuste de desempenho; Realizar a modelagem conceitual do projeto para gerar o histórico da ferramenta; Implementar a ferramenta; Testar e validar a ferramenta ; e Documentar o desenvolvimento do trabalho de conclusão de curso; 1.2. METODOLOGIA As etapas para o cumprimento dos objetivos do TCC (Trabalho de Conclusão de Curso) são descritas em seguida. Redação Pré-Proposta: documento que expõe um visão geral do projeto de conclusão do Curso de Ciência da Computação relatando: introdução do projeto, objetivos, atividades, cronograma e definição de critérios; Levantamento Bibliográfico: O trabalho (TCCI) iniciou com a pesquisa de material bibliográfico: livros, artigos, periódicos, teses, Internet, a fim de fundamentar teoricamente as tecnologias que deveriam ser abordadas no trabalho; Revisão Bibliográfica: Nessa etapa, houve então a fundamentação teórica do trabalho através da utilização do levantamento bibliográfico realizado na etapa anterior, bem como o conhecimento adquirido durante a pesquisa. Este período foi acompanhado por reuniões semanais com o orientador e por relatórios quinzenais entregues á coordenação do TCC; Análise do Projeto: foi realizada a analise do sistema bem como a modelagem do banco. A modelagem foi realizada através de um diagrama de contexto, diagramas de fluxos de dados e especificações de processos, sendo utilizado, também, um diagrama ER (entidade-relacionamento) para banco de dados para o modelo relacional/objetorelacional dos bancos de dados tradicionais; 4

15 Considerações Finais: o trabalho é brevemente recapitulando, ressaltando pontos gerais do trabalho de conclusão de curso; Referências Bibliográficas: lista das referências utilizadas para o desenvolvimento desse trabalho; Apêndice A: esse apêndice consta a modelagem de dados que será utilizado na implementação da ferramenta foco desse trabalho. Essa modelagem consta o dicionário de dados das tabelas da ferramenta relatando o nome das tabelas, assim como o nome, o tipo e a descrição de cada campo da tabela; Apêndice B: nesse apêndice consta os algoritmos utilizados na implementação da ferramenta. Entre as informações contidas nesses algoritmos estão as instruções SQL; e Anexo: Como anexo do trabalho de conclusão de curso esta o artigo apresentado no XIX Congresso Regional de Iniciação e Tecnológica em Engenharia - CRICTE 2004, com o tema Desenvolvimento de uma Ferramenta para Análise de ajuste de Desempenho do Banco de Dados Oracle ESTRUTURA DO TRABALHO Este trabalho tem como finalidade auxiliar na análise e no ajuste de desempenho do banco de dados Oracle. Para tanto, a primeira etapa deste trabalho foi fazer um levantamento bibliográfico sobre: banco de dados Oracle; sistema de gerenciamento de banco de dados; conceito de ajuste de desempenho; ajuste de desempenho no banco de dados Oracle; e projetos/ ou sistemas similares. No tópico sobre o banco de dados Oracle é relatado informações referentes a sua historia. Em sistema de gerenciamento de banco de dados dá-se uma noção de como é tratada a estrutura física e lógica de um banco de dados, assim como a estrutura da memória. Na etapa de conceituação de ajuste de desempenho, são retratados seis passos fundamentais para a realização de ajustes de desempenho de um banco de dados. Ao se falar sobre ajuste de desempenho, então são focados conceitos sobre administração de banco de dados e justamente o ajuste de desempenho no banco de dados Oracle. 5

16 Por fim, então é apresentada a modelagem da analise do projeto a ser desenvolvida na segunda etapa do trabalho de conclusão de curso. 6

17 2. FUNDAMENTAÇÃO TEÓRICA Como pontos da fundamentação teórica desse trabalho de conclusão, estão 05 tópicos: banco de dados Oracle; Sistema Gerenciador de Banco de Dados; Conceito de Ajuste de Desempenho; Ajuste de Desempenho; Ferramentas de Tuning para Oracle; e Estudo sobre Sistemas e/ou Projetos Similares BANCO DE DADOS ORACLE O banco de dados foco desse trabalho de conclusão de curso será o Oracle 9i. Nesse capitulo será mostrado seu histórico A Historia do Banco de Dados Oracle A historia do banco de dados Oracle começou em 1970, quando Ted Codd lançou um modelo de dados relacional, tendo como protótipos o System R e o Ingress. O System R foi desenvolvido pela IBM, porém, ainda era um modelo não-comercial de banco de dados. Já o Ingress, teve seu desenvolvimento na Universidade de Berkeley, na Califórnia, pela equipe liberada por Michael Stonebaker (FANDERUFF, 2003). A linguagem SQL, que atualmente é padrão para linguagem de banco de dados relacional, foi desenvolvida a partir do System R. Nesse período (1977), então surge a Software Development Laboratories, através de Bob Miner, Ed Oates, Bruce Scott e Larry Ellison, que ate então eram analistas de sistemas que, ao estudarem sobre os dois sistemas acima citados, decidem lançar uma versão comercial de um produto similar (ibidem). De acordo com Oracle (2004), nessa época Larry Ellison vislumbrou, ao encontrar uma descrição de um protótipo funcional de um banco de dados relacional, uma oportunidade que outras companhias não haviam percebido, a de comercializar essa tecnologia. Porém, Ellison e os confundadores da Oracle, Bob Miner e Ed Oates, não imaginavam de que transformariam a cara da computação empresarial para sempre. A empresa, em 1979, mudou o seu nome para RSI (Relational Software Incorporated), sendo então gerado a primeira versão do Oracle, mais conhecido como Oracle V2, tendo como

18 primeiro cliente a Base da Força Aérea Patterson. Essa versão do Oracle rodava em uma maquina DEC PDP 11(FANDERUFF, 2003). Nesse mesmo na oferece o primeiro sistema comercial de gerenciamento de banco de dados relacionais SQL (ORACLE, 2004). Quando a RSI mudou seu nome para Oracle, em 1983, o Oracle V3 já rodava em PCs e mainframes, tornando-se o sistema mais potável do mundo (FANDERRUFF, 2003). No decorrer dos anos 80, Oracle (2004) relata que outras inovações foram desenvolvidas, entre elas: Disponibiliza um primeiro banco de dados desenvolvido em C, para portabilidade (1983); Oferece o primeiro banco de dados com consistência de leitura (1984); Oferece o primeiro banco de dados para servidores em paralelo (1985); Fornece suporte consultas distribuídas e desenvolve o primeiro banco de dados cliente/servidor (1986); e Primeiro banco de dados a oferecer bloqueio no nível de linhas e a introduzir o PL/SQL (1988). Nas versões mais atuais, tem-se Oracle 08, lançada em 1997, que já comportava um limite de 512 petabytes (um petabytes equivale a 1024 x 1024 x 1GB) de informações, além de ser um sistema gerenciador de banco de dados objeto-relacional. Já em 1999, com o crescimento da Internet, foi lançado o Oracle 8i, voltado para aplicações eb, sendo que, juntamente com a versão 9i, tem o desempenho e a escalabilidade necessárias para suportar essas aplicações (FANDERUFF, 2003). A versão focada neste trabalho é a versão 9i, que teve seu lançamento em 1º de Junho de Em relação a versão anterior, essa versão apresenta avanços em clusterização, confiabilidade e performance(ibidem). Como respaldo mundial. O Oracle 9i ganhou prêmios, como: Database para Linux (Linux Journal); Business Intelligence (DM Review); e o Recorde mundial de data warehousing (TCP-H) (ORACLE, 2004). 8

19 Além disso, segundo estudo da Harte-Hanks, três vezes mais clientes do banco de dados Informix pretendem migrar para o Oracle do que para o concorrente (FANDERUFF, 2003) SISTEMA DE GERENCIADOR DE BANCO DE DADOS ORACLE Ramalho (1999) relata que o Oracle é um banco de dados que possui uma estrutura física e lógica separadas no servidor, sendo que o armazenamento físico dos dados pode ser gerenciado de forma separada do acesso ás estruturas lógicas de armazenamento. Por conseguinte, o sistema gerenciador de banco de dados (SGBD) Oracle, segundo Fanderuff (2003), mantêm fisicamente um conjunto de arquivos em algum ponto do disco. O armazenamento lógico, por sua vez, é dividido em um conjunto de contas de usuário conhecidas como esquemas. Esse esquema é acessado e manipulado através de um usuário, que possui uma senha e privilégio de acesso. A seguir essas estruturas serão detalhadas e caracterizadas: Estrutura Física De acordo com Ramalho (1999), a estrutura física do Oracle é determinada pelos arquivos do sistema operacional que o constituem. Então, para cada banco de dados Oracle há pelo menos: um arquivo datafiles, dois arquivos redo e um arquivo de controle. Abaixo estão listadas as características de cada um desses arquivos. Após, a Figura 1 ilustra a estrutura física do Oracle. Datafiles: o Descrição: De acordo com Fanderuff (2003), datafiles é um conjunto de arquivos onde as informações estão efetivamente armazenadas, ou seja, os datafiles armazenam os dados das tabelas, os índices e as áreas temporárias e de rollback; o Funcionamento: Scherer (2002) relata que os dados armazenados nos datafiles são recuperados conforme a solicitação do cliente. Esses dados são alocados em uma memória real do servidor, tornando-a disponível para que os demais usuários possam acessar de forma mais rápida; e o Gerência: Como cópia de segurança para os dados contidos nos datafiles deve ser realizado regularmente backup desses arquivos. Alguns sistemas operacionais podem 9

20 mostrar restrições ao tamanho do datafile, nesse caso, recomenda-se que um datafile não ultrapasse o tamanho de 2GB. (FANDERUFF, 2003). Redo log files: o Descrição: Fanderuff (2003) relata que os arquivos redo log files são utilizados para armazenagem de transações realizadas no banco de dados com a finalidade de refazer as operações quando da perda de dados; o Funcionamento: Scherer (2002) diz que a função do arquivo redo log file é garantir a armazenagem de todas as alterações realizadas sobre os dados do banco de dados. Dessa forma é possível a recuperação para um estado seguro do banco de dados no caso de uma eventual falha; e o Gerencia: Há a necessidade de dois grupos de arquivos para quando um estiver cheio o outro possa ser utilizado. Se possível, manter os arquivos em discos diferentes para evitar gargalos, devido a um grande numero de gravação. (FANDERUFF, 2003). Control files: o Descrição: Scherer (2002) conta que toda vez que o banco de dados é inicializado o arquivo control file é lido para localização dos arquivos datafiles e redo log files. As alterações nesses arquivos, assim como as alterações estruturais no banco de dados, são registradas no arquivo control file. Um exemplo de alteração no banco de dados é a inclusão de um novo arquivo datafile; o Funcionamento: Scherer (2002) diz que um arquivo control file contém ponteiros que especificam a estrutura física do banco de dados. Entre as informações do banco de dados estão: nome do banco de dados; nomes e localizações dos datafiles e dos redo log files, arquivo de redo log corrente, e time stamp de criação do banco de dados; e o Gerência: Deve ser realizada regularmente uma cópia do arquivo control files, assim como ter cópias distribuídas em diferentes discos para garantir uma maior segurança. (FANDERUFF, 2003). 10

21 Datafiles Control Files Redo Logs Files Estrutura da Memória Figura 1: Estrutura Física Fonte: Adaptado de Fanderuff (2003) 2001): O Oracle divide a memória RAM (Random Access Memory) em duas partes (ZEGGER, O SGA (system global area) é um grupo das estruturas de memórias compartilhadas que, quando combinadas com os processos do Oracle, compreendem uma instância do Oracle. É dividido em quatro áreas: database buffer cache; redo log buffer; e shared pool; e O PGA (process global área) é onde a memória é alocada a cada processo conectada a base de dados. O tamanho deste alocamento é estático. O tamanho do PGA é dependente do sistema, mas é afetado pelos seguintes parâmetros: open links; db_files; e log_files. A figura 2 mostra como é a estrutura da memória do banco de dados Oracle. 11

22 Figura 2. Estrutura de memória utilizada pelo banco de dados Oracle Fonte: Adaptado de Zegger (2001) O DB Buffer Cachê mantém cópias de todos os blocos de dados que são lidos do data files. O Oracle mantém uma lista de blocos sujos e a LRU (Least Recently Used) para decidir-se que blocos devem ser mantidos na memória. Os blocos sujos são blocos update escritos e ainda não atualizados em disco. A lista de LRU identifica que são buffers livres, buffers fixados, ou buffers sujos que não foram removidos ainda da lista suja. Se um processo que esteja tentando executar leitura não encontra um buffer livre na lista LRU, então são utilizados esses buffers sujos (ZEGGER, 2001). O Redo Log Buffer é um buffer circular com um tamanho fixado. É nessa memória que os dados alterados são armazenados até a sua transferência para o redo log files. Ressalta-se que os dados aqui guardados não são os dados reais propriamente ditos, mas sim as instruções insert, delete e update para construção e alteração do banco de dados. Na pratica, quando acontece um update, por exemplo, é guardada essa instrução que passa da situação A (atual) para a situação B (após o update), além dessa instrução, também é guardada uma instrução que equivalente ao rollback, ou seja, da situação B (após o update) para A (atual) (FANDERRUFF, 2003). Quando o Oracle necessita executar uma tarefa que requeira a classificação dos dados o Sort Area é usada. Um processo do Oracle pede uma Sort Area. Essa Sort Area pode crescer até o tamanho do parâmetro SORT_AREA_SIZE e, se esta quantidade de memória não for suficiente a 12