OK, algumas informações a mais que podem te ajudar : 1) se essa carga hoje é feita via PL/SQL, que lê uma linha, insere uma linha, lê uma linha, insere, aí pense ** CARINHOSAMENTE ** na hipótese de ter um único comando SQL INSERT /*+ APPEND */ , o NOLOG só funciona efetivamente com SQL no formato INSERT /*+APPEND */ into tabela (select) , um insert linha-alinha não vai se beneficiar
2) para tabela que tenha índices é FORTEMENTE recomendado vc desabilitar os índices durante o processo de carga para máximo benefício, pois índices ativos SEMPRE geram LOG e não é pouco, é muito e como eu disse nas msgs, não deixe de analisar direitinho o modo de operação no banco, se há concorrências durante a carga, quais rotinas usam/alteram esses dados carregados e de que modo, deixe o DBA e os outros desenvolvedores ABSOLUTAMENTE cientes do que vc quer fazer... Pincipalmente o DBA, ele (por exemplo) pode agendar um backup online só dos arquivos da tablespace que contém o segmento NOLOG imediatamente após a operação NOLOG, planejamento do tipo é CRÍTICO []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Alexandre Brum <alexandre_b...@...> escreveu > > Grande Chiappa > > Muito obrigado pelos esclarecimentos. Tenho um processo de carga que está demorando um tempo considerável. E refleti na hipótese de não gerar logs dessa carga, a fim de agilizar. Mas havia ficado com muito receio, para a situação de crash nesses datafiles e haver muita demora para disponibilizar novamente o BD para uso. A explanação foi muito importante, pois até então, pensava que colocando a tablespace como no logging fosse suficiente. E tudo isso servirá de insumo para eu abordar com o cliente e demais interessados. > > > Obrigado. > > Fique com Deus. > Um grande abraço. > > Att. > Alexandre Brum > > > > > ________________________________ > De: jlchiappa <jlchia...@...> > Para: oracle_br@yahoogrupos.com.br > Enviadas: Quinta-feira, 5 de Fevereiro de 2009 11:58:15 > Assunto: Res: Res: [oracle_br] Re: Recuperação de Tablespace em no logging > > > 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...@yahoogrup os.com.br, Alexandre Brum > <alexandre_brum@ ...> 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 <jlchiappa@ ..> > > Para: oracle...@yahoogrup os.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.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] >
