LEONARDO DE SOUZA PARRA

TUNNING de Desempenho em Banco de Dados

Londrina 2005

LEONARDO DE SOUZA PARRA

TUNNING de Desempenho em Banco de Dados

Monografia apresentada ao Curso de PsGraduao em Engenharia de Software e Banco de Dados da Universidade Estadual de Londrina, como requisito parcial obteno do ttulo de Especialista.

Orientador: Prof. Ms. Daniel dos Santos Kaster

Londrina 2005

LEONARDO DE SOUZA PARRA

TUNNING de Desempenho em Banco de Dados

Monografia apresentada ao Curso de PsGraduao em Engenharia de Software e Banco de Dados da Universidade Estadual de Londrina, como requisito parcial obteno do ttulo de Especialista.

COMISSO EXAMINADORA

________________________________________ Prof. Ms. Daniel dos Santos Kaster Universidade Estadual de Londrina ________________________________________ Prof. Ms. Fbio Csar Martins Universidade Estadual de Londrina ________________________________________ Prof. Ms. Rodolfo Miranda de Barros Universidade Estadual de Londrina

Londrina, 17 de agosto de 2006.

DEDICATRIA Dedico esse trabalho a todos os que possuem interesse na rea como pesquisadores, estudantes, profissionais que lidam com o contedo apresentado.

AGRADECIMENTOS Agradeo a todos que contriburam das mais variadas maneiras para realizao dessa pesquisa. Professores, alunos, amigos, que contriburam com artigos, opinies sobre o assunto, dicas bibliogrficas e todas as mais variadas formas de ajuda.

As invenes so, sobretudo, o resultado de um trabalho teimoso.... Alberto Santos Dumont

RESUMO

Com o crescimento cada vez maior de bases de dados, a demanda por informaes rpidas se torna inevitvel. possvel associar o crescimento de empresas ao crescimento cada vez maior de suas informaes. Via de regra, quanto maior a base de dados, teoricamente a mesma fica cada vez mais lenta. Para tentar mostrar que possvel ter uma base de dados grande e veloz, algumas tcnicas foram abordadas nessa pesquisa. Para o desenvolvimento dessa pesquisa foram selecionadas algumas tcnicas que podem ajudar muito no quesito performance. A proposta estudar cada uma das tcnicas selecionadas com intuito de se obter um comparativo (com exemplos prticos) entre o antes e o depois do uso de cada tcnica, mostrando o ganho ou a perda de performance.

ABSTRACT

With the progress of the database, the demand for fast information has gotten inevitable. Its possible to relate the progress of companies to the progress of its information. Nevertheless, the larger is the database the slower it is due to its progress. To try to show it is possible to have a database considered large, but speed, some techniques were shown in this search. To this searchs development some techniques were selected to help a lot the performance. This searchs purpose is to study all the selected techniques to get a comparative, with some examples, comparing the before and the after in the use of each technique, showing the increase or the loss of performance with its use.

SUMRIO 1) 2) Introduo .................................................................................................... 1-11 Definio de performance em banco de dados ........................................... 2-13

2.1) A regra 80/20 .....................................................................................................................2-13 2.2) Componentes que definem a performance de um sistema ............................................2-14
2.2.1) Performance da plataforma subjacente ......................................................................................2-14 2.2.2) Performance de SGBD...............................................................................................................2-15

2.3) Gerenciamento de Performance ......................................................................................2-15

2.3.1) Planejamento de performance ....................................................................................................2-17 2.3.2) Administrao de performance ..................................................................................................2-18

2.4) O papel do DBA ................................................................................................................2-20

3)

Gerenciamento de performance da plataforma subjacente ....................... 3-24

3.1) Interao com o Sistema operacional..............................................................................3-24 3.2) Arquiteturas de Sistemas .................................................................................................3-24

3.2.1) Sistemas Centralizados ..............................................................................................................3-25 3.2.2) Sistemas Cliente / Servidor ........................................................................................................3-25 3.2.3) Sistemas Paralelos......................................................................................................................3-26

3.3) Configurao de Agentes Aliados....................................................................................3-26 3.4) Configuraes de Hardware ............................................................................................3-27

3.4.1) Escolha dos meios de armazenamento .......................................................................................3-27 3.4.2) Uso de RAID (Redundant Arrays of Inexpensive Disks) ..........................................................3-28 3.4.3) Organizao de arquivos e otimizao de Acessos a Blocos de Disco ......................................3-30

4)

Gerenciamento de performance de SGBD.................................................. 4-33

4.1) Parmetros de configurao ............................................................................................4-33

4.1.1) Uso de Memria.........................................................................................................................4-33 4.1.2) Configurao do Log .................................................................................................................4-37 4.1.3) Conteno e Locking .................................................................................................................4-39 4.1.4) Outras Opes de Configurao.................................................................................................4-39 4.2Estratgia de armazenamento..........................................................................................................4-40 4.2.1) Alocao de Discos....................................................................................................................4-40 4.2.2) Colocao e Distribuio de Arquivos.......................................................................................4-41 4.2.3) Isolamento do catlogo do sistema ............................................................................................4-41 4.2.4) Reserva de espaos livres (free space) .......................................................................................4-42 4.2.5) Distribuio dos dados ...............................................................................................................4-42 4.2.6) Armazenamento do log ..............................................................................................................4-43 4.2.7) Particionamento .........................................................................................................................4-43 4.2.8) Definio da forma de controle dos arquivos.............................................................................4-43 4.2.9) Definio do tamanho de bloco..................................................................................................4-44 4.2.10) Uso de tcnicas de compresso de dados .................................................................................4-44

5)

Gerenciamento de performance de aplicaes ........................................... 5-46

5.1) Refinamento do projeto de banco de dados....................................................................5-46

5.1.1) Desnormalizao........................................................................................................................5-46 5.1.2) Clustering de tabelas ..................................................................................................................5-46

5.2) Entendendo o otimizador de consultas do SGBD ..........................................................5-47

5.2.1) A otimizao relacional ..........................................................................................................5-48 5.2.2) Desenvolvendo aplicaes para Acesso Relacional ...................................................................5-49 5.2.3) Otimizao baseada em regras e Otimizao baseada em custos...............................................5-49

5.3) Tunning de frases SQL.....................................................................................................5-51

5.3.1) Definio adequada de ndices...................................................................................................5-51 5.3.2) Otimizao de junes (joins)....................................................................................................5-56 5.3.3) Escrita de frases SQL que faam uso dos ndices criados..........................................................5-62 5.3.4) Habilitando o Acesso Paralelo ...................................................................................................5-67 5.3.5) Acessos a Views ........................................................................................................................5-67 5.3.6) Reescrita de Consultas ...............................................................................................................5-68 5.3.7) Revisando caminhos de acesso ..................................................................................................5-69 5.3.8) Algumas Regras bsicas para um SQL bem escrito...................................................................5-71

6)

Estudo de caso.............................................................................................. 6-76

6.1) Arquitetura do Oracle ......................................................................................................6-76 6.1.1) Planos de Execuo no Oracle ......................................................................................6-78 6.2 Etapas do Estudo de Caso: ................................................................................................6-81
6.2.1 Estrutura ......................................................................................................................................6-81 6.1.2.2 Comparaes entre as consultas (testes)...................................................................................6-83

7) 8)

Concluso ..................................................................................................... 7-98 Referncias bibliogrficas ........................................................................... 8-99

1) Introduo
Quando se ouve falar em DBA (Administrador de Banco de Dados DataBase Administrator), imagina-se que os mesmos cuidam freqentemente de performance e monitoramento do banco de dados. O requisito performance no pode ser algo inesperado, muito pelo contrrio, tem que ser o mais esperado e o mais projetado possvel. Grande parte dos desenvolvedores que iniciam contato com o banco de dados, na maioria das vezes sofre algum tipo de problema de performance (MULLINS, 2002). Alm desse tipo de problema, fatores de infra-estrutura (servidores, redes, entre outros) acabam contribuindo para uma performance insatisfatria. Uma parte considervel para se obter uma boa performance est contida em uma boa infra-estrutura. Essa infra-estrutura engloba servios, redes, aplicaes, banco de dados, equipamentos, entre outros. No entanto, o gerenciamento de performance, no seu contexto mais amplo, um degrau que casualmente concebe ateno. Resolver problemas de performance um trabalho complicado dentro de uma empresa. Entretanto, a tarefa da gerncia de desempenho da empresa transforma-se freqentemente em um trabalho realizado por um grupo de DBAs. Qualquer um que trabalhou como DBA sabe que ele o culpado at que prove sua inocncia quando existe um problema de performance no banco de dados. Em cada problema de desempenho, a responsabilidade cai sempre primeiro na base de dados, depois em sua verdadeira causa. DBAs precisam ser pesquisadores, para poderem ser capazes de verificar toda a fonte de degradao de performance do banco de dados, e assim provar onde est o real problema, alm do que devem conhecer pelos menos os princpios bsicos da estrutura que o banco de dados est trabalhando, como uma equipe de profissionais que trabalham com outras ferramentas que no sejam o banco de dados (operacionalizao do sistema, redes, protocolos de comunicao, etc). Possuir uma compreenso razovel em infra-estrutura vai possibilitar o DBA a resolver problemas levantados com uma maior agilidade. Existem ferramentas que gerenciam eventos para facilitar o DBA na gerncia de performance da base de dados, alertando o mesmo quando os problemas ocorrem. Por exemplo, um alerta para reorganizar o banco de dados quando ele atinge sua capacidade mxima de armazenamento de dados, ou um aviso para alocar mais memria quando a mesma est sendo utilizada ao seu limite (KOCK; KEVIN, 1997). Muitas das supostas etapas pr-ativas so na verdade problemas em aplicaes que rodam sobre o banco de dados, o que na verdade uma etapa reativa. Mantendo o DBA sempre fazendo manutenes e monitorando as aplicaes, sendo que tal problema deveria ter sido corrigido no seu incio, no projeto da aplicao. Embora muitas discusses, uma pergunta sempre questionada: O que significa o termo performance para o banco de dados? Um SGBD (Sistema de Gerenciamento de Banco de Dados) fornece a informao queles que as requisitam de forma controlada e eficiente. A taxa em que o SGBD atende a demanda por informao pode ser denominada como o desempenho do banco de dados (YANG, Y; SINGHAL, M; 1997). Para alcanar o desempenho esperado, necessria uma poltica de administrao de performance, que compreende trs componentes

especficos que precisam ser executados juntos: monitoramento, anlise, e correo (WEININGER, 2002). Esta monografia tem o objetivo de apresentar os conceitos envolvidos no gerenciamento de performance em bancos de dados, passando pelas tarefas de administrao dos elementos que influenciam no comportamento do banco de dados. Aps um estudo aprofundado do tema, foi desenvolvido um estudo de caso com dados de um banco de testes de uma empresa de grande porte, visando aplicar algumas das definies e diretrizes discutidas. O trabalho est organizado como descrito a seguir: o O captulo 2 traz uma viso geral de performance, com uma definio mais conceitual do termo. o Logo aps, o captulo 3 aborda performance de uma forma mais genrica, sem especificar uma determinada plataforma. Esse tpico foi projetado para mostrar como a performance do banco de dados pode ser afetada diretamente caso a plataforma adjacente no esteja em perfeita sincronia com o banco de dados. o Posteriormente, o captulo 4 aborda mais a questo de configurao tanto do banco de dados como do hardware (servidor) sobre o qual o mesmo vai operar. Esse contedo mostra alguns parmetros do banco de dados a serem configurados antes e durante a sua instalao, algumas configuraes do servidor que devem ser observadas antes mesmo da instalao do banco de dados (na fase de projeto), para evitar frustraes no futuro (um futuro s vezes bem prximo). o O captulo 5 trabalha mais a questo de performance de aplicao, mostrando tcnicas geralmente utilizadas por desenvolvedores ou at mesmo por DBAs com intuito de melhorar a performance de aplicaes projetadas para rodar sobre o banco de dados. Esse captulo tambm aborda a questo de planejamento, cuja idia procurar identificar e corrigir possveis problemas de performance ainda na fase de projeto, e com isso evitar ao mximo ter problemas depois que as aplicaes j esto rodando. o O estudo de caso abordado no captulo 6. Esse mostra um exemplo desenvolvido com objetivo de mostrar atravs de comparaes o ganho ou perda de performance com uso das tcnicas trabalhadas nessa pesquisa. Alm do que esse captulo tambm conta com o estudo mais aprofundado sobre um banco de dados especfico (Oracle), levando ao foco sua arquitetura e a forma como esse banco trabalha a questo de planos de execuo, entre outros. o Os captulos 7 e 8 resumemse concluso e referncias bibliogrficas utilizadas nessa pesquisa.

2)

Definio de performance em banco de dados

Uma definio mais detalhada do desempenho da base de dados seria considerar cinco fatores que influenciam o desempenho, sendo esses: workload, throughput, recursos, otimizao e concorrncia (SILBERCHATZ; KORTH; SUDARSHAN, 1999). O workload uma combinao de transaes, de trabalhos em grupo, de perguntas, da anlise e armazenamento dos dados. s vezes o workload varivel (como em um comeo de ms aps processar a folha de pagamento de todos os funcionrios de uma empresa, ou manter o funcionamento tranqilo aps as 19:00 h, quando a maioria dos usurios terminou o expediente). O workload total tem um impacto fundamental no desempenho da base de dados. O throughput define a potencialidade total do computador para processar dados. um composto do sistema operando-se de um software. As ferramentas do sistema e do software so conhecidas como recursos. Os exemplos dos recursos incluem o ncleo da base de dados, dispositivos de armazenamento do disco, dispositivos de memria de acesso aleatrio, controladores e microcdigos. Todos os tipos de sistemas podem ser otimizados, mas as bases de dados relacionais se destacam. Essa tarefa envolve muitos fatores, como os parmetros dos aplicativos e da base de dados, alm de elementos externos. Quando a demanda para um recurso particular elevada, a disputa pode resultar em um problema de otimizao gerando concorrncia entre dois ou os mais componentes do workload. Enquanto a concorrncia aumenta, o throughput diminui. As aplicaes comunicam-se regularmente com outros subsistemas e componentes da infra-estrutura. Entretanto, sbio colocar limites para as responsabilidades da equipe de DBAs. Se a tarefa no for de responsabilidade da equipe de DBAs, requer provavelmente a percia de outros tcnicos (administradores de redes, etc) (CARATTI, 2004).

2.1) A regra 80/20

A regra 80/20, tambm conhecida como o Princpio de Pareto, uma velha regra que declara que 80% dos resultados vm de 20% dos esforos. Esta regra normalmente aplicvel maioria dos esforos. Assim se existir perspectiva de melhoria de performance no banco de dados, o DBA sbio concentrar seus esforos primeiro nas provveis causas dos problemas, porque ele receber um retorno alto do investimento feito nessas otimizaes, por exemplo: Junes utilizadas de forma imprpria (loop, merge, etc); Cdigos SQL em aplicaes ineficientes; Formulao de consultas e subconsultas ineficientes (exists, not exists, in, not in); Comandos que degradam performance utilizados de maneiras incorretas (group by, order by); Declaraes SQL que monopolizam recursos do sistema podem estar escondidas em uma centena, ou at mesmo, milhares de programas. At mesmo os usurios que

produzem consultas SQL dinmicas poderiam estar afetando severamente a performance do banco de dados. Uma aproximao boa usar um monitor de consultas SQL que identifica todo o SQL que executado em qualquer lugar em seu ambiente. Tipicamente, estas ferramentas classificam declaraes SQL, baseado na quantia de recursos que so consumidos, possvel localizar a declarao, quem a emitiu e de qual programa. De posse dessas informaes possvel trabalhar nas declaraes que apresentam maiores problemas. claro que outros fatores podem atrapalhar desempenho de banco de dados negativamente. sbio conferir o desempenho global do banco de dados e do sistema operacional do servidor periodicamente. Alguns elementos que precisam ser gerenciados so (MULLINS, 2002): Alocao de memria (buffer / cache para dados, SQL, autorizaes); Opes de login (log cache, log size, rollback segments); Eficincia de I/O (separao de tabelas e ndices no disco, tamanho da base de dados, fragmentao e extenso dos arquivos); Aplicao global e carga de trabalho do banco de dados no servidor.

2.2) Componentes que definem a performance de um sistema

Uma aplicao de banco de dados requer iterao constante entre recursos para poder operar de maneira eficaz. Realisticamente, entretanto, a performance de uma aplicao de banco de dados pode ser demonstrada em trs componentes: performance da plataforma, performance do banco de dados, e performance de aplicao. Realmente, todas estas reas so aspectos relacionados performance e requerem uma aproximao integrada. Porm, para um melhor entendimento estas reas sero discutidas separadamente. 2.2.1) Performance da plataforma subjacente Performance de sistema acontece ao nvel mais baixo tendo o maior impacto global, isso porque toda aplicao depende do sistema. Nenhuma aplicao bem otimizada vai ajudar um banco de dados quando o servidor estiver contendo poucos recursos, ou recursos instalados indevidamente, ou quando um sistema operacional mal implementado e estiver causando problemas de desempenho (FANDERUFF, 2003). O sistema de gerenciamento de banco de dados (SGBD) sofre interferncia direta da plataforma. Memria, disco, CPU (unidade central processamento), outros recursos, e qualquer opo de configurao, tanto do servidor como do sistema operacional pode modificar a performance da aplicao de banco de dados. Ento, um problema de servidor ou sistema operacional pode fazer todos os bancos de dados e aplicaes serem executados de forma ineficiente. Tais problemas afetam o banco de dados que por sua vez pode causar problemas em todas as aplicaes que acessam informaes contidas no mesmo. imperativo que o DBA entenda do ambiente do sistema operacional onde a aplicao de banco de dados rodada. Ele deve poder facilitar mudanas a qualquer

componente do sistema para melhorar o ambiente do banco de dados. Claro que, ento no pode ser esperado que o DBA seja um perito em todos os aspectos do sistema, nesse caso precisa trabalhar com outras equipes dentro da organizao para iniciar as devidas mudanas (KOCK; KEVIN, 1997). 2.2.2) Performance de SGBD Desempenho pode ter um impacto fundamental devido estrutura fsica do banco de dados, inclusive a normalizao, armazenamento de disco, nmero de tabelas, desempenho de ndice. O local fsico de arquivos de banco de dados em sistemas de disco ter um impacto fundamental no desempenho de aplicaes que acessam os dados. Como grandes volumes de dados geralmente so armazenados no mesmo dispositivo de disco, existe a possibilidade de degradao de performance. A organizao do banco de dados que muda com o passar do tempo. A forma como dados so inseridos, atualizados e removidos pode prejudicar a eficincia do banco de dados, degradando a performance global (SILBERCHATZ; KORTH; SUDARSHAN, 1999). Desta forma, deve haver um monitoramento do banco de dados, incluindo, por exemplo, arquivos de dados e ndices, que precisam ser analisados e ajustados para que eles no proporcionem um impacto negativo. 2.2.3) Performance de Aplicaes A prpria aplicao deve ser projetada adequadamente e deve ser monitorada para manter uma boa eficincia. A maioria dos peritos concorda que at 75% de problemas de desempenho causado atravs de aplicaes impropriamente codificadas. SQL o culpado primrio; codificar declaraes de SQL eficientes pode ser complicado. Desenvolvedores precisam ser ensinados como formular corretamente, monitorar, e melhorar declaraes de SQL. Porm, no so todos os problemas de aplicao cujo culpado o SQL impropriamente codificado. A linguagem da aplicao (cdigo) no qual o SQL foi embutido pode estar causando o problema. Por exemplo, o Java, COBOL, C++, podem ser ineficientes a ponto de prejudicar a performance do banco de dados.

2.3) Gerenciamento de Performance

Alguns profissionais acreditam que o processo de otimizao comea com as reclamaes dos usurios. Normalmente, esse momento se demonstra tardio para aplicar algumas das estratgias eficazes de melhoria de performance, e na maioria das vezes, o real problema acaba sendo adiado ao invs de resolvido. A anlise pr-ativa sobre a performance do sistema a abordagem mais eficiente e evita esse cenrio. Para que isso seja possvel, preciso que os executivos da empresa colaborem com os projetistas, no sentido de estabelecer metas justificveis de performance, fixando expectativas reais desde o incio (CARATTI, 2004).

O estudo de desempenho tambm deve levar em considerao o tipo de aplicao, pois sistemas com diferentes propsitos podem requerer abordagens especficas. Contudo, alguns passos das anlises pr-ativa so comuns a todos os sistemas. O processo de otimizao um ciclo que pode ser percorrido mais de uma vez. Note tambm que a performance alcanada em alguns passos pode abrir caminho para passos anteriores adicionais, gerando a necessidade de se retroceder algumas etapas do processo (MULLINS, 2002). Para se obter um bom resultado em performance global necessrio atuar em todas as fases do desenvolvimento de um sistema de informao: 1. Regras do negcio Visa adaptar as necessidades do sistema aos objetivos da performance. Entre as questes relacionadas a esta fase esto o nmero de usurios simultneos, tempo de resposta por transao e nmero de registros em cache que o aplicativo frontend suporta. 2. Projeto de dados Nesta fase importante organizar as estruturas de dados de modo que se atinja o melhor desempenho. Em alguns casos, interessante desnormalizar o projeto, em prol da performance. 3. Projeto de aplicaes Executivos e projetistas da aplicao devem traduzir metas em um projeto eficaz. Um exemplo seria um sistema que utiliza vrias vezes um ndice dirio. O ndice poderia ser calculado uma vez pela manh, evitando a repetio do clculo durante o dia. 4. Estrutura lgica do banco de dados Inclui, por exemplo, a preocupao com o projeto de ndices. Sabe se que uma quantidade excessiva de ndices em uma tabela pode ocasionar gargalos, pois a alterao em uma coluna indexada resulta em trabalho adicional para atualizar tambm seus ndices. Em contrapartida, um nmero reduzido de ndices aumenta o tempo de resposta das consultas. 5. Operaes do banco de dados O aplicativo deve obter o mximo de vantagem da linguagem SQL e dos recursos disponveis para o aumento de performance. Lembrando sempre que no h melhoria de frases SQL que compense um projeto ineficiente. 6. Caminhos de acesso Assegure-se de que existe um acesso eficaz aos dados. Em alguns casos, pode ser interessante o uso de recursos especficos do SGBD utilizado, como ndices cluster ou views materializadas. 7. Alocao de memria A memria RAM destinada ao SGBD pode afetar positivamente a performance. A escolha deve levar em considerao que o sistema operacional tambm necessita de memria. Se uma quantidade excessiva for destinada ao SGBD, o sistema operacional pode aumentar a atividade de swap, prejudicando o desempenho do sistema como um todo. 8. Entrada e sada de dados O input/output de disco tende a reduzir a performance. Alguns procedimentos podem minimizar esse impacto, como a distribuio dos dados entre unidades de discos distintas. Fatores externos tambm devem ser levados em conta, como um antivrus rodando em paralelo ao servio do banco de dados. 9. Conteno de recursos O acesso concorrente de mltiplos usurios precisa ser gerenciado atravs da conteno de recursos. Por exemplo, devese evitar que o usurio bloqueie uma tabela inteira enquanto na realidade ele s precisa

bloquear uma linha, bem como impedir que um bloqueio de linha permanea por um tempo alm do aceitvel. O gerenciamento de performance compreende, basicamente duas tarefas: planejamento e administrao de performance, que sero detalhadas nas sees que se seguem. 2.3.1) Planejamento de performance Planejar o desempenho do banco de dados um componente crucial de qualquer implementao, o DBA precisa forjar o bsico, planejar e assegurar que aquela performance de banco de dados seja a ideal para todas as aplicaes que esto sobre o banco de dados. Um planejamento completo inclui ajuda no desenvolvimento da aplicao e monitoramento contnuo das consultas SQL que esto rodando no banco de dados. O gerenciamento de desempenho pr-ativo combina premeditao, planejamento, e automatizao para minimizar problemas de performance reativos que afetam a performance. Em outras palavras, o gerenciamento de performance pr-ativo reduz o tempo, esforo e erro humano dos envolvidos na implementao e manuteno dos sistemas de banco de dados eficientes (CARATTI, 2004). Seguindo a regra 80/20, o primeiro passo deveria ser identificar as reas mais problemticas. Porm, isto quase sempre no to fcil quanto poderia parecer. Os provveis culpados pela maioria dos problemas no banco de dados so cdigos SQL ineficientes. Isto no significa que aquele SQL em aplicao pode ser 100% melhorado, com o passar do tempo trabalhando em um banco de produo, o mesmo sofre uma certa degradao devido a outros fatores, comprometendo tambm a performance da aplicao. Esta degradao pode acontecer por muitas razes, como crescimento de banco de dados, usurios adicionais, mudanas no negcio e assim por diante. claro que se o SQL (comando bsico da aplicao) estiver ruim, logicamente o problema de performance aparece mais depressa. Problemas como os a seguir degradam o banco de dados de forma perigosa: Acesso tabela de forma completa (FULL SCAN); Falta de ndices apropriados; Escolhas indexadas de forma incorretas; No utilizao de ndices disponveis; Estatsticas de banco de dados inadequadas; Unio e ordenao entre tabelas. Idealmente, DBAs e desenvolvedores deveriam desenvolver aplicaes utilizando uma metodologia. Tal metodologia tem que enderear o ciclo de vida do desenvolvimento da aplicao, incorporando tticas para alcanar a performance adequada. Problemas identificados mais cedo no ciclo de desenvolvimento so mais fceis e mais simples de corrigir e tem menos problemas do que descobrir um problema desses com a aplicao rodando. Planejamento pode reduzir o custo de

desenvolvimento de aplicao, porque acontece antes da aplicao ficar operacional em um ambiente de produo (MULLINS, 2002). Calcular o desempenho de aplicao difere de analisar e aperfeioar nicas questes de banco de dados. Um modelo bem desenvolvido mostrar o efeito global de todas as questes e como elas afetam o desempenho. Tal modelo permite o DBA aperfeioar desempenho global (JARKE, KOCH, 1984). Para criar um modelo de desempenho, necessrio um processo iterativo. Cada mudana deve ser revisada e atualizada, e seu impacto medido para efetividade. DBAs e desenvolvedores de aplicao tm que cooperar, compartilhar informao e focalizar qualquer assunto de exigncia empresarial que pode afetar os critrios de performance. 2.3.1.1) Planejamento de Nvel de Servio Gerenciamento de Nvel de Servios (SLM Service Level Management) uma metodologia de disciplina contemplando que procedimentos sero entregues queles nveis adequados de servio, aos usurios conforme prioridades empresariais e a custos aceitveis. Para planejar nveis de servio efetivos, necessrio priorizar a aplicao, identificar a quantia de tempo, esforo, e capital que podem ser gastos (MULLINS, 2002). Um nvel de servio uma medida de comportamento operacional. SLM assegura que aplicaes se comportam adequadamente, assegurando que os recursos so aplicados devidamente a essas aplicaes, baseadas na importncia delas para a organizao. Dependendo da necessidade, SLM pode concentrar-se em disponibilidade, desempenho, ou ambos. Em condies de disponibilidade, o nvel de servio poderia ser definido como 99,95% no horrio de 9:00 h a 22:00 h em dias de semana. Claro que, um nvel de servio pode ser mais especfico, enquanto que declarado o tempo de resposta comum por transaes. Para que os nveis de servio tenham xito, todas as partes envolvidas tm que concordar com os objetivos declarados para disponibilidade e desempenho. Os usurios finais devem estar satisfeitos com o desempenho das aplicaes, e os DBAs e tcnicos comprometidos em administrar o sistema segundo os objetivos da empresa. SLM uma prtica benfica: Uma disciplina de SLM robusta faz administrao de desempenho previsvel. Sem um acompanhamento preciso, como o DBA e os usurios sabero se uma aplicao est executando adequadamente? Nem toda aplicao pode, ou precisa ter um rpido tempo de resposta. Sem um acompanhamento, os usurios empresariais e DBAs podem ter expectativas diferentes. DBAs podem ajustar os recursos aplicando s aplicaes consideradas de missocrtica conforme definio do projeto. Sero controlados custos e capital gasto nas pores do negcio (LONEY; THERIAULT, 1999). 2.3.2) Administrao de performance

Administrao de performance consiste em trs componentes especficos que precisam ser executados juntos: monitoramento, anlise, e correo (WEININGER, 2002). Monitorar o primeiro componente de administrao de performance. Consiste em verificar o ambiente, sempre revisando as rotinas de forma peridica, as instalaes das ferramentas e as aplicaes. Monitorar o processo de identificar problemas. Anlise o segundo componente de administrao de desempenho. Uma tarefa monitorada pode gerar centenas ou milhares de mensagens, ou resmas e resmas de relatrios. Um monitor coleciona as informaes pertinentes que formam o desempenho de origem, baseada nessas informaes, decises referentes otimizao podem ser tomadas. Um monitor no pode tomar decises de forma independente, baseadas nas informaes que colecionou. Isto requer anlise-a anlise que executada tipicamente por um tcnico qualificado. A ao corretiva o terceiro componente de administrao de performance. Algumas ferramentas de desempenho permitem o tcnico automatizar certos aspectos de administrao de performance dando o chute inicial em aes corretivas automaticamente. Porm, a maioria destas ferramentas est limitada. Alm disso, um tcnico qualificado precisa montar a automao para ter certeza que o passo de otimizao apropriado dado no momento correto. Eventualmente ferramentas de administrao de performance e solues ficaram inteligentes - com a construo em conhecimento de como aperfeioar um SGBD e com a habilidade para aprender o que trabalhar melhor. Administrao de desempenho s pode ser alcanada usando um plano de desempenho pr-ativo. Muitos problemas podem ser identificados e solues traadas com antecedncia, durante o planejamento antes que uma emergncia acontea. Com um prprio plano, correes de problemas de desempenho ficam mais fceis, e realmente, alguns problemas de desempenho podem ser evitados (SILBERCHATZ; KORTH; SUDARSHAN, 1999). Administrao de desempenho reativo no , em si mesmo, uma coisa ruim, mas manual, consome mais tempo no processo. 2.3.2.1) Ferramentas de Administrao de Performance Ferramentas de banco de dados so teis para administrar a performance do banco de dados efetivamente. Alguns vendedores de SGBD provem opes embutidas e empacotam ferramentas para facilitar administrao de desempenho de banco de dados. Porm, estas ferramentas so freqentemente insuficientes. Felizmente, algumas ferramentas de grande escala administram o desempenho de aplicaes em misses crticas efetivamente. Essas permitem DBAs obter uma boa performance do banco de dados. Existem duas categorias principais: administrao de desempenho e otimizao de desempenho (LONEY; THERIAULT, 1999). Muitos tipos diferentes de ferramentas de administrao de desempenho esto disponveis: Monitores de performance permitem aos DBAs e analistas medir o desempenho das aplicaes que acessam bancos de dados de trs modos: tempo real, tempo aproximado (intervalos), ou baseado em tendncias histricas.

Ferramentas de estimativas de performance provm estimativas de desempenho de programas inteiros e declaraes SQL baseado em caminhos de acesso, ambiente operacional. Ferramentas de anlise de performance SQL provem de descries textuais referentes a caminhos de acesso determinado pelo otimizador relacional. Estas ferramentas podem executar contra declaraes SQL ou programas inteiros. Ferramentas auxiliares aumentam anlise de SQL utilizando ferramentas de performance, provendo uma base de conhecimento que possibilita reformular SQL para timo desempenho. Ferramentas avanadas podem mudar o SQL automaticamente baseado nos projetos de codificao na base de conhecimento. Na categoria de otimizao de desempenho, podem ser usadas vrias ferramentas para performance de bancos de dados: Ferramentas de reorganizao automatizam o processo de reconstruir bancos de dados otimizadamente organizados. Bancos de dados podem causar problemas de desempenho devido sua organizao interna (por exemplo, fragmentao, ordenao de fila, distribuio de armazenamento). Ferramentas de compresso permitem DBAs minimizarem a quantia de armazenamento de disco, enquanto reduzem a utilizao global do disco, e assim, possivelmente, melhora a questo do tempo de execuo do programa, porque menos I/O pode ser requerido. importante notar que ferramentas de compresso tambm podem aumentar consumo de CPU devido aos algoritmos de compresso e descompresso de dados. Ferramentas de ordenao podem ser usadas para ordenar dados antes de carregar bancos de dados para assegurar que os registros estaro em uma sucesso predeterminada. Adicionalmente, ferramentas podem ser usadas em lugar de ORDER BY ou GROUP BY SQL. Registros recuperados de um banco de dados relacional atravs de SQL so mais usados e mais eficientes. O DBA precisa freqentemente usar estas ferramentas juntas, acessveis de um console de administrao central. Isto permite o DBA executar desempenho de performance de forma orientada. Muitos vendedores de SGBD provem solues para s administrar os bancos de dados, como por exemplo: Oracle Provides, Oracle Enterprise Manager, Sysbase Provides, SQL Central, entre outros. Porm, outros vendedores provem opes mais robustas que agem por ambientes heterogneos como servidores de banco de dados diferentes ou sistemas operacionais mltiplos.

2.4) O papel do DBA

Vrias so as tarefas de um DBA, que incluem planejamento, instalao, atualizao, monitoramento e medidas corretivas, alm de polticas de acesso, backup

e expanso. Esta seo discute as principais tarefas e em que elas podem afetar a performance de um sistema de banco de dados. Planejar a infra-estrutura: antes da implantao de um banco de dados, importante que o DBA conhea a demanda de informao da empresa, com a finalidade de definir uma infra-estrutura que a complete. Isso ir assegurar um ambiente computacional compatvel com o esperado, evitando surpresas. Por exemplo, o investimento de hardware e software pode no suportar a demanda de recursos do sistema em produo. Tambm importante que o DBA conhea e configure o sistema operacional de acordo com as necessidades do sistema gerenciador de banco de dados (SGBD) utilizado (CARATTI, 2004). Instalar o SGBD e ferramentas de suporte: alm de definir o produto de software e a plataforma de hardware, o DBA deve cuidar da instalao e atualizao do SGBD. Antes de uma atualizao de verso, necessrio analisar o impacto que pode ser causado nos sistemas que utilizam o banco. Na mesma direo, as ferramentas de suporte podem ser um diferencial na qualidade do servio prestado pelo administrador. O ideal escolher um conjunto de ferramentas que aliviem o DBA das atividades rotineiras e sujeitas a erros (CARATTI, 2004). Configurar os componentes fsicos e lgicos: esta etapa tem o objetivo de reduzir a conteno de recursos e gargalos, definindo corretamente a distribuio de arquivos fsicos do banco, estrutura de tabelas, tipo de dados, ndices, entre outros (BOSCATTO, DAMINELLO, 1999). Realizar modificaes e dar apoio equipe de desenvolvedores: em muitos casos, a necessidade de alterao no banco de dados causada pela falta de planejamento adequado, sendo uma medida reativa. Se isso acontecer, o ideal mapear o problema como um todo, diminuindo novas solicitaes de alterao no futuro. Alm disso, o DBA, antes de efetuar qualquer modificao, deve realizar uma anlise de impacto, a fim de no introduzir outras complicaes ao sistema. Vale notar que as solues prativas sempre so mais eficientes (FANDERUFF, 2003). Criar usurios e definir seus perfis de acesso: estar de acordo com a poltica de segurana da empresa e definir padres de acesso que garantam a integridade dos dados mais um requisito para o administrador. Essa tarefa inclui a definio dos recursos que cada usurio pode acessar. Controlar e monitorar o acesso dos usurios: funo do DBA acompanhar e controlar acesso aos dados, procurando por situaes atpicas. O objetivo detectar possvel falha de segurana nas aplicaes ou aes mal intencionadas. Monitorar a performance do banco de dados: o monitoramento, de usurio ou de performance, uma atividade diria. Cabe ao DBA analisar comportamentos no esperados, incluindo reduo de desempenho e consultas ineficientes, bem como condies gerais do SGBD e do sistema operacional. Entre os objetivos dessa rotina est a deteco de problemas potenciais, como verificar se existe um nmero

crescente de acessos simultneos aos dados. Nesse caso particular, o administrador deve tomar medidas para diminuir a degradao da performance de acesso, evitando uma futura interrupo do sistema (FANDERUFF, 2003). Auditar as atividades do banco de dados: entende-se por auditoria, nesse caso, como a atividade de investigar aes efetuadas por usurios. Por exemplo, identificar qual o usurio excluiu dados, em que data, hora e por qual aplicao. Implementar a estratgia de Backup e Recovery: informaes como disponibilidade do banco durante essa atividade, tempo de recuperao em caso de desastre e perodo no qual as informaes antigas devem ser mantidas so alguns entre os diversos parmetros que o DBA deve analisar para implantar o sistema de Backup e Recovery. Sendo a pessoa responsvel pela integridade das informaes da empresa, o administrador deve se preocupar em efetuar testes regulares sobre o sistema de backup comprovando sua eficcia (CARATTI, 2004). De forma geral, no que se refere otimizao e integridade, fundamental a utilizao de mtodos pr-ativos, que incluem atividades exercidas antes da existncia do propsito banco de dados. O DBA deve estar presente em todos os passos referidos neste texto, dando apoio equipe de arquitetos e buscando sempre a qualidade na manuteno dos dados, que se tornaram o bem mais valioso nas empresas. A organizao sbia implementar um desempenho monitorado intensivo visando tunning, o ambiente, procedimentos, ferramentas de administrao, desempenho integrado e utilitrios (BOSCATTO, DAMINELLO, 1999). Nesse sentido, algumas diretrizes so indicadas para atingir um bom nvel de qualidade nas tarefas de administrao de banco de dados: Trabalhar na otimizao de desempenho de acordo com o negcio: a maioria dos DBAs mais feliz por arregaar as mangas e obter conhecimentos tcnicos minuciosos do SGBD. s vezes isto requerido. Porm, como DBA, deve-se lembrar sempre dos objetivos empresariais dos bancos de dados e aplicaes ao qual administra. sbio administrar desempenho baseado nas expectativas e oramento dos usurios empresariais. Embora pudesse ser um desafio intelectual interessante mudar a performance de uma consulta para seu melhor desempenho, isso em muitas vezes pode levar o DBA a executar funes que no so diretamente suas. Manter-se focado: o DBA deve entender a meta de cada tarefa que executa e permanecer focalizado nisto. Isso importante porque o banco de dados complexo, e quando se est trabalhando a performance de uma rea, pode-se achar problemas em outra rea. Nesse caso, melhor documentar o que foi encontrado deixar para depois, e continuar a tarefa inicial de tunning. No ser paranico: esperado que o DBA saiba tudo o banco de dados que ele administra. Porm, esta uma expectativa irracional. "Eu no sei, mas eu descubro um das frases mais importantes em seu arsenal de comunicaes. Um DBA bom sabe onde procurar respostas e a quem pedir ajuda.

Comunicar-se claramente: comunicao fundamental para assegurar as propriedades do tunning em sistemas de banco de dados de alto desempenho. O DBA deve estar ao centro daquela comunicao coordenando discusses entre os usurios empresariais, programadores e gerentes. Aceitar a realidade: muitas organizaes falam sobre ser prativas, mas na realidade tem muito pouco interesse em solucionar problemas de desempenho antes que eles aconteam. Ainda, toda organizao est interessada em fixar problemas de desempenho depois que os problemas acontecem. Este pode ser um ambiente frustrante para o DBA que preferiria montar manuteno preventiva para o ambiente de banco de dados. Isto requer oramento, tempo, e esforo dos quais provm em resumo das organizaes de TI. Como um DBA, voc deve estar s vezes contente em aceitar a realidade e lidar com problemas, da forma como eles acontecem.

3) Gerenciamento subjacente

de

performance

da

plataforma

Um SGBD opera dentro do contexto de um ambiente muito maior que consiste em software e componentes de hardware. Cada um destes componentes deve ser instalado, deve ser configurado, e deve ser administrado efetivamente para que o SGBD tenha interao com o hardware de servidor, sistema operacional e qualquer outro software exigido. Performance e configuraes destes componentes e conexes corretamente podem ter um impacto dramtico em desempenho de sistema (CARATTI, 2004).

3.1) Interao com o Sistema operacional

Quando o sistema operacional apresenta um problema de performance, todo software que trabalha sobre o operacional pode apresentar problemas de performance. Para ajudar na escolha correta das configuraes do sistema operacional, o DBA deveria fazer algumas perguntas (MULLINS, 2002). Uma quantia suficiente de memria foi alocada para tarefas de sistema operacional? A maioria dos sistemas operacionais tem capacidade de alocar uma quantia especfica de espao de disco como uma rea de troca. A troca usada quando o SO necessita de memria. Uma quantia suficiente de espao de disco foi alocada rea de troca? Como os arquivos de banco de dados foram alocados quando o banco de dados foi implementado? Mudando o banco de dados, arquivos usados em discos, SO e sistema de arquivo podem estar sendo eliminados? Alguns sistemas operacionais permitem o administrador fixar a prioridade de tarefas a serem executadas pelo sistema operacional. Existe banco de dados relacionais ordenados por prioridade.A prioridade apropriada para aquela tarefa especfica? O sistema operacional est com a verso adequada segundo o vendedor do banco de dados? O servidor do banco de dados est trabalhando de forma adequada ao necessrio para o funcionamento correto do banco? Os parmetros de configurao de sistema operacional foram modificados quando o SGBD foi instalado? Nesse caso, existe prova suficiente para assegurar que os parmetros foram modificados corretamente e no causam problema a qualquer outro processo que trabalha no servidor de banco de dados?

3.2) Arquiteturas de Sistemas

A arquitetura do sistema de informao tambm afeta diretamente a sua execuo, influenciando na performance global. importante definir qual a arquitetura mais adequada para cada situao.

3.2.1) Sistemas Centralizados So sistemas executados em um nico ambiente computacional, composto de um ou vrios processadores trabalhando de forma concorrente. Porm esses processadores possuem memria cache locais e executam operaes distintas quando acionados ao mesmo tempo, acionam dispositivos distintos (exemplo, drive de disco, dispositivo udio e vdeo, etc) ou executam processos distintos. Os vrios processadores podem trabalhar concorrentemente, compartilhando o acesso memria (memria principal, no memria cache). A memria cache parcialmente reduz a conteno de acessos memria principal, uma vez que reduz o nmero de tentativas de acesso da CPU memria compartilhada (SILBERCHATZ; KORTH; SUDARSHAN, 1999). 3.2.2) Sistemas Cliente / Servidor So sistemas concentrados em um nico servidor, possuem estaes ligadas a esse servidor que requisitam solicitaes. As estaes se encarregam de tarefas simples como executar as ferramentas para acesso aos dados (sistema que far acesso aos dados), abrir determinadas ferramentas de apoio gerao de relatrios e grficos para processamento dos mesmos, etc. O servidor se encarrega de receber as solicitaes das estaes, processar as solicitaes, gerar o resultado e devolver para a estao solicitante. Esse o tipo de arquitetura mais conhecida e utilizada atualmente, e possui vantagens como: deixa apenas o processamento das solicitaes para o servidor e as estaes se encarregam de todo o resto (execuo das aplicaes necessrias para exibio dessas informaes), entre outros. Porm existem desvantagens, ficam dependentes de uma rede com bom sistema de comunicao e com trfego de informao tolervel a ponto de no prejudicar seu funcionamento. Caso a rede no esteja em boas condies, pode comprometer a performance da solicitao, logicamente da aplicao (causando problema de performance) (SILBERCHATZ; KORTH; SUDARSHAN, 1999). Os sistemas cliente-servidor podem ser agrupados em duas categorias: os sistemas servidores de transaes e os sistemas servidores de dados. Os sistemas servidores de transao, tambm chamados de sistemas servidores de consultas, proporcionam uma interface por meio da qual os clientes podem enviar pedidos para determinada ao e, em resposta, eles executam a ao e mandam de volta os resultados ao cliente. Usurios podem especificar pedidos por SQL ou por meio de programa de aplicao usando um mecanismo de chamada remota do procedimento. Os sistemas servidores de dados permitem que os servidores interajam com os clientes que fazem solicitaes de leitura e atualizao de dados em unidades como arquivos ou pginas. Por exemplo, servidores de arquivos proporcionam uma interface sistemaarquivo na qual os clientes podem criar, atualizar, ler e remover arquivos. Servidores de dados para sistema de banco de dados oferecem muito mais recursos: do suporte a unidades de dados como pginas, registros ou objetos menores que um arquivo. Proporcionam meios para indexao de dados e transaes,

tais que os dados nunca se tornem inconsistentes se um equipamento cliente ou processo falhar. 3.2.3) Sistemas Paralelos Sistemas paralelos imprimem velocidade ao processamento e ao I/O por meio do uso em paralelo de diversas CPUs e discos. Equipamentos paralelos esto se tornando bastante comuns, fazendo com que o estudo de sistemas de bancos de dados paralelos seja tambm cada vez mais importante. Os direcionamentos das atenes para os sistemas de bancos de dados muito grandes provem da demanda de aplicaes que geram consultas em bancos de dados muito grandes (da ordem de terabytes - 1012 bytes) ou que tenham de processar um volume enorme de transaes por segundo. Sistemas de banco de dados centralizados e clienteservidor no so poderosos o suficiente para tratar desse tipo de aplicao. Em um processamento paralelo, operaes so realizadas simultaneamente, ao contrrio do processamento serial, no qual os passos do processamento so sucessivos. Um equipamento paralelo de granulao grossa consiste em poucos e poderosos processadores; um paralelismo intensivo ou de granulao fina usa vrios pequenos processadores. A maioria das mquinas (servidores), atualmente, oferece algum grau de paralelismo de granulao grossa: dois a quatro processadores em uma nica mquina j comum. Computadores de paralelismo intensivo podem ser diferenciados dos equipamentos de paralelismo de granulao grossa pelo grau de paralelismo. So duas as principais formas de avaliar o desempenho de um sistema de banco de dados. A primeira o throughput: o nmero de tarefas que podem ser realizadas em um dado intervalo de tempo. A segunda o tempo de resposta: o tempo total que o sistema leva para completar uma nica tarefa. Um sistema que processa um grande nmero de pequenas transaes pode aumentar o throughput por meio do processamento de diversas transaes em paralelo (SILBERCHATZ; KORTH; SUDARSHAN, 1999).

3.3) Configurao de Agentes Aliados

Para se avaliar o SGBD tem que se aliar muitos outros componentes de software, servios ao usurio final. Exemplos de agente aliado: Processadores de transao como CICS e Microsoft Transaction Server; Protocolo de rede como TCP/IP; Software de mensagem como MQSeries e MSMQ; Conectividade de web e software de desenvolvimento como ColdFusion; Linguagens de programao tal JAVA, COBOL e C. Cada um destes agentes aliados deve ser configurado para interagir com o SGBD corretamente, e responsabilidade do DBA entender as exigncias da organizao. Em grupos maiores o DBA poderia no executar a configurao atual e deixar isto para profissionais mais qualificados que so especializados na administrao do

respectivo software. Porm, em grupos menores o DBA pode ter que configurar todos os softwares que envolvem o banco de dados (FANDERUFF, 2003).

3.4) Configuraes de Hardware

O SGBD deve trabalhar em um computador que tenha bom hardware. Aquele hardware pode ser um amplo mainframe, um intermedirio sistema UNIX, ou um PC com Windows. Existem algumas perguntas que o DBA deveria fazer para assegurar um timo ambiente de hardware para as aplicaes de banco de dados (CARATTI, 2004): o hardware com capacidade ideal destinada para o ambiente de SGBD? Em outras palavras, o vendedor de SGBD recomenda esta implementao do hardware utilizado? Uma quantia suficiente de memria foi instalada para todo o funcionamento do software de sistema a ser instalado? Quantia apropriada de espao de armazenamento de disco foi alocada e foi configurada para uso pelo SGBD? O tipo de armazenamento de disco que est sendo usado e apropriado para grandes volumes de dados (questes referentes velocidade)? Todos os cabos de rede so conectados e funcionando corretamente? Todas as conexes fsicas so completamente conectadas e operacionais? O hardware conectado est protegido contra interrupo de energia? 3.4.1) Escolha dos meios de armazenamento Fisicamente os discos so simples, cada prato possui uma forma plana e circular. Suas superfcies so cobertas por material magntico e a informao armazenada em suas superfcies. Os pratos so feitos de metal ou vidro rgido e so cobertos (geralmente pelos dois lados) com material de gravao magntica. o meio mais usado para armazenamento de dados, geralmente um banco de dados inteiro est armazenado em um ou mais discos magnticos. Tal armazenamento o mais confivel, pois sobrevive a falta de energia, proporciona fcil movimentao (insero, atualizao ou remoo) dos arquivos que esto contidos no mesmo. Seus acessos seguem um caminho lgico, seus dados so movidos do disco magntico para a memria principal para depois serem acessados. Atualmente fcil encontrar no mercado poderosos discos com grande capacidade de armazenamento e com alto ndice de rotao. As principais caractersticas de um disco so: sua capacidade de armazenamento, o tempo de acesso, a taxa de transferncia de dados e a confiabilidade dos mesmos. O tempo de acesso o tempo gasto desde um pedido de leitura ou de escrita at o incio da transferncia dos dados. Para acessar os dados em um determinado setor do disco, primeiramente o brao deve mover-se de forma a posicionarse sobre a trilha correta e, ento deve esperar at o setor aparecer sob a cabea de leitura e escrita enquanto o disco rotaciona. O tempo de reposicionamento do disco chamado de

tempo de procura, e ele aumenta de acordo com a distncia que o brao deve se mover. Tambm necessrio escolher uma placa controladora de disco adequada para o hardware que se deseja utilizar, considerando o ambiente de execuo, para fazer a interface entre o sistema e o hardware do acionador de discos. Essa controladora aceita comandos de alto nvel para ler ou escrever em setor e inicializar as aes, tal como mover o brao do disco para a trilha executando uma leitura ou escrita de dados. Outra tarefa interessante executada pelas controladoras de disco o remapeamento de setores ruins. Se a controladora detecta que um setor est danificado enquanto o disco estiver sendo formatado, ou quando for realizada uma tentativa escrever no setor, ela pode mapear logicamente o setor para uma localizao fsica diferente (alocada de um conjunto de setores extras separados para esse propsito). O remapeamento anotado no disco ou em memria no voltil e a escrita executada em nova localizao (SILBERCHATZ; KORTH; SUDARSHAN, 1999). As controladoras so ligadas a vrios discos atravs de uma interconexo de alta velocidade. Uma dessas interconexes mais comuns a interconexo para pequenos sistemas de computador (SCSI) muito comum para conectar discos a computadores pessoais e estaes de trabalho, assim como servidores de pequenos e mdio porte. Sistemas mainframe e de servidores de grade porte possuem barramentos mais rpidos e mais caros para conectar seus discos. 3.4.2) Uso de RAID (Redundant Arrays of Inexpensive Disks) RAID nada mais que um sistema de armazenamento de arquivos composto por vrios discos. Em sua grande maioria so pequenos discos ligados e funcionando em paralelo. Possuir um grande nmero de discos ligados em paralelo proporciona vantagens como alto desempenho na escrita e leitura dos discos. A tecnologia RAID aps vrios testes foi dividida em cinco nveis, cada um com uma particularidade a ser estudada e escolhida de acordo com a necessidade de cada situao. RAID nvel 0: refere-se ao arranjo de discos com distribuio paralela baseada em blocos, sem qualquer redundncia; RAID nvel 1: espelhamento de discos, garantia de segurana, porm alto investimento. Discos so usados para espelhamento, uma espcie de backup on-line; RAID nvel 2: conhecido como cdigo de correo de erros ao estilo memria, ou seja, cada byte em um sistema de memria pode ter associado a ele um bit de paridade no qual gravado 0 ou 1. Se cada um desses bits for danificado (um 1 tornar-se 0 ou um o tornar-se 1) ento a paridade dos bits se altera, e no coincidir com a paridade gravada. Essa idia de correo de erros pode ser utilizada diretamente nos arranjos de discos por meio da distribuio paralela dos bytes pelos discos. Ex: o primeiro bit gravado no disco um, o segundo no disco dois e assim por diante at o oitavo no disco oito, logo os bits de correo de erros seriam gravados em outros discos; RAID nvel 3: uma organizao de paridade de bits entrelaados melhorando o conceito do RAID nvel 2 por meio da observao de que, diferentemente dos sistemas de memria, as controladoras de discos podem detectar se um setor foi lido corretamente, portanto um nico bit de paridade pode ser utilizado para a correo de

erros, assim como para a deteco. O conceito baseia-se na idia de que se um dos setores for danificado, sabemos exatamente qual foi o danificado por meio do clculo de paridade dos bits correspondentes dos setores dos outros discos. Esse nvel traz vantagens como um nmero reduzido de discos, porm traz desvantagens como a baixa taxa de I/Os por segundo, j que cada disco deve participar de cada solicitao de I/O; RAID nvel 4: organizao de paridade de blocos entrelaados armazena blocos exatamente da mesma forma que em discos comuns, sem distribu-los pelos discos, mas mantm um bloco de paridade em um disco separado para os blocos correspondentes de N outros discos. A leitura desses blocos acessa somente um nico disco, permitindo que outras solicitaes sejam processadas pelos outros discos. Assim a taxa de transferncia de dados para cada acesso menor, mas mltiplos acessos de leitura podem ser processados em paralelo, levando a uma taxa geral de I/O mais alta, uma vez que todos os discos podem ser lidos em paralelo, a taxa de transferncia para grandes operaes de escrita alta. Em contrapartida, as operaes de escrita pequenas e independentes no podem ser executadas em paralelo. A escrita de um bloco deve acessar o disco no qual o bloco est armazenado, assim como o disco de paridade, uma vez que o bloco de paridade precisa ser atualizado. RAID nvel 5: uma melhoria do RAID nvel 4, melhoria obtida por meio de um particionamento de dados e paridade entre todos os N + 1 discos, em vez de armazenar os dados em N discos e a paridade em um nico disco. Assim, o nvel 5 aumenta o nmero total de solicitaes que podem ser atendidas em um dado espao de tempo. Para cada bloco, um disco armazena a paridade e outro os dados; RAID nvel 6: tambm chamado de esquema de redundncia P + Q, muito parecido com o RAID nvel 5, mas armazena informaes redundantes adicionais para prevenir falhas de discos mltiplas. Em vez de utilizar paridade, so usados os cdigos de correo de erros (PATTERSON; GIBSON, 1988). Tabela 1: Resumo dos nveis de RAID. RAID 0: Distribuio paralela no redundante; RAID 1: Espelhamento de disco; RAID 2: Cdigos de correo de erros ao estilo de memria; RAID 3: Paridade de bits interlaados; RAID 4: Paridade de blocos interlaados; RAID 5: Paridade distribuda de blocos interlaados RAID 6: Redundncia P + Q; Figura 3.1: A figura 1 (abaixo) ilustra os nveis RAID apresentados (SILBERCHATZ; KORTH; SUDARSHAN, 1999).

3.4.3) Organizao de arquivos e otimizao de Acessos a Blocos de Disco Requisies de I/O (input (entrada) / output (sada)) de disco so geradas tanto pelo sistema de arquivo quanto pelo gerenciador de memria virtual encontrado na maioria dos sistemas operacionais. Cada solicitao especifica o endereo do disco a ser referenciado; esse endereo est no formato de nmero de bloco. Um bloco uma seqncia contgua de setores de uma nica trilha de um prato. O tamanho dos blocos varia de 512 bytes a at vrios kilobytes. Os dados so transferidos entre o disco e a memria principal em unidades de blocos. Os nveis mais baixos do gerenciador do sistema de arquivos convertem os endereos de bloco em nmeros, em nvel de hardware, de cilindro, superfcie e setor. Algumas tcnicas que facilitam a otimizao de acessos aos blocos do disco, como agendamento e organizao de arquivos. Se diversos blocos de um cilindro precisam ser transferidos para a memria principal, pode-se economizar tempo de acesso requisitando (agendando) os blocos na ordem na qual eles passaro sob a cabea de leitura e escrita. Se os blocos desejados estiverem em cilindros diferentes vantajoso requisitar os blocos em uma

ordem que minimize o movimento do brao do disco. Algoritmos de agendamento do brao do disco so bastante utilizados. O algoritmo do elevador um exemplo, ele trabalha na forma de um elevador. Imagine que o brao do disco esteja se movendo da parte interna para a parte externa do disco. Para cada trilha onde exista uma solicitao o brao do disco pra na trilha, executando a requisio e, ento, continua a mover-se na direo da parte externa at que no haja mais solicitaes aguardando acesso a trilhas nessa direo. Feito isso o brao faz movimento inverso, logo aps chegar ao final (da parte externa) ele inverte seu percurso dirigindose a parte interna do disco, obviamente fazendo paradas caso existe alguma requisio para que o mesmo pare em uma determinada trilha (SILBERCHATZ; KORTH; SUDARSHAN, 1999). A organizao de arquivo pode reduzir o tempo de acesso aos blocos, pois eles podem ser organizados em disco de forma a corresponderem aproximadamente maneira pela qual esperamos que os dados sejam acessados. Por exemplo, se espera que um arquivo seja acessado seqencialmente, ento o ideal seria manter todos os blocos de um arquivo seqencialmente em cilindros adjacentes. Sistemas operacionais antigos, como os sistemas operacionais de mainframes IBM, fornecem aos programados um controle detalhado do posicionamento de arquivos, permitindo que o programador reserve um conjunto de cilindros para o armazenamento de um arquivo (CARATTI, 2004). Entretanto, esse controle sobrecarrega o desenvolvedor ou administrador do sistema, obrigando o mesmo a escolher, por exemplo, quantos cilindros devem ser alocados para um arquivo, e podendo exigir uma onerosa reorganizao se os dados vierem a ser inseridos ou removidos do arquivo. Sistemas operacionais mais recentes, como o Unix e os sistemas operacionais de computadores pessoais, escondem a organizao dos discos dos usurios e gerenciam a alocao interna. Entretanto, com o tempo, um arquivo seqencial pode tornar-se fragmentado; ou seja, seus blocos encontram-se espalhados por todo o disco. Para reduzir a fragmentao, o sistema pode fazer uma cpia de segurana dos dados do disco e restaurar a disco inteiro. A operao de restaurao escreve de volta os blocos de cada arquivo contiguamente (ou prxima de). Alguns sistemas possuem utilitrios que varrem o disco e movem os blocos para reduzir a fragmentao. O aumento de desempenho obtido com essas tcnicas pode ser grande, mas, geralmente, o sistema no pode ser utilizado enquanto esses utilitrios estiverem em execuo (PATTERSON; GIBSON, 1988). O uso de buffers no volteis de escrita pode ajudar, uma vez que o contedo da memria principal se perde com falhas de energia, as informaes de atualizaes de banco de dados devem ser gravadas em disco para sobreviver a possveis falhas de sistema. Por isso, o desempenho de aplicaes de banco de dados de atualizaes intensivas, tal como sistemas de processamento de transaes so muito dependentes da velocidade da escrita em disco. Pode-se utilizar, tambm, memria de acesso aleatrio voltil (RAM voltil) para aumentar drasticamente a velocidade das escritas. O contedo da RAM voltil perdido em falhas de energia. Uma maneira comum de implementar RAM no voltil a utilizao de RAM alimentada por baterias reserva. A idia que, quando o sistema de banco de dados (ou sistema operacional) solicita que um bloco seja escrito no disco, a controladora de disco escreve o bloco em buffer de RAM no voltil e, imediatamente, informa ao sistema operacional de que a escrita foi completada com

sucesso. A controladora escreve os dados em seu destino no disco somente quando o disco no tiver nenhuma outra solicitao ou quando o buffer de RAM no voltil estiver cheio. Quando o sistema de banco de dados solicita a escrita de um bloco, ele percebe a demora somente se o buffer estiver cheio. Na recuperao de uma falha do sistema, quaisquer escritas pendentes no buffer de RAM no voltil so escritas de volta no disco (FANDERUFF, 2003). Outra abordagem para reduzir a latncia de escritas a utilizao de disco de log, ou seja, um disco voltado para armazenar um log seqencial muito similar ao buffer de RAM no voltil. Todo acesso ao disco de log seqencial, eliminando essencialmente o tempo de procura, e diversos blocos consecutivos podem ser escritos simultaneamente, tornando a escrita em discos de log diversas vezes mais rpida que escritas aleatrias. Assim como antes, os dados tambm tm de ser escritos em suas localizaes reais no disco, mas essa operao de escrita pode ser feita sem que o sistema de banco de dados tenha de esperar para que ela seja completada. Aps uma falha de sistema, o sistema l o disco de log para encontrar aquelas operaes de escrita que no tenham sido completadas e ento complet-las. Um sistema de arquivos baseados em log uma verso extrema da abordagem de disco de log. Os dados no so escritos de volta em seus destinos originais no disco; em vez disso, o sistema de arquivos mantm informaes de onde os blocos foram escritos mais recentemente no disco de log e os recupera dessa localizao. O prprio disco de log compactado periodicamente, fora que escritas antigas que tenham sido reescritas posteriormente possam ser removidas. Essa abordagem aumenta o desempenho da escrita, mas gera um alto grau de fragmentao para arquivos que so atualizados com freqncia (SILBERCHATZ; KORTH; SUDARSHAN, 1999).

4) Gerenciamento de performance de SGBD

Um SGBD um sistema muito complexo que requer centenas de milhares de linhas de cdigo. Um SGBD to complexo que so requeridos programas mltiplos a desenvolver a funcionalidade de administrao de dados requeridos. O DBA tem que estudar a estrutura do SGBD e tem que ganhar uma compreenso de cada componente e como ele se integra com os outros componentes do banco de dados. O DBA tem que se tornar um perito nos funcionamentos internos do SGBD para assegurar um ambiente aperfeioado para aplicaes de banco de dados. Um fracasso ou problema em qualquer nico componente do SGBD pode causar degradao de desempenho severa para toda aplicao que acessa o banco de dados (LONEY; THERIAULT, 1999).

4.1) Parmetros de configurao

Todo sistema de administrao de banco de dados prov parmetros que permitem o DBA configurar vrios aspectos do ambiente de banco de dados. Configurao acompanhada por uma variedade de modos dependendo do SGBD. Alguns mtodos de configurao populares incluem execuo de procedimentos de sistemas para fixar e reajustar valores, editar arquivos de parmetro e comandos emitidos a um SGBD (KOCK; KEVIN, 1997). A maioria dos SGBD vem com configuraes padro, vindas do fabricante. Porm, estes padres geralmente no so suficientes para apoiar o desenvolvimento robusto de aplicaes de produo. Esta seo discutir alguns dos parmetros de configurao comuns e como os configurar. O banco de dados pode ser configurado na sua instalao ou depois que j est sendo utilizado. Durante instalao, o DBA instala os componentes necessrios para possuir mais opes de configuraes, baseando-se no conhecimento dos dados e aplicaes que estaro usando o SGBD. Uma vez que o SGBD instalado, ele prov mtodos de mudar os parmetros de configurao. Dependendo do SGBD, podem ser mudados parmetros dinamicamente, no dinamicamente, ou ambos. Parmetros dinmicos podem entrar em vigor sem a necessidade para reiniciar servidor. Depois de emitir os comandos apropriados, as mudanas de valores e parmetros, o SGBD se comportar adequadamente (MULLINS, 2002). Para que os parmetros no dinmicos entrem em vigor, o SGBD deve ser fechado e reiniciado. 4.1.1) Uso de Memria Uma das maiores tarefas de um DBA em se tratando de tunning de sistema, configurar o uso correto de memria do banco de dados. O SGBD usa memria cache de acesso a dados e outros recursos requeridos. Isto porque ler dados de memria muito mais eficiente que ler os dados de disco (questo de performance). Desta forma, o SGBD tem que ser configurado para usar a memria corretamente.

4.1.1.1) A importncia da cache O dicionrio American Heritage define cache como "um lugar por guardar valores de preciosidades (SILBERCHATZ; KORTH; SUDARSHAN, 1999). Este um ponto de partida para entender o que cache significa a um banco de dados. O "lugar" usado pelo SGBD memria (ao invs de disco). As "preciosidades" so os dados, consultas, planos de execuo, e outros recursos de banco de dados. Um SGBD tpico usar memria cache para manter recursos mais tempo em memria. Quanto mais longo o tempo que um recurso ficar alocado em memria cache, melhor a chance para pedidos subseqentes ao recurso, evitando operaes caras de I/O (KOCK; KEVIN, 1997). H muitos blocos de memria cache utilizados pelo SGBD para reduzir o custo de I/O. Cada SGBD usa terminologia diferente, mas geralmente cache so usadas para os mesmos recursos. Um dado em cache usado para evitar operaes de I/O quando dados atuais estiverem sendo lidos no banco de dados, pois acessar dados em memria substancialmente mais rpido que acessa-los em disco. Ento, os dados de um banco de dados (relacional) passam por uma rea de caching. Acesso memria est tipicamente medido em micro segundos, enquanto acesso ao disco I/O normalmente em milisegundos. Quando um programa precisar de uma linha contida em uma tabela, o SGBD recupera a pgina de disco e aloca a pgina na cache de dados. Se a linha mudar, a mudana escrita pgina na cache de dados. Eventualmente, o SGBD escrever de volta a pgina na cache de dados para disco. Quando os dados forem requeridos por uma aplicao, se j esto na cache de dados, a aplicao no ter que esperar pela pgina a ser carregada em disco. Dependendo do SGBD, esta estrutura de memria tambm pode ser chamada buffer pool (KOCK; KEVIN, 1997). O processo de otimizao de uma instruo SQL cria como estrutura interna que representa o caminho de acesso que ser usado pelo SGBD para ler os dados. O SGBD pode armazenar estes acessos a caminhos no procedimento cache e os usar de novo a cada vez que o programa executa uma solicitao SQL. Isto aperfeioa desempenho de aplicao porque a necessidade de processo de otimizao no realizada toda vez que o SQL executado. Ao invs, a otimizao acontece na primeira vez que o SQL emitido, e execues subseqentes utilizam o caminho de acesso ao cache de procedimento (MULLINS, 2002). O SGBD tambm tem log de registros armazenados em buffer separados dos logs de cache do banco de dados. Alm disso, o SGBD pode implementar dois logs de cache, um para escrita e outro para leitura. O log de banco de dados mantm um registro de todas as mudanas feito ao banco de dados. O log escreve em cache para acelerar modificaes de banco de dados. Os dados mudados so escritos em log de cache, e com o passar do tempo a cache escrita a disco. O rollback e recovery sempre acessam o log do banco de dados. Um rollback ou uma recuperao precisa acessar o log para desfazer ou reaplicar mudanas feitas no banco de dados. Como so pedidos os registros de log, eles ficam armazenados em buffer at o banco de dados ler a memria cache (LONEY; THERIAULT, 1999).

O desempenho do cache de dados depende de como eficazmente a memria foi alocada para seu uso. Por exemplo, se pginas indisponveis dominarem o cache de dados, o SGBD pode ativar o mtodo sncrono para escrever e aumentar o espao no cache de dados. Escrita sncrona pode reduzir a velocidade de processamento do banco de dados porque cada pedido de escrita tem que esperar pelos dados a serem escritos de fato fisicamente no disco. Dependendo do tipo de processamento que as aplicaes de banco de dados esto usando, o DBA pode afinar parmetros de caching de dados e tamanhos para habilitar proteo mais eficiente de dados (SILBERCHATZ; KORTH; SUDARSHAN, 1999). 4.1.1.2) Dimensionamento da memria Alm dos vrios caches e buffers usados por sistemas de banco de dados relacional, memria tambm requerida para outros propsitos. Geralmente, na instalao do SGBD, rotinas de configurao permitem para o DBA alocar e afinar o consumo de memria do SGBD. Algumas das reas mais comuns de SGBD consomem memria: Conexes de usurio: Cada conexo de usurio requer memria para o SGBD manter e administrar a conexo; Dispositivos: Os dispositivos usados por bancos de dados podem requerer memria para o sistema manter e usar os mesmos; Bancos de dados abertos: A maioria do SGBD prov um parmetro para especificar o nmero de mximo de bancos de dados que podem estar abertos de uma vez. Cada banco de dados aberto requer memria de SGBD; Objetos abertos: Outro parmetro pode existir para identificar o nmero de mximo de objetos de banco de dados que podem estar abertos de uma vez, tabelas, ndices, e qualquer outro objeto de banco de dados em uso. Cada objeto de banco de dados aberto requer memria; Locks: Cada lock simultneo requer memria. O SGBD deveria prover um parmetro de configurao para o nmero de locks simultneas que podem ser utilizados de uma vez; Uma das principais definies quanto ao uso de memria de um SGBD a quantidade de memria que deveria ser alocada. Todo SGBD usa memria, mas em quantias diferentes para coisas diferentes. A melhor aproximao procurar a documentao do SGBD para determinar quanta memria requerida para cada recurso. Ento, pode-se calcular as exigncias de uso para cada recurso e pode calcular a quantia aproximada de memria requerida pelo SGBD. Por exemplo, o SQL Server requer aproximadamente 75 bytes de memria por lock. Para configurar a quantia de memria requerida por lock, o DBA precisar calcular o nmero total de transaes simultneas e o nmero comum de locks por transao (MULLINS, 2002). O clculo para memria requerida pelo SGBD para lock simples: Locks concorrentes = [# transaes concorrentes] * [# transaes por lock] * 75

O resultado deste clculo prov uma estimativa para a memria (em bytes) usada por lock em um sistema SQL Server. Claro que, o nmero de transaes simultneas e o nmero de locks por transao pode ser difcil de averiguar dependendo do ambiente. Voc pode substituir o nmero de transaes simultneas com o SGBD configurando o nmero de total de conexes de usurio. Se locks/transaes so indisponveis, voc pode examinar alguns programas tpicos para propor uma estimativa. Este processo ento repetido para cada recurso de banco de dados que consome memria. Depois de repetir este processo para cada recurso, chega-se quantia de memria estimada para instalar para o servidor de banco de dados. uma prtica deixar uma certa rea de memria para apoiar a adio de programas e aplicaes inesperadas, atualizar aes do SGBD que requerem memria adicional, e outros elementos imprevistos. Isto significa instalar um pouco mais memria que a quantia mostrada no clculo. Porm, no deixe muita memria livre. A memria foi instalada para ser usada, no conservada. Ainda no quesito dimensionamento, assegurar o tamanho da cache um dos aspectos mais crticos de ter um cache de dados eficiente. Os dados muito grandes que ficam em memria sem utilidade podem causar problemas no armazenamento do cache de dados. Uma cache de dados muito pequena, causa em muitas vezes em escrita em disco (swapping), causando assim problema de lentido (CARATTI, 2004). A complexidade de tunning de cache de dados varia por SGBD e depende da configurao dos parmetros que esto disponveis para o cache de dados. Alguns SGBDs, como DB2, provem buffer de acessos mltiplos que podem ser configuradas e podem ser ajustados independentemente com parmetros mltiplos. Outros, como SQL Server, so mais bsicos, com um cache de dados por banco de dados (LONEY; THERIAULT, 1999). A eficincia do cache de dados uma porcentagem que localiza bem o cache que est sendo executado, evitando operaes de I/O disco fsico. calculada a eficincia de cada cache de dados como o nmero de I/Os atualmente executados subtraindo do nmero total de pedido de dados, ento dividido pelo nmero total de pedidos de dados, ou: ReadEfficiency =((#database I/O request)(#physical I/Os)) / (database I/O request)

Em outras palavras, eficincia mostra a porcentagem de vezes que uma pgina de dados localizada no cache de dados. Quanto mais alto esta porcentagem, mais eficiente o buffer. O nmero atual de I/O fsico que cada operao requisita, pode ser achado examinando o SGBD, localizando os registros ou usando monitor de desempenho do banco de dados. Cada SGBD tem seu prprio conjunto de informao de instrumentao que pode ser examinada (FANDERUFF, 2003). Possibilidades adicionais para tunning de cache de dados - oferecidas por alguns vendedores de SGBD como adicionais aos produtos, incluem a criao de um cache adicional, guardando pginas especficas em memria e ajustando o tamanho do cache de dados automaticamente com aumentos de processamento.

4.1.2) Configurao do Log O log de banco de dados outra opo de configurao de sistema que pode ter impacto no desempenho. O log s vezes chamado de log de transao, um componente fundamental de um sistema de administrao de banco de dados. Todos os dados que so mudados so registrados de forma serial no log. Usando esta informao, o SGBD pode localizar qual transao fez quais mudanas ao banco de dados. Alm disso, ROLLBACK e RECOVER so operaes que utilizam o log para reajustar o banco de dados. A maneira na qual o log de banco de dados criado depende do SGBD. Alguns SGBDs especificam o log em nvel de sistema, outros definem um log para cada banco de dados que criado dentro do sistema. Alguns SGBDs provem de parmetros para habilitar e desabilitar o log. Em geral, evite desabilitar o log para qualquer banco de dados onde os dados so valiosos (SILBERCHATZ; KORTH; SUDARSHAN, 1999). Durante o processamento normal da aplicao no banco de dados, INSERTS, UPDATES e DELETES so realizados para modificar dados no banco. O log de transao crescer porque cada mudana no banco de dados gravada, portanto o DBA precisar monitorar o tamanho dos arquivos do log de transao ativamente. O log de transao escrito antes que sejam feitas mudanas de dados em tabelas. Quando a modificao for registrada completamente no log, a recuperao da transao est garantida (LONEY; THERIAULT, 1999). Tipicamente, o SGBD tem um checkpoint de sistema para garantir que todo o log registrado de forma correta e segura no disco. A freqncia com que os checkpoints de sistemas podem ser ajustados pelo DBA esto em parmetros de configurao. A freqncia de checkpoints normalmente fixa com um intervalo de tempo predeterminado ou um nmero prefixado de registros de logs escritos (JARKE, KOCH, 1984). Geralmente, a informao registrada no log do banco de dados inclui: Tempo de incio e de fim de cada transao; Mudanas atuais feitas aos dados usando "antes"/"depois " de imagens dos dados; Distribuio e realocao de pginas de banco de dados; COMMIT ou ROLLBACK de cada transao. Usando esta informao, o SGBD pode realizar operaes de integridade de dados para assegurar dados consistentes. O log de transao usado quando o SGBD reiniciado, e necessrio restabelecer um banco de dados a um estado anterior. Quando o SGBD reiniciado, cada banco de dados passa por um processo de recuperao. Durante o processo de reinicializao, o SGBD conferir para determinar quais transaes devem ser recuperadas adiante. Isto acontece para cada transao onde desconhecido se todas as modificaes foram escritas de fato do

cache para o disco. Um checkpoint fora todas as modificaes de pginas para o disco. Ento, representa o ponto ao qual a recuperao tem que comear a rodar as transaes (ponto de incio), porque todas as pginas modificadas antes do checkpoint foram escritas com preciso no disco, no existe necessidade de recuperar as mesmas (KOCK; KEVIN, 1997). Pode-se ver como o log de transao como um artigo til para garantir integridade dos dados, quando ocorre algum problema de transao de dados. A configurao do log de banco de dados pode ser uma tarefa complicada, dependendo do SGBD. O DBA precisa tomar decises de configurao para montar o log de transao de banco de dados, como definir os arquivos de log atuais. Dependendo do tamanho do buffer do banco de dados, operaes de escrita no log podem ser otimizadas, e escrevendo o log diretamente em memria em vez de disco. O SGBD escreve log de forma assncrona, registrando os mesmos em buffer antes de gravar o mesmo em disco rgido. Quando totalmente implementado sem buffer, o banco de dados registra o log de forma sncrona, gravando seus dados em disco rgido. Definies de buffers para log de banco de dados podem otimizar operaes como ROLLBACK e RECOVER que fazem leitura ao log do banco de dados. Ao configurar o log de banco de dados, uma boa idia configurar logs virtuais. Com logs virtuais, o SGBD anotar duas mudanas separadas gerando arquivos de log independentes. Implementando o log virtual, prov um log redundante para uso no caso de falta de um dos logs. Um log pode falhar por muitas razes, inclusive fracassos inesperados, problemas de mdia, ou descuido simples. Ao montar log virtual, defina cada log em dispositivos e controladores separados para minimizar a possibilidade de ambos os logs falharem ao mesmo tempo (CARATTI, 2004). Outro detalhe de configurao de log a deciso se os logs de banco de dados sero controlados quando eles encherem. Uma vez mais, os detalhes de implementao dependem do SGBD. Alguns SGBDs provem automaticamente de log offloading. Offloading de log o processo de arquivar um log ativo a um log de archive. Se o SGBD executar offloading de log automtico, voc pode melhorar desempenho atravs de offloading para um log de arquivo em disco em vez de fita. Arquivando a disco, correr o processo de offloading de log mais rapidamente e processos de recuperao tambm podem correr mais rapidamente porque os registros de log estaro em disco. O DBA gerencia o sistema de armazenamento e migrao de logs de arquivo automaticamente para gravar depois de uma quantia predeterminada de tempo (BOSCATTO, DAMINELLO, 1999). Durante algumas operaes grandes, como CREATE INDEX, o SGBD no guardar toda pgina. Ao invs, o SGBD vai registrar bastante informao no banco de dados para determinar que um CREATE INDEX aconteceu, de forma que isto pode ser utilizado quando necessrio (caso de rollback). Adicionalmente, alguns SGBDs provem opes de configurao ao banco de dados por nveis de usurios e tipos de processos. Por exemplo, no Microsoft SQL Server, quando a opo SELECT INTO/BULKCOPY configurada TRUE, as operaes seguintes no sero registradas no log de transao de banco de dados: operaes de maior carga, SELECT INTO , WRITE TEXT e declaraes de UPDATE TEXT. Estas operaes normalmente causam um volume grande de dados a ser mudado no banco de dados. Como tal, registrando podem reduzir a velocidade

destes processos, enquanto que com essa opo desabilitada, as operaes ficam mais rpidas, porm menos seguras (SILBERCHATZ; KORTH; SUDARSHAN, 1999). 4.1.3) Conteno e Locking Operaes de concorrncia como deteco de deadlock e lock manager settings podem ter grande impacto no desempenho. preciso equilibrar a necessidade por concorrncia com a necessidade por desempenho. Se possvel, deve-se minimizar as situaes seguintes: Locks suspensions: acontece quando algum pedido de processo de aplicao fica em lock, segurado por outro processo de aplicao. O processo suspenso deixa de executar temporariamente at que o lock pedido fique disponvel; Timeouts: acontecem quando um processo de aplicao terminado porque esteve suspenso por um tempo mais longo que um intervalo prefixado. Este intervalo normalmente usa um parmetro de configurao para ser fixado; Deadlocks acontecem quando dois ou mais processos de aplicao entram em lock por utilizar recursos que os outros precisam. Ao acessar banco de dados relacional, o processo de locking pode ser bastante complexo. Dependendo do tipo do processo, do tamanho do lock especificado quando a tabela foi criada, do nvel de isolamento da declarao de SQL, do mtodo de acesso de dados, e dos parmetros de configurao do SGBD (FANDERUFF, 2003). 4.1.4) Outras Opes de Configurao Todo SGBD tem muitas configuraes e opes que so particular quele SGBD. O DBA precisa se tornar um perito nas opes que esto disponveis e entender o impacto de cada colocao permissvel. Algumas opes de configurao de exemplo que podem ser encontradas incluem: Chamadas de gatilho aninhadas: alguns SGBDs permitem habilitar chamadas de gatilho aninhadas. Isso prov um controle adicional sobre o gatilho que aninha, provendo um valor mximo para ele. Fixando este valor, o DBA pode controlar quantos nveis de chamadas de gatilho aninhadas so permissveis. Controle em cima de gatilhos pode ter um impacto enorme em desempenho. Por exemplo, se uma aplicao bater o nmero de mximo de gatilhos aninhados, todas as mudanas feitas por todos os gatilhos prvios precisam ser recompilados, causando degradao de desempenho considervel; Opes de segurana: a funcionalidade de segurana e autorizao pode ser controlada atravs de opes de configurao do SGBD; Valores de identidade: a propriedade de identidade pode ser nomeada a uma coluna tal que o SGBD nomeia automaticamente para numerao valores seqenciais quando dados so inseridos na tabela. O SGBD pode permitir a configurao do tamanho no qual so obtidos valores de identidade.

Ao configurar um ambiente de banco de dados, o ideal seria evitar padres. A maioria das opes de configurao padroniza um valor predefinido sem que nenhum valor especfico seja nomeado. O problema principal com usar valores padres que eles quase nunca so a melhor escolha para seu ambiente particular (MULLINS, 2002). Finalmente, o ideal analisar cuidadosamente todas as opes de configurao que mudam o comportamento do SGBD. Fixando um nico parmetro de configurao simplesmente ao valor errado podem causar muitos danos. 4.2Estratgia de armazenamento O local fsico configurado atravs do catlogo de sistema tendo impacto no desempenho de sistema. O DBA tem que decidir onde ser instalado, em que tipo de disco, e quanto espao alocar. Estas decises so tomadas tipicamente a tempo de instalao. O DBA deve estar ciente das caractersticas do SGBD para aplicar as tcnicas de armazenamento para aperfeioar o desempenho de estruturas de banco de dados. A maioria dos principais SGBDs usa as mesmas tcnicas embora talvez atravs de nomes diferentes. Cada uma das tcnicas seguintes pode ser usada para melhorar desempenho de banco de dados (FANDERUFF, 2003): Partitioning - dividindo uma nica tabela de banco de dados em sees que armazenam em arquivos mltiplos; Raw partitions versus file systems - escolha se o ideal armazenar dados em um arquivo controlado pelo sistema operacional ou diretamente pelo SGBD; Index - escolhendo os prprios ndices e opes para habilitar questes eficientes; Clustering - obrigando a sucesso fsica de dados em disco; Interleaving data - combinando dados de tabelas mltiplas em um nico, arquivo de seqncia; Free space - deixando espao para acomodar o crescimento de dados; Compression - algoritmo que reduz exigncias de armazenamento; File placement and allocation - colocar os arquivos certos no lugar certo; Page size - usando o tamanho de pgina adequado para armazenamento de dados; Reorganization - removendo ineficincias do banco de dados e reestruturando objetos de banco de dados. 4.2.1) Alocao de Discos O SGBD pode exigir alocar dispositivos para uso de banco de dados. Se este for o caso, o SGBD prover comandos para inicializar dispositivos de disco fsicos. O comando de inicializao de disco associar um nome lgico para uma partio de disco fsica ou arquivo de SO. Depois que o disco foi inicializado, armazenado no catlogo de sistema e pode ser usado por armazenar dados de tabela.

Antes de inicializar um disco, verifique se aquele espao suficiente est disponvel no dispositivo de disco fsico. Igualmente, certifique-se que o dispositivo j no est inicializado. Use dispositivo significante nomeado para facilitar o uso mais eficiente e administrao de dispositivos de disco. Por exemplo, no difcil de interpretar mal o uso de um dispositivo nomeado DUMP_DEV1 ou TEST_DEV7. Porm, nomes como XYZ ou A193 no so particularmente teis. Adicionalmente, mantenha documentao em dispositivos inicializados economizando arquivos manuscrito que contm a inicializao atual comandos e diagramas que indicam o espao alocado atravs de dispositivo (JARKE, KOCH, 1984). 4.2.2) Colocao e Distribuio de Arquivos O local dos arquivos que contm os dados para o banco de dados pode ter um impacto significante em desempenho. Um banco de dados possui I/O intensivo, e o DBA tem que fazer todo esforo para minimizar o custo de disco fsico (escrita e leitura). Este conhecimento requer entendimento dos padres de acesso associados com cada pedao de dados no sistema. A primeira considerao para colocao de arquivo em disco separar os ndices dos dados, se possvel. Freqentemente so exigidas questes de banco de dados em como acessar dados da tabela e um ndice naquela tabela. Se ambos estes arquivos residirem no mesmo dispositivo de disco, degradao de desempenho provvel para recuperar dados de um disco. Se existir uma nica operao que acessa dados de arquivos no mesmo dispositivo de disco, latncia acontecer, a leitura de um arquivo ter que esperar at leituras do outro arquivo serem processadas (BOSCATTO, DAMINELLO, 1999). Uma outra regra para colocao de arquivo analisar os padres de acesso de suas aplicaes e separar os arquivos de tabelas que freqentemente so acessadas juntas. O DBA deveria fazer isto pela mesma razo ele deveria separar arquivos de ndice de arquivos de tabela. Uma considerao final por colocar arquivos em dispositivos de disco separados acontece quando uma nica tabela for armazenada em arquivos mltiplos (partitioning). sbio neste caso colocar cada arquivo em um disco separado, encorajar e aperfeioar operaes de banco de dados paralelas (MULLINS, 2002). 4.2.3) Isolamento do catlogo do sistema Como uma regra tpica, coloque o catlogo de sistema em um dispositivo de disco separado de forma que isto pode ser administrado e melhorado independentemente de outros dados de aplicao. Se possvel, considere dedicar um volume de disco ou dois completamente ao catlogo de sistema. Alm disso, se o SGBD j no prover um cache de dados separado para o catlogo de sistema, considere isolar o catlogo de sistema uma cache de dados dedicada (JARKE, KOCH, 1984). DBA deveria usar o catlogo de sistema para administrar o ambiente de banco de dados ativamente. uma prtica boa monitorar os objetos de banco de dados ativamente no catlogo de sistema e apagar objetos obsoletos (KOCK; KEVIN,1997).

4.2.4) Reserva de espaos livres (free space) Free space, fator de abastecimento como s vezes chamado, pode ser usado para carregar uma partio de uma tablespace ou ndice vazio e armazenar dados. A especificao de free space em uma tablespace ou ndice pode reduzir a freqncia de reorganizao, reduzir conteno, e aumentar a eficincia de insero. Cada SGBD prov um mtodo de especificar free espace para um objeto de banco de dados dentro do CREATE e ALTER das declaraes. Um parmetro tpico PCTFREE onde o DBA especifica a porcentagem de cada pgina de dados que deveria permanecer disponvel para suplementos futuros (MULLINS, 2002). Assegurar uma prpria quantia de free space para cada objeto de banco de dados prov os benefcios seguintes: Suplementos so mais rpidos quando espao livre estiver disponvel; Como so inseridas filas novas, eles podem ser agrupados corretamente; Variveis e linhas alteradas tm espao para expandir, enquanto reduzindo a probabilidade de se mudarem fisicamente; Menos linhas em uma pgina resulta em concorrncia melhor porque menos dados so indisponveis a outros usurios quando uma pgina fechada. Porm, free space tambm tem vrias desvantagens: Exigncias de armazenamento de disco so maiores; Algumas pesquisas demoram muito mais tempo; Menos linhas em uma pgina podem exigir para mais operaes de I/O para acessar toda a informao pedida; O DBA deveria monitorar free space e assegurar que a quantia apropriada est definida para cada objeto de banco de dados. A quantia correta de free space deve ser baseado em (SILBERCHATZ; KORTH; SUDARSHAN, 1999): Freqncia de solicitaes e modificaes; Quantia de seqncia contra acesso randmico; Impacto de acessar dados no contguos; Tipo de processamento; Probabilidade de linhas encadeadas, migrao de linha e divises de pgina. 4.2.5) Distribuio dos dados A meta de colocao de dados aperfeioar o acesso reduzindo conteno em dispositivos fsicos. Dentro de um ambiente de cliente/servidor, esta meta pode ser ampliada para cercar a otimizao de desempenho de aplicao reduzindo custos de transmisso de rede. Dados deveriam residir ao servidor de banco de dados onde provvel, ou freqentemente, ser acessado. Por exemplo, dados de Chicago deveriam residir em

Chicago, num banco de dados servidor, e assim por diante. Se a deciso no est to clara, coloca-se os dados no servidor de banco de dados que geograficamente mais prximo de onde freqentemente os dados sero mais acessados. 4.2.6) Armazenamento do log Colocando o log de transao em um dispositivo de disco separado dos dados atuais permite a movimentao do log de transao do banco de dados. Tambm minimiza a escrita ao mesmo tempo mesma unidade de disco, que degrada o desempenho at mesmo mais que lendo dados ao mesmo tempo de dois arquivos na mesma unidade de disco. Deve-se lembrar tambm que toda modificao de banco de dados (escrita) registrada no log de transao de banco de dados. 4.2.7) Particionamento Uma tabela de banco de dados fisicamente uma manifestao de um dado lgico armazenado no computador. Uma das decises que o DBA tem que tomar saber como armazenar informaes (dados) em uma tabela. Cada SGBD prov mecanismos diferentes que realizam a mesma coisa traando arquivos fsicos a tabelas de banco de dados. O DBA tem que decidir de entre as opes de mapeamentos seguintes para cada tabela. nica tabela para um nico arquivo: isto a escolha mais comum. O dados no arquivo so formatados tal que o SGBD entende a estrutura de tabelas como fila inserindo naquela tabela e armazenado no mesmo arquivo. Porm, esta organizao necessariamente no a mais eficiente; nica tabela e mltiplos arquivos: esta opo freqentemente usada para tabelas muito grandes ou tabelas que exigem separar dados fisicamente ao nvel de armazenamento. O traado dos arquivos mltiplos realizado usando tablespaces dividido ou implementando dispositivos de disco segmentados; Mltiplas tabelas e nico arquivo: este tipo de forma de mapear usado em tabelas pequenas como tabelas de lookup e tabelas de cdigo, e pode ser mais eficiente para perspectiva de utilizao de disco. 4.2.8) Definio da forma de controle dos arquivos Para um ambiente de SGBD baseado em Unix, o DBA tem que escolher entre uma partio raw ou usar o sistema de arquivo Unix para armazenar os dados no banco de dados. Uma partio raw o tipo preferido de dispositivo fsico para armazenamento porque escreve em cache pelo sistema operacional quando um sistema de arquivo utilizado. Quando existe escrita, a mesma armazenada pelo sistema operacional sendo que o SGBD no sabe se o dados foram copiados fisicamente para o disco ou no. Enquanto o SGBD possuir memria, tenta escrever os dados no disco, o sistema operacional pode demorar a escrever at porque os dados ainda podem estar no arquivo cache de sistema. Se uma partio raw no for usada, os dados so escritos diretamente do cache de banco de dados para o disco sem sistema de arquivo intermedirio ou caching de

sistema operacional. Quando o SGBD manager cache escrever os dados no disco, ser escrito fisicamente a disco sem interveno. Adicionalmente, ao usar uma partio raw, o SGBD assegurar que bastante espao est disponvel para escrever as pginas. Ao usar um sistema de arquivo, o sistema operacional no vai pr-alocar espaos para uso de banco de dados. De uma perspectiva de performance, no h nenhuma vantagem em ter camada secundria de caching ao sistema de arquivo ou nvel de sistema operacional; ento cache de SGBD suficiente. De fato, o trabalho adicional requereu o cache de dados uma segunda vez, portanto consome recursos (JARKE, KOCH, 1984). 4.2.9) Definio do tamanho de bloco A maioria do SGBDs prov a habilidade para especificar o tamanho de uma pgina, ou bloco. O tamanho de pgina usado para armazenar linhas de uma tabela em disco. Por exemplo, considere que uma tabela requer linhas que tm 125 bytes em comprimento com 6 bytes adicionais. Isto faz com que cada registro tenha 131 bytes. Para armazenar 25 registros em uma pgina, o tamanho teria que ser pelo menos 3275 bytes. Porm, cada SGBD requer uma quantia de pgina, assim o tamanho prtico ser maior. O ideal acima seria 20 bytes, ento o tamanho de pgina seria 3295 bytes. Porm, esta discusso simplista. Em geral prtica, a maioria das tablespaces exigir alguma quantia de espao livre para acomodar dados novos. Ento, alguma porcentagem de espao livre precisar ser fatorada em uma equao. Para complicar a situao, muitos SGBD limitam os tamanhos de pgina que podem ser escolhidos. Por exemplo, DB2 para OS/390 limita tamanho de pgina a 4k, 8k, 16k ou 32k. Neste caso, o DBA precisar calcular o melhor tamanho de pgina baseado no tamanho da linha, o nmero de linhas por pgina, e exigncias especiais livres. Escolher o tamanho de pgina adequado uma tarefa importante para o DBA aperfeioar banco de dados desempenho de I/O (MULLINS, 2002). Quando dados de duas tabelas freqentemente so unidos (com uso de junes), pode fazer sentido intercalar os dados fisicamente na mesma estrutura de armazenamento fsica. Isto pode ser visto como uma forma especializada de cluster (SILBERCHATZ; KORTH; SUDARSHAN, 1999). 4.2.10) Uso de tcnicas de compresso de dados Pode ser usada compresso para encolher o tamanho de um banco de dados. Comprimindo dados, o banco de dados requer menos armazenamento de disco. Alguns SGBDs provem opes de DDL internas para comprimir arquivos de banco de dados. Quando compresso especificada, dados so comprimidos durante sua insero no banco de dados e descomprimidos quando so lidos. Ler e escrever dados comprimidos consomem mais recursos de CPU que ler e escrever dados descomprimidos, pois o SGBD tem que executar cdigo para comprimir e descomprimir os dados como suplemento de usurios, atualizao, e leitura os dados (KOCK; KEVIN, 1997).

Assim, por que comprimir dados? Considere uma tabela no comprimida com um tamanho de linhas de 800 bytes. Cinco destas linhas da tabela ajustariam em 4k da pgina de dados (ou bloco). Agora o que acontece se os dados estivessem comprimidos? Assuma que a rotina de compresso alcana 30% compresso em mdia (uma estimativa muito conservadora). Naquele caso, a 800 bytes (linhas) consumiriam apenas 560 bytes (800 x 0.30 = 560). Depois de comprimir os dados, sete linhas se ajustaro em 4k de uma pgina. Porque I/O acontece ao nvel de pgina, um nico I/O recobrar mais dados do que aperfeioar o desempenho da pesquisa de dados seqente e aumenta a probabilidade de dados que residem no cache porque mais linhas se ajustaram em uma pgina fsica. claro que, compresso sempre requer um trabalho extra para o DBA ter que analisar. No lado positivo, tem-se conteno de disco para reduzir custo de I/O. No lado negativo, temos o custo de CPU adicional exigido comprimir e descomprimir os dados. Porm, compresso no uma opo para todo ndice de banco de dados ou tabela. Para quantias menores de dados, possvel que um arquivo comprimido seja maior que um arquivo no comprimido. Isto assim porque em alguns SGBDs e algoritmos de compresso exigem um dicionrio interno administrar a compresso. O dicionrio contm estatsticas sobre a composio dos dados que esto estando comprimidos. Para uma quantia trivial de dados, o tamanho do dicionrio pode ser maior que a quantia de armazenamento economizado por compresso (BOSCATTO, DAMINELLO, 1999).

5) Gerenciamento de performance de aplicaes

Como j citado, a aplicao que utiliza um banco de dados gerenciado por um SGBD em geral responsvel pela maioria dos problemas de desempenho de um sistema de informao. Este captulo apresenta algumas diretrizes para otimizar a performance de aplicaes de banco de dados.

5.1) Refinamento do projeto de banco de dados

5.1.1) Desnormalizao Um modo para aperfeioar o desempenho de acesso de banco de dados a desnormalizao das tabelas. Desnormalizao, o oposto de normalizao, o processo de pr um fato em muitos lugares (uma mesma coluna em muitas tabelas). Isto faz acelerar a recuperao de dados s custas de modificao de dados. Tabelas desnormalizadas podem ser uma deciso boa quando um completo desgnio de normalizao no executado da forma mais adequada. A nica razo para uma desnormalizao em um banco de dados relacional o aumento de desempenho (FANDERUFF, 2003). Exemplos de desnormalizao incluem: Tabelas Projetadas - Quando o custo de unir excessivo, causando degradao de performance; Tabelas de relatrios - Quando as geraes dos relatrios especializados so muito caras; Tabelas Espelho - Quando tabelas so requeridas simultaneamente por dois tipos de ambientes; Tabelas Particionadas - Quando grupos distintos usam partes diferentes de uma tabela; Tabelas Combinadas - consolidar um-para-um ou um-para-muitas relaes em uma nica tabela; Tabelas Rpidas - apoiar hierarquias ou informando estruturas; Desnormalizao fsica - tirar proveito de caractersticas de SGBD especficas. 5.1.2) Clustering de tabelas Uma tabela agrupada armazenar seus registros fisicamente em disco em ordem de uma ou mais colunas especificadas. Normalmente clustering obriga o SGBD a utilizar um ndice clustering. O ndice clustering fora uma tabela a ser acessada pelas colunas indexadas pelo ndice. Pode haver um nico clustering sucessivo por tabela (porque fisicamente os dados podem ser armazenados em s uma sucesso). Dependendo do SGBD, os dados podem no serem sempre mantidos fisicamente em clusters com agrupamentos exatos. Quando cluster agrupado estiver definido para uma tabela, o SGBD agir em um dos dois modos para obrigar o agrupamento:

Quando so inseridas linhas novas, o SGBD manobrar fisicamente dados, linhas e pginas para ajustar as filas novas do cluster agrupado; Quando so inseridas filas novas, o SGBD tentar colocar os dados no cluster agrupado definido, mas se espao no est disponvel na pgina exigida que os dados podem ser colocados em outro lugar. O DBA tem que aprender como o SGBD mantm clusters. Se o SGBD operar como no segundo cenrio, dados podem se tornar unclustered com o passar do tempo e podem requerer reorganizao. Tabelas agrupadas que so acessadas consecutivamente so na prtica uma boa opo. Em outras palavras, ndices agrupados so bons para apoiar acessos considerados grandes, e ndices de unclustered so melhores para apoiar acessos randmicos. A escolha das colunas agrupadas deve ser feita sabiamente. Agrupamentos de ndices so utilizados para as seguintes situaes: Colunas que incluem chaves estrangeiras e so usadas em junes; Colunas que no mudam freqentemente (reduz o reagrupamento fisicamente); Colunas que freqentemente se agrupam ou ordenam em declaraes de SQL. Em geral, o clustering ajuda o desempenho dos predicados mais acessados. Quando uma tabela tiver os candidatos mltiplos por clustering, o ideal seria pensar no custo de ordenar contra o desempenho ganho pelo clustering para cada chave candidata. Como uma regra primria, entretanto, se o SGBD suporta cluster, normalmente uma prtica boa para definir um ndice cluster para cada tabela que criada (a menos que a tabela seja muito pequena) (BOSCATTO, DAMINELLO, 1999). Geralmente clusters no so recomendados para colunas primrias porque a chave primria , por definio, sem dados duplicados. Porm, se freqentemente so selecionados ranges de linhas e ordenados por valor de chave primria, ento um ndice cluster pode ser benfico.

5.2) Entendendo o otimizador de consultas do SGBD

Um otimizador relacional de pequeno uso sem estatsticas precisas sobre os dados armazenados no banco de dados. Um SGBD relacional prov um programa de utilidade ou juno de estatsticas sobre objetos de banco de dados e os armazena para uso do otimizador (ou pelo DBA para desempenho que monitora). Por exemplo, para colecionar estatsticas em DB2, o DBA tem que executar a utilidade de RUNSTATS; para colecionar estatsticas em SQL Server o comando UPDATE STATISTICS deve ser emitido. O DBA dever coletar estatsticas modificadas sempre que um volume significante de dados for somado ou for modificado. Estatsticas de banco de dados proporcionam para o otimizador informaes sobre o estado da tablespace, tabelas, colunas e ndices. O SGBD coleciona informao de estatsticas como:

Nmero de registros na tablespace, tabelas ou ndices; Nmero de valores distintos armazenados na coluna; Densidade fundamental de ndices; Detalhes na relao em crescimento de clusters para tabelas agrupadas; Correlao de colunas para outras colunas; Estado estrutural do ndice ou tablespace; Quantia de armazenamento usada pelo objeto de banco de dados. Quando emitido o comando RUNSTATS, o DBA especifica quais estatsticas para juntar. Obviamente, as estatsticas exatas colecionadas variam de SGBD para SGBD. A chave, entretanto, manter as estatsticas to precisas quanto possvel para assegurar otimizao relacional eficiente e til (MULLINS, 2002). Ao desenvolver uma aplicao em bancos de dados de teste, as estatsticas para os dados de teste no refletiro sobre as estatsticas com preciso para o banco de dados de produo. Sempre que possvel, o DBA deveria trabalhar com a equipe de desenvolvimento de aplicao para criar um manual para povoar estatsticas de produo no sistema de teste. Dependendo do SGBD, isto pode ser realizado com declaraes de SQL ou um dado que testa a ferramenta. Sem estatsticas de produo, o otimizador escolher caminhos de acesso diferente no ambiente de teste e em produo, causando problemas de desempenho quando a aplicao entra em estado de produo. 5.2.1) A otimizao relacional O DBA tem que ficar familiar com as tcnicas de otimizao usadas por cada SGBD na organizao. Claro que, desenvolvedores de aplicao tm que codificar SQL eficiente e tm que entender como aperfeioar SQL, mas no fim o DBA que responsvel por desempenho de aplicaes no banco de dados. Como tal, o DBA deve estar qualificado em SQL codificando e afinando SQL para desempenho. O otimizador o corao de um banco de dados relacional na administrao do sistema. o mecanismo responsvel para determinar a melhor estratgia possvel de navegao de banco de dados para qualquer determinado pedido de SQL (YANG, Y; SINGHAL, M; 1997). O desenvolvedor de aplicao especifica quais dados so requeridos para codificar as declaraes SQL, e o otimizador decide como navegar no banco de dados eficazmente. O usurio final no precisa de nenhum conhecimento de onde e como o dado atual armazenado. O otimizador sabe esta informao. Esta separao de critrios de acesso de caractersticas de armazenamento fsicas chamada independncia de dados fsica (MULLINS, 2002). O otimizador relacional de cada declarao SQL analisa gramaticalmente para determinar as tabelas e colunas que devem ser acessadas. O otimizador acessa tambm estatsticas armazenadas pelo SGBD no catlogo de sistema. As estatsticas so usadas para determinar o melhor mtodo de realizar a tarefa caso precise ser executado para satisfazer o pedido de SQL.

A otimizao relacional muito poderosa porque permite adaptar a um ambiente de banco de dados varivel. O otimizador pode reagir a mudanas formulando caminhos de acesso novos sem requerer recodificar a aplicao. Todo SGBD relacional tem um otimizador relacional embutido que faz declaraes de SQL em caminhos de acesso executveis. Alm disso, cada otimizador relacional trabalha com um pequeno diferencial, com passos diferentes e informaes diferentes. No obstante, o processo o mesmo de SGBD para SGBD. O otimizador analisa gramaticalmente a declarao de SQL e executa vrias fases de otimizao, envolvendo verificao sinttica e semntica, seguido por anlise de questo e formulao dos caminhos de acesso para satisfazer a questo. O otimizador relacional pode desdobrar muitos tipos de estratgias disponveis para o SGBD para aperfeioar declaraes de SQL. As operaes internas e instrues que so usadas por cada otimizador de SGBD so segredos cuidadosos. So vlidos para otimizadores de bancos relacionais modernos, significando que o otimizador tentar formular um caminho de acesso para cada questo que reduz o custo global. 5.2.2) Desenvolvendo aplicaes para Acesso Relacional Uma aplicao de banco de dados deve ser projetada para desempenho no incio, porque mudando o desgnio da aplicao depois ou impossvel, ou no prtico, ou muito caro. Alguns assuntos que afetam o desempenho de aplicao so discutidos a seguir. Tipo de SQL. O tipo ideal de SQL planejado ou no planejado, dinmico ou esttico, embutido ou no embutido a ser usado para esta aplicao? Linguagem de programao. A linguagem de programao capaz de alcanar o desempenho exigido, e o ambiente de idioma aperfeioado para acesso de banco de dados? Transao projetada e processada. So projetadas as transaes dentro do programa corretamente para assegurar propriedades ACID, e o programa usa o processador de transao adequadamente e eficazmente? Estratgia de lock. A aplicao segura o funcionamento do banco de forma errada, ou segura de uma forma correta, porm leva muito tempo para liberar o mesmo? Estratgia COMMIT. Cada programa de aplicao emite um SQL COMMIT para declaraes minimizar o impacto de fechar? Processo de grupo. So projetados programas de grupo adequadamente para tirar proveito das caractersticas de processo do SGBD? Processamento on-line. So projetadas aplicaes on-line para devolver informao til e minimizar a quantia de informao retornada tela do usurio? 5.2.3) Otimizao baseada em regras e Otimizao baseada em custos

A maioria dos otimizadores relacionais so baseados em custo, isso significa que eles escolhem o caminho de acesso devido a uma deciso baseada na estimativa de custos. Porm, alguns SGBDs apiam um tipo diferente de otimizao que est baseado em heursticas, ou regras. Por exemplo, Oracle prov ambos, otimizao baseada em custo e otimizao baseada em regras. Um otimizador baseado em regras funda suas decises de otimizao em sintaxe de SQL e estrutura, colocao de predicados, ordem de tabelas na declarao SELECT e disponibilidade de ndices. Com um otimizador baseado em regras, o desenvolvedor de SQL precisa estar atento as regras como ele escreve para SQL. Otimizao baseada em custo a tendncia para SGBDs porque o otimizador que calcula o custo de caminhos de acesso diferentes produz execuo mais prxima do real (TEKNO, 1996). 5.2.3.1) Custos de CPU e I/O Um otimizador relacional usa frmulas e modelos para calcular o caminho de acesso potencial. Baseado em informao de CPU, o otimizador pode chegar a uma estimativa do tempo de CPU exigido para executar a questo que usa cada caminho de acesso que analisa. Alm disso, um otimizador relacional tem que calcular o custo da escritura atual e recuperao dos dados. O otimizador calcula o custo de I/O questo usando uma srie de frmulas baseadas nas estatsticas de banco de dados, a eficincia de cache de dados, e o custo de I/O. Estas frmulas resultam em um fator de filtro que determina o I/O relativo da questo (SILBERCHATZ; KORTH; SUDARSHAN, 1999). 5.2.3.2) Densidade Densidade a porcentagem de valores duplicados armazenados em ndices colunas e registrado como uma porcentagem. A equao seguinte determina o nmero comum de linhas que se estima ser devolvidas ao acessar uma tabela pelo ndice: Average # Rows = Total # Rows * Density Por exemplo, ao acessar uma tabela com 1000 linhas por um ndice com uma densidade de 50%: Average # Rows = 1000 * 0.50 = 500 Ao acessar uma tabela com 20.000 linhas por um com uma densidade de 15%: Average # Rows = 20000 * 0.15 = 3000 Esta informao til ao otimizador porque ajuda determinando o tamanho dos resultados e assim, se um ndice til para caminhos de acesso especficos. Durante anlise de questo, o otimizador analisa aspectos da declarao SQL e do

sistema de banco de dados, como (SILBERCHATZ; KORTH; SUDARSHAN, 1999): Quais tabelas nas quais banco de dados requerido; Se qualquer viso exigiu ser destruda em tabelas subjacentes; Se junes entre tabelas so requeridas subselects; Quais ndices podem ser usados; Quantos predicados (clusulas WHERE) devem ser satisfeitos; Quais funes devem ser executadas; Se o SQL usa OR ou AND; Como o SGBD processa cada componente da declarao de SQL; Quanta memria foi nomeada ao cache de dados e usada pelas tabelas na declarao de SQL; Quanta memria est disponvel para ordenar se a questo exigir ordenao.

5.3) Tunning de frases SQL

Codificar e afinar cdigos SQL so tarefas que consomem muito tempo de um DBA. Podem existir milhares de declaraes de SQL individuais contidas em centenas de aplicaes que acessam bancos de dados. O DBA responsvel para assegurar que os passos seguintes acontecem para cada declarao de SQL na organizao: 1. Identifique as exigncias de dados empresariais; 2. Assegure que o dado exigido est disponvel dentro de bancos de dados existentes; 3. Traduza as exigncias empresariais em SQL; 4. Teste o SQL para preciso; 5. Revise os caminhos de acesso para desempenho; 6. Verifique o SQL para caminhos de acesso melhores; 7. Sugestes de otimizao de cdigo; 8. Repetio passos 4 por 7 at que desempenho seja aceitvel; 9. Passo 8 repetido sempre que problemas de desempenho surgem ou uma verso de SGBD nova instalada; Repita processo inteiro sempre que ocorrerem mudanas de necessidades da organizao. Refinar SQL complexo, consome tempo, e um processo propenso a erros. Alm disso, requer cooperao e comunicao entre os usurios empresariais e programadores de aplicao para os primeiros 3 passos, e entre os programadores de aplicao e o DBA para os passos restantes (CARATTI, 2004). 5.3.1) Definio adequada de ndices

Criando os ndices corretos em tabelas no banco de dados talvez a melhor forma de um DBA conseguir ganhar desempenho sobre o banco de dados. So usados ndices para aumentar a performance. ndices particulares so teis para: Localizar registros atravs de colunas; Fazendo joins mais eficientes (quando o ndice est definido nas colunas corretas); Dados correlacionados em tabelas; Agregaes de dados; Dados ordenando para satisfazer uma consulta. Sem ndices, todo o acesso para dados no banco de dados teria que ser executado varrendo toda a tabela em busca de um nico registro. Essa varredura muito ineficiente quando as tabelas so grandes. Projetar e criar ndices para tabelas, o banco de dados geralmente cruza informaes de desempenho para melhorar o desempenho da aplicao. ndices so objetos de banco de dados criados pelo DBA sobre o banco de dados, so construdos para fazer com que declaraes SQL em aplicaes sejam executadas mais rapidamente. Indexar um esforo de melhoria para que a aplicao seja executada de forma mais eficiente quando determinados dados forem requisitados (FANDERUFF, 2003). Antes de otimizar o banco de dados criando ndices novos, necessrio o entendimento do impacto de criar um ndice. O DBA deve ter uma compreenso dos padres de acesso da tabela na qual o ndice ser construdo. Essa informao til para incluir a porcentagem do volume de acessos e atualizaes da tabela, os limitadores de desempenho fixados dentro de qualquer consulta, nveis para cada tabela, o impacto de acrescentar um ndice novo a utilidades de banco de dados correntes como cargas, reorganizaes e recuperao (CARATTI, 2004). Uma das grandes perguntas sem resposta de desgnio de banco de dados : "Quantos ndices deveriam ser criados para uma nica tabela?" No h nenhuma resposta fixa a esta pergunta. O DBA precisar usar as percias dele para determinar o nmero adequado de ndices para cada tabela. Determinando o prprio nmero de ndices para cada tabela requer uma anlise detalhada do banco de dados e as aplicaes que acessam o banco de dados. A meta geral de anlise de ndice usar menos I/O para satisfazer as consultas feitas a uma tabela. Claro que, um ndice pode ajudar algumas questes e outras no. Ento, o DBA tem que avaliar o impacto de acrescentar um ndice a todas as aplicaes. Esta pode ser uma tarefa rdua, mas recompensadora (MULLINS, 2002). Um ndice afeta desempenho positivamente quando menos I/Os so usados para devolver resultados a uma consulta. Reciprocamente, impacta negativamente quando dados forem atualizados e os ndices tm que ser mudados como tal. Uma estratgia seria uma indexao efetiva que busca proporcionar a maior reduo em I/O um nvel aceitvel de esforo para manter os ndices atualizados. Algumas aplicaes tm questes problemticas que exigem otimizao significante para alcanar desempenho satisfatrio. Criar um ndice para apoiar uma nica questo aceitvel se aquela questo for importante para o negcio. Se a

questo mau desempenho infreqentemente, o ideal seria criar o ndice antes do processo comear e eliminar o ndice quando o processo estiver completo (BOSCATTO, DAMINELLO, 1999). Sempre que se criam ndices novos, o ideal testar o desempenho das consultas. Adicionalmente, teste declaraes de modificao de banco de dados para medir o custo adicional em cima de atualizao os ndices novos. Revisar o tempo de CPU com o decorrer do tempo, e exigncias de I/O para assegurar que existe necessidade da ajuda de ndices. Otimizao um processo de iteratividade, e pode levar tempo para que vrios ndices testados para determinar o impacto de uma mudana. No h nenhuma regra precisa e rpida para criao de ndice. H alguns cenrios onde indexar pode no ser uma idia boa. Quando tabelas forem muito pequenas, menos de 10 pginas. Acesso indexado para uma tabela pequena pode ser menos eficiente que a verificao de todas as linhas da tabela, porque ler o ndice soma pedidos de I/O (TEKNO, 1996). ndices, todavia geram I/O, at mesmo um ndice considerado pequeno em uma tabela s vezes pode beneficiar a mesma, por exemplo, obrigar singularidade ou se a maioria do acesso de dados recobra uma nica linha que usa chave primria. O ideal seria querer evitar indexar colunas de comprimento varivel se o SGBD em questo amplia a coluna varivel ao comprimento ao mximo dentro do ndice. Tal expanso pode fazer ndices consumir uma quantia irregular de espao de disco e serem ineficiente. Porm, se colunas de comprimento varivel so usadas em clusulas SQL WHERE, o custo de armazenamento de disco normalmente mais barato que desperdiar recursos de CPU para localizar linhas. ndices so tipicamente baseados nas clusulas WHERE. Por exemplo, vamos considerar a declarao SQL da listagem 5.1. Listagem 5.1: A consulta abaixo mostram o conceito de criao e utilizao de ndices. Nesse caso como s existe uma nica condio na clusula WHERE, o ndice foi posicionado na respectiva coluna (salary).

Select emp_no, last_name, salary From employee Where salary > 1500,00;
Criar um ndice na coluna de salary pode aumentar o desempenho desta consulta. Porm, o DBA pode aumentar o desempenho da consulta mais adiante sobrecarregando o ndice das colunas emp_no e last_name. Como sobrecarregamento do ndice, o SGBD no precisa incorrer a I/O adicional para acessar os dados da tabela. O custo estimado que consideramos para expresses da lgebra relacional no leva em conta os defeitos de ndices e de funes de hashing no custo de avaliao de uma expresso. A presena dessas estruturas, entretanto, tem uma importncia significativa na escolha de uma estratgia de processamento de consultas (JARKE, KOCH, 1984). ndices e funes de hashing permitem acessos rpidos a registros contendo um valor especfico na chave de ndice. ndices permitem que os registros de um arquivo sejam lidos em uma ordem de classificao. Se um ndice permite que registros de um

arquivo sejam lidos em uma ordem correspondente ordem fsica, esse ndice chamado ndice de agrupamento (clustering index). Os ndices de agrupamento permitem-nos tirar vantagem do agrupamento fsico de registros em blocos. A estratgia detalhada para processamento de consultas chamada de plano de execuo para consulta. Um plano inclui no apenas as operaes relacionais a serem executadas, mas tambm os ndices a serem usados, a ordem na qual as tuplas sero processadas e a ordem na qual as operaes sero executadas. Obviamente, o uso de ndices impe a sobrecarga do acesso queles blocos contendo o ndice. Precisase levar em conta esses acessos a blocos quando se estima o custo de uma estratgia que envolva o uso de ndices. Como um exemplo de estimativa do custo de uma consulta usando ndices, vamos assumir que estamos processando a consulta da listagem 5.2. Listagem 5.2: O exemplo abaixo mostra a seguinte situao: a consulta possui trs condies na clusula WHERE. Duas dessas condies possuem ndices especficos. A coluna nome_agncia possui um ndice e a coluna nome_cliente possui outro ndice. Mediante a isso, o otimizador obrigado a escolher qual dos ndices traz o melhor caminho para que a consulta seja processada.

select nmero-conta from depsito where nome-agncia = "Perryridge and nome-cliente="Williams" and saldo > 1000
Existem as seguintes informaes estatsticas sobre a relao depsito: 20 tuplas de depsito cabem em um bloco. nome-agncia = 50. nome-cliente = 200. saldo = 5.000. A relao depsito tem 10000 tuplas. Vamos imaginar que existam os seguintes ndices em depsitos: Um ndice em forma de rvore-B+ para nome-agncia com clustering; Um ndice em forma de rvore-B+ para nome-cliente sem clustering. Considere-se a hiptese simplificadora de que os valores so distribudos uniformemente. Uma vez que nome-agncia=50, espera-se que 10000/50 = 200 tuplas da relao depsito pertenam agncia Perryridge. Se usarmos o ndice em nome-agncia, vamos precisar ler essas 200 tuplas e verificar se cada uma satisfaz a clusula WHERE. Uma vez que o ndice tem clustering, a leitura de 200/20 = 10 blocos ser necessria para ler as tuplas de depsito.

E mais, diversos blocos de ndice precisam ser lidos. A rvore-B+ do ndice armazena 20 ponteiros por n. Isto significa que a rvore-B+ do ndice precisa ter entre 3 e 5 ns. Com este nmero de ns, a rvore inteira teria uma profundidade de 2, ento 2 blocos de ndice precisam ser lidos. Assim, a estratgia acima requer a leitura total de 12 blocos lidos. Se usarmos o ndice para nome-cliente, estimamos o nmero de acessos a blocos como segue. Uma vez que nome-cliente=200, espera-se que 10000/200 = 50 tuplas da relao depsito pertenam a Williams. No entanto, uma vez que o ndice para nome-cliente no tem clustering, antecipamos que um bloco lido ser requerido para cada tupla. Assim, 50 blocos lidos so requeridos apenas para ler as tuplas depsito. Vamos assumir que 20 ponteiros cabem em um n da rvore-B+ para o ndice de nome-cliente. Uma vez que existem 200 nomes de clientes, a rvore tem entre 11 e 20 ns. Assim, como no caso da rvore-B+ para o outro ndice, o ndice para nomecliente tem profundidade de 2, e 2 blocos de acesso so requeridos para ler os blocos de ndice necessrios. Assim, essa estratgia requer um total de 52 blocos lidos. Conclumos que prefervel usar o ndice para nome-agncia. Observe que, se os dois ndices no tivessem clustering, preferiramos usar o ndice para nome-cliente, uma vez que esperamos apenas 50 tuplas com nome-cliente = Williams contra 200 tuplas com nome-agncia = Perryridge.Sem a propriedade de clustering, nossa primeira estratgia poderia requerer o acesso a at 200 blocos para ler os dados, uma vez que, no pior dos casos, cada tupla est em um bloco diferente. Adicionamos isso aos 2 acessos a blocos num total de 202 blocos lidos. Entretanto, por causa da propriedade de clustering do ndice nome-agncia, realmente menos caro neste exemplo usar o ndice para nome-agncia. Um outro modo pelo qual os ndices podem ser usados para processar a consulta exemplo o seguinte. Usando o ndice para nome-cliente para obter os ponteiros para registros com nome-cliente= Williams em vez dos prprios registros. Digamos que P1 represente o conjunto desses ponteiros. Da mesma forma, usando o ndice para nome-agncia para obter os ponteiros para registros com nome-agncia= Perryridge. Digamos que P2 represente esse conjunto de ponteiros. Ento P1 P2 um conjunto de ponteiros para registros com nome-agncia= Perryridge e nomecliente = Williams. Esses registros precisam ser recuperados e testados para ver se saldo > 1000. Uma vez que essa tcnica requer que os dois ndices sejam usados, um total de quatro blocos de ndices so lidos. Estimamos o nmero de blocos que precisam ser lidos do arquivo depsito calculando aproximadamente o nmero de ponteiros em P1 P2. Como nome-agncia = 50 e nome-cliente = 200, estima-se que uma tupla em 50 x 200 ou uma em 10.000 tenha nome-agncia = Perryridge e nome-cliente = Williams. Essa estimativa baseada em uma hiptese de distribuio uniforme e em uma hiptese adicional que a distribuio de nomes de agncia e nomes de clientes so independentes. Com base nessas tentativas, P1 P2 estimado como tendo apenas um ponteiro. Assim, apenas um bloco de depsito precisa ser lido. O custo total estimado desta estratgia de cinco blocos lidos.

No vamos considerar o uso do atributo saldo e do predicado saldo > 1000 como um ponto de partida para uma estratgia de processamento de consultas por duas razes: No h nenhum ndice para saldo; O predicado de seleo em saldo envolve uma comparao maior do que. Em geral, predicados de igualdade so mais seletivos do que os predicados maior do que. Uma vez que temos um predicado de igualdade disponvel (na verdade, temos dois), preferimos comear usando tal predicado j que provvel que ele selecione menos tuplas. A estimativa de custo de acesso usando ndices permite estimar o custo completo, em termos de acessos a blocos, de uma estratgia. Para uma dada expresso da lgebra relacional, pode ser possvel formular diversas estratgias. A fase de seleo do plano de acesso de um otimizador de consultas escolhe a melhor estratgia para uma dada expresso. possvel que uma expresso da lgebra relacional (para a qual um bom plano exista) seja prefervel uma expresso da lgebra aparentemente mais eficiente, mas que possibilite apenas planos inferiores (BOSCATTO, DAMINELLO, 1999). 5.3.2) Otimizao de junes (joins) Quando so acessadas tabelas mltiplas, o otimizador entende como combinar as tabelas da maneira mais eficiente. Informao combinando tabelas mltiplas so conhecidas como juno. Ao determinar o caminho de acesso para uma juno, o otimizador tem que determinar a ordem que sero unidas s tabelas, ser computada a estimativa de custo global de cada caminho de acesso, e ser escolhido um mtodo para a questo particular. O SGBD pode utilizar vrios mtodos diferentes por unir tabelas. O SGBD tem que tomar vrias decises e tem que executar certas operaes. A primeira deciso escolher a tabela para processar primeiro, esta tabela chamada de tabela exterior. Logo, so executadas operaes na tabela exterior para preparar a mesma para a juno. So combinadas linhas daquela tabela ento com linhas da segunda tabela, chamada de tabela interna. Tambm executada uma srie de operaes na tabela interna antes da unio acontecer. Embora todos os joins tenham funcionalidade similar, cada join trabalha diferentemente. Investiguemos dois mtodos comuns de joins: o nestedloop e o mergescan join. Os nested-loop trabalha comparando linhas qualificativas da tabela exterior tabela interior. Uma linha qualificativa identificada na tabela exterior, e ento a tabela interna verificada. Quando a tabela interna verificada por completo, outra linha qualificativa de outra tabela exterior identificada. A tabela interna verificada novamente, e assim por diante. A verificao repetida da tabela interna normalmente realizada com um ndice para evitar custos de I/O imprprios. Quanto menor o tamanho da tabela interna, melhor um nested loop executado, porque menos linhas precisam ser verificadas para cada linha qualificativa da tabela exterior (JARKE, KOCH, 1984).

O otimizador revisa cada juno em uma questo e analisa as estatsticas apropriadas para determinar a ordem tima que as tabelas deveriam ser acessadas para realizar o join. Achar a unio contendo o caminho de acesso timo, com uso de otimizador para construir algoritmos que contm conhecimento aproximado de joins e volume de dados, predicados, estatsticas de bancos de dados e ndices disponveis para calcular qual ordem mais eficiente. Dependendo do SGBD, outros mtodos de juno podem estar disponveis e so discutidos na seqncia. 5.3.2.1) Junes por Intercalao Nos casos em que nenhuma relao cabe na memria principal, ainda possvel processar a juno eficientemente se ambas as relaes estiverem armazenadas na ordem dos atributos da juno. Suponha que as relaes cliente e pedido estejam ordenados por nome-cliente. Nesse caso podemos executar a operao de juno por intercalao (merge join). Associamos um ponteiro a cada relao. Esses ponteiros apontam inicialmente para a primeira tupla da respectiva relao. medida que o algoritmo executado, os ponteiros se movem atravs da relao. lido um grupo de tuplas de uma relao com mesmo valor nos atributos da juno. Ento as tuplas (se houver) correspondentes da outra relao so lidas. Uma vez que as relaes esto ordenadas, as tuplas com o mesmo valor nos atributos da juno esto em ordem consecutiva. Isto nos permite ler cada tupla apenas uma vez. No caso, em que as tuplas das relaes so armazenadas fisicamente juntas, esse algoritmo nos permite computar a juno lendo cada bloco exatamente uma vez (WEININGER, 2002). suficiente manter todas as tuplas com o mesmo valor para os atributos da juno na memria principal. Isto vivel mesmo que ambas as relaes sejam grandes. Uma desvantagem do mtodo de juno por intercalao que ambas as relaes precisam estar classificadas fisicamente. A listagem 5.3 apresenta o algoritmo de juno por intercalao, considerando uma juno pedido x cliente. Listagem 5.3: Algoritmo referente ao exemplo de juno por intercalao, mediante ao conceito descrito (WEININGER, 2002).

pd = endereo da primeira tupla de pedido; pc: = endereo da primeira tupla de cliente; while (pc nulo) do begin tc: = tupla para a qual pc aponta; sc: = {tc} ajuste pc para apontar para a prxima tupla cliente; pronto := false; while (not pronto and pc nulo) do begin; tc' := tupla para a qual pc aponta; if tc' [nome-cliente] = tc[nome-cliente] then begin si := sc UNIO {tc};

de

ajuste pc para apontar para a prxima tupla de cliente; end else pronto := true; td := tupla para a qual pd aponta; ajuste pd para apontar para a prxima tupla de pedido while (td[nome-cliente] < [nome-cliente] do begin td := tupla para a qual pd aponta; end while (td[nome-cliente] = tc[nome-cliente]) do begin for each t in sc do begin compute t x td e adicione ao resultado; end ajuste pd para apontar para a prxima tupla de pedido; td := tupla para a qual pd aponta; end end;
5.3.2.2) Junes com Hashing Pode ser compensador construir um ndice especificamente para o uso na computao de uma juno, mesmo que esse ndice no seja retido aps a computao da juno. Em vez de construir um ndice em forma de rvore-B+, freqentemente prefervel usar o hashing para um ndice do tipo "use uma vez" construdo para auxiliar a computao de uma nica juno. Uma funo de hashing (h) usada para as tuplas de ambas as relaes sobre os atributos da funo. Os resultados que contm ponteiros para tuplas das relaes, so usados para limitar o nmero de pares de tuplas que devem ser comparados. Se o uma tupla de compra e c uma tupla de cliente, ento o e c devem ser testadas apenas se h(c) = h(o). Se h(c) DIFERENTE h(o), ento c e o devem ter valores diferentes. O exemplo abaixo mostra os detalhes do algoritmo de juno com hashing utilizado em um exemplo de compras x clientes. A funo de hashing (h) deveria ter as boas propriedades de aleatoriedade e uniformidade. Usa-se essas propriedades para estimar os custos da execuo da juno com hashing. Sendo assim, assume-se que: h uma funo hashing mapeando valores de nome-cliente em {0, 1,..., max}; Hc0, Hc1... Hcmax representam os grupos de ponteiros para tuplas de cliente, cada um inicialmente vazio; Ho0, Ho1... Homax representam os grupos de ponteiros para tuplas de compras, cada um inicialmente vazio. Usando-se em seguida essas propriedades para estimar o custo da execuo de uma juno com hashing.

A distribuio de ponteiros para uso de hashing nos dois laos faz com que o algoritmo requeira uma leitura completa de ambas as relaes. O custo desta operao requer acessos a blocos se as tuplas de compras e as tuplas de cliente estiverem armazenadas juntas fisicamente. Uma vez que os grupos contm apenas ponteiros, assumimos que eles cabem na memria principal, assim nenhum acesso a disco necessrio para fazer acesso aos grupos (YANG, Y; SINGHAL, M; 1997). Exemplo ro x rc Onde ro o conjunto de tuplas cujo valor de hashing colocadas no grupo i e rc outro conjunto de tuplas cujo valor de hashing tambm as leva ao grupo i. Esta juno computada usando a iterao simples, uma vez que esperamos que ro e rc sejam suficientemente pequenos para caber na memria principal. Uma vez que o hashing de uma tupla leva-a exatamente em um grupo (seleo), cada tupla lida apenas uma vez pelo lao. Como observado anteriormente, isto requer acessos a bloco. O otimizador no deve escolher uma funo de hashing que tenha um contra domnio to grande que os grupos fiquem vazios. Isto gastaria espao e foraria o algoritmo de juno com hashing a incorrer em desperdcio processando grupos vazios (BOSCATTO, DAMINELLO, 1999). 5.3.2.3) Estratgias de juno para Processadores Paralelos Vamos considerar agora uma juno envolvendo trs relaes: agncia x depsito x cliente Diramos que ndepsito = 10.000, ncliente = 200 e nagncia = 50. No apenas existe uma escolha de estratgia para o processamento de juno, mas temos tambm uma escolha de qual juno ser computada primeiro. Existem muitas estratgias possveis a considerar. Sero analisadas diversas delas a seguir. Estratgia 1: A juno depsito x cliente usando uma das tcnicas apresentadas anteriormente. Uma vez que nome-cliente uma chave de cliente, sabemos que o resultado dessa juno tem no mximo 10.000 tuplas. Se ao construir um ndice em agncia para nome-agncia, pode-se computar agncia x (depsito x cliente). Considerar cada tupla t de (depsito x cliente) e buscar a tupla em agncia com um valor de nome-agncia igual a t[nome-agncia]. Uma vez que nome-agncia uma chave de agncia, sabe-se que preciso examinar apenas uma tupla de agncia para cada uma das 10.000 tuplas em (depsito x cliente). O nmero exato de acessos a blocos requeridos por esta estratgia depende do modo pelo qual computamos (depsito x cliente) e do modo pelo qual agncia armazenada fisicamente. Diversos exerccios examinam os custos de vrias possibilidades. Estratgia 2: Uma juno tripla sem construir qualquer ndice. Isto requer a verificao de 50*10.000*200 possibilidades, ou num total de 100.000.000.

Estratgia 3: Em vez de se executar duas junes, executa-se um par de junes de cada vez. Essa tcnica primeira envolve a construo de dois ndices: Sobre agncia usando nome-agncia Sobre cliente usando nome-cliente. Em seguida considera-se cada tupla t em depsito. Para cada t, busca-se as tuplas correspondentes em cliente e as tuplas correspondentes em agncia. Assim, basta examinar cada tupla de depsito exatamente uma vez. A estratgia 3 representa uma forma que no havamos considerado anteriormente. Esta no corresponde diretamente a uma operao da lgebra relacional. Em vez disso, combina duas operaes e uma operao especial. Com a estratgia 3, freqentemente possvel executar uma juno de trs relaes mais eficientemente do que usando duas junes de duas relaes. Os custos relativos dependem do modo pelo qual as relaes esto armazenadas, da distribuio de valores dentro das colunas e da presena de ndices (SILBERCHATZ; KORTH; SUDARSHAN, 1999). As estratgias de juno que foram consideradas at agora assumem que um nico processador est disponvel para computar a juno. Numerosas arquiteturas tm sido propostas para processadores paralelos para aplicaes de banco de dados. Considerase uma arquitetura simples com os seguintes recursos: 1) todos os processadores tm acesso a todos os discos; ou 2) todos os processadores compartilham a memria principal. As tcnicas apresentadas a seguir para o processamento paralelo de junes podem ser adaptadas as outras arquiteturas nas quais cada processador tem sua prpria memria particular. Nas tcnicas que foram discutidas para processar junes em um nico processador, a eficincia obtida pela reduo do nmero de pares de tuplas que precisam ser testadas. A meta de um algoritmo de juno paralela dividir os pares a serem testados entre os diversos processadores. Cada processador ento computa parte da juno. No passo final, os resultados de cada processador so coletados para produzir o resultado final. Idealmente, o trabalho geral de computar a juno particionado igualmente entre todos os processadores. Se tal diviso feita sem qualquer sobrecarga, uma juno paralela usando N processadores tomar 1/N do tempo que a mesma juno tomaria em um nico processador. Na prtica, o aceleramento menos dramtico por diversas razes:

Ocorre sobrecarga ao se particionar o trabalho entre os processadores; Ocorre sobrecarga ao se coletar os resultados computados para cada processador para produzir o resultado final; O esforo feito para dividir o trabalho igualmente apenas uma aproximao, assim alguns processadores podem ter mais trabalho do que outros. O resultado final no pode ser obtido at que o ltimo processador tenha de fato terminado;

Os processadores podem competir por recursos compartilhados do sistema. Isto resulta em demoras medida que os processadores esperam que outros processadores liberem os recursos. Basta considerar o exemplo contendo duas tabelas (D, C), assumir que se tem N processadores P1, P2, ..., PN. Dividindo D em N participaes de igual tamanho: D1, D2,..., DN. (Para simplificar, o ideal seria assumir que o tamanho da relao depsito um mltiplo de N). Ento cada processador Pi computa D x C em paralelo. No passo final, computa-se a unio dos resultados parciais computados por cada processador. O custo desta estratgia depende de diversos fatores, entre outros: a escolha do algoritmo de juno usado por cada processador; o custo de montagem do resultado final; os atrasos impostos pela conteno de recursos. Embora cada processador use sua prpria partio de depsito, todos os processadores fazem acesso a cliente. Se a memria principal no suficientemente grande para guardar a relao cliente inteira, os processadores precisam sincronizar seus acessos aos clientes para reduzirem o nmero de vezes que cada bloco de cliente precisa ser lido do disco. O potencial de conteno da memria principal ao armazenar tuplas de cliente sugere tomar alguns cuidados na diviso do trabalho entre os processadores para reduzir a conteno (YANG, Y; SINGHAL, M; 1997). Existem muitos modos de fazer isso. Uma tcnica simples usar uma verso paralela do algoritmo de juno com hashing. 5.3.2.4) Junes em pipeline Existe a possibilidade de computar diversas junes em paralelo. Esta uma questo importante uma vez que, muitas consultas no mundo real, particularmente aquelas expressas em termos de uma viso, envolvem diversas relaes. Vamos considerar uma juno de quatro relaes: r1 x r2 x r3 x r4 Claramente, computa-se t1 r1 x r2 em paralelo com t2 r3 x r4. Quando essas duas computaes estiverem completas, podemos computar: t1 x t2. Um paralelismo ainda maior pode se feito ajustando um duto (pipeline) que permite as trs computaes sejam feitas em paralelo. Diramos que o processador execute a computao r1 x r2 e diramos que P2 execute r3 x r4. medida que P1 computa tuplas em r1 x r2, ele deixa essas tuplas disponveis para o processador P3. Da mesma forma, medida que o processador P2 computa tuplas em r3 x r4, ele torna essas tuplas disponveis para P3. Assim, P3 tem disponveis algumas tuplas de r1 x r2 e r3 x r antes que os processadores P1 e P2 tenham acabado totalmente seus servios. P3 pode usar essas tuplas disponveis para iniciar a computao de (r1 x r2) x (r3 x r4) antes mesmo que r1 x r2 e r3 x r4 tenham sido completamente computadas. Essa juno em duto, que mostra um "fluxo" de tuplas de P1 para P3 e de P2 para P3. Em uma mquina paralela assumida, as tuplas so passadas via memria principal compartilhada. Esta tcnica aplicvel a outras arquiteturas paralelas.

Os processadores P1 e P2 esto livres para usar qualquer um dos algoritmos de juno que consideramos antes. A nica modificao que quando uma tupla t adicionada ao resultado, t precisa ser tornada disponvel para P3 colocando t na fila. Alm disso, uma entrada especial de fila consistindo em ENDP1 e ENDP2, respectivamente, feita aps o trmino da computao (BOSCATTO, DAMINELLO, 1999). 5.3.3) Escrita de frases SQL que faam uso dos ndices criados 5.3.3.1) Minimizar o acesso seqencial O acesso (ou varredura) seqencial de tabelas a forma mais simples de acesso de dados. Uma verificao de tabela simplesmente executada lendo todas as linhas da tabela. Dependendo do SGBD, um tipo alternativo de varredura pode existir, chamada verificao de tablespace. A verificao de tablespace a leitura toda pgina da tablespace que pode conter mais de uma tabela. Obviamente, uma verificao de tablespace executar mais lentamente que uma verificao de tabela porque I/O adicional ser includo nos dados de leitura (LONEY; THERIAULT, 1999). Outra forma de varredura a verificao de parties. Se o SGBD pode determinar que o dados a serem acessados existem em certas parties de uma tabela de multi parties (ou tablespace), pode limitar os dados que so verificados s parties apropriadas. Tipicamente, o otimizador escolhe a verificao dados para um das razes seguintes: A questo que usa um ndice possivelmente no pode ser satisfeita porque nenhum ndice est disponvel, nenhum predicado emparelha o ndice, ou o predicado impede o uso de um ndice; Uma porcentagem alta das linhas na tabela qualifica neste caso que usar um ndice pode ser menos eficiente porque a maioria das linhas de dados precisa ser lido de qualquer maneira; Os ndices que tm emparelhamento de predicados tm baixas relaes de agrupamento e s so eficientes para quantias pequenas de dados; A tabela to pequena que uso de um ndice seria na verdade prejudicial. Para tabelas pequenas, acrescentando acesso de ndice ao acesso de tabela pode resultar em I/O adicional, em vez de menos I/O (KOCK; KEVIN, 1997). Ao ajudar o desempenho de uma verificao, o otimizador pode invocar prefetch de dados. Prefetch de dados faz o SGBD ler dados chamados consecutivamente at mesmo no cache de dados antes de lhes pedissem. Essencialmente, o prefetch de dados uma leitura frente do mecanismo, quando dados verificados j existem em memria. Prefetch de dados particularmente til para tabela e tablespace verificada, mas pode ser prtico para qualquer tipo de acesso de dados seqencial. Se prefetch de dados est disponvel, se usado, depende do SGBD. O otimizador pode escolher desdobrar isto quando o caminho de acesso formulado, ou o SGBD pode escolher virar em prefetch de dados quando a questo est sendo corrida (MULLINS, 2002).

5.3.3.2) Obtendo benefcio de acessos indexados Das muitas decises que devem ser tomadas pelo otimizador, uma das mais importantes para desempenho a questo se um ndice ser usado para satisfazer a questo. Para determinar isto, o otimizador tem que descobrir primeiro se um ndice existe. Claro que, antes do otimizador relacional usar um ndice para satisfazer uma questo, um ndice apropriado j tem que existir. Adicionalmente, pelo menos a coluna indexada deve ser referenciada dentro de um predicado. O SGBD no capaz de usar um ndice para toda clusula WHERE, isso porque cada SGBD tem uma lista diferente do que , e o que no indexado. Alm disso, o que indexado tende a mudar de verso a verso de cada SGBD. A listagem 5.4 mostra o modo mais simples de acesso indexado (lookup). Listagem 5.4: O otimizador relacional pode escolher usar um ndice de muitos modos diferentes. O primeiro, e mais simples, tipo de acesso indexado o lookup de ndice direto. Para executar um lookup de ndice direto, o SGBD inicia os passos seguintes: 1 - O valor comparado no predicado de SQL aos valores armazenados na pgina raiz do ndice. Baseado nestas comparaes, o SGBD decidir se vai ou no usar o ndice para consultas nessa pgina; 2 - Se pginas internas do ndice existirem, a pgina apropriada carregada, e o valor comparado para determinar qual pgina ser acessada; 3 - A pgina apropriada carregada; a pgina de ndice contm ponteiros para as linhas em disco; 4 - Baseado nos ponteiros obtidos, o SGBD l as pginas de dados de tabela apropriadas.

H dois tipos bsicos de varreduras de ndice: matching index scans e nonmatching. Um ndice matching index scans s vezes chamado posicionamento absoluto. Um ndice matching index scans comea pela pgina pela raiz de um ndice e trabalha at uma pgina de folha, da mesma maneira como um lookup de ndice direto faz. Porm, porque a chave completa do ndice no est disponvel, o SGBD tem que verificar a folha do ndice que procura os valores que esto disponveis, at que tudo seja verificado e os valores sejam recuperados outro (SILBERCHATZ; KORTH; SUDARSHAN, 1999). Para um matching index scan ser solicitado, voc tem-se que especificar a coluna de ordem na chave de ndice, em outras palavras, para a primeira coluna especificada no ndice DDL. Vamos considerar as conseqncias de no especificar a coluna de ordem na consulta. Como exemplo podemos mostrar a listagem 5.5: Listagem 5.5: Na consulta abaixo, o SGBD usa um ndice tipo nonmatching scan por julgar ser o melhor ndice para satisfazer a consulta.

SELECT last_name, first_name, middle_initial, empno

FROM employee WHERE work_code AND dept

= 1 = 001000;

Em tais situaes, o SGBD pode desdobrar um ndice de nonmatching scan, s vezes chamado de posicionamento relativo. Quando um ponto de partida no pode ser determinado, a primeira coluna na chave de ndice no especificada, o SGBD no pode usar a estrutura de rvore de ndice. Um ndice de nonmatching scan comea com a primeira pgina de folha no ndice e verifica toda folha subseqente chamando a consecutivamente, enquanto aplicando os predicados disponveis (WEININGER, 2002). Um ndice de nonmatching scan pode ser mais eficiente que uma tabela ou tablespace scan, especialmente se as pginas de dados que devem ser acessadas esto em ordem agrupada. Isto mostra cluster contra uncluster de ndice de acesso. Quaisquer dos mtodos anteriores para acesso indexado pode ser usado com ambos agrupados e ndices de uncluster. Porm, em ndice scan isso no provvel uma vez que as tabelas de acesso a dados de pginas sejam muito eficientes quando o dados no so agrupados: Em acesso de ndice agrupado, como procede na pgina de folha, nunca existe pedidos para leitura dos mesmos dados chamados duas vezes. Unclustered indexa acesso pedindo os mesmos dados chamando-os em tempos mltiplos porque o dados so esparramados ao longo da tabela (YANG, Y; SINGHAL, M; 1997). A listagem 5.6 mostra a tcnica de acesso conhecida como index screening. Listagem 5.6: Com index screening, matching index scan terminado nas colunas principais de um ndice de multi-colunas, e predicados adicionais so aplicados durante o scan. Esta tcnica til se no so especificadas algumas colunas de um ndice de multi-colunas na questo. Considere outra questo de amostra:

SELECT last_nme, empno FROM employee WHERE position = MANAGER AND work_code = 1 AND salary > 50000,00
Agora vamos assumir que um ndice foi criado nas colunas seguintes na ordem seguinte: position, work_code, dept, e salary. O ndice pode ser escondido aplicando um ndice matching scan em position e work_code, e ento um nonmatching scan para o salary maior que 50,000.00, mas s para essas linhas que emparelharam position = 'MANAGER' e work_code = 1. Um dos tipos mais eficientes de acesso indexado index-only access, s vezes chamado index covering. Vamos considerar a questo que acabamos de examinar. Mais adiante assume que um ndice foi criado nas colunas: position, work_code, dept, salary, last_name, e empno. Em tal um enredo, o SGBD pode satisfazer a questo que usa s o ndice porque todos os dados pedidos na lista SELECT e os predicados existem no ndice. Nenhum I/O adicional para pginas de dados da tabela requerido. Com acesso atravs de index-only, o SGBD pode satisfazer a questo da verificao folha simplesmente chamando o ndice. Um nonmatching index-only

utilizado podendo ser muito mais rpido que a verificao a uma tablespace ou tabela porque suas entradas so geralmente menores que as linhas da tabela, e conseqentemente mais dados so eruditos com cada I/O (SILBERCHATZ; KORTH; SUDARSHAN, 1999). Para encorajar acesso atravs de um index-only o DBA pode sobrecarregar o ndice, somando colunas extras que aparecem na lista SELECT de declaraes de SQL. Fazendo isso pode prover um reembolso de desempenho grande, mas vem s custas de exigncias de armazenamento de disco adicionais porque esto sendo indexadas colunas adicionais. Uma outra maneiro de acesso indexado a apresentada na listagem 5.7. Listagem 5.7: Um tipo final de acesso indexado multi-index access. Com um multi-index access, o SGBD usa mais que um ndice para satisfazer um nico caminho de acesso. Por exemplo, considere outra variao de nossa questo de tabela de empregado:

SELECT last_name, empno FROM employee WHERE position = MANAGER AND work_code = 1;
Nessa situao temos dois ndices: um na coluna de position e outra na coluna de work_code. A questo especifica dois predicados cada um dos quais so apoiados por um ndice diferente. Em vez de escolher usar um ndice ou o outro, o otimizador relacional pode combinar os dois ndices para devolver os dados corretos eficazmente (FANDERUFF, 2003). H dois tipos de multi-index access dependendo da maneira como os predicados so amarrados (AND ou OR). Alguns SGBDs suportam apenas o AND como operador lgico, considerando que outros suportam ambos AND e OR. O DBA deveria fundar esta deciso na eficincia do SGBD usando multi-index access (BOSCATTO, DAMINELLO, 1999). A listagem 5.8 exibe algumas situaes onde o SGBD acaba tendo que ordenar uma consulta, isso por sua vez por prejudicar a performance da mesma. Listagem 5.8: O SGBD pode precisar ordenar dados para satisfazer pedidos de SQL. Ordenar valido, porm evitado se possvel. Ordenar pode ser necessrio quando as clusulas seguintes so especificadas: DISTINCT: Quando esta clusula especificada, o SGBD exige para toda coluna dos dados resultantes estar em ordem de forma que as linhas duplicadas podem ser removidas do resultado; UNION: Esta operao requer as colunas em cada lista SELECT a ser ordenada porque os resultados no podem ter nenhuma linha duplicada; GROUP BY: Quando esta clusula especificada, o SGBD exige ordenar dados pelas colunas especificadas para se agregar dados; ORDER BY: Quando esta clusula especificada, o SGBD assegurar que os resultados sero ordenados pelas colunas especificadas.

Considere a declarao SQL seguinte:

SELECT last_name, first_name, middle_initial, empno, position FROM employee WHERE position in (MANAGER,DIRECTOR,VICE PRESIDENT) ORDER BY last_name;
Se um ndice existir na coluna last_name, a consulta pode usar este ndice. Usando um ndice o banco agiliza consultas, alm do que diminui o custo de CPU adicional exigido para ordenar. Claro que, se o ndice for ser usado de qualquer maneira, a escolha no trs os resultados esperados. Usando um ndice, pode ou no ser realmente mais rpido que a verificao dos dados considerando toda a tabela. Essa agilidade se da aos seguintes critrios (TEKNO, 1996): Nmero de linhas qualificativas; Velocidade; Caractersticas do ndice. Por que o ndice no foi escolhido? Situaes que s vezes surgem onde voc pensa que o otimizador deveria ter escolhido um ndice, mas no fez. Qualquer nmero de razes pode fazer o otimizador evitar usar um ndice. Consulte a lista seguinte para modos para encorajar seleo de ndice: A questo especifica um argumento de procura? Se nenhum predicado usar um argumento de procura, o otimizador no pode usar um ndice para satisfazer a questo; Voc est unindo um nmero grande de tabelas? O otimizador dentro de algum SGBD pode produzir plano de execuo imprevisvel resulta ao unir um nmero grande de tabelas; As estatsticas so correntes? Se foram inseridas quantias grandes de dados, UPDATE, DELETE, deveriam ser recapturadas estatsticas de banco de dados para assegurar que o otimizador tem informao em dia na qual consegue gerar planos de execuo; Existem stored procedures (procedimentos armazenados)? s vezes o SGBD prov operaes por meio de que uma stored procedure, uma vez compilou, no reformular um plano de execuo para execues subseqentes. Voc pode precisar recompilar ou reotimizar a stored procedure para tirar proveito de estatsticas em dia, ndices novos, ou qualquer outra mudana de banco de dados pertinente; So precisos predicados adicionais? Um diferencial na clusula WHERE poderia permitir o otimizador possivelmente a considerar um ndice diferente (JARKE, KOCH, 1984). 5.3.4) Habilitando o Acesso Paralelo

Quando o paralelismo invocado pelo SGBD, so invocadas tarefas simultneas mltiplas para acessar os dados. Dois tipos bsicos de paralelismo podem ser apoiados pelo SGBD: Paralelismo de I/O habilita I/O simultneo que flui para ser iniciado para uma nica consulta. Verificando tarefas de I/O paralelas, podem aumentar o desempenho de I/O significativamente em consultas encadeadas. Quebrando os dados acessados para uma consulta em fluxos de I/O simultneos executados em paralelo pode reduzir o tempo global da consulta (TEKNO, 1996); Paralelismo de CPU habilita multi-tarefas de CPU processadas dentro de uma consulta. Paralelismo de CPU invoca tambm paralelismo de I/O porque cada mquina de CPU requer seu prprio fluxo de I/O. Paralelismo de CPU decompe uma consulta em consultas menores mltiplas que podem ser executadas simultaneamente em processadores mltiplos. Paralelismo de CPU pode reduzir o tempo de uma consulta (WEININGER, 2002). Assegurando que aqueles planos de execuo so formulados com o uso de ndice correto e em um tempo estimado que o processo consome, isso nem sempre garantia de uma boa performance por muito tempo, o desempenho pode sofrer com o aumento da base de dados. DBA deveria treinar o pessoal de desenvolvimento de aplicao para entender otimizao relacional e criar um SQL otimizado. Claro que, a responsabilidade cai no programador de aplicao em codificar SQL eficiente. Porm, o DBA a sentinela de desempenho de banco de dados relacional. Quando problemas de desempenho acontecerem, o DBA o que tem que procurar a causa do problema e sugestionar solues para os problemas. Alm disso, o DBA deveria administrar revises de desgnio para procurar e melhorar SQL ineficiente antes dos usurios finais acessarem essas aplicaes em modo de produo (CARATTI, 2004). 5.3.5) Acessos a Views Uma das decises que devem ser tomadas durante otimizao como acessar dados de vises. Uma questo que acessa uma viso basicamente uma declarao SQL embutida dentro de outra declarao SQL. Quando o otimizador determinar o caminho de acesso para a consulta que contm a viso, tambm tem que determinar como solucionar a viso SQL. Lembre-se de que a viso e o SQL que acessa a viso podem referenciar tabelas mltiplas e vises adicionais (FANDERUFF, 2003). Podem ser usados dois mtodos para aperfeioar SQL e as vises referenciadas: materializao em tempo de execuo e fuso de viso. O mais eficiente dos dois mtodos fuso de viso. Como insinua o nome, quando a fuso desdobrada, o SQL na viso DDL fundido com o SQL que referencia a viso. O SQL fundido usado para formular um caminho de acesso contra as tabelas bsicas das vises. A segunda tcnica ocorre quando o otimizador no puder combinar o SQL na viso com o SQL que acessa a viso. Nesse caso, na execuo o SGBD cria um arquivo de

trabalho intermedirio para manter os resultados da viso. O SQL que acessa a viso executado ento conta o arquivo de trabalho que contm os dados de viso. Materializao de viso em tempo de execuo no to eficiente quanto fuso de viso porque devem ser recobrados dados e devem ser armazenados em um arquivo de trabalho temporrio (MULLINS, 2002). Quando freqente a situao de materializao, interessante optar pela viso materializada, em tempo de criao ao invs de execuo. Na viso materializada, os dados da viso so armazenados em uma tabela e mantidos pelo SGBD quando as tabelas base so alteradas. Assim, em tempo de execuo, diviso de dados obtida diretamente, sem a necessidade de reconstruir a viso. 5.3.6) Reescrita de Consultas Os otimizadores relacionais so bastante inteligentes para reescrever SQL mais eficazmente durante o processo de otimizao. Por exemplo, o otimizador poderia converter uma subquery em uma juno equivalente. Alternativamente, poderia testar formulaes de predicado equivalentes, diferentes para determinar qual cria o melhor caminho de acesso. Por exemplo, uma vez que os predicados seguintes so equivalentes, o otimizador pode reescrever a questo de ambos os modos para ver qual produz o melhor caminho de acesso. A listagem 5.9 faz uma comparao entre duas formas de escrita. Listagem 5.9: Reescrita de consulta buscando um melhor caminho de acesso no banco de dados.

WHERE column1 >= 1 AND column1 <= 100 WHERE column1 BETWEEN 1 AND 100
Adicionalmente, o otimizador pode reescrever consultas criando predicados deduzidos. Um exemplo disto uma caracterstica conhecida como predicado de fechamento transitivo no qual o otimizador acrescenta um predicado consulta para melhorar desempenho. Considere a declarao da listagem 5.10. Listagem 5.10: Comparao entre consultas com modificao na clusula WHERE, visando uma melhor performance no banco de dados.

SELECT d.dept_name, e.last_name, e.empno FROM employee e, Department d WHERE e.deptno = d.depto AND d.depto = 808;
A declarao SQL funcionalmente equivalente declarao de SQL seguinte:

SELECT d.dept_name, e.last_name, e.empno FROM employee e, Department d WHERE e.deptno = d.depto

AND

e.depto = 808;

A nica diferena o segundo predicado, mas porque a coluna depto ss as mesmas em ambas as tabelas, no importa se ns conferimos depto da tabela de empregado ou da tabela de departamento. Porm, isso poderia fazer uma diferena em termos de desempenho. Por exemplo, um ndice poderia existir no acesso das colunas de depto, em uma determinada tabela, ou talvez uma das tabelas significativamente maior que o outro (SILBERCHATZ; KORTH; SUDARSHAN, 1999). 5.3.7) Revisando caminhos de acesso O programador ou DBA pode examinar os caminhos de acesso escolhidos pelo otimizador relacional. Os comandos e processo realizavam isto dependendo do SGBD. Normalmente o comando para verificar o acesso a esses caminhos o EXPLAIN. Microsoft SQL Server faz uso do comando SHOW-PLAN. Oracle e DB2 usam um mtodo diferente, isto a declarao EXPLAIN. Antepondo a declarao de SQL com o comando EXPLAIN, a informao de caminho de acesso determinada pelo otimizador escrita fora para uma tabela de sistema. O DBA ou programador pode examinar essa tabela para interpretar os caminhos de acesso especificados pelo otimizador. Por exemplo, vamos considerar a listagem 5.11. Listagem 5.11: Exemplo de como gerar um plano de execuo atravs do comando EXPLAIN PLAN no Oracle.

EXPLAIN plan SET STATEMENT_ID = emptest FOR SELECT position, last_name, first_name, middle_initial, empno FROM employee WHERE position in (MANAGER,DIRECTOR,VICE PRESIDENT) ORDER BY position;
A clusula de STATEMENT_ID prov um identificador para localizar o caminho de acesso da declarao de SQL. As informaes sobre o caminho de acesso usado incluem: Se um ndice usado, e nesse caso, o quanto usado; O mtodo de unio est sendo usado; Se acesso paralelo usado; Se ordenao requerida. 5.3.7.1) Forando um caminho de acesso Por exemplo, Microsoft SQL Server prov a opo de FORCEPLAN. Quando FORCEPLAN for configurada como SIM, o otimizador une as tabelas na ordem na qual eles so codificados na declarao de SQL.

Outro exemplo, Oracle prov sugestes que podem ser usadas para guiar o otimizador relacional para escolher caminhos de acesso especficos. So especificadas sugestes diretamente na consulta de SQL embutida dentro / * + * /. A listagem 5.12 mostra um exemplo de como forar um caminho de acesso. Listagem 5.12: Consulta mostrando um exemplo de como forar o otimizador a seguir um caminho (a usar determinado ndice). Nesse caso, o otimizador no segue o caminho que ele julga ser o melhor, e sim o caminho apontado por quem escreveu a consulta. Nesse exemplo, o otimizador usa o algoritmo USE_NL (nested loop = loop aninhado), conforme descrito na clusula SELECT da consulta.

SELECT /* + USE_NL */ e.position, e.last_name, e.empno, d.manager FROM employee e, departament d WHERE d.dept_id = e.dept_id AND position IN (MANAGER,DIRECTOR,VICE PRESIDENT) ORDER BY position;
Esta consulta usa a sugesto da Oracle USE_NL para forar um loop aninhado para computar a juno. Podem ser providas sugestes adicionais para forar a escolha de ndice, forar o uso de paralelismo, ou forar outras metas de otimizao (BOSCATTO, DAMINELLO, 1999). Essas tcnicas devem ser usadas com critrios e precaues. normalmente melhor deixar o otimizador relacional escolher os caminhos de acesso a menos que: O programador tenha conhecimento detalhado da quantia e tipo de dados armazenados nas tabelas envolvidas; Esteja razoavelmente seguro que voc pode determinar o melhor join ordenado pelo otimizador; Estatsticas de banco de dados no estejam em dia, assim o otimizador no est trabalhando com informao suficiente sobre o ambiente de banco de dados. Mtodos alternativos esto disponveis para encorajar o otimizador a selecionar caminhos de acessos diferentes. Um mtodo comum de SQL mudar a consulta tal que os resultados so os mesmos, mas otimizador incapaz de usar certos caminhos de acesso. Por exemplo, vamos considerar a listagem 5.13. Listagem 5.13: Consulta mostrando que em determinadas consultas existem condies na clusula WHERE que acabam sendo desnecessrias.

SELECT last_name, first_name, empno, depto FROM employee WHERE empno BETWEEN 001000 AND 009999 AND (salary > 50000,00 OR 0=1) ORDER BY last_name;

O resultado dessa consulta exato mesmo com, ou sem o OR 0 = 1 componente do ltimo predicado. Porm, alguns produtos do SGBD probem o uso de um ndice com tais formulaes de consulta. Enquanto juntando OR 0 = 1 eliminar a possibilidade de usar um ndice para apoiar o predicado de salary. O DBA tem que aprender os fundamentos de tunning de SQL de cada SGBD que ele administra (JARKE, KOCH, 1984). 5.3.8) Algumas Regras bsicas para um SQL bem escrito Regra 1: Dependncia A resposta para toda pergunta sobre desempenho de banco de dados "depende".Um DBA prspero saber em que depende. Por exemplo, se algum perguntar qual o melhor caminho de acesso para meu SQL examinar? ", a melhor resposta depende. Por que? Se vrias linhas devem ser devolvidas, uma tabela verificada atravs de sua chave provvel ser mais eficiente que um acesso atravs de um ndice. Porm, se s uma linha ser devolvida, um lookup de ndice direto provavelmente executar melhor. Para consultas que devolvem entre um e todas as linhas, o desempenho de caminhos de acesso depender em como os dados agruparam, qual verso do SGBD est em uso, se paralelismo pode ser invocado, e assim sucessivamente. Ser cuidadoso, nunca usar palavras como sempre ou nunca, mesmo porque os resultados em sua maioria dependem de muitos outros fatores (CARATTI, 2004). Regra 2: Ter cuidado com o que se pede O arranjo de elementos dentro de uma consulta pode mudar desempenho de consulta. Uma boa regra bsica, embora dependa do SGBD, colocar o predicado mais restritivo onde o otimizador pode ler isto primeiro. Em Oracle, o otimizador l a clusula WHERE do fim para o comeo, ento, o predicado mais restritivo deveria ser colocado no final. Colocando o predicado mais restritivo onde o otimizador pode ler isto primeiro permite o otimizador a reduzir o primeiro feixe de resultados antes de proceder ao prximo predicado. O prximo predicado ser aplicado ao subconjunto de dados que foram selecionados pela condio mais seletiva, em vez de contra a tabela inteira (BOSCATTO, DAMINELLO, 1999). Regra 3: KISS Uma regra bsica para vrios tipos de atividades de TI seguir o princpio de KISS (Faa-o simples, estpido Keep It Simple, Stupid). SQL mantendo-se simples faz desenvolvimento e manuteno uma tarefa mais fcil. Uma declarao de SQL simples mais fcil decifrar e mais fcil mudar. Com SQL simples, programador de aplicao pode executar o trabalho dele/dela mais facilmente do que com SQL complexo (FANDERUFF, 2003). Regra 4: Recupere o que preciso

Minimizar a quantia de dados devolvida por suas declaraes de SQL, especificando o nmero mnimo absoluto de colunas na lista SELECT. Se a coluna no necessria para satisfazer a exigncia empresarial, no pea que seja devolvido no resultado. Programadores freqentemente copiam declaraes de SQL para usar como modelos para declaraes novas. s vezes o programador esquece de apagar colunas quando ele s precisa de um subconjunto das colunas da consulta original. Isto pode atrapalhar o desempenho da consulta. Quanto mais colunas que deve ser devolvida pelo SGBD, o maior o processamento e trfego de rede. Outro problema comum pedir dados desnecessrios. Considere a declarao de SQL da listagem 5.14. Listagem 5.14: O exemplo abaixo mostra que existe uma coluna desnecessria na clusula SELECT. Isso de certa forma acaba por prejudicar a performance da consulta.

SELECT position, FROM employee WHERE last_name =

last_name, empno SMITH;

No h nenhuma razo para especificar a coluna de last_name na lista SELECT desta declarao de SQL. Sabe-se que last_name deve ser 'SMITH' para o resultado inteiro fixado na clusula WHERE. Devolvendo apenas as colunas necessrias, a consulta fica mais eficiente. Deve-se tambm minimizar o nmero de linhas a serem devolvidas codificando propriamente a clusula WHERE para toda declarao de SQL. Quanto mais dados podem ser filtrados fora do resultado fixado pelo SGBD, mais eficiente fica a consulta, devido ao fato de menos registros serem mostrados a quem os pediu. s vezes programadores de aplicao evitam codificao apropriada em clusulas WHERE numa tentativa de simplificar declaraes de SQL. Quanto mais informao o otimizador tem sobre os dados a serem recuperados, melhor ser o caminho de acesso. Um sinal potencial de degradao de desempenho achar declaraes SQL em um programa de aplicao que seguido imediatamente por sries de clusulas IF - THEN - ELSE. Tentar ajustar a questo movendo as declaraes IF - THEN - ELSE para clusulas WHERE (TEKNO, 1996). Regra 5: Evite Produtos Cartesianos Sempre que os predicados no existem por unir duas tabelas, o SGBDR tem que executar um produto cartesiano. Esta a combinao de toda linha de uma tabela com toda linha da outra tabela. No so eliminadas linhas de nonmatching porque no h nada que pode ser emparelhado. Os resultados de um produto cartesiano so difceis de interpretar e conter nenhuma informao diferente de uma lista simples de todas as linhas de cada tabela (KOCK; KEVIN, 1997). Regra 6: Uso judicioso de OR

O operador lgico OR pode ser problemtico para desempenho. Se voc pode converter uma declarao de SQL que usa OR em uma que usa IN, provvel que desempenho seja melhor. Por exemplo, vamos considerar a listagem 5.15. Listagem 5.15: A comparao entre as consultas abaixo mostra como o operador OR pode causar problemas em certas consultas. s vezes o mesmo substitudo por outro comando pode gerar ganho considerado no quesito performance.

SELECT e.position, e.last_name, e.empno, d.manager FROM employee e, Departament d WHERE d.dept_id = e.dept_id AND position = MANAGER OR position = DIRECTOR OR position = VICE PRESIDENT ORDER BY position; SELECT e.position, e.last_name, e.empno, d.manager FROM employee e, Departament d WHERE d.dept_id = e.dept_id AND position IN (MANAGER,DIRECTOR,VICE PRESIDENT) ORDER BY position;
Claro que, seus resultados podem variar, dependendo em uso do SGBD e a natureza dos dados (TEKNO, 1996). Regra 7: Uso judicioso de LIKE O operador LIKE outra problemtica. muito fcil de criar problemas de desempenho quando usado em SQL. Por exemplo, considere o SQL da listagem 5.16. Listagem 5.16: Assim como o operador OR, o operador LIKE tambm pode trazer problemas em algumas consultas. Abaixo segue uma comparao que ilustra melhor esse problema (contido em algumas consultas, no em todas).

SELECT position, last_name, empno FROM employee WHERE dept_id LIKE %X ORDER BY position;
Esta consulta devolver informao de empregado para todos os empregados que trabalham em qualquer departamento em onde dept_id termina 'X.' Porm, o otimizador relacional ter que verificar os dados para solucionar esta consulta, sendo que no h nenhum modo para usar um ndice. Uma maneira de reescrever esta consulta de forma mais adequada e menos prejudicial seria por exemplo, usar o dept_id comeando com qualquer um 'A' ou 'B'. Nesse caso a consulta ficaria da seguinte maneira:

SELECT position, last_name, empno FROM employee WHERE dept_id LIKE A%X OR dept_id LIKE B%X
Neste caso, o SGBD pode poder usar um ndice nonmatching para verificar se o ndice existe na coluna dept_id (TEKNO, 1996).

Regra 8: COMMIT freqente Ao codificar programas para trabalhar com transao de grupo, importante emitir declaraes COMMIT regularmente. A declarao COMMIT finaliza modificaes ao banco de dados. Quando um COMMIT emitido, locks no banco de dados modificado podem ser liberados. Uma considerao adicional para DBAs Oracle o impacto de um COMMIT nos segmentos de rollback. Segmentos de Rollback so usados pelo Oracle para armazenar transaes completas antes das mudanas serem escritas de fato na tabela. Quando se emite um COMMIT em Oracle, o contedo do segmento de rollback tambm liberado.Ento, um DBA tem que assegurar que os programadores de aplicao emitam bastantes declaraes COMMIT para minimizar o impacto de locks, mantendo segmentos de rollback a um tamanho manejvel (LONEY; THERIAULT, 1999). Regra 9: Preveno contra Geradores de Cdigos Previna-se de geradores de cdigo de aplicao e ferramentas semelhantes que automaticamente criam SQL. Muitas destas ferramentas exigem recompilar cada declarao de SQL aps seu aperfeioamento. Regra 10: Considere o uso de Procedimentos Armazenados (Stored Procedures) A degradao de desempenho, devido a trfego de rede repetido, pode ser minimizada usando procedimentos armazenados porque s um nico pedido preciso para execut-lo. Dentro do procedimento armazenado, podem ser emitidas mltiplas declaraes SQL, os resultados so processados e enviados aplicao que os solicitou. Sem o procedimento armazenado, declaraes de SQL mltiplas teriam que ser enviadas via rede. Adicionalmente, SQL em procedimentos armazenados pode executar melhor que o mesmo SQL fora do procedimento armazenado se o SGBD analisar gramaticalmente e compilar a declarao antes de tempo de execuo (FANDERUFF, 2003).

6) Estudo de caso
O estudo de caso foi baseado em um sistema de controle de produo industrial, sistema esse que controla produo de diversos produtos de vrios segmentos. Esse sistema controla principalmente parte de cho de fbrica da empresa, acompanhamento da produo, controles especficos de cada setor industrial, entre outros. Como o sistema relativamente grande, foram extradas algumas partes dos diferentes mdulos do sistema para se executar a tarefa de tunning e assim mostrar algumas tcnicas para aperfeioamento das consultas. Tambm vale destacar que o sistema de onde foram retirados nossos exemplos foi desenvolvido e est em produo sobre uma plataforma Oracle, portanto os exemplos seguem a arquitetura e padres da Oracle.

6.1) Arquitetura do Oracle

Para gerenciar um ambiente Oracle efetivamente, o DBA tem que entender a arquitetura bsica do Oracle. Oracle composto de cinco componentes bsicos que operam de uma maneira integrada para prover apoio pelas tarefas de cliente: estruturas de arquivo, estruturas de memria, processos, segmentos de rollback, e redo logs (LONEY; THERIAULT, 1999). Uma instncia Oracle a combinao das estruturas de memria e processos que so alocados quando o banco de dados iniciado. Um banco de dados Oracle tem estruturas fsicas (arquivos de dados) e estruturas lgicas (tabelas, ndices). A estrutura fsica de um banco de dados Oracle determinada pelos arquivos criados ao nvel de sistema operacional pela instncia Oracle, durante criao de banco de dados ou pelo DBA durante a operao normal. Um banco de dados Oracle inclui trs estruturas de arquivo fsicas: Arquivos de Controle - Arquivos pequenos de parmetros que so usados pelo banco de dados de Oracle; Arquivos Redo logs - Registros de mudanas feitas sobre os dados. Os arquivos redo logs so usados em circunstncias de recuperao para assegurar que nenhum dado est perdido se um fracasso vier a acontecer durante a escrita em disco; Arquivos do Banco de Dados - Arquivos que contm a informao de banco de dados, incluindo dados de sistema e dados de aplicao. Um arquivo de parmetro da Oracle contm todos os parmetros de configurao. Estes parmetros podem ser configurados com valores diferentes dependendo do sistema que est operando (MULLINS, 2002). Arquivos de banco de dados Oracle contm os dados associados a um banco de dados particular. Adicionalmente, a Oracle utiliza memria especfica para estruturar e executar SGBD. O SGA um grupo de estrutura de memria alocada para instncias Oracle

que contm dados e informaes de controle. O SGA contm dados de cache, buffers de redo logs e memria para processamento de consultas SQL. O PGA uma rea de trabalho para usurio e processos. Cada processo tem seu prprio PGA. Os contedos do PGA podem variar dependendo do tipo de processo e configurao do banco Oracle (KOCK; KEVIN, 1997). Finalmente, vimos alguns processos da Oracle onde a maioria do trabalho de administrao de dados realizada. Cada processo est composto de umas sries de tarefas. Processos da Oracle so criados para executar o programa. Um processo da Oracle chamado por outro processo para executar funes especficas. Processos de servidor comunicam com processos de usurio que agem como um "revezamento" entre o processo de usurio e informao SGA. A seguir, algumas funcionalidades de cada processo de background da Oracle. O monitor de processo background (PMON) executa deveres de limpeza, quando um processo de usurio falhar com uma condio de erro. PMON limpa o cache, libera os locks (travas) e executa outras tarefas diversas. SMON tambm limpa segmentos temporrios que no so de longo uso, compensar espao vazios em extenses contguas, e em um ambiente de servidor paralelo, prov recuperao de exemplo para uma falha de CPU (MULLINS, 2002). O processo de escrita (DBWR) de banco de dados escreve os dados contidos em memria cache para arquivos contidos em disco fsicos. A escrita do log (LGWR) gerenciada pelo buffer de redo log. Se uma instncia Oracle possui mais pontos de checagem que o processo pode controlar, esses pontos de checagem podem sem invertidos para o processo de background controlar. O processo de archiver (ARCH) consome performance ao gerar cpias on-line de arquivos de log. O processo de background recover (RECO) automtico soluciona problema de falhas que envolvem transaes distribudas (LONEY; THERIAULT, 1999). Os processos de servidor analisam gramaticalmente e executam declaraes de SQL, executar todas as tarefas exigidas enviando os resultados para a aplicao que fez tal requisio. Esta avaliao de arquitetura da Oracle necessariamente um sumrio. Um DBA Oracle precisar entender tudo dos componentes anteriores, como eles interagem, e como eles podem ser afinados para aperfeioar o desempenho do sistema Oracle e aplicaes. Figura 6.1: Arquitetura Oracle.

www.sqlmagazine.com.br

6.1.1) Planos de Execuo no Oracle

No Oracle, a instruo Explain Plan utilizada para apresentar o plano de execuo de uma determinada consulta. Ela descreve cada passo do plano de execuo. Alm disso, mostra as tabelas e ndices que o banco usar ao processar determinada declarao, bem como a ordem na qual essas tabelas e esses ndices sero acessados, ou seja, a ordem dos eventos que o banco seguir para acessar os dados e processar as declaraes. Caso a declarao SQL tenha sido recentemente utilizada e no tenha sido modificada, seu plano de execuo ainda estar na em memria, podendo ser reutilizado, gerando um ganho de performance. Inicialmente, preciso criar uma tabela na qual o explain plan grava as informaes do plano em uma tabela do banco de dados. A listagem 6.1 mostra a sintaxe desta instruo (TEKNO, 1996). Listagem 6.1: A listagem ilustra como o banco de armazenas as informaes de um plano de execuo antes de mostrar ao usurio. O plano de execuo de uma tabela armazenado em uma tabela no banco de dados, para depois ser mostrado ao usurio.

Para visualizar o plano de execuo gerado, deve-se acessar a tabela plan_table, onde os planos explicados so armazenados, de acordo com a listagem 6.2. Listagem 6.2: De posse do plano de execuo gravado, a figura abaixo mostra como acessar as informaes desse plano de execuo.

Column query plan format a60 Select id Lpad( , 2*level)||operation || decode(id,0, cost = ||position) || ||options || || object_name as query plan from plan_table where statement_id = demo_01 connect by prior id = parent_id start with id = 0 / ID Query Plan - SELECT STATEMENT COST = TABLE ACESS BY INDEX ROWID CLASSES AND EQUAL INDEX RANGE SCAN STAT INDEX INDEX RANGE SCAN LOC_INDEX

O resultado do explain plan fica gravado em uma tabela do banco de dados, algumas dessas colunas so especiais e utilizadas com freqncia na interpretao da anlise da declarao (TEKNO, 1996). A tabela 1 mostra algumas das colunas especiais para essa interpretao. Tabela 1, colunas: Atributo: Nome das colunas referentes tabela contida no banco de dados; Significado: Explicao sobre as informaes contidas em cada coluna;

Atributo Significado STATEMENT_ID Identificador opcional

especificado

para o plano de execuo. OPERATION Nome da operao executada em determinado passo. OPTIONS Modo de acesso (por exemplo: by rowid, range scan, etc). OBJECT_NAME Nome do objeto. ID Nmero seqencial do passo dentro do plano de execuo. PARENT_ID Nmero do passo ao qual este o seguinte. POSITION Ordem na qual passos com o mesmo pai so processados. TIMESTAMP Data da execuo do plano. COST No CBO (otimizao baseada em custo) o custo estimado para a operao e somente serve para ser comparado com outros resultados. CARDINALITY Para CBO (otimizao baseada em custo) o nmero de registros estimados. Modo do otimizador. Pode ser RULE OPTIMIZER (regra) ou COST (custo) ou CHOOSE (escolha entre regra ou custo dependendo das estatsticas. OBJECT_OWNER Nome do schema (esquema) que contm a tabela ou ndice acessado. Outra forma de obter os planos de execuo explicados utilizando a clusula set sql autotrace on no SQL*PLUS. Essa clusula automaticamente explica o plano de execuo e o apresenta conforme for processada uma consulta SQL realizada.Os significados de cada um dos itens apresentados no plano de execuo so os citados na listagem 6.3: Listagem 6.3: Mostra uma outra forma de plano de execuo tambm usado no banco de dados Oracle.

SQL> set autotrace on SQL> select * from dual; Statistics 1 - 0 recursive calls 2 - 3 db block gets 3 - 1 consistent gets 4 - 0 physical reads 5 - 0 redo size 6 - 565 bytes sent via sql*net to cliente 7 - 646 bytes received via SQK*NET from client 8 - 4 SQL*NET roundtrips to/from client 9 - 1 sorts (memory) 10 - 0 sorts (disk) 11 - 1 rows processed

1 Nmero de comandos recursivos; 2 Nmero de blocos lidos no banco; 3 Leituras consistentes, dados que no esto atualizados no disco, esto apenas em cache; 4 Leituras fsicas em disco; 6,7,8 Dados referentes rede. (Esse exemplo foi implementado em ambiente cliente / servidor); 11 Nmero de linhas processadas.

6.2 Etapas do Estudo de Caso:

6.2.1 Estrutura Foram selecionadas algumas consultas tpicas desse sistema para uma melhor anlise, a lista de consultas que foi projetada com intuito de ser comparada para melhor explicar algumas tcnicas que utilizadas de forma correta podem melhor o desempenho das mesmas. A tabela 2 mostra quantas linhas cada consulta utilizada nessa pesquisa retorna. Tabela 2, colunas: Ordem: a ordem cujas consultas so apresentadas nessa pesquisa; Consulta: Explicao resumida sobre o objetivo de cada consulta; Retorno (linhas): Quantas linhas a determinada consulta retorna;

Ordem 1 2 3 4 5

Consulta Retorna a quantidade de Ordens de Produo lanadas por cada ponto de controle da indstria. Retorna a configurao e programao de um equipamento industrial. Retorna cada ordem de produo de um determinado plano de produo. Deveria retornar os produtos de apenas duas categorias. Retorna os produtos de apenas duas categorias.

Retorno (linhas) 6 1 102 110.522 33

Inicialmente o banco de dados foi carregado com uma quantidade razovel de dados (quantidade baseada na quantidade original, porm com garantia certa de aumento de dados em pouco tempo). A tabela 3 mostra a quantidade de registros inicial de cada tabela: Tabela 3, colunas: Tabela: Nome da tabela; Quantidade: Quantidade de registros existentes na tabela; Tabela PCP_PRODUTOS PCP_CATEGORIAS EPI_PLA_PLA_ROT EPI_ENG_ESTRURA_CAT EPI_ENG_ESTR_MOD EPI_ROTEIRO EPI_ESTAGIO EPI_MATRIZ_LATERAL EPI_DISTRIBUICAO OE_PRODUCAO PCP_TAMANHO EPI_BAIXA EPI_ESTACAO EPI_MATRIZ EPI_LATERAL EPI_MATRIZ_MAQUINA EPI_MAQUINA EPI_TURNO Quantidade 110.068 4.359 10 11.083 291 5 5 98 65.423 9.999.825 60 88.562 72 100 100 180 120 4

Figura 6.3: Diagrama de entidade e relacionamento (DER) das tabelas relacionadas acima. A figura 6.3 mostra o relacionamento entre as tabelas utilizadas como exemplo nessa pesquisa.

OE_PRODUCAO
@#Seq_oe @#cod_unp @# c od_d ivisa o @# c od_se c ao
Pcp_tamanho
@Cod_tamanho PCP_PRODUTOS

PCP_CAT EGORIAS

EPI_ENG_ESTRURA_CAT

@Cod_produto # c od_categoria #cod_tamanho

@Cod_categoria

@COD_ESTRUTURA @#COD_CATEGORIA

EPI_TURNO
@Cod_turno
EPI_PLA_PLA_ROT @Cod_plano @# cod_produto @#cod_roteiro

EPI_ROT EIRO
@Cod _roteiro #cod_estagio

EPI_ENG_ESTR_MOD
@#Cod_estrutura @# c od_c ategoria @#cod_componente

EPI_DIST RIBUICAO

EPI_ESTAGIO
@Cod_estagio

EPI_ESTACAO
EPI_MATRIZ

@# Cod _p lano @# c o d_produto @# c o d_produto @# c o d_esta gio @# c o d_unp

EPI_MAT RIZ_MAQUINA
@# Cod_unp @# cod_m a quina

EPI_MAQUINA
@Cod_maquina

EPI_LATERAL

EPI_MAT RIZ_LAT ERAL

Inicialmente, foram criadas apenas a chave primria e as chaves estrangeiras de cada tabela. A seguir sero mostrados os resultados (comparaes) de cada uma das consultas (vale ressaltar que esses exemplos so prticos): 6.1.2.2 Comparaes entre as consultas (testes) Listagem 6.4: As consultas abaixo mostram a eficincia e melhoria de uma consulta com a criao de um ndice.

select a.seq_ficha, a.cod_divisao, a.cod_secao, to_char(a.dat_baixa,'dd/mm/yyyy hh24:mi:ss') data from epi_baixa a where a.cod_empresa = 51 and a.cod_filial = 10 and a.cod_up = 1 and a.dat_baixa >= (select to_date(to_char('27-jul2006')||to_char(b.hor_inicial_dia,'hh24:mi:ss'), 'dd/mm/yyyy hh24:mi:ss ') from epi_turno b

where b.seq_turno = 1) and a.dat_baixa <= (select to_date(to_char('29-jul2006')||to_char(b.HOR_FINAL_VIRADA,'hh24:mi:ss'), 'dd/mm/yyyy hh24:mi:ss ') from epi_turno b where b.seq_turno = 1) order by a.dat_baixa;
Total de 6 linhas selecionadas. O plano de execuo e as estatsticas iniciais esto relacionados conforme tabelas abaixo: Plano de Execuo: Ordem Modo de Acesso acesso 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=10 Card=18 Bytes=252 ) 1 SORT (ORDER BY) (Cost=10 Card=18 Bytes=252) 2 TABLE ACCESS (BY INDEX ROWID) OF 'EPI_BAIXA ' (Cost=2 Card=18 Bytes=252) 3 INDEX (RANGE SCAN) OF 'IX_EPIPECLABAIUPSEC_EPIUNPS' (NON-UNIQUE) (Cost=58 Card=7210) 4 TABLE ACCESS (BY INDEX ROWID) OF 'EPI_TURNO' (Cost=1 Card=1 Bytes=22) 5 INDEX (UNIQUE SCAN) OF 'PK_EPIPLATUR' (UNIQUE) (Cost=1 Card=1) 6 TABLE ACCESS (BY INDEX ROWID) OF 'EPI_TURNO' (Cost=1 Card=1 Bytes=22) 7 INDEX (UNIQUE SCAN) OF 'PK_EPIPLATUR' (UNIQUE) (Cost=1 Card=1) Plano e estatstico: Volume (processado) 0 0 1119 0 0 695 417 2 Recurso recursive calls db block gets consistent gets physical reads Redo size bytes sent via SQL*Net to client bytes received via SQL*Net from client SQL*Net roundtrips to/from client

1 0 6

sorts (memory) sorts (disk) rows processed

Na seqncia foi criado apenas um ndice conforme descrito abaixo: Nome IX_EPIPECLABAIUPSEC_DATA Tabela EPI_BAIXA Coluna DAT_BAIXA Tipo Nonunique

As tabelas abaixo mostram o plano de execuo e as estatsticas dessa mesma consulta aps a criao do ndice: Plano de Execuo: Ordem Modo de acesso acesso 1 SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=18 Bytes=252) 2 TABLE ACCESS (BY INDEX ROWID) OF 'EPI_BAIXA' (Cost=1 Card=18 Bytes=252) 3 INDEX (RANGE SCAN) OF 'IX_EPIPECLABAIUPSEC_DATA' (NON-UNIQUE) (Cost=2 Card=65) 4 TABLE ACCESS (BY INDEX ROWID) OF 'EPI_TURNO' (Cost=1 Card=1 Bytes=22) 5 INDEX (UNIQUE SCAN) OF 'PK_EPIPLATUR' (UNIQUE) (Cost=1 Card=1) 6 TABLE ACCESS (BY INDEX ROWID) OF 'EPI_TURNO' (Cost =1 Card=1 bytes=22) 7 INDEX (UNIQUE SCAN) OF 'PK_EPIPLATUR' (UNIQUE) (Cost =1 Card=1) Plano estatstico: Volume (processado) 0 0 8 0 0 695 417 2 0 0 6 Recurso recursive calls db block gets consistent gets physical reads redo size bytes sent via SQL*Net to client bytes received via SQL*Net from client SQL*Net roundtrips to/from client sorts (memory) sorts (disk) rows processed

Comparando as estatsticas desses dois planos de execuo, chegamos a concluso que a criao do ndice foi muito proveitosa, afinal houve uma melhoria considervel nos quesitos consistent gets e sorts (memory). Outro fator que merece destaque, que os planos de execuo esto diferentes, obviamente o segundo plano de execuo mostra o uso do ndice (no contido no primeiro plano). Na seqncia, a prxima consulta foi escrita visando mudana da ordem das tabelas na clusula FROM, Essa mudana tambm traz ganho em performance, conforme apresentando na listagem 6.5. Listagem 6.5: Mostra que uma alterao na clusula FROM pode melhorar a performance da consulta.

select i.cod_up up, o.cod_maquina, d.seq_estrutura estrutura, j.num_palma tamanho, nvl(h.qtd_lateral,0), nvl(sum(a.QTD_PRODUCAO),0) qtd_pares, o.nro_prioridade, l.cod_matriz, m.cod_lateral, a.cod_roteiro, d.COD_GRUPO_COMPONENTE, p.qtd_horas_dia from EPI_PLA_PLA_ROT a, pcp_produtos b, pcp_categorias c, EPI_ENG_ESTRURA_CAT d, EPI_ENG_ESTR_MOD q, epi_roteiro e, epi_estagio f, EPI_ENG_ESTR_MOD g, epi_matriz_lateral h, epi_distribuicao i, pcp_tamanho j, epi_matriz l, epi_lateral m, epi_matriz_maquina n, epi_estacao o, epi_maquina p where a.seq_plano = 1485110 and b.cod_produto = a.cod_produto_producao and c.cod_reduzido = b.cod_reduzido and d.cod_reduzido = b.cod_reduzido and q.seq_estrutura = d.seq_estrutura and q.cod_grupo_componente = d.cod_grupo_componente and q.flg_matrizaria = 'S' and e.cod_roteiro = a.cod_roteiro and f.cod_estagio = e.cod_estagio_final

and f.flg_matrizaria = 'S' --- estagio que verifica matrizaria and g.seq_estrutura = d.seq_estrutura and g.flg_matrizaria = 'S' --- estrutura que olha matrizaria and h.seq_estrutura = g.seq_estrutura and i.cod_empresa = 51 and i.cod_filial = 10 and i.seq_plano = a.seq_plano and i.cod_roteiro = e.cod_roteiro and i.cod_produto = a.cod_produto_producao and i.num_pedido = a.num_pedido and j.num_tamanho = b.num_tamanho and j.tip_tamanho = c.cod_negocio and l.cod_matriz = h.cod_matriz and l.num_tamanho = j.num_palma and upper(l.flg_ativo) = 'S' -- matriz ativa and m.cod_lateral = h.cod_lateral and m.num_tamanho = j.num_palma and upper(m.flg_ativo) = 'S' --- lateral ativa and n.cod_empresa = i.cod_empresa and n.cod_filial = i.cod_filial and n.cod_up = i.cod_up and o.cod_empresa = n.cod_empresa and o.cod_filial = n.cod_filial and o.cod_up = i.cod_up and o.cod_maquina = n.cod_maquina and to_number(o.cod_matriz) = to_number(h.cod_matriz) and to_number(o.cod_lateral) = to_number(h.cod_lateral) and to_number(o.cod_grupo_componente) = to_number(g.cod_grupo_componente) and to_number(o.seq_estrutura) = to_number(g.seq_estrutura) and p.cod_maquina = o.cod_maquina group by i.cod_up, o.cod_maquina, d.seq_estrutura, j.num_palma, nvl(h.qtd_lateral,0), o.nro_prioridade, l.cod_matriz, m.cod_lateral, a.cod_roteiro, d.COD_GRUPO_COMPONENTE, p.qtd_horas_dia order by nvl(sum(a.QTD_PRODUCAO),0) desc;
Total de 1 linha selecionada. O plano de execuo e as estatsticas iniciais dessa consulta seguem conforme abaixo:

Plano de Execuo: Ordem Modo de acesso acesso 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=31 Card=1 Bytes=158) 1 SORT (ORDER BY) (Cost=31 Card=1 Bytes=158) 2 SORT (GROUP BY) (Cost=31 Card=1 Bytes=158) 3 NESTED LOOPS (Cost=16 Card=1 Bytes=158) 4 NESTED LOOPS (Cost=15 Card=1 Bytes=153) 5 NESTED LOOPS (Cost=14 Card=1 Bytes=148) 6 NESTED LOOPS (Cost=13 Card=1 Bytes=140) 7 NESTED LOOPS (Cost=12 Card=1 Bytes=134) 8 NESTED LOOPS (Cost=11 Card=1 Bytes=128) 9 NESTED LOOPS (Cost=10 Card=1 Bytes=118) 10 NESTED LOOPS (Cost=9 Card=1 Bytes=110) 11 NESTED LOOPS (Cost=8 Card=1 Bytes=102) 12 NESTED LOOPS (Cost=7 Card=1 Bytes=90) 13 NESTED LOOPS (Cost=6 Card=54 Bytes =3942) 14 NESTED LOOPS (Cost=5 Card=61 Bytes=4270) 15 NESTED LOOPS (Cost=4 Card=61 Bytes=4026) 16 NESTED LOOPS (Cost=3 Card=22Bytes=990) 17 NESTED LOOPS (Cost=2 Card=22 Bytes=770) 18 TABLE ACCESS (BY INDEX ROWID) OF 'EPI_ESTACAO' (Cost=1 Card=22 Bytes=638) 19 INDEX (RANGE SCAN) OF 'IX_EPIMATMAQMAT_EPIMATUPMAQ' (NON-UNIQUE) (Cost=1 Card=22) 20 TABLE ACCESS (BY INDEX ROWID) OF 'EPI_MAQUINA' (Cost=1 Card=1 Bytes=6) 21 INDEX (UNIQUE SCAN) OF 'PK_EPIUNPMAQ' (UNIQUE) 22 TABLE ACCESS (BY INDEX ROWID) OF 'EPI_MATRIZ_MAQUINA' (Cost=1 Card=1 Bytes=10) 23 INDEX (RANGE SCAN) OF 'IX_EPIMATUPMAQ_EPIUNPUP' (NON-UNIQUE) (Cost=1 Card=1) 24 INDEX (RANGE SCAN) OF 'PK_UNP_DISTRIBUICAO' (UNIQUE) (Cost=1 Card=3 Bytes=63) 25 TABLE ACCESS (BY INDEX ROWID) OF 'EPI_ROTEIRO' (Cost=1 Card=1 Bytes=4) 26 INDEX (UNIQUE SCAN) OF 'PK_EPIENGROT' (UNIQUE) 27 TABLE ACCESS (BY INDEX ROWID) OF 'EPI_ESTAGIO' (Cost=1 Card=1 Bytes=3) 28 INDEX (UNIQUE SCAN) OF 'PK_EPIENGESTAGIO' (UNIQUE) 29 TABLE ACCESS (BY INDEX ROWID) OF ' EPI_PLA_PLA_ROT'

30 31 32 33 34 35 36 37 38

39 40 41 42 43 44 45 46 47 48

(Cost=1 Card=1 Bytes=17) INDEX (RANGE SCAN) OF 'IX_EPIPLAPLAROT_EPIENGROT' (NON-UNIQUE) TABLE ACCESS (BY INDEX ROWID) OF 'PCP_PRODUTOS' (Cost=1 Card=1 Bytes=12 INDEX (UNIQUE SCAN) OF 'PK_PCPPROCAL' (UNIQUE) TABLE ACCESS (BY INDEX ROWID) OF 'PCP_CATEGORIAS' (Cost=1 Card=1 Bytes=8) INDEX (UNIQUE SCAN) OF 'PK_PCPPROSEGUR' (UNIQUE) TABLE ACCESS (BY INDEX ROWID) OF 'PCP_TAMANHO' (Cost=1 Card=1 Bytes=8 INDEX (UNIQUE SCAN) OF 'PK_PCP_TAMANHO' (UNIQUE) TABLE ACCESS (BY INDEX ROWID) OF 'EPI_ENG_ESTRURA_CAT' (Cost=1 Card=1 Bytes=10) INDEX (RANGE SCAN) OF 'IX_EPIENGESTRED_EPIENGESTMOD' (NON-UNIQUE) (Cost=1 Card=3) TABLE ACCESS (BY INDEX ROWID) OF 'EPI_ENG_ESTR_MOD' (Cost=1 Card=1 Bytes=6) INDEX (UNIQUE SCAN) OF 'PK_EPIENGESTMOD' (UNIQUE) TABLE ACCESS (BY INDEX ROWID) OF 'EPI_ENG_ESTR_MOD' (Cost=1 Card=1 Bytes=6) INDEX (RANGE SCAN) OF 'IX_PI_ENG_ESTRUTURA_MODELO_02' (NON-UNIQUE) TABLE ACCESS (BY INDEX ROWID) OF 'EPI_MATRIZ_LATERAL' (Cost=1 Card=1 Bytes=8) INDEX (RANGE SCAN) OF 'IX_SEQ_ESTRUTURA_EPIMATMATLAT' (NON-UNIQUE) TABLE ACCESS (BY INDEX ROWID) OF 'EPI_LATERAL'(Cost=1 Card=1 Bytes=5) INDEX (UNIQUE SCAN) OF 'PK_EPIMATLAT' (UNIQUE) TABLE ACCESS (BY INDEX ROWID) OF 'EPI_MATRIZ' (Cost=1 Card=1 Bytes=5) INDEX (UNIQUE SCAN) OF 'PK_EPIMATMAT' (UNIQUE)

Plano estatstico: Volume (processado) 0 0 480 0 0 908 1707 Recurso recursive calls Db block gets consistent gets physical reads Redo size bytes sent via SQL*Net to client bytes received via SQL*Net from client

2 2 0 1

SQL*Net roundtrips to/from client sorts (memory) sorts (disk) rows processed

Alterando a ordem das tabelas na clusula FROM, houve um ganho de performance.A alterao da ordem das tabelas segue conforme comparativo abaixo: Primeira Ordem das tabelas (FROM) (forma original) Segunda Ordem das tabelas (FROM) (forma alterada para ganho performance) epi_roteiro epi_maquina epi_estao epi_estagio epi_matriz epi_lateral pcp_tamanho epi_matriz_lateral EPI_PLA_PLA_ROT epi_matriz_maquina pcp_categorias EPI_ENG_ESTRURA_CAT EPI_ENG_ESTR_MOD EPI_ENG_ESTR_MOD pcp_produtos epi_distribuio

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

EPI_PLA_PLA_ROT pcp_produtos pcp_categorias EPI_ENG_ESTRURA_CAT EPI_ENG_ESTR_MOD epi_roteiro epi_estagio EPI_ENG_ESTR_MOD epi_matriz_lateral epi_distribuio pcp_tamanho epi_matriz epi_lateral epi_matriz_maquina epi_estao epi_maquina

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Aps a mesma consulta ser escrita novamente com a segunda ordem das tabelas, a mesma apresentou o seguinte plano de execuo: Plano de execuo: Ordem Modo de acesso Acesso 0 SELECT STATEMENT Optimizer=CHOOSE Bytes=158) 1 SORT (ORDER BY) (Cost=31 Card=1 Bytes=158) 2 SORT (GROUP BY) (Cost=31 Card=1 Bytes=158) 3 NESTED LOOPS (Cost=16 Card=1 Bytes=158) 4 NESTED LOOPS (Cost=15 Card=1 Bytes=153) 5 NESTED LOOPS (Cost=14 Card=1 Bytes=148) 6 NESTED LOOPS (Cost=13 Card=1 Bytes=142) 7 NESTED LOOPS (Cost=12 Card=1 Bytes=113)

(Cost=31

Card=1

8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 25 26 27 28 29 30 31 32 33 34 35 36 37 38

NESTED LOOPS (Cost=11 Card=1 Bytes=110) NESTED LOOPS (Cost=10 Card=1 Bytes=102) NESTED LOOPS (Cost=9 Card=1 Bytes=96) NESTED LOOPS (Cost=8 Card=1 Bytes=90) NESTED LOOPS (Cost=7 Card=1 Bytes=82) NESTED LOOPS (Cost=6 Card=1 Bytes= 74) NESTED LOOPS (Cost=5 Card=1 Bytes=64) NESTED LOOPS (Cost=4 Card=1 Bytes=52) NESTED LOOPS (Cost=3 Card=1Bytes=48) NESTED LOOPS (Cost=2 Card=1 Bytes=38) INDEX (RANGE SCAN) OF 'PK_UNP_DISTRIBUICAO' (UNIQUE) (Cost=1 Card=11 Bytes=231) TABLE ACCESS (BY INDEX ROWID) OF 'EPI_PLA_PLA_ROT' (Cost=1 Card=1 Bytes=17) INDEX (RANGE SCAN) OF 'IX_EPIPLAPLAROT_EPIPLAPEDGRA' (NON-UNIQUE) (Cost=1 Card=1) TABLE ACCESS (BY INDEX ROWID) OF 'EPI_MATRIZ_MAQUINA' (Cost=1 Card=1 Bytes=10) INDEX (RANGE SCAN) OF 'IX_EPIMATUPMAQ_EPIUNPUP' (NONUNIQUE) TABLE ACCESS (BY INDEX ROWID) OF 'EPI_ROTEIRO' (Cost=1 Card=1 Bytes=4) TABLE ACCESS (BY INDEX ROWID) OF 'PCP_PRODUTOS' (Cost=1 Card=1 Bytes=12) INDEX (UNIQUE SCAN) OF 'PK_PCPPROCAL' (UNIQUE) TABLE ACCESS (BY INDEX ROWID) OF 'EPI_ENG_ESTRURA_CAT' (Cost=1 Card=1 Bytes=10) INDEX (RANGE SCAN) OF 'IX_EPIENGESTRED_EPIENGESTMOD' (NON-UNIQUE) (Cost=1 Card=3) TABLE ACCESS (BY INDEX ROWID) OF ' PCP_CATEGORIAS' (Cost=1 Card=1 Bytes=8) INDEX (UNIQUE SCAN) OF 'PK_PCPPROSEGUR' (UNIQUE) TABLE ACCESS (BY INDEX ROWID) OF 'PCP_TAMANHO' (Cost=1 Card=1 Bytes=8) INDEX (UNIQUE SCAN) OF 'PK_PCP_TAMANHO' (UNIQUE) TABLE ACCESS (BY INDEX ROWID) OF 'EPI_ENG_ESTR_MOD' (Cost=1 Card=1 Bytes=6) INDEX (UNIQUE SCAN) OF 'PK_EPIENGESTMOD' (UNIQUE) TABLE ACCESS (BY INDEX ROWID) OF 'EPI_ENG_ESTR_MOD' (Cost=1 Card=1 Bytes=6) INDEX (RANGE SCAN) OF 'IX_PI_ENG_ESTRUTURA_MODELO_02' (NON-UNIQUE) TABLE ACCESS (BY INDEX ROWID) OF 'EPI_MATRIZ_LATERAL' (Cost=1 Card=1 Bytes=8) INDEX (RANGE SCAN) OF 'IX_SEQ_ESTRUTURA_EPIMATMATLAT' (NON-UNIQUE)

40 41 42 43 44 45 46 47 48

INDEX (UNIQUE SCAN) OF 'PK_EPIENGESTAGIO'(UNIQUE) TABLE ACCESS (BY INDEX ROWID) OF 'EPI_ESTACAO' (Cost=1 Card=1 Bytes=29 INDEX (RANGE SCAN) OF 'IX_EPIMATMAQMAT_EPIMATUPMAQ' (NON-UNIQUE) TABLE ACCESS (BY INDEX ROWID) OF 'EPI_MAQUINA' (Cost=1 Card=1 Bytes=6) INDEX (UNIQUE SCAN) OF 'PK_EPIUNPMAQ' (UNIQUE) TABLE ACCESS (BY INDEX ROWID) OF 'EPI_LATERAL'(Cost=1 Card=1 Bytes=5) INDEX (UNIQUE SCAN) OF 'PK_EPIMATLAT' (UNIQUE) TABLE ACCESS (BY INDEX ROWID) OF 'EPI_MATRIZ' (Cost=1 Card=1 Bytes=5) INDEX (UNIQUE SCAN) OF 'PK_EPIMATMAT' (UNIQUE)

Estatsticas: Volume (processado) 0 0 104 0 0 908 1735 2 2 0 1 Recurso recursive calls db block gets Consistent gets physical reads Redo size bytes sent via SQL*Net to client bytes received via SQL*Net from client SQL*Net roundtrips to/from client sorts (memory) sorts (disk) rows processed

Analisando esses dois planos de execuo, podemos verificar variao em dois quesitos. O segundo plano de execuo possui o quesito consistent gets melhor (menor) que o primeiro plano de execuo. Por outro lado, o primeiro plano de execuo possui o quesito bytes received via SQL*Net from client considerado melhor que o do segundo plano de execuo. Mediante a essa peculiaridade de cada plano de execuo, baseado na arquitetura da Oracle o segundo plano seria o melhor a ser utilizado, mesmo possuindo um quesito considerado pior que o do primeiro plano de execuo. Listagem 6.5: Seguindo o raciocnio, o prximo exemplo mostra como desnormalizar tabelas s vezes pode ser vantajoso, o ganho de performance pode compensar. Duas consultas foram projetadas para mostrar essa tcnica. A primeira mostra a consulta de forma normalizada:

select distinct(a.nro_ficha), a.qtd_pares from oe_producao a, pcp_produtos b where a.cod_empresa = 51 and a.cod_filial = 10 and a.nro_plano = '396/FBI-06' and b.cod_produto = a.cod_produto and b.cod_processo = 45;
Total de 102 linhas selecionadas. Essa consulta possui o seguinte plano de execuo: Ordem Modo de acesso acesso 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=209 Card=1150 1 2 3 4 5 Bytes= 36800) SORT (UNIQUE) (Cost=209 Card=1150 Bytes=36800) HASH JOIN (Cost=184 Card=1150 Bytes=36800) TABLE ACCESS (BY INDEX ROWID) OF 'OE_PRODUCAO' (Cost=160 Card=1150 Bytes=28750) INDEX (SKIP SCAN) OF 'IX_OE_PRODUCAO_04' (NON-UNIQUE) (Cost=133 Card=2300) 2 INDEX (FAST FULL SCAN) OF 'IX_PCP_PROD_PROC' (NONUNIQUE) (Cost=20 Card=6141 Bytes=42987) Plano estatstico: Volume (processado) 0 0 425 364 0 2618 1084 8 1 0 102 Recurso recursive calls db block gets consistent gets physical reads redo size bytes sent via SQL*Net to client bytes received via SQL*Net from client SQL*Net roundtrips to/from client sorts (memory) sorts (disk) rows processed

Desnormalizando a tabela conforme exemplo abaixo (consulta abaixo), a tabela PCP_PRODUTOS acaba no sendo necessria, porm uma redundncia (de dados) acaba sendo gerada na tabela OE_PRODUO.

Como a tabela OE_PRODUCAO considerada muito grande (em relao a dados), essa tcnica acaba sendo vlida e til, mesmo que conceitualmente no seja a melhor forma de agir. Utilizando tal tcnica, a consulta seria escrita dessa maneira:

select distinct(a.nro_ficha), a.qtd_pares from oe_producao a where a.cod_empresa = 51 and a.cod_filial = 10 and a.nro_plano = '396/FBI-06' and a.cod_processo = 45
Total de 102 linhas selecionadas. Teria o seguinte plano de execuo: Ordem acesso 0 1 2 3 Modo de acesso SELECT STATEMENT Optimizer=CHOOSE (Cost=26 Card=115 Bytes=2760) SORT (UNIQUE) (Cost=26 Card=115 Bytes=2760) TABLE ACCESS (BY INDEX ROWID) OF 'OE_PRODUCAO' (Cost=7 Card=115 Bytes=2760) INDEX (RANGE SCAN) OF 'IX_OE_PRODUCAO_02' (NON-UNIQUE) (Cost=5 Card=115)

Plano estatstico: Volume (processado) 0 0 119 0 0 2618 1084 8 1 0 102 Recurso recursive calls db block gets consistent gets physical reads redo size bytes sent via SQL*Net to client bytes received via SQL*Net from client SQL*Net roundtrips to/from client sorts (memory) sorts (disk) rows processed

Se forem comparados, o plano de execuo da primeira consulta est maior que o da segunda, eventualmente porque a primeira consulta possui uma tabela a mais que a segunda consulta. Como a consulta do segundo plano de execuo roda sobre uma

nica tabela, obviamente a mesma mais rpida e possui um plano de execuo menor. Alm do mais, o quesito consistent gets do segundo plano estatstico est menor que o do primeiro plano, o que significa estar melhor que o do primeiro plano. Para efeitos de testes, foram selecionadas (conforme abaixo) algumas consultas com comandos que agridem diretamente a performance do banco de dados. Essas consultas no foram trabalhadas com intuito de serem modificadas com alguma tcnica que melhora sua performance, sua idia mostrar como alguns comandos podem prejudicar a performance do banco de dados. Listagem 6.6: O comando OR no aconselhvel para ser utilizado em junes, pois geralmente seu uso pode gerar algumas estatsticas consideradas altas prejudicando a performance do banco de dados.

select a.cod_reduzido, b.cod_produto from pcp_categorias a, pcp_produtos b where a.cod_reduzido = 40760091 or 33010001 and b.cod_reduzido = a.cod_reduzido
Total de 110522 linhas selecionadas.

a.cod_reduzido

Essa consulta possui planos de execuo e planos estatsticos considerados perigosos: Plano de execuo: Ordem Modo de acesso Acesso 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=8 Card=108508 Bytes= 1736128) 1 CONCATENATION 2 NESTED LOOPS (Cost=6 Card=108504 Bytes=1736064) 3 INDEX (UNIQUE SCAN) OF 'PK_PCPPROSEGUR' (UNIQUE) (Cost=1 Card=1 Bytes=6) 4 TABLE ACCESS (BY INDEX ROWID) OF 'PCP_PRODUTOS' (Cost=5 Card=108504 Bytes=1085040) 5 INDEX (RANGE SCAN) OF 'IX_PCP_PROD_CALCADOS_REDUZIDO ' (NON-UNIQUE) (Cost=401 Card=108504) 6 NESTED LOOPS (Cost=6 Card=108504 Bytes=1736064) 7 INDEX (UNIQUE SCAN) OF 'PK_PCPPROSEGUR' (UNIQUE) (Cost=1 Card=1 Bytes=6) 8 INDEX (FULL SCAN) OF 'IX_PCP_PROD_PROC_REDUZ' (NON-

UNIQUE) (Cost=401 Card=108504 Bytes=1085040) Plano estatstico: Volume (processado) 0 0 7788 284 1088 2821159 818265 7370 0 0 110552 Recurso recursive calls db block gets consistent gets physical reads redo size bytes sent via SQL*Net to client bytes received via SQL*Net from client SQL*Net roundtrips to/from client sorts (memory) sorts (disk) rows processed

Listagem 6.7: Uma forma de substituir essa consulta para uma que agrida menos o banco de dados seria substituir o comando OR pelo comando IN. Abaixo segue essa mesma consulta escrita com uso do comando IN:

select a.cod_reduzido, b.cod_produto from pcp_categorias a, pcp_produtos b where a.cod_reduzido in (40760091,33010001) and b.cod_reduzido = a.cod_reduzido
Total de 33 linhas selecionadas. Essa consulta mostra planos de execuo e estatstico (conforme abaixo) muito melhores que os planos mostrados acima. Como ela est mais bem escrita, seu volume de dados menor e preciso, portanto seu desempenho acaba sendo mais rpido e confivel. Plano de execuo: Ordem Acesso 0 1 2 3 4 Modo de acesso SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=2 Bytes=32) TABLE ACCESS (BY INDEX ROWID) OF 'PCP_PRODUTOS' (Cost=1 Card=1 Bytes=10) NESTED LOOPS (Cost=2 Card=2 Bytes=32) INLIST ITERATOR INDEX (RANGE SCAN) OF 'PK_PCPPROSEGUR' (UNIQUE)

(Cost=2 Card=2 Bytes=12) INDEX (RANGE SCAN) OF 'IX_PCP_PROD_CALCADOS_REDUZIDO'(NON-UNIQUE) (Cost=1 Card=1)

Plano estatstico: Volume (processado) 0 0 20 0 0 1142 693 4 0 0 33 Recurso recursive calls db block gets consistent gets physical reads redo size bytes sent via SQL*Net to client bytes received via SQL*Net from client SQL*Net roundtrips to/from client sorts (memory) sorts (disk) rows processed

7) Concluso
Performance tem se tornado um fator de grande importncia para profissionais da rea de TI. Um banco de dados que sofre com problemas de performance pode trazer inmeros problemas, e s vezes grandes prejuzos a empresa que depende das suas informaes. Essa pesquisa procurou mostrar a importncia do gerenciamento de performance e do planejamento na hora de desenvolver aplicaes, entre outros fatores que contribuem diretamente para que sejam cada vez menores os problemas com relao performance em um banco de dados. Algumas tcnicas e conceitos foram mostrados, com intuito de se obter o melhor desempenho possvel. Para chegar o mais prximo desse objetivo, foi feita uma pesquisa bibliogrfica com o objetivo de encontrar as melhores tcnicas e conceitos a serem demonstrados nessa pesquisa. Alguns testes foram implementados em uma base de dados, utilizando o banco de dados Oracle 9i, para ser demonstrado algumas comparaes e melhorias em consultas. Acredita-se que essa pesquisa ser de grande valor para quem se depara com problemas de performance tanto na administrao do banco de dados quanto no desenvolvimento de aplicaes. Apesar do bom resultado apresentado, esse tema ainda pode ser aproveitando em estudos futuros podendo ser ainda mais explorado. Ao final, conclui-se que performance algo nada fcil de se administrar e por sua vez um tpico fundamental para toda empresa que depende das informaes contidas em seu banco de dados.

8) Referncias bibliogrficas
BOSCATTO, R; DAMINELLO, M.R; Instituto municipal ensino superior de So Caetano do Sul, 1999; CARATTI, R; Atividades de um DBA e questes sobre performance. SQL Magazine 5, 2004; FANDERUFF, D; Dominando o Oracle 9i modelagem e desenvolvimento, 2003; JARKE, M; KOCH, J; Query optimization in database system, ACM computing servers, 1984; KOCK, G; KEVIN, L; Oracle 8: The complete reference Oracle Press, 1997; LONEY, K; THERIAULT, M; Oracle 8i DBA handbook, 1999; MULLINS, C. S; Database administration: the complete guide to practices and procedures, 2002; Patterson, D. A; Gibson, G; Katz, R.H; A case for redundant arrays of inexpensive disks (RAID), 1988; SILBERCHATZ, A; KORTH, H.F; SUDARSHAN, S; Sistema de banco de dados, 3 edio, 1999; TEKNO SOFTWARE; Manual de tunning Oracle 8i, 1996; WEININGER, A; Efficient execution of joins in a star schema, 2002; YANG, Y; SINGHAL, M; A comprehensive survey of join techniques in relational database, 1997;

This document was created with Win2PDF available at http://www.daneprairie.com. The unregistered version of Win2PDF is for evaluation or non-commercial use only.