Obrigado pela explicação jlchiappa. Valeu....
----- Mensagem original ---- De: jlchiappa <[EMAIL PROTECTED]> Para: oracle_br@yahoogrupos.com.br Enviadas: Quarta-feira, 25 de Outubro de 2006 13:41:02 Assunto: [oracle_br] Re: Update Monstro Por partes : >> 1 - Como eu faço para limpar a area de Redolog ... essa frase NÂO faz o menor sentido, ao contrário do que ocorre em alguns outros bancos, no Oracle redos NÃO SÃO coisas temporárias que vc pode imediatamente esvazliar/apagar/dropar, eles PODEM a qquer momento conter dados REAIS e COMITADOS ainda não presentes nos datafiles. É uma questão de estrutura interna do bd Oracle. Se vc estiver REALMENTE, TOTALMENTE, ABSOLUTAMENTE desesperado por espaço em disco, o que vc PODE fazer, em tese, é criar NOVOS log files menores com comandos alter database add logfile nnn , pedir por banco fechar (e se em modo archive archivar) os anteriores com switch logfile, e aí sim dropar os log files grandes via alter database drop logfile . Fique ciente que isso NÂO É recomendado nem recomendável, pois via de regra vc VAI PAGAR um alto preço em performance fazendo isso, já que com log files menores eles VÂO encher mais rapidamente, PORTANTO o proceso archivador de logs vai ser acionado mais frequentemente, ALTAS CHANCES dele conflitar com outrs I/Os.... Já archived logs, por sua própria definição (ie, são CÓPIAS dos log files que encheram), são um PASSADO, portanto NÂO SÃO obrigatórios de se manter online enquanto não tiver que fazer recuperação de banco, ok ? Assim, o procedimento é SIMPELSMENTE se fazer um backup deles (em fita, em DVD, naonde vc puder), pra quando no futuro vc vir a precisar, e feito isso vc APAGA eles do disco com o comando de APAGAR ARQUIVOS do seu Sistema Operacional, simples... >> area que eu possa limpar ??? Claro : primeira coisa, levantar nas tablespaces de DADOS de usuários os objetos que mais estão ocupando espaço, e checar com o usuário o que se faz com eles : certamente ALGUNS devem poder ser compactados, alguns talvez possam sofrer DELETEs ou DROPs... Segunda coisa, o DBA desse banco terá que checar as condições de STORAGE dos objetos de usuários : há extents iniciais muitíssimo maiores do que o necessário ? Há datafiles LMT criados com desperdício de espaço (ie, de tamanho não-múltiplo do extent size da tablespace mais 64 Kb) ?? Há objetos que só sofrem INSERTs (tais como tabs de log/históricos) e (ultra-erradamente!!) NÃO estão criadas com PCTUSED o mais alto possível ? Há fragmentação, se for usada tablespace DMT ? ==>> SÓ com essas coisas acima, já vi banco que estava sofrendo de falta de espaço crônica do "nada" liberar razoável espaço livre, PRINCIPALMENTE em DWs/batches... Nem citarei aqui os schemas de exemplos do bd Oracle, já que LOGICAMENTE se há espaço limitado a PRIMEIRA coisa que o responsável fez foi dropar esses caras, né :) >> 2 - Como fazer este update sem armazenar nada no Redolog e Archive ou qualquer outra area de Rolback ??? Eu já disse em msg anterior, TORNO A DIZER : redo log (e archived logs, que DECORREM da geração de logs) e rollback/undo são INESCAPÁVEIS, absolutamente NÃO TEM COMO vc não os gerar, a estrutura interna do funcionamento do bd Oracle assim o exige - repita isso ATÉ acreditar, pois essa é a verdade nua e crua.... O que é possível, como já tinha dito em outras msg e repito, é DIMINUIR o redo e o undo/rollback, mas APENAS EM ALGUNS POUCOS CASOS, como por exemplo INSERTs de ** várias linhas ** simultâneas , feito em modo APPEND feitos em objetos NOLOGGINGs, sim ? E para que a diminuição seja palpável, os ÌNDICES e as CONSTRAINTS da tabela sendo inserida em append-mode necessariamente TEM QUE estarem desabilitados/desligados, confere ??? UPDATE *** NÂO TEM COMO *** não gerar redo/undo, mas se for o caso vc PODE transformar o seu UPDATE num INSERT, + ou - assim : faz insert /*+ APPEND */ tabelatemporária (select que traz os dados que vc quer alterar já alterados), faz TRUNCATE na tabela real, faz INSERT /+ APPEND */ tabelareal (select from tabelatemp), ou variações da técnica, é EXATAMENTE ISSO que é discutido em http://asktom.oracle.com/pls/ask/f? p=4950:8:::::F4950_P8_DISPLAYID:6407993912330 , é uma técnica absolutamente COMUM em ambientes Oracle de grandes volumes. Evidentemente, já que uma operação do tipo LOGICAMENTE é algo pontual, certamente será feita fora do horário de pico, quando POUQUÍSSIMAS coisas (ou mesmo NADA) estará rodando no bd Oracle, assim nada impede de vc "alocar" o máximo do hardware para a tarefa, já que a operação estará "sozinha" na máquina - via ALTER SESSION, usar Parallel Queries, Parallel DMLs, deixar sort_area_size e hash_area_size lááááá no topo (se preciso mudando workarea_size_policy=MANUAL), essas coisas serão os seus aliados nisso... Da mesma forma, já que vc estará sozinho, NÂO FAZ SENTIDO checar as constraints, então uma vez re-construída a tabela, feito o rebuild NOLOGGING e PARALLEL dos índices, vc ** NÂO VALIDA ** as constraints que foram desabilitadas, pois NINGUÉM alterou os dados, vc só dá um ALTER TABLE nnn ENABLE CONSTRAINT xxx NOVALIDATE, o que é quase instantâneo... []s Chiappa =========================================================== Participe do ENPO - Encontro de Profissionais Oracle 2006 ! Informações e inscrições em www.enpo-br.org José Laurindo Chiappa, Palestrante ENPO-2006 =========================================================== _______________________________________________________ Você quer respostas para suas perguntas? Ou você sabe muito e quer compartilhar seu conhecimento? Experimente o Yahoo! Respostas ! http://br.answers.yahoo.com/ [As partes desta mensagem que não continham texto foram removidas] Vem aí: ENPO-BR 2006 - Encontro Nacional de Profissionais Oracle VISITE: http://www.enpo-br.org/ - Dia 11/11 "Vagas Limitadas" ________________________________________________________________ Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine -------------------------------------------------------------------------------------------------------------------------- Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -------------------------------------------------------------------------------------------------------------------------- O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: http://www.oraclebr.com.br/ ------------------------------------------------------------------------------------------------------------------------ Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
