1111330740

VAGNER FREITAS RIGO
ESTUDO DA METODOLOGIA DE TUNING EM BANCO DE DADOS ORACLE
Assis 2012
VAGNER FREITAS RIGO
Trabalho
de
Concluso
de
Curso
apresentado ao Curso de Cincias da Computao do Instituto Municipal de Ensino Superior de Assis IMESA e a Fundao Educacional do Municpio de Assis FEMA, como requisito do Curso de Graduao. Orientador: Dr. Alex Sandro Romeo de Souza Poletto. rea de Concentrao: Sistema de Banco de Dados. Sistema Gerenciador de Banco de Dados. Tuning em Banco de Dados.
Assis 2012
FICHA CATALOGRFICA
RIGO, Vagner Freitas. Estudo da Metodologia de Tuning em Banco de Dados Oracle/ Vagner Freitas Rigo. Fundao Educacional do Municpio de Assis FEMA - Assis, 2012. 116 p. Orientador: Dr. Alex Sandro Romeo de Souza Poletto. Trabalho de Concluso de Curso Instituto Municipal de Ensino Superior de Assis -
IMESA.
1. Banco de dados. 2. Tuning. 3. Oracle 11g. 4. Otimizao. CDD: 001.6 Biblioteca da FEMA
VAGNER FREITAS RIGO
Trabalho de Concluso de Curso apresentado ao Instituto Municipal de Ensino Superior de Assis IMESA, como requisito do Curso de Graduao, analisado pela seguinte comisso examinadora:
Orientador: Dr. Alex Sandro Romeo de Souza Poletto.
Analisador (1): Fernando Cesar de Lima
Analisador (2):
Assis 2012
Dedico este trabalho a Deus, Pela fora espiritual para a realizao desse trabalho. Aos meus pais Bento Rigo e Edith Freitas Rigo, Pelo carinho, compreenso e pela grande ajuda. minha esposa, meu grande e eterno amor de minha vida Daiane Lima Xaro, Pelo eterno orgulho de nossa caminhada, pelo apoio, compreenso, ajuda, e, em especial, por todo carinho ao longo deste percurso. Ao professor Alex Sandro Romeo de Souza Poletto, Pela orientao deste trabalho.
RESUMO
Este trabalho apresenta um estudo sobre tuning, uma importante rea de atuao do banco de dados, que trata do ajuste fino de desempenho, conceito este que se encontra em grande desenvolvimento e aplicao atualmente, diante do grande volume de dados que so gerados pelas empresas que utilizam da Tecnologia da Informao. Pelo fato desse grande nmero de informao e necessidade de constante acesso s mesmas, encontra-se a necessidade de utilizao do tuning, como uma forma de aprimoramento destas consultas aos Bancos de Dados, que precisam ser realizadas da maneira mais satisfatria possvel, com alto desempenho de resposta e menor tempo. Neste contexto, ajustar e otimizar uma consulta e mesmo o prprio Banco de Dados, questo primordial. Assim, o presente trabalho, abordando o contedo atinente matria em questo, trata de descrever os conceitos bsicos sobre o Sistema Gerenciador de Banco de Dados (SGBD), tecendo as informaes bsicas sobre Banco de Dados (BD), sua evoluo histrica, conceitos, consideraes e SGBD Oracle, e a importncia da linguagem SQL. Trata-se ainda da metodologia e tcnicas de tuning e otimizao e a finalizar apresenta-se proposta de trabalho e estudo de caso com base em um SGBD Oracle 11g, com propostas para instrues DML dentro do Banco de Dados, implementao e testes. Os resultados obtidos apresentam situaes de melhora ou degradao no desempenho de vrias funcionalidades do software.
Palavras-chave: Banco de dados, Tuning, Oracle 11g, Otimizao.
ABSTRACT
This work discusses tuning, an important area of operation of the database, which is fine-tuning performance, a concept that is in great development and application currently before the large volume of data that are generated by companies that use the Information Technology. Because of this large number of information and need for constant access to them, we find the need for use of tuning, as a way to improve these queries to databases that need to be performed most satisfactorily as possible, with high response performance and shorter. In this context, tweak and optimize a query, and even your own database, is key issue. Thus, the present work, addressing the content regards the subject matter, comes to describing the basic concepts of the System Manager Database, weaving the basic information about BD, its historical development, concepts, considerations about the DBMS, and BD Oracle DBMS, and the importance of the SQL language. We will further the methodology and techniques for tuning and optimizing and finalizing work proposal and present a case study based on an Oracle 11g DBMS, with proposals for DML within the database, implementation and testing. The results obtained are situations of improvement or degradation in performance of various software features. Keywords: Database, Tuning, Oracle 11g, Optimization.
LISTA DE ILUSTRAES/FIGURAS
Figura 1. Sistemas antigos X Sistemas atuais ...................................................................................... 18 Figura 2. Desenvolvimento dos modelos de dados (ROB; CORONEL, 2011, p. 48) ........................... 22 Figura 3. Principais funes e componentes de um SGBD (Date, 2003, p. 38) ................................... 26 Figura 4. Estrutura do sistema (SILBERSCHATZ; KORTH; SUDARSHAN, 2006, p. 18) .................... 27 Figura 5. Arquitetura do Oracle ............................................................................................................. 35 Figura 6. Fases do Tuning (Souza (2009), et al apud Peixoto Jnior e Carvalho(2008)) .................... 43 Figura 7. Responsveis pelo tuning ...................................................................................................... 44 Figura 8. Metodologia para tuning......................................................................................................... 46 Figura 9. Viso Geral do processamento de consultas (DATE, 2003, p. 459). .................................... 53 Figura 10. Script para criao da tablespaces de dados ...................................................................... 59 Figura 11. Script para criao da tablespaces de ndices .................................................................... 59 Figura 12. Script para criao do usurio do banco de dados e grants ............................................... 59 Figura 13. Conexo com o Banco de Dados ........................................................................................ 60 Figura 14. Schema criado ECOMMERCE_I ......................................................................................... 60 Figura 15. Tabelas para testes de tuning .............................................................................................. 61 Figura 16. Estatsticas no RDBMS da tabela Cliente............................................................................ 62 Figura 17. Script DBMS_STATS ........................................................................................................... 62 Figura 18. Terminada a coleta de estatstica das tabelas .................................................................... 63 Figura 19. Tabela Atualizada ................................................................................................................ 63 Figura 20. Antes de gerar as estatsticas .............................................................................................. 64 Figura 21. Aps atualizao das estatsticas e ndices do schema...................................................... 65 Figura 22. Trecho de campos da tabela cliente .................................................................................... 66 Figura 23. Campo flag NUMBER .......................................................................................................... 67 Figura 24. Estrutura do ndice B-Tree ................................................................................................... 68 Figura 25. Estrutura de ndice Bitmap ................................................................................................... 69 Figura 26. Plano de Execuo .............................................................................................................. 71 Figura 27. Tempo de resposta entre o comando DELETE e TRUNCATE ........................................... 73 Figura 28. Teste DELETE com FORALL .............................................................................................. 74 Figura 29. Utilizando DELETE com PARALLEL ................................................................................... 75 Figura 30. Insert com Direct Path.......................................................................................................... 76 Figura 31. Criao de Sequences. ........................................................................................................ 77 Figura 32. Tempo entre Insert com Sequence com Cache e Sem cache ............................................ 78 Figura 33. Insert com Bulk Collection ................................................................................................... 79 Figura 34. Criando arquivo texto, delimitado por pipe .......................................................................... 80 Figura 35. Estrutura do Arquivo Texto .................................................................................................. 81 Figura 36. Arquivos necessrios para carga via SQL_LOADER .......................................................... 81 Figura 37. Cliente.ctl ............................................................................................................................. 81
Figura 38. exec_carga_loader.sh .......................................................................................................... 82 Figura 39. Tempo de carga de 35 segundos ........................................................................................ 82 Figura 40. Alterao no arquivo cliente.ctl ............................................................................................ 83 Figura 41. Tempo de carga de 01 minuto e 34 segundos .................................................................... 83 Figura 42. Insert Convencional X MERGE ............................................................................................ 84 Figura 43. Evitando o uso do Asterisco ................................................................................................ 85 Figura 44. Processamento de SQL no Oracle ...................................................................................... 86 Figura 45. Queries Apelidos .................................................................................................................. 87 Figura 46. Dica de programao com NOT IN e IN .............................................................................. 88 Figura 47. Operadores de negao ...................................................................................................... 89 Figura 48. Evitando uso de Curingas no LIKE ...................................................................................... 90 Figura 49. Comparao com funes na ligao entre tabelas ............................................................ 91 Figura 50. Plano de Execuo entre JOINS com ndice baseado em Funes ................................... 92 Figura 51. Comparao NULL e NOT NULL ........................................................................................ 93 Figura 52. UNION X UNION ALL .......................................................................................................... 94 Figura 53. Utilizando CASE ................................................................................................................... 95 Figura 54. Desempenho do CASE X UNION ALL ................................................................................ 96 Figura 55. Utilizando a Clausula WITH ................................................................................................. 97 Figura 56. Comparao com a Clusula WITH .................................................................................... 97 Figura 57. Tempo de Desempenho com varivel BIND........................................................................ 98 Figura 58. Local onde ser gerado os arquivos do TKPROF ............................................................. 104 Figura 59. Habilitando o trace no ambiente ........................................................................................ 104 Figura 60. Instruo realizada no trace ............................................................................................... 105 Figura 61. Localizando os arquivos gerados pelo TKPROF ............................................................... 105 Figura 62. Gerando arquivo .txt do trace gerado pelo TKPROF ......................................................... 105 Figura 63. Lendo o arquivo gerado ..................................................................................................... 106 Figura 64. Parte do arquivo gerado onde encontra-se o trace da instruo executada a ser analisada ............................................................................................................................................................. 106 Figura 65. Alterado o parmetro CURSOR_SHARING ...................................................................... 107 Figura 66. Parmetro OPTIMIZER_INDEX_COST_ADJ .................................................................... 108 Figura 67. Obtendo valor para o parametros OPTIMIZER_INDEX_CACHING ................................. 109
LISTA DE TABELAS
Tabela 1. Evoluo dos principais modelos de dados (ROB; CORONEL, 2011, p. 37)....................... 19 Tabela 2. Vantagens e desvantagens dos diferentes modelos de BD (Ind.*: Independncia) ............ 21 Tabela 3. Quadro demonstrativo das verses de Banco de Dados Oracle (ORACLE 2 a ORACLE 6.1) ............................................................................................................................................................... 28 Tabela 4. Quadro demonstrativo das verses de Banco de Dados Oracle ORACLE 7.0 a ORACLE 7.3 ............................................................................................................................................................... 29 Tabela 5. Quadro demonstrativo das verses de Banco de Dados Oracle ORACLE 8.0 a ORACLE 8i (8.1.7) .................................................................................................................................................... 31 Tabela 6. Quadro demonstrativo das verses de Banco de Dados Oracle ORACLE 9i Release 1 (9.0.1) a ORACLE 9i Release 2 (9.2.0) ................................................................................................. 31 Tabela 7. Quadro demonstrativo das verses de Banco de Dados Oracle ORACLE 10g Release 1 (10.1.0) a ORACLE 10g Express Edition (ORACLE XE) ...................................................................... 32 Tabela 8. Quadro demonstrativo das verses de Banco de Dados Oracle ORACLE 11g ................... 33 Tabela 9. Tipos de dados suportados pelo Oracle ............................................................................... 37 Tabela 10. Vantagens e desvantagens do SQL ................................................................................... 39 Tabela 11. Diretrizes Gerais para melhor desempenho do sistema (ROB; CORONEL, 2011, p. 471) 51
LISTA DE ABREVIATURAS E SIGLAS
BD DBA DDL DML I/O PGA SBD SGA SGBD SQL
Banco de Dados Administrador de Banco de Dados Linguagem Language) Linguagem de Manipulao de Dados (Data Manipulation Language) Input/Output Program Global Area Sistema de Banco de Dados System Global Area Sistema Gerenciador de Banco de Dados Linguagem Estruturada de Consulta (Structure and Query Language) de Definio de Dados (Data Definition
Sumrio 1 INTRODUO .................................................................................. 14

1.1 OBJETIVOS ........................................................................................................ 14 1.2 JUSTIFICATIVAS ................................................................................................ 15 1.3 MOTIVAO ....................................................................................................... 15 1.4 METODOLOGIA DE PESQUISA ......................................................................... 15 1.5 ESTRUTURA DO TRABALHO ............................................................................ 16
2. CONCEITOS BSICOS SOBRE O SISTEMA GERENCIADOR DE BANCO DE DADOS (SGBD) ............................................................... 18

2.1 BREVES CONSIDERAES SOBRE BANCO DE DADOS............................... 18 2.2 SISTEMA GERENCIADOR DE BANCO DE DADOS (SGBD) ............................ 24 2.3 BANCO DE DADOS ORACLE ............................................................................ 28 2.3.1 Evoluo Histrica da Oracle ........................................................................... 28 2.3.2 SGBD Oracle.................................................................................................... 34
3. METODOLOGIA DE TUNING .......................................................... 38

3.1 LINGUAGEM SQL ............................................................................................... 38 3.2 FUNDAMENTAO TERICA SOBRE TUNING ............................................... 40 3.2.1 Conceitos gerais sobre Tuning ......................................................................... 41 3.3 OTIMIZAO ...................................................................................................... 49 3.3.1 Conceito e funo ............................................................................................ 49 3.3.2 Aspectos gerais ................................................................................................ 50 3.3.3 Plano de execuo ........................................................................................... 53 3.3.4 Otimizador de Query ........................................................................................ 54
4. PROPOSTA DE TRABALHO........................................................... 57 5. ESTUDO DE CASO ......................................................................... 58

5.1 Criao do modelo fsico (modelagem e normalizao): ..................................... 58 5.1.1 Estrutura fsica das tablelas do schema ECOMMERCE_I ............................... 59 5.2 Estatsticas no RDBMS Oracle............................................................................ 61 5.3 Modelagem Fsica do Banco de Dados ............................................................... 66 5.3.1 ndices em tabelas ........................................................................................... 67 5.4 Entendendo como o Oracle Database processa as instrues SQL. .................. 70 5.4.1 Plano de Execuo .......................................................................................... 71
5.5 Tunando Atualizaes de dados no Oracle Database. ....................................... 72 5.5.1 DELETE. .......................................................................................................... 72 5.5.2 INSERT. ........................................................................................................... 76 5.6 Tuning em Queries. ............................................................................................. 84 5.6.1 Uso do Asterisco em consultas. ....................................................................... 85 5.6.2 Queries Idnticas ............................................................................................. 86 5.6.3 Queries Apelidos .............................................................................................. 87 5.6.4 Regras de Precedncia .................................................................................... 87 5.6.5 Operadores Ou e Diferente .............................................................................. 88 5.6.6 Operadores de Negao .................................................................................. 89 5.6.7 Operador Like................................................................................................... 90 5.6.8 ndices nas Foreing Key ................................................................................... 91 5.6.9 Evite o uso de funes entre ligaes de tabelas. ........................................... 91 5.6.10 Converses de dados em ligaes como ndices baseado em Funes. ...... 92 5.6.11 Utilizao do NULL para comparaes .......................................................... 93 5.6.12 UNION e UNION ALL ..................................................................................... 94 5.6.13 Utilizando CASE para busca de dados........................................................... 95 5.6.14 Utilizando a Clusula WITH para criao de tabela temporria ..................... 96 5.6.15 Utilizao de Variveis BIND.......................................................................... 98 5.7 Utilizao de HINT. ............................................................................................. 99 5.7.1 HINT FULL SCAN ............................................................................................ 99 5.7.2 HINT FULL COM PARALLEL ......................................................................... 100 5.7.3 HINT FIRST_ROWS....................................................................................... 100 5.7.4 HINT RULE .................................................................................................... 100 5.7.5 HINT FULL ..................................................................................................... 100 5.7.6 HINT LEADING .............................................................................................. 100 5.7.7 HINT USE_NL ................................................................................................ 101 5.7.8 HINT USE_HASH ........................................................................................... 101 5.8 Ferramentas para analise de performance e desempenho do banco. .............. 101 5.8.1 Explain Plan. .................................................................................................. 101 5.8.2 SQL LOADER ................................................................................................ 102 5.8.3 TKPROF ......................................................................................................... 103
5.9 Parmetros de Banco de dados Oracle 11 G .................................................... 106 5.9.1 Parmetro Cursor_Sharing............................................................................. 106 5.9.2 Parmetro Optimizer_Index_Cost_Adj ........................................................... 107 5.9.3 Parmetro OPTIMIZER_INDEX_CACHING ................................................... 108 5.9.4 Parmetro OPTIMIZER_MODE ..................................................................... 109
CONCLUSO .................................................................................... 111 REFERNCIAS .................................................................................. 113
14
1 INTRODUO
Diante do crescente volume de dados atualmente pertencentes s Empresas que empregam Sistemas de Informao, torna-se imprescindvel o papel do Banco de Dados. Frente a isso, e necessidade constante de acesso aos dados, verifica-se em muitas vezes que a disponibilidade dos resultados, insatisfatria. Dessa forma, v-se a necessidade de implementao de cdigos estruturados seguindo padres de tuning para otimizao dos resultados, dada a sua relevncia para as Empresas. Neste sentido, que proposto este trabalho, cuja finalidade apresentar a importncia da tecnologia (ou dos recursos) de tuning, a fim de proporcionar uma melhor utilizao dos recursos oferecidos pelos Sistemas Gerenciadores de Banco de Dados (SGBD) no que diz respeito recuperao de informaes por meio de consultas otimizadas. O crescimento da rea notvel, ante a importncia ao acesso das informaes para as Empresas a fim de que sejam tomadas as decises. O enorme volume dos dados e o espao de tempo para a busca destas informaes exigem uma ateno especial com a velocidade para o acesso aos bancos de dados. A importncia para o desenvolvimento deste trabalho se d pelo fato de ser o tuning um processo de refinamento que envolve modificaes em vrios aspectos.
1.1 OBJETIVOS
O objetivo do presente trabalho demonstrar o desempenho e a importncia do tuning, diante de sua atual necessidade para as empresas manterem um bom funcionamento no que diz respeito ao acesso de informaes aos bancos de dados, sendo o tuning um ajuste fino de desempenho. A partir disso, pretende-se expor os conceitos gerais de banco de dados e ater-se aos conceitos especficos da tecnologia tuning, bem como realizar propostas de instrues, implementaes e testes na referida rea, com base no Oracle 11g.
15
1.2 JUSTIFICATIVAS
A justificativa para propositura deste trabalho est no fato de que o presente tema est muito em comento na atualidade, tratando-se de um assunto pouco utilizado no desenvolvimento dos sistemas, sem muitos contedos disponveis, sendo este, portanto, a fim de esmiuar o contedo e demonstrar que a utilizao de tal tcnica capaz de ajustar e aperfeioar uma consulta e o prprio Banco de Dados da empresa, podendo-se ter um ganho de performance satisfatria, haja vista a cobrana do mercado a respeito de desempenho e otimizao.
1.3 MOTIVAO
O presente trabalho poder servir como fonte de consulta, haja vista a escassa explorao sobre este tema pouco abordado at o momento. Ademais, imprescindvel o desenvolvimento de tais pesquisas dada a importncia para as empresas na modernidade, quando concentram um grande banco de dados, que precisam ser acessados constantemente para seu funcionamento, ademais, pelo fato de aumento das informaes a cada ano e constantemente. Este trabalho poder contribuir com as empresas que desejarem buscar informaes a cerca desta tcnica de otimizao de consultas aos seus bancos de dados, a fim de obter um melhor desempenho, sugerindo possveis alteraes.
1.4 METODOLOGIA DE PESQUISA
Para o desenvolvimento da presente pesquisa pretende-se coletar o material bibliogrfico sobre o tema, a partir de livros, artigos, teses, dissertaes, coletas de dados, Internet e todos os demais recursos que abranjam o tema. Utilizando-se de um Banco de Dados em Oracle 11g, ser elaborado um Estudo de Caso cuja
16 finalidade apresentar testes de performance e otimizao de instrues DML (Data Manipulation Language).
1.5 ESTRUTURA DO TRABALHO
O trabalho ser dividido em seis captulos, como descrito abaixo: No Captulo 1 retrata-se um breve apontamento sobre o tema objeto da pesquisa, descrio dos objetivos, justificativa, motivao, metodologia de pesquisa e estrutura do trabalho. No Captulo 2 so abordados os conceitos bsicos sobre o Sistema Gerenciador de Banco de Dados, discorrendo-se inicialmente sobre breves consideraes de Banco de Dados, sua evoluo histrica e seus vrios conceitos apresentados por diferentes doutrinadores. Aps, discute-se o SGBD, seus conceitos gerais e caractersticas. Em seguida o tema delimitado tratando especificamente de Banco de Dados Oracle, expondo sucintamente a cerca da evoluo histrica da Oracle e suas vrias verses desenvolvidas para BD Oracle e a finalizar este capitulo trata-se do SGBD Oracle e suas caractersticas gerais. O Captulo 3 aborda os conceitos e importncia da linguagem SQL, com a demonstrao das vantagens e desvantagens de utilizao da referida linguagem, suas funes e categorias, enfim, os principais aspectos desta linguagem. Aps, o tema objeto da presente pesquisa aprofundado pela fundamentao terica sobre tuning e sua alta incidncia no mercado atual, apresentando seus conceitos gerais, com fundamento em vrios autores, seus objetivos, tcnicas, implementao, responsveis por sua realizao, metodologia. E por fim, discorre-se a cerca da otimizao, delimitando seu conceito e funo, aspectos gerais, plano de execuo, otimizador de consultas e Database Oracle 11g automatic SQL tuning. No Captulo 4 apresentada a Proposta do Trabalho.
17
No Captulo 5 apresentado o Estudo de Caso, propostas para instrues DML dentro do Banco de dados, implementao e testes. O Captulo 6 traz as Consideraes Finais.
18
2. CONCEITOS BSICOS SOBRE O SISTEMA GERENCIADOR DE BANCO DE DADOS (SGBD)
2.1 BREVES CONSIDERAES SOBRE BANCO DE DADOS
Antes de se adentrar no assunto, imprescindvel percorrer sobre a evoluo histrica dos bancos de dados, diante da relevncia do assunto em questo, simplesmente pelo fato de que, de alguma forma, com certeza se pertence a um banco de dados ou se usurio do mesmo. Atualmente, todos esto rodeados de ambientes informatizados, vivenciando-se a era da informao. Mas antes desse momento, os programas se desenvolviam a fim de satisfazer as necessidades que eventualmente iam surgindo, o que gerava uma sria inconsistncia de dados, dificuldade do acesso aos dados e isolamento dos dados, problemas de segurana, dentre muitos outros, diante do fato de que cada sistema seria desenvolvido especificamente para cada atividade, no havia o cruzamento de informaes. A fim de solucionar estes e outros problemas, viu-se a necessidade da criao dos bancos de dados e dos sistemas gerenciadores de banco de dados. Pelo fato de inicialmente no existir os bancos de dados, mas to somente os sistemas de arquivos (fitas magnticas e decks de carto perfurado) especficos, sem qualquer forma de compartilhamento de dados entre as mesmas.
Figura 1. Sistemas antigos X Sistemas atuais
19 Assim como os sistemas de arquivos, os bancos de dados tambm evoluram, passando por vrias geraes at atingir o patamar atual, onde cada novo modelo de dados supera uma falha dos modelos anteriores. A fim de ilustrar o exposto, esto s tabelas abaixo, que resumem sucintamente as caractersticas de cada uma.
Gerao
Primeira
poca
Dcada de 1960 e 1970
Modelo
Sistema de arquivos
Exemplos
VMS/VSAM
Comentrios
Utilizado principalmente de em sistemas mainframe da IBM Gerenciamento registros, sem relacionamentos
Segunda
Dcada de 1970
Modelo de dados hierrquico e em rede
IMS ADABAS IDS-II
Primeiros sistemas de bancos de dados Acesso navegacional
Terceira
De meados da dcada de 1970 at o presente
Modelo de dados relacional
DBS Oracle MS SQL Server MySQL
Simplicidade conceitual Modelagem entidade relacionamento (ER) e suporte a modelagem relacional de dados
Quarta
De meados da dcada de 1980 at o presente
Orientado objetos Relacional estendido
Versant FastObjects.Net Objectivity/DB DB/2 UDB Oracle 10g
Suporte a dados complexos Produtos relacionais estendidos com suporte a warehouse de dados e objetos Bancos de dados na web tornam-se comuns
Prxima gerao
Do presente ao futuro
XML
dbXML Tamino DB2 UDB Oracle 10g My SQL Server
Organizao e gerenciamento de dados no estruturados Modelos relacionais e de objetos adicionam suporte a documentos em XML
Tabela 1. Evoluo dos principais modelos de dados (ROB; CORONEL, 2011, p. 37)
20
Modelo de dados
Hierrquico
Ind.* de dados
Sim No
Ind.* estrutural
Vantagens
1. Promove o compartilhamento de dados; 2. O relacionamento pai/filho promove simplicidade conceitual; 3. A segurana do banco de dados fornecida e aplicada pelo SGBD; 4. O relacionamento pai/filho promove integridade de dados; 5. eficiente em relacionamentos 1:M.
Desvantagens
1. Implementao complexa exige conhecimento das caractersticas de armazenamento fsico; 2. O sistema navegacional torna complexo o desenvolvimento, gerenciamento e utilizao de aplicaes; exige conhecimento do caminho hierrquico; 3. Alteraes de estrutura exigem alteraes em todos os aplicativos; 4. H limites de implementao (no so possveis vrios pais nem relacionamentos M:N); 5. No h linguagem de definio ou manipulao de dados no SGBD; 6. No h padres. 1. A complexidade do sistema limita a eficincia ainda um sistema navegacional; 2. O sistema navegacional resulta em implementao, aplicao, desenvolvimento e gerenciamento complexos; 3. Alteraes estruturais exigem alteraes em todos os aplicativos.
Em rede
Sim
No
1. A simplicidade conceitual pelo menos igual do modelo hierrquico; 2. Lida com mais tipos de relacionamentos, como M:N e de vrios pais; 3. O acesso aos dados mais flexvel do que nos modelos hierrquicos e de sistema de arquivos; 4. O relacionamento proprietrio/membro promove a integridade DE DADOS; 5. H conformidade a padres; 6. Inclui linguagem de definio (DDL) e de manipulao (DML) de dados no SGBD.
21
Modelo de dados
Relacional
Ind.* de dados
Sim Sim
Ind.* estrutural
Vantagens
1. A independncia estrutural promovida pela utilizao de tabelas independente. Alteraes em uma estrutura de tabelas no afetam o acesso a dados ou os aplicativos; 2. A visualizao tabular aprimora consideravelmente a simplicidade conceitual, promovendo, assim, projeto, implementao, gerenciamento e utilizao mais fceis; 3. O recurso de consultas ad hoc baseia-se em SQL; 4. O SGBD isola o usurio final dos detalhes do nvel fsico e aprimora a simplicidade de implementao e gerenciamento. 1. A modelagem visual resulta em excelente simplicidade conceitual; 2. A representao visual o torna um ferramenta de comunicao eficiente; 3. integrado ao modelo relacional dominante.
Desvantagens
1. O SGBD exige capacidade considervel de hardware e de software do sistema; 2. A simplicidade conceitual permite que pessoas relativamente sem treino utilizem mal as ferramentas de um bom sistema e, se isso no for controlado, pode produzir as mesmas anomalias de dados encontradas em sistemas de arquivos; 3. possvel desenvolver problemas de ilhas de informao, pois indivduos e departamentos podem desenvolver suas prprias aplicaes.
Entidaderelacioname nto
Sim
Sim
Orientado a objetos
Sim
Sim
1. Adiciona contedo semntico; 2. A representao visual inclui contedo semntico; 3. A herana promove a integridade de dados.
1. A representao de restries limitada; 2. A representao de relacionamentos limitada; 3. No h linguagem de manipulao de dados; 4. Ocorre perda de contedo de informao quando atributos so removidos de entidades para evitar exibies muito poludas. 1. O desenvolvimento lento de padres fez com que os fornecedores oferecessem seus prprios aprimoramentos, eliminando, assim, um padro amplamente aceito; 2. Trata-se de um sistema navegacional complexo; 3. Exige uma ampla aprendizagem; 4. A alta carga dos sistemas deixa as transaes lentas.
Tabela 2. Vantagens e desvantagens dos diferentes modelos de BD (Ind.*: Independncia)
22
Figura 2. Desenvolvimento dos modelos de dados (ROB; CORONEL, 2011, p. 48)
Discorrido sobre a evoluo dos modelos de dados, cabe adentrar no conceito de banco de dados, que dado por diversos autores, como a seguir demonstra-se. De acordo com Date (2003):
Um sistema de banco de dados basicamente apenas um sistema computadorizado de manuteno de registros. O banco de dados, por si s, pode ser considerado como o equivalente eletrnico de um armrio de arquivamento; ou seja, ele um repositrio ou recipiente para uma coleo de arquivos de dados computadorizados (DATE, C. J., 2003, p. 3).
Conforme Teorey, um banco de dados uma coleo de dados armazenados e inter-relacionados, que atende s necessidades de vrios usurios dentro de uma ou mais organizaes, ou seja, colees inter-relacionadas de muitos tipos diferentes de tabelas (TEOREY, 2007, p. 2). Eles so utilizados em aplicaes na rea da informtica, cujo objetivo registrar e manter informaes consideradas significativas para as organizaes (ELMSRI, 2000).
23 Nos ensinamentos de Silberschatz (2006):

Os sistemas de banco de dados so projetados para gerenciar grandes blocos de informaes. Esses grandes blocos de informaes no existem isolados. Eles so parte da operao de alguma empresa cujo produto final pode ser informaes do banco de dados ou pode ser algum dispositivo ou servio para o qual o banco de dados desempenha apenas um papel de apoio (SILBERSCHATZ; KORTH; SUDARSHAN, 2006, p. 9).
A acrescentar, adota-se novamente os ensinamentos de Silberschatz, Korth e Sudarshan (2001), onde apresentam o objetivo do sistema de banco de dados:
O objetivo de um sistema de banco de dados simplificar e facilitar o acesso aos dados. Vises de alto nvel ajudam a alcanar esses objetivos. Os usurios do sistema no devem ser desnecessariamente importunados com detalhes fsicos relativos implementao do sistema. Todavia, um dos fatores mais importantes de satisfao ou insatisfao do usurio com um sistema de banco de dados justamente seu desempenho. Se o tempo de resposta demasiado, o valor do sistema diminui. O desempenho de um sistema de banco de dados depende da eficincia das estruturas usadas para a representao dos dados, e do quanto este sistema est apto a operar essas estruturas de dados. Como acontece em outras reas dos sistemas computacionais, no se trata somente do consumo de espao e tempo, mas tambm da eficincia de um tipo de operao sobre outra. (SILBERSCHATZ; KORTH; SUDARSHAN, 2001, p. 14)
Um banco de dados tem como principais objetivos, atender as necessidades da empresa e dos usurios; garantir a segurana dos dados e das transaes realizadas; agilizar os processos de consultas, alteraes e excluses de dados; armazenar os dados e garantir que fiquem armazenados permanentemente.
24
2.2 SISTEMA GERENCIADOR DE BANCO DE DADOS (SGBD)
O sistema de gerenciamento de bancos de dados (SGBD) um conjunto de programas que gerenciam a estrutura do banco de dados e controlam o acesso aos dados armazenados. At certo ponto, o banco de dados se assemelha a um arquivo eletrnico com contedo muito bem organizado com a ajuda de um software poderoso, conhecido como sistema de gerenciamento de banco de dados (ROB; CORONEL, 2011, p. 6). O SGBD seria um intermedirio entre o usurio e o banco de dados, e somente por meio dele que possvel o acesso ao conjunto de dados e arquivos em geral, armazenados em sua estrutura. Em resumo, o software responsvel pela criao e manuteno do banco de dados, ou seja, o SGBD se comunica com o BD e assim possibilita a realizao de consultas e manipulaes das informaes pelos usurios. Um SGBD de boa qualidade deve oferecer garantia de integridade, restrio de acesso no autorizado, recuperao e backup, controle de concorrncia, mltiplas interfaces e representao de relaes complexas entre os dados. Dentre as inmeras vantagens que um SGBD pode trazer, pode-se citar como principais: o aprimoramento do compartilhamento e segurana de dados, melhoria na integrao dos dados, minimizao da inconsistncia dos dados, aprimoramento do acesso aos dados, da tomada de deciso e aumento da produtividade do usurio final. Dois tipos de linguagens devem ser suportadas pelo SGBD, quais sejam, a DDL (Data Definition Language) e a DML (Data Manipulation Language): A DDL permite a especificao do esquema da organizao, ou seja, entidades com seus atributos e tipos de dados associados; os relacionamentos entre estas entidades e os ndices de acesso associados aos atributos. Portanto, entende-se que se trata de uma organizao lgica dos dados de uma realidade, adequados ao modelo de dados do SGBD.
25 A DML permite as operaes usuais de manipulao de dados, executados pelas aplicaes: incluso, alterao, excluso e consulta. Ao tratar do tema, Date o define como software que aborda o acesso ao BD em sua totalidade. A fim de demonstrar, por meio de exemplos, o autor adota ocorrer o seguinte:
1. Um usurio faz um pedido de acesso usando uma determinada sublinguagem de dados (geralmente SQL). 2. O SGBD intercepta o pedido e o analisa. 3. O SGBD, por sua vez, inspeciona o esquema externo (ou as verses objeto desse esquema) para esse o usurio, esquema o mapeamento conceitual, o externo/conceitual armazenado. 4. O SGBD executa as operaes necessrias sobre o BD armazenado. Como exemplo, considere as aes relacionadas com a busca de uma determinada ocorrncia de registro externo. Em geral, sero necessrios campos de vrias ocorrncias de registros conceituais e, por sua vez, cada ocorrncia de registro conceitual exigir campos de vrias ocorrncias de registros armazenados. Ento conceitualmente, o SGBD deve primeiro buscar todas as ocorrncias necessrias de registros armazenados, depois construir as ocorrncias de registros conceituais exigidas e, em seguida, construir a ocorrncia de registro externo exigida. Em cada estgio, podem ser necessrias converses de tipos de dados ou outras converses (Date, 2003, p. 37). correspondente,
mapeamento conceitual/interno e a definio do banco de dados
Segundo Silberschatz (2001):

Um Sistema Gerenciador de Banco de Dados (SGBD) constitudo por um conjunto de dados associados a um conjunto de programas para acesso a esses dados. O conjunto de dados, comumente chamado de banco de dados, contm informaes sobre uma empresa em particular. O principal objetivo de um SGBD proporcionar um ambiente tanto conveniente quanto eficiente para a recuperao e armazenamento de informaes do banco de dados. (SILBERSCHATZ; KORTH; SUDARSHAN, 2001, p. 1)
26
Acrescentando, os mesmos autores:

Um SGBD uma coleo de arquivos e programas inter-relacionados que permitem ao usurio o acesso para consultas e alteraes destes dados. O maior benefcio de um banco de dados proporcionar ao usurio uma viso abstrata dos dados. Isto , o sistema acaba por ocultar determinados detalhes sobre a forma de armazenamento e manuteno desses dados. (SILBERSCHATZ; KORTH; SUDARSHAN, 2001, p. 4)
A fim de expor as principais funes e componentes de um SGBD, est a Figura 3:
Figura 3. Principais funes e componentes de um SGBD (Date, 2003, p. 38)
27 A resumir todo o acima explanado importante observar a estrutura de um Sistema Gerenciador de Banco de Dados, que se d da seguinte maneira apresentada na Figura 4:
Figura 4. Estrutura do sistema (SILBERSCHATZ; KORTH; SUDARSHAN, 20012006, p. 18)
28
2.3 BANCO DE DADOS ORACLE

2.3.1 Evoluo Histrica da Oracle O Oracle um sistema gerenciador de banco de dados desenvolvido no final dos anos 70 por Lawrence J. Ellison ao descobrir uma oportunidade no abrangida por outras companhias, por um prottipo funcional de um banco de dados relacional. A Oracle Corporation foi instituda em 1977 e desde ento lder de mercado. A linguagem criada para o processamento de transaes chamada de PL/SQL, e atualmente est-se na verso 11g. Com o passar dos anos, a Oracle desenvolve vrias verses para o banco de dados, as quais sero demonstradas por meio da tabela abaixo:
Verso Oracle 2 Oracle 3
Ano de criao 1979 1981
Caractersticas Primeiro Lanamento Pblico Funcionalidades bsicas SQL (queries and joins) Execuo automtica de instrues SQL Transaes Consultas em bloqueios Estabilidade Cliente-Servidor Consultas distribudas Bloqueio linha-nvel Backup de dados em linha PL/SQL no banco de dados Servidor Paralelo
Oracle 4 Oracle 5.0 Oracle 5.1 Oracle 6
1984 1986
Julho 1988
Oracle 6.1
Tabela 3. Quadro demonstrativo das verses de Banco de Dados Oracle (ORACLE 2 a ORACLE 6.1)
Verso
Oracle 7.0
Ano de criao
Junho Constraints
Caractersticas
29
1992 Oracle 7.1 Oracle 7.2 Oracle 7.3 Armazenamento de funes e padres Triggers Visualizar compilao Manual de funes SQL definidas Segurana Limite de recursos perfis Auditoria reforada Replicao de dados Replicao de dados simtricos Recuperao paralela SQL dinmico DBMS_SQL Consulta e criao de ndices, carregamento de dados Arquivos de dados redimensionvel Subconsulta na clusula FROM Criao de tabelas paralelas ndices bitmap Leitura assncrona das tabelas Opo contexto Introduo Db_verify Trigger compilao, depurao Limitaes de clusulas de extenses Histogramas Dependenciais Oracle Trace
Tabela 4. Quadro demonstrativo das verses de Banco de Dados Oracle ORACLE 7.0 a ORACLE 7.3
Verso Oracle 8.0
Ano de criao Junho 1997
Caractersticas Banco de dados objeto relacional Padro SQL 3 Recuperao de parties individuais Security Server introduzidas pela administrao central do usurio. Termo de senha, senha de perfis, permitem esquema de senha personalizada. Links de banco de dados privilegiado (sem necessidade de senha a ser armazenada) START otimizado de consultas Organizao de tabelas por ndice Verificao de restrio de integridade
30
Oracle 8i (8.1.5) Dados de tinta introduzida na base de dados Novo formato ROWID DML paralela Fuso/parties de equilbrio Pool de conexo para suportar mais usurios simultneos Muitos melhoramentos de desempenho para o SQL/PSQL/OCI fazendo uso mais eficiente da CPU/Memria. V7 limites alargados A recuperao rpida Iniciar Checkpoint taxa de auto ajustada por atender roll Reorganizao de ndices/tabelas de ndices Log Miner introduzidos Permite online ou redo logs arquivados a ser visualizada atravs do SQL Oracle 8i (8.1.6) Oracle 8i (8.1.7) Manual de Segurana Gesto de propriedade de recursos Estatsticas do otimizador Procedimentos armazenados Java (Oracle Java VM) Banco de dados virtual privado Analisar as tabelas em paralelo Dados de espera auto transporte e aplicao de redo logs Tablespaces transportveis entre bancos de dados Drop da coluna na tabela ndices Funcional NLS, maisculas e minsculas DBA Studio introduzida XML Parser para Java Novas funes SQL Comando ALTER FREELISTS Checksums sempre na tablespace SYSTEM Novo PLSQL criptografar/descriptografar Usurios e esquemas separados Muitos aprimoramentos de desempenho Static Servidor HTTP includo Java Server Pages (JSP) motor OIS Oracle Integration Server introduzidas JVM Accelerator para melhorar a performance de cdigo Java PLSQL Gateway introduziu para implementao de PL/SQL solues com base na Web Enterprise Manager Enhancements incluindo novos relatrios baseados
31
em HTML e avanada funcionalidade de replicao includo New Character Database Set utilitrio ed migrao includo Tabela 5. Quadro demonstrativo das verses de Banco de Dados Oracle ORACLE 8.0 a ORACLE 8i (8.1.7) Verso Ano de Caractersticas criao Oracle 9i Release 1 (9.0.1) Junho 2001 Segmentos de reverso tradicional (RBS) Oracle Parallel Servers (OPS) de escalabilidade Consulta Flashback (dbms_flashback.enable), este recurso permitir que os usurios para corrigir as operaes sem chamar o DBA Oracle Ultra Search para pesquisar bancos de dados, sistemas de arquivos VI (Virtual Interface) suporte ao protocolo, uma alternativa para o TCP/IP disponveis para o uso com o Oracle Net (SQL*Net) Minerao de dados Apoio de cursor de rolagem, permite a busca para trs de um conjunto de resultados Gerenciamento de memria dinmica Reorganizao online do ndice Build em XML Developers Kit (XKD), novos tipos de dados para XML (XMLType) Cost Based Optimizer agora considera tambm a memria e CPU, No s custos de acesso do disco Oracle 9i Release 2 (9.2.0) Programas PL/SQL nativa pode ser compilado para binrios Proteo de dados Deep segurana gro fino e de auditoria Separao lista de particionamento de uma lista de valores Oracle Nameserver Gerenciado localmente tablespaces SYSTEM Sistema de arquivos de cluster para Windows e Linux Compresso do segmento de dados (comprimir as chaves nas tabelas apenas quando os dados de carga) Criar bancos de dados standby lgicos com dados da Guarda Melhorias na segurana Default Install contas bloqueadas, VPD em sinnimos, AES, Usurios migrar para o diretrio Tabela 6. Quadro demonstrativo das verses de Banco de Dados Oracle ORACLE 9i Release 1 (9.0.1) a ORACLE 9i Release 2 (9.2.0) Verso Ano de criao Caractersticas
32
Oracle 10g Release 1 (10.1.0) Grid Computing uma extenso da funcionalidade de clustering Melhorias de gerenciamento (self-tuning caractersticas) Melhorias de desempenha e escalabilidade Automated Storage Management (ASM) Automatic Workload Repository (AWR) Automatic Database Diagnostic Monitor (DAMS) Capacidade de Undrop uma tabela a partir de uma lixeira Flashback operaes disponveis em linha, transao, tabela ou banco de dados de nvel Oracle 10g Release 2 (10.2.0) Oracle 10g Express Edition (Oracle XE) Maro 2006 Setembro 2005 Capacidade de transporte de tabela em todos os tipos de mquina Data Pump mais rpido movimento de dados com expdp e impdp Capacidade de mudar o nome de tabela Declarao Nova base de dados drop Novo agendados de banco de dados DBMS SCHEDULER Suporte para espaos de tabela de at 8 exabytes de tamanho As senhas para DB so criptografas Async Asmcmd novo utilitrio para o gerenciamento de armazenamento ASM Liberdade para desenvolver e implementar aplicativos de muitas plataformas Suporte para uma grande variedade de ambientes de desenvolvimento Recursos de performance, confiabilidade e segurana Permite que os desenvolvedores tirem total profeito do Oracle Application Express para rpido desenvolvimento e implementao de aplicativos baseados na Web Tabela 7. Quadro demonstrativo das verses de Banco de Dados Oracle ORACLE 10g Release 1 (10.1.0) a ORACLE 10g Express Edition (ORACLE XE)
Verso Oracle 11g
Ano de criao
Caractersticas Alta capacidade de cluster de banco de dados Acelerao da automao do data Center e o gerenciamento da carga de trabalho Grids seguros, altamente disponveis e escalveis de servidores e armazenamento de baixo custo XML binrio para melhor desempenho de aplicativos Oracle Real Application Testing inovao no teste e gerenciamento de
33
alteraes em ambientes de TI Oracle Data Guard banco de dados em standby com alto desempenho, segurana e recuperao Gerenciamento do armazenamento orientado por regras de negcios possvel atingir ndices de compactao de 2x a 3x ou at mais para todos os dados Registro total de todas as alteraes nos dados Oracle Flashback transaction facilita a reverso de uma transao efetuada com erro, bem como de qualquer transao dependente Parallel Backup and Restore ajuda a melhorar o desempenho do backup e restaurao de bancos de dados grandes Oracle Fast Files armazena grandes objetos Criptografia aparente XML mais rpido Data Recovery Advisor significativamente a ajuda os administradores para recuperao, o a reduzir permite parada que
automatizar investigao de falhas, determinar planos de recuperao e lidar com vrias situaes de crise Novo Compilador Java Just-in-time para executar procedimentos Java no banco de dados mais rapidamente Integrao nativa com o Visual Studio 2005 para desenvolvimento de aplicativos .NET no Oracle; ferramentas de migrao de Acess com Oracle Application Express; e um recurso para fcil criao de consultas do SQL Developer e rpida codificao de rotinas SQL e PL/SQL Hot patching alta disponibilidade do sistema ao permitir que correes sejam aplicadas sem a necessidade de interromper a operao do SGBD Pool de conexes e cachs de resultados das consultas: produtos Query Result Caches e Database Resident Connection Pooling Cubos OLAP incorporados Tabela 8. Quadro demonstrativo das verses de Banco de Dados Oracle ORACLE 11g
34 2.3.2 SGBD Oracle Discorrido sobre os conceitos gerais de banco de dados, sistema gerenciador de banco de dados e evoluo histrica da Oracle, cabe agora ponderar sobre as caractersticas bsicas de um sistema de gerenciamento de banco de dados Oracle. Trata-se de um SGBD relacional de objeto que propicia uma abordagem aberta, ampla e integrada para o gerenciamento de informaes, consistente em um banco de dados Oracle e uma instncia do servidor Oracle. Segundo Lorenzo (2011), o servidor Oracle inclui um sistema de gesto de base de dados relacional (SGBDR) que: Armazena grandes volumes de dados em formato texto ou binrio; Pesquisa dados utilizando tcnicas que minimizam o tempo de acesso; Gere a segurana de acesso aos dados para insero, consulta e alterao de acordo com os perfis definidos para cada utilizador; Mantm a consistncia e integridade dos dados e suas relaes, incluindo mecanismos de arquivo de segurana, bloqueio para alterao e verificao de transao; Permite armazenamento de dados distribudos numa rede, mantendo a integridade das relaes entre os dados; Disponibiliza mecanismos que facilitam o backup/restore dos dados e a sua recuperao em caso de avaria de hardware ou erro humano. Um BD Oracle possui uma estrutura fsica e lgica separadas, onde o armazenamento fsico de seus dados pode ser facilmente gerenciado sem comprometer o acesso s estruturas lgicas de armazenamento. A estrutura fsica de um BD Oracle se determina pelos arquivos do sistema operacional que constituem o BD. Cada banco de dados Oracle formado por trs
35 tipos de arquivos: arquivos de dados, arquivos de registros redo e arquivos de controle. A retratar a arquitetura do Oracle, pode-se verificar a figura a seguir:
Background Processes
System Global Area Banco de Dados

Servers
Redo Log Files
Users Data Files
Control Files
Figura 5. Arquitetura do Oracle
Os arquivos de dados ou datafiles armazenam todos os dados do BD, onde os dados das estruturas lgicas de banco de dados tais como as tabelas e os ndices so armazenados fisicamente nos datafiles alocados para um banco de dados. Contm todos os dados do banco de dados. Os arquivos de registro redo ou redo log files so formados por entradas redo, onde cada qual um grupo de vetores de alterao que descreve uma nica alterao atmica no BD. Contm todas as informaes relativas s alteraes efetuadas no banco de dados para permitir a recuperao. Os arquivos de controle ou control files possuem entradas que especificam a natureza fsica do BD, como nome do BD e nomes e localizaes dos datafiles de um BD e dos arquivos de registro redo. Em resumo, registra a estrutura fsica do banco de dados.
36 A estrutura lgica de um BD determinada por um ou mais tablespaces (rea lgica de armazenamento) e por objetos de esquemas do banco de dados. As estruturas de memria so divididas pela SGA e PGA: SGA (System Global Area): trata-se de uma regio compartilhada de memria reservada pelo SGBD Oracle, que armazena dados e informaes de controle. Assim, quando maior for a SGA, o desempenho ser melhor. Seus dados sero compartilhados por todos os usurios que acessem ao BD, pois esto divididas por tipo de estrutura de memria, incluindo database buffers, redo log buffers e shared poll. PGA (Program Global Area): uma regio de memria que armazena dados e informaes de controle para um processo servidor, sendo criada sempre que um processo servidor seja iniciado. Conforme Sumit (2000):
Toda vez que um banco de dados iniciado, uma system global area (SGA) alocada e os processos de segundo plano do Oracle so iniciados. A system global rea uma rea da memria usada para as informaes do banco de dados que so compartilhadas pelos usurios. A combinao entre os processos de segundo plano e os buffers de memria se chama instncia do Oracle (SUMIT, 2000, p. 529).
A cerca dos processos, so divididos em: processos usurio e processos do Oracle. Onde cada usurio conectado possui um Processo Usurio, atravs do qual se comunica com o Oracle. Entre os processos do Oracle esto os Processos Servidores, que executam as solicitaes emitidas pelos Processos Usurios, e os Processos Background. A fim de resumir o acima explanado, um BD Oracle uma coleo de dados tratada como unidade capaz de armazenar e recuperar as informaes relacionadas. Um banco de dados Oracle pode ser aberto (acessvel) ou fechado (no acessvel). Em situaes normais, o BD aberto e disponibilizado para o uso, em outras ocasies
37 fechado para as funes administrativas especficas que exigem que os bancos de dados estejam indisponveis aos usurios. A finalizar, est a tabela abaixo que demonstra quais os tipos de dados suportados pelo Oracle:
Tabela 9. Tipos de dados suportados pelo Oracle
Retratado sobre os principais assuntos atinentes matria que abrange o tuning, passa-se ento ao seu contedo e entendimento da matria propriamente dita, em nosso prximo capitulo, tratando inicialmente da linguagem SQL e aps abordando as principais caractersticas sobre tuning.
38
3. METODOLOGIA DE TUNING
Neste captulo sero abordados os conceitos sobre a linguagem SQL; tuning, esta passando por sua arquitetura, topologia, vantagens e desvantagens. Tambm abordar-se- sobre otimizao, suas tcnicas e implementao, bem como sobre o BD Oracle 11g.
3.1 LINGUAGEM SQL
Antes de iniciar-se a discusso sobre tuning, imprescindvel tambm discorrer sobre a importncia da linguagem SQL, uma vez que por meio desta o desenvolvimento do tuning. O SQL a linguagem de programao que define e manipula o BD, como so relacionais, so armazenados em um conjunto de relaes simples, podendo conter uma ou mais tabelas, com colunas e linhas, nos permitindo definir e manipular os dados de uma tabela com os comandos SQL. Apenas uma declarao SQL completa pode ser executada. O SQL (Structured Quey Language Linguagem Estruturada de Consulta) baseado no modelo relacional, mas pode ser adaptada a qualquer ambiente no relacional, foi desenvolvida nos anos 70, inicialmente proposta por E. F. Codd. Vrias so as vantagens e desvantagens para utilizao da linguagem SQL, no quadro abaixo apresenta-se algumas delas:
VANTAGENS
DESVANTAGENS
Por ser uma linguagem padronizada Diante da padronizao, impossibilita o pode ser utilizada em quase todos os desenvolvimento de solues, melhorias SGBD relacionais. ou alteraes.
39 Pode ser utilizada em computador Falta de ortogonalidade nas expresses, pessoal, mainframe ou computadores funes embutidas, variveis indicadoras, de trabalho de mdio porte. referncia a dados correntes, constante NULL, conjuntos vazios, etc. Possibilita acesso rpido aos dados, Definio formal da linguagem aps sua reduo facilidade (simplicidade). de custo, diante de de sua criao; discordncia entre as linguagens erros, etc.
Tabela 10. Vantagens e desvantagens do SQL
manipulao hospedeiras; falta de algumas funes;
As funes do SQL se dividem em duas categorias, quais sejam: DDL e DML. A DDL: uma linguagem de definio de dados, que permite criar, modificar e excluir a estrutura de uma tabela e seus ndices, ou seja, o SQL inclui comandos para criao de objetos no BD como tabelas, ndices, e visualizaes, e comandos para definir direitos de acesso a esses objetos. Alguns comandos desta linguagem so: 1. CREATE SCHEMA AUTHORIZATION: Cria um esquema de banco de dados. 2. ALTER TABLE: Modifica uma definio de tabelas (adiciona, modifica ou exclui atributos ou restries). 3. DROP INDEX: Exclui um ndice de forma permanente. A DML: uma linguagem de manipulao de dados, o SQL inclui comandos para inserir, atualizar, excluir e recuperar dados em tabelas de bancos de dados. Alguns comandos desta linguagem so: 1. INSERT: Insere linhas em uma tabela. 2. SELECT: Seleciona atributos a partir de linhas de uma ou mais tabelas ou visualizaes.
40 3. WHERE: Restringe a seleo de linhas com base em uma expresso condicional. 4. DELETE: Exclui uma ou mais linhas de uma tabela. 5. ROLLBACK: Restaura os dados a seus valores originais. Segundo Rob e Coronel (2011), O corao do SQL a consulta. [...] no ambiente do SQL, a palavra consulta inclui tanto perguntas como aes (p. 242). Apesar da extrema importncia desta referida linguagem nos dias atuais e de sua imprescindibilidade para o tema objeto da presente pesquisa, ater-se- a apenas destacar suas principais caractersticas. Portanto, agora j discutido sobre os aspectos principais sobre a linguagem SQL, direciona-se o presente trabalho ao assunto principal, qual seja, o tuning.
3.2 FUNDAMENTAO TERICA SOBRE TUNING
A fim de retratar o tema objeto desta pesquisa, imprescindvel destacar as sbias e consistentes palavras de Rob (2011):
Uma das principais funes de um sistema de banco de dados fornecer resposta aos usurios finais dentro de um tempo adequado. Os usurios interagem com o SGBD por meio de consultas que geram informaes, utilizando a seguinte sequncia: 1. A aplicao do usurio final (extremidade do cliente) gera uma consulta. 2. A consulta enviada ao SGBD (extremidade do servidor). 3. O SGBD (extremidade do servidor) executa a consulta. 4. O SGBD envia o conjunto de dados resultante para a aplicao do usurio final (extremidade do cliente). [...] o objetivo do desempenho de banco de dados executar as consultas o mais rpido possvel. Portanto, esse desempenho deve ser
41
estritamente monitorado e passar por sintonizaes regulares. A sintonizao de desempenho de banco de dados refere-se a um conjunto de atividades e procedimentos projetados para reduzir o tempo de resposta de um sistema de banco de dados (ROB; CORONEL, 2011, p. 470/471) (grifou-se).
A alta competitividade do mercado atual faz com que as empresas adotem, cada vez mais, sistemas de informao que lhes proporcionem apoio e melhoria a seus processos. Neste aspecto surge a necessidade de utilizao dos SGBD a fim de armazenar e gerenciar informaes e proporcionar que estejam disponveis de maneira eficaz e gil, em resposta s consultas realizadas pelos usurios. No entanto, em sua maioria, os SGBDs no so perfeitos, e portanto, necessitam de tcnicas de otimizao, de aperfeioamento de seu funcionamento interno. Assim, tratar-se- na prxima subseo dos conceitos gerais sobre tuning, para melhor entendimento desta tcnica mencionada.
3.2.1 Conceitos gerais sobre Tuning

O termo tuning pode ser interpretado como ajustar, sintonizar, a fim de melhorar o desempenho. Assim, pode-se definir tuning como capaz de ajustar partes das aplicaes do Sistema de Gerenciamento de Banco de Dados, transaes do BD ou usabilidade das Redes. Portanto, tuning diz respeito ao ajuste do Sistema de Gerenciamento de Banco de Dados. Neste sentido, Ikematu (2007) afirma que tuning da base de dados, pode ser entendida como uma customizao do sistema sob medida para que a performance atenda melhor as suas necessidades. Como outra definio pode-se adotar as palavras de Sousa (2011):
42
O termo tuning, que traduzido friamente significa sintonia, encaixou-se no cenrio de tecnologia a partir do momento em que somaram-se: o uso das informaes armazenadas para tomadas de decises gerenciais estratgicas, mais o aumento no volume de dados consideravelmente, mais a preocupao com a velocidade do tempo de resposta. A soma desses trs requisitos fizeram com que se intensificassem os estudos sobre aumento de desempenho e surgisse ento a valorizao da sintonia e do refino do banco de dados. (SOUZA, 2011, p. 30)
O tuning utilizado e recomendado para reduzir custos, trazer agilidade, aumento de produtividade e segurana, garantindo a integridade do SGBD. muito importante para o sucesso de todo o processo. De acordo com Hiratsuka (2012):
O termo performance, ou desempenho, como preferir, uma palavra-chave quando se fala em aplicaes de banco de dados, pois no s se quer obter resultados confiveis, como necessrio que os mesmos sejam oferecidos em tempo hbil. Com o desenvolvimento das novas tecnologias de computador, os sistemas se tornaram mais complexos. Mais dados precisam ser gerenciados, consultas mais complexas precisam ser processadas, caractersticas para a utilizao de redes de computadores devem ser incorporadas s aplicaes, fazendo com que os problemas de performance tornem-se mais frequentes (HIRATSUKA, 2012, p. 01).
Conforme retratado por Souza (2009) apud Peixoto Jnior e Carvalho (2008), profissionais com experincia em BD constataram que 45% (quarenta e cinco por cento) das aes de tuning so destinadas a configurao do Sistema Operacional, 35% destinadas configurao do SGBD e 20% destinadas ao refinamento das consultas, conforme figura abaixo:
43
Figura 6. Fases do Tuning (Souza (2009), et al apud Peixoto Jnior e Carvalho(2008))
Adota-se as palavras de Castro (2011) a fim de demonstrar os principais objetivos do tuning, quais sejam:
- estruturas SQL acessem o menor nmero possvel de blocos no database - os blocos de dados (disponveis /exigidos) para futuro uso so carregados na memria quando requisitados pelos usurios e que os blocos lidos pelo full table scan so removidos da memria para ajuda a liberar espao na memria - estruturas de memria sejam grandes o suficiente para dados cache na memria por um perodo mais longo de tempo - usurios compartilhem cdigos SQL nas reas de memria, a fim de evitar o REPARSING das estruturas - processos de leitura e escrita sero realizados de forma mais rpida quanto possvel - minimizar a concorrncia entre os recursos (CASTRO, 2011, p. 01).
Cabe destacar que para se verificar a eficincia do tuning, importante que a rede seja confivel e rpida, caso contrrio no ser obtido o resultado esperado, outro ponto que tambm deve ser levado em considerao fluxo de dados que circunda a rede, pois quanto menor, melhor ser o desempenho. O tuning envolve em sua realizao os administradores de banco de dados, administradores de sistemas e desenvolvedores de aplicao, que se procede da maneira exposta na tabela abaixo:
44
Figura 7. Responsveis pelo tuning
Geralmente o tuning iniciado durante a fase de aceitao do sistema, pelo fato de os problemas de desempenho estar mais visveis, mas deve ser realizado em todas as fases (projeto, desenvolvimento e produo). Portanto, para a realizao do tuning necessrio a realizao de cinco passos primordiais para a execuo no servidor, como: Checagem da arquitetura e designo do modelo de dados do servidor; Checagem das aplicaes do BD, definindo design eficiente para a linguagem SQL; Checagem das estruturas de memria e tuning do SQL e user memory; Tuning I/O, com monitoramento de distribuio do BD, tipos de segmentos e tablespaces nas operaes I/O; Tuning OVERALL MEMORY, para garantia das reas de memria que so utilizadas de maneira eficiente. Neste mesmo sentido, Ikematu (2007), que frisa a relevncia do tuning, sendo necessria a preparao de uma estratgia de performance quando da elaborao do projeto, pois no momento em que os usurios comearem a perceber os
45 problemas quanto ao desempenho da aplicao, j ser tarde para empregar algumas das tcnicas do tuning e enquanto outras tcnicas somente podero ser implementadas se o referido projeto tenha sido bem elaborado, mesmo a performance de um sistema bem projetado pode degradar com o uso, da a sua importncia de realizao do tuning em todas as fases do sistema e para sua manuteno. Adotando os pensamentos de Carneiro et al (2006):
Aps um banco de dados ter sido desenvolvido e estar em operao, o uso real das aplicaes, das transaes, das consultas e das vises revela fatores e reas de problemas que podem no ter sido considerados durante o projeto fsico inicial. As informaes de entrada para o projeto fsico podem ser revisadas por meio da coleta de estatsticas reais sobre os padres de uso. A utilizao dos recursos, bem como o processamento interno do SGBD pode ser monitorado para revelar gargalos, tais como a disputa pelos mesmos dados ou dispositivos. Os volumes de atividades e os tamanhos dos dados podem ser bem mais estimados. (CARNEIRO, et al, 2006, p. 02)
Conforme se pode verificar no decorrer do presente trabalho, refere-se sempre a um banco de dados Oracle, portanto, trata-se do tuning com bases de dados em ORACLE. Novamente, toma-se por base os notveis ensinamentos de Hiratsuka (2012), o qual define que para o alcance de bons resultados na performance tuning, necessrio seguir alguns procedimentos, os quais se do pela forma apresentada, respectivamente:
46
Figura 8. Metodologia para tuning (baseado no artigo cientfico de Hiratsuka, disponvel em: http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=1681))
3.2.1.1 Sintonia de ndices
A opo inicial de ndices pode necessitar de uma reviso, pelos seguintes fatos: algumas consultas podem demorar maior tempo para serem executadas diante da ausncia de um ndice, alguns ndices podem, no ser usados e certos ndices podem ocasionar sobrecarga exagerada por serem baseadas em um atributo que invariavelmente sofre alteraes. Segundo Rob e Coronel (2011), os ndices so fundamentais para acelerar o acesso aos dados, pois facilitam a busca, classificao e utilizao de funes agregadas e, at mesmo, de operaes de juno. (p. 480) Acrescentam ainda que, a melhoria da velocidade de acesso aos dados se deve ao fato de que o ndice ser um conjunto ordenado de valores que contm a chave de ndice e ponteiros. (ROB, Peter; CORONEL, Carlos, 2011, p. 480)
47 Muitos dos SGBDs possuem ou um comando ou um meio de rastreamento que pode ser utilizado para requisitar que o sistema revele como a consulta foi executada, as operaes realizadas, e a ordem e estruturas de acesso. Diante da anlise destes planos de execuo possvel diagnosticar os motivos dos problemas citados. Certos ndices podem ser excludos e outros novos podem ser criados diante da anlise de sintonia. A finalidade da sintonizao a avaliao dinmica dos requisitos, que podem variar durante os diferentes perodos de ms e semana, podendo reorganiz-los a fim de proporcionar a melhor performance possvel. As excluses e criaes dos novos ndices so justificadas em funo desta melhoria de desempenho, e a atualizao de uma tabela normalmente suspensa enquanto o ndice for excludo ou criado. A importncia do ndice se d pelo fato de que a sua varredura mais eficiente que a varredura completa de uma tabela, uma vez que os dados apresentados no ndice encontram-se preordenados e sua quantidade, na maioria das vezes, relativamente menor. Assim, ao se executar buscas quase sempre melhor que o SGBD utilize-se dos ndices para acesso a tabelas e no pela varredura completa.
3.2.1.2 Sintonia de consultas
O monitoramento e a sintonia de consultas SQL uma tarefa que retira grande tempo dos DBAs, haja vista a complexidade e por ser a maior parte dos acessos realizados no Sistema Gerenciador de Banco de Dados, no entanto, como j tratado neste trabalho, muitas as vezes, os sistemas no apresentam o desempenho esperado, seja pela falta de experincia no desenvolvimento, seja pelo nvel baixo de conhecimento tcnico, seja pelos prazos de entrega subdimensionados, seja pela ausncia de monitoramento individual que, por consequncia, tornam as consultas ineficientes. O otimizador ir determinar um plano de execuo partindo de uma consulta SQL, com margem limitada de opes sobre a utilizao de operadores. Se a consulta SQL for mal elaborada, o otimizador ir se valer de um caminho nem sempre
48 adequado e ir desencadear um plano de execuo que poder vir a comprometer o desempenho. Em circunstncias onde so realizadas muitas consultas mal escritas,
frequentemente pode gerar consequncias drsticas, atrapalhando a utilizao eficiente dos recursos disponveis e deixando de atender, em momento oportuno os processos urgentes de execues rpidas e prioritrias. Neste contexto, Carneiro et al (2006) faz-se valer das sbias palavras de Navathe (2006), onde expe:
Desta forma existem algumas tcnicas utilizadas pelos administradores de banco de dados a fim de alcanar desempenho. A justificativa para se usar a tcnica de reescrita de consultas como uma das primeiras a ser utilizada, que essa tcnica afeta apenas uma consulta especfica, no se propagando para outras aplicaes que acessam as tabelas envolvidas na instruo SQL (CARNEIRO, et al, 2006, p. 04).
Complementando, Carneiro (2006) cita alguns critrios que podem ser utilizados quando da identificao de consultas que necessitem ser modificadas como: Monitorar as sesses ativas que esto sendo executadas no banco de dados; Separar demoradas; Dividi-las em grupos, como: prioridade, frequncia de execuo e fraco desempenho; Implementar os ajustes reescrevendo as consultas que esto com fraco desempenho. Cada banco de dados fornece suas ferramentas especficas para capturar as consultas citadas nos itens acima, porm a maneira mais eficiente e explcita o prprio uso feito pelo usurio final. (CARNEIRO, 2006, p. 04). as consultas que esto com execues
49
3.3 OTIMIZAO
3.3.1 Conceito e funo Date (2003) apresenta conceituao otimizao da seguinte maneira:
A otimizao representa ao mesmo tempo um desafio e uma oportunidade para sistemas relacionais: um desafio, por que a otimizao uma exigncia, caso o sistema espera atingir um desempenho aceitvel; uma oportunidade, pois precisamente um dos pontos fortes da abordagem relacional o fato de que as expresses relacionais esto em um nvel semntico suficientemente alto para a que a otimizao seja vivel em primeiro lugar. Ao contrrio, em um sistema no relacional, em que requisies dos usurios so expressas em um nvel semntico mais baixo, qualquer otimizao deve ser feita manualmente pelo usurio. E, se, o usurio tomar uma deciso equivocada no haver nada de que o sistema possa fazer para melhorar a situao (DATE, 2003, p. 456)
Acrescenta ainda, o mesmo autor:
[...] O otimizador um programa; assim, por definio, muito mais paciente que um usurio humano tpico. O otimizador capaz de considerar literalmente centenas de estratgias de implementao diferentes para requisio, enquanto extremamente improvvel que um usurio sequer levasse em considerao mais de trs ou quatro (pelo menos com alguma profundidade). Por fim, o otimizador pode ser considerado, em certo sentido, como a incorporao dos conhecimentos e servios dos melhores programadores. [...] (DATE, 2003, p. 457).
A otimizao tem como principal objetivo permitir que as aplicaes passem por tempos de respostas mais curtos com reduo do uso de recursos do BD, e
50 consequentemente, outras aplicaes do BD tambm sero influenciadas com o ganho de performance.
3.3.2 Aspectos gerais De modo simplificado, a otimizao pode ser entendida como eliminao de ndice ineficiente, pela implementao de novos filtros ou alteraes de parmetros. De acordo com Silberschatz et al (2001):
O custo do processamento de uma consulta determinado pelo acesso ao disco, que lento se comparado ao acesso memria. Normalmente, h muitas estratgias possveis para processar uma determinada consulta, especialmente se a consulta for complexa. A diferena entre uma estratgia boa e uma estratgia ruim, em termos do nmero de acessos de discos exigidos, frequentemente significativa, e pode ser de grande magnitude. Consequentemente, vale a pena para o sistema ganhar uma quantia significativa de tempo na seleo de uma estratgia boa para processar uma consulta, at mesmo se a consulta for executada somente uma vez (SILBERSCHATZ; KORTH; SUDARSHAN, 2001, p. 381).
Obviamente o sistema ter melhor funcionamento com seus recursos otimizados, com componentes de sistema suficientes para tanto. Neste sentido, Rob et al (2011) apresenta tabela que demonstra as diretrizes gerais para melhor desempenho do sistema, com requisitos bsicos para hardware e software, quais sejam:
RECURSOS DO SISTEMA O mais rpido possvel Hardware CPU RAM CPU superior O mximo possvel dual core ou O mais rpido possvel Vrios processadores (tecnologia quadcore) O mximo possvel CLIENTE SERVIDOR
51
Disco rgido SATA/EIDE Disco Rgido Rede rpido, como espao livre suficiente. Conexo velocidade Sintonizao Software Sistema Operacional Rede Aplicao melhor fina para de para de em Sintonizao fina para melhor desempenho fina taxa SQL desempenho de aplicaes de servidor Sintonizao fina para melhor taxa de transmisso Otimizar servidor de SGBD para o melhor desempenho de alta Vrios discos rgidos de alta velocidade e capacidade (SCSI / SATA / Firewire / Fibre Channel) em configurao RAID Conexo de alta velocidade
aplicaes de cliente Sintonizao melhor transmisso Otimizar aplicaes de cliente
Tabela 11. Diretrizes Gerais para melhor desempenho do sistema (ROB; CORONEL, 2011, p. 471)
Mas da mesma forma, deve-se entender que, normalmente estando diante de recursos limitados, com restries tanto internas como externas, portanto, necessrio trabalhar com o que se tem, otimizando os recursos existentes para o melhor desempenho possvel, da a motivao para a realizao da otimizao e do tuning. Neste sentido esto os ensinamentos de Silberchatz et al (2006), quando o mesmo resume sucintamente os procedimentos a serem realizados para a execuo de uma consulta e a ocorrncia da otimizao:
A primeira ao que o sistema tem de executar em uma consulta traduzir a consulta para sua forma interna, que (para sistemas de bancos de dados relacionais) normalmente baseada na lgebra relacional. No processo de gerao da forma interna da consulta, o analisador sinttico verifica a sintaxe da consulta do usurio, verifica se os nomes das relaes que aparecem na consulta so nomes de relaes no banco de dados e assim por diante. Se a consulta foi expressa em termos de uma viso, o analisador sinttico substitui todas as referncias ao nome pela expresso da lgebra relacional para obter a viso. Dada uma consulta, geralmente h uma variedade de mtodos para chegar resposta. responsabilidade de o
52
sistema transformar a consulta, de acordo com o que foi fornecido pelo usurio, em uma consulta equivalente que pode ser calcula mais eficientemente. Essa otimizao ou, mais precisamente, essa melhoria da estratgia de processamento de uma consulta chamada de otimizao de consulta (SILBERSCHATZ; KORTH; SUDARSHAN, 2001, p. 433/434).
Conforme j mencionado no incio do captulo, as atividades de sintonizao sero desempenhadas por vrias pessoas, mas em geral, pode-se divid-las em cliente e servidor, da seguinte maneira: Para o cliente, o objetivo criar uma consulta de SQL que retorne a resposta correta no menor espao de tempo possvel, com a quantidade mnima de recursos do servidor. Essa atividade necessria para alcance da meta descrita nomeada como sintonizao de desempenho de SQL. Para o servidor, o ambiente de DGBD deve ser configurado adequadamente para atender as solicitaes/consultas dos clientes no menor perodo de tempo, por meio dos recursos existentes. As atividades necessrias para atingir essa fase so designadas como sintonizao de desempenho de SGBD. Para se ter uma viso geral a cerca do processamento de consultas, cabe destacar seus quatro estgios da otimizao, que se do na respectiva ordem: Converso da consulta em alguma forma interna (geralmente, uma rvore de consulta ou uma rvore de sintaxe abstrata ou simplesmente como forma interna da lgebra relacional ou do clculo relacional); Coverso para a forma cannica, usando diversas leis de transformao; Escolha de procedimentos de baixo nvel candidatos para implementao de diversas operaes na representao cannica da consulta; E por fim, Criar planos de consulta e definir o mais econmico, atravs da utilizao de frmulas de custo e cincia das estatsticas do BD. A demonstrar o contedo acima exposto, cabe ilustrar com a figura abaixo, conforme preordenado por Date (2003):
53
Figura 9. Viso Geral do processamento de consultas (DATE, 2003, p. 459).
Segundo Souza (2007):
Aps o otimizador cumprir a sua funo de buscar o melhor desempenho para execuo da expresso proposta, enviado ento ao gerador de registros, que ir executar o plano de execuo, e por fim, pass-lo para o executor de SQL, que por sua vez ir apresentar o resultado final.
A fim de entender passo a passo tais procedimentos abre-se ainda tpico especfico a cerca do plano de execuo e otimizador de consultas, em seguida, o tema ser delimitado ao otimizador do Oracle, na verso 11g.
3.3.3 Plano de execuo Neste momento tratar-se- de demonstrar o que o plano de execuo e para que serve, nos moldes de um SGBD Oracle. O plano de execuo de uma instruo SQL uma sequncia de operaes que o Oracle realiza para executar uma instruo (PRADO, 2010, p. 03).
54 exibido na forma de rvore de linhas, com as informaes de ordenao de tabelas descritas na instruo, qual o mtodo de acesso s tabelas, mtodo join para as tabelas comprometidas pelas operaes, operaes de dados, otimizao, particionamento e execuo paralela, entre outras. No entanto, frisa Prado (2010), que:
O Plano de execuo, por si s, no pode diferenciar instrues bem tunadas daquelas que no apresentam boa performance. O acesso a dados por meio de ndices normalmente mais rpido que acesso full table scan, em ambientes OLTP, porm o fato do plano de execuo utilizar um ndice em algum passo da execuo no necessariamente significa que a instruo ser executada eficientemente. Em alguns casos, ndices podem ser extremamente ineficientes. Quando uma consulta ir retornar mais que 20% dos dados de uma ou mais tabelas ou quando uma consulta ir acessar tabelas pequenas (com poucas linhas), geralmente mais rpido o acesso full table scan do que o acesso atravs de ndices (index lookup). (PRADO, 2010, p. 04)
Nestes termos, embora o otimizador geralmente seja eficiente, em certos casos pode no realizar a melhor escolha do plano de execuo, principalmente pelo fato de que o mesmo toma decises a partir das estatsticas existentes, e se estas forem antigas, desatualizadas, ou mesmo atualizadas, a escolha do otimizador pode no ser a mais eficiente e ento o usurio poder alterar o modo do otimizador.
3.3.4 Otimizador de Query Segundo Prado (2010), o otimizador de consultas Oracle estabelece, de forma dinmica qual o plano de execuo SQL mais eficiente para o caso especifico, considerando os caminhos acessveis e as informaes fundadas em estatsticas de objetos de tabelas ou ndices acessados.
55 Muitas vezes, o otimizador pode se valer do uso de hints, que servem como instrues ao otimizador, como comentrios, que podem ou no serem adotados, fornecendo determinado caminho de acesso, ndice, etc. Este ser o objetivo do otimizador, na escolha do caminho mais pertinente para execuo da instruo, com a utilizao da quantidade menor de recursos possvel e em menor tempo de resposta. Neste sentido Rob e Coronel (2011), ao expor:
Durante a otimizao de consultas, o SGBD deve escolher quais ndices utilizar, como executar operaes de juno, qual tabela utilizar primeiro, etc. cada SGBD possui seus prprios algoritmos para a determinao do modo mais eficiente de acessar os dados. As duas abordagens mais comuns so a otimizao com base em regras e a com base em custos. O otimizador com base em regras utiliza regras e pontos
preestabelecidos para determinar a melhor abordagem de execuo de uma consulta. As regras atribuem um custo fixo a cada operao de SQL. Os custos so, em seguida, somados para produzir o custo do plano de execuo. O otimizador com base em custos utiliza algoritmos sofisticados com
base em estatsticas sobre os objetos a serem acessados para determinar a melhor abordagem de execuo de uma consulta. Nesse caso, o processo do otimizador soma os custos de processamento de E/S e de recursos (RAM e outros espaos temporrios) para obter o custo total de determinado plano de execuo. (ROB & CORONEL, 2011, p. 493)
De acordo com Prado (2010, p. 05), escolhido o melhor plano de execuo o otimizador baseia-se basicamente em trs tipos de medidas: seletividade, cardinalidade e custo. Seletividade: frao de linhas de um conjunto de linhas tal como uma tabela, viso ou resultado de uma ligao (join) ou operador GROUP BY.
56 Cardinalidade: nmero de linhas em um conjunto de linhas, tal como uma tabela, viso ou resultado de uma ligao (join) ou operador GROUP BY. Custo: unidade de trabalho ou recursos utilizados para execuo da instruo SQL como plano particular, com envolvimento de I/O, CPU e memria. Decorrida esta fase, determinando-se o plano de execuo, o otimizador ir criar um conjunto de planos para a instruo SQL conforme os caminhos de acesso e hints, estimando-se o custo de cada plano de acordo com as estatsticas do dicionrio de dados para a distribuio de dados e caractersticas de armazenamento das tabelas, ndices e parties acessadas pela instruo. Ao final, depois de comparar os planos realizar a escolha do plano de menor custo.
57
4. PROPOSTA DE TRABALHO
Segundo Andrade (2005):
Antes de encontrar nas consultas SQL o responsvel por todos os problemas de desempenho, vital saber se realmente h problemas de desempenho. Se realmente existe, preciso identificar corretamente a causa do problema. Uma vez verificado que realmente h problemas nas consultas base de dados preciso san-los. E realmente consultas SQL so responsveis por boa parte dos problemas de desempenho das aplicaes que utilizam banco de dados. (ANDRADE, 2005, p. 12)
Neste contexto, apresenta-se a seguinte proposta de trabalho: Propostas de tunnig em escritas de consultas SQL;
As ferramentas para tuning utilizadas no banco de dados Oracle: o Explain Plan; o SQL Loader; o TKPROF; Regras de Otimizao versus custo da otimizao; Tuning em ndices e mtodos bsicos de acessos; Influncia do otimizador de cdigos; Tcnicas de Tuning em views materializadas e tabelas temporrias; Tuning com base em tcnicas alternativas de armazenamento de dados; O tuning ligado as consultas DML; O tuning em Joins e Agrupamentos de Consultas;
58
5. ESTUDO DE CASO
Uma vez discorrido sobre os conceitos gerais de BD, SGBD, bem como sobre o Oracle, especificamente sobre a verso 11g, e tuning, no presente captulo cabe to somente desenvolver as propostas para instrues DML no BD mencionado, e realizar as implementaes e testes cabveis. Iniciando-se a implementao do estudo de caso, parte-se dos downloads necessrios quanto aos aplicativos para o desenvolvimento das tcnicas de tuning, com as descries de cada um dos utilizados, bem como a localizao de sua disponibilidade, quais sejam:
Virtual
BOX
(Verso
4.1.20
r80170).
Disponvel
em:
http://www.oracle.com/technetwork/serverstorage/virtualbox/downloads/index.html. Banco de dados ORACLE DATABASE EXPRESS edition 11g Release 2. Disponvel
urceSiteId=ocomen.
em:
http://www.oracle.com/technetwork/products/expressedition/downloads/index.html?ssSo
Sql-Developer. Disponvel em:
http://www.oracle.com/technetwork/developer-
tools/sql-developer/downloads/index.html. Appliance. vm-161299.html. Disponvel em:
http://www.oracle.com/technetwork/database/enterprise-edition/databaseappdev-
5.1 Criao do modelo fsico (modelagem e normalizao): Parte-se da criao dos tablespaces da aplicao do Banco de Dados.
59 Para ganho de tunning na aplicao, necessria a criao de tablespaces diferentes para dados e ndices, como recomendao prpria da Oracle, tem-se que destacar que nesta criao, no obteve-se resultados satisfatrios, mas to somente diferenas de respostas de processamento ao criar a tablespaces de ndices com tamanho de blocos de 32 kbytes (o padro do banco de dados instalado de blocos de 8 kbytes, tamanho definido de blocos do tablespaces de dados). Assim, segue-se os scripts utilizados para criao das tablespaces conforme j exposto:
Figura 10. Script para criao da tablespaces de dados
Figura 11. Script para criao da tablespaces de ndices
Figura 12. Script para criao do usurio do banco de dados e grants
5.1.1 Estrutura fsica das tablelas do schema ECOMMERCE_I
Para a estrutura fsica das tabelas para testes de performance e para melhor entendimento do tunning em consultas DML, foram criadas 6 tabelas, como um sistema bsico de ECOMMERCE_I, e insero de informao nas tabelas, os quais se deram da seguinte maneira como apresentado nas figuras abaixo:
60
Figura 13. Conexo com o Banco de Dados
Figura 14. Schema criado ECOMMERCE_I
61
Figura 15. Tabelas para testes de tuning
5.2 Estatsticas no RDBMS Oracle O otimizador um programa que realiza as transformaes de instrues DML em planos de execuo. Com a verso do Oracle 7 introduziu-se o CBO (Cost Based Optimizer), que se baseia-se no custos das operaes, nas verses 10 G e 11 G, o processo ficou default no Oracle, por meio da tarefa que rodada no banco entre as 22:00 horas e 02:00 horas, somente se o banco de dados estiver ocioso, com baixo processamento. Tal tarefa se mostra importante, logo pensando em um banco de dados 24x7, onde essas estatsticas estaro desatualizadas. De acordo com LEWIS (2005), o CBO gera suas estimativas para acesso aos dados baseado nas mtricas de custo, cardinalidade e seletividade, sendo influenciado por parmetros, estatsticas e hints (diretivas de compilao). Da a importncia de se entender como as statistics funcionam e auxiliam o CBO na gerao do plano de execuo.
62 Com isso, se o banco de dados tiver uma estatstica desatualizada haver perda no desempenho das instrues. Como apenas foram criadas tabelas e gerados processo de carga automtica nas tabelas, as estatsticas esto zeradas, conforme segue:
Figura 16. Estatsticas no RDBMS da tabela Cliente
A fim de contornar tal situao, pode-se rodar o processo de estatstica, conforme o script abaixo:
Figura 17. Script DBMS_STATS
63 Este script tem a funo de atualizar todas as estatsticas do schema passado por parmetro, atravs da chamada da package core DBMS_STATS, que chama a procedure core GATHER_SCHEMA_STATS que tem a funo de coletar estatsticas dos objetos. A procedure recebe os parametros owname (nome do schema), cascade (com a opo TRUE que ir gerar estatsticas de tabelas e ndices, todos os objetos adjacentes) e options (caso tenha um banco de dados 24x7 com tamanho relativamente grande, deve-se ter cuidado ao gerar estatsticas para todos os objetos, pois isso afetaria o desempenho do mesmo, como o banco trabalhado possui poucos dados, a opo GATHER AUTO, tem a funo de deixar o banco atualizar todas as estatsticas desatualizadas).
Figura 18. Terminada a coleta de estatstica das tabelas
Figura 19. Tabela Atualizada
64 Para teste realizou-se uma pequena instruo, utilizando-se do SQL PLUS no Linux, ativando os parmetros de timing e autotrace para verificao do tempo de processamento e seus passos, como segue:
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> set timing on SQL> set autotrace traceonly SQL> select * from ecommerce.produto p, ecommerce.item_pedido ip where p.cd_produto = ip.cd_produto; SQL> / 1138048 rows selected. Elapsed: 00:00:21.92 Execution Plan ---------------------------------------------------------Plan hash value: 1270662005 -------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU) | Time | -------------------------------------------------------------------------------| 0 | SELECT STATEMENT | 00:00:01 | | | 1 | NESTED LOOPS | | | 1 | 246 | 2 (0)
| 2 | NESTED LOOPS | 00:00:01 | 3 | TABLE ACCESS FULL | | 00:00:01 | |* 4 | INDEX UNIQUE SCAN | 00:00:01 |
1 | 1 |
246 | 52 |
2 2
(0) (0)
| ITEM_PEDIDO |
| PK_PRODUTO
1 |
(0)
| 5 | TABLE ACCESS BY INDEX ROWID| PRODUTO | 00:00:01 |
1 |
194 |
(0)
-------------------------------------------------------------------------------Predicate Information (identified by operation id): --------------------------------------------------4 - access("P"."CD_PRODUTO"="IP"."CD_PRODUTO") Statistics ---------------------------------------------------------0 recursive calls 0 db block gets 1292447 consistent gets 0 physical reads 0 redo size 111869380 bytes sent via SQL*Net to client 1517817 bytes received via SQL*Net from client 75871 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1138048 rows processed
Figura 20. Antes de gerar as estatsticas
65
SQL> select * from ecommerce.produto p, ecommerce.item_pedido ip where p.cd_produto = ip.cd_produto; SQL> / 1138048 rows selected. Elapsed: 00:00:21.21 Execution Plan ---------------------------------------------------------Plan hash value: 1792694285 --------------------------------------------------------------------------------| Id | | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
--------------------------------------------------------------------------------| | |* | | | | | 0 | SELECT STATEMENT | | 1138K| 93M| 798 (2)| 00:00:10
1 |
HASH JOIN
1138K|
93M|
798
(2)| 00:00:10
2 |
TABLE ACCESS FULL| PRODUTO
5 |
365 |
(0)| 00:00:01
3 |
TABLE ACCESS FULL| ITEM_PEDIDO |
1138K|
14M|
791
(2)| 00:00:10
--------------------------------------------------------------------------------Predicate Information (identified by operation id): --------------------------------------------------1 - access("P"."CD_PRODUTO"="IP"."CD_PRODUTO")
Statistics ---------------------------------------------------------0 recursive calls 0 db block gets 1292447 consistent gets 0 physical reads 0 redo size 111869380 bytes sent via SQL*Net to client 1517817 bytes received via SQL*Net from client 75871 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1138048 rows processed
Figura 21. Aps atualizao das estatsticas e ndices do schema
Com isso, percebe-se que o processamento cai, onde o inicial foi de elapsed: 00:00:21.92, para aps a atualizao das estatsticas para Elapsed: 00:00:21.21, onde o Oracle decidiu por utilizar as informaes de estatsticas das tabelas e diminuiu suas regras na otimizao. Isso pode ser pouco significativo nessas tabelas
66 por conterem poucos dados, mas deve-se ter em mente tal procedimento em um sistema real, onde o resultado de melhora de processamento fica claro.
5.3 Modelagem Fsica do Banco de Dados Nesta subseo tratar-se- dos tipos de dados em uma tabela do Oracle.
Figura 22. Trecho de campos da tabela cliente
Toda a chave primria de uma tabela deve ser criada com o tipo NUMBER, salvo excees em que, por sua modelagem seja necessrio outro tipo de dado como chave primria. Tempo de respostas de instrues DML em tabelas com chave primria so maiores do que em tabelas com chave primria VARCHAR2, por exemplo. Na coluna 2 da figura, pode-se notar, que o nm_cliente (nome do cliente) tem tipo de dado VARCHAR2, isso por que o nome de um cliente dinmico, no se tem um tamanho pr definido, quando se define VARCHAR2 em uma tabela, o Oracle aloca somente o tamanho usado de dados em bytes para esse campo, ao contrrio do tipo de dados CHAR, que aloca o tamanho dimensionado pelo desenvolvedor. O Tipo CHAR s deve ser usado quando se tem certeza do tamanho do dado a ser inserido no campo, como desenvolvedor utilize sempre VARCHAR2, ora para no se confundir com inmeros campos. Sempre que houver a necessidade de criao de um campo flag, como exemplo item ativo ou inativo no sistema, sempre usar tipo de dados NUMBER, por ser mais rpida a resposta, segue exemplo abaixo, e colocar comentrio no campo para identificao do mesmo.
67
Figura 23. Campo flag NUMBER
5.3.1 ndices em tabelas De acordo com VALIATE (2012):
os ndices so estruturas opcionais associadas a tabelas e clusters que permitem que as consultas SQL sejam executadas mais rapidamente. Assim como o ndice analtico ou remissivo numa revista lhe ajuda a encontrar mais rapidamente informaes, um ndice de Oracle fornece um trajeto de acesso mais rpido aos dados da tabela. Voc pode usar ndices sem reescrever nenhuma consulta, os resultados das consultas so os mesmos, mas voc os v mais rapidamente (VALIATE, 2012, p. 01).
Os aspectos negativos com criao de ndices, que degradam a performance das atualizaes (INSERT, UPDATE, DELETE e MERGE), e tambm consomem espao em disco. Ento quanto mais ndices uma tabela possuir, menor ser sua performance com atualizaes. Sempre que criar um ndice, rever se h um grande nmero de consultas nessa coluna. A Oracle diz que um ndice pode degradar 3 vezes a performance de uma atualizao, ento imaginemos agora uma tabela com 10 ndices, onde a perda de performance de atualizao de 30 vezes.
5.3.1.1 Tipos de ndices e dicas de criao. Oracle 11G disponibiliza diferentes tipos de ndices e opes de armazenamento dos mesmos, providenciando melhor desempenho, disponibilidade e gerenciamento.
68 Segue abaixo, alguns exemplos de ndices no Oracle 11 G, os quais sero tratados individualmente: ndices B-tree; ndices Bitmap; ndices Function Based; ndices de domnio.
5.3.1.1.1 ndices B-Tree:
Este ndice possui alta cardinalidade, ou seja, tem maior desempenho em colunas de dados que nunca ou pouco se repetem, mais indicados como exemplo para ndices de PK, este ndice o default do Oracle. Abaixo demonstra-se sua estrutura fsica para melhor entendimento:
Figura 24. Estrutura do ndice B-Tree
Este ndice, conforme se pode entender por seu prprio nome, baseia-se numa rvore, onde comea a diviso pelo valor atravs da Raiz, por exemplo, para se
69 chegar ao Igor, o ndice se separa da busca na raiz, de AM, separando no prximo n dentro de GI, at chegar na folha e encontrar o Igor, com isso so feitos trs testes da raiz, do primeiro n e da folha, reduzindo o caminho de busca. Existem certas ocasies onde um ndice B-Tree no apropriado e no ir melhorar a performance de consultas. Em muitas destas situaes, tal como criar um ndice sobre uma aplicao de data warehouse, onde a coluna indexada tem poucos valores distintos, um ndice bitmap pode ser criado e melhorar bastante a performance (WHALEN, 1996).
5.3.1.1.2 Indice Bitmap. Ao inverso do B-Tree, este ndice otimiza consultas de baixa cardinalidade em colunas, ou seja, onde h pouca repetio de dados. De acordo com (BURLESON, 1997):
os ndices Bitmap foram introduzidos com o Oracle 7.3. Em um ndice bitmap, o Oracle cria um bitmap para cada valor nico da coluna em questo. Cada bitmap contm um nico bit (0 ou 1) para cada linha na tabela. Um 1 indica que a linha tem o valor especificado pelo bitmap e um 0 indica que no tem.
O Oracle pode rapidamente percorrer estes bitmaps para encontrar linhas que satisfazem um critrio especfico, tambm pode rapidamente comparar mltiplos bitmaps para encontrar todas as linhas que satisfazem aos mltiplos critrios. Esses ndices possuem desempenho desfavorveis para colunas que sofrem atualizaes constantes.
Figura 25. Estrutura de ndice Bitmap
70 5.3.1.1.3 ndices Function Based Este ndice baseia-se no retorno de uma funo ou expresso. Foi introduzido no Oracle 8i, pode ter a estrutura de um ndice Bitmap ou B-tree. Para otimizao de desempenho somente utilizado quando se faz necessrio utilizar de funes em consultas, com condies seletivas.
5.3.1.1.4 ndice de Domnio Este grupo de ndice so criados para colunas com tipos de dados especiais. Como exemplo, se possui-se uma coluna de imagem (geogrficas) e deseja-se fazer consultas, o ndice indicado no Oracle para esta coluna o Oracle Spatial. Se possui-se uma coluna de Varchar2 como quantidade de texto elevado ou tipo de dado Clob, o ndice indicado para esta situao o Oracle Text.
5.4 Entendendo como o Oracle Database processa as instrues SQL. Antes de iniciar o desenvolvimento de tcnicas de tuning em instrues DML, devese entender como o Oracle Database processa as instrues SQL. No Oracle os principais conceitos envolvidos na execuo das instrues so: Plano de Execuo; Otimizador de Query; Mtodos de Acesso aos dados; Mtodos de ligaes.
71 5.4.1 Plano de Execuo Define-se como uma sequncia de operaes que o Oracle realiza para executar as instrues DML. O plano de execuo se mostra em forma de rvore de linhas, onde contm os seguintes passos: Ordenao das tabelas referenciadas pela instruo; Mtodo de acesso para cada tabela mencionada na instruo; Mtodo join para as tabelas afetadas pelas operaes join da instruo; Operaes de dados tais como filter, sort ou agregao; Otimizao: custo e cardinalidade de cada operao; Particionamento: conjunto de parties acessadas; Para se ter acesso ao plano de execuo basta acrescentar a instruo o cabealho (EXPLAIN PLAN FOR). Nesse momento ser criado os passos necessrios para gerar a instruo na tabela core plan_table. Para uma melhor visualizao do plano de execuo utiliza-se da package core DBMS_XPLAN.DISPLAY, onde se ter em tela uma melhor visualizao dos passos para gerao da instruo DML, como segue melhor demonstrado na figura abaixo:
Figura 26. Plano de Execuo
72 Atravs do plano de execuo pode-se analisar as decises do Otimizador de Query do Oracle, analisando assim sua performance. Atravs deste plano pode-se analisar se uma query acessa os dados atraves de full table scan (caminho de acesso em que os dados so recuperados percorrendo todas as linhas de uma tabela. Tem maior eficincia em recuperar uma grande quantidade de dados da tabela ou os dados de tabelas com poucas linhas), ou index lookup (Caminho de acesso em que os dados so recuperados atraves de indices. mais eficiente para recuperar dados de um pequeno conjunto, 4 % de linhas de uma tabela), e o tipo de join que ela efetuou: seja nested loops join (Mtodo de acesso de ligao entre tabelas, utilizado quando pequenos conjuntos de dados esto sendo ligados e se a condio de ligao um caminho eficiente para acessar a segunda tabela), ou um hash join (Mtodo de acesso de ligao (join) entre 2 tabelas ou origens de dados, utilizado para ligar grandes conjuntos de dados). O plano de execuo varia de acordo com o ambiente que est sendo executado, ou seja, pode-se gerar um plano de execuo da mesma query em ambientes diferentes e ter diferentes valores, como exemplo de ambientes de desenvolvimento para um ambiente de produo. O plano pode ser diferente se for tambm gerado por schemas diferentes, pois leva em considerao o volume de dados, as estatsticas, parmetros de bancos, parmetros de servidor, sesso, etc.
5.5 Tunando Atualizaes de dados no Oracle Database.
5.5.1 DELETE.
5.5.1.1 Comando Truncate
Quando se deseja realmente apagar todos os dados de uma tabela, deve-se ter em mente que este comando irreversivel, pois no h ROLLBACK de suas transaes, uma vez que no gera logs e nem UNDO. Este comando
73 extremamente mais rpido do que o comando DELETE, pois redefine a estrutura da tabela, onde a Marca dgua vai para o incio da tabela. Alm de mais rpido que o comando DELETE, o comando truncate reorganiza a estrutura da tabela. O comando delete deixa espaos vazios na tabela, e estes espaos blocos de dados vazios fazem com que o insert na tabela demore mais. Segue exemplo de tempo de performance entre o comando DELETE e TRUNCATE abaixo:
Figura 27. Tempo de resposta entre o comando DELETE e TRUNCATE
5.5.1.2 Comando Bulk Binding no DELETE
Quando h a necessidade de apagar vrios registros em uma tabela dentro de um bloco autnomo de PL/SQL, deve-se utilizar do bulk binds, como exemplo o FORALL, na instruo DELETE. extremamente mais rpido do que um loop convencional, pois com FORALL ele ir ler toda a seleo da tabela, todas as linhas e enviar para o DELETE de uma vez, ou seja, N para 1, quando se faz um loop normal, o Oracle l a linha e envia para o DELETE, sendo 1 para 1.
74 Como exemplo de ganho de performance segue abaixo um trecho de bloco em PLSQL, nesse bloco carrega-se 10.000 (dez mil) linhas em uma coluna de 1 a 10.000 e deleta-se os dados dentro de um FOR normal e testo o tempo com um FORALL usando bulk binding.
Figura 28. Teste DELETE com FORALL
Como segue figura acima, ativou-se a funcionalidade SERVEROUTPUT para on, a fim de ter a sada em tela, criando ainda uma collection para a estrutura da tabela. Coletou-se antes dos dois processos de loop normal e com FORALL, as estatsticas dos dados, com isso tendo um retorno de desempenho maior. Utilizou-se a package DBMS_UTILITY.GET_TIME, para pegar a hora atual. Assim dando o tempo de execuo real desde a primeira interao do loop ate a sua finalizao. E com isso percebe-se a grande diferena de desempenho entre um FOR normal e utilizando de Bulk Binding com FORALL, onde o FOR normal terminou a deleo de 10.000 linhas em um tempo de 1.4 s e com FORALL o tempo foi reduzido para 0.66 s, resultando em quase 3 vezes no ganho de performance.
75 5.5.1.3 Comando DELETE com PARALLEL. Nesse comando pode-se inserir na instruo uma sugesto ao otimizador de quantos processadores usar para rodar determinada instruo, isso no quer dizer que o otimizador ir seguir essa sugesto, o mesmo ir analisar se prudente, caso sim realizar a instruo seguida da sugesto. Exemplo segue abaixo:
Figura 29. Utilizando DELETE com PARALLEL
Na figura acima, a dica dada para o otimizador utilizar 6 processadores para rodar a instruo, onde os hints comeam com /*+ e terminam com */, utilizando como mostra a figura o PARALLEL com dois parmetros, e o nome da tabela que, no caso foi utilizado como apelido da tabela e a quantidade de processadores. Neste caso, no teve como se medir o tempo de ganho que bem significativo, pois os testes foram realizados em uma mquina virtual com Oracle Express Edition, e nesta verso no h disponibilidade da funo de hint PARALLEL, logo disponvel em bancos Enterprise.
76 5.5.2 INSERT. 5.5.2.1 Comando Insert com Direct Path Este comando deve ser usado quando se deseja ganhar performance na insero de muitas linhas, ou insero dentro de um bloco PL-SQL, sempre quando se prioriza a performance da insero, neste caso pode-se ser usado o insert com hint APPEND. mais rpido que um insert convencional, pois insere no fim da tabela acima da HWM (high water mark), porm, neste momento o APPEND bloqueia a tabela, ento deve-se tomar cuidado com o concorrncia de atualizao nessa tabela. Segue abaixo o script.
Figura 30. Insert com Direct Path
Como demonstrado na figura acima, o insert com direct path muito mais rpido que o insert convencional, na primeira rodada, o insert foi mais rpido por que havia sido criada uma tabela vazia, e com isso no continha espaos em brancos, e assim que foi rodada pela segunda vez, o rollback criou os espaos vazios na tabela.
77 5.5.2.2 Comando Insert com Sequence Segundo Prado (2011):

ao utilizar SEQUENCES para inserir valores nicos em colunas de uma tabela, utilize SEQUENCES com CACHE. Sequences em cache ocupam pouca memria na Shared Pool e so muito eficientes para otimizar performance. O comportamento padro do Oracle na criao de sequences, cri-las com 20 valores em cache.
Para comprovar o que Prado afirma, segue abaixo a implementao, onde criou-se duas sequences, uma com cache padro do Oracle de 20 e outra sequence sem cache, criou-se ainda, uma tabela, com a insero de valores, ora utilizando sequence com cach, ora utilizando sequence sem cache, e assim chega-se ao resultado de que a sequence com cache obtm maior performance nas inseres, conforme demonstram as figuras abaixo de criao das sequences e da execuo do script:
Figura 31. Criao de Sequences.
78
Figura 32. Tempo entre Insert com Sequence com Cache e Sem cache
5.5.2.3 Comando Insert com Bulk Collection Quando se deseja inserir dados em uma tabela atravs de um loop, deve-se levar em considerao a possibilidade de fazer isso atravs de bulk collection, que mais rpido que um loop convencional, pois l N quantidades de dados para inserir, ao contrrio de um loop convencional que l 1 linha do cursor para fazer o insert sendo ento 1 para 1. Como exemplo, pode-se tomar a figura abaixo, que mostra o ganho de desempenho utilizando bulk collection no insert dentro de um bloco PL-SQL com LOOP, como pode-se perceber o ganho de performance com insero de 100.000 linhas em muito superior utilizando BULK COLLECTION no insert.
79
Figura 33. Insert com Bulk Collection
5.5.2.4 Comando INSERT com Pipelined Table Function Este comando exige um nvel de conhecimento mais elevado, possui ganho de performance em otimizar funes ou procedimentos complexos. Permite retornar dados como se fosse uma tabela virtual, no momento em que cada linha est sendo processada transforma os dados, excelente quando a aplicao necessita de um export de dados em formatos diferentes do banco de dados. Dispensar-se- a submisso de um script para testes no presente caso, pois o ganho de otimizao so muito raros de serem verificados, e com bulk collection tem-se um maior ganho de desempenho.
80 5.5.2.5 Comando INSERT com SQL LOADER Quando se deseja efetuar uma carga de dados em um tabela, e essa massa de dados tem um tamanho favorvel, um script de insert convencional normalmente muito demorado, levando horas para terminar. Nesse momento, pode-se tunar a aplicao utilizando o conceito de carga via SQL LOADER, atravs de um arquivo texto que insere-se na tabela do banco de dados os dados. A fim de demonstrar o ganho de desempenho simulou-se uma carga da tabela de cliente, onde pode-se verificar o tempo decorrido do insert e entender os comandos. O Primeiro passo foi a criao de um arquivo texto da tabela cliente, como segue os prints abaixo:
Figura 34. Criando arquivo texto, delimitado por pipe
81
Figura 35. Estrutura do Arquivo Texto
Figura 36. Arquivos necessrios para carga via SQL_LOADER
Figura 37. Cliente.ctl
A figura acima trata-se do arquivo de definio do insert, onde define-se a propriedade DIRECT = TRUE, ou seja, insert acima da HWM, e a propriedade UNRECOVERABLE, como essa propriedade impossvel voltar, o insert como ROLLBACK, define-se o tipo de caracteres que possa ter no arquivo, o nome do arquivo texto que contm os dados na propriedade INFILE, passando o insert em
82 qual tabela se ir fazer, dizendo que os campos so separados por pipe, que define na extrao, e os campos da tabela a ser feito o insert.
Figura 38. exec_carga_loader.sh
Na figura acima, determinou-se os parmetros de usurio e senha, o arquivo de configurao da carga e o nome do arquivo de log que ser gerado.
Figura 39. Tempo de carga de 35 segundos
Para cargas de mais de 64.000 (sessenta e quatro mil) linhas foram gastos apenas 35 segundos, o erro acima da linha se deu devido ao cabealho do arquivo.
83 Agora no arquivo cliente.ctl, alterou-se as configuraes para gerao de log e o modo agora insere nos clusters em bancos da tabela.
Figura 40. Alterao no arquivo cliente.ctl
Figura 41. Tempo de carga de 01 minuto e 34 segundos
Se essa carga fosse feita por um script, demoraria vrios minutos, ento aqui demonstra-se a eficincia da carga via SQL_LOADER, com algumas dicas para ganho de performance.
84 5.5.2.6 Comando insert utilizando MERGE Para este comando utiliza-se a ideia dentro de um bloco pl_sql, no momento onde h a necessidade de saber se um insert ou update na tabela. No comando MERGE pode-se combinar vrias instrues DML como INSERT, UPDATE e DELETE. Abaixo segue sua estrutura e o ganho de desempenho comparando com um insert convencional dentro de um loop FOR.
Figura 42. Insert Convencional X MERGE
Observa-se na figura acima, o ganho de desempenho do insert convencional para o MERGE, quando a necessidade de saber se um INSERT ou UPDATE. 5.6 Tuning em Queries.
85 5.6.1 Uso do Asterisco em consultas. Sempre quando se utilizar de busca de dados para uma aplicao, deve-se dimensionar as colunas que sero utilizadas na aplicao. Isso reduz o tempo de busca das informaes, logo, se necessrio duas colunas para a aplicao em uma tabela que contm trinta colunas, ao trazer somente as duas colunas necessrias, diminui-se o trfego de dados na rede, na situao cliente x servidor, reduzindo o uso de memria do Oracle no armazenamento deste espao. Isso pode ser demonstrado simplesmente no plano de execuo, conforme v-se abaixo:
Figura 43. Evitando o uso do Asterisco
86 Pela figura acima pode-se verificar o plano de execuo do uso do asterisco e abaixo o plano de execuo da mesma tabela somente dimensionando duas colunas. Nesse caso de 9 M caiu para 6668 K de dados retornados, reduzindo o custo de processamento da CPU. 5.6.2 Queries Idnticas Sempre que se utilizar uma mesma busca de dados para outras aplicaes, deve-se tomar o cuidado de escrev-las de forma idntica, pois, quando executar-se no Oracle queries idnticas, na primeira vez o Oracle guarda essa execuo na Shared Pool, e quando essa consulta for executada novamente o Oracle pesquisa em sua Shared Pool e v que esta consulta existe e apenas executa a mesma (repete), tornando o processo mais rpido, pois quando o Oracle encontra a querie na Shared Pool, o otimizador utiliza o mtodo Soft Parse apenas para execuo da querie, como definido na figura abaixo. Uma dica para sempre utilizar queries idnticas nas aplicaes o uso de Storage Procedures, fazendo apenas chamadas para retorno dos dados.
Figura 44. Processamento de SQL no Oracle
87 5.6.3 Queries Apelidos Quando programar-se queries deve-se sempre trabalhar com apelidos para as colunas, vale a dica logo que, ao usar apelidos diminu-se o nmero de letras nas queries, diminuindo tambm a alocao de memria na Shared Pool, alm de ficar mais clara a query para outros desenvolvedores. Neste momento, por ser um banco pequeno de testes e no ter concorrncia de dados, apenas submetendo-se a queries no h como se medir o ganho de desempenho, mas numa situao real o ganho de performance grande, alm de ser descrito com manual de programao da prpria Oracle. Segue abaixo exemplo na figura, com o modo errado de programao para o modo com apelidos.
Figura 45. Queries Apelidos
5.6.4 Regras de Precedncia
88 Como dica, a programao sempre deve ser feita pensando na regra de precedncia do Oracle, onde o otimizador sempre vai seguir a precedncia abaixo, de cima para baixo, com maior ganho de performance. Operador aritmtico; Operador de concatenao; Condies de comparao; IS [NOT] NULL, LIKE, [NOT] IN; [NOT] BETWEEN; No igual a... Negao da condio lgica; Condio lgica AND; Condio lgica OR.
5.6.5 Operadores Ou e Diferente Sempre que possvel dentro do desenvolvimento substitua os operadores OR, <> ou != por operadores NOT IN ou IN, isso alm de deixar o cdigo mais limpo e de fcil entendimento evita erros, conforme se pode verificar:
Figura 46. Dica de programao com NOT IN e IN
89 5.6.6 Operadores de Negao Ao se desenvolver uma querie que haja a necessidade de excluir a busca valores com NOT IN, <> ou !=, levar em considerao que, nesses casos, o otimizador entende que a busca ter pouca seletividade e no utilizar os ndices B-tree, assim, sempre informar na querie os dados que busca retornar com IN. Segue exemplo abaixo:
Figura 47. Operadores de negao
90 5.6.7 Operador Like Quando houver a necessidade de utilizar o operador LIKE em queries, sempre evitar o uso, se possvel, de curingas como (% ou _) no incio de comparaes, pois quando utilizado o otimizador entende-se que a consulta ter pouca seletividade e no utiliza-se os ndices. Como segue exemplo de performance abaixo:
Figura 48. Evitando uso de Curingas no LIKE
91 5.6.8 ndices nas Foreing Key Se uma query for utilizada com bastante frequncia na aplicao, deve-se criar ndices para otimizao de suas consultas, uma dica que vale lembrar, de sempre criar ndices em colunas FKs, o que otimiza a performance nas ligaes entre JOINS. 5.6.9 Evite o uso de funes entre ligaes de tabelas. Deve-se evitar ao mximo o uso de funes de converses de dados em ligaes de JOIN, em tabelas, tal fator aumenta o uso da CPU e consequentemente diminui a performance de processamento da query. Na documentao Oracle, diz-se que o uso de funes SQL entre ligaes de tabelas eliminam o uso do ndice B-tree. Segue plano de execuo abaixo para comprovao do fato:
Figura 49. Comparao com funes na ligao entre tabelas
92 Pode-se verificar pela figura acima que a query com a utilizao de funes para junes entre tabelas no utiliza o ndice existente no campo CD_PEDIDO para retornar os dados, fazendo um table acess full, logo na query abaixo, o otimizador utiliza o ndice fazendo um index range scan, como pode-se reparar, o ganho de performance foi grande de 10 s para 01 s, com custo de processamento de 792 para 6.
5.6.10 Converses de dados em ligaes como ndices baseado em Funes. ndices de datas podem ser de tipos baseados em funes para converso de datas, sempre que se fizer uma query de consulta com JOINS entre colunas que possuem ndices baseados em funes deve-se ter cuidado para a insero correta da converso, com isso utiliza-se o ndice e ganha na performance de aplicao. Segue exemplo abaixo com seu plano de execuo:
Figura 50. Plano de Execuo entre JOINS com ndice baseado em Funes
93 No exemplo acima, observa-se o ganho de performance usando a converso correta to_date, para a consulta, logo quando utilizou-se a query com parmetro fixo, o otimizador entendeu a necessidade de fazer um full table scan na tabela ignorando o ndice j existente, quando insere-se a funo to_date, afim de utilizar o ndice baseado em funo, o otimizador j fez index range scan, otimizando a performance de 04 s para 01 s, diminuindo o custo de 275 para 105.
5.6.11 Utilizao do NULL para comparaes Deve-se evitar ao mximo comparaes no WHERE com NULL, logo quando isso ocorre o otimizador no utiliza o ndice para pesquisas, resultando numa perca de performance. Isto ocorre por que o otimizador do Oracle no reconhece NULL como ndice, e com isso no gera as estatsticas da tabela. Segue abaixo plano de otimizao:
Figura 51. Comparao NULL e NOT NULL
94 Quando utilizado o NULL, como visto acima o otimizador fez full table scan na tabela, resultando em um custo de 274 com tempo de 04 s em uma tabela pequena, quando maior a tabela maior o tempo de retorno, menor a performance. Quando utilizado o NOT NULL, o otimizador j utilizou o ndice B-Tree resultando em um custo 0 com tempo de 01s.
5.6.12 UNION e UNION ALL Em certas ocasies, querys complexas podem ser resolvidas e melhor compreendidas utilizando UNION ou UNION ALL, que fazem a funo de juno de resultados de duas instrues. A diferena entre ambos que a instruo UNION trabalha retirando as linhas repetidas e comparando-as, com isso reduz o desempenho, utilizando de um DISTINCT. Nesses casos, sempre que possvel, substitua o uso do UNION pelo UNION ALL. Segue plano de execuo abaixo de duas instrues, onde a primeira foi utilizada o UNION e a prxima foi utilizada UNION ALL.
Figura 52. UNION X UNION ALL
95 Nota-se o ganho de performance com a utilizao do UNION ALL, em menos parses no plano de execuo, isso deve-se ao fato de que o UNION ALL no utiliza do DISTINCT, trazendo todas as linhas.
5.6.13 Utilizando CASE para busca de dados. A utilizao da clusula CASE permite a montagem de uma estrutura similar a IF..THEN..ELSE. O ganho de desempenho com CASE se deve ao fato de buscar as informaes no banco somente um vez, ao contrrio de um conjunto de selects para trazer valores. Para demonstrar o ganho foi construdo o script abaixo, onde se busca que a aplicao receba os valores de quantos funcionrios esto recebendo abaixo de R$ 2.000,00 (dois mil reais), quantos esto ganhando entre R$ 2.000,00 (dois mil reais) e R$ 4.000,00 (quatro mil reais) e quantos esto ganhando mais que R$ 4.000,00 (quatro mil reais), neste caso pode ser feito de duas formas por select com UNION ALL ou para ganho de desempenho com a utilizao do CASE como observa-se abaixo:
Figura 53. Utilizando CASE
96
Figura 54. Desempenho do CASE X UNION ALL
De acordo com a figura acima, pode-se observar o ganho de desempenho logo que o CASE somente buscou uma nica vez os dados na tabela EMPLOYEES, com a utilizao do SELECT com UNION ALL foram necessrias trs buscas de TABLE ACESS FULL. Com isso h uma reduo no custo da CPU e logo de tempo.
5.6.14 Utilizando a Clusula WITH para criao de tabela temporria Muitas vezes h a situao de j estar com a query escrita, a fim de evitar a sua reescrita novamente para utilizao do CASE, pode-se utilizar a clusula WITH em algumas situaes, com isso realiza-se apenas uma consulta na tabela, a clusula WITH foi implantada no Oracle verso 9, e tem a funo de criar uma tabela temporria, otimizando queries que precisam referenciar vrias vezes a mesma
97 tabela. Segue exemplo abaixo de plano de execuo para ganho de desempenho, neste caso necessrio apenas saber apenas quantos funcionrios ganham menos que R$ 2.000,00 (dois mil reais) e quantos esto ganhando entre R$ 2.000,00 (dois mil reais) e R$ 4.000,00 (quatro mil reais).
Figura 55. Utilizando a Clausula WITH
Figura 56. Comparao com a Clusula WITH
98 Tendo em vista que a presente aplicao somente precisa de duas situaes no WHERE, a Clusula WITH cria uma tabela temporria somente do que precisa retornar, sem precisar ir na tabela EMPLOYEES fazer TABLE SCAN FULL, com isso h ganho de desempenho na consulta de menos linhas.
5.6.15 Utilizao de Variveis BIND Sempre trabalhar com variveis nas condies WHERE dos SELECTS que so reutilizados na aplicao, com isso o otimizador identifica que a SELECT est na Shared Pool, e com isso utiliza o plano de execuo j existente, tendo um desempenho maior. Segue exemplo de ganho de desempenho abaixo:
Figura 57. Tempo de Desempenho com varivel BIND
99 Nota-se o ganho de 268 segundos com BIND para 280 com variveis fixas, isso se deve ao fato comentado acima.
5.7 Utilizao de HINT. De acordo com Lewis (2005):

Apesar de todas as informaes coletadas e todo algoritmo sofisticado do otimizador, provavelmente o nosso conhecimento da informao armazenada maior que a que o otimizador possui. Por exemplo, podemos saber que um ndice ais seletivo em certas queries que o otimizador possa determinar. Baseado nisso podemos estar mais apto a escolher um plano de execuo mais eficiente que o otimizador. Neste caso, podemos usar HINTS para forar o otimizador a usar o plano de execuo que desejamos. HINTS so sugestes que fornecemos ao otimizador para um comando SQL. (LEWIS, 2005)
Nesse tpico tratar-se- dos HINTS mais conceituados, com maior uso por programadores. A verso 11G mais eficaz com relao a este assunto; em testes realizados somente dois HINTS obtiveram ganho de desempenho (FIRST-ROW, FULL), os demais apresentaram o mesmo plano de execuo, isso se d pelo fato de que o Banco de Dados Oracle 11G est mais preparado para estas situaes, escolhendo os melhores plano de execues.
5.7.1 HINT FULL SCAN Este HINT FULL (/*+FULL*/) tem a funo de realizar um full table scan na tabela, deve ser utilizado quando houver a certeza que um FTS ter o melhor resultado do que um index scan.
100 5.7.2 HINT FULL COM PARALLEL Conforme testado no incio do capitulo 5, este HINT (/*+ PARALLEL (p,2,2) */) utilizado quando se busca que a aplicao seja executada por mais de 1 processador. Deve-se conhecer a arquitetura dos servidores para poder dimensionar com quantos CPU uma query ser executada, para processamento distribudo.
5.7.3 HINT FIRST_ROWS Trata-se de uma hint muito utilizada (/* first_rows (5) */); deve ser utilizada pela busca de linhas determinadas, mas no para leitura completa da tabela.
5.7.4 HINT RULE Este HINT (/*+ RULE */) considera as regras que o Oracle possui pr configuradas para execuo da expresso, desconsiderando qualquer outra hint.
5.7.5 HINT FULL O HINT FULL (/*+ FUL (p) */) realiza uma varredura completa da tabela, a qual deve ser realizada com cautela, e assim poder contribuir com resultados positivos ou negativos.
5.7.6 HINT LEADING Este HINT (/* LEADING (p) */) concorre diretamente com a ORDERED, prevalecendo esta. Utiliza-se a LEADING quando no h aptido em determinar a
101 ordem ideal das tabelas para varredura, assim determina-se a tabela especificada e a hint realizar a sequncia ideal para as tabelas seguintes envolvidas.
5.7.7 HINT USE_NL Este hint (/* USE_NL (p) */) mais rpido para retorno de uma linha, mas lento para conjunto de linhas.
5.7.8 HINT USE_HASH Este hint (/* USE_HASH(infe) */) tem como funo principal subir para a memria a segunda tabela que ser percorrida a fim de achar as combinaes que atendem a linha selecionada na primeira tabela, com desempenho satisfatrio quando h espao considervel nas reas de HASH_AREA_SIZE e PGA_AGGREGATE_TARGET.
5.8 Ferramentas para analise de performance e desempenho do banco. 5.8.1 Explain Plan. O Explain Plan ir demonstrar ao desenvolvedor, atravs do plano de execuo, os meios de acesso que o otimizador est utilizando para acessar as tabelas do banco de dados. Como pode-se notar, esse foi o meio escolhido para demonstrar os ganhos de desempenho no tuning. Segue abaixo o comando a ser inserido para gerar o plano de execuo: EXPLAIN PLAN FOR {INSTRUO SELECT A SER AVALIADA}
102 SELECT * FROM TABLE (dbms_xplan.display) Importante lembrar que, para ter uma bom resultado no plano de execuo deve-se ter sempre os dados estatsticos atualizados das tabelas, uma vez que o plano de execuo trabalha em cima de seletividade, cardinalidade e custo.
5.8.2 SQL LOADER De acordo com VIEGAS (2012):

O SQL*Loader um aplicativo de importao que acompanha o Oracle, tendo como diferencial a flexibilidade na configurao, pois utiliza uma linguagem de scripts para importar os dados. Entre os recursos disponibilizados pela linguagem de script, possvel validar cada registro antes da importao, definir valores default, aplicar alteraes sobre os registros lidos, separar os dados importados em duas ou mais tabelas, entre outros. O SQL Loader tambm permite a importao de tipos BLOB, objetos complexos e colees de dados. O utilitrio foi projetado para importao de arquivos texto que tenham formato de tabela, onde cada registro representado por uma linha, os campos podem ter tamanho fixo ou varivel e qualquer carter pode ser utilizado para separ-los. O script de importao deve ser salvo em um arquivo texto, conhecido como arquivo de controle (Control File). O SQL*Loader um aplicativo de linha de comando, que interpreta o arquivo de controle passado como parmetro. A linguagem utilizada no script especfica, denominada SQL*Loaders DDL (Data Definition Language). A documentao completa desta linguagem est disponvel na instalao do Oracle.
Esta ferramenta foi utilizada nesse trabalho para dar carga em algumas das tabelas utilizadas conforme descrita no subitem 5.6.5.
103 5.8.3 TKPROF De acordo com Ricardo (2009):

Essa uma ferramenta cuja funo principal de transformar um arquivo de trace em um arquivo de texto, para que assim possa permitir a nossa avaliao quanto ao desempenho das instrues de consultas abertas ou fechadas como os procedimentos armazenados (storeds procedures) ou os pacotes (packages).
O retorno dos dados convertidos, para o arquivo do tipo texto, deve ser realizado linha a linha, de maneira cuidadosa para que no passe qualquer detalhe que possa representar o verdadeiro motivo da baixa performance. O arquivo, que denominado tecnicamente como arquivo de trace, normalmente est localizado nos diretrios: UDUMP, CDUMP e BDUMP e armazena todas as operaes que ocorrerem dentro do banco de dados (RICARDO, 2009). Ricardo (2009) indica ainda certos pontos que devem ser observados nos arquivos gerados pelo TKPROF:
Comparar o nmero de Parses com o nmero de execues, onde o ideal um Parse para vrias execues. Aproveitamos esse momento para especificar que as estatsticas so divididas basicamente em 3 grupos: Parse o momento onde verifica a existncia dos objetos citados na instruo assim como se a sintaxe est correta; Execute a etapa onde ocorre verdadeiramente a execuo do SQL pelo Oracle; e Fetch onde ocorre o retorno das linhas que satisfazem a instruo SQL, portanto vlida somente para selects, Procurar aplicar as variveis BIND em instrues que no estejam utilizando-as, isto, por que essas variveis permitem um ganho de desempenho considervel no momento da execuo das consultas (Execute), pois permite que a instruo seja preparada uma nica vez pelo otimizador do gerenciador de banco de dados e consequentemente executada inmeras vezes; Localizar os processos que estejam constantemente fazendo uso de Full Table Scans (FTS), pois, por consequncia esses processos, como j foram
104
citados anteriormente, consomem muita CPU alm de um alto custo de leituras a disco.
Abaixo segue os prints de gerao de um arquivo TKPROF para anlise:
Figura 58. Local onde ser gerado os arquivos do TKPROF
Figura 59. Habilitando o trace no ambiente
Quando habilitado o trace no ambiente deve-se ter cuidado, pois isso acarretar numa perda de desempenho, logo que sero gravados em arquivo todos os passos das instrues executadas.
Figura 58. Nomeando o trace no ambiente.
Nomeia-se o trace a ser gerado como forma de facilitar na busca do arquivo gerado.
105
Figura 60. Instruo realizada no trace
No terminal do Linux ou no Dos do Windows, deve-se ir no caminho onde foi gravado os arquivos do TKPROF.
Figura 61. Localizando os arquivos gerados pelo TKPROF
Figura 62. Gerando arquivo .txt do trace gerado pelo TKPROF
106
Figura 63. Lendo o arquivo gerado
Figura 64. Parte do arquivo gerado onde encontra-se o trace da instruo executada a ser analisada
Assim finaliza-se os passos para gerao do arquivo TKPROF e a leitura do mesmo. Por se tratar de uma instruo SELECT analisada, foram executados 3 passos para consulta do mesmo (PARSE, EXECUTE e FETCH).
5.9 Parmetros de Banco de dados Oracle 11 G Finalizando o TCC, verifica-se parmetros em nvel de sesso de usurio que setados corretamente geram maior ganho de desempenho em instrues SQL.
5.9.1 Parmetro Cursor_Sharing Trata-se de um parmetro do banco de dados que afeta o nvel de interpretao das sentenas SQL que so comuns entre os usurios. Quando se tem SQL idnticos no banco de dados, este gravado na SHARED POOL, com isso na sua prxima
107 execuo o otimizador realize a busca se o mesmo j existe em um plano de execuo na SHARED POOL, se sim o otimizador o utiliza. No Cursor_Sharing existe dois valores suportados na verso 11 G, que o EXACT, padro este documentado pela Oracle para aplicativos ERP Enterprise Business Suite, onde respeita o que esta escrito na SQL, no levando em considerao as sentenas comuns, e o outro valor aceito o FORCE, quando setado no banco de dados o otimizador levar em considerao os SQL fixo como variveis BIND, com isso para bancos OLTP, o desempenho ser maior. Para alterar o parmetro que est setado no banco utilize a instruo abaixo, normalmente a instalao do Banco de Dados Oracle vem com o parmetro setado para EXACT.
Figura 65. Alterado o parmetro CURSOR_SHARING
Quando setado este parmetro no banco e o desenvolvedor desejar trabalhar com o parmetro na aplicao com EXACT, o mesmo pode utilizar do HINT /*+ CURSOR_SHARING_EXACT */.
5.9.2 Parmetro Optimizer_Index_Cost_Adj Este parmetro permite mudar os custos de operaes FULL TABLE SCAN X INDEX SEARCH. Para este parmetro, os valores permitidos so entre 0 e 10.000. De default, o banco de dados Oracle vem com parmetro setado com valor 100. Porm para muitos bancos de dados Oracle, o padro entre 10 e 50 so os ideais para ganho de desempenho, pois nessa faixa o banco utiliza os ndices com maior frequncia, se o banco estiver recolhendo as estatsticas corretamente, e ter o cuidado para criao somente de ndices necessrios, o valor entre 10 e 50 o mais indicado.
108 Para saber o valor correto a ser configurado nesse parmetro para ganho de performance, existe a query abaixo que mostra no campo STARTING_VALUE_OICA, o valor mais indicado para este parmetro:
Figura 66. Parmetro OPTIMIZER_INDEX_COST_ADJ
Para alterar o valor do parmetro OPTIMIZER_INDEX_COST_ADJ, utilize a seguinte sentena, lembrando que somente o DBA tem acesso a este procedimento: ALTER SESSION SET OPTIMIZER_INDEX_COST_ADJ = 50.
5.9.3 Parmetro OPTIMIZER_INDEX_CACHING Este parmetro ao ser configurado, indica ao otimizador um valor percentual mdio de ndices que residem em cache, a fim de influenciar o plano de execuo do otimizador. Seguindo a regra de que quanto maior o valor do parmetro ir favorecer-se a operaes para NESTED LOOP JOINS, quanto menores forem os valores o otimizador ir favorecer as operaes de hash joins ou sort merge joins.
109 Por default, o Oracle j vem setado com 0. Para definir valor para este parmetro na instalao da instncia do banco, deve ter sido criado tablespaces diferentes para dados e ndices, logo que as tablespaces de ndices devem obedecer o valor de 32 k de blocos, como explicado acima, esse valor dar ganho de performance no banco, somente com esta configurao este parmetro trar ganho de desempenho ao banco de dados. Para verificar o valor a ser inserido nesse parmetro utilize o select abaixo no owner SYSADMIN:
Figura 67. Obtendo valor para o parametros OPTIMIZER_INDEX_CACHING
Para alterar o valor do parmetro utilize a instruo abaixo: ALTER SESSION SET OPTIMIZER_INDEX_CACHING = Valor desejado.
5.9.4 Parmetro OPTIMIZER_MODE Esse parmetro pode ser configurado para designar ao banco de dados a optar pelo uso de INDEX SCAN (utilizao de indices), ou pelo uso de FULL TABLE SCAN (varredura completa na tabela) nas consultas do banco de dados. indicado para ganho de performance que o valor deste parmetro esteja com FIRST_ROW, onde ir optar pelo uso de ndices. Para alterar este parmetro no banco de dados utilize o script abaixo: ALTER SESSION SET OPTIMIZER_MODE = FIRST_ROWS;
110 Existem inmeros parmetros no banco de dados, citados acima os principais parmetros que influenciam em um melhor desempenho do banco de dados Oracle OLTP, deve-se ter muito cuidado ao se alterar os valores destes parmetros, devendo levar em considerao todos os aspectos como sistema operacional, hardware, quantidade de dados, entre outros.
111
CONCLUSO
O fator de preocupao com o desempenho trata-se de tema relevante, mas com pouca explorao at a atualidade. Muito se sabe que o problema existe e que h formas de melhoria, porm a falta de um bom contedo que abranja o tema na lngua portuguesa, tal assunto deixado ao acaso, tentando ser contornado em outras perspectivas. Em razo da grande massa de dados que compem os bancos de dados e a necessidade cada vez maior de tempo de resposta em tempo real, faz-se necessrio a elaborao de cdigo limpo, levando em considerao as diretrizes de um banco de dados. Alm disso, sempre preciso pensar no poder de processamento do ambiente para atingir tempos de resposta mais curtos e somente os dados foco de buscas. Pode-se observar atravs do estudo realizado sobre tuning ser o mesmo de grande importncia para os novos desenvolvimentos bem como para manuteno das aplicaes, sendo necessrio monitoramento constante de desempenho, ajustes e administrao do ambiente, partindo do princpio de polticas a serem implantadas e seguidas, como procedimentos integrados para o gerenciamento do desempenho do banco de dados. Para obteno de resultados satisfatrios, imprescindvel considerar-se as fases iniciais de implantao do banco de dados, bem como o desenho do projeto do mesmo. Com isso, evita-se a necessidade de reprojeto ou recodificao dos cdigos fontes. No transcorrer do desenvolvimento do trabalho, buscou-se demonstrar as melhores prticas de programao de SQL, as configuraes de ambiente, os quais foram comprovados por meio tcnicas de medio de tempo de resposta utilizando-se de um banco de dados Oracle 11G Enterprise Express Edition. Alguns ganhos de desempenho no puderam ser demonstrados em razo de se tratar de um banco de dados gratuito da Oracle, o qual possui certas limitaes.
112 Apesar da longa discusso do tema no presente trabalho, este ainda possibilita muitas outras pesquisas e aprofundamento do assunto, como o estudo do tuning em sistemas operacionais e tuning de instncia, temas estes que exigem alm de todo o descrito neste trabalho, um amplo conhecimento de infraestrutura.
113
REFERNCIAS
ANDRADE, Luciano Duarte. Otimizao de Consultas de Aplicaes T-SQL em Ambiente SQL Server 2000. 2005. 52 f. Monografia (Graduao em Cincia da Computao) Departamento de Cincia da Computao, Instituto de Matemtica, Universidade Federal da Bahia, Salvador, 2005. Disponvel em: http://disciplinas.dcc.ufba.br/pub/MATA67/TrabalhosSemestre20051/Monografia_Luc iano_Andrade.pdf Acesso em: 16 maio 2012. ATHREYA, Jagan R. Banco de Dados Oracle 11g: Viso geral do Real Application Testing e da capacidade de gerenciamento. Junho de 2007. Disponvel em: http://www.oracle.com.br. Acesso em: 17 maio 2012. BURLESON, Don, High Performance Oracle8 Tuning. Coriolis Group Books, 1997. BURGO, Amrico F. T. Engenharia de Software e Banco de Dados: Tuning de banco de dados em um software de CRM. 2007. Monografia (Especializao em Engenharia de Software e Banco de Dados) Universidade Estadual de Londrina. Londrina, 2007. CARNEIRO, A. P.; FREITAS, A. L. C.; MOREIRA, J. L. Artigo Cientfico: TUNING Tcnicas de Otimizao de Banco de Dados Um Estudo Comparativo: Mysql e Postgresql, FURG - Rio Grande do Sul, 2006. CASTRO, Gabriela de. Melhorando a performance. 2011. Oracle support services. Disponvel em: http://www.oracle.com. Acesso em: 17 maio 2012. CASTRO, Gabriela de. Oracle 7 Performance tuning: memory, I/O and Contention. 2011. Oracle support services. Disponvel em: http://www.oracle.com. Acesso em: 17 maio 2012. COLELLO, David. Arquitetura do Banco de Dados Oracle 11g no Windows. Julho de 2007. Oracle. Disponvel em: http://www.oracle.com.br Acesso em: 17 maio 2012. DATE, C. J. Introduo a Sistemas de Bancos de Dados. Traduo da 8 edio americana de Daniel Vieira. 7 reimpresso. Rio de Janeiro: Elsevier, 2003.
114 ELMASRI, Ramez; NAVATHE, Shamkant. Fundamentals of Database Systems. Benjamim-Cummings. 3 edio, 2000. GIORGINO, Paula dos Santos. Sistema de Gerenciamento de Banco de Dados Oracle. Disponvel em: http://pt.scribd.com/doc/77492276/Artigo-Oracle. Acesso em: 04 maio 2012. HIRATSUKA, Eleni Lumi. Voc um Tuner? Disponvel em: http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=1681. Acesso em: 09 maio 2012. IKEMATU, Ricardo Shoiti. Realizando Tuning na Base de Aplicaes. Disponvel em: http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=1592. Acesso em: 10 maio 2012. LEGATTI, Eduardo. A evoluo dos bancos de dados Oracle. Disponvel em: http://eduardolegatti.blogspot.com.br/2007/04/evoluo-dos-bancos-de-dadosoracle.html. Acesso em: 04 maio 2012. LEWIS, Jonathan. Cost Based Oracle. 2005. ORACLE. A histria do Oracle: Inovao, liderana e Resultados. Disponvel em: http://www.oracle.com/br/corporate/press/story-346137-ptb.html. Acesso em: 04 maio 2012. PRADO, Fbio. Tunando instrues SQL no Oracle 10g. 2010. Disponvel em: http://www.fabioprado.net. Acesso em: 17 maio 2012. RICADO, D. TKPROF Utilizar ou no? E Porque? Disponvel http://profissionaloracle.com.br/blogs/drbs/2009/06/30/tkprof-utilizar-ou-nao-eporque/. Acesso em: 14 outubro 2012. em:
ROB, Peter; CORONEL, Carlos. Sistemas de Banco de Dados: Projeto, implementao e administrao. Traduo da 8 edio norte-americana. Reviso tcnica Ana Paula Appel. 1 edio. So Paulo: Cengage Learning, 2011.
115 SETZER, Valdemar W. Bancos de dados: conceitos, modelos, gerenciadores, projeto lgico e projeto fsico. 3 edio revista. So Paulo: Edgard Blucher Ltda, 1995. SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistemas de Banco de Dados. Traduo de Daniel Vieira. 5 edio Rio de Janeiro: Elsevier, 2006. SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistemas de Banco de Dados. Traduo de Marlia Guimares Pinheiro e Cludio Csar Canhete. 3 edio So Paulo: Makron, 2001. SOUSA, Humberto Delgado de. O conceito de tuning aplicado em instrues SQL dentro de um Banco de Dados Oracle. 2011. 80p. Monografia (graduao) Universidade Nove de Julho (UNINOVE), So Paulo: Campus Memorial Barra Funda, 2011. SOUZA, F. A.; ALONSO, A. K. P. B.; SANTOS, R., Artigo Cientfico: Avaliao das principais tcnicas de desempenho em banco de dados Oracle atravs da otimizao SQL, Policamp So Paulo, 2007. SOUZA, Ana Paula dos Santos; CAMPOS, Bruno Fidelis; DIAS, Carla Glnia Guedes; ALVES, Michel Batista; VIEIRA, Carlos Eduardo Costa; CARELLI, Flvio Campos; COSTA DE S, Luiz Fabiano. Tuning em Banco de Dados. Cadernos UniFOA. Volta Redonda, ano IV, n. 10, agosto. 2009. Disponvel em: http://www.unifoa.edu.br/portal_pesq/caderno/edicao/10/19.pdf. Acesso em 14 maio 2012. SUMIT, Sarim. Oracle DBA: Dicas e tcnicas. Rio de Janeiro: Campus, 2000. TEOREY, Toby; LIGHTSTONE, Sam; NADEAU, Tom. Projeto e Modelagem de Banco de Dados. 4. ed. Traduo de Daniel Vieira. Rio de Janeiro: Editora Elsevier, 2007. VALIATE, Pedro. Artigo da SQL Magazine 36 - ndices no Oracle. 2012. Disponvel em: http://www.devmedia.com.br/artigo-da-sql-magazine-36-indices-nooracle-parte-i/6835#ixzz26sPHNCK6. Acesso em: 18 setembro 2012. WHALEN, Edward. Oracle 8 in 21 days, Sams Publishing, 1996.
116 WEBER, Flvio Augusto; ANGELOTTI, Elaini Simoni. Otimizando Consultas SQL no ambiente SQLServer. Disponvel em: http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=1184. Acesso em 10 maio 2012. YONG, Chu Shao. Banco de Dados: organizao, sistema e administrao. So Paulo: Atlas,1990.

1111330740

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

1111330740

Încărcat de

Drepturi de autor:

Formate disponibile

VAGNER FREITAS RIGO

ESTUDO DA METODOLOGIA DE TUNING EM BANCO DE DADOS ORACLE

VAGNER FREITAS RIGO

ESTUDO DA METODOLOGIA DE TUNING EM BANCO DE DADOS ORACLE

ESTUDO DA METODOLOGIA DE TUNING EM BANCO DE DADOS ORACLE

VAGNER FREITAS RIGO

Orientador: Dr. Alex Sandro Romeo de Souza Poletto.

Analisador (1): Fernando Cesar de Lima

Palavras-chave: Banco de dados, Tuning, Oracle 11g, Otimizao.

LISTA DE ABREVIATURAS E SIGLAS

BD DBA DDL DML I/O PGA SBD SGA SGBD SQL

Sumrio 1 INTRODUO .................................................................................. 14

2. CONCEITOS BSICOS SOBRE O SISTEMA GERENCIADOR DE BANCO DE DADOS (SGBD) ............................................................... 18

3. METODOLOGIA DE TUNING .......................................................... 38

4. PROPOSTA DE TRABALHO........................................................... 57 5. ESTUDO DE CASO ......................................................................... 58

CONCLUSO .................................................................................... 111 REFERNCIAS .................................................................................. 113

1.4 METODOLOGIA DE PESQUISA

1.5 ESTRUTURA DO TRABALHO

2. CONCEITOS BSICOS SOBRE O SISTEMA GERENCIADOR DE BANCO DE DADOS (SGBD)

2.1 BREVES CONSIDERAES SOBRE BANCO DE DADOS

Figura 1. Sistemas antigos X Sistemas atuais

Modelo de dados hierrquico e em rede

IMS ADABAS IDS-II

Primeiros sistemas de bancos de dados Acesso navegacional

De meados da dcada de 1970 at o presente

Modelo de dados relacional

DBS Oracle MS SQL Server MySQL

De meados da dcada de 1980 at o presente

Orientado objetos Relacional estendido

Versant FastObjects.Net Objectivity/DB DB/2 UDB Oracle 10g

dbXML Tamino DB2 UDB Oracle 10g My SQL Server

Tabela 2. Vantagens e desvantagens dos diferentes modelos de BD (Ind.*: Independncia)

Figura 2. Desenvolvimento dos modelos de dados (ROB; CORONEL, 2011, p. 48)

23 Nos ensinamentos de Silberschatz (2006):

2.2 SISTEMA GERENCIADOR DE BANCO DE DADOS (SGBD)

mapeamento conceitual/interno e a definio do banco de dados

Segundo Silberschatz (2001):

Acrescentando, os mesmos autores:

A fim de expor as principais funes e componentes de um SGBD, est a Figura 3:

Figura 3. Principais funes e componentes de um SGBD (Date, 2003, p. 38)

Figura 4. Estrutura do sistema (SILBERSCHATZ; KORTH; SUDARSHAN, 20012006, p. 18)

2.3 BANCO DE DADOS ORACLE

Verso Oracle 2 Oracle 3

Ano de criao 1979 1981

Oracle 4 Oracle 5.0 Oracle 5.1 Oracle 6

Verso Oracle 8.0

Ano de criao Junho 1997

Verso Oracle 11g

System Global Area Banco de Dados

Redo Log Files

Users Data Files

Figura 5. Arquitetura do Oracle

Tabela 9. Tipos de dados suportados pelo Oracle

3.1 LINGUAGEM SQL

manipulao hospedeiras; falta de algumas funes;

3.2 FUNDAMENTAO TERICA SOBRE TUNING

3.2.1 Conceitos gerais sobre Tuning

Figura 6. Fases do Tuning (Souza (2009), et al apud Peixoto Jnior e Carvalho(2008))

Figura 7. Responsveis pelo tuning

3.2.1.1 Sintonia de ndices

3.2.1.2 Sintonia de consultas

Acrescenta ainda, o mesmo autor:

50 consequentemente, outras aplicaes do BD tambm sero influenciadas com o ganho de performance.