Olá pessoal,
Estou compartilhando neste post o arquivo da apresentação que eu e o "incansável" Fábio Cotrim fizemos ontem (6/5/17), no DBA BRASIL 2.0, com o tema "Top 5 Tuning for Oracle and SQL Server".
Infelizmente o tempo foi curto para falar tudo o que gostaríamos de ter falado, porém, você poderá ver ou baixar o arquivo da apresentação clicando na imagem abaixo, e se tiver qualquer dúvida sobre o assunto, é só deixar um comentário neste post que eu (se for sobre Oracle) ou o Fábio Cotrim (se for sobre SQL Server) iremos respondê-la o mais breve possível!
A palestra também foi gravada, parcialmente e voluntariamente, por um amigo. Infelizmente ele não conseguiu gravar a palestra inteira porque a bateria da câmera que ele estava utilizando acabou aproximadamente 20 min. antes da finalização dela. Veja abaixo os vídeos:
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.
ResponderExcluirNa 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).
Se eu fizer um EXPORT - TRUNCATE - IMPORT , acho que vai levar muito tempo (deixando o banco nesse caso offline).
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.
Outra coisa o oracle é o SE... (pra ajudar..rs).
Valeu!!!
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.
ExcluirQuanto 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.
Qual é o tamanho atual do seu UNDO e quanto você tem de espaço para ele crescer?
[]s
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 ?
ExcluirAdriano, 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?
ExcluirQuanto 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?
Veja o post: http://www.fabioprado.net/2017/05/como-desfragmentar-tabelas-no-oracle.html
Excluir