Re: [oracle_br] Erro instalação RAC

[Rodrigo Mufalani rodr...@mufalani.com.br [oracle_br]]

Tent seguir essa dica aqui usando esse dnsmasq

http://dbaora.com/configure-scan-dns-for-rac-11g-rac-12c-using-dnsmasq-in-oel5-oel6-2/

Get Outlook for iOS
_
From: Rodrigo Mufalani >
Sent: quinta-feira, abril 13, 2017 21:11
Subject: Re: [oracle_br] Erro instalação RAC
To: >


Entao...

O que o instalador do Oracle faz é usar o nslookup (utilitario do linux) 
para checar os nomes e se está usando dns. O que eu fiz foi pegar um script 
linux pronto na net e aí troquei o nslookup original por ele, quando o 
instalado do Oracle faz a chamada, ele chama o script já ajustado para simular 
a resposta de um dns.

Get Outlook for iOS

From: oracle_br@yahoogrupos.com.br 
> on behalf 
of Carlos Eduardo carloseduard...@yahoo.com 
[oracle_br] >
Sent: Thursday, April 13, 2017 8:53:51 PM
To: oracle_br@yahoogrupos.com.br
Subject: Re: [oracle_br] Erro instalação RAC



Rodrigo, obrigado pelo retorno.

Mas como estou começando meus estudos e meus aprendizados com RAC, eu não 
entendi o que você quis dizer.


Em Quinta-feira, 13 de Abril de 2017 19:03, "Rodrigo Mufalani 
rodr...@mufalani.com.br [oracle_br]" 
> escreveu:



Vc renomeia o nslookup e o substitui por um shell script... da uma googlada por 
esse caminho que foi assim que resolvi essa questao.

Get Outlook for iOS

From: oracle_br@yahoogrupos.com.br 
> on behalf 
of Carlos Eduardo carloseduard...@yahoo.com 
[oracle_br] >
Sent: Thursday, April 13, 2017 6:41:08 PM
To: Yahoo! Brazil
Subject: [oracle_br] Erro instalação RAC


Cenário:

GI and DB 12cR1
OEL 6.9
Virtual BOX (sem servidor DNS/GNS)

Dois nós


# Public
192.168.56.101   rac1.localdomainrac1
192.168.56.102   rac2.localdomainrac2
# Private
192.168.1.101   rac1-priv.localdomain   rac1-priv
192.168.1.102   rac2-priv.localdomain   rac2-priv
# Virtual
192.168.56.103  rac1-vip.localdomainrac1-vip
192.168.56.104  rac2-vip.localdomainrac2-vip
# SCAN
#192.168.56.105   rac-scan.localdomain rac-scan
#192.168.56.106   rac-scan.localdomain rac-scan
#192.168.56.107   rac-scan.localdomain rac-scan


Obs: Em cada VM, eu tenho 3 adaptadores de rede, a primeira NAT, a segunda Host 
only (publica) e a terceira Internal network (privada)

As maquinas RAC1 e RAC2 se comunicam pela rede PUBLICA e pela rede PRIVADA 
(pingando pelo IP ou pelo host).

Mas se eu pingar o endereço virtual ou pelo SCAN, não funciona.

Quando eu chego na instalação do GI na parte GRID PLUG and PLAY information, o 
erro abaixo é gerado:

[INS-40718]

Single Client Access Name (SCAN): rac-scan.localdomain could not be resolved.


Alguém sabe como posso resolver essa situação?

Re: [oracle_br] Erro instalação RAC

[Rodrigo Mufalani rodr...@mufalani.com.br [oracle_br]]

Entao...

O que o instalador do Oracle faz é usar o nslookup (utilitario do linux) 
para checar os nomes e se está usando dns. O que eu fiz foi pegar um script 
linux pronto na net e aí troquei o nslookup original por ele, quando o 
instalado do Oracle faz a chamada, ele chama o script já ajustado para simular 
a resposta de um dns.

Get Outlook for iOS

From: oracle_br@yahoogrupos.com.br  on behalf of 
Carlos Eduardo carloseduard...@yahoo.com [oracle_br] 

Sent: Thursday, April 13, 2017 8:53:51 PM
To: oracle_br@yahoogrupos.com.br
Subject: Re: [oracle_br] Erro instalação RAC



Rodrigo, obrigado pelo retorno.

Mas como estou começando meus estudos e meus aprendizados com RAC, eu não 
entendi o que você quis dizer.


Em Quinta-feira, 13 de Abril de 2017 19:03, "Rodrigo Mufalani 
rodr...@mufalani.com.br [oracle_br]"  escreveu:



Vc renomeia o nslookup e o substitui por um shell script... da uma googlada por 
esse caminho que foi assim que resolvi essa questao.

Get Outlook for iOS

From: oracle_br@yahoogrupos.com.br  on behalf of 
Carlos Eduardo carloseduard...@yahoo.com [oracle_br] 

Sent: Thursday, April 13, 2017 6:41:08 PM
To: Yahoo! Brazil
Subject: [oracle_br] Erro instalação RAC


Cenário:

GI and DB 12cR1
OEL 6.9
Virtual BOX (sem servidor DNS/GNS)

Dois nós


# Public
192.168.56.101   rac1.localdomainrac1
192.168.56.102   rac2.localdomainrac2
# Private
192.168.1.101   rac1-priv.localdomain   rac1-priv
192.168.1.102   rac2-priv.localdomain   rac2-priv
# Virtual
192.168.56.103  rac1-vip.localdomainrac1-vip
192.168.56.104  rac2-vip.localdomainrac2-vip
# SCAN
#192.168.56.105   rac-scan.localdomain rac-scan
#192.168.56.106   rac-scan.localdomain rac-scan
#192.168.56.107   rac-scan.localdomain rac-scan


Obs: Em cada VM, eu tenho 3 adaptadores de rede, a primeira NAT, a segunda Host 
only (publica) e a terceira Internal network (privada)

As maquinas RAC1 e RAC2 se comunicam pela rede PUBLICA e pela rede PRIVADA 
(pingando pelo IP ou pelo host).

Mas se eu pingar o endereço virtual ou pelo SCAN, não funciona.

Quando eu chego na instalação do GI na parte GRID PLUG and PLAY information, o 
erro abaixo é gerado:

[INS-40718]

Single Client Access Name (SCAN): rac-scan.localdomain could not be resolved.


Alguém sabe como posso resolver essa situação?

Re: [oracle_br] Erro instalação RAC

[Carlos Eduardo carloseduard...@yahoo.com [oracle_br]]

Rodrigo, obrigado pelo retorno.
Mas como estou começando meus estudos e meus aprendizados com RAC, eu não 
entendi o que você quis dizer. 

Em Quinta-feira, 13 de Abril de 2017 19:03, "Rodrigo Mufalani 
rodr...@mufalani.com.br [oracle_br]"  escreveu:
 

     Vc renomeia o nslookup e o substitui por um shell script... da uma 
googlada por esse caminho que foi assim que resolvi essa questao.
Get Outlook for iOSFrom: oracle_br@yahoogrupos.com.br 
 on behalf of Carlos Eduardo 
carloseduard...@yahoo.com [oracle_br] 
Sent: Thursday, April 13, 2017 6:41:08 PM
To: Yahoo! Brazil
Subject: [oracle_br] Erro instalação RAC  Cenário: 
GI and DB 12cR1OEL 6.9Virtual BOX (sem servidor DNS/GNS)
Dois nós

# Public192.168.56.101   rac1.localdomain        rac1192.168.56.102   
rac2.localdomain        rac2# Private192.168.1.101   rac1-priv.localdomain   
rac1-priv192.168.1.102   rac2-priv.localdomain   rac2-priv# 
Virtual192.168.56.103  rac1-vip.localdomain    rac1-vip192.168.56.104  
rac2-vip.localdomain    rac2-vip# SCAN#192.168.56.105   rac-scan.localdomain 
rac-scan#192.168.56.106   rac-scan.localdomain rac-scan#192.168.56.107   
rac-scan.localdomain rac-scan

Obs: Em cada VM, eu tenho 3 adaptadores de rede, a primeira NAT, a segunda Host 
only (publica) e a terceira Internal network (privada)
As maquinas RAC1 e RAC2 se comunicam pela rede PUBLICA e pela rede PRIVADA 
(pingando pelo IP ou pelo host).
Mas se eu pingar o endereço virtual ou pelo SCAN, não funciona.
Quando eu chego na instalação do GI na parte GRID PLUG and PLAY information, o 
erro abaixo é gerado:
[INS-40718] 
Single Client Access Name (SCAN): rac-scan.localdomain could not be resolved.

Alguém sabe como posso resolver essa situação?




  #yiv7524536005 #yiv7524536005 -- #yiv7524536005ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv7524536005 
#yiv7524536005ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv7524536005 
#yiv7524536005ygrp-mkp #yiv7524536005hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv7524536005 #yiv7524536005ygrp-mkp #yiv7524536005ads 
{margin-bottom:10px;}#yiv7524536005 #yiv7524536005ygrp-mkp .yiv7524536005ad 
{padding:0 0;}#yiv7524536005 #yiv7524536005ygrp-mkp .yiv7524536005ad p 
{margin:0;}#yiv7524536005 #yiv7524536005ygrp-mkp .yiv7524536005ad a 
{color:#ff;text-decoration:none;}#yiv7524536005 #yiv7524536005ygrp-sponsor 
#yiv7524536005ygrp-lc {font-family:Arial;}#yiv7524536005 
#yiv7524536005ygrp-sponsor #yiv7524536005ygrp-lc #yiv7524536005hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv7524536005 
#yiv7524536005ygrp-sponsor #yiv7524536005ygrp-lc .yiv7524536005ad 
{margin-bottom:10px;padding:0 0;}#yiv7524536005 #yiv7524536005actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv7524536005 
#yiv7524536005activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv7524536005
 #yiv7524536005activity span {font-weight:700;}#yiv7524536005 
#yiv7524536005activity span:first-child 
{text-transform:uppercase;}#yiv7524536005 #yiv7524536005activity span a 
{color:#5085b6;text-decoration:none;}#yiv7524536005 #yiv7524536005activity span 
span {color:#ff7900;}#yiv7524536005 #yiv7524536005activity span 
.yiv7524536005underline {text-decoration:underline;}#yiv7524536005 
.yiv7524536005attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv7524536005 .yiv7524536005attach div a 
{text-decoration:none;}#yiv7524536005 .yiv7524536005attach img 
{border:none;padding-right:5px;}#yiv7524536005 .yiv7524536005attach label 
{display:block;margin-bottom:5px;}#yiv7524536005 .yiv7524536005attach label a 
{text-decoration:none;}#yiv7524536005 blockquote {margin:0 0 0 
4px;}#yiv7524536005 .yiv7524536005bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv7524536005 
.yiv7524536005bold a {text-decoration:none;}#yiv7524536005 dd.yiv7524536005last 
p a {font-family:Verdana;font-weight:700;}#yiv7524536005 dd.yiv7524536005last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv7524536005 
dd.yiv7524536005last p span.yiv7524536005yshortcuts 
{margin-right:0;}#yiv7524536005 div.yiv7524536005attach-table div div a 
{text-decoration:none;}#yiv7524536005 div.yiv7524536005attach-table 
{width:400px;}#yiv7524536005 div.yiv7524536005file-title a, #yiv7524536005 
div.yiv7524536005file-title a:active, #yiv7524536005 
div.yiv7524536005file-title a:hover, #yiv7524536005 div.yiv7524536005file-title 
a:visited {text-decoration:none;}#yiv7524536005 div.yiv7524536005photo-title a, 
#yiv7524536005 div.yiv7524536005photo-title a:active, #yiv7524536005 
div.yiv7524536005photo-title a:hover, #yiv7524536005 
div.yiv7524536005photo-title a:visited {text-decoration:none;}#yiv7524536005 
div#yiv7524536005ygrp-mlmsg #yiv7524536005ygrp-msg p a 
span.yiv7524536005yshortcuts 

Re: [oracle_br] Erro instalação RAC

[Rodrigo Mufalani rodr...@mufalani.com.br [oracle_br]]

Vc renomeia o nslookup e o substitui por um shell script... da uma googlada por 
esse caminho que foi assim que resolvi essa questao.

Get Outlook for iOS

From: oracle_br@yahoogrupos.com.br  on behalf of 
Carlos Eduardo carloseduard...@yahoo.com [oracle_br] 

Sent: Thursday, April 13, 2017 6:41:08 PM
To: Yahoo! Brazil
Subject: [oracle_br] Erro instalação RAC



Cenário:

GI and DB 12cR1
OEL 6.9
Virtual BOX (sem servidor DNS/GNS)

Dois nós


# Public
192.168.56.101   rac1.localdomainrac1
192.168.56.102   rac2.localdomainrac2
# Private
192.168.1.101   rac1-priv.localdomain   rac1-priv
192.168.1.102   rac2-priv.localdomain   rac2-priv
# Virtual
192.168.56.103  rac1-vip.localdomainrac1-vip
192.168.56.104  rac2-vip.localdomainrac2-vip
# SCAN
#192.168.56.105   rac-scan.localdomain rac-scan
#192.168.56.106   rac-scan.localdomain rac-scan
#192.168.56.107   rac-scan.localdomain rac-scan


Obs: Em cada VM, eu tenho 3 adaptadores de rede, a primeira NAT, a segunda Host 
only (publica) e a terceira Internal network (privada)

As maquinas RAC1 e RAC2 se comunicam pela rede PUBLICA e pela rede PRIVADA 
(pingando pelo IP ou pelo host).

Mas se eu pingar o endereço virtual ou pelo SCAN, não funciona.

Quando eu chego na instalação do GI na parte GRID PLUG and PLAY information, o 
erro abaixo é gerado:

[INS-40718]

Single Client Access Name (SCAN): rac-scan.localdomain could not be resolved.


Alguém sabe como posso resolver essa situação?

[oracle_br] Erro instalação RAC

[Carlos Eduardo carloseduard...@yahoo.com [oracle_br]]

Cenário: 
GI and DB 12cR1OEL 6.9Virtual BOX (sem servidor DNS/GNS)
Dois nós

# Public192.168.56.101   rac1.localdomain        rac1192.168.56.102   
rac2.localdomain        rac2# Private192.168.1.101   rac1-priv.localdomain   
rac1-priv192.168.1.102   rac2-priv.localdomain   rac2-priv# 
Virtual192.168.56.103  rac1-vip.localdomain    rac1-vip192.168.56.104  
rac2-vip.localdomain    rac2-vip# SCAN#192.168.56.105   rac-scan.localdomain 
rac-scan#192.168.56.106   rac-scan.localdomain rac-scan#192.168.56.107   
rac-scan.localdomain rac-scan

Obs: Em cada VM, eu tenho 3 adaptadores de rede, a primeira NAT, a segunda Host 
only (publica) e a terceira Internal network (privada)
As maquinas RAC1 e RAC2 se comunicam pela rede PUBLICA e pela rede PRIVADA 
(pingando pelo IP ou pelo host).
Mas se eu pingar o endereço virtual ou pelo SCAN, não funciona.
Quando eu chego na instalação do GI na parte GRID PLUG and PLAY information, o 
erro abaixo é gerado:
[INS-40718] 
Single Client Access Name (SCAN): rac-scan.localdomain could not be resolved.

Alguém sabe como posso resolver essa situação?

Re: [oracle_br] impdp

[Mario Rodrigues marioirodrig...@gmail.com [oracle_br]]

Vlw Chiappa é exatamente isso que estou fazendo ... obrigado!


Em 13 de abril de 2017 18:04, Mario Rodrigues 
escreveu:

> Vlw Chiappa .. é exatamente isos
>
>
> Em 13 de abril de 2017 18:02, jlchia...@yahoo.com.br [oracle_br] <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>>
>>
>> Ok : entendo que por enquanto os volumes de dados reais vindos da
>> Produção estão cabendo no Oracle XE, E no momento a Aplicação não está
>> usando nenhum recurso que inexiste no XE,  por isso vc estava usando o XE
>> (já que ele é free pra qualquer tipo de dado, em qualquer ambiente , com
>> código prod ou não, nada importa) enquanto não é licenciado um RDBMS full
>> que vai virar Prod e nessa ocasião vai ultrapassar o tamanho de dados
>> permitido no XE, tendi
>>  Muito bem, minha Recomendação seria nesse meio-tempo enquanto o pessoal
>> tá providenciando um banco FULL vc ir fazendo seus testes/desenvolvimentos
>> em cima desses dados reais mas em pequeno volume no XE mesmo...
>>   Para que o import possa ocorrer vc vai criar um banco XE novo e usar
>> uma das opções que indiquei em URLs anteriores - acredito que a melhor seja
>> a opção de fazer o import criar as tabelas sem dados E delimitrada por BYTE
>> mesmo que nem deve estar vindo da Produção/origem  e depois rodar o
>> scriptzinho que altera as colunas string de delimitado em BYTEs para
>> delimitado em CHARs Feito isso aí vc roda o import de dados
>>
>> []s
>>
>>   Chiappa
>> 
>>
>
>

Re: [oracle_br] impdp

[Mario Rodrigues marioirodrig...@gmail.com [oracle_br]]

Vlw Chiappa .. é exatamente isos


Em 13 de abril de 2017 18:02, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Ok : entendo que por enquanto os volumes de dados reais vindos da Produção
> estão cabendo no Oracle XE, E no momento a Aplicação não está usando nenhum
> recurso que inexiste no XE,  por isso vc estava usando o XE (já que ele é
> free pra qualquer tipo de dado, em qualquer ambiente , com código prod ou
> não, nada importa) enquanto não é licenciado um RDBMS full que vai virar
> Prod e nessa ocasião vai ultrapassar o tamanho de dados permitido no XE,
> tendi
>  Muito bem, minha Recomendação seria nesse meio-tempo enquanto o pessoal
> tá providenciando um banco FULL vc ir fazendo seus testes/desenvolvimentos
> em cima desses dados reais mas em pequeno volume no XE mesmo...
>   Para que o import possa ocorrer vc vai criar um banco XE novo e usar uma
> das opções que indiquei em URLs anteriores - acredito que a melhor seja a
> opção de fazer o import criar as tabelas sem dados E delimitrada por BYTE
> mesmo que nem deve estar vindo da Produção/origem  e depois rodar o
> scriptzinho que altera as colunas string de delimitado em BYTEs para
> delimitado em CHARs Feito isso aí vc roda o import de dados
>
> []s
>
>   Chiappa
> 
>

Re: [oracle_br] impdp

[jlchia...@yahoo.com.br [oracle_br]]

Ok : entendo que por enquanto os volumes de dados reais vindos da Produção 
estão cabendo no Oracle XE, E no momento a Aplicação não está usando nenhum 
recurso que inexiste no XE,  por isso vc estava usando o XE (já que ele é free 
pra qualquer tipo de dado, em qualquer ambiente , com código prod ou não, nada 
importa) enquanto não é licenciado um RDBMS full que vai virar Prod e nessa 
ocasião vai ultrapassar o tamanho de dados permitido no XE, tendi
 Muito bem, minha Recomendação seria nesse meio-tempo enquanto o pessoal tá 
providenciando um banco FULL vc ir fazendo seus testes/desenvolvimentos em cima 
desses dados reais mas em pequeno volume no XE mesmo...
  Para que o import possa ocorrer vc vai criar um banco XE novo e usar uma das 
opções que indiquei em URLs anteriores - acredito que a melhor seja a opção de 
fazer o import criar as tabelas sem dados E delimitrada por BYTE mesmo que nem 
deve estar vindo da Produção/origem  e depois rodar o scriptzinho que altera as 
colunas string de delimitado em BYTEs para delimitado em CHARs Feito isso 
aí vc roda o import de dados

[]s

  Chiappa

Re: [oracle_br] Re: Erro ORA-10693 - ressurgindo das cinzas

[jlchia...@yahoo.com.br [oracle_br]]

Ah tá, tá explicado, vc passou batido na questão de renomear o path pra 
tablespace TEMP, aí o RDBMS foi tentar (baseado na lista do controlfile) criar 
a tablespace tempo num local/path que não existia no servidor destino,  tá 
explicado... okdoc, curiosidade matada...

[]s

  Chiappa

Re: [oracle_br] impdp

[Mario Rodrigues marioirodrig...@gmail.com [oracle_br]]

Exatamente o X da questão é teste hoje .. mas vai virar produção e os dados
do teste SÃO REAIS.

Infelizmente é a realidade rsrsrs .. já conversei com o diretor e estamos
vendo licenças .. vlw pessoal


Em 13 de abril de 2017 15:25, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Exatamente, embora depende de que tipo de DESENVOLVIMENTO e/ou TESTES que
> vão ser feitos nesse banco aí : se são testes com dados ** reais ** vindos
> de Produção, e/ou se o código sendo Desenvolvido vai fazer parte de um
> Produto/Aplicativo que vai ser vendido e gerar lucro OU vai ser usado em
> Produção a licença de Desenvolvimento do OTN Absolutamente Não é Válida
> nesse cenário, aí é OU usar o XE OU comprar Licença de Standard ou
> Enterprise, sim, sim
>
>  Já se os dados NÃO SÃO dados reais de um cliente seu nem da sua Produção,
> E qquer código desenvolvido nesse banco NÃO VAI SER executado em produção e
> nem vendido para seus clientes (ou seja, esse código é só uma POC, uma
> Prova de Conceito, um teste simples pra vc ver se um ponto está funcionando
> bem, ou para aprender uma determinada tecnologia, sem dados reais e SEM
> reaproveitar em PROD o código) realmente, a licença Developer do OTN diz
> Claramente que pra esses casos vc está 100% no direito de baixar qquer
> versão de banco Enterprise ou Standard lá no OTN e usar `à vontade, sem
> custo nenhum E por quanto tempo quiser... SE o uso lá do colega se encaixa
> nessas restrições Sim, seria legal ele baixar no OTN e passar a usar ou
> Standard ou Enterprise, pois (entre outras vantagens) nesses bancos se pode
> mudar o CHARACTERSET tranquilinho
>
>  []s
>
>Chiappa
> 
>

Re: [oracle_br] Re: Erro ORA-10693 - ressurgindo das cinzas

[angelo angelolis...@gmail.com [oracle_br]]

Não criou porque a restauração apontou para um volume que não existe ( era
apontamento de path da outra maquina), acho que passou batido na
configuracao do newid
Só percebi quando fui rodar pela 1a vez o NID.

Então para dropar o tablespace, só criando outro temp como padrão (com um
caminho existente)

vou fazer o texto


2017-04-13 15:55 GMT-03:00 jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br>:

>
>
> Ah, se vc for eventualmente criar um texto com o seu exemplo de backup e
> restore pra gente tentar saber por que o RMAN não criou a tablespace TEMP
> sozinho pra vc, plz faça algo tipo o que eu fiz em
> https://pastebin.com/W0A1w5AL , bem passo-a-passo mesmo, E principalmente
> mostrando como estava e como ficou a config de banco E do RMAN, okdoc ? Aí
> quem puder/quiser ter a curiosidade de tentar reproduzir o seu caso
> consegue...
>
> []s
>
>   Chiappa
> 
>

Re: [oracle_br] Re: Erro ORA-10693 - ressurgindo das cinzas

[jlchia...@yahoo.com.br [oracle_br]]

Ah, se vc for eventualmente criar um texto com o seu exemplo de backup e 
restore pra gente tentar saber por que o RMAN não criou a tablespace TEMP 
sozinho pra vc, plz faça algo tipo o que eu fiz em 
https://pastebin.com/W0A1w5AL https://pastebin.com/W0A1w5AL , bem passo-a-passo 
mesmo, E principalmente mostrando como estava e como ficou a config de banco E 
do RMAN, okdoc ? Aí quem puder/quiser ter a curiosidade de tentar reproduzir o 
seu caso consegue...

[]s

  Chiappa

Re: [oracle_br] impdp

[jlchia...@yahoo.com.br [oracle_br]]

Exatamente, embora depende de que tipo de DESENVOLVIMENTO e/ou TESTES que vão 
ser feitos nesse banco aí : se são testes com dados ** reais ** vindos de 
Produção, e/ou se o código sendo Desenvolvido vai fazer parte de um 
Produto/Aplicativo que vai ser vendido e gerar lucro OU vai ser usado em 
Produção a licença de Desenvolvimento do OTN Absolutamente Não é Válida nesse 
cenário, aí é OU usar o XE OU comprar Licença de Standard ou Enterprise, sim, 
sim 

 Já se os dados NÃO SÃO dados reais de um cliente seu nem da sua Produção, E 
qquer código desenvolvido nesse banco NÃO VAI SER executado em produção e nem 
vendido para seus clientes (ou seja, esse código é só uma POC, uma Prova de 
Conceito, um teste simples pra vc ver se um ponto está funcionando bem, ou para 
aprender uma determinada tecnologia, sem dados reais e SEM reaproveitar em PROD 
o código) realmente, a licença Developer do OTN diz Claramente que pra esses 
casos vc está 100% no direito de baixar qquer versão de banco Enterprise ou 
Standard lá no OTN e usar `à vontade, sem custo nenhum E por quanto tempo 
quiser... SE o uso lá do colega se encaixa nessas restrições Sim, seria legal 
ele baixar no OTN e passar a usar ou Standard ou Enterprise, pois (entre outras 
vantagens) nesses bancos se pode mudar o CHARACTERSET tranquilinho
 
 []s
 
   Chiappa

Re: [oracle_br] Re: Erro ORA-10693 - ressurgindo das cinzas

[jlchia...@yahoo.com.br [oracle_br]]

Perfeitamente, pelo jeito vc caiu exatamente no mesmo caso que eu, ie, já tinha 
backup posterior ao que eu queria registrado no controlfile que recuperei e o 
restore por default vai no último... Tem outras maneiras de se evitar isso (pra 
isso é que foi criado a opção de TAG no RMAN, vc indica EXATAMENTE a partir de 
qual backup vc quer restaurar mas IMHO é *** IMENSAMENTE MAIS SIMPLES e DIRETO 
*** em casos de catálogo dentro do controlfile simplesmente se apagar TUDO que 
estava catalogado antes imediatamente assim que restaurar o controlfile, como 
vc fez ao que entendo, é o que eu Prefiro também

 Muito bem, "problema" resolvido... Só achei curioso o fato que vc teve que 
criar na mão a tablespace temp num backup hot, via de regra ela NUNCA é 
backupeada num backup hot (já que toda e qualquer informação nela contida NÃO É 
CONSISTENTE com nada, vc não precisa de NADA que esteja numa tablespace temp 
pra voltar o banco pro último ponto consistente) , e assim o RMAN sempre criava 
sozinho uma nova pra mim no restore - se puder, pra matar a curiosidade, plz 
registra num texto como que tava configurado seu RMAN e como foi feito o backup 
e cada passo do restore, pra gente ficar sabendo o que que estava diferente no 
seu ambiente que exigiu essa intervenção manual a mais...
 
 Como vc diz que já tinha alterado todos os parâmetros para apontarem pros 
novos paths , creio que agora é mesmo só trocar o SID, o  nome do banco ** E ** 
trocar o dbid (não há problema técnico em vc ter dois bancos com o mesmo nome e 
mesmo dbid e/ou mesmo SID rodando em servidores diferentes MAS 
administrativamente isso é um Risco, eu não faço isso nem que me amarrem, não 
gosto disso) e tá feita a fofoca, sim... 
 
 []s
 
   Chiappa
   
==> OBS : EVIDENTEMENTE, não há problema técnico nenhum em vc ter eventuais 
sub-diretórios administrativos, nomes de archives ou demais componentes que 
ainda tenham na sua nomenclatura / prefixo o nome e/ou o SID antigos lá do 
banco original, mas Recomendo que vc os altere, também : tecnicamente não pega 
NADINHA DE NADA mas Administrativamente eu não gosto disso, eu prefiro manter 
tudo logicamente relacionado bonitinho...

Re: [oracle_br] impdp

[Luis Freitas lfreita...@yahoo.com [oracle_br]]

Mario,
   Se você não vai usar este sistema em produção, está fazendo testes ou 
desenvolvimento, pode usar uma versão full com a licença "OTN", que não tem 
custo.
    Mas para isso não pode ter esse sistema em produção ai na empresa ou 
organização onde você está. Se tiver uma produção do sistema, a licença OTN não 
vale.
Atc,Luis Freitas 

On Wednesday, April 12, 2017 4:35 PM, "jlchia...@yahoo.com.br [oracle_br]" 
 wrote:
 

     Intão, Angelo : sim, muito provavelmente corrompeu o XE atual mas como era 
uma instância de testes e POCs pelo que entendi então não vale a pena o 
trabalho de tentar consertar, é criar outra  instância mesmo... 
 Agora, não necessariamente essa nova instância ** Obrigatoriamente ** teria 
que ser algo 'full', ie, Standard ou Enterprise : seria interessante se pudesse 
ser algo acima do XE (pois entre outras coisas assim o cara poderia testar 
recursos não disponíveis no XE) mas se isso não for viável (principalmente por 
causa de CUSTOS!!), é ** TOTALMENTE POSSÍVEL ** vc importar dumps de banco 
'full' no e repetir testes / executar rotinas no XE mesmo que elas foram 
originalmente desenvolvidas num banco 'full', *** RESPEITANDO-SE os limites e 
ausências do XE
 
 []s
 
   Chiappa  #yiv9047748934 #yiv9047748934 -- #yiv9047748934ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9047748934 
#yiv9047748934ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9047748934 
#yiv9047748934ygrp-mkp #yiv9047748934hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv9047748934 #yiv9047748934ygrp-mkp #yiv9047748934ads 
{margin-bottom:10px;}#yiv9047748934 #yiv9047748934ygrp-mkp .yiv9047748934ad 
{padding:0 0;}#yiv9047748934 #yiv9047748934ygrp-mkp .yiv9047748934ad p 
{margin:0;}#yiv9047748934 #yiv9047748934ygrp-mkp .yiv9047748934ad a 
{color:#ff;text-decoration:none;}#yiv9047748934 #yiv9047748934ygrp-sponsor 
#yiv9047748934ygrp-lc {font-family:Arial;}#yiv9047748934 
#yiv9047748934ygrp-sponsor #yiv9047748934ygrp-lc #yiv9047748934hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9047748934 
#yiv9047748934ygrp-sponsor #yiv9047748934ygrp-lc .yiv9047748934ad 
{margin-bottom:10px;padding:0 0;}#yiv9047748934 #yiv9047748934actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9047748934 
#yiv9047748934activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9047748934
 #yiv9047748934activity span {font-weight:700;}#yiv9047748934 
#yiv9047748934activity span:first-child 
{text-transform:uppercase;}#yiv9047748934 #yiv9047748934activity span a 
{color:#5085b6;text-decoration:none;}#yiv9047748934 #yiv9047748934activity span 
span {color:#ff7900;}#yiv9047748934 #yiv9047748934activity span 
.yiv9047748934underline {text-decoration:underline;}#yiv9047748934 
.yiv9047748934attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv9047748934 .yiv9047748934attach div a 
{text-decoration:none;}#yiv9047748934 .yiv9047748934attach img 
{border:none;padding-right:5px;}#yiv9047748934 .yiv9047748934attach label 
{display:block;margin-bottom:5px;}#yiv9047748934 .yiv9047748934attach label a 
{text-decoration:none;}#yiv9047748934 blockquote {margin:0 0 0 
4px;}#yiv9047748934 .yiv9047748934bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv9047748934 
.yiv9047748934bold a {text-decoration:none;}#yiv9047748934 dd.yiv9047748934last 
p a {font-family:Verdana;font-weight:700;}#yiv9047748934 dd.yiv9047748934last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv9047748934 
dd.yiv9047748934last p span.yiv9047748934yshortcuts 
{margin-right:0;}#yiv9047748934 div.yiv9047748934attach-table div div a 
{text-decoration:none;}#yiv9047748934 div.yiv9047748934attach-table 
{width:400px;}#yiv9047748934 div.yiv9047748934file-title a, #yiv9047748934 
div.yiv9047748934file-title a:active, #yiv9047748934 
div.yiv9047748934file-title a:hover, #yiv9047748934 div.yiv9047748934file-title 
a:visited {text-decoration:none;}#yiv9047748934 div.yiv9047748934photo-title a, 
#yiv9047748934 div.yiv9047748934photo-title a:active, #yiv9047748934 
div.yiv9047748934photo-title a:hover, #yiv9047748934 
div.yiv9047748934photo-title a:visited {text-decoration:none;}#yiv9047748934 
div#yiv9047748934ygrp-mlmsg #yiv9047748934ygrp-msg p a 
span.yiv9047748934yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv9047748934 
.yiv9047748934green {color:#628c2a;}#yiv9047748934 .yiv9047748934MsoNormal 
{margin:0 0 0 0;}#yiv9047748934 o {font-size:0;}#yiv9047748934 
#yiv9047748934photos div {float:left;width:72px;}#yiv9047748934 
#yiv9047748934photos div div {border:1px solid 
#66;height:62px;overflow:hidden;width:62px;}#yiv9047748934 
#yiv9047748934photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv9047748934
 

Re: [oracle_br] Re: Erro ORA-10693 - ressurgindo das cinzas

[angelo angelolis...@gmail.com [oracle_br]]

Vamos lá..

Origem era 11.2.0.4

Destino:  11.2.0.4  ( foi instalado do zero, substituindo o antigo, na
maquina desenv )

backup de origem: Hot  (full + archivelogs)

tudo windows x64

Eu já consegui resolver e restaurar o backup. Fiz examente isso.. apaguei
tudo do repositorio do rman e cataloguei novamente, pegando um backup de
ontem a noite.  O servidor original tinha catalogo.  Esse nao tem e nem vai
ter.

O mexe / remexe de trocar caminho das pastas newid etc, era porque o
servidor origem tem discos onde os arquivos estavam espalhados

Nessa maquina só tem  C:\  e  D:\  e foram todos moram no D:\ORACLE

Como já havia tentado restaurar o backup antes e tinha topado com o
problema e também, já havia alterado o pfile, o controle e tudo mais, para
deixar tudo apontando para as pastas no D:\
A segunda tentativa de restauração foi relax.  O sistema já encontrou tudo
e aí fluiu

Um detalhe que precisei recriar  o tablespace TEMP  default novamente a
base subiu apontando pra pasta e depois recriar os redos.

Eu to montando um passo a passo de backup/restore e colocando nele todas
essas coisas que acontecem no meio do caminho até pra usar como referencia
já que não é algo que eu faça toda hora.

Próximo passo vai ser renomear a base, via nid



2017-04-13 12:41 GMT-03:00 jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br>:

>
>
> Xô entender : o database-origem está rodando em QUAL exata versão de
> binários, é essa mesma 11.2.0.4 cujos binários vc instalou na máquina
> destino ?? SE NÃO FOR, provavelmente vc vai ter que depois de restaurar
> fazer um startup upgrade e executar os scripts de recriação do dicionário
> de dados, ie, o catalog.sql e catproc.sql, bem como um utlrp depois...
>
> Prosseguindo : se vc leu minha thread original, vc vai ver que no meu caso
> o primeiro problema foi que meus backups todos estavam sendo registrados em
> controlfile e não em banco de catálogo (vc não diz mas PARECE ser esse seu
> caso) e casualmente eu tinha registrado nesse controlfile backups MAIS
> RECENTES do que aquele cujos backup files eu estava tentando restaurar
> A solução foi simplesmente *** apagar *** todos os backups outros que já
> estavam nesse controlfile após o restore dele, ou seja, , toricar o
> procedimento de (depois que os backup files já foram disponibilizados no
> servidor destino) :
>
> "criar o pfile,  voltar o spfile, editar, criar o spfile, criar as
> pastinhas, restaurar o control,  catalogar, restaurar a base,..."
>
> para :
>
> "criar o pfile,  voltar o spfile, editar, criar o spfile, criar as
> pastinhas, restaurar o control,  APAGAR TODOS OS BACKUPS REGISTRADOS
> NESSE CONTROLFILE ***,  catalogar, restaurar a base,"
>
> faça isso, mal não faz, sim sim ??
>
> ===>> Meu OUTRO problema é que não tinham me passado que era backup COLD,
> aí eu ficava que nem tonto tentando fazer recover depois do restore... Aí
> vem a pergunta, DE QUE TIPO é esse backup que vc está tentando voltar, QUAL
> os SCNs contidos nos archives que vc dispõe se for backup HOT, como está o
> SCN dos datafiles, como está o SCN do controlfile ??? Com essa info vc vai
> ser capaz de identificar se precisa fazer ou não recover depois do restore
> (e UNTIL até quando, se for o caso de RESTORE), confirmar que vc tem TODOS
> os archives na sequência bonitinhos se for HOT... Sim sim sim ???
>
> []s
>
>   Chiappa
>
> OBS :
>
>   a.  eu notei que vc falou que vai "trocar os caminhos" , provavelmente
> porque na máquina destino o caminho para os datafiles é diferente, né ? Não
> esqueça de que (SE vc não está usando arquivos criados automaticamente pelo
> RDBMS) vc precisa  usar o comando para isso, pode ser o SET NEWNAME direto
> no RMAN, pode ser executando comandos SQL padrão tipo ALTER DATABASE RENAME
> FILE 'xxx' TO 'yyy'... Eu prefiro sempre  executar um comando para cada
> arquivo a renomear/mudar de path, pois assim tenho CERTEZA que não esqueci
> nenhum, não confio/não gosto das opções de trocar o destino geral...
>   E não esqueça que *** OUTROS *** paths podem precisar ser mudados nos
> parâmetros do banco : *** LISTE *** na íntegra os parâmetros do
> banco-origem e CONFIRME que todos os parâmetros que indicam algum PATH
> (aonde gravar log, controlfiles, dumps, etc, etc, etc) estão apontando para
> PATHs válidos/apropriados...
>
>   b. Não É INCOMUM que vc queira mudar o NOME do database e/ou da
> instância, etc no novo servidor : SE houver essa necessidade, veja os
> comandos apropriados, que pode ser dbnewid, pode ser recriar o controlfile
> a partir do backup to trace ou outros cfrme preferir... Logicamente, depois
> de trocado o nome da instância/do database tipicamente vc tem que RECRIAR
> ou RENOMEAR arquivos que contém no nome referência para a
> instância/database original, como initfiles, archives, etc
>E por ORGANIZAÇÃO também é mega-comum que os diretórios Administrativos
> do database contenham o nome dele, se vc renomear o database por questão de
> Organização normalmente se 

[oracle_br] Re: Erro ORA-10693 - ressurgindo das cinzas

[jlchia...@yahoo.com.br [oracle_br]]

Xô entender : o database-origem está rodando em QUAL exata versão de binários, 
é essa mesma 11.2.0.4 cujos binários vc instalou na máquina destino ?? SE NÃO 
FOR, provavelmente vc vai ter que depois de restaurar fazer um startup upgrade 
e executar os scripts de recriação do dicionário de dados, ie, o catalog.sql e 
catproc.sql, bem como um utlrp depois...

Prosseguindo : se vc leu minha thread original, vc vai ver que no meu caso o 
primeiro problema foi que meus backups todos estavam sendo registrados em 
controlfile e não em banco de catálogo (vc não diz mas PARECE ser esse seu 
caso) e casualmente eu tinha registrado nesse controlfile backups MAIS RECENTES 
do que aquele cujos backup files eu estava tentando restaurar A solução foi 
simplesmente *** apagar *** todos os backups outros que já estavam nesse 
controlfile após o restore dele, ou seja, , toricar o procedimento de (depois 
que os backup files já foram disponibilizados no servidor destino) :

"criar o pfile,  voltar o spfile, editar, criar o spfile, criar as pastinhas, 
restaurar o control,  catalogar, restaurar a base,..."

para :

"criar o pfile,  voltar o spfile, editar, criar o spfile, criar as pastinhas, 
restaurar o control,  APAGAR TODOS OS BACKUPS REGISTRADOS NESSE CONTROLFILE 
***,  catalogar, restaurar a base,"

faça isso, mal não faz, sim sim ??

===>> Meu OUTRO problema é que não tinham me passado que era backup COLD, aí eu 
ficava que nem tonto tentando fazer recover depois do restore... Aí vem a 
pergunta, DE QUE TIPO é esse backup que vc está tentando voltar, QUAL os SCNs 
contidos nos archives que vc dispõe se for backup HOT, como está o SCN dos 
datafiles, como está o SCN do controlfile ??? Com essa info vc vai ser capaz de 
identificar se precisa fazer ou não recover depois do restore (e UNTIL até 
quando, se for o caso de RESTORE), confirmar que vc tem TODOS os archives na 
sequência bonitinhos se for HOT... Sim sim sim ???

[]s

  Chiappa
  
OBS :

  a.  eu notei que vc falou que vai "trocar os caminhos" , provavelmente porque 
na máquina destino o caminho para os datafiles é diferente, né ? Não esqueça de 
que (SE vc não está usando arquivos criados automaticamente pelo RDBMS) vc 
precisa  usar o comando para isso, pode ser o SET NEWNAME direto no RMAN, pode 
ser executando comandos SQL padrão tipo ALTER DATABASE RENAME FILE 'xxx' TO 
'yyy'... Eu prefiro sempre  executar um comando para cada arquivo a 
renomear/mudar de path, pois assim tenho CERTEZA que não esqueci nenhum, não 
confio/não gosto das opções de trocar o destino geral...
  E não esqueça que *** OUTROS *** paths podem precisar ser mudados nos 
parâmetros do banco : *** LISTE *** na íntegra os parâmetros do banco-origem e 
CONFIRME que todos os parâmetros que indicam algum PATH (aonde gravar log, 
controlfiles, dumps, etc, etc, etc) estão apontando para PATHs 
válidos/apropriados...

  b. Não É INCOMUM que vc queira mudar o NOME do database e/ou da instância, 
etc no novo servidor : SE houver essa necessidade, veja os comandos 
apropriados, que pode ser dbnewid, pode ser recriar o controlfile a partir do 
backup to trace ou outros cfrme preferir... Logicamente, depois de trocado o 
nome da instância/do database tipicamente vc tem que RECRIAR ou RENOMEAR 
arquivos que contém no nome referência para a instância/database original, como 
initfiles, archives, etc
   E por ORGANIZAÇÃO também é mega-comum que os diretórios Administrativos do 
database contenham o nome dele, se vc renomear o database por questão de 
Organização normalmente se renomeia Também esses diretórios...

Re: [oracle_br] ORA-19816: Ajuda

[Paulo Jr paulobarbosa....@gmail.com [oracle_br]]

Já verificou se tem alguma ferramenta que faz cópia e bloqueia a gravação
no disco, já vi algo desse tipo.





*Abraços,*

*Paulo Barbosa*

*skype: paulobarbosa.sp*
*Cel.: (11) 98869-0988*

2017-04-13 9:57 GMT-03:00 alisson daniel alisson...@yahoo.com.br
[oracle_br] :

>
>
>
>  Olá Paulo,
>
> Foi a primeira coisa que fiz. Mas o erro retorna com o tempo.
>
> *Action:* Use RMAN command CATALOG RECOVERY AREA to re-catalog any such files.
>   If the file header is corrupted, then delete those files using an OS
>   utility. Do not use messages 19817; it is used for simulating lock
>   failure Do not use messages 19818; it is used for space reclamation
>   before backup Do not use messages 19819; it is used to disable clearing
>   file name
>
>
>
>
> Em Quinta-feira, 13 de Abril de 2017 9:51, "Paulo Jr
> paulobarbosa@gmail.com [oracle_br]" 
> escreveu:
>
>
>
> olha essa nota e veja se resolve.
>
>
>
> OERR: ORA-19816 "WARNING: Files may exist in %s that are not known to
> database." Reference Note (Doc ID 288181.1)
>
>
>
>
>
>
> *Abraços,*
>
> *Paulo Barbosa*
>
> *skype: paulobarbosa.sp*
> *Cel.: (11) 98869-0988*
>
> 2017-04-13 9:37 GMT-03:00 alisson daniel alisson...@yahoo.com.br
> [oracle_br] :
>
>
> Olá Angelo,
>
> As permissões estão ok, inclusive ele grava os archives logs ( tenho
> vários de hoje ).
>
>
>
>
> Em Quinta-feira, 13 de Abril de 2017 9:12, "angelo angelolis...@gmail.com
> [oracle_br]"  escreveu:
>
>
>
> Permissões de ntfs nessa pasta como estão ?
>
> Parece que a base não consegue escrever no disco
>
>
>
> OSD-04002: unable to open file
> O/S-Error: (OS 1392) The file or directory is corrupted and unreadable.
> Unable to create archive log file 'E:\BDEDUCAR\ARCHIVELOG\2017_
> 04_11\O1_MF_1_421421_%U_.ARC'
> ORA-19816: WARNING: Files may exist in db_recovery_file_dest that are not
> known to database.
> ORA-27040: file create error, unable to create file
> OSD-04002: unable to open file
> O/S-Error: (OS 1392) The file or directory is corrupted and unreadable.
>
>
> On 13 April 2017 at 08:43, alisson...@yahoo.com.br [oracle_br] <
> oracle_br@yahoogrupos.com.br> wrote:
>
>
> Bom dia a todos,
>
> começou a apresentar erros no banco aqui ,
>
> Estou com a versão Oracle Database 11g Enterprise Edition Release
> 11.2.0.4.0 - 64bit Product , com todos os pacth atualizados.
> Uso Windows Server 2012 R2
>
> Fiz o procedimento sugerido Catalog Recovery area, mas o erro persiste
> depois de algum tempo.
>
> Alguém pode me ajudar nesse processo ? me dizendo se já passou por isso ?
>
> Grato.
>
>
>
> ORA-19816: WARNING: Files may exist in db_recovery_file_dest that are not
> known to database.
> ORA-27040: file create error, unable to create file
> OSD-04002: unable to open file
> O/S-Error: (OS 1392) The file or directory is corrupted and unreadable.
>
> *** 2017-04-11 22:18:23.726
> Unable to create archive log file 'E:\BDEDUCAR\ARCHIVELOG\2017_
> 04_11\O1_MF_1_421421_%U_.ARC'
> ORA-19816: WARNING: Files may exist in db_recovery_file_dest that are not
> known to database.
> ORA-27040: file create error, unable to create file
> OSD-04002: unable to open file
> O/S-Error: (OS 1392) The file or directory is corrupted and unreadable.
> ** ** *
> WARNING: A file of type ARCHIVED LOG may exist in
> db_recovery_file_dest that is not known to the database.
> Use the RMAN command CATALOG RECOVERY AREA to re-catalog
> any such files. If files cannot be cataloged, then manually
> delete them using OS command. This is most likely the
> result of a crash during file creation.
>
>
>
>
>
>
>
>
>
> 
>

Re: [oracle_br] ORA-19816: Ajuda

[jlchia...@yahoo.com.br [oracle_br]]

A msg parece que tá clara aqui :

ORA-27040: file create error, unable to create file
OSD-04002: unable to open file
O/S-Error: (OS 1392) The file or directory is corrupted and unreadable.

OU SEJA, o archiver não tá conseguindo criar/abrir corretamente o arquivo... O 
busílis é que há ** trocentas ** causas possível para que o SO não consiga 
abrir um arquivo, vc vai ter que validar todas Por exemplo, 
http://www.databasejournal.com/features/oracle/article.php/3867646/Oracle-Database-Archive-LoggingWhere-are-my-archive-logs.htm
 mostra um caso sutil, onde o asn... - digo, DBA :) deixou LOG_ARCHIVE_DEST 
igual ao LOG_ARCHIVE_DEST_1, besteira feita E há ** diversos ** parâmetros 
relacionados a archive (além das 10 destinations extras possíveis, neguim 
Sempre esquece de outros como log_archive_duplex_dest ) : vc VAI TER QUE checar 
CUIDADOSAMENTE cada um deles
 Outra possibilidade é que (por qualquer besteira operacional) alguém já tenha 
criado (ou restaurado, copiado, enfim) nesse disco/diretório/destino  um 
arquivo com o mesmo nome do que o archiver tá tentando criar, só dá besteira 
isso
  Outra coisa, talvez haja um CARACTER ESPECIAL / espaço em branco no arquivo 
em disco ?
  E outro ponto, talvez o mais CRÍTICO DE TODOS : achei MEGA-ESTRANHA essa msg :
  
  Unable to create archive log file 'E:\BDEDUCAR\ARCHIVELOG\2017_ 
04_11\O1_MF_1_421421_%U_.ARC'
  
  Pois acontece que , SE vc olhar o manual 11gR2 para formato de log archives 
(online em 
https://docs.oracle.com/cd/E18283_01/server.112/e17110/initparams124.htm) vc 
encontra :
  
  ""
  
  LOG_ARCHIVE_FORMAT
Property Description
Parameter type String
Syntax LOG_ARCHIVE_FORMAT = filename
Default value Operating system-dependent
Modifiable No
Range of values Any string that resolves to a valid filename
Basic No
Oracle RAC Multiple instances can have different values, but identical 
values are recommended.

LOG_ARCHIVE_FORMAT is applicable only if you are using the redo log in 
ARCHIVELOG mode. Use a text string and variables to specify the default 
filename format when archiving redo log files. The string generated from this 
format is appended to the string specified in the LOG_ARCHIVE_DEST parameter.

The following variables can be used in the format:

%s log sequence number

%S log sequence number, zero filled

%t thread number

%T thread number, zero filled

%a activation ID

%d database ID

%r resetlogs ID that ensures unique names are constructed for the archived log 
files across multiple incarnations of the database
  destination in the V$ARCHIVE_DEST
"

>> ABSOLUTAMENTE NÃO HÁ REFERÊNCIA a esse %U como um formatador 
Válido/Documentado, de onde é que está vindo isso pelo amor dos deuses ?? 
iirc %U é um delimitador/formatdor válido para BACKUP FILES, mas iirc NÃO PARA 
LOG FILES !

Alguma coisa de errado NÂO ESTÁ CERTA, concorda ??? Será que algum neguim 
arteiro não indicou pro archive %U como parte do nome de archive a gerar, aí 
não sendo um delimitar válido ele interpreta como uma string real a botar no 
nome do arquivo, e aí o Windows REJEITA esse arquivo, pois como Documentado em 
trocentos lugares 
(https://technet.microsoft.com/pt-br/library/ms163853(v=sql.105).aspx é um 
deles) o Windows *** não aceita *** caracter % no meio dum nome de arquivo ?

 Veja lá
 
 []s
 
   Chiappa

Re: [oracle_br] ORA-19816: Ajuda

[alisson daniel alisson...@yahoo.com.br [oracle_br]]

 Olá Paulo,
Foi a primeira coisa que fiz. Mas o erro retorna com o tempo. Action: Use RMAN 
command CATALOG RECOVERY AREA to re-catalog any such files. 
If the file header is corrupted, then delete those files using an OS 
utility. Do not use messages 19817; it is used for simulating lock 
failure Do not use messages 19818; it is used for space reclamation 
before backup Do not use messages 19819; it is used to disable clearing 
file name 
 

Em Quinta-feira, 13 de Abril de 2017 9:51, "Paulo Jr 
paulobarbosa@gmail.com [oracle_br]"  escreveu:
 

     olha essa nota e veja se resolve.



| OERR: ORA-19816 "WARNING: Files may exist in %s that are not known to 
database." Reference Note (Doc ID 288181.1)



 |




Abraços,
Paulo Barbosaskype: paulobarbosa.sp
Cel.: (11) 98869-0988

2017-04-13 9:37 GMT-03:00 alisson daniel alisson...@yahoo.com.br [oracle_br] 
:

     Olá Angelo, 
As permissões estão ok, inclusive ele grava os archives logs ( tenho vários de 
hoje ).  


 

Em Quinta-feira, 13 de Abril de 2017 9:12, "angelo angelolis...@gmail.com 
[oracle_br]"  escreveu:
 

     Permissões de ntfs nessa pasta como estão ?  

Parece que a base não consegue escrever no disco


OSD-04002: unable to open fileO/S-Error: (OS 1392) The file or directory is 
corrupted and unreadable.Unable to create archive log file 
'E:\BDEDUCAR\ARCHIVELOG\2017_ 04_11\O1_MF_1_421421_%U_.ARC'ORA-19816: WARNING: 
Files may exist in db_recovery_file_dest that are not known to 
database.ORA-27040: file create error, unable to create fileOSD-04002: unable 
to open fileO/S-Error: (OS 1392) The file or directory is corrupted and 
unreadable.

On 13 April 2017 at 08:43, alisson...@yahoo.com.br [oracle_br] 
 wrote:

     Bom dia a todos,
começou a apresentar erros no banco aqui , 
Estou com a versão Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 
64bit Product , com todos os pacth atualizados. Uso Windows Server 2012 R2
Fiz o procedimento sugerido Catalog Recovery area, mas o erro persiste depois 
de algum tempo.
Alguém pode me ajudar nesse processo ? me dizendo se já passou por isso ?
Grato.


ORA-19816: WARNING: Files may exist in db_recovery_file_dest that are not known 
to database.ORA-27040: file create error, unable to create fileOSD-04002: 
unable to open fileO/S-Error: (OS 1392) The file or directory is corrupted and 
unreadable.
*** 2017-04-11 22:18:23.726Unable to create archive log file 
'E:\BDEDUCAR\ARCHIVELOG\2017_ 04_11\O1_MF_1_421421_%U_.ARC'ORA-19816: WARNING: 
Files may exist in db_recovery_file_dest that are not known to 
database.ORA-27040: file create error, unable to create fileOSD-04002: unable 
to open fileO/S-Error: (OS 1392) The file or directory is corrupted and 
unreadable.** ** 
*WARNING: A file of type ARCHIVED LOG may exist indb_recovery_file_dest that is 
not known to the database.Use the RMAN command CATALOG RECOVERY AREA to 
re-catalogany such files. If files cannot be cataloged, then manuallydelete 
them using OS command. This is most likely theresult of a crash during file 
creation.


   

  

  

  #yiv7081389581 #yiv7081389581 -- #yiv7081389581ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv7081389581 
#yiv7081389581ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv7081389581 
#yiv7081389581ygrp-mkp #yiv7081389581hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv7081389581 #yiv7081389581ygrp-mkp #yiv7081389581ads 
{margin-bottom:10px;}#yiv7081389581 #yiv7081389581ygrp-mkp .yiv7081389581ad 
{padding:0 0;}#yiv7081389581 #yiv7081389581ygrp-mkp .yiv7081389581ad p 
{margin:0;}#yiv7081389581 #yiv7081389581ygrp-mkp .yiv7081389581ad a 
{color:#ff;text-decoration:none;}#yiv7081389581 #yiv7081389581ygrp-sponsor 
#yiv7081389581ygrp-lc {font-family:Arial;}#yiv7081389581 
#yiv7081389581ygrp-sponsor #yiv7081389581ygrp-lc #yiv7081389581hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv7081389581 
#yiv7081389581ygrp-sponsor #yiv7081389581ygrp-lc .yiv7081389581ad 
{margin-bottom:10px;padding:0 0;}#yiv7081389581 #yiv7081389581actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv7081389581 
#yiv7081389581activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv7081389581
 #yiv7081389581activity span {font-weight:700;}#yiv7081389581 
#yiv7081389581activity span:first-child 
{text-transform:uppercase;}#yiv7081389581 #yiv7081389581activity span a 
{color:#5085b6;text-decoration:none;}#yiv7081389581 #yiv7081389581activity span 
span {color:#ff7900;}#yiv7081389581 #yiv7081389581activity span 
.yiv7081389581underline {text-decoration:underline;}#yiv7081389581 
.yiv7081389581attach 

Re: [oracle_br] ORA-19816: Ajuda

[Paulo Jr paulobarbosa....@gmail.com [oracle_br]]

olha essa nota e veja se resolve.



OERR: ORA-19816 "WARNING: Files may exist in %s that are not known to
database." Reference Note (Doc ID 288181.1)






*Abraços,*

*Paulo Barbosa*

*skype: paulobarbosa.sp*
*Cel.: (11) 98869-0988*

2017-04-13 9:37 GMT-03:00 alisson daniel alisson...@yahoo.com.br
[oracle_br] :

>
>
> Olá Angelo,
>
> As permissões estão ok, inclusive ele grava os archives logs ( tenho
> vários de hoje ).
>
>
>
>
> Em Quinta-feira, 13 de Abril de 2017 9:12, "angelo angelolis...@gmail.com
> [oracle_br]"  escreveu:
>
>
>
> Permissões de ntfs nessa pasta como estão ?
>
> Parece que a base não consegue escrever no disco
>
>
>
> OSD-04002: unable to open file
> O/S-Error: (OS 1392) The file or directory is corrupted and unreadable.
> Unable to create archive log file 'E:\BDEDUCAR\ARCHIVELOG\2017_
> 04_11\O1_MF_1_421421_%U_.ARC'
> ORA-19816: WARNING: Files may exist in db_recovery_file_dest that are not
> known to database.
> ORA-27040: file create error, unable to create file
> OSD-04002: unable to open file
> O/S-Error: (OS 1392) The file or directory is corrupted and unreadable.
>
>
> On 13 April 2017 at 08:43, alisson...@yahoo.com.br [oracle_br] <
> oracle_br@yahoogrupos.com.br> wrote:
>
>
> Bom dia a todos,
>
> começou a apresentar erros no banco aqui ,
>
> Estou com a versão Oracle Database 11g Enterprise Edition Release
> 11.2.0.4.0 - 64bit Product , com todos os pacth atualizados.
> Uso Windows Server 2012 R2
>
> Fiz o procedimento sugerido Catalog Recovery area, mas o erro persiste
> depois de algum tempo.
>
> Alguém pode me ajudar nesse processo ? me dizendo se já passou por isso ?
>
> Grato.
>
>
>
> ORA-19816: WARNING: Files may exist in db_recovery_file_dest that are not
> known to database.
> ORA-27040: file create error, unable to create file
> OSD-04002: unable to open file
> O/S-Error: (OS 1392) The file or directory is corrupted and unreadable.
>
> *** 2017-04-11 22:18:23.726
> Unable to create archive log file 'E:\BDEDUCAR\ARCHIVELOG\2017_
> 04_11\O1_MF_1_421421_%U_.ARC'
> ORA-19816: WARNING: Files may exist in db_recovery_file_dest that are not
> known to database.
> ORA-27040: file create error, unable to create file
> OSD-04002: unable to open file
> O/S-Error: (OS 1392) The file or directory is corrupted and unreadable.
> ** ** *
> WARNING: A file of type ARCHIVED LOG may exist in
> db_recovery_file_dest that is not known to the database.
> Use the RMAN command CATALOG RECOVERY AREA to re-catalog
> any such files. If files cannot be cataloged, then manually
> delete them using OS command. This is most likely the
> result of a crash during file creation.
>
>
>
>
>
>
> 
>

Re: [oracle_br] ORA-19816: Ajuda

[alisson daniel alisson...@yahoo.com.br [oracle_br]]

Olá Angelo, 
As permissões estão ok, inclusive ele grava os archives logs ( tenho vários de 
hoje ).  


 

Em Quinta-feira, 13 de Abril de 2017 9:12, "angelo angelolis...@gmail.com 
[oracle_br]"  escreveu:
 

     Permissões de ntfs nessa pasta como estão ?  

Parece que a base não consegue escrever no disco


OSD-04002: unable to open fileO/S-Error: (OS 1392) The file or directory is 
corrupted and unreadable.Unable to create archive log file 
'E:\BDEDUCAR\ARCHIVELOG\2017_ 04_11\O1_MF_1_421421_%U_.ARC'ORA-19816: WARNING: 
Files may exist in db_recovery_file_dest that are not known to 
database.ORA-27040: file create error, unable to create fileOSD-04002: unable 
to open fileO/S-Error: (OS 1392) The file or directory is corrupted and 
unreadable.

On 13 April 2017 at 08:43, alisson...@yahoo.com.br [oracle_br] 
 wrote:

     Bom dia a todos,
começou a apresentar erros no banco aqui , 
Estou com a versão Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 
64bit Product , com todos os pacth atualizados. Uso Windows Server 2012 R2
Fiz o procedimento sugerido Catalog Recovery area, mas o erro persiste depois 
de algum tempo.
Alguém pode me ajudar nesse processo ? me dizendo se já passou por isso ?
Grato.


ORA-19816: WARNING: Files may exist in db_recovery_file_dest that are not known 
to database.ORA-27040: file create error, unable to create fileOSD-04002: 
unable to open fileO/S-Error: (OS 1392) The file or directory is corrupted and 
unreadable.
*** 2017-04-11 22:18:23.726Unable to create archive log file 
'E:\BDEDUCAR\ARCHIVELOG\2017_ 04_11\O1_MF_1_421421_%U_.ARC'ORA-19816: WARNING: 
Files may exist in db_recovery_file_dest that are not known to 
database.ORA-27040: file create error, unable to create fileOSD-04002: unable 
to open fileO/S-Error: (OS 1392) The file or directory is corrupted and 
unreadable.** ** 
*WARNING: A file of type ARCHIVED LOG may exist indb_recovery_file_dest that is 
not known to the database.Use the RMAN command CATALOG RECOVERY AREA to 
re-catalogany such files. If files cannot be cataloged, then manuallydelete 
them using OS command. This is most likely theresult of a crash during file 
creation.


   

  #yiv8425901296 #yiv8425901296 -- #yiv8425901296ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv8425901296 
#yiv8425901296ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv8425901296 
#yiv8425901296ygrp-mkp #yiv8425901296hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv8425901296 #yiv8425901296ygrp-mkp #yiv8425901296ads 
{margin-bottom:10px;}#yiv8425901296 #yiv8425901296ygrp-mkp .yiv8425901296ad 
{padding:0 0;}#yiv8425901296 #yiv8425901296ygrp-mkp .yiv8425901296ad p 
{margin:0;}#yiv8425901296 #yiv8425901296ygrp-mkp .yiv8425901296ad a 
{color:#ff;text-decoration:none;}#yiv8425901296 #yiv8425901296ygrp-sponsor 
#yiv8425901296ygrp-lc {font-family:Arial;}#yiv8425901296 
#yiv8425901296ygrp-sponsor #yiv8425901296ygrp-lc #yiv8425901296hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv8425901296 
#yiv8425901296ygrp-sponsor #yiv8425901296ygrp-lc .yiv8425901296ad 
{margin-bottom:10px;padding:0 0;}#yiv8425901296 #yiv8425901296actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv8425901296 
#yiv8425901296activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv8425901296
 #yiv8425901296activity span {font-weight:700;}#yiv8425901296 
#yiv8425901296activity span:first-child 
{text-transform:uppercase;}#yiv8425901296 #yiv8425901296activity span a 
{color:#5085b6;text-decoration:none;}#yiv8425901296 #yiv8425901296activity span 
span {color:#ff7900;}#yiv8425901296 #yiv8425901296activity span 
.yiv8425901296underline {text-decoration:underline;}#yiv8425901296 
.yiv8425901296attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv8425901296 .yiv8425901296attach div a 
{text-decoration:none;}#yiv8425901296 .yiv8425901296attach img 
{border:none;padding-right:5px;}#yiv8425901296 .yiv8425901296attach label 
{display:block;margin-bottom:5px;}#yiv8425901296 .yiv8425901296attach label a 
{text-decoration:none;}#yiv8425901296 blockquote {margin:0 0 0 
4px;}#yiv8425901296 .yiv8425901296bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv8425901296 
.yiv8425901296bold a {text-decoration:none;}#yiv8425901296 dd.yiv8425901296last 
p a {font-family:Verdana;font-weight:700;}#yiv8425901296 dd.yiv8425901296last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv8425901296 
dd.yiv8425901296last p span.yiv8425901296yshortcuts 
{margin-right:0;}#yiv8425901296 div.yiv8425901296attach-table div div a 
{text-decoration:none;}#yiv8425901296 div.yiv8425901296attach-table 
{width:400px;}#yiv8425901296 div.yiv8425901296file-title a, #yiv8425901296 

[oracle_br] Erro ORA-10693 - ressurgindo das cinzas

[angelo angelolis...@gmail.com [oracle_br]]

Bom dia pessoal,

Chiappa, eu to topando com um bug (talvez o bug na verdade seja eu)   que
já foi objeto de discussao aqui ha 9 anos atras num thread seu
https://www.mail-archive.com/oracle_br@yahoogrupos.com.br/msg44178.html

O erro ORA-19693: componente de backup

D:\ORACLE\FAST_RECOVERY_AREA\ORALAB\BACKUPSET\2017_04_11\O1_MF_A_TAG20170411T223652_DGV15OQ3_.BKP
jß foi incluÝdo


É uma restauração de um backup de outro servidor (prod) para uma maquina de
desenvolvimento, em Windows.

Até ontem era 11.2.0.3 e vinha de um 11.2.0.4 patchset

Tive a ideia entao de atualizar a base e deixar um ambiente mais decente,
digamos assim.
Só que desinstalei o banco de dados da maquina (ja tava bem zoneado, e era
maquina de teste.. ) e instalei o 11.2.0.4 nele

E ai foi o procedimento de criar a instancia, criar o pfile,  voltar o
spfile, editar, criar o spfile, criar as pastinhas, restaurar o control,
 catalogar, restaurar a base, trocar os caminhos...


Chegou na hora de rodar o recover.. não estou conseguindo transpor esse
obstáculo. Mando o recover e erro.

Estou com uma cópia nova mais recente de ontem a noite, na maquina, to
pensando em dropar e recomeçar do zero novamente  rodei agorinha e
resultado..

Estou achando que fiz alguma besteira em catalogar, bem com cara que foi
descrito no thread

Eu vou retomar o trabalho agora.. e talvez reiniciar, to com um backup mais
recente ainda a mão.



RMAN> recover database skip tablespace wms_data,wms_index;

Iniciando recover em 13/04/17
utilizando o canal ORA_DISK_1

Executando: alter database datafile 5 offline
Executando: alter database datafile 6 offline
iniciar recuperaçao de media

canal ORA_DISK_1: iniciando restauração de log arquivado para destino
default
canal ORA_DISK_1: restaurando log de arquivado
thread de log arquivado=1 sequÛncia=3243
RMAN-00571: ===
RMAN-00569: === ERROR MESSAGE STACK FOLLOWS ===
RMAN-00571: ===
RMAN-03002: falha do comando recover em 04/13/2017 09:30:35
ORA-19693: componente de backup
D:\ORACLE\FAST_RECOVERY_AREA\ORALAB\BACKUPSET\20
17_04_11\O1_MF_A_TAG20170411T223652_DGV15OQ3_.BKP já foi incluído

RMAN>

Re: [oracle_br] Re: Sequences schema sys

[jlchia...@yahoo.com.br [oracle_br]]

Sim, o ponto é que imho há peixinhos maiores pra se fritar, há muitas outras 
coisas mais comuns/possíveis de acontecer que temos que treinar antes, mas 
okdoc
 No caso, se vc não consegue abrir o banco normalmente a opção é fechar  e 
depois abrir com startup upgrade, e só então vc rodar os scripts - caso a 
bagunça no dicionário não permita nem isso, aí vc vai fazer a ** mesma ** coisa 
que faria em Prod, ie, voltar backup
 
 []s
 
   Chiappa

Re: [oracle_br] ORA-19816: Ajuda

[angelo angelolis...@gmail.com [oracle_br]]

Permissões de ntfs nessa pasta como estão ?

Parece que a base não consegue escrever no disco



OSD-04002: unable to open file

O/S-Error: (OS 1392) The file or directory is corrupted and unreadable.

Unable to create archive log file 'E:\BDEDUCAR\ARCHIVELOG\2017_
04_11\O1_MF_1_421421_%U_.ARC'

ORA-19816: WARNING: Files may exist in db_recovery_file_dest that are not
known to database.

ORA-27040: file create error, unable to create file

OSD-04002: unable to open file

O/S-Error: (OS 1392) The file or directory is corrupted and unreadable.



On 13 April 2017 at 08:43, alisson...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> wrote:

>
>
> Bom dia a todos,
>
>
> começou a apresentar erros no banco aqui ,
>
>
> Estou com a versão Oracle Database 11g Enterprise Edition Release
> 11.2.0.4.0 - 64bit Product , com todos os pacth atualizados.
>
> Uso Windows Server 2012 R2
>
>
> Fiz o procedimento sugerido Catalog Recovery area, mas o erro persiste
> depois de algum tempo.
>
>
> Alguém pode me ajudar nesse processo ? me dizendo se já passou por isso ?
>
>
> Grato.
>
>
>
>
> ORA-19816: WARNING: Files may exist in db_recovery_file_dest that are not
> known to database.
>
> ORA-27040: file create error, unable to create file
>
> OSD-04002: unable to open file
>
> O/S-Error: (OS 1392) The file or directory is corrupted and unreadable.
>
>
> *** 2017-04-11 22:18:23.726
>
> Unable to create archive log file 'E:\BDEDUCAR\ARCHIVELOG\2017_
> 04_11\O1_MF_1_421421_%U_.ARC'
>
> ORA-19816: WARNING: Files may exist in db_recovery_file_dest that are not
> known to database.
>
> ORA-27040: file create error, unable to create file
>
> OSD-04002: unable to open file
>
> O/S-Error: (OS 1392) The file or directory is corrupted and unreadable.
>
> *
>
> WARNING: A file of type ARCHIVED LOG may exist in
>
> db_recovery_file_dest that is not known to the database.
>
> Use the RMAN command CATALOG RECOVERY AREA to re-catalog
>
> any such files. If files cannot be cataloged, then manually
>
> delete them using OS command. This is most likely the
>
> result of a crash during file creation.
>
>
>
>
> 
>

[oracle_br] ORA-19816: Ajuda

[alisson...@yahoo.com.br [oracle_br]]

Bom dia a todos,
 

 começou a apresentar erros no banco aqui , 
 

 Estou com a versão Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 
64bit Product , com todos os pacth atualizados. 
 Uso Windows Server 2012 R2
 

 Fiz o procedimento sugerido Catalog Recovery area, mas o erro persiste depois 
de algum tempo.
 

 Alguém pode me ajudar nesse processo ? me dizendo se já passou por isso ?
 

 Grato.
 

 

 

 ORA-19816: WARNING: Files may exist in db_recovery_file_dest that are not 
known to database.
 ORA-27040: file create error, unable to create file
 OSD-04002: unable to open file
 
 O/S-Error: (OS 1392) The file or directory is corrupted and unreadable.
 

 *** 2017-04-11 22:18:23.726
 Unable to create archive log file 
'E:\BDEDUCAR\ARCHIVELOG\2017_04_11\O1_MF_1_421421_%U_.ARC'
 ORA-19816: WARNING: Files may exist in db_recovery_file_dest that are not 
known to database.
 ORA-27040: file create error, unable to create file
 OSD-04002: unable to open file
 O/S-Error: (OS 1392) The file or directory is corrupted and unreadable.
 *
 WARNING: A file of type ARCHIVED LOG may exist in
 db_recovery_file_dest that is not known to the database.
 Use the RMAN command CATALOG RECOVERY AREA to re-catalog
 any such files. If files cannot be cataloged, then manually
 delete them using OS command. This is most likely the
 result of a crash during file creation.