Bem, supondo que a policy está Corretamente setada, seguinte : falo aqui de
cabeça (então logicamente ** confirme ** no material de referência) mas AFAIK o
standby ** não ** tem recurso para remotamente apagar archives lá do primary -
assim, se vc está rodando o script RMAN que faz o DELETE lá no standby, ele Não
Vai remover os archives lá no primary - CONFIRME se não houve alguma
parâmetro/setup que faça isso recentemente mas até onde saiba isso não
existe....
Então da mesma maneira que vc já tem um script rman rodando periodicamente no
standby, vc precisa ter um script RMAN rodando periodicamente (via job,
provavelmente) lá no primary que faça o DELETE necessário, sempre de acordo com
a sua Policy que vc também setou lá...
[]s
Chiappa
---Em oracle_br@yahoogrupos.com.br, <carloseduard...@yahoo.com> escreveu:
Cenário:
Primary database 11.2.0.4
Standby 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 aplicado
SELECT 'Last applied : ' Logs,
To_char(next_time, 'DD-MON-YY:HH24:MI:SS') Time
FROM v$archived_log
WHERE sequence# = (SELECT Max(sequence#)
FROM v$archived_log
WHERE applied = 'YES')
UNION
SELECT 'Last received : ' Logs,
To_char(next_time, 'DD-MON-YY:HH24:MI:SS') Time
FROM v$archived_log
WHERE sequence# = (SELECT Max(sequence#)
FROM v$archived_log);
LOGS TIME
---------------- ------------------
Last applied : 19-MAR-17:01:53:24
Last 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 2017
RFS[1]: Selected log 62 for thread 2 sequence 432 dbid -98229520 branch
614228627
Tue Mar 21 01:10:07 2017
Media 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.923005101
Tue Mar 21 01:10:17 2017
RFS[1]: Selected log 63 for thread 2 sequence 433 dbid -98229520 branch
614228627
Tue Mar 21 01:10:18 2017
Media 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.923005107
Tue Mar 21 01:10:21 2017
Archived 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.
