Só acrescentando, além de verificar o espaço em disco FRA, tb verifiquei o
tamanho da db_recovery_file_dest_size e possui 300GB, quase nada também
utilizado.
Vale apena eu antes de rodar novamente o processo de duplicate eu abrir um
chamado com a Oracle para verificar qual motivo do archive não está sendo
archivado? POis espaço em área tem e só trava no final do processo do
duplicate. db_recovery_file_dest string +FRA
db_recovery_file_dest_size big integer 200G
Em Sexta-feira, 12 de Fevereiro de 2016 9:36, Rafael Mendonca
<raffaell.t...@yahoo.com> escreveu:
a) confirme que o processo ARCH não morreu/parou no banco prod : é mandar uma
verificação no SO (via ps ou o que vc tiver disponível) E mandar um archive log
list conectado como sysdba no sqlplus
Irei recriar o dataguard caso trave novamente irei verificar essa opção.
b) CONFIRMAR que os parâmetros de archive ** todos ** estão Corretos tanto no
banco PROD quanto no banco standby sendo criado pelo DUPLICATE : por exemplo,
não vi vc alterar o log_archive_dest_1 no banco standby a ser criado, vc Tem
certeza que o valor dele está válido para o banco standby ? FAL_SERVER e
FAL_CLIENT apontam para os nomes corretos ? No log_archive_config a ordem dos
valores está correta ? Assim por diante ...
Chiappa, eu sempre criei o dataguard sem configurar o log_archive_dest_1 no
database standby, pois ele já configura automático a fast recovery área que eh
aonde eu sempre deixo (+FRA)
c) o TNSPING e testes de comunicação Funcionam ?? Uma coisa que o DUPLICATE **
não faz ** Automagicamente sozinho é Configurar o TNSNAMES.ORA corretamente...
IDEM para a eventual config de LISTENER requerida, afaik isso Também não é
Automático
Resposta: SIM. Faço sempre o teste antes de realizar o duplicate. o tnsping
tanto da produção pro standby e do standby pra produção.Listener e TNSNAMES
configurados perfeitamente.
d) verifique o ESPAÇO LIVRE nas áreas de archive indicadas ** E ** a permissão
para o usuário oracle gravar nelas, TANTo no banco prod quanto no servidor que
irá conter o banco standby - uma das Causas mais Comuns de falha de
archivamento éjustamente isso, situações em que o ARCH não pode gravar o
archived redo log file..
Sim, fiz isso. Existe bastante espaço livre, o disco FRA possui 3% apenas de
espaço utilizado, aproximadamente 400GB livres.E o usuário Oracle possui
permissão de gravar nessas áreas.
e) outra coisa comum (que normalmente não dá exatamente esse sintoma, mas vale
se conferir) é a questão de IGUALDADE dos log files / standby log files : por
exemplo, se há standby log files no banco PROD, eles TAMBÉM terão que ser
criados igualzinhos, na mesma qtdade/tamanhos, etc, no banco standby, CONFIRA
se o local indicado para os criar é válido no servidor standby, etc, etc
Obrigado pelas dicas Chiappa, irei rodar novamente o script, porém irá demorar
pois a base possui quase 2TB
Em Quinta-feira, 11 de Fevereiro de 2016 20:02, "jlchia...@yahoo.com.br
[oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu:
Opa, blz ? Pra mim a chave tá nas linhas :
"...
Thu Feb 11 15:21:17 2016
ORACLE Instance XUXAPRD - Cannot allocate log, archival required
Thread 1 cannot allocate new log, sequence 1845
All online logs need archiving
Examine archive trace files for archiving errors
Current log# 3 seq# 1844 mem# 0:
+DATA/xuxaprd/onlinelog/group_3.422.902214817
Current log# 3 seq# 1844 mem# 1:
+FRA/xuxaprd/onlinelog/group_3.394.902214819
..."
==> Claramente as msgs dizem que os log files encheram (normal, é o que
acontece em qquer database Ativo, online log files não são infinitos), aí eles
tinham que ser arquivado (ie, feita uma cópia dele, gerando um archived redo
log file) Porém houve erros que Impediram o arquivamento...
Para eliminar possibilidades, ALÉM de olhar os trace files indicados (E o
alert e os trace files recentes do banco standby), vc vai olhar os traces files
do processo ARCH (em prod e no standby) e vai :
a) confirme que o processo ARCH não morreu/parou no banco prod : é mandar uma
verificação no SO (via ps ou o que vc tiver disponível) E mandar um archive log
list conectado como sysdba no sqlplus
b) CONFIRMAR que os parâmetros de archive ** todos ** estão Corretos tanto no
banco PROD quanto no banco standby sendo criado pelo DUPLICATE : por exemplo,
não vi vc alterar o log_archive_dest_1 no banco standby a ser criado, vc Tem
certeza que o valor dele está válido para o banco standby ? FAL_SERVER e
FAL_CLIENT apontam para os nomes corretos ? No log_archive_config a ordem dos
valores está correta ? Assim por diante ...
c) o TNSPING e testes de comunicação Funcionam ?? Uma coisa que o DUPLICATE **
não faz ** Automagicamente sozinho é Configurar o TNSNAMES.ORA corretamente...
IDEM para a eventual config de LISTENER requerida, afaik isso Também não é
Automático
d) verifique o ESPAÇO LIVRE nas áreas de archive indicadas ** E ** a permissão
para o usuário oracle gravar nelas, TANTo no banco prod quanto no servidor que
irá conter o banco standby - uma das Causas mais Comuns de falha de
archivamento éjustamente isso, situações em que o ARCH não pode gravar o
archived redo log file..
e) outra coisa comum (que normalmente não dá exatamente esse sintoma, mas vale
se conferir) é a questão de IGUALDADE dos log files / standby log files : por
exemplo, se há standby log files no banco PROD, eles TAMBÉM terão que ser
criados igualzinhos, na mesma qtdade/tamanhos, etc, no banco standby, CONFIRA
se o local indicado para os criar é válido no servidor standby, etc, etc
[]s
Chiappa #yiv3234979739 -- #yiv3234979739ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv3234979739
#yiv3234979739ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv3234979739
#yiv3234979739ygrp-mkp #yiv3234979739hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv3234979739 #yiv3234979739ygrp-mkp #yiv3234979739ads
{margin-bottom:10px;}#yiv3234979739 #yiv3234979739ygrp-mkp .yiv3234979739ad
{padding:0 0;}#yiv3234979739 #yiv3234979739ygrp-mkp .yiv3234979739ad p
{margin:0;}#yiv3234979739 #yiv3234979739ygrp-mkp .yiv3234979739ad a
{color:#0000ff;text-decoration:none;}#yiv3234979739 #yiv3234979739ygrp-sponsor
#yiv3234979739ygrp-lc {font-family:Arial;}#yiv3234979739
#yiv3234979739ygrp-sponsor #yiv3234979739ygrp-lc #yiv3234979739hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv3234979739
#yiv3234979739ygrp-sponsor #yiv3234979739ygrp-lc .yiv3234979739ad
{margin-bottom:10px;padding:0 0;}#yiv3234979739 #yiv3234979739actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv3234979739
#yiv3234979739activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv3234979739
#yiv3234979739activity span {font-weight:700;}#yiv3234979739
#yiv3234979739activity span:first-child
{text-transform:uppercase;}#yiv3234979739 #yiv3234979739activity span a
{color:#5085b6;text-decoration:none;}#yiv3234979739 #yiv3234979739activity span
span {color:#ff7900;}#yiv3234979739 #yiv3234979739activity span
.yiv3234979739underline {text-decoration:underline;}#yiv3234979739
.yiv3234979739attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv3234979739 .yiv3234979739attach div a
{text-decoration:none;}#yiv3234979739 .yiv3234979739attach img
{border:none;padding-right:5px;}#yiv3234979739 .yiv3234979739attach label
{display:block;margin-bottom:5px;}#yiv3234979739 .yiv3234979739attach label a
{text-decoration:none;}#yiv3234979739 blockquote {margin:0 0 0
4px;}#yiv3234979739 .yiv3234979739bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv3234979739
.yiv3234979739bold a {text-decoration:none;}#yiv3234979739 dd.yiv3234979739last
p a {font-family:Verdana;font-weight:700;}#yiv3234979739 dd.yiv3234979739last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv3234979739
dd.yiv3234979739last p span.yiv3234979739yshortcuts
{margin-right:0;}#yiv3234979739 div.yiv3234979739attach-table div div a
{text-decoration:none;}#yiv3234979739 div.yiv3234979739attach-table
{width:400px;}#yiv3234979739 div.yiv3234979739file-title a, #yiv3234979739
div.yiv3234979739file-title a:active, #yiv3234979739
div.yiv3234979739file-title a:hover, #yiv3234979739 div.yiv3234979739file-title
a:visited {text-decoration:none;}#yiv3234979739 div.yiv3234979739photo-title a,
#yiv3234979739 div.yiv3234979739photo-title a:active, #yiv3234979739
div.yiv3234979739photo-title a:hover, #yiv3234979739
div.yiv3234979739photo-title a:visited {text-decoration:none;}#yiv3234979739
div#yiv3234979739ygrp-mlmsg #yiv3234979739ygrp-msg p a
span.yiv3234979739yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv3234979739
.yiv3234979739green {color:#628c2a;}#yiv3234979739 .yiv3234979739MsoNormal
{margin:0 0 0 0;}#yiv3234979739 o {font-size:0;}#yiv3234979739
#yiv3234979739photos div {float:left;width:72px;}#yiv3234979739
#yiv3234979739photos div div {border:1px solid
#666666;height:62px;overflow:hidden;width:62px;}#yiv3234979739
#yiv3234979739photos div label
{color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv3234979739
#yiv3234979739reco-category {font-size:77%;}#yiv3234979739
#yiv3234979739reco-desc {font-size:77%;}#yiv3234979739 .yiv3234979739replbq
{margin:4px;}#yiv3234979739 #yiv3234979739ygrp-actbar div a:first-child
{margin-right:2px;padding-right:5px;}#yiv3234979739 #yiv3234979739ygrp-mlmsg
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv3234979739
#yiv3234979739ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv3234979739
#yiv3234979739ygrp-mlmsg select, #yiv3234979739 input, #yiv3234979739 textarea
{font:99% Arial, Helvetica, clean, sans-serif;}#yiv3234979739
#yiv3234979739ygrp-mlmsg pre, #yiv3234979739 code {font:115%
monospace;}#yiv3234979739 #yiv3234979739ygrp-mlmsg *
{line-height:1.22em;}#yiv3234979739 #yiv3234979739ygrp-mlmsg #yiv3234979739logo
{padding-bottom:10px;}#yiv3234979739 #yiv3234979739ygrp-msg p a
{font-family:Verdana;}#yiv3234979739 #yiv3234979739ygrp-msg
p#yiv3234979739attach-count span {color:#1E66AE;font-weight:700;}#yiv3234979739
#yiv3234979739ygrp-reco #yiv3234979739reco-head
{color:#ff7900;font-weight:700;}#yiv3234979739 #yiv3234979739ygrp-reco
{margin-bottom:20px;padding:0px;}#yiv3234979739 #yiv3234979739ygrp-sponsor
#yiv3234979739ov li a {font-size:130%;text-decoration:none;}#yiv3234979739
#yiv3234979739ygrp-sponsor #yiv3234979739ov li
{font-size:77%;list-style-type:square;padding:6px 0;}#yiv3234979739
#yiv3234979739ygrp-sponsor #yiv3234979739ov ul {margin:0;padding:0 0 0
8px;}#yiv3234979739 #yiv3234979739ygrp-text
{font-family:Georgia;}#yiv3234979739 #yiv3234979739ygrp-text p {margin:0 0 1em
0;}#yiv3234979739 #yiv3234979739ygrp-text tt {font-size:120%;}#yiv3234979739
#yiv3234979739ygrp-vital ul li:last-child {border-right:none
!important;}#yiv3234979739
