Aqui tem um conceito importantérrimo que eu passei no e-mail original e vc não captou pelo jeito, vou o repetir : o atributo de NOLOG de uma tablespace **** NÂO SERVE PARA NADA **** além de servir como default se vc não especificar nada na hora de vc criar a tabela dentro da tablespace, o que vale para uma operação é o atributo de log/nolog DA TABELA, rigorosamente ****** NÂO EXISTE ****** o conceito de tablespace em modo nologging, é A TABELA que vai estar ou não com atributo nolog, tá bem ?? Esse atributo pode ter sido herdado na tablespace na hora do CREATE TABLE, mas em si o atributo da tablespace NÂO SERVE PRA NADA MAIS, Captado ? Então a sua frase "Pois tanto os segmentos quanto a tablespace estarão em nologging" não faz sentido algum , ok ? O que vai acontecer portanto é que apenas os blocos desses segmentos/tabelas que estão marcados como NOLOG ativo (OU porque vc assim especificou num CREATE ou ALTER TABLE, OU porque a tablespace assim estava definida e na hora de criar a tabela dentro da tablespace vc não disse nada, ele assumiu/herdou o atributo da tablespace).... ESQUEÇA a idéia de "tablespace em modo nolog" isso NÂO EXISTE, é segmento a segmento que vc indica para estar em nolog, ok ?
Quanto ao backup : veja, SE vc estiver em modo noarchive nesse banco, evidentemente não tem conversa, é o último backup cold COMPLETO que vc tem que voltar, não existe a figura do archived log nesse cenário, vc NÂO CONSEGUE recuperar uma tablespace só nem um datafile só, o banco inteiro será recuperado, volta à posição do backup, VAI PERDER todas as transações feitas após esse backup, sejam em modo log, seja em nolog, não importa. Já se o banco está em archived log mode e vc teve um crash com perda de um datafile qquer, vc PODE optar voltar o último backup DESSE DATAFILE (certamente num banco em archive mode isso deve ser um backup hot), mas aí o banco vai (corretamente) perceber que esse arquivo está defasado no tempo em relação aos demais, ele vai portanto pedir a aplicação dos archived logs, que serão aplicados na ordem nesse datafile deixando-o sincronizado - ocorre que como eu disse em msg anterior as operações NOLOG foram feitas em blocos virgens, com certeza ZERADOS/vazios nesse arquivo que vc voltou, e não foi gerado log, então essa operação NOLOG vc ** perdeu **, sem possibilidade de recuperação. O que fazer nesse caso ? Aí é o que eu falei, o normal é que não haja nenhum tipo de dependência lógica entre os dados entrados via NOLOG e os dados processados após, aí é muito simples, após recuperado o datafile (pois vc *** VAI TER SIM *** os logs gerados pelas operações log), vc simplesmente re-executa a carga e boa, tá tudo bem. INCLUSIVE, há diversos autores que defendem que nesse cenário de archived mode IMEDIATEMENTE após a operação nolog vc faça um backup, se for o caso apenas dos datafiles que contém o segmento que operou em NOLOG, nesse caso em caso de crash vc voltaria esses datafiles, voltaria o(s) datafile(s) que crasharam e recuperaria via aplicação do log normalmente.... Esse é o caso NORMAL, COMUM e ROTINEIRO, ok ? A sugestão de voltar o banco inteiro pra posição imediatamente anterior à operação de nolog só seria necessária em exceções, quando há alguma dependência lógica contra o objeto nolog por parte dos objetos log que o simples reprocesso da carga não cobre, é algo excepcional... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Alexandre Brum <alexandre_b...@...> escreveu > > Chiappa > > Estou pretendendo deixar a tablespace da carga sempre em nologging. Sendo assim, não irá gerar log, pois conforme teu e-mail anterior, irei criar os segmentos também como nologging. Não entedi direito com a mensagem que você disse: "MAS se houver em caso de crash vc voltará um backup anterior dos datafiles dessa tablespace e irá aplicar os logs até o momento imediatamente anterior ao início NOLOG, que é o que vc tem." Eu não terei esses logs. Pois tanto os segmentos quanto a tablespace estarão em nologging. > > > Fique com Deus. > Um grande abraço. > > Att. > Alexandre Brum > > > > > ________________________________ > De: jlchiappa <jlchia...@...> > Para: oracle_br@yahoogrupos.com.br > Enviadas: Quarta-feira, 4 de Fevereiro de 2009 22:32:21 > Assunto: Res: [oracle_br] Re: Recuperação de Tablespace em no logging > > > Só complementando : como eu disse, normalmente operações NOLOG ocorrem > em período de carga, então via de regra não há outras transações > gravando/alterando na mesma tablespace, normalmente não há > considerações necessárias, MAS se houver em caso de crash vc voltará > um backup anterior dos datafiles dessa tablespace e irá aplicar os > logs até o momento imediatamente anterior ao início NOLOG, que é o que > vc tem - ou seja, na prática o banco VOLTA à situação que estava nessa > ocasião, as transações outras que estavam ocorrendo em paralelo à > operação NOLOG serão perdidas, também terão que ser > re-executadas. ..São coisas do tipo que vc TEM que estabelecer/ combinar > muito muito direitinho com o DBA e com os OUTROS desenvolvedores , ok ? > > []s > > Chiappa > > > > Colegas, vamos botar uns detalhes aí nessa thread : Brum, primeiro de > > tudo se vc pedir um ALTER TABLESPACE nn NOLOGGING (ou a criar como > > NOLOGGING), o que vc conseguiu nesse momento com isso foi NADA, ZERO, > > NIENTE, ** COISA ALGUMA ** - somente quando vc ** CRIAR ** e/ou mover > > segmentos/tabelas pra dentro dessa tablespace sem especificar cláusula > > de log é que esse atributo da tablespace vai ser assumido pelo > > segmento/tabela, e isso é CRUCIAL, pois operações NOLOGGING são ** > > sempre ** a nível de tabela/segmento, esse atributo NOLOG da > > tablespace serve apenas como default quando vc cria a > > tabela/segmento. ..O manual mesmo já nos diz : > > > > "When an existing tablespace logging attribute is changed by an ALTER > > TABLESPACE statement, all tables, indexes, and partitions created > > after the statement will have the new default logging attribute (which > > you can still subsequently override). The logging attribute of > > existing objects is not changed." > > > > Continuando, para que uma operação não gere log, *** absolutamente não > > basta *** que o atributo de NOLOG esteja ativo, há uma SEGUNDA > > exigência , é EXIGIDO que a operação esteja na lista de operações que > > são permitidas nesse modo : UPDATE por exemplo não é, e já cansei de > > ver "expertos" recomendarem ou debaterem contra a conveniência de > > UPDATE em tabelas nolog, o que não faz o MENOR SENTIDO... Ok ? Isto > > deve ficar escrupulosamente claro, o fato de vc ativar o atributo de > > NOLOG numa tabela por si *** NÂO QUER DIZER NADA **, não fará COISA > > ALGUMA se a operação não permite modo nolog, apenas umas poucas > > operações (como INSERT /*+ APPEND */ , CREATE TABLE, etc) permitem... > > Há uma TERCEIRA condição, que é a de que o modo NOLOG de operação > > SEJA permitido nesse banco, vc pode ativar o atributo FORCE LOGGING no > > seu banco, aí esse cara tem precedência sobre os anteriores, num banco > > com FORCELOGGING vc pode ativar o atributo num dado segmento e tentar > > uma operação que normalmente permite nolog que o log será SIM > > gerado...A Oracle criou isso para os casos em que há replicação > > lógica/standby, streams ou coisas do tipo, aonde o log é exigido > > sempre para que tais features funcionem a contento. > > > > Muito bem, agora sobre o backup : realmente, se vc tem um dado > > segmento com atributo NOLOG e o banco não está em FORCELOGGING, se vc > > iniciar uma operação que permita NOLOG às (digamos) 09:00h , não será > > gerado log desse ponto em diante para esse segmento, então a coisa é > > assim : necessariamente esse recurso é usado para cargas em ambiente > > DW, á noite, onde o segmento em questão ** NÃO ** está sendo usado por > > ninguém , NÂO HÁ absolutamente outras transações usando a tal > > tablespace ativamente (só consultas), então SE durante a operação, ou > > mesmo imediatamente após a operação vc tiver um crash, vc volta o > > backup anterior do(s) datafile(s) (que óbvio, está com SCN ** anterior > > ** à operação) e aplica os logs ** até ** às 09:00h, que vc tem,vc > > perde só a operação NOLOG, yes ??? Simples... O que vc faz também é , > > imediatamente após a operação NOLOG, é fazer um novo backup ** DO(s) > > DATAFILE(S) que sofreram a operação, aí sim com esse backup se depois > > dele vc tiver um crash é ELE que vc vai recuperar, cfrme citado na > > thread não há log gerados na operação, então NUNCA vc conseguirá fazer > > um recover com os logs apenas E o datafile do backup anterior está > > antigo, vc TEM que ter backup dos datafiles APÓS A OPERAÇÃO, mesmo... > > O manual de Backup nos diz textualmente isso : > > > > "The presence of NOLOGGING operations must be taken into account when > > devising the backup and recovery strategy. When a database relies on > > NOLOGGING operations, the conventional recovery strategy (of > > recovering from the latest tape backup and applying the archived > > logfiles) is no longer applicable because the log files cannot recover > > the NOLOGGING operation." > > > > É claro, isso ainda tem que ser joeirado com a sua estratégia de uso > > : por exemplo, num cliente anterior (DW) o particionamento era por dia > > do mês, e cada partição ficava numa tablespace diferente, assim era > > feita a carga NOLOG na partição do dia de hoje, que era uma tablespace > > só pra ela, SE eu tivesse problema eu simplesmente ** dropava ** a > > tablespace, recriava VAZIA e re-executava o procedimento de carga do > > dia... > > > > []s > > > > Chiappa > > > > --- Em oracle...@yahoogrup os.com.br, Alexandre Brum > > <alexandre_brum@ > escreveu > > > > > > Obrigado Carlos > > > > > > Com relação aos dados não haverá problema, pois tenho como reiniciar > > a carga dos dados. O meu receio maior é quanto a recuperar o datafile > > dessa tablespace em no logging. Se o BD por exemplo, iria reconhecer > > um datafile de um cold backup anterior, mesmo com os datafiles das > > outras tablespaces, controlfile estarem numa nova versão. > > > > > > > > > Fique com Deus. > > > Um grande abraço. > > > > > > Att. > > > Alexandre Brum > > > > > > > > > > > > > > > ____________ _________ _________ __ > > > De: Carlos E. Gorges <carlos.gorges@ > > > > Para: oracle...@yahoogrup os.com.br > > > Enviadas: Terça-feira, 3 de Fevereiro de 2009 16:59:07 > > > Assunto: Re: [oracle_br] Re: Recuperação de Tablespace em no logging > > > > > > > > > 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.gorges@ gmail.com> > > > > > > 2009/2/3 alexandre_brum <alexandre_brum@ 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...@yahoogrup os.com.br, "Carlos E. Gorges" > > > > <carlos.gorges@ ...> 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.gorges@ ...> > > > >> > > > >> 2009/2/3 Alexandre Brum <alexandre_brum@ ...>: > > > >> > 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 > > > > > > > > > > > > Veja quais são os assuntos do momento no Yahoo! +Buscados > > > http://br.maisbusca dos.yahoo. com > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > Veja quais são os assuntos do momento no Yahoo! +Buscados > http://br.maisbuscados.yahoo.com > > [As partes desta mensagem que não continham texto foram removidas] >
