Chiappa, obrigado pelo rápido retorno. Eu como não tenho experiência com standby físico/lógico/snapshot standby, irei dropar o database e gerar um duplicate database a partir do meu database de produção. Até encomendei um livro pela amazon do Data Guard da Oracle Press para ter um pouco mais de noção sobre o funcionando do data guard. Como esse database de homologação é pedido a atualização sobre demanda, o que acontece 1x a cada 2 meses. Eu irei atualizar sem a necessidade de um snapshot stanby.
________________________________ De: J. Laurindo Chiappa <jlchia...@yahoo.com.br> Para: oracle_br@yahoogrupos.com.br Enviadas: Segunda-feira, 29 de Julho de 2013 11:05 Assunto: [oracle_br] Re: ORA-38701: Flashback database log % seq 1 thread %: E é claro : pensando mais friamente, se esse banco é um standby, OBVIAMENTE os dados vêm de um banco Produção, origem - então, caso não consiga recuperar esse database, IMAGINO que vc sempre tem a opção de RECONSTRUIR esse standby, trazendo de novo para esses servidores os datafiles do banco-origem e recriando o standby.... []s Chiappa --- Em mailto:oracle_br%40yahoogrupos.com.br, "J. Laurindo Chiappa" <jlchiappa@...> escreveu > > Ah, agora tá mais claro : > http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/11g/r2/prod/ha/dataguard/usingsnapshot/usingsnapshot.htm#p > nos lembra que um SNAPSHOT STANDBY **** obrigatoriamente *** precisa E > DEPENDE DA feature de flashback database, tá EXPLICADO portanto porque vc não > conseguiu abrir o database com o flashback desativado... É uma sinuca, pois > vc não consegue ter snapshot standby sem flashback e não consegue ativar o > flashback por causa do log requerido erradamente deletado... > Bem, eu não estou com uma config do tipo para testar, mas falando de cabeça > acho mesmo que a primeira tentativa acho que seria a que eu citei, ie, tentar > recriar os flashback logs com : > > shutdown immediate; > startup mount; > alter database flashback off; > > e só depois : > > alter database flashback on; > > e se aí o RDBMS responder com Instance recovery required , fazer o recover > database; (já que vc ** TEM ** aí todos os archived redo logs, com certeza , > né ??) ..... > Isso feito, aí sim tentar o alter database open.... Caso não dê certo, > manda pra gente o copy/paste das saídas todas do sqlplus, que a gente pode > palpitar em cima, E é claro que vc vai se garantir com um Chamado no Suporte, > MAS nesse caso pode ir se preparando para o RESTORE do último backup, penso > eu .... > > []s > > Chiappa > > --- Em mailto:oracle_br%40yahoogrupos.com.br, Rafael Mendonca > <raffaell.ti77@> escreveu > > > > CONFIRME para a gente se o database REALMENTE crashou: > > > > R: Crashou > > > > > > se tiver msgs sobre isso no alert.log, as mostre também: > > > > R: Nenhuma mensagem relevante ao alert.log > > > > > > CONFIRME que vc está usando a FRA para archived redo logs bem como para > > flashback logs... > > > > > > R: > > > > SQL> show parameter instan > > > > NAME TYPE VALUE > > ------------------------------------ ----------- > > ------------------------------ > > active_instance_count integer > > cluster_database_instances integer 1 > > instance_groups string > > instance_name string BDTRF5 > > instance_number integer 0 > > instance_type string RDBMS > > open_links_per_instance integer 4 > > parallel_instance_group string > > parallel_server_instances integer 1 > > > > SQL> archive log list; > > Database log mode Archive Mode > > Automatic archival Enabled > > Archive destination USE_DB_RECOVERY_FILE_DEST > > Oldest online log sequence 170 > > Next log sequence to archive 176 > > Current log sequence 176 > > db_recovery_file_dest string /u06/fast_recovery_area/BDTRF5/BDTRF5 > > > > log_archive_dest_1 location=USE_DB_RECOVERY_FILE_DEST, > > valid_for=(ALL_LOGFILES,ALL_ROLES) > > log_archive_dest_2 SERVICE=TRF5PRD LGWR ASYNC > > VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) DB_UNIQUE_NAME=TRF5PRD > > log_archive_dest_3 LOCATION=BDTRF5 OPTIONAL REOPE N=300 > > log_archive_dest_4 SERVICE=BDTRF5 LGWR ASYNC NOAFFIRM > > VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) DB_UNIQUE_NAME=BDTRF5 > > log_archive_config dg_config=(BDTRF5,TRF5PRD,TRF5PRDS,TRF5PRDG) > > > > > > **Esse database é um snapshot stanby. > > > > > > desativar o flashback e depois o ativar de novo, pois aí o RDBMS vai criar > > flashback logs novos e aí sim vc deverá ser capaz de colocar o banco em > > OPEN.... > > > > SQL> alter database flashback on; > > alter database flashback on > > * > > ERROR at line 1: > > ORA-38706: Cannot turn on FLASHBACK DATABASE logging. > > ORA-38714: Instance recovery required. > > > > > > > > b. CONFIRME que vc tem livre o espaço em disco necessário para poder criar > > os flashback logs > > > > R: Sim, existe espaço em disco agora. > > > > > > > > > > > > > > ________________________________ > > De: J. Laurindo Chiappa <jlchiappa@> > > Para: mailto:oracle_br%40yahoogrupos.com.br > > Enviadas: Domingo, 28 de Julho de 2013 15:00 > > Assunto: [oracle_br] Re: ORA-38701: Flashback database log % seq 1 thread %: > > > > > > > > > > > > > > Bom, primeiro de tudo, tenho que observar que é bem difícil trabalhar "no > > escuro", sem saber o papel do database (pois databases standby, por > > exemplo) devem ser administrados de maneira diferente, então ANTES de > > assumir a administração desse database Alguém deveria ter seguido um > > checklist, verificado como está instalado, quem usa, para que usa, se o > > database está aberto normalmente ou se é standby, enfim, os detalhes - é > > Bem difícil na hora do apuro, com o database fora, tentar só aí levantar o > > status... > > Outro ponto : CONFIRME para a gente se o database REALMENTE crashou, ou se > > só "congelou" (o que tipicamente acontece quando o espaço de archived redo > > logs enche) - se tiver msgs sobre isso no alert.log, as mostre também -, e > > CONFIRME que vc está usando a FRA para archived redo logs bem como para > > flashback logs... > > > > Bom, sobre a sua questão : vamos dar pitacos a respeito ** MAS ** se esse > > database é importante como vc diz, minha Recomendação Básica é ter CERTEZA > > de como e onde estão os backups E abrir um Chamado no Suporte Oracle, para > > se assegurar, E tentar tirar um backup agora, se possível, ** E ** deixar > > de atirar para todo lado, tentando CONVERTER STANDBY sem saber se é standby > > - segura aí a onda.... > > > > A resposta : eu mesmo nunca vi uma situação do seu tipo, mas diria para vc > > (UMA VEZ QUE a recomendação acima tenha sido seguida) : > > > > a. LISTE os parâmetros de inicialização não-default usados por esse > > database : se ele estiver em MOUNT acredito que vc deve conseguir os > > recuperar pela V$PARAMETER, se não aí localize o initfile ou spfile que > > esse database está usando , OU então veja no alert.log : a idéia aqui é > > CONFIRMAR que esse database é mesmo single-instance, não é um standby, > > enfim, é um banco "normal"... INCLUSIVE, se esse database estiver como > > standby, afaik vc *** VAI TER QUE *** quebrar o standby antes de proceder > > para o poder abrir... > > > > b. CONFIRME que vc tem livre o espaço em disco necessário para poder criar > > os flashback logs > > > > c) cfrme > > http://www.dba-oracle.com/t_rman_159_restore_dropped_tablespace.htm e a > > nota metalink "Database report errors when Flashback Logs are deleted > > Manually" (Doc ID 302488.1) - e isso foi Exatamente o teu erro pelo que > > entendi, vc saiu deletando manualmente flashback logs - Realmente dá erro > > se vc deletar manualmente o flashback log corrente, mas o work-around é, > > com o banco em MOUNT, desativar o flashback e depois o ativar de novo, pois > > aí o RDBMS vai criar flashback logs novos e aí sim vc deverá ser capaz de > > colocar o banco em OPEN.... > > Se não der certo, mostra EXATAMENTE para nós as msgs de erro do sqlplus, > > mostra para nós o alert.log desde o último startup bem-sucedido até as > > últimas linhas criadas depois desta tentativa de OPEN, e PLZ DETALHA > > versões de todo o ambiente envolvido, tipo de utilização do banco e > > parâmetros usados, que a gente pode tentar palpitar mais... > > > > []s > > > > Chiappa > > > > OBS Importante : vc TEM que, depois de abrir o database, DESCOBRIR a CAUSA > > do esgotamente de espaço - entre muitas outras possibilidades, vc pode > > estar caindo no caso relatado na nota metalink "Applied Archivelogs Are Not > > Deleted On Physical Standby Site from Flash Recovery Area" (Doc ID > > 404338.1) e quetais... > > > > --- Em mailto:oracle_br%40yahoogrupos.com.br, Rafael Mendonca > > <raffaell.ti77@> escreveu > > > > > > Desculpe pela falta de informações Chiappa, é que na hora fiquei meio > > > desesperado e ainda não consegui levantar o banco. > > > > > > Seguinte, esse banco estava funcionando normalmente, é um importante > > > database de homologação, e o pessoal usa muito esse banco, o banco estava > > > em modo archivelog e com o flashback database ON, o espaço em disco > > > estourou e o database caiu. O máximo que consegui foi montar o database. > > > > > > Verifiquei que existia um ponto de restauração garantido e tentei dropar, > > > mas sem sucesso. Alterei sim, o banco de dados para flashback OFF. Só que > > > o modo de flashback agora ficou como "RESTORE POINT ONLY" e o database > > > continou sem subir. > > > > > > A merda que eu fiz foi excluir esses logs de flashback que foram criados > > > com o GUARANTEE pelo Sistema Operacional, e agora não consigo mais > > > levantar o database. Antes eu já não estava conseguindo. Enfim, estou sem > > > uma solução para o problema. > > > > > > Pois o Restore POint não consigo dropar, sem isso o database não sobe, e > > > como o arquivo físico foi apagado, ele não consegue achar o arquivo > > > obviamente. > > > > > > Aí executei os comandos abaixo tentando levantar o database, sobre o > > > standby eu não sei nada a respeito, pois é um database que chegou para > > > sermos responsáveis a pouquíssimo tempo. > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > De: J. Laurindo Chiappa <jlchiappa@> > > > Para: mailto:oracle_br%40yahoogrupos.com.br > > > Enviadas: Sábado, 27 de Julho de 2013 11:28 > > > Assunto: [oracle_br] Re: ORA-38701: Flashback database log % seq 1 thread > > > %: > > > > > > > > > > > > > > > Colega, plz dá um mínimo de backgroud pra gente : isso aí é um RESTORE de > > > um backup vindo de outra máquina ?? Ou é um banco que já existia, parou e > > > vc está tentando startar ele ?? SE é um banco que já existia, esse banco > > > será que já foi um standby no passado ?? Dá uma chance pra gente entender > > > de onde vieram esses arquivos que vc está tentando abrir como database , > > > né não ?? Outra coisa estranha é que normalmente vc usa esse ALTER > > > DATABASE CONVERT TO PHYSICAL STANDBY; para converter um database que JÁ > > > ESTÁ ABERTO como snapshot standby para physical, POR QUR vc tentou usar > > > isso se não conseguia abrir o database ??? DETALHEs, DETALHEs, plz, do > > > que vc quer fazer, de onde veio esse database, COMO os arquivos foram > > > enviados para o outro servidor se for o caso (ie, via RMAN ou não, > > > consistent ou não, etc)... > > > > > > Anyway : > > > > > > - flashback database NÃO tem a ver com standby, não é uma Exigência nem > > > nada assim > > > > > > - SE " o log de flashback(físico) não existe mais", então POR QUE vc > > > simplesmente não DESLIGOU (temporariamente que seja) o flashback option > > > do database com : > > > > > > shutdown immediate > > > startup mount > > > alter database flashback off; > > > alter database open; > > > > > > ???? > > > > > > []s > > > > > > Chiappa > > > > > > --- Em mailto:oracle_br%40yahoogrupos.com.br, Rafael Mendonca > > > <raffaell.ti77@> escreveu > > > > > > > > SQL> select FLASHBACK_ON from v$database; > > > > FLASHBACK_ON > > > > ------------------ > > > > RESTORE POINT ONLY > > > > > > > > > > > > SQL> select * from v$restore_point; > > > > select * from v$restore_point > > > > * > > > > ERROR at line 1: > > > > ORA-38701: Flashback database log 35 seq 896 thread 1: > > > > "/u06/fast_recovery_area/XXXX/XXXX/XXXX/flashback/o1_mf_8yq3s0ks_.flb" > > > > ORA-27037: unable to obtain file status > > > > IBM AIX RISC System/6000 Error: 2: No such file or directory > > > > Additional information: 3 > > > > > > > > SQL> select name from v$restore_point; > > > > NAME > > > > ---------------------------------------------------------- > > > > SNAPSHOT_STANDBY_REQUIRED_07/21/2013 05:00:44 > > > > > > > > SQL> drop restore point "SNAPSHOT_STANDBY_REQUIRED_07/21/2013 05:00:44"; > > > > drop restore point "SNAPSHOT_STANDBY_REQUIRED_07/21/2013 05:00:44" > > > > * > > > > ERROR at line 1: > > > > ORA-38799: Cannot drop guaranteed restore point internally created for > > > > snapshot > > > > standby > > > > > > > > SQL> alter database convert to physical standby; > > > > alter database convert to physical standby > > > > * > > > > ERROR at line 1: > > > > ORA-19926: Database cannot be converted at this time > > > > > > > > > > > > Pessoal, não estou conseguindo subir um banco por conta desse restore > > > > point guarantee que criaram e o espaço em disco estourou, e ainda por > > > > cima o log de flashback(físico) não existe mais. > > > > Esse é um database que não está como standby, não sei o motivo de está > > > > acontecendo esse erro. > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > [As partes desta mensagem que não continham texto foram removidas]
