Percebe que coloquei o scope memory, ou seja, não será alterado no spfile. Observe isso.
Reforço: cuidado ao alterar parâmetros que tu não sabe porque foram setados... Att,/Regards, Vitor Jr. Infraestrutura / Infrastructure Team Oracle 11g DBA Certified Professional - OCP Oracle Certified Expert, Oracle Real Application Clusters 11g and Grid Infrastructure Administrator - OCE Oracle Database 11g Performance Tuning Certified Expert - OCE Oracle Exadata 11g Certified Implementation Specialist Oracle Certified Associate, MySQL 5 mail, gtalk e msn: <mailto:vitorj...@gmail.com> vitorj...@gmail.com <http://certificacaobd.com.br/> http://certificacaobd.com.br/ skype: vjunior1981 <https://mybizcard.co/vitor.jr.385628> https://mybizcard.co/vitor.jr.385628 De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome de Rafael Mendonca Enviada em: quarta-feira, 14 de agosto de 2013 16:59 Para: oracle_br@yahoogrupos.com.br Assunto: Re: RES: [oracle_br] Data Guard Vitor, lembro-me de ter conseguido resetar o parâmetro da forma que coloquei, mas não tenho certeza, tanto que estava aqui guardado quando uso algumas vezes. Bom, utilizei o seu e funcionou, dei um crosscheck e agora os archives que eram para estar como obsoletos, se tornaram obsoletos. A FRA jpa estava 90% cheia, depois disso caiu para 33% ________________________________ De: Vitor Jr. <vitorj...@gmail.com <mailto:vitorjr81%40gmail.com> > Para: oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> Enviadas: Quarta-feira, 14 de Agosto de 2013 16:40 Assunto: RES: [oracle_br] Data Guard Se tu tá tentando ‘resetar’ o valor do parâmetro é dessa forma: alter system set log_archive_dest_4='' scope=memory sid='*'; Mas aviso, sair alterando parâmetros assim, sem conhecer o contexto/conceito do que está acontecendo, não é nada recomendado. Att,/Regards, Vitor Jr. Infraestrutura / Infrastructure Team Oracle 11g DBA Certified Professional - OCP Oracle Certified Expert, Oracle Real Application Clusters 11g and Grid Infrastructure Administrator - OCE Oracle Database 11g Performance Tuning Certified Expert - OCE Oracle Exadata 11g Certified Implementation Specialist Oracle Certified Associate, MySQL 5 mail, gtalk e msn: <mailto:mailto:vitorjr81%40gmail.com> mailto:vitorjr81%40gmail.com <http://certificacaobd.com.br/> http://certificacaobd.com.br/ skype: vjunior1981 <https://mybizcard.co/vitor.jr.385628> https://mybizcard.co/vitor.jr.385628 De: mailto:oracle_br%40yahoogrupos.com.br [mailto:mailto:oracle_br%40yahoogrupos.com.br] Em nome de Rafael Mendonca Enviada em: quarta-feira, 14 de agosto de 2013 16:37 Para: mailto:oracle_br%40yahoogrupos.com.br Assunto: [oracle_br] Data Guard BANNER ---------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production PL/SQL Release 11.2.0.3.0 - Production CORE 11.2.0.3.0 Production TNS for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production NLSRTL Version 11.2.0.3.0 - Production Pessoal, existe um banco de produção chamado X que possuia um data guard chamado Y. Acontece que ocorreu um problema no banco de dados Y aonde ficava armazenado o data guard e resolvemos retirar o data guard de cena. Só que consultando o banco de dados X, me deparo com a seguinte situação: log_archive_dest_4 string service="Y", LGWR SYNC AF FIRM delay=0 optional compress ion=disable max_failure=0 max_ connections=1 reopen=300 db_un ique_name="BDTRF5" net_timeout =30, valid_for=(all_logfiles,p rimary_role) Ou seja, o log_archive_dest_4 ainda está apontando para ele. E isso é um dos motivos que o archive não está ficando obsoleto. Como conheço muito pouco o funcionamento/arquitetura do data guard(é uma das coisas que irei começar a estudar próxima semana) fiz o seguinte: DGMGRL for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - 64bit Production Copyright (c) 2000, 2009, Oracle. All rights reserved. Welcome to DGMGRL, type "help" for information. Connected. DGMGRL> show configuration Configuration - DGConfig1 Protection Mode: MaxAvailability Databases: X - Primary database Z - Physical standby database W - Physical standby database Error: ORA-16810: multiple errors or warnings detected for the database Fast-Start Failover: DISABLED Configuration Status: ERROR DGMGRL> Ou seja, o database Y não está mais na lista, mas no destino do archive ele ainda consta. Tentei resetar o log_archive_dest_4 e não obtive sucesso: alter system reset log_archive_dest_4 scope=spfile; * ERROR at line 1: ORA-32010: cannot find entry to delete in SPFILE Alguém pode ajudar? [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]
