Então, na verdade a limitação aí é da linguagem PL/SQL, ela só pode manipular/retornar/aceitar como entrada/saída 32767 bytes, então se vc quiser (por exemplo) ler totalmente um LOB, vc escreve um LOOP aonde vc lê e guarda numa variável os primeiros 32767 bytes e faz o processamento que quiser, depois lê os próximos 32767 bytes e processa, assim vai... Vc pode pensar no LOB como um "arquivo" que vc abre, lê uma "linha"/pedaço, processa, continua lendo e no fim vc fecha, é tipo assim, e o banco Oracle te dá uma package DBMS_LOB que justamente faz isso, são DBMS_LOB.OPEn, READ, WRITE, CLOSE... Veja no manual de programadores LOB e em http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1533006062995 , http://www.akadia.com/services/read_file_with_dbms_lob.html e http://www.psoug.org/reference/dbms_lob.html que vc acha uns exemplos, sintaxes, modo de usar....
[]s Chiappa --- Em oracle_br@yahoogrupos.com.br, Rogério Falconi <rogerfal...@...> escreveu > > 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...@...> 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" <jlchiappa@> 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] >
