tuning de banco de dados

Procedimentos doadministrador, focando o

desempenho dosgerenciadores de banco

de dados (SGBD)Resumir os principais procedimentos de um profissional de Administrao deBanco de Dados (DBA), visando manter um bom desempenho do gerenciador

de dados e, desta maneira, preservar os processos de uma organizao.

Introduo

Cada vez mais as organizaes dependem de sua Tecnologia de Informao para o andamentodos seus processos. Desta maneira, o desempenho da infraestrutura de TI, particularmente dosgerenciadores de banco de dados, se torna crucial neste cenrio.

Os profissionais de administrao de banco de dados devem definir uma srie de processospara garantir este desempenho. Segue a diante um resumo destes procedimentos que devem serdefinidos para que os gerenciadores de banco de dados possam ter um desempenho satisfatrio e,desta maneira, preservar os processos das organizaes.

Avaliao da infraestrutura

A avaliao da infraestrutura de TI, incluindo servidores, redes, desktops etc, so de extremaimportncia para o bom desempenho do ambiente computacional.

Particularmente, para os gerenciadores de banco de dados so necessrios servidores comcapacidade de processamento, memria e operaes de entrada e sada compatveis.

Os processos de avaliao da infraestrutura devero ser contnuos, visto que a necessidade dehardware e software costuma ser crescentes ao longo do tempo.

De nada adianta fazer um bom trabalho de monitoramento do desempenho nos gerenciadores

de banco de dados e a infraestrutura no atender a demanda que os SGBD necessitam para um bomtrabalho.

Implementar ferramentasde suporte para avaliao

A avaliao do desempenho de um Sistema Gerenciador de Banco de Dados (SGBD) nopoder ser um processo pontual. Ela dever ser feita ao longo do tempo, acompanhando asmudanas de desempenho, registrando-as por meio de relatrios estatsticos, grficos etc. Esteprocedimento se torna invivel caso seja feita de forma manual.

As ferramentas de avaliao e monitoramento tm condies no somente de automatizaralguns desses processos e facilitar a vida do DBA, mas tambm de registrar o resultado dessasavaliaes podendo ser consultadas posteriormente para anlise e tomada de decises.

Manter bem definidos os objetos fsicose lgicos

Os SGBD tm como caracterstica a distribuio lgica de seus objetos dentro de tablespaces....

... Como forma de melhorar o seu desempenho, podemos distribuir esses objetos como tabelas,ndices, views etc em tablespaces diferentes e, desta maneira, proporcionando leituras maiseficientes nos servidores a fim de evitar a sobrecarga de leitura e gravao em uma nicatablespace, por exemplo.

Manter uma boa sintoniacom as atividades do desenvolvedorde aplicativos

A maioria dos problemas de desempenho ligados aos bancos de dados oriunda das aplicaesque o utilizam. Sendo assim, o analista e o programador devero ter conhecimentos dos processosque podem melhorar ou piorar o seu desempenho. Cabe ao DBA transmitir esses conhecimentos aosprofissionais ligados ao desenvolvimento de sistemas, pois os problemas podero ser tratados deforma proativa, evitando, assim, manutenes futuras.

Definir e gerenciar os perfisde acesso dos usurios

Cabe ao administrador definir a poltica de segurana aos dados da organizao garantindo queos usurios acessem somente as informaes necessrias para os seus processos, evitandodesperdcio no uso e manipulao.

Desta maneira, ele estar assegurando o uso eficiente das informaes e garantindo um bomdesempenho do gerenciador de banco de dados e na segurana no manuseio das informaes.

Com a implantao desta poltica de segurana o administrador poder controlar possveistentativas de violaes e roubo de informaes e tambm aes mal intencionadas por parte dosusurios.

Acompanhar o comportamentodos gerenciadores de banco de dados

Com o uso de ferramentas de monitoramento dos gerenciadores de banco de dados, oadministrador poder identificar comportamentos no padres no manuseio das informaes,possveis desvios no seu manuseio e detectar o crescimento inesperado das informaes no bancode dados. Com isso, ele deve tomar medidas necessrias de ajuste nos espaos fsicos e lgicosocupados pelo BD.

Este monitoramento dever ser feito diariamente, semanalmente, mensalmente, e por todo otempo de uso do BD, pois situaes atpicas podem aparecer a qualquer momento e quanto maisrpido forem detectadas essas mudanas, mais rpido podero ser tomadas medidas de ajustes noambiente.

Outro aspecto a ser considerado em relao aos gerenciadores de banco de dados que elespossuem um conjunto de tabelas utilizadas para o gerenciamento do ambiente e para a tomada dedeciso do otimizador. Essas tabelas esto localizadas no dicionrio de dados.

Entre as informaes contidas nelas, existe uma srie de estatsticas tanto dos objetos comodas aplicaes que acessam o banco de dados. O otimizador utiliza as informaes dessasestatsticas para escolher o melhor caminho a ser feito por um comando SQL quando ele forexecutado.

Algumas das informaes dessas estatsticas so atualizadas automaticamente pelogerenciador e outras tm que ser feitas por meios de comandos, por exemplo, a quantidade defragmentao de um objeto.

Cabe ao administrador manter essas estatsticas atualizadas para que o otimizador sempretome as melhores decises a respeito do caminho a ser utilizado por um comando SQL e tambmpara uma avaliao precisa das condies de desempenho de um SGBD.

Treinamento e apoio para analistase programadores

O administrador de banco de dados tem a responsabilidade pelo desempenho de todos osprofissionais envolvidos no desenvolvimento das aplicaes como os analistas e programadores.Desta maneira, fica a seu encargo prover todo o apoio e treinamento a esses profissionais para queeles faam o uso eficiente.

Tambm faz parte das medidas de apoio a avaliao dos comandos de acesso e manipulaodos bancos de dados envolvidas nas aplicaes antes delas irem para a produo.

Neste contexto o administrador poder avaliar os comandos das aplicaes submetendo-os,como exemplo, ao comando EXPLAIN PLAN do SQL, pois ele ir fornecer uma srie de informaes arespeito do comando como, seu custo, quantidade de linhas a serem processadas, se estarutilizando o ndice ou no e outras informaes necessrias para a anlise.

Desta maneira, a administrador poder avaliar com preciso se o comando SQL a ser utilizadonas aplicaes o far de maneira eficiente ou no.

Planejamento, implantaoe acompanhamento dos procedimentos de backup erecovery

Um dos processos mais importantes definido pelo administrador a poltica de backup erecuperao dos bancos de dados, pois ela que ir definir tanto o aspecto da disponibilidade dasinformaes para os usurios e a poltica de segurana na recuperao das informaes em caso deperda ou alguma manipulao indevida.

Neste processo dever ser definido, por exemplo, quanto tempo o banco de dados poder ficarindisponvel para o usurio, quanto tempo as informaes devero estar disponveis no banco, se umano, cinco anos, etc. Estas questes iro definir a poltica de backup e recuperao de dados que oadministrador dever implementar.

A poltica dever ter controle de qualidade rigoroso e processos bem definidos em relao aoarmazenamento das mdias, vida til, ambiente onde elas sero guardadas, quem ir manipul-las,testes de recuperao de dados, entre outros.

Agora que voc j estudou esta aula, resolva os exerccios e verifique seu conhecimento. Caso fique alguma dvida, leve a questo aoFrum e divida com seus colegas e professor.

Referncias

BOSCATTO, R.; DAMINELLO, M.R. Instituto municipal ensino superior de So Caetano do Sul, 1999.BRYLA, B.; Loney, K. Oracle Data Base 10g manual do DBA. So Paulo: Campus, 2005.CARATTI, R. Ajustes de Desempenho em "Consultas Simples" na SQL, SQL Magazine 11, 2004.Disponvel em: www.devmedia.com.br. Acesso em: 22 jan. 2013.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.MORELLI, Eduardo Terra. Oracle 9i Fundamental: SQL, PL/SQL e Administrao. So Paulo: rica,2012.NIEMIEC, Richard J. Oracle Database 10g performance tuning tips & techniques. New York:McGraw-Hill, 2007.ORACLE Database Performance Tuning Guide, Copyright 2000, 2011, Oracle and/or its affiliates.All rights reserved. Disponvel em: docs.oracle.com. Acesso em 21 jan. 2013.PARRA, L.S. (2005). Tuning de Desempenho em Banco de Dados. Londrina-UEL UniversidadeEstadual de Londrina. Dissertao de Mestrado. Disponvel em: www2.dc.uel.br. Acesso em 21 jan.2013.PATTERSON, D. A; Gibson, G; Katz, R.H; A case for redundant arrays of inexpensive disks (RAID).Proc. ACM Conf. on management of data, 1988.SILVA, Robson S. Oracle Database 10g. Express Edition. So Paulo: rica, 2007.

Aumentando odesempenho de umaaplicao por meio de

processos de refinamentodo ambiente onde ser

utilizada a linguagem SQLdo banco de dados

Resumir o ambiente onde devero ser utilizados os comandos SQL de umaaplicao para manipulao dos bancos de dados relacionais, identificando os

principais processos a serem considerados, visando melhoria dodesempenho dessas aplicaes.

Introduo

O processo de aperfeioamento de um comando SQL dever ser feito bem antes de estar emfase de produo, ou seja, dever ser visto inicialmente pelos programadores e analistas que estoprojetando a aplicao. Para isto se faz necessrio o treinamento destes profissionais para que elestenham conhecimento dos fatores que podero influenciar o desempenho de uma aplicao.

Aps eles elaborarem a aplicao, devero passar por um processo de avaliao para verificarse esto atendendo requisitos de qualidade neste aspecto.

A anlise proativa sobre o desempenho do sistema a abordagem mais eficiente e evita essecenrio. Para que isso seja possvel, preciso que os executivos da empresa colaborem com osprojetistas, no sentido de estabelecer metas justificveis de desempenho, fixando expectativas reaisdesde o incio. (CARATTI, 2004).

O tipo de aplicao tambm um fator importante nesta anlise, pois uma aplicao OLTP (OnLine Transaction Process) se caracteriza por ser uma aplicao com muitos I/O (Input/Output), ouseja, atua nos processos empresariais como compras, vendas, produo, pagamentos, recebimentosetc, e fazem gravao no banco de dados destas informaes.

Por outro lado, existem as aplicaes de data warehouse que se caracterizam por serem

aplicaes que manipulam uma quantidade muito grande de dados e que costumam ter consultasSQL bastante complexas.

Faremos agora uma anlise de cada um desses processos:

Processos avaliando as regras de negcio

Esses processos devero avaliar aspectos ligados aos negcios do ambiente como nmero deusurios envolvidos na aplicao, tempos de resposta permitidos para cada aplicao, entre outros.Alm disso, eles visam ajustar necessidades dos usurios s de informaes no banco de dados.

Por exemplo, o caso de um usurio que necessita de informaes comerciais dos ltimos cincoanos, obtida de um dia para outro ou precisa da informao naquele momento. No caso de poderobter a informao no dia seguinte, a informao poder ficar em um banco de dados de histrico eno no de informaes correntes do dia a dia.

Desta maneira, o administrador poder separar estas informaes e tornar o BD mais eficientepara as operaes rotineiras, deixando as histricas em outro ambiente ou tablespace, por exemplo.

Processos avaliando o projeto dos dados do banco de dados

Todo projeto de desenvolvimento de um banco de dados comea com a fase de modelagem, eas fases de normalizao. Nesta fase, caso seja possvel, dever ter a participao de umadministrador de banco de dados, pois alm de considerar a questo de negcios do banco, irtambm considerar aspectos de desempenho.

Um banco de dados mal modelado ir gerar problemas de desempenho por todo o tempo deuso deles, independentemente das aplicaes serem desenvolvidas de maneira eficiente ou no. Oideal que o processo de modelagem considere pelo menos at a Terceira Forma Normal (3FN).

Processos avaliando o projeto das aplicaes

Um dos principais fatores que influenciam o desempenho das aplicaes o uso de ndices naspesquisas dos dados.

Toda vez que o SGBD detecta que existe um ndice em uma pesquisa, ele no far a varredurade uma tabela, e ir buscar a informao diretamente no ndice correspondente.

Portanto, os processos de avaliao das necessidades de ndices nas aplicaes so deextrema importncia e levaro a um ganho de desempenho significativo. Entretanto, no podemosesquecer que o SGBD mantm uma integridade entre os dados das tabelas e os seus ndices, ou

seja, toda vez que houver uma atualizao em uma coluna indexada ele tambm far a atualizaonos ndices correspondentes.

Desta maneira, as aplicaes que fazem muitas atualizaes nos dados tambm a faro muitasnos ndices. Sendo assim, elas devero ser avaliadas, e se deve verificar a possibilidade delas seremexecutadas em horrios pr-determinados, para que o desempenho do ambiente no seja afetado.

Processos avaliando as operaes do Sistema Gerenciadordo Banco de Dados (SGBD)

Esses processos devero considerar aspectos como o uso do banco de dados de maneiraeficiente, ou seja, devem-se evitar comandos SQL complexos dentro das aplicaes, pois muitomais eficiente para o gerenciador processar mais comandos simples do que um nico comando SQLcomplexo.

Tambm das aplicaes irem para a produo, interessante fazer sua avaliao, por exemplo,por intermdio do comando explain plan que fornece uma srie de informao a respeito docomando como se usam ndices ou no, quantidades de linhas processadas, custo, entre outras.

Comandos SQL que ordenam as linhas (order by, group by) devem ser evitados e usadossomente em caso de extrema necessidade, pois toda vez que houver um comando destes ogerenciador ir trazer as linhas da tabela correspondente para a memria e depois ir classific-las enormalmente desconsidera o uso de ndices. Outro aspecto a ser evitado nos comandos SQL acomparao de dados incompatveis, ou seja, compara campos numricos com camposalfanumricos, por exemplo.

Toda vez que o gerenciador identificar uma situao, dessas ele ir fazer a converso de umdos campos para que os dois tenham as mesmas especificaes e, desta maneira, poder afetar odesempenho do comando e da aplicao.

Processos avaliando a memria utilizada pelo SGBD

A quantidade de memria a ser fornecida para o SGBD tambm pode afetar o seudesempenho, ou seja, se fornecemos pouca memria, ele no conseguir trazer todos os objetospara a memria quando necessitar, s ir trazer o que couber na memria. Em seguida, ele utiliza,libera e vai buscar outro objeto provocando muitas atividades de swap no sistema operacional.

Entretanto, a memria do servidor no somente do gerenciador, pois tambm tem que serdividida com o sistema operacional, ou seja, tambm no adianta fornecermos uma quantidadeexcessiva de memria para o gerenciador e deixarmos o sistema operacional com memriainsuficiente.

Os processos ligados alocao de memria devero fazer uma anlise e identificar aquantidade precisa tanto para o gerenciador como para o sistema operacional. No caso dogerenciador devero ser avaliados os parmetros de shared pool, bufffer cache, log buffer, entre

outros.

Processos avaliando as operaes de I/O (input/output) dedados

necessrio existir processos para avaliar as entradas e sadas das aplicaes, pois este umitem que poder afetar o desempenho dos gerenciadores de banco de dados. Dever ser evitadorodar outras aplicaes nos servidores de banco de dados, pois, assim, far concorrncia com asoperaes do gerenciador.

Outro aspecto importante a diviso dos objetos do banco em unidades de discos separadascomo tabelas em uma e ndices em outra, como exemplo, e, desta maneira, evitar o gargalo em umanica unidade.

A questo da fragmentao dos objetos como tabelas, ndices e tablespaces tambm deverser levada em considerao, pois isto costuma degradar o desempenho nas leituras e gravao dasinformaes no meio fsico.

Processos avaliando a alocao dos recursos do banco dedados

Uma caracterstica importante dos gerenciadores de banco de dados que eles no permitemque dois usurios acessem a mesma informao para atualizao ao mesmo tempo.

Para isto eles dispem de um mecanismo de trava (Locks) para os dados assim que o primeirousurio os requisita para atualizao. Essa trava s encerrada assim que a aplicao conclui o seuservio, ou seja, assim que a sesso relativa aplicao se encerra, tanto de maneira satisfatria(commit) ou insatisfatria (rollback).

tarefa do administrador de banco de dados avaliar se essas aplicaes esto solicitando osdados necessrios para atualizao, ou seja, evitar travar dados desnecessrios para a aplicao eprejudicar o desempenho da aplicao e do ambiente. Os gerenciadores podem travar tanto algumaslinhas de uma tabela como uma tabela inteira, dependendo da necessidade das aplicaes.

Depois de rever o contedo desta aula, solucione os exerccios de mltipla escolha propostos. Lembre-se de que voc poder postarsuas dvidas no Frum e ter auxlio de seus colegas e professor.

Referncias

BOSCATTO, R.; DAMINELLO, M.R. Instituto municipal ensino superior de So Caetano do Sul, 1999.BRYLA, B.; Loney, K. Oracle Data Base 10g manual do DBA. So Paulo: Campus, 2005.CARATTI, R. Ajustes de Desempenho em "Consultas Simples" na SQL, SQL Magazine 11, 2004.Disponvel em:www.devmedia.com.br. Acesso em: 22 jan. 2013.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.MORELLI, Eduardo Terra. Oracle 9i Fundamental: SQL, PL/SQL e Administrao. So Paulo: rica,2012.NIEMIEC, Richard J. Oracle Database 10g performance tuning tips & techniques. New York:McGraw-Hill, 2007.PATTERSON, D. A; Gibson, G; Katz, R.H; A case for redundant arrays of inexpensive disks (RAID).Proc. ACM Conf. on management of data, 1988.SILVA, Robson S. Oracle Database 10g. Express Edition. So Paulo: rica, 2007.

Avaliao do desempenhodas consultas SQL

utilizadas nas aplicaesDar uma viso dos principais cuidados a serem tomados na elaborao doscomandos SQL utilizados em uma aplicao, para que eles acessem os dadosdos BD de forma eficiente e da melhor maneira possvel sem comprometer o

desempenho da aplicao e o ambiente do BD como um todo.

Introduo

Existe uma srie de cuidados a serem tomados na elaborao de um comando SQL de acesso emanipulao das informaes nos banco de dados. No filtro desses acessos, devero ser tomadoscuidados para que ele no faa varredura nas informaes das tabelas, pois isso se torna onerosopara o gerenciador, particularmente em tabelas com um nmero muito grande de linhas.

Outro aspecto a ser considerado nesses filtros de acesso que devemos fornecer um maiornmero possvel de informaes para pesquisa, pois quanto menos informaes fornecermos, maistrabalho o gerenciador ir ter para conseguir buscar aquilo que pedimos e, consequentemente, piorser o desempenho da aplicao e do ambiente.

Vejamos uma descrio desses cuidados.

Quantidade de informaes fornecidas na clusula Where

Os filtros de pesquisa dos comandos de acesso aos bancos de dados SQL devero receberinformaes da forma mais precisa possvel para encontrar o que esta procurando, pois quantomenos informaes forem fornecidas, mais trabalho o gerenciador ter para encontrar o dadoprocurado e, desta maneira, poder prejudicar o desempenho da aplicao e tambm do ambientecomo um todo.

Vamos considerar os trs exemplos de filtro de pesquisa a seguir:Cenrio 1 -... WHERE endereo LIKE ?Rua%? AND nome LIKE ?Joao%?Cenrio 2 -... WHERE nome ?Pedro?Cenrio 3 -... WHERE codigo = 5No caso dos cenrios 1 e 2 o gerenciador dever fazer uma busca em toda a tabela, pois no

sabe exatamente o que procurar. No caso do cenrio 3 o gerenciador sabe exatamente o que

procurar, e a pesquisa ser mais eficiente, pois alm de ter informao precisa, ainda poder utilizarum ndice, caso exista.

Desta maneira, fica claro que os filtros de pesquisa devero ter, na medida do possvel,informaes cada vez mais precisas, pois iro proporcionar um bom desempenho na aplicao queutiliza o cdigo SQL e no ambiente.

Consultas simples envolvendo uma pequena quantidade dedados e com filtros simples

Quanto mais simples for o comando SQL mais facilmente o otimizador ir atender anecessidade da aplicao e do usurio, pois comandos que manipulam muitas linhas e comconsultas altamente complexas iro gerar um trabalho para o otimizador resolver, o que poderafetar o desempenho do comando e do ambiente.

O ideal ao invs de se fazer um comando SQL complexo deve-se fazer mais de um comandoSQL simples, pois, assim, o BD ter um desempenho melhor.

Desempenho dos tipos de operadores de comparao

O desempenho de um comando SQL depende, entre outros fatores, do filtro de pesquisa naclusula Where quando se est buscando alguma informao.

Quanto mais exatas forem as informaes passadas neste filtro de pesquisa, melhor ser odesempenho do comando SQL no acesso aos dados. Esta exatido diretamente ligada ao tipo deoperador utilizado no filtro de pesquisa de um comando SQL.

Existe um quadro que informa a pontuao relativa ao desempenho de cada tipo de operadorem um filtro de pesquisa; quanto maior a pontuao melhor ser o desempenho no uso desteoperador.

Tipo de operador no filtro Pontuao relativo ao desempenho= 10> 5>= 5< 5

Tipo de operador no filtro Pontuao relativo ao desempenho= 10> 5>= 5< 5 descontos

Avaliao de letras maisculas e minsculas

Uma questo importante no ambiente e que acaba interferindo no desempenho dos comandosSQL so as letras maisculas ou minsculas, pois os gerenciadores tratam de maneira diferente cadauma dessas letras. Para que esta questo no afete o desempenho das pesquisas, devemos definir oambiente com um dos dois tipos de letras e deixarmos como padro.

No momento da pesquisa podemos alterar o formato para o padro que precisarmos,entretanto, a converso se torna onerosa, pois deveremos usar funes para esta converso, ouseja, UPPER para a converso maiscula e LOWER para a converso minscula.

Essas ou outras funes acabam desconsiderando os ndices, caso eles existam, portanto,devero ser utilizadas somente em caso de necessidade e no como um procedimento corriqueiro.Desta maneira, um padro definido para todo o ambiente e respeitado por todos melhora odesempenho consideravelmente.

Uso de funes nas pesquisas dos comandos SQL

As funes tm um poder muito grande na manipulao dos dados nos comandos SQL,entretanto, elas normalmente no consideram os ndices para as colunas, caso existam, no momentoda pesquisa.

Desta maneira, seu uso dever ser feito somente no caso de grande necessidade, pois se deum lado ela oferece flexibilidade, por outro lado, afeta o desempenho do comando SQL.

Ordem dos operadores e operando nos filtros

Assim como nas linguagens de programao, a ordem das perguntas sempre respeitam ooperador na esquerda e o a direita, separados pelos operadores lgicos.

Se esta ordem no for respeitada, entretanto, os comandos SQL devero aceitar como vlido ocomando, porm o otimizador ir fazer as alteraes necessrias colocando na ordem padro.

J que ele ir alterar a ordem devemos, portanto, manter o formato padro, a fim de evitar umtrabalho a mais para o otimizador, afetando o desempenho do comando SQL.

Vejamos o exemplo a seguir:20.00 = vendas alterado para: vendas = 20.00WHERE vendas 40,00 = - comisso alterado para: Comisso = - vendas+40,00

Operadores AND e OR envolvidos nos comandos SQL

Os operadores AND e OR de um comando SQL obedecem a um critrio na avaliao quandoso executados pelo gerenciador, ou seja, no caso do operador AND ele testa a primeira condio, nocaso dela ser verdadeira ele vai testar a segunda condio. J no caso da segunda ser verdadeira elevai testar a terceira condio, e assim por diante. Desta maneira, se a primeira condio for falsa ogerenciador nem ir testar a segunda condio.

Aproveitando esta lgica, deveremos colocar a condio menos provvel primeiro, pois, se acondio for falsa, ele nem ir testar a segunda condio, ganhando em desempenho.

Como exemplo deste conceito pode ilustrar:Where comisso = 0 and vendas > 1000.00Considerando que a condio de comisso = 0 a menos provvel.No caso do operador OR, ele testa a primeira condio, se for verdadeira ele nem vai testar a

segunda condio, ou seja, s vai testar a segunda condio caso a primeira seja falsa, e s vaitestar a terceira caso a segunda seja falsa.

Aproveitando essa lgica, deveremos colocar a condio mais provvel primeiro, pois se acondio for verdadeira ele nem ir testar a segunda, ganhando em desempenho.

Como exemplo desse conceito, pode-se ilustrar:Where vendas > 1000.00 OR comisso = 0 OR lucro > 1.000,00Considerando que a condio de vendas > 1000.00 a mais provvel.

Agrupamento de colunas iguais no uso do OR em umcomando SQL

Quando temos vrios operando com uma mesma coluna em um comando SQL o ideal que asoperaes com a mesma coluna estejam juntas, pois o gerenciador ir ler a coluna uma nica vez e,assim, estar ajudando no desempenho do comando SQL e do ambiente.

Considerando o exemplo a seguir, podemos ver:Where codigo = 10 ORvendas > 1000.00 ORcodigo = 20Dever ser colocada na seguinte ordem:Where codigo = 10 ORcodigo = 20 ORvendas > 1000.00

Operador de desigualdade NOT

Sempre que possvel a utilizao da expresso NOT dever ser evitada, pois em uma pesquisana qual se informa o que no se quer o gerenciador ir fazer uma varredura nas linhas de umatabela, podendo afetar a performance da aplicao.

Sempre que possvel a pergunta dever ser feita pela expresso verdadeira e no pelaexpresso falsa.

Vejamos no seguinte exemplo:... WHERE NOT (vendas > 100.00)Dever ser substituda por... WHERE vendas

Avaliao dosmecanismos de travas(Locks) dos SGBD nas

atualizaes dasinformaes

Observar os procedimentos adotados pelos gerenciadores de banco de dadosnos processos de consulta e atualizao das informaes, considerando a

concorrncia dos usurios dessas.

Introduo

A concorrncia pelas informaes armazenadas nos bancos de dados cada vez maior, vistoque quase todos os processos das organizaes dependem das informaes para serem realizados.Como exemplos, podemos citar a internet como um meio para as organizaes realizarem asoperaes de vendas de seus produtos. Desta maneira, a necessidade pelas informaes vem sendocada vez maior e isto dever ser controlado para que elas tenham a sua integridade mantida.

Neste cenrio, os SGBD desenvolveram um mecanismo para garantir que a mesma informaono seja atualizada por mais de um usurio ao mesmo tempo, conhecido como travas ou locks. Apartir do momento que um determinado usurio solicita uma informao para atualizao ogerenciador de banco de dados a bloqueia para outros usurios at que o processo de atualizao doprimeiro usurio seja concludo.

Locks dos gerenciadores de banco de dados

O conceito de lock consiste de manter um dado locado por uma seo, ou seja, um usurio queacessou a informao para atualizao ate que a seo seja concluda com sucesso (commit) ou semsucesso (rollback).

Estrutura do lock no SGBD Oracle

A estrutura do lock do SGBD Oracle bastante eficiente e sofisticada, chegando a ser melhorque os demais gerenciadores como o DB2 e SQL-Server.

O gerenciamento do lock do Oracle feito totalmente no cabealho do bloco em que reside oregistro, enquanto que os demais gerenciadores de BD, como o DB2, feito por um gerenciador delocks, ou seja, o lock manager.

Esta estrutura mais eficiente, pois como o gerenciamento feito no prprio cabealho doregistro evita possveis gargalos no caso de grandes atualizaes no banco de dados.

Existem duas estruturas de locks feitos pelos gerenciadores de banco de dados, ou seja, oslocks para tratamento de linhas e os locks para tratamento de tabelas.

Locks para tratamento de linhas

Este tipo de lock utilizado quando necessitamos fazer uma atualizao em uma ou maislinhas da tabela.

A partir do momento que estas linhas esto sendo atualizados pelo gerenciador, os demaisusurios que necessitarem de uma atualizao no conseguiro at que a seo relativa a estaatualizao esteja encerrada, quer seja a atualizao com sucesso (commit) ou no tenha sucessona atualizao (rollback).

Evidentemente essas linhas, enquanto atualizadas, podero ser consultadas por outrosusurios ou processos sem nenhum problema, e tambm podero ser atualizadas outras linhas poroutros usurios.

Em relao ao desempenho da aplicao e ao ambiente, o ideal que ela faa bloqueiosomente nas linhas necessrias que sero atualizadas e preferencialmente faa o bloqueio na horaque ela for atualizada, evitando, assim, o bloqueio de linhas por um longo tempo.

Locks para tratamento de tabelas

Este tipo de lock utilizado quando necessitamos fazer uma atualizao em uma tabela inteira.Quando este tipo de lock solicitado, o gerenciador faz cpia da tabela na memria paraprovidenciar as alteraes e a bloqueia para que ningum faa alteraes em suas linhas enquanto atabela estiver sendo atualizada.

Aplicaes que fazem bloqueio em uma tabela inteira devero ser executadas em horrios pr-determinados a fim de evitar problemas de desempenho no ambiente, ou seja, enquanto estaaplicao estiver bloqueando a tabela toda nenhuma outra aplicao ir conseguir atualizar outra

linha desta tabela, somente ir consulta-las.A tabela que gerencia os locks do ambiente no caso do gerenciador Oracle a tabela V$LOCK.

No caso especfico do gerenciador Oracle existe vrios tipos de locks, cada um com caractersticasdiferentes. Os tipos de locks do Oracle so descritos a seguir:

Row Share (RS)

Este tipo de lock tem como principal caracterstica o bloqueio das linhas antes de fazer asalteraes, ou seja, possui linhas locadas, mas ainda no efetuou a alterao nelas.

Em termos de desempenho no a melhor soluo, pois se forem alocadas muitas linhas, elasficaro indisponveis para outros usurios enquanto suas alteraes no forem concludas.

Os comandos que solicitam este tipo de lock so:SELECT...... FROM nome_tabela FOR UPDATELOCK TABLE nome_tabela IN ROW SHARE MODE

Row Exclusive (RX)

Este tipo de lock tem como principal caracterstica o bloqueio das linhas no momento em queforem alteradas, ou seja, possui linhas locadas, e as alteraes esto sendo feitas. mais eficienteem termos de desempenho, pois as linhas so bloqueadas somente no momento da alterao, com otempo de bloqueio menor.

Em termos de desempenho, o comando SQL que ir fazer as alteraes deve ser eficiente paraefetuar o bloqueio somente nas linhas que sero alteradas e no bloquear linhas que no sofreroalteraes, evitando desperdcio de recursos.

Os comandos que solicitam este tipo de lock so:INSER INTO nome_tabelaUPDATE nome_tabelaDELETE FROM nome_tabelaLOCK TABLE nome_tabela IN ROW EXCLUSIVE MODE

Share (S)

Este tipo de lock tem como principal caracterstica permitir que mais de uma seo possa obter

o lock de uma tabela, entretanto, o gerenciador somente ir fazer os comandos DML de uma seopor vez, ou seja, quando uma seo encerra, normal ou anormalmente, que o gerenciador efetuaos comandos DML das demais sees.

O comando que solicita este tipo de lock :LOCK TABLE nome_tabela IN SHARE MODE

Share Row Exclusive (SSX)

Este tipo de lock tem como principal caracterstica permitir que somente uma seo possaobter o lock de uma tabela, ou seja, um pouco mais restritivo que o locks. Ele permite tambm obloqueio de algumas linhas, entretanto, somente os comandos DML aps encerrar a seo da tabela.

O comando que solicita este tipo de lock :LOCK TABLE nome_tabela IN SHARE ROW EXCLUSIVE MODE

Exclusive (X)

Este tipo de lock tem como principal caracterstica ser o mais poderoso de restrio entre todosos outros, pois permite que as outras sees acessem as linhas somente para consultas.

Outra caracterstica importante deste tipo de lock que ele pode ser aplicado somente para obloqueio de linhas, ou seja, quando uma linha estiver travada nenhuma aplicao poder emitir umcomando DML para ela at que seo se encerre normalmente (Commit) ou anormalmente(Rollback).

Este tipo de lock obtido automaticamente por meio dos comandos Insert, Update e Delete.O comando que solicita este tipo de lock :LOCK ROW EXCLUSIVE MODE

Dead lock

Quando dois ou mais usurios esto esperando por acesso a dados que um usurio bloqueoupara o outro conhecido como um dead lock ou impasse.

Quando ocorre este conflito, as transaes deixam de ir em frente, pois elas ficam presas.Nestes casos, os SGBD quebram o impasse, forando uma ou mais transaes a serem desfeitas.

Se o bloqueio padro dos SGBD so substitudos em qualquer nvel, o administrador de banco

de dados ou o desenvolvedor do aplicativo deve garantir que os procedimentos de bloqueio devamfuncionar corretamente, dando garantia da integridade e simultaneidade dos dados.

Concluso

O bloqueio ou locks uma parte muito importante de qualquer sistema de base de dados. Omais interessante utilizar o bloqueio implcito dos sistemas gerenciadores.

Caso muito necessrio, deve-se usar o bloqueio manual, pois utilizando os bloqueios implcitosos gerenciadores garantem a maior consistncia, integridade e simultaneidade dos dados.


RefernciasBOSCATTO, R.; DAMINELLO, M.R. Instituto municipal ensino superior de So Caetano do Sul, 1999.BRYLA, B.; Loney, K.Oracle Data Base 10g manual do DBA.So Paulo: Campus, 2005.JARKE, M.; KOCH, J.Query optimization in database systemACM computing servers, 1984.KOCK, G.; KEVIN, L. Oracle 8: The complete reference. Oracle Press, 1997.MORELLI, Eduardo Terra. Oracle 9i Fundamental: SQL, PL/SQL e Administrao. So Paulo: rica,2012.NIEMIEC, Richard J. Oracle Database 10g performance tuning tips & techniquesNew York: McGraw-Hill, 2007.PATTERSON, D. A; Gibson, G; Katz, R.H. A case for redundant arrays of inexpensive disks (RAID),1988.SILVA, Robson S. Oracle Database 10g Express Edition. So Paulo: rica, 2007.BAM, A. Oracle Locks Parte 1. SQL Magazine.Dev Media, 313, 2005. Disponvel em:www.devmedia.com.br. Acesso em: 22 jan. 2013.CARATTI, R. Ajustes de Desempenho em "Consultas Simples" na SQL,SQL Magazine 11,2004.Disponvel em: www.devmedia.com.br. Acesso em: 22 jan. 2013.ORACLE.Database Performance Tuning Guide,Copyright 2000, 2011, Oracle and/or its affiliates.Disponvel em: docs.oracle.com. Acesso em 21 jan. 2013.PARRA, L.S. (2005). Tuning de Desempenho em Banco de Dados. Londrina-UEL UniversidadeEstadual de Londrina. Dissertao de Mestrado. Disponvel em: www2.dc.uel.br. Acesso em 21 jan.2013.

Criando um cenrio esimulando o mecanismo

de trava (lock) dogerenciador de banco de

dados Oracle e osmecanismos de

identificao e remoo,atravs dos comandos

apropriadosPraticar a simulao do mecanismo de trava (lock) do Oracle, identificando osobjetos geradores e os que foram prejudicados pelo lock gerado, removendo

esta trava por meio da eliminao utilizando comandos apropriados.

Introduo

A eficincia do ambiente dos bancos de dados depende da utilizao dos recursos, portanto, tarefa do administrador torn-los o mais disponvel possvel para que os processos de negcios nosejam prejudicados.

Bloqueios do gerenciador de banco de dados Oracle

Os processos de identificao das travas (locks) devero ser feitos de maneira eficiente paraque os recursos sejam utilizados da melhor maneira possvel.

Cabe ao administrador, por meio de comandos, identificar essas travas, com mecanismos

eficientes buscar qual a seo que est causando a trava e qual a que esta sendo prejudicada.Existem dois tipos de bloqueis do gerenciador de banco de dados. Primeiro, temos o bloqueio

explcito, ou seja, feito pelo prprio administrador quando quer fazer uma manuteno em algumobjeto do banco de dados e feito por meio dos comandos lock table.

Existe tambm o bloqueio implcito que o prprio sistema gerenciador de banco de dadoscria quando emitimos um comando DML, ou seja, INSERT, UPDATE ou DELETE. Este bloqueiosomente liberado quando emitido um comando com a efetivao da seo (commit) ou caso elano tenha ocorrido com sucesso (rollback).

Uma vez identificados s respectivas sees, deve-se tomar medidas para eliminar o impassepor meio da remoo das sees que esto sendo prejudicadas.

Vale ressaltar que a maioria dos problemas de trava resolvida pelo prprio gerenciador pelomecanismo de filas do Oracle e demais gerenciadores. Entretanto, muito importante uma anliseproativa do administrador de banco de dados nas aplicaes para que este problema no venhaocorrer, analisando as aplicaes e identificando aquelas que bloqueiam os recursos do gerenciadorpor um longo perodo de tempo.

Caso existam estas aplicaes, os desenvolvedores devero ser orientados para aplicar omecanismo de efetivao (commit) para que os recursos sejam liberados o mais rpido possvel.

A seguir faremos uma simulao do mecanismo de trava do Oracle; em seguida, utilizaremosos comandos para identificao e, posteriormente, faremos a eliminao desta situao, por vriospassos.

Passo 1: criar um perfil para usurio, restringindo-o para usar uma seo por vez no Oracle,atravs do usurio system.

O contedo desta pgina requer uma verso mais recente do Adobe Flash Player.

Passo 2: criar um primeiro usurio para ser utilizado na simulao.

Content on this page requires a newer version of Adobe Flash Player.

Passo 3: criar um segundo usurio para ser utilizado na simulao.


Passo 4: dar autorizao para os usurios isi_simulacao_01 e usu_simulacao_02 criar tabelas ese conectar no Oracle.


Passo 5: conectar-nos ao usurio usu_simulacao_01 e criar uma tabela cliente para simular atrava e inserir 2 linhas. Finalmente, devemos efetivar as implementaes.


Passo 6: uma vez criada a tabela cliente pelo primeiro usurio, devemos dar permisso deupdate na respectiva tabela para o segundo usurio.


Passo 7: ainda no primeiro usurio devemos fazer uma atualizao na tabela cliente parapoder simular a situao de trava pelo Oracle.


Passo 8: abrir uma nova seo com o usurio usu_simulacao_02 e fazermos uma mesmaatualizao no mesmo cliente.


Para fazermos o update, temos que informar o usurio em que foi criada a tabela cliente, poisela no foi criada por este usurio.

Percebemos que neste momento o gerenciador Oracle mostra a trava (lock) feita no clientecom o CNPJ igual a 67890120002132, pois o mesmo cliente est sendo atualizado pelo usuriousu_simulacao_01 e a seo ainda no foi finalizada (commit). Neste caso a seo do usuriousu_simulacao_02 fica aguardando a atualizao feita na seo do usurio usu_simulacao_01 serconcluda, ou seja, alguma emisso do comando commit.

Passo 9: uma vez criada a trava pelo Oracle devemos agora identificar qual a seo que estcausando o impasse para, posteriormente, eliminarmos.

Para isso, devemos voltar a seo do administrador, ou seja, system.


Passo 10: podemos identificar tambm qual a seo que esta causando o impasse, por meioda seguinte consulta:


Passo 11: podemos tambm identificar que objeto est causando o lock:


O objeto causador do lock a tabela CLIENTE.

Passo 12: identificar qual a seo que est aguardando a soluo do impasse.


Passo 13: podemos tambm identificar a seo que causou o lock e a seo que estaaguardando a liberao do lock por meio de um join.


Passo 14: como podemos resolver os conflitos de locksOs conflitos de lock podero ser resolvidos ou pela emisso de um commit na seo que esta

causando o lock ou por meio do trmino da respectiva seo.

A emisso desse commit poder ser feita caso o usurio encerre a aplicao que esta utilizandoa seo.O encerramento da seo poder ser feito tambm, de maneira mais dramtica, pelocomando KILL do Oracle.

Primeiro, temos que encontrar o identificador e o serial number da seo que esta causando olock, por meio do seguinte comando:


Posteriormente, eliminamos a seo que esta causando o lock, por meio do comando a seguir:



RefernciasBOSCATTO, R.; DAMINELLO, M.R. Instituto municipal ensino superior de So Caetano do Sul, 1999.BRYLA, B.; Loney, K. Oracle Data Base 10g manual do DBA. So Paulo: Campus, 2005.

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.MORELLI, Eduardo Terra. Oracle 9i Fundamental: SQL, PL/SQL e Administrao. So Paulo: rica,2012.NIEMIEC, Richard J. Oracle Database 10g performance tuning tips & techniques. New York:McGraw-Hill, 2007.PATTERSON, D. A; Gibson, G; Katz, R.H. A case for redundant arrays of inexpensive disks (RAID),1988.SILVA, Robson S. Oracle Database 10g Express Edition. So Paulo: rica, 2007.BAM, A. Oracle Locks Parte 1. SQL Magazine. Dev Media, 313, 2005. Disponvel em:www.devmedia.com.br. Acesso em: 22 jan. 2013.

CARATTI, R. Ajustes de Desempenho em "Consultas Simples" na SQL, SQL Magazine 11, 2004.Disponvel em: www.devmedia.com.br. Acesso em: 22 jan. 2013.ORACLE. Database Performance Tuning Guide, Copyright 2000, 2011, Oracle and/or its affiliates.Disponvel em: http://docs.oracle.com. Acesso em 21 jan. 2013.PARRA, L.S. (2005). Tuning de Desempenho em Banco de Dados. Londrina-UEL UniversidadeEstadual de Londrina. Dissertao de Mestrado. Disponvel em: www2.dc.uel.br. Acesso em 21 jan.2013.SOARES, F. Conflitos de Bloqueios, Blog de Flvio Soares, 2009. Disponvel em:http://profissionaloracle.com.br. Acesso em: 22 jan. 2013.

Fazendo um estudo daestrutura fsica e lgicado gerenciador de banco

de dados OracleDetalhar a estrutura fsica e lgica do gerenciador de banco de dados Oracle

para que todos tenham uma viso do funcionamento desta estrutura.

Introduo

Os gerenciadores de banco de dados, particularmente do Oracle, tm uma estrutura bastantecomplexa para o seu funcionamento, a qual se torna necessria para que eles tenham umdesempenho aceitvel nas questes de segurana, concorrncia, armazenamento, integridade eprincipalmente de performance.

Esta estrutura abrange aspectos de armazenamento fsico atravs dos data files do sistemaoperacional e armazenamento lgico por meio de tablespaces, segmentos, extents e blocos dedados Oracle.

Os quadros a seguir nos do uma viso grfica destas estruturas.

Estrutura fsica e lgica do banco de dados Oracle

Estrutura fsical

Estrutura Fsica do Banco de Dados Oracle. Objetivo: Mostrar os arquivos que compe a estrutura fsica do gerenciador de banco de dadosOracle.

Composta pelos arquivos que so estabelecidos no servidor por ocasio da instalao do

Oracle. Esta estrutura est sempre no ar, ou seja, disponvel para uso.Os arquivos que fazem parte da estrutura fsica do Oracle so os seguintes:

Data fileslEsses arquivos compem os arquivos de dados do Oracle e so responsveis por guardar todas

as informaes que so alimentadas pelos usurios, as estruturas dos objetos do banco de dados,como tabelas, ndices, views, etc. e tambm os objetos que fazem parte do controle do gerenciadorcomo o dicionrio de dados.

Eles devero ter seu crescimento gerenciado e controlado e tambm podem ter umcrescimento automtico, dependendo dos parmetros informados.

Alm disso, os arquivos devero fazer parte de um nico banco de dados, ou seja, cada BDdevero ter os seus prprios Data Files.Redo log filesl

Esses arquivos contm o registro de todo o histrico ocorrido no BD referente a alteraes, ouseja, todas as mudanas feitas nos dados do banco de dados so registradas neste arquivo comodata, hora, usurio, informao alterada, etc.

Eles so extremamente importantes, pois iro servir nos processos de recuperao do BD, ouseja, quando houver um problema e ele necessitar de uma recuperao nas suas informaes, essesarquivos sero utilizados, pois as alteraes contidas nestes arquivos so aplicadas em cima doltimo backup e, desta maneira, podemos recuperar o banco no momento em que houve a falha.

Um BD necessita de pelo menos dois arquivos de redo, podendo ter mais arquivos dependo danecessidade.

Control fileslEsses arquivos contm todas as informaes que so utilizadas para avaliao da integridade

do BD. O processo de avaliao da integridade do banco de dados feito durante todo o tempo emque a instncia estiver no ar, e no somente quando o banco de dados inicializado.

Todas as informaes necessrias para avaliao desta integridade esto contidas nestesarquivos, como localizao, algoritmos de avaliao de integridade, entre outras.Parameter filel

Este arquivo tem como objetivo identificar todos os parmetros dimensionados para o banco dedados instalados, desde parmetros envolvendo a estrutura fsica dos arquivos, como control files eredo log files e tambm parmetros de dimensionamento da instncia na memria, como SGA, etc.Password Filel

Este arquivo contm a senha dos usurios administrador do banco e tem, entre outrosobjetivos, a ativao e desativao de uma instncia do gerenciador Oracle.Archived log filesl

Este arquivo tem como objetivo armazenar as informaes dos redo log files do gerenciadorOracle. Toda vez que um arquivo do redo enche, as informaes so transferidas para este arquivode maneira offline e o gerenciador continua gravando as alteraes que ocorrem no BD outroarquivo de redo.

Desta maneira, as informaes podem ser guardadas, caso seja necessrio sua utilizao emum processo de recuperao do BD.Estrutura lgical

Estrutura lgica do Banco de Dados Oracle. Objetivo: Mostrar a relao entre a estrutura fsica e lgica do banco de dados Oracle.

Esta estrutura tem como caracterstica uma viso lgica para o armazenamento de dados nobanco de dados. Ela composta de tablespaces, segmentos, extenses e blocos de dados.

A estrutura lgica permite uma maior eficincia e flexibilidade no armazenamento dasinformaes, pois possvel juntar vrios arquivos de uma estrutura fsica em uma nica estruturalgica. Alm do mais, o controle do consumo dos espaos mais eficiente por meio da estruturalgica.

A relao a seguinte:Um BD dever ser armazenado em uma estrutura lgica conhecida como tablespaces.lUm tablespace dever fazer parte de um nico banco de dados.lA relao entre os tablespaces e os data file da estrutura fsica que um tablespace poder serlformado com um ou mais data files.Cada tablespace poder ser formado com um ou mais segmentos.lCada segmento poder ser formado com um ou mais extents.lCada extent poder ser formado com um ou mais blocos de dados Oracle.l

Cada bloco de dados Oracle poder ser formado com um ou mais blocos do sistema operacional. Nolcaso da estrutura fsica um data file poder ser composto por um ou mais blocos do sistemaoperacional.No caso da estrutura fsica um data file poder ser composto por um ou mais blocos do sistemaloperacional.

Os arquivos que compe a estrutura lgica so os seguintes:Tablespacesl

Consistem de uma viso lgica do espao a ser utilizado pelos BD nos data files da estruturafsica.Segmentosl

So pores menores das tablespaces utilizados pelos BD. Podero ser armazenados objetosespecficos dos bancos de dados em segmentos separados, como segmento de dados, ndices,rollback, etc.

Existem tambm os segmentos de undo utilizados nos processos de recuperao de dados do

banco.Extentsl

Extents so grupos de blocos Oracle adjacentes, ou seja, juntos. So utilizados no processo dealocao de espaos para o banco de dados, ou seja, quando o BD criado so alocados algunsextents para o banco, e medida que ele vai precisando de mais espaos, so alocados novossegmentos.

Blocos de dados Oracle

Os blocos de dados Oracle a menor unidade de armazenamento do banco de dados e tmvalores mltiplos dos blocos de dados do sistema operacional. A relao entre os blocos de dadosOracle e os do sistema operacional definida por ocasio da instalao do gerenciador do banco dedados.


RefernciasBAM, A. Oracle Locks Parte 1. SQL Magazine. Dev Media, 313, 2005. Disponvelem:www.devmedia.com.br. Acesso em: 22 jan. 2013.BOSCATTO, R.; DAMINELLO, M.R. Instituto municipal ensino superior de So Caetano do Sul, 1999.BRYLA, B.; Loney, K. Oracle Data Base 10g manual do DBA. So Paulo: Campus, 2005.CARATTI, R. Ajustes de Desempenho em "Consultas Simples" na SQL, SQL Magazine 11, 2004.Disponvel em: www.devmedia.com.br. Acesso em: 22 jan. 2013.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.MORELLI, Eduardo Terra. Oracle 9i Fundamental: SQL, PL/SQL e Administrao. So Paulo: rica,2012.NIEMIEC, Richard J. Oracle Database 10g performance tuning tips & techniques. New York:McGraw-Hill, 2007.ORACLE. Database Performance Tuning Guide, Copyright 2000, 2011, Oracle and/or its affiliates.Disponvel em: docs.oracle.com. Acesso em 21 jan. 2013.PARRA, L.S. (2005). Tuning de Desempenho em Banco de Dados. Londrina-UEL UniversidadeEstadual de Londrina. Dissertao de Mestrado. Disponvel em: www2.dc.uel.br. Acesso em 21 jan.2013.

PATTERSON, D. A; Gibson, G; Katz, R.H. A case for redundant arrays of inexpensive disks (RAID),1988.SILVA, Robson S. Oracle Database 10g Express Edition. So Paulo: rica, 2007.SOARES, F. Conflitos de Bloqueios, Blog de Flvio Soares, 2009. Disponvel em:profissionaloracle.com.br. Acesso em: 22 jan. 2013.

Fazendo um estudo daestrutura de memria dogerenciador de banco de

dados OracleDetalhar a estrutura de memria do gerenciador de banco de dados Oracle,

para que todos tenham uma viso do funcionamento do banco.

Estrutura de memria do bancode dados Oracle

Estrutura de memria compartilhada

Composta pelos arquivos que so carregados na memria formando a instncia do Oracle, aestrutura est no ar somente quando o Oracle inicializado.

Os dados dos arquivos da estrutura fsica s podem ser manuseados por meio desta estrutura,ou seja, pelas sesses criadas na instncia pelos usurios.

Os arquivos que fazem parte desta estrutura so os seguintes:

Para visualizarvisualizar a estrutura de memria do Banco de Dados Oracle clique no boto abaixo.

Instncia

A instncia se compe de toda a estrutura de memria criada quando o BD colocado no arbem como de uma SGA (System Global rea ou rea Global do Sistema) e tambm dos processos desegundo plano ou processos background.

O banco de dados somente poder ser acessado por meio da instncia.

SGA (System Global rea)

rea utilizada para armazenar informaes que sero utilizadas pelos usurios do banco dedados. Entre essas informaes, podemos identificar os ltimos comandos SQL e blocos PLSQLutilizados e validados.

Tambm existem os buffers onde so armazenados blocos de dados enquanto eles esto sendoprocessados. Os buffers contendo o histrico das alteraes do banco (REDO) tambm fazem partedesta estrutura.

Shared pool

Local onde so guardados os ltimos comandos SQL e blocos PLSQL utilizados nas seesanteriores e que j foram validados.

Caso estes comandos venham a serem utilizados novamente eles no precisam ser validados,pois o gerenciador busca o comando desta rea, valida a autorizao do usurio e executanovamente.

Tambm so guardadas neste local as estruturas dos objetos (tabelas, ndices, etc.) utilizadosna validao dos comandos.

Esta estrutura subdividida nas reas de library cache e data dictionary cache.

Library cache: local onde so guardados os comandos SQL e PLSQL utilizados maisrecentemente. Caso eles venham a ser utilizados novamente, no precisam ser validados.

Data dictionary cache: local onde so guardadas as estruturas dos objetos utilizadas navalidao dos comandos SQL e PLSQL.

Redo log buffer: local onde so guardadas todas as alteraes feitas no banco de dadosantes de serem enviadas para os redo log files.

Java pool: neste local ficam armazenadas todas as rotinas do gerenciador desenvolvidas emjava, ou seja, quando estas rotinas forem acionadas para execuo, as classes necessrias soextradas deste local.

Processos de segundo plano (processos background)

Esses processos so rotinas desenvolvidas pela Oracle para controlar e executar atividadesdistintas, como gravaes e leituras nos data files, gerenciamento da integridade do banco de dados,entre outras.

Esses processos so carregados para a memria medida que o gerenciador precisar destas

funes. Os processos do segundo plano so os seguintes:Data base writer (DBWO): tem como objetivo a transferncia dos dados do data buffer

cache para os data files e vice-versa.Tambm gerencia a necessidade de limpeza do data buffercache para liberar espaos para novas leituras para a memria.

Log writer (LGWR): objetiva a transferncia dos dados do redo log buffer para os arquivos deredo log.Tambm gerencia a necessidade de limpeza do buffer de redo para liberar espaos paranovas gravaes.

System Monitor (Monitor de Sistemas SMON): tem como objetivo verificar durante todoo tempo, desde quando ele aberto, a integridade dos dados e arquivos do BD, e em caso de perdadesta integridade, ele tenta fazer sua recuperao com base nos backups e arquivos de redo.

Process Monitor (Monitor de Processos PMON): objetiva identificar processos quefalharam anteriormente quando o banco de dados colocado no ar. No caso de identificar estesprocessos, ele efetua a limpeza dos dados deste processo, e tambm desfaz (rollback) todas asalteraes feitas por ele, voltando ao estgio inicial. Desta maneira, o gerenciador garante que oprocesso vai at o final com o sucesso das alteraes (commit), ou o processo volta ao seu estgioinicial desfazendo todas as alteraes feitas (rollback).

Checkpoint Process (CKPT): tem como objetivo gravar as informaes de controle e nosdata file sempre que ocorrer a transferncia dos dados do data buffer cache para estes, por ocasiode um commit. Esta gravao poder ser feita vrias vezes ao longo de uma seo garantindo seuretorno no ponto de gravao, caso ela no tenha sido concluda com sucesso. Desta maneira, evita-se voltar desde o incio da seo no caso de algum problema com a transao.

Esses checkpoints podero ser emitidos pelo gerenciador de tempos em tempos e por umaaplicao em um momento especfico, dependendo da necessidade.

Archiver (ARCN): objetiva fazer a transferncia dos registros de redo dos redo log files paraos archived log files e vice-versa, de maneira offline. Tambm tem a responsabilidade degerenciador os arquivos archived gravados e lidos posteriormente no caso do processo de umarecuperao (recovery) do BD.

Estrutura de memria do usurio (PGA Program Global rea): esta estrutura dememria criada pelo processo servidor para cada seo do usurio quando ele se conecta aobanco de dados, ou seja, quando aberta uma nova seo do usurio. Ela liberada quando ousurio encerra a aplicao ou quando a seo finalizada.

Existe uma estrutura de memria PGA para cada usurio.Os componentes da PGA so os seguintes:

rea de classificao Esta rea utilizada para quando o processo necessita efetuar uma classificao atravs dolorder by ou group by em um comando SQL, e caso esta classificao seja feita na memria.Informaes dos privilgios dos usurios Nesta rea so carregados todos os privilgios definidos para oslusurios, ou seja, de sistema e de objetos. Toda vez que um comando SQL validado, uma das validaes no sentido deverificar se o usurio que est tentando executar um comando SQL tem privilgios para tal.Controle do cursor Toda vez que um usurio efetua a seleo de dados nas tabelas, e nesta seleo vem mais deluma linha a bloco PLSQL tem que fazer isto por meio do uso de cursores. Nesta rea ficam registradas todas asinformaes da situao do cursor, utilizado na seo como: status de abertura e fechamento, posio em que linha lidaencontra etc.


RefernciasBOSCATTO, R.; DAMINELLO, M.R. Instituto municipal ensino superior de So Caetano do Sul, 1999.BRYLA, B.; Loney, K. Oracle Data Base 10g manual do DBA. So Paulo: Campus, 2005.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.MORELLI, Eduardo Terra. Oracle 9i Fundamental: SQL, PL/SQL e Administrao. So Paulo: rica,2012.NIEMIEC, Richard J. Oracle Database 10g performance tuning tips & techniques. New York:McGraw-Hill, 2007.PATTERSON, D. A; Gibson, G; Katz, R.H. A case for redundant arrays of inexpensive disks (RAID),1988.SILVA, Robson S. Oracle Database 10g Express Edition. So Paulo: rica, 2007.BAM, A. Oracle Locks Parte 1. SQL Magazine. Dev Media, 313, 2005.Disponvel em:www.devmedia.com.br. Acesso em: 22 de jan. de 2013.

BCARATTI, R. Ajustes de Desempenho em "Consultas Simples" na SQL, SQL Magazine 11,2004.Disponvel em: www.devmedia.com.br. Acesso em: 22 de jan. de 2013.

ORACLE. Database Performance Tuning Guide, Copyright 2000, 2011, Oracle and/or itsaffiliates.Disponvel em: http://docs.oracle.com. Acesso em: 21 de jan. de 2013.

PARRA, L.S. (2005). Tuning de Desempenho em Banco de Dados. Londrina-UEL UniversidadeEstadual de Londrina. Dissertao de Mestrado.Disponvel em: www2.dc.uel.br. Acesso em: 21 dejan. de 2013.

SOARES, F. Conflitos de Bloqueios, Blog de Flvio Soares, 2009. Disponvel em:profissionaloracle.com.br. Acesso em: 22 de jan. de 2013.

Avaliando os recursosdestinados para a

estrutura de memria dogerenciador de banco de

dados OracleAnalisar os recursos de memria destinados aos objetos do banco de dadosOracle, verificando se esto adequados para o bom desempenho do banco.

Introduo

Os objetos do gerenciador de Banco de Dados Oracle quando so carregados na memria, poiseles necessitam de espaos na memria para poderem cumprir o seu papel. Ocorre que se esteespao alocado na memria no adequado, o gerenciador no consegue carregar todos os objetosno momento em que necessita. Desta maneira, ele vai trazendo esses objetos medida que osespaos so disponibilizados e poder haver perda de desempenho.

Dentre esses objetos podemos citar os comandos SQL e blocos PLSQL que so guardados naShared Pool, as estruturas dos objetos para validao dos comandos SQL e os processos de segundoplano ou processos background que tm como responsabilidades a avaliao da integridade dobanco, entre outras. Esses espaos na memria podero ser consultados por meio das views deestatsticas e se eles no estiverem adequados, podero ser ajustados por parmetros estticos oudinmicos.

Parmetros de instncia

O tamanho definido para a SGA (System Global rea) tem uma influncia no seu desempenho,pois se ela for muito pequena o gerenciador no consegue trazer todos os objetos para a memriapor ocasio da criao da instncia. Por outro lado, se tiver uma rea muito alm do que necessita,poder comprometer o espao de memria para o sistema operacional e a criao dos processos doservidor criados para cada seo do usurio ou PGA (Program Global rea).

Esse espao poder ser ajustado de acordo com parmetros que podero ser dinmicos, ouseja, que podem ser passados sem tirar o banco de dados do ar, ou estticos, ou seja, existe anecessidade de tirar a instncia do ar para valer.

O espao adequado para a SGA dever ser avaliado pelo administrador de banco de dados,quer seja por meio de assistentes disponveis a partir da verso 10g, ou de consultas estatsticas emviews disponveis no dicionrio de dados.

Um exemplo da consulta do tamanho real da SGA poder ser feito por meio das informaesdisponveis na views V$SGASTAT disponvel no quadro a seguir.

Tamanho real da SGA de uma instncia Oracle


Legenda: Tamanho real da SGA de uma instncia OracleObjetivo: Identificar o Tamanho Real da SGA de uma instncia.

O tamanho limite da memria disponvel para a SGA dever ser definida com base noparmetro SGA_MAX_SIZE, de acordo com o quadro a seguir.

Tamanho limite da SGA de uma instncia Oracle


Legenda: Tamanho mximo permitido para a SGA de uma instncia Oracle. Objetivo: Definir o tamanho mximo permitidopara a SGA em uma instncia Oracle.

Uma avaliao a ser feita na memria alocada para a SGA e por meio da comparao dotamanho real utilizado e o tamanho limite disponvel no seguinte quadro.

O tamanho real nunca ir exceder o tamanho limite

Se o tamanho real est prximo ou igual ao limite significa que a quantidade limite disponvelpoder estar insuficiente e dever ser avaliada, pois isto um sintoma de que poder afetar odesempenho do gerenciador.

Por outro lado, se o tamanho real est muito abaixo do limite definido tambm pode indicarque a memria est muito grande, necessitando ser avaliada, pois a quantidade de memriadesperdiada poder faltar para o sistema operacional e para alocao das sees na PGA.

No caso deste parmetro no ter sido configurado, o gerenciador ir assumir o valor padrodefinido nos parmetros de inicializao do banco de dados.

Todos os valores definidos de alocao de memria na SGA sero definidos em grnulos queso blocos de aproximadamente 4M os quais podero variar dependendo do sistema operacional,alm de poderem ser configurados, por meio de parmetros.

Os valores dos grnulos utilizados podero ser consultados, de acordo com o quadro a seguir

Valores dos grnulos definidos para alocao de memria


Legenda: Valores dos grnulos definidos para alocao de memria em uma instncia. Objetivo: Definir o tamanho mnimoem grnulos quando so alocados espaos de memria para o banco de dados Oracle.

Esses grnulos podero variar dependendo do sistema operacional e tambm podero serconfigurados, de acordo com parmetros. Uma vez definido um valor para o grnulo, toda vez queformos alocar memria para a SGA o gerenciador ir alocar valores mltiplos do valor do grnulo.

Outra rea da memria que tem que ser gerenciada o pool compartilhado ou shared pool,pois esta rea compe a SGA. Nela ficam localizados os objetos que so utilizados por todos osusurios autorizados para esta instncia, por exemplo os comandos SQL, blocos PLSQL, estruturasdos objetos para avaliao dos comandos SQL emitidos, etc.

Existe um parmetro que define o tamanho limite de espao para esta rea conhecido comoSHARED_POOL_SIZE. Ele poder ser visualizado e alterado dinamicamente, como mostrado noquadro a seguir. Para alter-lo, no existe a necessidade de tirar do ar a instncia.

Visualizao e alterao do parmetro de tamanho dashared pool


Legenda: Visualizao e alterao do parmetro da shared pool de uma instncia. Objetivo: Visualizar o tamanho definidopara a shared pool de uma instncia e posteriormente alterar este valor para um novo tamanho.

Outro aspecto a ser considerado no pool compartilhado que ele tem uma srie de reas decontrole na memria que o gerenciador utiliza, entretanto, no temos nenhum controle sobre estasreas. Elas podero ser visualizadas por meioi de consultas na view V$SGASTAT, como mostrado no

quadro a diante.

Parmetros definidos para a shared pool e seus tamanhos


Legenda: Parmetros definidos para a shared pool e seus respectivos tamanhos. Objetivo: Identificar todos os parmetrosdefinidos para a shared pool que o Oracle utiliza, bem como o tamanho de cada um.

Dentro da estrutura do pool compartilhado existem algumas reas de devem ser destacadas,dentre essas reas podemos citar:

Cache do dicionrio de dadoslEsta rea armazena os objetos utilizados para avaliar os o comandos SQL, e o seu

dimensionamento correto tem uma importncia significativa no desempenho dos gerenciadores, poisquanto mais objeto estiver armazenado, menos buscas desses sero necessrias para avaliar oscomandos SQL que foram utilizados na instncia.Historic session activel

Esta rea tambm tem uma importncia grande no desempenho dos gerenciadores de bancode dados, pois ela armazena as informaes histricas das sesses dos usurios, e utilizada parafazer diagnsticos dos problemas das sesses. Quanto mais informao histrica tiver de uma seomais rpida dever ser o diagnstico das solues e desta maneira o desempenho do ambiente serbeneficiada.

O tamanho desta rea poder ser visualizado por meio da consulta na view V$SGASTAT, comomostrado no quadro a seguir.

Informaes histricas das sees dos usurios


Legenda: Informaes histricas das sees dos usurios. Objetivo: Identificar o tamanho definido na shared pool para oarmazenamento de informaes histricas das sees dos usurios.

Existe uma maneira de saber o tamanho ideal do pool compartilhado. Para isso, primeiro,temos que saber se o parmetro de estatstica da instncia est habilitado, ou seja, se est com ovalor typical, por meio da consulta a seguir.

Identificao da habilitao do parmetro de estatsticas


Legenda: Identificao da habilitao do parmetro de estatsticas.Objetivo: Identificar se o parmetro de estatsticas do Oracle esta habilitado, ou seja, se esta armazenando informaes deestatsticas no dicionrio de dados.

Para isso, primeiro temos que saber se o parmetro de estatstica da instncia esta habilitado,ou seja, esta com o valor typical, por meio da seguinte consulta.

Posteriormente, consultamos a view v$shared_pool_advice, pela consulta a seguir:

Avaliao do tamanho idealda shared pool


Avaliao do tamanho ideal para a shared pool.Objetivo: Avaliar o tamanho ideal a ser definido para a shared pool para queo Oracle tenha um desempenho aceitvel.

De acordo com a consulta anterior, o tempo economizado caso o tamanho do poolcompartilhado o mesmo se tivssemos 132MB de memria, ao invs dos 172MB utilizadoatualmente, ou seja, 2409 milissegundos. Podemos reduzir, portanto, o espao do poolcompartilhado de 172 MB para 132 MB e no perderamos nada em termos de desempenho dogerenciador do BD.


RefernciasBOSCATTO, R.; DAMINELLO, M.R. Instituto municipal ensino superior de So Caetano do Sul, 1999.BRYLA, B.; Loney, K. Oracle Data Base 10g manual do DBA. So Paulo: Campus, 2005.

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.MORELLI, Eduardo Terra. Oracle 9i Fundamental: SQL, PL/SQL e Administrao. So Paulo: rica,2012.NIEMIEC, Richard J. Oracle Database 10g performance tuning tips & techniques. New York:McGraw-Hill, 2007.PATTERSON, D. A; Gibson, G; Katz, R.H. A case for redundant arrays of inexpensive disks (RAID),1988.SILVA, Robson S. Oracle Database 10g Express Edition. So Paulo: rica, 2007.BAM, A. Oracle Locks Parte 1. SQL Magazine. Dev Media, 313, 2005. Disponvelem:www.devmedia.com.br. Acesso em: 25 de nov de 2010.CARATTI, R. Ajustes de Desempenho em "Consultas Simples" na SQL, SQL Magazine 11, 2004.Disponvel em: www.devmedia.com.br.Acesso em: 22 jan. 2013.BAM, A. Oracle Locks Parte 1. SQL Magazine. Dev Media, 313, 2005. Disponvelem:docs.oracle.com. Acesso em 21 jan. 2013.

Analisando a alocao dememria utilizada poruma instncia do banco

de dados Oracle, por meiode consultas estatsticasnas views do dicionrio de

dadosAnalisar a alocao de memria ocupada por uma instncia do gerenciador de

banco de dados Oracle por meio de consultas e anlise de tabelas deestatsticas localizadas no dicionrio de dados.

Introduo

Os gerenciadores de banco de dados, particularmente do Oracle, tm uma estrutura bastantecomplexa para o seu funcionamento. A estrutura de memria um componente extremamenteimportante na sua anlise da performance. Ela ter influncia em questes como segurana,concorrncia, armazenamento, integridade e principalmente de desempenho.

A estrutura abrange reas de memria compartilhada para processamentos dos dados doscomandos SQL, avaliao dos comandos SQL e tambm rea individual alocada para cada seo dousurio.

Estatsticas de desempenho do banco de dados Oracle

O gerenciador de banco de dados Oracle permite medir um grande nmero de estatsticassobre dados de sua utilizao. Desta maneira, possvel criar processos de obteno destes dados efazer comparaes ao longo do perodo para avaliar o comportamento do Oracle, e, assim, avaliar oseu desempenho de maneira pr-ativa.

Estas estatsticas tambm permitem avaliar se determinados procedimentos de ajustes foramsuficientes para melhorar ou piorar desempenho do Oracle.

Importante observar que as estatsticas a seguir mostram valores estticos em umdeterminado momento e para fazer um uso eficinte destas informaes necessrio um estudo aolongo do tempo.

Dentre as principais informaes analisadas nas estatsticas abaixo podemos destacar aquantidade de memria utilizada no data buffer cache, shared pool,etc.

As principais estatticas avaliadas neste estudo so:Buffer cache hit ratiol

Representa a porcentagem de pginas de dados que o Oracle mantm em memria, ou seja, ataxa de sucesso de busca das pginas na memria e no no disco para que o desempenho sejaainda maior. O software de busca do Oracle procura as pginas de dados a partir da memria e nodo disco.

A consulta que fornece esta porcentagem mostrada no quadro abaixo:

Taxa de sucesso do buffer cache

A taxa de sucesso do buffer cache uma medida da proporo de pedidos de dados que foramencontrados na memria do buffer cache.

Quantos maiores forem os ndices de acessos na memria, melhor ser para o desempenho doOracle, pois se os dados no esto na memria tero que ser lidos do disco e o sistema operacionalter que fazer operao de I/O em disco. Desta maneira, o aumento do tamanho do buffer irproporcionar uma taxa maior de sucesso.

O uso de memria adicional poder ser uma soluo eficiente para que mais dados fiquemarmazenados na memria, pois uma paginao da SGA se torna desastrosa para o desempenho dogerenciador.

O parmetro que dimensiona o espao do buffer cache o DB_BLOCK_BUFFERS que poder seralterado por meio dos parmetros do arquivo de inicializao do Oracle init.ora.Dictionary cache hit ratiol

Representa a porcentagem de sucesso na solicitao dos dados do dicionrio de dados que jesto disponveis na memria.

A consulta que fornece esta porcentagem mostrada no seguinte quadro:

Taxa de sucesso do cache do dicionrio

A taxa de sucesso do cache do dicionrio uma medida da proporo de pedidos deinformaes do dicionrio de dados, o conjunto de tabelas de dados e as vises que contminformaes de referncia sobre esse, suas estruturas, e seus usurios.

Quantos maiores forem os ndices de acessos no dicionrio de dados, melhor ser para odesempenho do Oracle, pois se os dados dos objetos no esto na memria, eles tero que ser lidosdo disco e o sistema operacional ter que fazer operao de I/O em disco. Desta maneira, o aumentodo tamanho do buffer ir proporcionar uma taxa maior de sucesso. Entretanto, o BD deve chegar aum "estado estacionrio", em que os dados do dicionrio mais utilizados esto no cache.

O parmetro que dimensiona o espao do buffer cache o SHARED_POOL_SIZE que poder seralterado por meio dos parmetros do arquivo de inicializao do Oracle init.ora.Library cache hit ratiol

Representa a porcentagem de sucesso na solicitao dos dados do library cache que j estodisponveis na memria.

A consulta que fornece esta porcentagem mostrada no quadro a seguir:

Taxa de sucesso da library cache

A taxa de sucesso da library cache uma medida da proporo dos comandos SQL e blocosPLSQL que j foram validados e esto na memria para serem utilizados.

Quantos maiores forem os ndices de acessos dessas informaes, melhor ser para odesempenho do Oracle, pois os dados que j esto na memria no tero que ser validadosnovamente, no precisaro ser lidos do disco e o sistema operacional no ter que fazer operao deI/O em disco. Com isso, o aumento do tamanho desta rea ir proporcionar uma taxa maior desucesso.

O parmetro que dimensiona o espao do shared pool o SHARED_POOL_RELOADS, quepoder ser alterado por meio dos parmetros do arquivo de inicializao do Oracle init.ora.Shared pool freel

Representa a porcentagem da memria da shared pool no utilizada. A consulta que forneceesta porcentagem mostrada no quadro a seguir.

Porcentagem da shared pool no utilizada.

Se uma grande proporo do pool compartilhado est sempre livre, provvel que o tamanhodo pool compartilhado possa ser reduzido. Baixos valores livres no so um motivo de preocupao,a menos que outros fatores tambm indiquem problemas, por exemplo, uma baixa taxa de pesquisano dicionrio que j est na memria ou grande proporo de recargas ocorrendo.

O parmetro que dimensiona o espao para rea de classificao o SHARED_POOL_SIZE, quepoder ser alterado por meio dos parmetros do arquivo de inicializao do Oracle init.ora.


RefernciasBAM, A. Oracle Locks Parte 1. SQL Magazine. Dev Media, 313, 2005. Disponvel em:www.devmedia.com.br. Acesso em: 22 jan. 2013.CARATTI, R. Ajustes de Desempenho em "Consultas Simples" na SQL, SQL Magazine 11, 2004.Disponvel em: www.devmedia.com.br. Acesso em: 22 jan. 2013.ORACLE. Database Performance Tuning Guide, Copyright 2000, 2011, Oracle and/or its affiliates.Disponvel em: http://docs.oracle.com. Acesso em 21 jan. 2013.PARRA, L.S. (2005). Tuning de Desempenho em Banco de Dados. Londrina-UEL UniversidadeEstadual de Londrina. Dissertao de Mestrado. Disponvel em: www2.dc.uel.br. Acesso em 21 jan.2013.SOARES, F. Conflitos de Bloqueios, Blog de Flvio Soares, 2009. Disponvel em:http://profissionaloracle.com.br. Acesso em: 22 jan. 2013.

Analisando o desempenhodos comandos SQL doBanco de Dados Oracleatravs de consultas

estatsticas nas views dodicionrio de dados

Analisar o desempenho dos comandos SQL atravs de consultas e anlise detabelas de estatsticas localizadas no dicionrio de dados. Este estudo se torna

importante dentro de processos de anlise do desempenho dos mesmos.

Introduo

Os gerenciadores de banco de dados, particularmente do Oracle, tm uma estrutura bastantecomplexa para o seu funcionamento.

O desempenho das consultas e comandos SQL um componente extremamente importante naanlise do desempenho do Oracle.

Estes comandos tm influncias em questes como segurana, concorrncia, armazenamento,integridade e, principalmente, de desempenho.

Estes comandos podero ser avaliados em questes como quantidades de leituras no data file,leituras lgicas, classificao de dados em memrias ou em discos, varreduras de tabelas em discosou em memria, etc.

Estatsticas de desempenho do banco de dados Oracle

O gerenciador de banco de dados Oracle permite medir um grande nmero de estatsticassobre dados de sua utilizao.

Desta maneira, possvel criar processos de obteno destes dados e fazer comparaes aolongo do perodo para avaliar o comportamento do Oracle e, portanto, avaliar o seu desempenho de

maneira prativa.Estas estatsticas tambm permitem avaliar se determinados procedimentos de ajustes foram

suficientes para melhorar ou piorar desempenho do Oracle. importante observar que as estatsticas a seguir mostram valores estticos em determinado

momento e, para fazer um uso eficiente destas informaes, necessrio um estudo ao longo dotempo.

Dentre as principais informaes analisadas nas estatsticas a seguir, podemos destacar aquantidade de buscas de informaes nos data files, quantidades de leituras lgicas e fsicas, etc.

Sort in Memory

Representa a porcentagem dos dados classificados na memria em relao aos discos.A consulta que fornece esta porcentagem mostrada no quadro a seguir:

Identificar a porcentagem de dados classificados na memriaem relao aos discos.


Porcentagem de dados classificados na memria.

Esta uma proporo dos dados, cuja classificao ocorre dentro da memria em vez de nodisco, sendo que quando a classificao feita no disco, o gerenciador faz uso de uma tabelatemporria.

O tamanho mximo do tipo da rea na memria que ir ocorrer a classificao definido pelotamanho da rea de classificao, que est dentro da PGA utilizada.

Cada processo da Oracle que ir classificar, ir alocar essa quantidade de memria, emborano seja necessrio tudo isso. O uso de memria para esse fim reduz a disponibilidade da SGA.

O parmetro que dimensiona o espao para rea de classificao o parmetroSORT_AREA_SIZE, que poder ser alterado atravs dos parmetros do arquivo de inicializao doOracle init.ora.

Short/Total Table Scans

Representa a porcentagem de pesquisa fazendo varredura em tabelas pequenas em relao aototal das tabelas.

A consulta que fornece esta porcentagem mostrada no quadro a seguir:

Identificar a porcentagem de pesquisas em tabelaspequenas em relao ao total de tabelas, pois quanto maiormelhor a performance do banco


Porcentagem de pesquisa em tabelas curtas em relao ao total de tabelas.

Esta a proporo de varreduras de tabelas pequenas que est ocorrendo em relao ao totalde tabelas. Tabelas pequenas podem ser pesquisadas na sua totalidade pelo Oracle quando este mais rpido do que usando um ndice.

Varreduras de tabelas grandes geralmente so ruins para o desempenho do ambiente.

Levantamento das cinco instrues mais frequentementeutilizadas

Representa o levantamento das cinco instrues mais utilizadas na instncia.A consulta que fornece este levantamento mostrada no quadro a seguir:

Identificar as cinco instrues SQL mais utilizadas noambiente e posteriormente fazer uma anlise dodesempenho delas.


Levantamento das cinco instrues mais utilizadas.

Este levantamento se torna importante para a avaliao do desempenho do ambiente, pois seestes comandos so muito frequentemente utilizados, devem ser avaliados nas questes dedesempenho, como varredura em tabelas, utilizao ou no de um ndice, quantidade de linhascarregadas na memria e tambm o custo definido pelo otimizador do Oracle.

Levantamento das cinco instrues que exigem mais leiturasde discos quando so solicitadas a sua execuo pelasaplicaes dos usurios

Representa o levantamento das cinco instrues que mais fazem leituras em discos quando soutilizadas pelas aplicaes dos usurios.

A consulta que fornece este levantamento mostrada no quadro a seguir:

Identificar as cinco instrues SQL que mais utilizam leiturasem discos para fazer uma anlise das necessidades destasleituras.


Levantamento das cinco instrues SQL que mais utilizam leituras de discos.

Este levantamento se torna importante para a avaliao do desempenho do ambiente, poiscomo elas faro muitas leituras em discos, naturalmente isto ir afetar o desempenho do ambiente.

Dever ser avaliada, nestes comandos, a quantidade de linhas que eles esto processando everificar se realmente esta quantidade necessria, se pode ser reduzida esta quantidade, pois,quanto mais linhas o comando processar, mais leituras em discos ele far.

Levantamento das cinco instrues que exigem mais leituras

lgicas

Representa o levantamento das cinco instrues que mais fazem leituras lgicas no buffer dememria.

A consulta que fornece este levantamento mostrada no quadro a seguir:

Identificar as cinco instrues SQL que mais utilizam leiturasLgicas para fazer uma anlise das necessidades destasleituras.


Levantamento das cinco instrues SQL que mais utilizam leituras lgicas.

Este levantamento se torna importante para a avaliao do desempenho do ambiente, poisquanto mais leituras lgicas o comando tiver que fazer na aplicao, mais demorado ser o tempode concluso, e pior ser a performance da aplicao e do ambiente.

Dever ser avaliada nestes comandos se a quantidade de leituras lgicas que esto sendofeitas na atividade realmente necessria ou se pode ser reduzida.


RefernciasBOSCATTO, R.; DAMINELLO, M.R. Instituto municipal ensino superior de So Caetano do Sul, 1999.BRYLA, B.; Loney, K. Oracle Data Base 10g manual do DBA. So Paulo: Campus, 2005.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.MORELLI, Eduardo Terra. Oracle 9i Fundamental: SQL, PL/SQL e Administrao. So Paulo: rica,2012.

NIEMIEC, Richard J. Oracle Database 10g performance tuning tips & techniques. New York:McGraw-Hill, 2007.PATTERSON, D. A; Gibson, G; Katz, R.H; A case for redundant arrays of inexpensive disks (RAID),1988.SILVA, Robson S. Oracle Database 10g Express Edition. So Paulo: rica, 2007.BAM, A. Oracle Locks Parte 1. SQL Magazine. Dev Media, 313, 2005. Disponvel em:www.devmedia.com.br. Acesso em: 22 jan. 2013.CARATTI, R. Ajustes de Desempenho em "Consultas Simples" na SQL, SQL Magazine 11, 2004.Disponvel em: www.devmedia.com.br. Acesso em: 22 jan. 2013.PARRA, L.S. (2005). Tuning de Desempenho em Banco de Dados. Londrina-UEL UniversidadeEstadual de Londrina. Dissertao de Mestrado. Disponvel em: www2.dc.uel.br . Acesso em 21jan. 2013.SOARES, F. Conflitos de Bloqueios, Blog de Flvio Soares, 2009. Disponvel em:profissionaloracle.com.br. Acesso em: 22 jan. 2013.______. Tamanho Ideal para Shared Pool, Blog de Flvio Soares, 2010. Disponvel em:profissionaloracle.com.br. Acesso em: 22 jan. 2013.

Conceitos de ndices e osseus impactos no

desempenho do OracleApresentar uma viso detalhada dos conceitos e funcionamentos dos ndicesno gerenciador de banco de dados Oracle, pois tm uma influncia decisiva na

performance do banco e do ambiente.

Introduo

Os gerenciadores de banco de dados, particularmente do Oracle, tm uma estrutura bastantecomplexa para o seu funcionamento.

Quando submetemos um comando de seleo de dados para o gerenciador (select), ele deverdefinir, atravs do otimizador, qual o melhor caminho para trazer os dados selecionados pelocomando.

Uma soluo rotineira o gerenciador fazer uma busca na tabela, realizando uma varredura,sendo isto ruim para o desempenho da aplicao e do ambiente.

Entretanto, os gerenciadores tm uma soluo mais eficiente para a busca das informaesatravs da criao de ndices, ou seja, o ndice uma tabela em que os dados esto organizados namesma ordem de pesquisa do comando SQL.

Desta maneira, o gerenciador vai direto aos dados a serem selecionados, eliminando anecessidade de varredura das tabelas, melhorando o desempenho da aplicao e do ambiente.

ndices

Conceitos Gerais

Os ndices tm como caractersticas terem os dados organizados na mesma ordem de pesquisados comandos SQL e, desta maneira, permitem o acesso direto a uma ou mais linhas de uma tabela.

A classificao dos dados nos ndices chamada de classificao lgica e est ligada snecessidades da aplicao, enquanto a classificao dos dados nas tabelas chamada declassificao fsica, ou seja, como os dados so organizados fisicamente.

Tipos de ndices

ndice de uma nica coluna So compostos de uma nica coluna como chave do ndice.lndices concatenados So compostos de duas ou mais colunas como chave do ndice, sendo que o nmerolmximo de colunas em um ndice 32 (Exemplo: estado, cidade).ndices exclusivos So ndices sem valores duplicados correspondentes na tabela principal (CNPJ), desta maneira,lcada linha do ndice dever apontar para uma nica linha da tabela principal.ndices no exclusivos Cada linha poder apontar para vrias linhas da tabela.l

ndices baseado em funes Esses ndices so criados quando temos a necessidade de usar funes nos filtroslde pesquisa, pois desta maneira ao invs do gerenciador criar a funo no momento da pesquisa mesma j esta criadapor ocasio da criao do ndice.A criao de funes no momento da pesquisa costuma degradar bastante o desempenhoda aplicao e do ambiente, principalmente se esta funo for muito utilizada pelas aplicaes.Comando SQL para acriao de um ndice baseado em funes:


Exemplo de consulta utilizando o ndice anterior:


ndices particionados e no particionadoslSo ndices utilizados por tabelas muito grandes, ou seja, podem ser definidos e propagados

para vrias tablespaces e, desta maneira, reduzir o gargalo nas pesquisas, garantindo umdesempenho melhor para a aplicao e o ambiente que dele se utiliza.

So utilizados em tabelas particionadas, garantindo uma melhor escalabilidade e capacidadede crescimento dos objetos e, tambm, um melhor gerenciamento do ambiente.

Sintaxe do comando para criao de um ndice:


No qual:PCTFREE: o espao reservado em cada bloco (em porcentagem do espao total menos olcabealho do bloco) durante a criao para acomodar novas entradas de ndice.LOGGING: especifica que a todas as operaes efetuadas no ndice sero registradas no arquivo delredo log (essa a opo default).NOLOGGING: especifica que a todas as operaes efetuadas no ndice no sero registradas nol

arquivo de redo log.NOSORT: especifica que as linhas sejam armazenadas no banco de dados em ordem crescente e,lportanto, que o servidor Oracle no precisa classificar as linhas durante a criao do ndice.

Exemplo de comando para criao de um ndice:


Consideraes sobre os ndices

Os ndices melhoram consideravelmente o desempenho das consultas SQL, ou seja, oscomandos select indo direto na informao do ndice e, desta maneira, evitando varredura nastabelas.

Por outro lado, os ndices acabam prejudicando os comandos SQL de atualiz

tuning de banco de dados

Documents