tag:blogger.com,1999:blog-5738872960415708519.post3941964001782817503..comments2024-01-29T06:38:46.574-03:00Comments on Blog do DBA/Instrutor Fábio Prado: Palestra "Top 5 Tuning for Oracle and SQL Server"Fábio Pradohttp://www.blogger.com/profile/05498446367081034213noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-5738872960415708519.post-83137147730449636882017-05-21T12:54:45.773-03:002017-05-21T12:54:45.773-03:00Veja o post: http://www.fabioprado.net/2017/05/com...Veja o post: http://www.fabioprado.net/2017/05/como-desfragmentar-tabelas-no-oracle.htmlFábio Pradohttps://www.blogger.com/profile/05498446367081034213noreply@blogger.comtag:blogger.com,1999:blog-5738872960415708519.post-16112323871902584042017-05-10T19:09:32.305-03:002017-05-10T19:09:32.305-03:00Adriano, infelizmente o tempo foi curto para falar...Adriano, infelizmente o tempo foi curto para falar sobre tudo, mas vou falar aqui algumas coisinhas mais e já estou preparando um artigo novo para publicar aqui no blog até o final do mês. O SHRINK é o método que causa o menor impacto possível na Produção, por isso recomendo ele com a menor qtde. de cautelas, porém ele tem algumas restrições, e de todos os métodos possíveis ele é o menos "eficiente" para eliminar LEMs (linhas encadeadas e migradas), ou seja, se existirem por exemplo muitas LEMs na tabela, normalmente ele elimina poucas delas. Se existirem apenas blocos vazios na tabela, dentro disso que normalmente chama-se "fragmentação", aí sim ele pode ser mais eficiente e menos traumático que qq outro método. É importante verificar se nessa tabela existem LEMs. Um modo fácil é executar "ANALYZE TABLE schema.tabela COMPUTE STATISTICS" e depois consultar na dba_tables a linha correspondente a essa tabela e o valor de CHAIN_CNT. Se for baixo, execute sem dó o SHRINK, se for alto eu recomendaria usar o pacote DBMS_REDEFINITION ou SHRINK + procedimentos do script utlchain.sql (que eu nem tinha comentado na palestra) para fazer a desfragmentação. Não sei há alguma limitação para usar o DBMS_REDEFINITION na versão Standard do Oracle. Vou pesquisar mais sobre isso e em breve publicarei um novo artigo aqui no blog, ok?<br /><br />Quanto ao espaço de UNDO que será consumido pelo SHRINK, isso depende muito do estado da tabela, e é proporcional à qtde. de blocos vazios existentes. Se houver poucos blocos vazios haverá poucas "movimentações internas" (deletes + inserts), e desse modo, será gerado poucos segmentos de UNDO, ok?Fábio Pradohttps://www.blogger.com/profile/05498446367081034213noreply@blogger.comtag:blogger.com,1999:blog-5738872960415708519.post-71982638523035546992017-05-10T08:39:19.025-03:002017-05-10T08:39:19.025-03:00Foi o que eu imaginei quando voce disse na palestr...Foi o que eu imaginei quando voce disse na palestra que a melhor técnica sem duvida seria o SHRINK. Pois então, eu tenho 15G de UNDO , porem eu tenho 220G disponível em um disco onde nao está a UNDO, mas certamente eu poderia apontar um arquivo dela para lá e depois que realizar essa desfragmentação, eu deletaria o arquivo e voltaria, a duvida é se, 200G seriam o suficiente para desfragmentar uma tabela de 300G , a proporção seria 1/1 ?Adriano Heissighttps://www.blogger.com/profile/12182054755942411550noreply@blogger.comtag:blogger.com,1999:blog-5738872960415708519.post-78024964679048695542017-05-09T08:52:20.823-03:002017-05-09T08:52:20.823-03:00Adriano, primeiramente agradeço pelo feedback! Rea...Adriano, primeiramente agradeço pelo feedback! Realmente o tempo foi curto nessa palestra e não deu tempo para falar tudo o que gostaríamos de ter falado. <br /><br />Quanto ao desfragmentar a sua tabela de 300Gb, sugiro sim usar o SHRINK ou DBMS_REDEFINITION. Eu particularmente gosto de usar o SHRINK por ser mais simples de usar, mas não vai ter como fugir da geração de dados de UNDO, visto que o SHRINK internamente faz DELETEs + INSERTs. Se você tem espaço para o UNDO crescer não vejo problemas em utilizá-lo. E vc não tem espaço para o UNDO crescer acredito então que qq outra técnica seria pior que o SHRINK, pois para fazer por exemplo um ALTER TABLE MOVE para outro tablespace você também precisaria de espaço extra para levar os dados para um lugar temporário.<br /><br />Qual é o tamanho atual do seu UNDO e quanto você tem de espaço para ele crescer? <br /><br />[]sFábio Pradohttps://www.blogger.com/profile/05498446367081034213noreply@blogger.comtag:blogger.com,1999:blog-5738872960415708519.post-65985688221690127062017-05-08T14:10:41.173-03:002017-05-08T14:10:41.173-03:00Fabio primeiramente gostaria de parabenizar você e...Fabio primeiramente gostaria de parabenizar você e todos os organizadores do evento DBA BRASIL 2.0 e dizer que foi excelente, conheci pessoas novas, pude conversar com os patrocinadores que estavam lá os quais me fizeram enxergar algumas novidades muito boas.<br />Na sua palestra eu gostaria de ter feito uma pergunta, mas estava bem corrido e acabei não fazendo, portanto, vou fazer ela aqui (rs) a minha dúvida é a seguinte, possuo uma tabela que ela sozinha tem 300 gigas e tenho plena certeza que ela está mega fragmentada, pensei por diversas vezes em como desfragmentar ela ONLINE e não consegui chegar numa conclusão óbvia. Usando o SHRINK percebi que ele vai aos poucos aumentando a minha UNDO e não saberia mensurar quanto ele vai acabar usando dela (mas ainda acho ele a melhor alternativa, desde que eu saiba quanto vou consumir da UNDO).<br /> <br />Se eu fizer um EXPORT - TRUNCATE - IMPORT , acho que vai levar muito tempo (deixando o banco nesse caso offline).<br /> <br />Você consegue enxergar com a sua experiência , uma forma mais adequada de eu conseguir obter êxito nessa tarefa ? Ah ta, a minha tabela é exclusiva da minha tablespace e fica em um disco diferente dos meus DBFS e IDXS. <br />Outra coisa o oracle é o SE... (pra ajudar..rs).<br /><br />Valeu!!!Adriano Heissighttps://www.blogger.com/profile/12182054755942411550noreply@blogger.com