Pular para o conteúdo
  • Este tópico contém 2 respostas, 2 vozes e foi atualizado pela última vez 6 anos, 9 meses atrás por Hitotuzi.
Visualizando 3 posts - 1 até 3 (de 3 do total)
  • Autor
    Posts
  • #109246
    Hitotuzi
    Participante

      Bom dia!

      A flash recovery area estourou, fiz o procedimento abaixo para limpar no RMAN:


      CROSSCHECK ARCHIVELOG ALL;
      DELETE EXPIRED ARCHIVELOG ALL;

      Também aumentei o “db_recovery_file_dest_size”


      alter system set db_recovery_file_dest_size = xxG scope=both;

      Porém diminuiu apenas uma pequena parte, ficou 80% cheio, repeti o processo e não diminuiu mais nada. Entrei na pasta no servidor e só consta a pasta do dia atual. A quantidade dos archives não justifica esse percentual de 80%. Ou seja, parece que mesmo eu eliminando os archive s fisicamente e pelo RMAN o percentual utilizado continua o mesmo. Como faço para limpar tudo? Alguém tem uma dica?

      Desde já agradeço!

      #109247
      Avatar photoJosé Laurindo Chiappa
      Moderador

        Blz ? Então, primeira coisa Acredito que vc sabe que o espaço na recovery area é controlado pelo banco NÂO pelo sistema operacional mas sim pelo parâmetro db_recovery_file_dest_size : se vc tiver Trocentos GBs livres no filesystem onde reside a recovery area MAS o param db_recovery_file_dest_size está setado para algo MENOR, é ESSE VALOR MENOR do db_recovery_file_dest_size que o banco usará para limitar a utilização da recovery area, ok ? Então primeira coisa ASSEGURE-SE que o parâmetro está setado para um valor ADEQUADO, yes ???
        Muito bem : segunda coisa, a fra é uma área EM DISCO, que reside num filesystem (ou num disco ASM) E que está em princípio aberto para se gravar OUTRAS COISAS que não só apenas controlfiles E backups : entre outros, sob demanda PODEM ser gravados nessa mesma área de disco DUMP FILES gerados pelo datapump ou pelo export tradicional, LOG FILES e TRACE FILES diversos, DATAFILES… É uma área ABERTA em princípio , sim sim ?? Então PLEASE VERIFIQUE tanto pelo SO quanto pelo database o que está presente nessa área – pra checar no database manda um SELECT * FROM V$RECOVERY_AREA_USAGE; , e para checar no SO use as tools do seu SO : talvez du no Linux, WindirTree no Windows, o que vc tiver/puder usar….
        ==> Essa obs acima é CRÍTICA para validar o teu ‘procedimento de limpeza’ que foi ir no RMAN e pedir um DELETE EXPIRED ARCHIVELOG ALL; : OBVIAMENTE, se NÂO FOR archive teu problema NÃO VAI SERVIR DE COISA NENHUMA teu ‘procedimento’ sim sim ??? CONSULTE e DESCUBRA quais arquivos/tipos de arquivos são os ofensores principais, talvez seja OUTROS que não archives, OU talvez sejam arquivos não controlados pelo RMAN, como exports….

        Aí chegamos na terceira coisa : SE vc comprovar (com os comandos/procedimentos que indiquei) que o problema são archives sendo retidos em grande qtdade, é CLARO que quando vc faz um DELETE EXPIRED ARCHIVELOG; o RMAN *** OBVIAMENTE *** vai :

        a. respeitar a UTILIZAÇÂO de archives fora do database : entre outros, STANDBY FÍSICO usa os archives, então archives AINDA NÃO APLICADOS no standby Obviamente Não vão nunca ser marcados como EXPIRADOS enquanto o standby não os aplicar

        e

        b. respeitar a POLÍTICA DE REMOÇÂO de archives que vc tenha : se vc indicou no seu RMAN uma policy de retenção (digamos) de BACKUPED 3 TIMES, só depois que TODO E QUALQUER archive for backupeado COM SUCESSO 3 vezes é que eles vão ser marcados como EXPIRED, e só então o DELETE EXPIRED os vai remover

        e

        c. OBVIAMENTE, os archives NÂO SÃO elementos a ser considerados independentemente : a função principal deles na vida é ATUALIZAR um backup HOT de databases… Assim sendo, SE vc tem ao menos UM backup de banco que pra se recuperar precisa do SCN registrado em um dos archives esse archive VAI ser retido independente da policy….

        ========>> TUDO isso que falei está respaldado nas Docs e nas notas metalink “Rman Not Deleting Obsolete Archive Logs And Archive Log Backups” (Doc ID 282617.1), “Archivlogs Expired causes Rman-08138: Warning: Archived Log Not Deleted – Must Create More Backups” (Doc ID 1407082.1) e nos links delas…. Certifique-se que vc não está caindo nos BUGs listados em “Known RMAN – Dataguard Problems” (Doc ID 357759.1) e notas relacionadas…

        []s

        Chiappa

        #109248
        Hitotuzi
        Participante

          Obrigado pelas dicas @jlchiappa vou rever os processos e fazer as análises, valeu!

        Visualizando 3 posts - 1 até 3 (de 3 do total)
        • Você deve fazer login para responder a este tópico.
        plugins premium WordPress