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
