Cenário:Primary database 11.2.0.4Standby físico (active dataguard) 11.2.0.4 Possuo um active dataguard (um standby fisico aberto somente leitura aplicando os archives) **aonde são realizados os backups do rman**. OU seja, nenhum backup do rman é feito na produção, todos os backups são realizados no standby. ==> O meu problema É: A política de deleção de archive automática *não funciona no primary database*, porém "funciona" no standby database, isso faz com que a área de archive esteja estourando com uma frequencia alta no primary database e tenha que ter interferência manual do DBA. Esse problema está dificultando nosso trabalho, pois a média de geração de redo por dia fica em torno de 60Gb.
Segue: ==> PRIMARY DATABASE política de deleção de archive -> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY; log_archive_dest_2 string service=prod_st obs: só existe apenas esse standby na configuração. ==> STANDBY DATABASE CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default No standby não possui política de deleção do archives no RMAN, porém o script de backup que é executado no standby possui o "delete input" após os backups dos archives. -- TROUBLESHOOTING Realizando uma consulta no stanby *PENSEI* que o sincronismo estava com problema, pelo resultado da consulta abaixo: -- Ultimo archive aplicadoSELECT 'Last applied : ' Logs, To_char(next_time, 'DD-MON-YY:HH24:MI:SS') TimeFROM v$archived_logWHERE sequence# = (SELECT Max(sequence#) FROM v$archived_log WHERE applied = 'YES')UNIONSELECT 'Last received : ' Logs, To_char(next_time, 'DD-MON-YY:HH24:MI:SS') TimeFROM v$archived_logWHERE sequence# = (SELECT Max(sequence#) FROM v$archived_log); LOGS TIME---------------- ------------------Last applied : 19-MAR-17:01:53:24Last received : 19-MAR-17:01:59:11 Porém, no database broker ele me retorna que a configuração está OK. Criei uma tabela de teste no primary e inseri alguns registros, no standby a tabela foi criada rapidamente com os registros inseridos. Outro teste que fiz foi: Realizei um switchover no primary, verifiquei no alert do standby que estava tudo ok, como segue abaixo: Tue Mar 21 01:10:06 2017RFS[1]: Selected log 62 for thread 2 sequence 432 dbid -98229520 branch 614228627Tue Mar 21 01:10:07 2017Media Recovery Waiting for thread 2 sequence 432 (in transit)Recovery of Online Redo Log: Thread 2 Group 62 Seq 432 Reading mem 0 Mem# 0: +DATA/prod_st/onlinelog/group_62.559.923005101Tue Mar 21 01:10:17 2017RFS[1]: Selected log 63 for thread 2 sequence 433 dbid -98229520 branch 614228627Tue Mar 21 01:10:18 2017Media Recovery Waiting for thread 2 sequence 433 (in transit)Recovery of Online Redo Log: Thread 2 Group 63 Seq 433 Reading mem 0 Mem# 0: +DATA/prod_st/onlinelog/group_63.560.923005107Tue Mar 21 01:10:21 2017Archived Log entry 40032 added for thread 2 sequence 432 ID 0x18e2c75 dest 1: Chegando a conclusão que o sincronismo está OK. Uma coisa importante que verifiquei no *PRIMARY* foi que, não existia nenhuma FAST RECOVERY AREA configurada, e os archives são gerados em um disco no ASM chamado FRA. Logo pensei, a política de deleção automática de archives pelo RMAN não está funcionando por causa que não existe uma FAST RECOVERY AREA configurada. Logo configurei os parametros db_recovery_file_dest_size e o db_recovery_file_dest para o disco +FRA, mas de nada adiantou, os archives continuam sendo gerados no primary e não estão sendo deletados após aplicados no standby. Gostaria de saber de vocês, o que eu poderia fazer a mais para tentar resolver esse problema.
