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