É bem simples : sim, os datafiles todos são armazenados no SO, ** mas ** o bd Oracle se 'auto-controla' também : assim nas tabelas internas do banco (que a gente pode consultar pelas views do dicionário DBA_TABLES, DBA_SEGMENTS, DBA_TABLESPACES, DBA_EXTENTS, etc) fica marcado que o datafile xyz vai do bloco 1 ao 100 (digamos), que a tabela tal fica dentro do datafile xyz nos blocos de 10 a 40 (digamos)... O bug é interno, ele quebra exatamente esses registros internos, assim no SO (digamos) o datafile vai do bloco 1 ao 100, mas no dicionário de dados está erradamente marcado que ele vai do 1 ao 99, ou do 1 ao 101, sei lá, então o DBV como só vai no SO corretamente lê os blocos de 1 a 100, já quando o banco tenta acessar os datafiles/objs internamente tá marcado que bloco a mais ou a menos, dá pau... Blz, tá mais claro ? É uma corrupção interna, dos 'registros internos' do banco... Fosse um banco de produção vc abriria Chamado e descobriria exatamente onde está o prob, qual registro de qual tabela interna está apontando pra menos ou mais blocos do que devia, mas como é banco Dev e sem Suporte fica difícil vc persistir na análise, então acho q vc vai só mesmo fazer o work-around de recriar a tablespace noutro lugar , mover os objs pra nova TS e dropar a antiga, bypassando/retirando das tabs internas do banco os regs corruptos : Claro que depois disso feito vc VAI usar as tools que falei, ie, DBV offline, dbv online, export full, SELECTs que leiam as tabs todas, que scaneiem s índices todos, VALIDATE dos índices, os scripts que a Oracle dá, etc, pra ter certeza que esse banco agora tá integro logicamente.... Pra fazer o move pras novas tablespaces vc pode usar o ALTER TABLE ... MOVE / ALTER INDEX REBUILD mesmo : fosse um banco prod, aonde não pode haver down-time ou este tem que ser mínimo, poderia se apelar pras packages de REDEF, mas pra banco DEV não acho que valha a pena...
[]s Chiappa --- Em oracle_br@yahoogrupos.com.br, "candiurudba" <candiuru...@...> escreveu > > Chiappa... > > Não entendi muito bem esta questão de datafile ir alem dos limtes de SO pq > teoricamente, todos os objetos criados são armazenados dentro do SO...dentro > de seus limites fisicos / logicos...não é isso ? De qualquer forma vou dar > uma olhada nos notes do metalink... > > Uma outra questão...vc tem alguma sugestão de uma melhor maneira de migra o > que esta nesta tablespace para alguma outra ? > > > > --- Em oracle_br@yahoogrupos.com.br, José Laurindo <jlchiappa@> escreveu > > > > Na verdade, como as notas dizem, os bugs envolvidos permitem ou criar um > > datafile além dos limites do SO, ficando com tamanho inválido, aí vc tem no > > dicionário um pointer apontando pro bloco x mas na verdade no SO o datafile > > acaba em x-y : num caso desses o DBV (que lê os blocos a partir do SO, > > tanto que pode ser executado com db offline) pára a leitura no bloco x-y, > > não chega até o bloco x corrupto.... Dê uma checada nos notas sobre > > Corrupção no metalink que a Oracle fala exatamente isso, ie, que o DBv faz > > verificação física, dos DATAFILEs apenas, pra vc encontrar corrupção no > > dicionário é usar export e/ou full table scans/fast indexes scans, esses > > sim lêem a informação extent por extent, baseado no dicionário... É um > > conjunto , no set toolkit pra healtcheck vc TEM que fazer um dbv online, um > > dbv offline, um export full, FTSs e FFISs (via SELECTs adequadamente > > preparados), consultar status na DBA_OBJECTS dos objetos do SYS, rodar os > > scripts quea Oracle disponibiliza, check frequente do alert e dos trace > > files gerados, é isso aí. > > > > []s > > > > Chiappa > > > > --- Em oracle_br@yahoogrupos.com.br, "candiurudba" <candiurudba@> escreveu > > > > > > Boa tarde colegas... > > > > > > GRande Chiappa.. > > > > > > Seguinte, após ler aqueles últimos posts la do metalink, bem observados > > > pelo chiappa, decide partir para uma investigação doq ue estava realmente > > > acontecendo e provavelmente existe sim um datafile corrompido...uma > > > tablespaces minha... > > > > > > > > > Mas eis a questão, o codigo de erro informa que o problema possivelmente > > > é na tablespace TSTESTE ([kcfrbd_3], [21]...onde segundo o suporte da > > > Oracle esta segunda casa representa o datafile...) > > > > > > Executei o DBV neste datafile e nada..não me mostrou erro algum. Entao > > > fiz a importação de algumas tabelas para este tablespace e toma-lhe erro > > > ORA-600. > > > > > > Tentei fazer a criação de uma tabela simples, apontando para esta > > > tablespace e toma-lhe ORA-600, alterei a criação da tabela para um outra > > > tablespace e funcionou bunito... > > > > > > Mas minha duvida segue...se realmente trata-se de corrompimento de um > > > datafile (e acredito realmente que seja) pq o DBV não exibiu ? Será que o > > > nivel de Bad block seja no SO e desta forma ele não conseguiria encontrar > > > o problema ? > > > > > > Alguem teria alguma sugestão para realizar a migração dos dados contidos > > > nesta tablespace para uma nova ? e Posteriormente a migração dos dados > > > para a mesma (ja recriada) ? > > > > > > Pensei em fazer algo do tipo: ALTER TABLE OWNER.TABLE_NAME MOVE > > > TABLESPACE TABLESPACE_DESTINO mas são mais de 500 tabelas e nem contei > > > ainda os indices... > > > > > > > > > > > > --- Em oracle_br@yahoogrupos.com.br, José Laurindo <jlchiappa@> escreveu > > > > > > > > Nada estranho : cfrme as notas, essa issue parece ser bug referente à > > > > datafile corrompido por tamanho inválido/transport tablespace com > > > > bitmap, certamente esse schema 'grande' só que deve estar tentando usar > > > > o(s) datafile(s) corrupto(s)... > > > > > > > > []s > > > > > > > > Chiappa > > > > > > > > --- Em oracle_br@yahoogrupos.com.br, "candiurudba" <candiurudba@> > > > > escreveu > > > > > > > > > > Grande Chiappa.. > > > > > > > > > > Realmente estava pesquisando errado... > > > > > > > > > > Estou trabalhando com o Banco Stardard 10.2.0.4 e um CentOS > > > > > 2.6.18-164.6.1.el5 #1 SMP Tue Nov 3 16:12:36 EST 2009 x86_64 x86_64 > > > > > x86_64 GNU/Linux.. > > > > > > > > > > Irei pesquisar novamente la no Metalink... > > > > > > > > > > O que é estranho é que para outro esquema eu consegui realizar a > > > > > importação sem problemas mas somente para este, que é grande não > > > > > consegui... > > > > > > > > > > > > > > > > > > > > --- Em oracle_br@yahoogrupos.com.br, José Laurindo <jlchiappa@> > > > > > escreveu > > > > > > > > > > > > Dia... Colega, se vc não achou nada no metalink pode-se por > > > > > > premissa assumir que vc pesquisou de modo Completamente, > > > > > > totalmente, ** absolutamente ** ERRADO : até há casos onde isso > > > > > > acontece, mas é Muito raro... O caso deve ter sido o seguinte : não > > > > > > sei se vc sabe, mas errors ORA-600 seguem um padrão, o primeiro > > > > > > argumento é o 'módulo', o 'componente'do banco aonde deu o bug, os > > > > > > demais são detalhes da sua máquina, como posição da memória se foi > > > > > > bug de mem, detalhes do datafile se foi bug de file, etc - eu > > > > > > IMAGINO que vc deve ter , ** Erradamente **, pesquisado por > > > > > > ORA-00600: internal error code, arguments: [kcfrbd_3], [21], > > > > > > [3047433], [1], > > > > > > [3047432], [3047432], [], [], ** LOGICAMENTE ** que é minúscula a > > > > > > chance de vc achar probs com os MESMOS números de datafiles/etc que > > > > > > os seus, né não ? Pesquisando rapidamente no metalink por > > > > > > "ORA-00600 [kcfrbd_3]" achei as notas 284565.1, 146580.1, 601798.1, > > > > > > 7251049.8 e 3219491.8, veja lá... > > > > > > Outro ponto, errors ORA-600 tem uma pesquisa ** Especial ** só pra > > > > > > eles no metalink,é o Error Lookup em n ORA-600 no Doc ID 153788.1 , > > > > > > mas PRA VARIAR não o pude usar porque vc PRA VARIAR NÃO DIZ a > > > > > > versão exata (com 4 dígitos) do banco e nem do SO - use-a e veja o > > > > > > que vc vai ver ... > > > > > > > > > > > > []s > > > > > > > > > > > > Chiappa > > > > > > > > > > > > > > > > > > --- Em oracle_br@yahoogrupos.com.br, "candiurudba" <candiurudba@> > > > > > > escreveu > > > > > > > > > > > > > > Bom dia Colegas, > > > > > > > > > > > > > > Estou com um problemão relacionado a importação dia datapump... > > > > > > > > > > > > > > Alguns esquemas menores consigo exportar sem problema algum mas, > > > > > > > quando tento exportar os meus maiores, tenho os seguintes erros: > > > > > > > > > > > > > > ORA-31693: Table data object "XXX"."XXX" failed to load/unload > > > > > > > and is being skipped due to error: > > > > > > > ORA-02354: error in exporting/importing data > > > > > > > ORA-39776: fatal Direct Path API error loading table "XXX"."XXX" > > > > > > > ORA-00600: internal error code, arguments: [kcfrbd_3], [21], > > > > > > > [3047433], [1], [3047432], [3047432], [], [] > > > > > > > ORA-39014: One or more workers have prematurely exited. > > > > > > > ORA-39029: worker 1 with process name "DW01" prematurely > > > > > > > terminated > > > > > > > ORA-31672: Worker process DW01 died unexpectedly. > > > > > > > > > > > > > > Procurei no Metalink e não vi nada a respeito sobre este ORA 600 > > > > > > > e o pior é que este banco esta em um CentOS por ser um servidor > > > > > > > da equipe de desenvolvimento, ou seja, não tenho suporte para > > > > > > > ele... > > > > > > > > > > > > > > Alguem teria alguma ideia ? > > > > > > > > > > > > > > > > > > > > > > > > > > > >
