Grande Chiappa, tudo certinho ? Então...obrigado pelas explicações...realmente é dificil procurando na web, reunir desta maneira informações sobre este assunto...
Mas, vamos as dúvidas: Quando falei de fragmentação, estava me referindo ao HWM alto e principalmente, sobre as recomendações do advisor de segmento, onde temos as informações sobre os objetos (tabelas e indices), relativo ao espaço alocado e o espaço que poderia ser liberado, se ações como SHRINK ou MOVE fossem tomadas (levando em consideração que o advisor somente sugere SHRINK). Normalmente o que faço é verificar as recomendações do advisor, criar alguns scripts a partir destas sugestões e executa-las nos finais de semana. Após estas execuções sempre obtive uma considerável melhoras nas operações das aplicações, principalmente relacionado aos FTS. Uma outra comprovação seria relativo ao backup / restore que é realizado. No meu ambiente de produção trabalho com um RAC (11.1.0.6) e diariamente, gero alguns backups logicos (via datapump) para restaura-los no meu ambiente de desenvolvimento e HML. Logo após a importação todas as aplicações ficam extremamente lentas. Solução ? Realizar a mesma atividade feita em produção, gerar os scripts tendo como base o advisor de sgmentos, realizar o MOVE das tabelas...tudo volta a funcionar com 100% de velocidade... Acho que entendi o X da questão... Um exemplo: CREATE TABLESPACE XXX DATAFILE '+DATA' SIZE 5M AUTOEXTEND ON NEXT 50K MAXSIZE 31G Este comando por exemplo poderia ser o "responsavel" pelo problema no que vc escreveu para o 2 topico e o HWM...se todas as tablespaces forem trabalhadas da mesma maneira...sem levar em consideração o tamanho das tabelas armazenadas, pctfree, used e etc... Pensando no que vc disse, talvez se utilizasse LMT AUTOALLOCATE ou UNIFORM SIZE, teria a mesma quantidade de extends sendo alocados e trabalhando tambem na HWM --- Em oracle_br@yahoogrupos.com.br, José Laurindo <jlchiappa@...> escreveu > > Colega, antes de entramos na questão, a pergunta que não quer (e não pode se) > calar : vc ** TEM ** uma evidência Exata, Reproduzível e Significativa de > performance diferente nos seus SQLs principais após a recriação das tais > tabelas , OU vc está se dando ao trabalho só porque viu em algum lugar que > isso deve ser feito ????? Pois é um trabalho Gigantesco em bases maiores/mais > exigentes, se vc não mede o retorno do investimento, vc ** Não ** tem como o > justificar... Essa evidência não precisa ser nada tão sofisticado quanto um > trace, pode ser simplesmente diminuição do número de I/Os, do tempo de CPU ou > do tempo gasto na V$SQL para o mesmo SQL, pode um plano diferente antes & > depois do rebuild (plano real, capturado/exibido com o > dbms_xplan.display_cursor), pode ser uma diferença apreciável pra menos nas > v$ de waits e estatísticas da sessão, qquer coisa assim, reproduzível e > tecnicamente assertiva... > > Muito bem : SUPONDO que vc tem a evidência, o primeiro Fato a notar é que > há/podem haver ** DIVERSAS ** issues de I/O ao se acessar tabelas no RDBMS > Oracle, e SHRINKs / REBUILDs (além do COALESCE e das alterações de > parâmetros de storage, tipo pctfree/pctused, que vc não cita mas deveria) > atacam ** DIFERENTES ** pontos : vc Necessariamente TEM QUE descobrir qual é > o ponto que está causando o problema que vc evidenciou, okdoc ? Chamar tudo > de "FRAGMENTAÇÃO" é por demais genérico... Isso serve pra quando vc está > passando um conceito de modo superficial (eu mesmo confesso, mais de uma vez > numa reunião com analistas tasquei o termo "fragmentação" pra eles poderem > entender de modo geral a questão), mas aqui nós estamos entre profissionais > de banco de dados, vamos então definir com exatidão o que pode ocorrer E o > que vc faz pra cada caso... > Vamos lá : > > 1. espaço livre não usado por diferença de tamanho de extents : isso ocorre > quando a tablespace possui extents livres de tamanhos totalmente diferentes e > não-múltiplos entre si E diferentes do extent requerido na tabela - digamos, > a tablespace tem livres vários extents de 19 Kb, de 45 Kb, e de 1,5 Mb, > digamos, mas a tabela pede pra alocar extents de 1 Mb : evidentemente não dá > pra quebrar/subdividir extents, então o RDBMS ** vai ** formatar e alocar um > extent novo quando precisar crescer, DESPREZANDO os que já existem, causando > desperdício de espaço e (em caso de Full Table Scan ou similares) causando > extents quase sem dados , ou mesmo sem dados, serem lidos... Esta issue é a > que normalmente é chamada de fragmentação nas conversas de usuário e em > livros genéricos... > Solução : usar tablespace LMT, nas tablespaces LMT vc *** Obrigatoriamente > ** ou tem extents iguais (se vc optar por indicar o tamanho, com o UNIFORM > SIZE) ou tem extents de poucos tamanhos e MÚLTIPLOS entre si (se optar por > AUTOALLOCATE), com tamanhos automaticamente criados e tipo de 16 Kb, 32 Kb, > 64 Kb, 1 Mb (aonde os menores PODEM ser coalescidos pra se criar os > maiores), então com isso vc torna IMPOSSÍVEL o problema ocorrer ... > > 2. tamanho de extent muito menor do que o máximo I/O possível no sistema > operacional : isso é problema quando vc vai fazer SCANs (Full Table Scan, > principalmente) , caso onde o RDBMS vai ler não blocos, mas extents inteiros > : se vc tiver uma tabela de 100 Mb, o máximo de I/O que o SO pode fazer é 1 > Mb, digamos, MAS os seus extents são todos de 64 Kb, no caso de FTS ao invés > do SO fazer 100 I/OS de 1 Mb, ele VAI TER que fazer 1600 (se minhas contas > estão corretas :) I/Os de 64 Kb ..... Não é uma issue frequente mas pode > ocorrer... > Solução : além de usar LMT, ou use LMTs AUTOALLOCATE (nessas tablespaces o > RDBMS segue um algoritmo que força o crescimento do extent size cfrme a > tabela cresce , até chegar no 1 Mb que é o máximo de I/O típico na maioria > dos SOs) , ou se for usar UNIFORM SIZE tenha CERTEZA de como serão usados e > até onde vão crescer os objetos que vc botar em tablespaces LMT UNIFORM SIZE, > os maiores/com mais tendência a crescer (e portanto a pedir por FTS) ** > deveriam ** ser colocados em LMT uniform de 1 Mb, OU múltiplos de 1 Mb ... > > 3. quantidade anormalmente grande de extents : isso era uma preocupação com > as tablespaces antigas, as DMT (gerenciadas por dicionário), pois nelas > haviam tabelas internas (sys.uet$, sys.fet$, e outras) que continham os > extents livres & usados, aí a cada acesso a uma tabela de usuário as tabelas > internas tinham que ser acessadas, a cada alteração de dados em tabelas de > usuários o novo consumo de extents tinha que ser inserido nas tabelas > internas, era bem fácil vc ter problemas de concorrência interna com isso > .... as tablespaces LMT usam um bitmap interno pra se controlar, é mais > rápido e menos propenso à concorrência... > Solução : usar tablespaces LMT ** E ** se atentar ao item 2. acima : já > que os objetos maiores são mais propensos a FTS, se vc tem um extent size bem > ajustado (ou usa AUTOALLOCATE), o extent maior vai naturalmente levar á uma > quantidade menor de extents nos objetos grandes , normalmente só isso já > deixa a quantidade de extents num nível gerenciável pelos bitmaps... > > 4. high-water mark mais alto do que o necessário : ao se fazer um INSERT /*+ > APPEND */ , o APPEND significa que o RDBMS ** não ** vai reaproveitar os > extents livres que já estejam reservados pra tabela, e sim vai requisitar > novos extents da lista de espaço livre, vai usá-los pra guardar os dados e > vai adicionar (APPEND) esses extents ao "final" da tabela... Imagine que vc, > após vários DELETEs (vide item 5., abaixo) vc tem a tabela fisicamente em > disco tipo abaixo (X são blocos com dados, e os pontos são blocos vazios) : > > XXXXXXXXXXXXX > XX........................... > XXXXX................... > ............................... > ............................... > X > > o APPEND necessariamente vai criar novos extents/blocos, desprezando os que > já estão livres, tipo : > > XXXXXXXXXXXXX > XX........................... > XXXXX................... > ............................... > ............................... > XXXXXXXXXXXX > XXXXXXXXXXXX > XXXXXXXXXXXX > > Isso é problema ?? DEPENDE : se após esse APPEND, vc sabe que no futuro breve > vão ser feitos INSERTs normais (vide item 5. abaixo) os espaços livres VÂO > SIM ser re-usados, no problema... > A Solução , se não vão haver INSERTs normais depois do APPEND , E vc > comprovou que esses white-spaces tão interferindo (nos seus FTSs, > provavelmente, ou no seu consumo de disco), pode ser : > > a. pedir um TRUNCATE ao invés de DELETE , antes da carga (APPEND > tipicamente são feitos em carga massiva de dados) > > ou > > b. liberação física dos extents : isso pode ser feito com SHRINK (** se ** > o ROW MOVIMENT está habilitado na tabela, e as demais exigências estão > atendidads, checar manual de Concepts no item "Space Reclamation" , OU com o > rebuild mesmo .... A diferença desses dois é que, cfrme o manual cita, o > SHRINK abaixa o HWM liberando os extents que estão entre o último > efetivamente usado e o HWM : os eventuais vazios "no meio" da tabela não > necessariamente serão reusados e irão pro free space, a única maneira de vc > re-aproveitar esse espaço se vc sabe que não haverão mais INSERTs normais) é > mesmo re-alocar os blocos, via REBUILD.... > > =====>> ESSA é sua resposta parcial sobre SHRINK x REBUILD, ie, DEPNDE DO > QUE VC QUER : se vc quer baixar a HWM ou quer efetivamente reusar os extents > no "meio" da tabela, vc TEM QUE analisar aí o seu caso das suas tabelas pra > poder entender / descobrir qual o comando que se ajusta melhor ao seu caso... > > > 5. white-space / espaço não usado após DELETEs : esta issue é ao que > normalmente a Oracle se refere como "fragmentação" - sim, mesmo a Oracle é > culpada de super-simplificar e chamar de fragmentação sem explicar o que é... > Isto tem que ser bem definido, é um dos pontos aonde vc mais besteira vê > por aí - o que ocorre é que, após deleções de dados, os blocos/extents que > continham dados do objeto que sofreu o DELETE ** vão ** continuar marcados > como reservados/pertencentes ao objeto : isso é pra Acelerar os futuros > INSERTs, com isso ao invés do RDBMS ter que formatar blocos novos (o que > teria que fazer se os blocos que sofreram DELETE fossem liberados pro sistema > após o DELETE) , o INSERT reusa simplesmente o espaço que o DELETE liberou... > Isso é CRÍTICO pra entendermos : se a tabela X sofreu DELETEs e algum > espaço está disponível pra ela, ** NECESSARIAMENTE ** e Obrigatoriamente os > próximos INSERTs vão sim reusar esse espaço disponível, esse espaço ***** NÂO > **** está morto, ele VAI SIM ser reusado, okdoc ? A besteira principal que vc > vai ouvir é que após DELETEs o espaço não pode ser reusado, fica 'perdido' e > isso é um tipo de "fragmentação".... > Muito bem, mas e nos casos aonde o objeto/segmento sofreu DELETEs > significativos , e (por regra de negócio) vc SABE que nunca mais serão > inseridos novos dados - tipo, é uma tabela particionada que só contém pos > dados de Outubro, e o mês de outubro acabou ? Aí sim, esse Sim é um caso onde > vc sabe o que o RDBMS Oracle não sabe, vc tem certeza que aquele espaço > reservado mas vazio não vai ser nunca reusado pelos novos INSERTs por força > de uma regra lógica externa ao banco, aí sim se vc quiser/precisarliberar > esse espaço vc TEM que tomar uma ação.... Notar que, além de desperdício de > espaço em disco, esse white-space VAI influenciar em FTSs ... > Solução : as mesmas do item acima , que (Novamente) só podem;devem ser > aplicadas SE e APENAS SE vc realmente sabe que não haverão INSERTs reusando > esse espaço em branco... > > 6. white-space/espaço reservado/não usado em Blocos, causando algum tipo de > migração de dados : o espaço nos blocos normalmente não é usado do começo ao > fim, há algum espaço reservado para futuros UPDATEs : caso esse espaço seja > muito grande, na hora dum INSERT de uma linha um tantinho maior não haverá > espaço pra gravar no bloco, a linha será "continuada" em um novo bloco, aí > eventuais leituras dessa linha passam a exigir mais de um acesso à blocos - > multiplique isso por milhões de linhas, E tenha uma Aplicação vagal que faz > leitura de muitos dados row by row (via CURSOR, provavelmente) pra processar, > e vc terá um grande problema em mãos... > Solução : CONHECER a utilização que a tabela terá e especificar > PCTFREE/PCTUSEd adequados, ou (em alguns casos, se viável) tentar usar ASSM... > > > Em termos gerais é isso , minha Recomendação é lapidar : > > R1 : obtenha Comprovação de que há diferença Apreciável quando vc faz o > REBUILD > > R2 : antes de pensar em automatizar, descubra Exatamente qual a issue que > está "pegando", já que cfrme eu disse em alguns casos há parâmetro/ação que > ELIMINA o problema, ao invés de ficar tolamente e cegamente fazendo rebuilds > e rebuilds sem pensar > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, "candiurudba" <candiurudba@> escreveu > > > > Bom dia colegas, > > > > Estou pensando em automatizar o processo de desfragmentação de tabelas do > > meu RAC. > > > > O volume de transações aumentou consideravelmente e por este motivo, todos > > os finais de semana estou tendo que executar manualmente procedimentos para > > desfragmentar as tabelas, o que tem tomado muito do meu tempo. > > > > Alguêm teria alguma forma de uma verificação mais simples destas > > fragmentação para que eu possa gerar um script agendado no CRON ? > > > > Uma outra dúvida é quanto os procedimentos para reorganização das tabelas > > fragmentadas. Sempre utilizei o comando MOVE com o rebuild dos indices e > > todos sabemos que ele (muitas vezes) é extremamente consumidor (CPU), > > gerando problemas tambem nos indices, sendo necessário o rebuild dos mesmos. > > > > Andei lendo alguma coisa sobre SHRINK SPACE COMPACT para reorganização das > > linhas nas tabelas, eliminando a fragmentação existente e depois SHRINK > > SPACE para mexer na HWM. Teoricamente estes comandos em conjunto, deixam as > > tabelas em funcionamento para operação DML, não consomem tanto recursos de > > maquina, alem de não deixarem os indices como UNUSABLE. Seria isto mesmo ? > > >
