jlchiappa bom dia... Estou com um problema de limitação de tamanho em manipulação de campos clob.
Quando uso o dbms_lob.substr, a limitação dos 32767. Vc sabe me dizer como posso romper isso? O script funciona até os 32767, e depois para por estou de buffer. Blob resolveria isso? e como manipulo fazendo contatenação e etc? é o mesmo jeito? Obrigado pela sua pasciência e presteza... Rogério Em 05/02/09, jlchiappa <jlchia...@yahoo.com.br> escreveu: > > Relendo a resposta e pensando um pouco, acho que não ficou claro o que > eu quis dizer com a volta coordenada de todo mundo no horário > imediatamente anterior à operação NOLOG se houver operações LOGGING > concorrentes, deixem-me detalhar um pouco - primeiro, o conceito de > NOLOG é : uma operação que está INTRODUZINDO dados novos e é > direcionada a usar blocos ACIMA dos últimos já usados, blocos 100% > garantidamente virgens portanto. Já que é assim, se der um crash no > banco nessa situação nós temos 100% de certeza de que ** NÃO ** > existem outras transações querendo mexer com outros registros nesses > blocos, os blocos que estão sofrendo operação NOLOG estão > garantidamente VAZIOS no momento (é por isso inclusive que é > fisicamente IMPOSSÍVEL um UPDATE em modo NOLOG)..... Sendo assim, o > que aconteceria se vc durante ou imediatamente após uma operação de > NOLOG aconteceram e foram comitadas operações LOGGING normais e nesse > cenário vc pedisse volta de backup dos datafiles e aplicasse os logs > todos até o instante anterior à falha, vc recuperaria ** TOTALMENTE ** > as operações LOGGING (pois afinal de contas elas ocorreram em blocos > que GERARM redo log normal!), só os blocos que sofreram a operação > NOLOG é que não seriam recuperados... A questão é que muitas vezes há > algum tipo de relacionamento lógico entre o segmento que sofreu NOLOG > e o segmento LOGGING, e com o restore completo vc teria dados do > segmento LOGGING sem o correspondente no segmento NOLOGGING, > logicamente falando PODE SER que nesse cenário bastasse re-executar a > operação NOLOGGING mas pode ser que não, isso depende da sua > necessidade, é por isso que eu acenei com a possibilidade de restaurar > só até o instante antes da operação NOLOG e re-executar tanto a > operação NOLOG quanto a LOGGING.... > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br <oracle_br%40yahoogrupos.com.br>, > "jlchiappa" <jlchia...@...> escreveu > > > > 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_br@yahoogrupos.com.br <oracle_br%40yahoogrupos.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_br@yahoogrupos.com.br <oracle_br%40yahoogrupos.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.maisbuscados.yahoo.com > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas]
