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] Re: Sequences schema sys

[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

[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 

Re: [oracle_br] Re: Sequences schema sys

[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

[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