Re: [oracle_br] Re: rman ORA-19563
Boa noite, Será que vc nao tem dois datafiles que estao com o mesmo "sufixo" e estao em discos separados? Quando vc tenta colocar o set new name talvez esteja jogando um em cima do outro. Tente usar set newname for database , isso vai simplificar muito os seus passos de restore. [ ]'s #mufalani Desculpe por erros! Este e-mail foi escrito do meu smartphone! Sorry for typos! This mail was written from my smartphone!!! > Em 30 de jun de 2016, às 20:17, jlchia...@yahoo.com.br [oracle_br] > escreveu: > > Opa : então, a msg de erro parece ser ** diretamente relacionada ** com o > comando SWITCH, que eu nunca uso : até por questão de hábito, já tou > acostumado a depois dos SET NEWNAME ter um bloco com os RENAME DATAFILE pra > cada datafile e RENAME TEMPFILE pra cada tempfile... > > SE REALMENTE vc não esqueceu de NENHUM datafile ou NENHUM tempfile no bloco > dos SET NEWNAME (confira), E SE a sintaxe que vc tá usando é a certa (no > manual referente em > http://docs.oracle.com/cd/E11882_01/backup.112/e10643/rcmsynta2020.htm#RCMRF159 > o exemplo usa o SWITCH imediatamente depois ** dos SET NEWNAME mas ** ANTES > ** do RESTORE, e no seu exemplo vc usa ** DEPOIS ** do RESTORE, confira se > seu exemplo/script tá sintaticamente certo) , aí a única coisa que eu penso é > algum BUG no comando SWITCH - testa com RENAME DATAFILE no lugar do SWITCH, > tipo cfrem mostrado em > http://www.oracledistilled.com/oracle-database/restore-database-to-another-host-using-rman/ > > > []s > >Chiappa > >
[oracle_br] Re: rman ORA-19563
Opa : então, a msg de erro parece ser ** diretamente relacionada ** com o comando SWITCH, que eu nunca uso : até por questão de hábito, já tou acostumado a depois dos SET NEWNAME ter um bloco com os RENAME DATAFILE pra cada datafile e RENAME TEMPFILE pra cada tempfile... SE REALMENTE vc não esqueceu de NENHUM datafile ou NENHUM tempfile no bloco dos SET NEWNAME (confira), E SE a sintaxe que vc tá usando é a certa (no manual referente em http://docs.oracle.com/cd/E11882_01/backup.112/e10643/rcmsynta2020.htm#RCMRF159 o exemplo usa o SWITCH imediatamente depois ** dos SET NEWNAME mas ** ANTES ** do RESTORE, e no seu exemplo vc usa ** DEPOIS ** do RESTORE, confira se seu exemplo/script tá sintaticamente certo) , aí a única coisa que eu penso é algum BUG no comando SWITCH - testa com RENAME DATAFILE no lugar do SWITCH, tipo cfrem mostrado em http://www.oracledistilled.com/oracle-database/restore-database-to-another-host-using-rman/ []s Chiappa
RES: [oracle_br] rman ORA-19563
Francisco,
Ocorreu o mesmo erro...
Grato,
Ednilson
De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br]
Enviada em: quinta-feira, 30 de junho de 2016 14:38
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: [oracle_br] rman ORA-19563
Ednilson,
Verificando no my oracle support(metalink) encontrei o doc. ID 453123.1 e
numa parte fala o abaixo como causa provavel do ora erro que voce
evidenciou:
"Because the datafiles are being placed into the same directory on the
destination machine (auxiliary), you must insure the datafiles names are
unique. Otherwise the latest file to be restored overwrites the previous one
thereby introducing the file header validation failure. Note, this same
problem can happen when using "set newname" instead of
db_file_name_convert."
e como solução menciona o seguinte:
1) Determine if there are duplicate files names. To quickly find the
problem when many datafiles are involved, from the source (target) database:
spool datafile.txt
select name from v$datafile;
spool off
Modify the query output to remove the directory names thereby leaving only
the file name, sort the query output, browse the query output for
duplicates. This step may not be necessary if the number of datafiles is
small.
OR
Save the RMAN logs in a file say rmanLogFile.
To check if there is really a duplicate file-name compare below 2 outputs:
cat rmanLogFile | grep "restoring datafile" | awk {'print $5'} | sort | wc
-l
cat rmanLogFile | grep "restoring datafile" | awk {'print $5'} | sort -u |
wc -l
If the second result is lesser, it means there are duplicates. To list out
just the sorted file-name components use:
cat rmanLogFile | grep "restoring datafile" | awk {'print $5'} | sort
If there are duplicates then modify the db_file_name_convert parameter to
have the duplicate file names go to separate directories on the destination
(auxiliary).
The Order of Precedence for Naming Files:
1 SET NEWNAME
2 CONFIGURE AUXNAME
3 DB_FILE_NAME_CONVERT
Settings higher on the list override settings lower on the list in
situations where BOTH have been applied.
So you can also use a combination of set newname and DB_FILE_NAME_CONVERT
Espero ter ajudado,
Francisco
_
De: oracle_br@yahoogrupos.com.br em nome de
'Ednilson Silva' ednilson.si...@jbs.com.br [oracle_br]
Enviado: quinta-feira, 30 de junho de 2016 17:12:59
Para: oracle_br@yahoogrupos.com.br
Assunto: [oracle_br] rman ORA-19563
Pessoal,
Tenho um banco de produção chamado "prod" Oracle Database Enterprise
11.2.0.4 em red hat linux 6.
A estrutura do file system desse banco esta da seguinte forma.
/u01/oradata/prod
/u02/oradata/prod
/u03/oradata/prod
Preciso criar um ambiente de homologação com o backup full deste banco que é
feito pelo HP Data Protector.
A estrutura do file system deste servidor tenho apenas o /u01
Bom, criei o init chamado initprodh.ora igual ao do prod acrescentando
apenas os parâmetros abaixo;
*.db_unique_name='prodh'
*.instance_name='prodh'
*.db_name='prod'
O controlfile restaurei em /u01/oradata/prodh
No restore fiz os
SET NEWNAME FOR DATAFILE 1 TO '/u01/oradata/prodh/system01.dbf';
SET NEWNAME FOR DATAFILE 2 TO '/u01/oradata/prodh/xpto01.dbf';
SET NEWNAME FOR DATAFILE 3 TO '/u01/oradata/prodh/abc01.dbf';
.
.
RESTORE DATABASE;
SWITCH TEMPFILE ALL;
SWITCH DATAFILE ALL;
RECOVER DATABASE;
Sabe dizer o que esta faltando, pois estou recebendo o erro abaixo
RMAN-03002: failure of switch command at 06/30/2016 11:50:03
ORA-19563: header validation failed for file
Grato
Ednilson Silva
Re: [oracle_br] rman ORA-19563
Ednilson,
Verificando no my oracle support(metalink) encontrei o doc. ID 453123.1 e numa
parte fala o abaixo como causa provavel do ora erro que voce evidenciou:
"Because the datafiles are being placed into the same directory on the
destination machine (auxiliary), you must insure the datafiles names are
unique. Otherwise the latest file to be restored overwrites the previous one
thereby introducing the file header validation failure. Note, this same
problem can happen when using "set newname" instead of db_file_name_convert."
e como solução menciona o seguinte:
1) Determine if there are duplicate files names. To quickly find the problem
when many datafiles are involved, from the source (target) database:
spool datafile.txt
select name from v$datafile;
spool off
Modify the query output to remove the directory names thereby leaving only the
file name, sort the query output, browse the query output for duplicates. This
step may not be necessary if the number of datafiles is small.
OR
Save the RMAN logs in a file say rmanLogFile.
To check if there is really a duplicate file-name compare below 2 outputs:
cat rmanLogFile | grep "restoring datafile" | awk {'print $5'} | sort | wc -l
cat rmanLogFile | grep "restoring datafile" | awk {'print $5'} | sort -u | wc -l
If the second result is lesser, it means there are duplicates. To list out just
the sorted file-name components use:
cat rmanLogFile | grep "restoring datafile" | awk {'print $5'} | sort
If there are duplicates then modify the db_file_name_convert parameter to have
the duplicate file names go to separate directories on the destination
(auxiliary).
The Order of Precedence for Naming Files:
1 SET NEWNAME
2 CONFIGURE AUXNAME
3 DB_FILE_NAME_CONVERT
Settings higher on the list override settings lower on the list in situations
where BOTH have been applied.
So you can also use a combination of set newname and DB_FILE_NAME_CONVERT
Espero ter ajudado,
Francisco
De: oracle_br@yahoogrupos.com.br em nome de
'Ednilson Silva' ednilson.si...@jbs.com.br [oracle_br]
Enviado: quinta-feira, 30 de junho de 2016 17:12:59
Para: oracle_br@yahoogrupos.com.br
Assunto: [oracle_br] rman ORA-19563
Pessoal,
Tenho um banco de produção chamado "prod" Oracle Database Enterprise 11.2.0.4
em red hat linux 6.
A estrutura do file system desse banco esta da seguinte forma.
/u01/oradata/prod
/u02/oradata/prod
/u03/oradata/prod
Preciso criar um ambiente de homologação com o backup full deste banco que é
feito pelo HP Data Protector.
A estrutura do file system deste servidor tenho apenas o /u01
Bom, criei o init chamado initprodh.ora igual ao do prod acrescentando apenas
os parâmetros abaixo;
*.db_unique_name='prodh'
*.instance_name='prodh'
*.db_name='prod'
O controlfile restaurei em /u01/oradata/prodh
No restore fiz os
SET NEWNAME FOR DATAFILE 1 TO '/u01/oradata/prodh/system01.dbf';
SET NEWNAME FOR DATAFILE 2 TO '/u01/oradata/prodh/xpto01.dbf';
SET NEWNAME FOR DATAFILE 3 TO '/u01/oradata/prodh/abc01.dbf';
.
.
RESTORE DATABASE;
SWITCH TEMPFILE ALL;
SWITCH DATAFILE ALL;
RECOVER DATABASE;
Sabe dizer o que esta faltando, pois estou recebendo o erro abaixo
RMAN-03002: failure of switch command at 06/30/2016 11:50:03
ORA-19563: header validation failed for file
Grato
Ednilson Silva
[oracle_br] rman ORA-19563
Pessoal, Tenho um banco de produção chamado "prod" Oracle Database Enterprise 11.2.0.4 em red hat linux 6. A estrutura do file system desse banco esta da seguinte forma. /u01/oradata/prod /u02/oradata/prod /u03/oradata/prod Preciso criar um ambiente de homologação com o backup full deste banco que é feito pelo HP Data Protector. A estrutura do file system deste servidor tenho apenas o /u01 Bom, criei o init chamado initprodh.ora igual ao do prod acrescentando apenas os parâmetros abaixo; *.db_unique_name='prodh' *.instance_name='prodh' *.db_name='prod' O controlfile restaurei em /u01/oradata/prodh No restore fiz os SET NEWNAME FOR DATAFILE 1 TO '/u01/oradata/prodh/system01.dbf'; SET NEWNAME FOR DATAFILE 2 TO '/u01/oradata/prodh/xpto01.dbf'; SET NEWNAME FOR DATAFILE 3 TO '/u01/oradata/prodh/abc01.dbf'; . . RESTORE DATABASE; SWITCH TEMPFILE ALL; SWITCH DATAFILE ALL; RECOVER DATABASE; Sabe dizer o que esta faltando, pois estou recebendo o erro abaixo RMAN-03002: failure of switch command at 06/30/2016 11:50:03 ORA-19563: header validation failed for file Grato Ednilson Silva
Re: [oracle_br] Re: [Forms] Erro PERL5LIB - Path 7047034
Obrigado Chiappa !!!
[ ]s
Em Quarta-feira, 29 de Junho de 2016 17:53, "jlchia...@yahoo.com.br
[oracle_br]" escreveu:
Sem dúvida : o custo de Licenciamento é o mesmo afaik mas Evidentemente as
versões mais novas do Forms vão vir SIM com versões mais novas de webserver OU
mesmo com um novo webserver, e quando se fala em versão mais nova ou novo
produto vc pode contar que vai consumir mais recurso de hardware, que vai ter
diffs na config
Quando eu falei de ausência de motivo forte que te impeça de upgradear, até
Poderia ser esse motivo ausência de capacidade de hardware suficiente pra
encarar a nova versão, ou falta de expertise com a nova versão, sim É
sempre contrabalancear o risco de vc não ter Suporte full/completo na versão
antiga VERSUS o eventual benefício das novas features Adicionado com a
diminuição de risco
[]s
Chiappa #yiv5832008668 #yiv5832008668 -- #yiv5832008668ygrp-mkp {border:1px
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv5832008668
#yiv5832008668ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv5832008668
#yiv5832008668ygrp-mkp #yiv5832008668hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv5832008668 #yiv5832008668ygrp-mkp #yiv5832008668ads
{margin-bottom:10px;}#yiv5832008668 #yiv5832008668ygrp-mkp .yiv5832008668ad
{padding:0 0;}#yiv5832008668 #yiv5832008668ygrp-mkp .yiv5832008668ad p
{margin:0;}#yiv5832008668 #yiv5832008668ygrp-mkp .yiv5832008668ad a
{color:#ff;text-decoration:none;}#yiv5832008668 #yiv5832008668ygrp-sponsor
#yiv5832008668ygrp-lc {font-family:Arial;}#yiv5832008668
#yiv5832008668ygrp-sponsor #yiv5832008668ygrp-lc #yiv5832008668hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv5832008668
#yiv5832008668ygrp-sponsor #yiv5832008668ygrp-lc .yiv5832008668ad
{margin-bottom:10px;padding:0 0;}#yiv5832008668 #yiv5832008668actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv5832008668
#yiv5832008668activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv5832008668
#yiv5832008668activity span {font-weight:700;}#yiv5832008668
#yiv5832008668activity span:first-child
{text-transform:uppercase;}#yiv5832008668 #yiv5832008668activity span a
{color:#5085b6;text-decoration:none;}#yiv5832008668 #yiv5832008668activity span
span {color:#ff7900;}#yiv5832008668 #yiv5832008668activity span
.yiv5832008668underline {text-decoration:underline;}#yiv5832008668
.yiv5832008668attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv5832008668 .yiv5832008668attach div a
{text-decoration:none;}#yiv5832008668 .yiv5832008668attach img
{border:none;padding-right:5px;}#yiv5832008668 .yiv5832008668attach label
{display:block;margin-bottom:5px;}#yiv5832008668 .yiv5832008668attach label a
{text-decoration:none;}#yiv5832008668 blockquote {margin:0 0 0
4px;}#yiv5832008668 .yiv5832008668bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv5832008668
.yiv5832008668bold a {text-decoration:none;}#yiv5832008668 dd.yiv5832008668last
p a {font-family:Verdana;font-weight:700;}#yiv5832008668 dd.yiv5832008668last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv5832008668
dd.yiv5832008668last p span.yiv5832008668yshortcuts
{margin-right:0;}#yiv5832008668 div.yiv5832008668attach-table div div a
{text-decoration:none;}#yiv5832008668 div.yiv5832008668attach-table
{width:400px;}#yiv5832008668 div.yiv5832008668file-title a, #yiv5832008668
div.yiv5832008668file-title a:active, #yiv5832008668
div.yiv5832008668file-title a:hover, #yiv5832008668 div.yiv5832008668file-title
a:visited {text-decoration:none;}#yiv5832008668 div.yiv5832008668photo-title a,
#yiv5832008668 div.yiv5832008668photo-title a:active, #yiv5832008668
div.yiv5832008668photo-title a:hover, #yiv5832008668
div.yiv5832008668photo-title a:visited {text-decoration:none;}#yiv5832008668
div#yiv5832008668ygrp-mlmsg #yiv5832008668ygrp-msg p a
span.yiv5832008668yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv5832008668
.yiv5832008668green {color:#628c2a;}#yiv5832008668 .yiv5832008668MsoNormal
{margin:0 0 0 0;}#yiv5832008668 o {font-size:0;}#yiv5832008668
#yiv5832008668photos div {float:left;width:72px;}#yiv5832008668
#yiv5832008668photos div div {border:1px solid
#66;min-height:62px;overflow:hidden;width:62px;}#yiv5832008668
#yiv5832008668photos div label
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv5832008668
#yiv5832008668reco-category {font-size:77%;}#yiv5832008668
#yiv5832008668reco-desc {font-size:77%;}#yiv5832008668 .yiv5832008668replbq
{margin:4px;}#yiv5832008668 #yiv5832008668ygrp-actbar div a:first-child
{margin-right:2px;padding-right:5px;}#yiv5832008668 #yiv5832008668ygrp-mlmsg
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv5832008668
#yiv5832008668ygrp-mlmsg table {font
