Sim, é Mas ai depende muito da criticidade do seu negocio.. Vale a pena guardar muitos meses de backup ? Ou um tempo menor seria suficiente ? Via de regra, uma geração de backup full + archived logs desde o ultimo backup full, é possivel levantar uma base caída.
Vai ser uma discussão bacana essa.. 2014-05-29 11:31 GMT-03:00 Erik Castilho [email protected] [oracle_br] < [email protected]>: > > > Senhores, bom dia! > > Aproveitando o gancho, é como prática excluir os archivelogs mais antigos? > Alguém tem uma documentação sobre melhores práticas de backup e também de > recovery que possa me passar? > > > Em 29 de maio de 2014 11:01, carlos silva [email protected] > [oracle_br] <[email protected]> escreveu: > > >> >> Oracle 11.2.0.1.0 >> SO: Windows 7 32 bits >> >> Certo Pessoal.. Eu estava realizando alguns testes aqui e simulei a perda >> de um control file com o banco em modo noarchivelog. Eu fiz um backup >> frio da base ontem e hoje simulei uma perda. Antes de deletá-lo criei uma >> tabela, inseri 1000 registros e comitei. Consegui recuperar o banco e a >> tabela criada também foi recuperada.. Não entendi uma coisa: Se >> eu restaurei o controlfile a partir do backup do dia anterior e não tinha >> essa tabela lá, como o Oracle conseguiu recuperá-la? Como vocês informaram, >> se o banco está em noarchivelog os dados posteriores ao último backup são >> perdidos em casos de recuperação correto? É isso mesmo? >> >> Segue o erro que ocorreu hoje após deletar o control file e ao subir a >> instancia. >> >> ORA-00214: arquivo de controle >> 'C:\APP\CARLOS\FLASH_RECOVERY_AREA\ORCL2\CONTROL02.CTL' vers?o 7772 >> incompativel com arquivo 'C:\APP\CARLOS\ORADATA\ORCL2\CONTROL01.CTL' >> vers?o >> 7744 >> >> Após esse erro, copiei o controlfile do backup para o diretório de >> origem dos arquivos do oracle que é o 'C:\APP\CARLOS\ORADATA\ORCL2\ e o >> erro persistiu. Então segui os passos abaixo para subir a instância. >> >> 1 - SHUTDOWN ABORT; >> 2 - CREATE PFILE = 'C:\APP\INITORCL2.ORA' FROM SPFILE; >> 3 - SHUTDOWN ABORT; >> 4 - STARTUP NOMOUNT PFILE = 'C:\APP\INITORCL2.ORA'; >> 5 - HO RMAN TARGET/ >> RMAN>RESTORE CONTROLFILE FROM AUTOBACKUP; >> RMAN> quit >> 6 - CREATE SPFILE FROM PFILE = 'C:\APP\INITORCL2.ORA'; >> 7 - SHUTDOWN IMMEDIATE; >> 8- STARTUP MOUNT; >> 9 - HO RMAN TARGET; --> RECOVER DATABASE; >> 10 - ALTER DATABASE OPEN RESETLOGS; >> >> Não entendi uma outra coisa.. Após seguir os passos e subir o banco, >> verifiquei que ele está em modo archivelog.. Não entendi isso, sendo que >> coloquei ele em modo noarchivelog para simular esse cenário de perda. >> >> >> SQL> shutdown immediate; >> Banco de dados fechado. >> Banco de dados desmontado. >> InstÔncia ORACLE desativada. >> >> SQL> startup mount; >> InstÔncia ORACLE iniciada. >> Total System Global Area 744910848 bytes >> Fixed Size 1374696 bytes >> Variable Size 427820568 bytes >> Database Buffers 310378496 bytes >> Redo Buffers 5337088 bytes >> Banco de dados montado. >> >> SQL> ALTER DATABASE NOARCHIVELOG; >> Banco de dados alterado. >> >> SQL> ALTER DATABASE OPEN; >> Banco de dados alterado. >> >> SQL> ARCHIVE LOG LIST; >> Modo log de banco de dados Modo Sem Arquivamento >> Arquivamento automßtico Desativado >> Destino de arquivamento USE_DB_RECOVERY_FILE_DEST >> A sequÛncia de log on-line mais antiga 1 >> SequÛncia de log atual 1 >> >> >> >> Após a recuperação, o banco ficou em modo archivelog. >> >> SQL> archive log list; >> Modo log de banco de dados Modo de Arquivamento >> Arquivamento automßtico Ativado >> Destino de arquivamento USE_DB_RECOVERY_FILE_DEST >> A sequÛncia de log on-line mais antiga 1 >> Pr¾xima sequÛncia de log a arquivar 1 >> SequÛncia de log atual 1 >> >> Em Quinta-feira, 29 de Maio de 2014 10:07, "angelo [email protected] >> [oracle_br]" <[email protected]> escreveu: >> >> >> Lembrando que Export nao é backup hein.. >> >> Isso é só um "flash" do que vc tem naquela hora dentro de um determinado >> esquema... claro que ajuda, mas nao pode ser considerado um backup.. nao >> atende aos preceitos de um bom pcn. >> tem que envolver o rman, e a base precisa rodar em archivelog >> >> 2014-05-29 9:59 GMT-03:00 David Ricardo [email protected] >> [oracle_br] <[email protected]>: >> >> > >> >Olá, concordo com o Chiappa em suas observações. Uma opção seria usar >> uma cópia lógica do seu banco, que não é nem considerado backup ( DUMP), >> visto que como ocorre a extração no momento de sua execução, os dados para >> frente seriam perdidos, considerando assim uma perda de dados por não ser >> um backup fisico e integro de seus dados. Com um DUMP pelo menos perderia >> suponhamos 1 dia de trabalho ou algumas horas, levando em consideração >> quantas vezes você executa EXPORT por dia do seu banco de dados. >> > >> >Abraço >> > >> > >> > >> > >> > >> >---------------------------------------------------------- >> >David Siqueira >> >DBA Oracle e Oracle ACE Member >> >BLOG .: http://databaseguard.blogspot.com/ >> >> > >> > >> > >> >"O mistério da vida me causa a mais forte emoção. É o sentimento que >> suscita a beleza e a verdade, cria a arte e a ciência. Se alguém não >> conhece essa sensação ou não pode mais exprimir espanto ou surpresa, já é >> um morto-vivo e seus olhos se cegaram.".(Albert Einstein - 1879 - 1955)" >> > >> > >> > >> > >> >Em 29 de maio de 2014 00:21, carlos silva [email protected] >> [oracle_br] <[email protected]> escreveu: >> > >> > >> > >> >> >> >> >> >>Muito obrigado pela resposta Chiappa, tirou as minhas duvidas. >> >> >> >>------------------------------ >> >>Em qua, 28 de mai de 2014 22:55 BRT [email protected] [oracle_br] >> escreveu: >> >> >> >> >> >>>Tudo jóia ? Então, no RDBMS Oracle o conceito é simples : recuperação >> se faz aplicando-se nos datafiles em disco os redo logs (os logs de >> transação, que registram as alterações havidas) sequencialmente - ora, se >> vc está em modo noarchive significa que quando o log file sendo usado >> encheu, vc ** não tem ** uma cópia dele, ele é reusado portanto vc PERDE os >> logs todos que houveram no passado, só tem os logs mais recentes, online... >> >>> Sendo assim, vc só poderá fazer o recover ** SE ** , por uma sorte >> incrível, as alterações necessárias para trazer o(s) datafile(s) a >> recuperar ainda estão presentes no redo log file online, é isso.... Na >> prática num ambiente produtivo isso é muito, muito, MUITO DiFÍCIL de >> acontecer (tranquilamente vc pode precisar aplicar alterações/logs de horas >> atrás em caso de falha e muitas vezes o redo log online enche em poucos >> minutos), então eu nem conto com isso, ok ? >> >>> Na real a regra é : quem coloca o database em noarchivelog tá >> indicando que o database pode ser perdido (digamos, é um armazém de dados, >> que em tese pode ter os dados recuperados dos databases online), e QUANDO >> isso acontecer (não é SE, é QUANDO), ou se assumirá o ônus de trazer os >> dados dos databases online OU se recuperará o último backup e os dados daí >> pra frente são descartados.... >> >>> SE não tiver backup E não há de onde trazer os dados E está em >> modo noarchive, basicamente vc VAi ter perda de dados : nem mais, nem >> menos.... >> >>> >> >>> []s >> >>> >> >>> Chiappa >> >>> >> >>>OBS : >> >>> >> >>> a) estamos falando aqui de recuperação de crash/atualização de >> datafiles/prevenção de perda de dados : é Claro, se o banco está OK e vc só >> quer ter os dados como estavam nalgum ponto do passado, outros recursos de >> recuperação (como FLASHBACK QUERY) normalmente dependem de UNDO e não de >> redo log, então há chances disso ser possível >> >>> >> >>> b) outras opções de recuperação de uma falha voltando o database no >> tempo até antes da falha (como o FLASHBACK DATABASE, por exemplo) dependem >> de setup extra (FLASHBACK LOGs no caso) : Dificilmente isso é o caso de >> estar presente... >> >> >> > >> >> >> >> > > > -- > Atenciosamente > Erik da Silva Castilho > Bacharel Sistemas de Informação > Supervisor IT at Consórcio Nacional Recon > > >
