Boa tarde, Depende do tipo de backup que você faz.
Em um cold backup, termine o banco com immediate, não com abort (ou ao menos force um checkpoint e espere ele terminar)... o abort faz com que o banco execute o restore no startup e com nologging não há dados no redo para o restore. Em um hot backup (expdb/export,etc) não há problema, pois os blocos são lidos logicamente (datafiles, undo e buffer cache) e não fisicamente do disco, pegando as informações corretas via leitura consistente. Em um backup baseado em archive, você NÃO terá as informações dessas alterações, já que o archive é na verdade o redolog que encheu e com nologging as informações dos blocos de dados alterados não vão para o redolog... você conseguirá fazer o recover: os datafiles ficarão legiveis pelo oracle mas em nível de dados eles provavelmente ficarão inconsistentes, além da estrutura dos metadados e índices que ficarão incorretas de acordo com os dados da tabela. cya[]; Carlos E. Gorges <carlos.gor...@gmail.com> 2009/2/3 alexandre_brum <alexandre_b...@yahoo.com.br>: > Carlos > > Sim. Sei que irei perder esses dados. Mas no caso do datafile dessa > tablespace se corromper, como seria o processo de restore do backup a > fim de que eu possa novamente ter essa tablespace disponível? > > Obrigado. > > Att. > Alexandre Brum > > --- Em oracle_br@yahoogrupos.com.br, "Carlos E. Gorges" > <carlos.gor...@...> escreveu > >> >> Boa tarde, >> >> O nologging irá desligar parte da geração do redolog, incluindo os >> blocos de dados alterados no DML. Como esses dados ficarão em memória >> até ser descarregados para os datafiles em um checkpoint e não estão >> em redo (disco), em caso de crash na máquina/banco os dados em memória >> (SGA->Buffer cache) serão perdidos e consequentemente esses blocos >> alterados também serão perdidos. O resultado será um segmento em uma >> versão (SCN) anterior ou parcial... Note que se algum datafile seja >> corrompido, por bug ou problema no subsistema de I/O por exemplo, o >> log não vai adiantar nada de qualquer modo... >> >> Em resumo: não há recuperação :-) >> >> cya[]; >> Carlos E. Gorges <carlos.gor...@...> >> >> 2009/2/3 Alexandre Brum <alexandre_b...@...>: >> > Prezados >> > >> > Durante um processo de carga pretendo colocar a tablespace desse > usuário da >> > carga em no logging para agilizar a carga. Entretanto, tenho > dúvidas de como >> > seria a recuperação dessa tablespace, se por algum motivo, durante > a carga, >> > os datafiles dessa tablespace se corrompam. Como seria a > recuperação dessa >> > tablespace? >> > >> > Muito obrigado. >> > Fique com Deus. >> > Um grande abraço. >> > >> > Att. >> > Alexandre Brum
