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... >> >> > >
