Re: [oracle_br] Re: Política de deleção não funciona
Problema resolvido, Chiappa.
Conforme sua solicitação, criei um script shell na crontab do oracle deletando
todos os archives do primary database que foram aplicados no standby.:)
Em Terça-feira, 21 de Março de 2017 17:13, "Carlos Eduardo
carloseduard...@yahoo.com [oracle_br]" escreveu:
Obrigado mais uma vez mestre Chiappa. Irei implementar um job para
executar o delete obsolete dos archives no primary database e posto aqui o
resultado. Vou seguir a sua sugestao sim. Obrigado.
Em Terça-feira, 21 de Março de 2017 11:06, "jlchia...@yahoo.com.br
[oracle_br]" escreveu:
Ah, só uma obs mais : num cenário do tipo, já que é no standby que vc faz
o backup eu teria no primary DELETE APPLIED ON ALL STANDBY a policy (para que
imediatamente após ter sido aplicado nos standby o RMAN já marque o archive
como passível de remoção pelo próximo comando de DELETE que receber), MAS (dada
a importância de se ter múltiplos backups como eu já disse em posts anteriores
de outras threads), ) no standby eu só deletaria com BACKUPED 3 TIMES
[]s
Chiappa
#yiv9441196805 #yiv9441196805 -- #yiv9441196805ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9441196805
#yiv9441196805ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9441196805
#yiv9441196805ygrp-mkp #yiv9441196805hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv9441196805 #yiv9441196805ygrp-mkp #yiv9441196805ads
{margin-bottom:10px;}#yiv9441196805 #yiv9441196805ygrp-mkp .yiv9441196805ad
{padding:0 0;}#yiv9441196805 #yiv9441196805ygrp-mkp .yiv9441196805ad p
{margin:0;}#yiv9441196805 #yiv9441196805ygrp-mkp .yiv9441196805ad a
{color:#ff;text-decoration:none;}#yiv9441196805 #yiv9441196805ygrp-sponsor
#yiv9441196805ygrp-lc {font-family:Arial;}#yiv9441196805
#yiv9441196805ygrp-sponsor #yiv9441196805ygrp-lc #yiv9441196805hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9441196805
#yiv9441196805ygrp-sponsor #yiv9441196805ygrp-lc .yiv9441196805ad
{margin-bottom:10px;padding:0 0;}#yiv9441196805 #yiv9441196805actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9441196805
#yiv9441196805activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9441196805
#yiv9441196805activity span {font-weight:700;}#yiv9441196805
#yiv9441196805activity span:first-child
{text-transform:uppercase;}#yiv9441196805 #yiv9441196805activity span a
{color:#5085b6;text-decoration:none;}#yiv9441196805 #yiv9441196805activity span
span {color:#ff7900;}#yiv9441196805 #yiv9441196805activity span
.yiv9441196805underline {text-decoration:underline;}#yiv9441196805
.yiv9441196805attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv9441196805 .yiv9441196805attach div a
{text-decoration:none;}#yiv9441196805 .yiv9441196805attach img
{border:none;padding-right:5px;}#yiv9441196805 .yiv9441196805attach label
{display:block;margin-bottom:5px;}#yiv9441196805 .yiv9441196805attach label a
{text-decoration:none;}#yiv9441196805 blockquote {margin:0 0 0
4px;}#yiv9441196805 .yiv9441196805bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv9441196805
.yiv9441196805bold a {text-decoration:none;}#yiv9441196805 dd.yiv9441196805last
p a {font-family:Verdana;font-weight:700;}#yiv9441196805 dd.yiv9441196805last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv9441196805
dd.yiv9441196805last p span.yiv9441196805yshortcuts
{margin-right:0;}#yiv9441196805 div.yiv9441196805attach-table div div a
{text-decoration:none;}#yiv9441196805 div.yiv9441196805attach-table
{width:400px;}#yiv9441196805 div.yiv9441196805file-title a, #yiv9441196805
div.yiv9441196805file-title a:active, #yiv9441196805
div.yiv9441196805file-title a:hover, #yiv9441196805 div.yiv9441196805file-title
a:visited {text-decoration:none;}#yiv9441196805 div.yiv9441196805photo-title a,
#yiv9441196805 div.yiv9441196805photo-title a:active, #yiv9441196805
div.yiv9441196805photo-title a:hover, #yiv9441196805
div.yiv9441196805photo-title a:visited {text-decoration:none;}#yiv9441196805
div#yiv9441196805ygrp-mlmsg #yiv9441196805ygrp-msg p a
span.yiv9441196805yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv9441196805
.yiv9441196805green {color:#628c2a;}#yiv9441196805 .yiv9441196805MsoNormal
{margin:0 0 0 0;}#yiv9441196805 o {font-size:0;}#yiv9441196805
#yiv9441196805photos div {float:left;width:72px;}#yiv9441196805
#yiv9441196805photos div div {border:1px solid
#66;height:62px;overflow:hidden;width:62px;}#yiv9441196805
#yiv9441196805photos div label
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv9441196805
#yiv9441196805reco-category {font-size:77%;}#yiv9441196805
#yiv9441196805reco-desc {font-size:77%;}#yiv9441196805 .yiv9441196805replbq
{margin:4px;}#yiv9441196805 #yiv9441196805ygrp-actbar div a
Re: [oracle_br] Re: Política de deleção não funciona
Obrigado mais uma vez mestre Chiappa. Irei implementar um job para executar o
delete obsolete dos archives no primary database e posto aqui o resultado. Vou
seguir a sua sugestao sim. Obrigado.
Em Terça-feira, 21 de Março de 2017 11:06, "jlchia...@yahoo.com.br
[oracle_br]" escreveu:
Ah, só uma obs mais : num cenário do tipo, já que é no standby que vc faz
o backup eu teria no primary DELETE APPLIED ON ALL STANDBY a policy (para que
imediatamente após ter sido aplicado nos standby o RMAN já marque o archive
como passível de remoção pelo próximo comando de DELETE que receber), MAS (dada
a importância de se ter múltiplos backups como eu já disse em posts anteriores
de outras threads), ) no standby eu só deletaria com BACKUPED 3 TIMES
[]s
Chiappa #yiv9951096576 #yiv9951096576 -- #yiv9951096576ygrp-mkp {border:1px
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9951096576
#yiv9951096576ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9951096576
#yiv9951096576ygrp-mkp #yiv9951096576hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv9951096576 #yiv9951096576ygrp-mkp #yiv9951096576ads
{margin-bottom:10px;}#yiv9951096576 #yiv9951096576ygrp-mkp .yiv9951096576ad
{padding:0 0;}#yiv9951096576 #yiv9951096576ygrp-mkp .yiv9951096576ad p
{margin:0;}#yiv9951096576 #yiv9951096576ygrp-mkp .yiv9951096576ad a
{color:#ff;text-decoration:none;}#yiv9951096576 #yiv9951096576ygrp-sponsor
#yiv9951096576ygrp-lc {font-family:Arial;}#yiv9951096576
#yiv9951096576ygrp-sponsor #yiv9951096576ygrp-lc #yiv9951096576hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9951096576
#yiv9951096576ygrp-sponsor #yiv9951096576ygrp-lc .yiv9951096576ad
{margin-bottom:10px;padding:0 0;}#yiv9951096576 #yiv9951096576actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9951096576
#yiv9951096576activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9951096576
#yiv9951096576activity span {font-weight:700;}#yiv9951096576
#yiv9951096576activity span:first-child
{text-transform:uppercase;}#yiv9951096576 #yiv9951096576activity span a
{color:#5085b6;text-decoration:none;}#yiv9951096576 #yiv9951096576activity span
span {color:#ff7900;}#yiv9951096576 #yiv9951096576activity span
.yiv9951096576underline {text-decoration:underline;}#yiv9951096576
.yiv9951096576attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv9951096576 .yiv9951096576attach div a
{text-decoration:none;}#yiv9951096576 .yiv9951096576attach img
{border:none;padding-right:5px;}#yiv9951096576 .yiv9951096576attach label
{display:block;margin-bottom:5px;}#yiv9951096576 .yiv9951096576attach label a
{text-decoration:none;}#yiv9951096576 blockquote {margin:0 0 0
4px;}#yiv9951096576 .yiv9951096576bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv9951096576
.yiv9951096576bold a {text-decoration:none;}#yiv9951096576 dd.yiv9951096576last
p a {font-family:Verdana;font-weight:700;}#yiv9951096576 dd.yiv9951096576last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv9951096576
dd.yiv9951096576last p span.yiv9951096576yshortcuts
{margin-right:0;}#yiv9951096576 div.yiv9951096576attach-table div div a
{text-decoration:none;}#yiv9951096576 div.yiv9951096576attach-table
{width:400px;}#yiv9951096576 div.yiv9951096576file-title a, #yiv9951096576
div.yiv9951096576file-title a:active, #yiv9951096576
div.yiv9951096576file-title a:hover, #yiv9951096576 div.yiv9951096576file-title
a:visited {text-decoration:none;}#yiv9951096576 div.yiv9951096576photo-title a,
#yiv9951096576 div.yiv9951096576photo-title a:active, #yiv9951096576
div.yiv9951096576photo-title a:hover, #yiv9951096576
div.yiv9951096576photo-title a:visited {text-decoration:none;}#yiv9951096576
div#yiv9951096576ygrp-mlmsg #yiv9951096576ygrp-msg p a
span.yiv9951096576yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv9951096576
.yiv9951096576green {color:#628c2a;}#yiv9951096576 .yiv9951096576MsoNormal
{margin:0 0 0 0;}#yiv9951096576 o {font-size:0;}#yiv9951096576
#yiv9951096576photos div {float:left;width:72px;}#yiv9951096576
#yiv9951096576photos div div {border:1px solid
#66;height:62px;overflow:hidden;width:62px;}#yiv9951096576
#yiv9951096576photos div label
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv9951096576
#yiv9951096576reco-category {font-size:77%;}#yiv9951096576
#yiv9951096576reco-desc {font-size:77%;}#yiv9951096576 .yiv9951096576replbq
{margin:4px;}#yiv9951096576 #yiv9951096576ygrp-actbar div a:first-child
{margin-right:2px;padding-right:5px;}#yiv9951096576 #yiv9951096576ygrp-mlmsg
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv9951096576
#yiv9951096576ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv9951096576
#yiv9951096576ygrp-mlmsg select, #yiv9951096576 input, #yiv995
[oracle_br] Re: Política de deleção não funciona
Ah, só uma obs mais : num cenário do tipo, já que é no standby que vc faz o backup eu teria no primary DELETE APPLIED ON ALL STANDBY a policy (para que imediatamente após ter sido aplicado nos standby o RMAN já marque o archive como passível de remoção pelo próximo comando de DELETE que receber), MAS (dada a importância de se ter múltiplos backups como eu já disse em posts anteriores de outras threads), ) no standby eu só deletaria com BACKUPED 3 TIMES []s Chiappa
[oracle_br] Re: Política de deleção não funciona
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, 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.
