Re: [oracle_br] Re: Sequences schema sys

2017-04-12 Por tôpico Roger Camatini rogerio.camat...@gmail.com [oracle_br] 
Luiz,

Obrigado pelas infos. Não tentei abrir com 'startup upgrade'.


Atenciosamente,

Rogério Camatini


2017-04-12 19:38 GMT-03:00 Luis Freitas lfreita...@yahoo.com [oracle_br] <
oracle_br@yahoogrupos.com.br>:

>
>
> Rogerio,
>
>O google aponta esse blog para esse erro:
>
> http://www.usn-it.de/index.php/2013/05/29/ora-600-kokiasg1-reasons-and-
> workarounds/
>
> Tem uma sugestão de colocar um parametro para poder abrir o banco e
> recriar uma das sequences do SYS. Depois disso talvez você consiga exportar
> os objetos para recriar o banco, ou rodar o catalog.sql como sugerido.
>
> Mas essas sugestões não são suportadas pela Oracle a não ser que você
> abra um chamado e o analista sugira fazer isso. Então a base que teve o
> problema precisa ser abandonada após extrair os dados.
>
> Nesse tipo de situação o antigo exp deve funcionar mais fácil que o
> expdp, pois precisa de menos recursos do banco para ser executado.
>
>Se o banco não abrir de jeito nenhum, e não houver backup, um jeito de
> recuperar os dados é através do Field Support, que pode usar uma ferramenta
> chamada Oracle's Data Unloader.
>
>Você tentou abrir o banco com "startup upgrade"?
>
> Atc,
> Luis Freitas
>
>
> On Wednesday, April 12, 2017 7:16 PM, "Roger Camatini
> rogerio.camat...@gmail.com [oracle_br]" 
> wrote:
>
>
>
> Chiappa,
>
> Sei que é muito dificil uma coisa dessas acontecer, mas como tu mesmo
> disse, a pouco dias atras houve um caso relatado aqui mesmo no forum, de um
> cidadão mexendo nos objetos do SYS.
>
> Tentei fazer o que foi proposto, mas como o banco não está aberto, os
> scripts dão erro. O 'alter database open' gera um ora 600 também.
>
>
> Atenciosamente,
>
> Rogério Camatini
>
>
> Em 12 de abril de 2017 19:02, jlchia...@yahoo.com.br [oracle_br] <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>
> imho dropar objetos (sequências ou seja o que for) do SYS *** não é *** um
> teste válido para aprendizado, pois é algo que ** DIFICILMENTE ** ocorre em
> uso REAL, do dia a dia, NÂO é um problema que vc rotineiramente venha a ser
> chamado pra resolver Na verdade a regra é Clara, no SYS salvo exceções
> realmente excepcionais não se faz DDL nenhum, DML nenhum, no máximo se faz
> DCLs dando GRANTs pra alguns POUCOS schemas/roles escolhidos, mas ok, que
> seja para aprendizado pessoal seu, algo que vc talvez não use na real
>
>  No caso a resposta é simples : praticamente ** todos ** os objetos do SYS
> são criados por scripts sqlplus, que ficam em $ORACLE_HOME/rdbms/admin
> (catalog.sql e catproc.sql são os principais, cheque no 12c se mais algum
> foi introduzido mas iirc não foi) , então o procedimento é vc os executar
> um após o outro e depois recompilar tudo que estiver inválido com utlrp, é
> isso 
>
>   Notar que muitas vezes um DDL ou DML feito no SYS causa diversos efeitos
> graves (pesquise aqui mesmo no Fórum, há algumas semanas teve um sujeito
> que saiu fazendo DML/DDL no schema SYS e em consequência perdeu acesso à
> export/import, ferramentas que ele usava pra backup lógico, esse foi um
> exemplo recente) mas como no seu caso ao que parece o SYS ainda consegue
> conectar no banco, os scripts devem funcionar sem probs
>
>   []s
>
> Chiappa
>
>
>
>
> 
>

Re: [oracle_br] Re: Sequences schema sys

2017-04-12 Por tôpico Luis Freitas lfreita...@yahoo.com [oracle_br] 
Rogerio,
   O google aponta esse blog para esse erro:
http://www.usn-it.de/index.php/2013/05/29/ora-600-kokiasg1-reasons-and-workarounds/

    Tem uma sugestão de colocar um parametro para poder abrir o banco e recriar 
uma das sequences do SYS. Depois disso talvez você consiga exportar os objetos 
para recriar o banco, ou rodar o catalog.sql como sugerido.
    Mas essas sugestões não são suportadas pela Oracle a não ser que você abra 
um chamado e o analista sugira fazer isso. Então a base que teve o problema 
precisa ser abandonada após extrair os dados.
    Nesse tipo de situação o antigo exp deve funcionar mais fácil que o expdp, 
pois precisa de menos recursos do banco para ser executado.
   Se o banco não abrir de jeito nenhum, e não houver backup, um jeito de 
recuperar os dados é através do Field Support, que pode usar uma ferramenta 
chamada Oracle's Data Unloader.
   Você tentou abrir o banco com "startup upgrade"?
Atc,Luis Freitas 

On Wednesday, April 12, 2017 7:16 PM, "Roger Camatini 
rogerio.camat...@gmail.com [oracle_br]"  wrote:
 

     Chiappa,
Sei que é muito dificil uma coisa dessas acontecer, mas como tu mesmo disse, a 
pouco dias atras houve um caso relatado aqui mesmo no forum, de um cidadão 
mexendo nos objetos do SYS. 
Tentei fazer o que foi proposto, mas como o banco não está aberto, os scripts 
dão erro. O 'alter database open' gera um ora 600 também.

Atenciosamente,
Rogério Camatini

Em 12 de abril de 2017 19:02, jlchia...@yahoo.com.br [oracle_br] 
 escreveu:

     imho dropar objetos (sequências ou seja o que for) do SYS *** não é *** um 
teste válido para aprendizado, pois é algo que ** DIFICILMENTE ** ocorre em uso 
REAL, do dia a dia, NÂO é um problema que vc rotineiramente venha a ser chamado 
pra resolver Na verdade a regra é Clara, no SYS salvo exceções realmente 
excepcionais não se faz DDL nenhum, DML nenhum, no máximo se faz DCLs dando 
GRANTs pra alguns POUCOS schemas/roles escolhidos, mas ok, que seja para 
aprendizado pessoal seu, algo que vc talvez não use na real

 No caso a resposta é simples : praticamente ** todos ** os objetos do SYS são 
criados por scripts sqlplus, que ficam em $ORACLE_HOME/rdbms/admin (catalog.sql 
e catproc.sql são os principais, cheque no 12c se mais algum foi introduzido 
mas iirc não foi) , então o procedimento é vc os executar um após o outro e 
depois recompilar tudo que estiver inválido com utlrp, é isso  
  
  Notar que muitas vezes um DDL ou DML feito no SYS causa diversos efeitos 
graves (pesquise aqui mesmo no Fórum, há algumas semanas teve um sujeito que 
saiu fazendo DML/DDL no schema SYS e em consequência perdeu acesso à 
export/import, ferramentas que ele usava pra backup lógico, esse foi um exemplo 
recente) mas como no seu caso ao que parece o SYS ainda consegue conectar no 
banco, os scripts devem funcionar sem probs
  
  []s
  
    Chiappa   

  #yiv0924645594 #yiv0924645594 -- #yiv0924645594ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv0924645594 
#yiv0924645594ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv0924645594 
#yiv0924645594ygrp-mkp #yiv0924645594hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv0924645594 #yiv0924645594ygrp-mkp #yiv0924645594ads 
{margin-bottom:10px;}#yiv0924645594 #yiv0924645594ygrp-mkp .yiv0924645594ad 
{padding:0 0;}#yiv0924645594 #yiv0924645594ygrp-mkp .yiv0924645594ad p 
{margin:0;}#yiv0924645594 #yiv0924645594ygrp-mkp .yiv0924645594ad a 
{color:#ff;text-decoration:none;}#yiv0924645594 #yiv0924645594ygrp-sponsor 
#yiv0924645594ygrp-lc {font-family:Arial;}#yiv0924645594 
#yiv0924645594ygrp-sponsor #yiv0924645594ygrp-lc #yiv0924645594hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv0924645594 
#yiv0924645594ygrp-sponsor #yiv0924645594ygrp-lc .yiv0924645594ad 
{margin-bottom:10px;padding:0 0;}#yiv0924645594 #yiv0924645594actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv0924645594 
#yiv0924645594activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv0924645594
 #yiv0924645594activity span {font-weight:700;}#yiv0924645594 
#yiv0924645594activity span:first-child 
{text-transform:uppercase;}#yiv0924645594 #yiv0924645594activity span a 
{color:#5085b6;text-decoration:none;}#yiv0924645594 #yiv0924645594activity span 
span {color:#ff7900;}#yiv0924645594 #yiv0924645594activity span 
.yiv0924645594underline {text-decoration:underline;}#yiv0924645594 
.yiv0924645594attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv0924645594 .yiv0924645594attach div a 
{text-decoration:none;}#yiv0924645594 .yiv0924645594attach img 
{border:none;padding-right:5px;}#yiv0924645594 .yiv0924645594attach label 
{display:block;margin-bottom:5px;}#yiv0924645594 .yiv0924645594attach label a 
{text-decoration:none;}#yiv0924645594 blockquote {margin:0 0 0 
4px;}#yiv0924645594 .yiv0924645594bold 
{fon

Re: [oracle_br] Re: Sequences schema sys

2017-04-12 Por tôpico Roger Camatini rogerio.camat...@gmail.com [oracle_br] 
Chiappa,

Sei que é muito dificil uma coisa dessas acontecer, mas como tu mesmo
disse, a pouco dias atras houve um caso relatado aqui mesmo no forum, de um
cidadão mexendo nos objetos do SYS.

Tentei fazer o que foi proposto, mas como o banco não está aberto, os
scripts dão erro. O 'alter database open' gera um ora 600 também.


Atenciosamente,

Rogério Camatini


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

>
>
> imho dropar objetos (sequências ou seja o que for) do SYS *** não é *** um
> teste válido para aprendizado, pois é algo que ** DIFICILMENTE ** ocorre em
> uso REAL, do dia a dia, NÂO é um problema que vc rotineiramente venha a ser
> chamado pra resolver Na verdade a regra é Clara, no SYS salvo exceções
> realmente excepcionais não se faz DDL nenhum, DML nenhum, no máximo se faz
> DCLs dando GRANTs pra alguns POUCOS schemas/roles escolhidos, mas ok, que
> seja para aprendizado pessoal seu, algo que vc talvez não use na real
>
>  No caso a resposta é simples : praticamente ** todos ** os objetos do SYS
> são criados por scripts sqlplus, que ficam em $ORACLE_HOME/rdbms/admin
> (catalog.sql e catproc.sql são os principais, cheque no 12c se mais algum
> foi introduzido mas iirc não foi) , então o procedimento é vc os executar
> um após o outro e depois recompilar tudo que estiver inválido com utlrp, é
> isso 
>
>   Notar que muitas vezes um DDL ou DML feito no SYS causa diversos efeitos
> graves (pesquise aqui mesmo no Fórum, há algumas semanas teve um sujeito
> que saiu fazendo DML/DDL no schema SYS e em consequência perdeu acesso à
> export/import, ferramentas que ele usava pra backup lógico, esse foi um
> exemplo recente) mas como no seu caso ao que parece o SYS ainda consegue
> conectar no banco, os scripts devem funcionar sem probs
>
>   []s
>
> Chiappa
> 
>

[oracle_br] Re: Sequences schema sys

2017-04-12 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
imho dropar objetos (sequências ou seja o que for) do SYS *** não é *** um 
teste válido para aprendizado, pois é algo que ** DIFICILMENTE ** ocorre em uso 
REAL, do dia a dia, NÂO é um problema que vc rotineiramente venha a ser chamado 
pra resolver Na verdade a regra é Clara, no SYS salvo exceções realmente 
excepcionais não se faz DDL nenhum, DML nenhum, no máximo se faz DCLs dando 
GRANTs pra alguns POUCOS schemas/roles escolhidos, mas ok, que seja para 
aprendizado pessoal seu, algo que vc talvez não use na real

 No caso a resposta é simples : praticamente ** todos ** os objetos do SYS são 
criados por scripts sqlplus, que ficam em $ORACLE_HOME/rdbms/admin (catalog.sql 
e catproc.sql são os principais, cheque no 12c se mais algum foi introduzido 
mas iirc não foi) , então o procedimento é vc os executar um após o outro e 
depois recompilar tudo que estiver inválido com utlrp, é isso  
  
  Notar que muitas vezes um DDL ou DML feito no SYS causa diversos efeitos 
graves (pesquise aqui mesmo no Fórum, há algumas semanas teve um sujeito que 
saiu fazendo DML/DDL no schema SYS e em consequência perdeu acesso à 
export/import, ferramentas que ele usava pra backup lógico, esse foi um exemplo 
recente) mas como no seu caso ao que parece o SYS ainda consegue conectar no 
banco, os scripts devem funcionar sem probs
  
  []s
  
Chiappa

Re: [oracle_br] Sequences schema sys

2017-04-12 Por tôpico Roger Camatini rogerio.camat...@gmail.com [oracle_br] 
Segue os erros:

-->ERRO ORA 600 INCIAL

Errors in file
/oraprd01/app/product/diag/rdbms/homol12c/homol12c/trace/homol12c_j001_50397658.trc:
ORA-00600: internal error code, arguments: [12803], [], [], [], [], [], [],
[], [], [], [], []
Wed Apr 12 14:59:09 2017
Errors in file
/oraprd01/app/product/diag/rdbms/homol12c/homol12c/trace/homol12c_j000_7012770.trc:
ORA-00600: internal error code, arguments: [12803], [], [], [], [], [], [],
[], [], [], [], []
Wed Apr 12 14:59:09 2017
Errors in file
/oraprd01/app/product/diag/rdbms/homol12c/homol12c/trace/homol12c_j001_19661048.trc:
ORA-00600: internal error code, arguments: [12803], [], [], [], [], [], [],
[], [], [], [], []
Wed Apr 12 14:59:09 2017
Errors in file
/oraprd01/app/product/diag/rdbms/homol12c/homol12c/trace/homol12c_j000_43319998.trc:
ORA-00600: internal error code, arguments: [12803], [], [], [], [], [], [],
[], [], [], [], []
Wed Apr 12 14:59:09 2017
Errors in file
/oraprd01/app/product/diag/rdbms/homol12c/homol12c/trace/homol12c_j001_23592962.trc:
ORA-00600: internal error code, arguments: [12803], [], [], [], [], [], [],
[], [], [], [], []
Wed Apr 12 15:00:17 2017
Errors in file
/oraprd01/app/product/diag/rdbms/homol12c/homol12c/trace/homol12c_j000_64487820.trc:
ORA-00600: internal error code, arguments: [12803], [], [], [], [], [], [],
[], [], [], [], []
Wed Apr 12 15:05:40 2017

-->ERRO AO SUBIR A INSTANCE

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup;
ORACLE instance started.

Total System Global Area 6291456000 bytes
Fixed Size  4584784 bytes
Variable Size3389000368 bytes
Database Buffers 2885681152 bytes
Redo Buffers   12189696 bytes
Database mounted.
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [kokiasg1], [], [], [], [], [],
[],
[], [], [], [], []
Process ID: 11076198
Session ID: 862 Serial number: 57103


Atenciosamente,

Rogério Camatini


2017-04-12 17:43 GMT-03:00 Luis Freitas lfreita...@yahoo.com [oracle_br] <
oracle_br@yahoogrupos.com.br>:

>
>
> Roger,
>
>Posta alguns dos erros.
>
>Tentou subir a base com startup upgrade?
>
> Atc.
> Luis Freitas
>
>
> On Wednesday, April 12, 2017 5:03 PM, "Rodrigo Mufalani
> rodr...@mufalani.com.br [oracle_br]"  wrote:
>
>
>
> Já tentou rodar catproc e catalog? Ou similar, caso tenha mudado no nome...
>
> Get Outlook for iOS 
> --
> *From:* oracle_br@yahoogrupos.com.br  on
> behalf of Roger Camatini rogerio.camat...@gmail.com [oracle_br] <
> oracle_br@yahoogrupos.com.br>
> *Sent:* Wednesday, April 12, 2017 4:52:17 PM
> *To:* oracle_br@yahoogrupos.com.br
> *Subject:* [oracle_br] Sequences schema sys
>
>
> Boa tarde Senhores,
>
> No sentido de estudo e resolução de problemas, criei uma base de testes
> 12c e deletei as sequences do schema SYS. Como esperado, o banco começou a
> gerar muitos erros ora 600, não deixando mais nenhum user que não tenha
> privilégio DBA conectar ao banco. Baixei o banco, e simplesmente não sobe
> mais..isso tbm já era esperado. Após muitas pesquisas e todas sem sucesso
> até o momento, não consegui encontrar nada que possa ajudar na resolução do
> problema. Alguem dos experts do grupo já passou por algo similar?
>
> Atenciosamente,
>
> Rogério Camatini
>
>
>
> 
>

Re: [oracle_br] Sequences schema sys

2017-04-12 Por tôpico Luis Freitas lfreita...@yahoo.com [oracle_br] 
Roger,
   Posta alguns dos erros.
   Tentou subir a base com startup upgrade?
Atc.Luis Freitas 

On Wednesday, April 12, 2017 5:03 PM, "Rodrigo Mufalani 
rodr...@mufalani.com.br [oracle_br]"  wrote:
 

     Já tentou rodar catproc e catalog? Ou similar, caso tenha mudado no nome...
Get Outlook for iOSFrom: oracle_br@yahoogrupos.com.br 
 on behalf of Roger Camatini 
rogerio.camat...@gmail.com [oracle_br] 
Sent: Wednesday, April 12, 2017 4:52:17 PM
To: oracle_br@yahoogrupos.com.br
Subject: [oracle_br] Sequences schema sys  Boa tarde Senhores,
No sentido de estudo e resolução de problemas, criei uma base de testes 12c e 
deletei as sequences do schema SYS. Como esperado, o banco começou a gerar 
muitos erros ora 600, não deixando mais nenhum user que não tenha privilégio 
DBA conectar ao banco. Baixei o banco, e simplesmente não sobe mais..isso tbm 
já era esperado. Após muitas pesquisas e todas sem sucesso até o momento, não 
consegui encontrar nada que possa ajudar na resolução do problema. Alguem dos 
experts do grupo já passou por algo similar?

Atenciosamente,
Rogério Camatini
  #yiv0798966193 #yiv0798966193 -- #yiv0798966193ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv0798966193 
#yiv0798966193ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv0798966193 
#yiv0798966193ygrp-mkp #yiv0798966193hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv0798966193 #yiv0798966193ygrp-mkp #yiv0798966193ads 
{margin-bottom:10px;}#yiv0798966193 #yiv0798966193ygrp-mkp .yiv0798966193ad 
{padding:0 0;}#yiv0798966193 #yiv0798966193ygrp-mkp .yiv0798966193ad p 
{margin:0;}#yiv0798966193 #yiv0798966193ygrp-mkp .yiv0798966193ad a 
{color:#ff;text-decoration:none;}#yiv0798966193 #yiv0798966193ygrp-sponsor 
#yiv0798966193ygrp-lc {font-family:Arial;}#yiv0798966193 
#yiv0798966193ygrp-sponsor #yiv0798966193ygrp-lc #yiv0798966193hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv0798966193 
#yiv0798966193ygrp-sponsor #yiv0798966193ygrp-lc .yiv0798966193ad 
{margin-bottom:10px;padding:0 0;}#yiv0798966193 #yiv0798966193actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv0798966193 
#yiv0798966193activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv0798966193
 #yiv0798966193activity span {font-weight:700;}#yiv0798966193 
#yiv0798966193activity span:first-child 
{text-transform:uppercase;}#yiv0798966193 #yiv0798966193activity span a 
{color:#5085b6;text-decoration:none;}#yiv0798966193 #yiv0798966193activity span 
span {color:#ff7900;}#yiv0798966193 #yiv0798966193activity span 
.yiv0798966193underline {text-decoration:underline;}#yiv0798966193 
.yiv0798966193attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv0798966193 .yiv0798966193attach div a 
{text-decoration:none;}#yiv0798966193 .yiv0798966193attach img 
{border:none;padding-right:5px;}#yiv0798966193 .yiv0798966193attach label 
{display:block;margin-bottom:5px;}#yiv0798966193 .yiv0798966193attach label a 
{text-decoration:none;}#yiv0798966193 blockquote {margin:0 0 0 
4px;}#yiv0798966193 .yiv0798966193bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv0798966193 
.yiv0798966193bold a {text-decoration:none;}#yiv0798966193 dd.yiv0798966193last 
p a {font-family:Verdana;font-weight:700;}#yiv0798966193 dd.yiv0798966193last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv0798966193 
dd.yiv0798966193last p span.yiv0798966193yshortcuts 
{margin-right:0;}#yiv0798966193 div.yiv0798966193attach-table div div a 
{text-decoration:none;}#yiv0798966193 div.yiv0798966193attach-table 
{width:400px;}#yiv0798966193 div.yiv0798966193file-title a, #yiv0798966193 
div.yiv0798966193file-title a:active, #yiv0798966193 
div.yiv0798966193file-title a:hover, #yiv0798966193 div.yiv0798966193file-title 
a:visited {text-decoration:none;}#yiv0798966193 div.yiv0798966193photo-title a, 
#yiv0798966193 div.yiv0798966193photo-title a:active, #yiv0798966193 
div.yiv0798966193photo-title a:hover, #yiv0798966193 
div.yiv0798966193photo-title a:visited {text-decoration:none;}#yiv0798966193 
div#yiv0798966193ygrp-mlmsg #yiv0798966193ygrp-msg p a 
span.yiv0798966193yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv0798966193 
.yiv0798966193green {color:#628c2a;}#yiv0798966193 .yiv0798966193MsoNormal 
{margin:0 0 0 0;}#yiv0798966193 o {font-size:0;}#yiv0798966193 
#yiv0798966193photos div {float:left;width:72px;}#yiv0798966193 
#yiv0798966193photos div div {border:1px solid 
#66;height:62px;overflow:hidden;width:62px;}#yiv0798966193 
#yiv0798966193photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv0798966193
 #yiv0798966193reco-category {font-size:77%;}#yiv0798966193 
#yiv0798966193reco-desc {font-size:77%;}#yiv0798966193 .yiv0798966193replbq 
{margin:4px;}#yiv0798966193 #yiv0798966193ygrp-actbar

Re: [oracle_br] Sequences schema sys

2017-04-12 Por tôpico Rodrigo Mufalani rodr...@mufalani.com.br [oracle_br] 
Já tentou rodar catproc e catalog? Ou similar, caso tenha mudado no nome...

Get Outlook for iOS

From: oracle_br@yahoogrupos.com.br  on behalf of 
Roger Camatini rogerio.camat...@gmail.com [oracle_br] 

Sent: Wednesday, April 12, 2017 4:52:17 PM
To: oracle_br@yahoogrupos.com.br
Subject: [oracle_br] Sequences schema sys



Boa tarde Senhores,

No sentido de estudo e resolução de problemas, criei uma base de testes 12c e 
deletei as sequences do schema SYS. Como esperado, o banco começou a gerar 
muitos erros ora 600, não deixando mais nenhum user que não tenha privilégio 
DBA conectar ao banco. Baixei o banco, e simplesmente não sobe mais..isso tbm 
já era esperado. Após muitas pesquisas e todas sem sucesso até o momento, não 
consegui encontrar nada que possa ajudar na resolução do problema. Alguem dos 
experts do grupo já passou por algo similar?

Atenciosamente,

Rogério Camatini

[oracle_br] Sequences schema sys

2017-04-12 Por tôpico Roger Camatini rogerio.camat...@gmail.com [oracle_br] 
Boa tarde Senhores,

No sentido de estudo e resolução de problemas, criei uma base de testes 12c
e deletei as sequences do schema SYS. Como esperado, o banco começou a
gerar muitos erros ora 600, não deixando mais nenhum user que não tenha
privilégio DBA conectar ao banco. Baixei o banco, e simplesmente não sobe
mais..isso tbm já era esperado. Após muitas pesquisas e todas sem sucesso
até o momento, não consegui encontrar nada que possa ajudar na resolução do
problema. Alguem dos experts do grupo já passou por algo similar?

Atenciosamente,

Rogério Camatini

Re: [oracle_br] impdp

2017-04-12 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
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

Re: [oracle_br] impdp

2017-04-12 Por tôpico Mario Rodrigues marioirodrig...@gmail.com [oracle_br] 
Sim sim Ângelo, eu criei um novo banco .. sobre usar uma versão full,
realmente já estou pensando nisso sim ..

Obrigado



Em 12 de abril de 2017 15:37, angelo angelolis...@gmail.com [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Mas agora o banco provavelmente foi corrompido.. pelo que comentou o
> Chiappa na mensagem anterior.. verifica se nao aconteceu ?
>
> Acho que vc vai precisar abandonar o XE e trabalhar com a versao full do
> banco (standard, enterprise)
>
> Se fosse uma situação de um banco normal, do tipo, não quisesse alterar o
> characterset,  ainda teria a opção de poder criar um novo banco e trabalhar
> em cima
>
>
>
>
> 2017-04-12 15:08 GMT-03:00 Mario Rodrigues marioirodrig...@gmail.com
> [oracle_br] :
>
>>
>>
>> Ângelo,
>>
>>
>> Pois eh .. vi ate uma resposta tua a alguns dias
>>  "
>>
>> https://docs.oracle.com/cd/E17781_01/install.112/e18803/toc.htm#BABGBFJH
>>
>>
>> AL16UTF16
>>
>> Unicode 4.0 UTF-16 Universal character set
>>
>> AL32UTF8
>>
>> Unicode 4.0 UTF-8 Universal character set
>>
>> UTF8
>>
>> Unicode 3.0 UTF-8 Universal character set, CESU-8 compliant
>> "
>>
>> Vou ver se rola essa dica do UTF8 .. mas acho q o jeito é alterar na mão
>> antes de importar os dados:(
>>
>> Vlww
>>
>>
>> Em 12 de abril de 2017 14:55, angelo angelolis...@gmail.com [oracle_br] <
>> oracle_br@yahoogrupos.com.br> escreveu:
>>
>>>
>>>
>>> Mario,
>>>
>>>
>>> Dá uma olhada nisso aqui =>   http://stackoverflow.com/que
>>> stions/23779159/change-nls-character-set-parameters-on-oracle-11g-xe
>>>
>>> e depois nisso, a documentação oficial =>  https://docs.oracle.com/cd/B1
>>> 9306_01/server.102/b14225/ch2charset.htm
>>>
>>>
>>> Tenho a impressão que por limitacoes do XE, vc nao vai conseguir fazer
>>> isso, mesmo que altere o banco vai chiar... eu acho
>>> mas se o encoding WE8ISO8859P1  for um subset do UTF8, talvez dê um
>>> samba..
>>>
>>>
>>>
>>>
>>>
>>> 2017-04-12 12:37 GMT-03:00 Mario Rodrigues marioirodrig...@gmail.com
>>> [oracle_br] :
>>>


 Pessoal

 Boa tarde

 Voltando com o topico, a empresa me enviou o characterset é o
 WE8ISO8859P1.

 Dai alterei usando "Alter database character set INTERNAL_USE
 WE8ISO8859P1;" (nunca havia feito, achei na internet)
 Rodando os SQL's
 SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET';
 SELECT value FROM nls_database_parameters WHERE parameter =
 'NLS_CHARACTERSET'

 Dai blz, quando tento realizar o IMPORT aparecem 2 erros:

 ORA 39006 Erro interno
 ORA 39213 metadados não disponível

 Alguem já passou por isso?? Faltou fazer algo?? Já tentei ate import
 com o SYS e da o mesmo erro.


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

>
>
> Acredito que talvez seja no 12c apenas - mas independente disso, já
> que vc não conseguiu obter o characterset de origem pelo impdp, vc CHEGOU 
> a
> usar a sugestão (que FUNCIONA, sim) do outro colega de usar o comando
> STRINGS no dumpfile que a empresa mandou ?? Logo nas primeiras linhas deve
> constar qual  o characterset origem usado na exportação E a ** minha 
> **
> Sugestão de vc extrair o DDL só da tabela  pra ver se a coluna
> originalmente foi definida com tamanho em CARACTERES ou em BYTES, vc fez
> ???
>  Essas coisas ABSOLUTAMENTE NÃO DEPENDEM da tal outra Empresa
>
> []s
>
>   Chiappa
>


>>>
>>
> 
>

Re: [oracle_br] impdp

2017-04-12 Por tôpico angelo angelolis...@gmail.com [oracle_br] 
Mas agora o banco provavelmente foi corrompido.. pelo que comentou o
Chiappa na mensagem anterior.. verifica se nao aconteceu ?

Acho que vc vai precisar abandonar o XE e trabalhar com a versao full do
banco (standard, enterprise)

Se fosse uma situação de um banco normal, do tipo, não quisesse alterar o
characterset,  ainda teria a opção de poder criar um novo banco e trabalhar
em cima




2017-04-12 15:08 GMT-03:00 Mario Rodrigues marioirodrig...@gmail.com
[oracle_br] :

>
>
> Ângelo,
>
>
> Pois eh .. vi ate uma resposta tua a alguns dias
>  "
>
> https://docs.oracle.com/cd/E17781_01/install.112/e18803/toc.htm#BABGBFJH
>
>
> AL16UTF16
>
> Unicode 4.0 UTF-16 Universal character set
>
> AL32UTF8
>
> Unicode 4.0 UTF-8 Universal character set
>
> UTF8
>
> Unicode 3.0 UTF-8 Universal character set, CESU-8 compliant
> "
>
> Vou ver se rola essa dica do UTF8 .. mas acho q o jeito é alterar na mão
> antes de importar os dados:(
>
> Vlww
>
>
> Em 12 de abril de 2017 14:55, angelo angelolis...@gmail.com [oracle_br] <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>>
>>
>> Mario,
>>
>>
>> Dá uma olhada nisso aqui =>   http://stackoverflow.com/que
>> stions/23779159/change-nls-character-set-parameters-on-oracle-11g-xe
>>
>> e depois nisso, a documentação oficial =>  https://docs.oracle.com/cd/B1
>> 9306_01/server.102/b14225/ch2charset.htm
>>
>>
>> Tenho a impressão que por limitacoes do XE, vc nao vai conseguir fazer
>> isso, mesmo que altere o banco vai chiar... eu acho
>> mas se o encoding WE8ISO8859P1  for um subset do UTF8, talvez dê um
>> samba..
>>
>>
>>
>>
>>
>> 2017-04-12 12:37 GMT-03:00 Mario Rodrigues marioirodrig...@gmail.com
>> [oracle_br] :
>>
>>>
>>>
>>> Pessoal
>>>
>>> Boa tarde
>>>
>>> Voltando com o topico, a empresa me enviou o characterset é o
>>> WE8ISO8859P1.
>>>
>>> Dai alterei usando "Alter database character set INTERNAL_USE
>>> WE8ISO8859P1;" (nunca havia feito, achei na internet)
>>> Rodando os SQL's
>>> SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET';
>>> SELECT value FROM nls_database_parameters WHERE parameter =
>>> 'NLS_CHARACTERSET'
>>>
>>> Dai blz, quando tento realizar o IMPORT aparecem 2 erros:
>>>
>>> ORA 39006 Erro interno
>>> ORA 39213 metadados não disponível
>>>
>>> Alguem já passou por isso?? Faltou fazer algo?? Já tentei ate import com
>>> o SYS e da o mesmo erro.
>>>
>>>
>>> Em 5 de abril de 2017 18:04, jlchia...@yahoo.com.br [oracle_br] <
>>> oracle_br@yahoogrupos.com.br> escreveu:
>>>


 Acredito que talvez seja no 12c apenas - mas independente disso, já que
 vc não conseguiu obter o characterset de origem pelo impdp, vc CHEGOU a
 usar a sugestão (que FUNCIONA, sim) do outro colega de usar o comando
 STRINGS no dumpfile que a empresa mandou ?? Logo nas primeiras linhas deve
 constar qual  o characterset origem usado na exportação E a ** minha **
 Sugestão de vc extrair o DDL só da tabela  pra ver se a coluna
 originalmente foi definida com tamanho em CARACTERES ou em BYTES, vc fez
 ???
  Essas coisas ABSOLUTAMENTE NÃO DEPENDEM da tal outra Empresa

 []s

   Chiappa

>>>
>>>
>>
> 
>

Re: [oracle_br] impdp

2017-04-12 Por tôpico Mario Rodrigues marioirodrig...@gmail.com [oracle_br] 
Vlw Chiappa, o banco realmente havia corrompido, porem como são testes não
é muito problema ...

Sobre as sugestões de testes, vou fazer isso sim ..

Obrigado!

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

>
>
> Ops, desconsidere o link de exemplo final, http://serverfault.com/
> questions/317151/how-do-i-make-imp-use-right-charachter-set é o link mais
> apropriado, que contém um script que muda as colunas string definidas como
> BYTE limited para CHAR limited
>
> []so
>
>   Chiappa
>
>
> ---Em oracle_br@yahoogrupos.com.br,  escreveu:
>
>
> Colega, lamento informar mas CREIO que fizeste besteira : em msg anterior
> vc já tinha dito que teu banco 11g E tinha dito que é Express Edition (não
> diretamente, mas ao perguntar se "ORACLE XE tem algum limite sobre o
> tamanho" é ESSa a dedução), e está Completamente Documentado que o Oracle
> XE ** não ** é oficialmente compatível com qualquer characterset - veja em
> http://docs.oracle.com/cd/E17781_01/install.112/e18803/toc.htm#XEINW144 a
> info :
>
> "Table 4 Supported Universal Character Sets
> Name Description
>
> AL16UTF16
>
>
> Unicode 4.0 UTF-16 Universal character set
>
> AL32UTF8
>
>
> Unicode 4.0 UTF-8 Universal character set
>
> UTF8
>
>
> Unicode 3.0 UTF-8 Universal character set, CESU-8 compliant
> 
> 
> "
>
> Então pra mim ao mandar um comando "Alter database character" para um
> characterset NÂO SUPORTADO, vc imho simplesmente CORROMPEU teu dicionário
> de dados, sim sim ?? Não é à toa que coisas que dependem de tabelas
> interas/do dicionário (como export e import) tão quebradas OKDOC ?
> Sabe-se lá de onde vc tirou a informação, mas de repente foi de páginas
> como http://www.devmedia.com.br/alterando-padrao-de-caracter-
> no-oracle-xe/9591 , que mostram a mudança no XE ** 10g **, onde elea era
> possível e autorizada, no XE 11g não mais
>   Até ** pode ser ** que recriando o dicionário de dados com os scripts
> apropriados (como CATALOG e CATPROC) mas Ninguém o Garante, vc vai tentar
> isso por sua Conta e Risco...
>
>  ===>> Lamento dizer também que vc fez isso à TOA ao saber que
> WE8ISO8859P1 era o characterset de origem, pois WE8ISO8859P1 é ** SIM ** um
> subset completo do AL32UTF8 padrão do XE , ** dificilmente ** daria qquer
> problema se estivesse com NLS_LANG setado corretamente
>
> Assim sendo, pra mim o seu "problema" aí é o MESMO que eu (E outros) já
> apontamos anteriormente, ie, no banco-origem as tabelas estão criadas com
> BYTES como limitador de strings, e no banco XE com characterset multibyte
> cada caracter pode ocupar mas de um byte... Tipo, se vc tem uma tabela
> sendo criada como :
>
> CREATE TABLE nomedatabela (C1 number,
>C2 varchar2(30),
>C3 ..
>
> No exemplo acima, no banco-origem com characterset single-byte
> WE8ISO8859P1 a tabela seria criada com a coluna C2 podendo receber até 30
> bytes, que correspondem a 30 caracteres (pois em single-byte cada caracter
> ocupa um bytes), *** MAS *** com as configs padrão no XE a mesma tabela
> seria criada com a coluna C2 podendo ter 30 ** BYTES ** no máximo, e não 30
> CARACTERES (em UTF cada caracter pode ocupar MAIS de um byte)
>
> Vc NÂO O DIZ portanto suponho que NÂO TENHA FEITO o que eu pedi (ie, de
> extrair os CREATEs das tabelas para confirmar isso), mas meu feeling é que
> é esse o seu problema
>
>  A solução portanto seria (num database XE ** recriado **, não vale o
> trabalho de tentar SALVAR esse XE que vc corrompeu, eu acho) vc CONFIRMAR
> que o NLS_LANG está corretamente setado, extrair os DDLs dos creates para
> confirmar a issue (que estará confirada TANTO se vc não ver nada na
> definição do tipo de limite da string como eu mostrei QUANTO se vc ver algo
> tipo C2 varchar2(30 BYTE)), E uma vez conbfirmada vc TERÁ que alterar os
> DDLs para que passem a informar o limite em CARACTERES e não em BYTES,
> veja  http://stackoverflow.com/questions/30707293/import-dmp-
> file-created-in-oracle-11g-we8iso8859p1-to-oracle-11g-xe-database para um
> exemplo
>
>  []s
>
>Chiappa
>
> 
>

Re: [oracle_br] impdp

2017-04-12 Por tôpico Mario Rodrigues marioirodrig...@gmail.com [oracle_br] 
Ângelo,


Pois eh .. vi ate uma resposta tua a alguns dias
 "

https://docs.oracle.com/cd/E17781_01/install.112/e18803/toc.htm#BABGBFJH


AL16UTF16

Unicode 4.0 UTF-16 Universal character set

AL32UTF8

Unicode 4.0 UTF-8 Universal character set

UTF8

Unicode 3.0 UTF-8 Universal character set, CESU-8 compliant
"

Vou ver se rola essa dica do UTF8 .. mas acho q o jeito é alterar na mão
antes de importar os dados:(

Vlww


Em 12 de abril de 2017 14:55, angelo angelolis...@gmail.com [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Mario,
>
>
> Dá uma olhada nisso aqui =>   http://stackoverflow.com/
> questions/23779159/change-nls-character-set-parameters-on-oracle-11g-xe
>
> e depois nisso, a documentação oficial =>  https://docs.oracle.com/cd/
> B19306_01/server.102/b14225/ch2charset.htm
>
>
> Tenho a impressão que por limitacoes do XE, vc nao vai conseguir fazer
> isso, mesmo que altere o banco vai chiar... eu acho
> mas se o encoding WE8ISO8859P1  for um subset do UTF8, talvez dê um
> samba..
>
>
>
>
>
> 2017-04-12 12:37 GMT-03:00 Mario Rodrigues marioirodrig...@gmail.com
> [oracle_br] :
>
>>
>>
>> Pessoal
>>
>> Boa tarde
>>
>> Voltando com o topico, a empresa me enviou o characterset é o
>> WE8ISO8859P1.
>>
>> Dai alterei usando "Alter database character set INTERNAL_USE
>> WE8ISO8859P1;" (nunca havia feito, achei na internet)
>> Rodando os SQL's
>> SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET';
>> SELECT value FROM nls_database_parameters WHERE parameter =
>> 'NLS_CHARACTERSET'
>>
>> Dai blz, quando tento realizar o IMPORT aparecem 2 erros:
>>
>> ORA 39006 Erro interno
>> ORA 39213 metadados não disponível
>>
>> Alguem já passou por isso?? Faltou fazer algo?? Já tentei ate import com
>> o SYS e da o mesmo erro.
>>
>>
>> Em 5 de abril de 2017 18:04, jlchia...@yahoo.com.br [oracle_br] <
>> oracle_br@yahoogrupos.com.br> escreveu:
>>
>>>
>>>
>>> Acredito que talvez seja no 12c apenas - mas independente disso, já que
>>> vc não conseguiu obter o characterset de origem pelo impdp, vc CHEGOU a
>>> usar a sugestão (que FUNCIONA, sim) do outro colega de usar o comando
>>> STRINGS no dumpfile que a empresa mandou ?? Logo nas primeiras linhas deve
>>> constar qual  o characterset origem usado na exportação E a ** minha **
>>> Sugestão de vc extrair o DDL só da tabela  pra ver se a coluna
>>> originalmente foi definida com tamanho em CARACTERES ou em BYTES, vc fez
>>> ???
>>>  Essas coisas ABSOLUTAMENTE NÃO DEPENDEM da tal outra Empresa
>>>
>>> []s
>>>
>>>   Chiappa
>>>
>>
>>
> 
>

Re: [oracle_br] impdp

2017-04-12 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Ops, desconsidere o link de exemplo final, 
http://serverfault.com/questions/317151/how-do-i-make-imp-use-right-charachter-set
 
http://serverfault.com/questions/317151/how-do-i-make-imp-use-right-charachter-set
 é o link mais apropriado, que contém um script que muda as colunas string 
definidas como BYTE limited para CHAR limited

[]s

  Chiappa
 

---Em oracle_br@yahoogrupos.com.br,  escreveu:

 Colega, lamento informar mas CREIO que fizeste besteira : em msg anterior vc 
já tinha dito que teu banco 11g E tinha dito que é Express Edition (não 
diretamente, mas ao perguntar se "ORACLE XE tem algum limite sobre o tamanho" é 
ESSa a dedução), e está Completamente Documentado que o Oracle XE ** não ** é 
oficialmente compatível com qualquer characterset - veja em 
http://docs.oracle.com/cd/E17781_01/install.112/e18803/toc.htm#XEINW144 a info :

"Table 4 Supported Universal Character Sets
Name Description

AL16UTF16


Unicode 4.0 UTF-16 Universal character set

AL32UTF8


Unicode 4.0 UTF-8 Universal character set

UTF8


Unicode 3.0 UTF-8 Universal character set, CESU-8 compliant

"

Então pra mim ao mandar um comando "Alter database character" para um 
characterset NÂO SUPORTADO, vc imho simplesmente CORROMPEU teu dicionário de 
dados, sim sim ?? Não é à toa que coisas que dependem de tabelas interas/do 
dicionário (como export e import) tão quebradas OKDOC ? Sabe-se lá de onde 
vc tirou a informação, mas de repente foi de páginas como 
http://www.devmedia.com.br/alterando-padrao-de-caracter-no-oracle-xe/9591 , que 
mostram a mudança no XE ** 10g **, onde elea era possível e autorizada, no XE 
11g não mais
  Até ** pode ser ** que recriando o dicionário de dados com os scripts 
apropriados (como CATALOG e CATPROC) mas Ninguém o Garante, vc vai tentar isso 
por sua Conta e Risco...
  
 ===>> Lamento dizer também que vc fez isso à TOA ao saber que WE8ISO8859P1 era 
o characterset de origem, pois WE8ISO8859P1 é ** SIM ** um subset completo do 
AL32UTF8 padrão do XE , ** dificilmente ** daria qquer problema se estivesse 
com NLS_LANG setado corretamente 

Assim sendo, pra mim o seu "problema" aí é o MESMO que eu (E outros) já 
apontamos anteriormente, ie, no banco-origem as tabelas estão criadas com BYTES 
como limitador de strings, e no banco XE com characterset multibyte cada 
caracter pode ocupar mas de um byte... Tipo, se vc tem uma tabela sendo criada 
como :

CREATE TABLE nomedatabela (C1 number,
   C2 varchar2(30),
   C3 ..
   
No exemplo acima, no banco-origem com characterset single-byte WE8ISO8859P1 a 
tabela seria criada com a coluna C2 podendo receber até 30 bytes, que 
correspondem a 30 caracteres (pois em single-byte cada caracter ocupa um 
bytes), *** MAS *** com as configs padrão no XE a mesma tabela seria criada com 
a coluna C2 podendo ter 30 ** BYTES ** no máximo, e não 30 CARACTERES (em UTF 
cada caracter pode ocupar MAIS de um byte)

Vc NÂO O DIZ portanto suponho que NÂO TENHA FEITO o que eu pedi (ie, de extrair 
os CREATEs das tabelas para confirmar isso), mas meu feeling é que é esse o seu 
problema 

 A solução portanto seria (num database XE ** recriado **, não vale o trabalho 
de tentar SALVAR esse XE que vc corrompeu, eu acho) vc CONFIRMAR que o NLS_LANG 
está corretamente setado, extrair os DDLs dos creates para confirmar a issue 
(que estará confirada TANTO se vc não ver nada na definição do tipo de limite 
da string como eu mostrei QUANTO se vc ver algo tipo C2 varchar2(30 BYTE)), E 
uma vez conbfirmada vc TERÁ que alterar os DDLs para que passem a informar o 
limite em CARACTERES e não em BYTES, veja  
http://stackoverflow.com/questions/30707293/import-dmp-file-created-in-oracle-11g-we8iso8859p1-to-oracle-11g-xe-database
 para um exemplo
 
 []s
 
   Chiappa

Re: [oracle_br] impdp

2017-04-12 Por tôpico jlchia...@yahoo.com.br [oracle_br] 
Colega, lamento informar mas CREIO que fizeste besteira : em msg anterior vc já 
tinha dito que teu banco 11g E tinha dito que é Express Edition (não 
diretamente, mas ao perguntar se "ORACLE XE tem algum limite sobre o tamanho" é 
ESSa a dedução), e está Completamente Documentado que o Oracle XE ** não ** é 
oficialmente compatível com qualquer characterset - veja em 
http://docs.oracle.com/cd/E17781_01/install.112/e18803/toc.htm#XEINW144 a info :

"Table 4 Supported Universal Character Sets
Name Description

AL16UTF16


Unicode 4.0 UTF-16 Universal character set

AL32UTF8


Unicode 4.0 UTF-8 Universal character set

UTF8


Unicode 3.0 UTF-8 Universal character set, CESU-8 compliant

"

Então pra mim ao mandar um comando "Alter database character" para um 
characterset NÂO SUPORTADO, vc imho simplesmente CORROMPEU teu dicionário de 
dados, sim sim ?? Não é à toa que coisas que dependem de tabelas interas/do 
dicionário (como export e import) tão quebradas OKDOC ? Sabe-se lá de onde 
vc tirou a informação, mas de repente foi de páginas como 
http://www.devmedia.com.br/alterando-padrao-de-caracter-no-oracle-xe/9591 , que 
mostram a mudança no XE ** 10g **, onde elea era possível e autorizada, no XE 
11g não mais
  Até ** pode ser ** que recriando o dicionário de dados com os scripts 
apropriados (como CATALOG e CATPROC) mas Ninguém o Garante, vc vai tentar isso 
por sua Conta e Risco...
  
 ===>> Lamento dizer também que vc fez isso à TOA ao saber que WE8ISO8859P1 era 
o characterset de origem, pois WE8ISO8859P1 é ** SIM ** um subset completo do 
AL32UTF8 padrão do XE , ** dificilmente ** daria qquer problema se estivesse 
com NLS_LANG setado corretamente 

Assim sendo, pra mim o seu "problema" aí é o MESMO que eu (E outros) já 
apontamos anteriormente, ie, no banco-origem as tabelas estão criadas com BYTES 
como limitador de strings, e no banco XE com characterset multibyte cada 
caracter pode ocupar mas de um byte... Tipo, se vc tem uma tabela sendo criada 
como :

CREATE TABLE nomedatabela (C1 number,
   C2 varchar2(30),
   C3 ..
   
No exemplo acima, no banco-origem com characterset single-byte WE8ISO8859P1 a 
tabela seria criada com a coluna C2 podendo receber até 30 bytes, que 
correspondem a 30 caracteres (pois em single-byte cada caracter ocupa um 
bytes), *** MAS *** com as configs padrão no XE a mesma tabela seria criada com 
a coluna C2 podendo ter 30 ** BYTES ** no máximo, e não 30 CARACTERES (em UTF 
cada caracter pode ocupar MAIS de um byte)

Vc NÂO O DIZ portanto suponho que NÂO TENHA FEITO o que eu pedi (ie, de extrair 
os CREATEs das tabelas para confirmar isso), mas meu feeling é que é esse o seu 
problema 

 A solução portanto seria (num database XE ** recriado **, não vale o trabalho 
de tentar SALVAR esse XE que vc corrompeu, eu acho) vc CONFIRMAR que o NLS_LANG 
está corretamente setado, extrair os DDLs dos creates para confirmar a issue 
(que estará confirada TANTO se vc não ver nada na definição do tipo de limite 
da string como eu mostrei QUANTO se vc ver algo tipo C2 varchar2(30 BYTE)), E 
uma vez conbfirmada vc TERÁ que alterar os DDLs para que passem a informar o 
limite em CARACTERES e não em BYTES, veja  
http://stackoverflow.com/questions/30707293/import-dmp-file-created-in-oracle-11g-we8iso8859p1-to-oracle-11g-xe-database
 para um exemplo
 
 []s
 
   Chiappa

Re: [oracle_br] impdp

2017-04-12 Por tôpico angelo angelolis...@gmail.com [oracle_br] 
Mario,


Dá uma olhada nisso aqui =>
http://stackoverflow.com/questions/23779159/change-nls-character-set-parameters-on-oracle-11g-xe

e depois nisso, a documentação oficial =>
https://docs.oracle.com/cd/B19306_01/server.102/b14225/ch2charset.htm


Tenho a impressão que por limitacoes do XE, vc nao vai conseguir fazer
isso, mesmo que altere o banco vai chiar... eu acho
mas se o encoding WE8ISO8859P1  for um subset do UTF8, talvez dê um samba..





2017-04-12 12:37 GMT-03:00 Mario Rodrigues marioirodrig...@gmail.com
[oracle_br] :

>
>
> Pessoal
>
> Boa tarde
>
> Voltando com o topico, a empresa me enviou o characterset é o WE8ISO8859P1.
>
> Dai alterei usando "Alter database character set INTERNAL_USE
> WE8ISO8859P1;" (nunca havia feito, achei na internet)
> Rodando os SQL's
> SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET';
> SELECT value FROM nls_database_parameters WHERE parameter =
> 'NLS_CHARACTERSET'
>
> Dai blz, quando tento realizar o IMPORT aparecem 2 erros:
>
> ORA 39006 Erro interno
> ORA 39213 metadados não disponível
>
> Alguem já passou por isso?? Faltou fazer algo?? Já tentei ate import com o
> SYS e da o mesmo erro.
>
>
> Em 5 de abril de 2017 18:04, jlchia...@yahoo.com.br [oracle_br] <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>>
>>
>> Acredito que talvez seja no 12c apenas - mas independente disso, já que
>> vc não conseguiu obter o characterset de origem pelo impdp, vc CHEGOU a
>> usar a sugestão (que FUNCIONA, sim) do outro colega de usar o comando
>> STRINGS no dumpfile que a empresa mandou ?? Logo nas primeiras linhas deve
>> constar qual  o characterset origem usado na exportação E a ** minha **
>> Sugestão de vc extrair o DDL só da tabela  pra ver se a coluna
>> originalmente foi definida com tamanho em CARACTERES ou em BYTES, vc fez
>> ???
>>  Essas coisas ABSOLUTAMENTE NÃO DEPENDEM da tal outra Empresa
>>
>> []s
>>
>>   Chiappa
>>
>
> 
>

Re: [oracle_br] impdp

2017-04-12 Por tôpico Mario Rodrigues marioirodrig...@gmail.com [oracle_br] 
Pessoal

Boa tarde

Voltando com o topico, a empresa me enviou o characterset é o WE8ISO8859P1.

Dai alterei usando "Alter database character set INTERNAL_USE WE8ISO8859P1;"
(nunca havia feito, achei na internet)
Rodando os SQL's
SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET';
SELECT value FROM nls_database_parameters WHERE parameter =
'NLS_CHARACTERSET'

Dai blz, quando tento realizar o IMPORT aparecem 2 erros:

ORA 39006 Erro interno
ORA 39213 metadados não disponível

Alguem já passou por isso?? Faltou fazer algo?? Já tentei ate import com o
SYS e da o mesmo erro.


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

>
>
> Acredito que talvez seja no 12c apenas - mas independente disso, já que vc
> não conseguiu obter o characterset de origem pelo impdp, vc CHEGOU a usar a
> sugestão (que FUNCIONA, sim) do outro colega de usar o comando STRINGS no
> dumpfile que a empresa mandou ?? Logo nas primeiras linhas deve constar
> qual  o characterset origem usado na exportação E a ** minha **
> Sugestão de vc extrair o DDL só da tabela  pra ver se a coluna
> originalmente foi definida com tamanho em CARACTERES ou em BYTES, vc fez
> ???
>  Essas coisas ABSOLUTAMENTE NÃO DEPENDEM da tal outra Empresa
>
> []s
>
>   Chiappa
> 
>