okdoc : olhando os seus dados de espaço livre, tá Claro que, já que o teu primeiro extent livre começa no bloco 1377, então tá Claro que vc TEM DADOS de algum tipo (índices, tabelas, o que for - vc diz que são índices, okdoc) dos blocos 1 a 1376, , depois vc tem esse pedaço pedaço livre, depois MAIS um pedação livre no bloco 1407, aí vai : o seu datafile está mais ou menos assim (supondo que "." são blocos livres e "x" são blocos com dados :
xxxxxxxxxxxxxxxxxxx..............xxxxxxxxxx...........xxxxxxxxx se o teu último 'x', teu último bloco ocupado é, digamos, o bloco 10000 , e nessa tablespace vc tem blocos de 8KB, vc só poderá fazer shrink para 10000 * 8192 = 81920000 , ou seja, cerca de 81 mB, INDEPENDENTE DE quantos mB em dados vc tem nesse datafile, okdoc ??? É basicamente o cálculo que o Autor faz no script mostrado em http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:153612348067 - tem uns detalhezitos a mais conceituais, mas a Idéia é essa.... Muito bem : antes de falar sobre o que vc pode fazer, há duas coisas que eu desejo deixar ESCRUPULOSAMENTE CLARAS : a) uma situação do tipo ABSOLUTAMENTE, COMPLETAMENTE, TOTALMENTE NÃO INTERFERE NA PERFORMANCE para recuperação normal dos dados, ok ?? Repito, *** Não Interfere *** !! A razão é porque o RDBMS Oracle NUNCA, em TEMPO ALGUM, vai varrer o datafile do início ao fim para buscar um dado, ele é um POUQUINHO mais esperto que isso : se o dado está no bloco, sei lá, 9000, se o acesso é via índice ela faz uma conta tipo 9000 * tamanho do bloco e faz um FSEEK (ele "pula" a 'cabeça de leitura' do disco para esse ponto) e lê esse bloco que precisa, ou se o acesso é via full table scan ele localiza na DBA_EXTENTS o bloco inicial do extent aonde reside o bloco 9000 e faz um FSEEK lendo a qtdade de blocos no extent.... Já que esse cenário NÂO INTERFERE em performance, eu REALMENTE hesito em chamar isso de "FRAGMENTAÇÃO", propriamente dita... b) antes de vc fazer qualquer coisa, TENHA EM MENTE que esse espaço residente em extents vazios VAI SER ** naturalmente e automaticamente ** Ocupado pelos próximos INSERTs/UPDATEs que ocorrerem nos índices (via DML nas tabelas indexadas), ou nas tabelas mesmo que usem essa tablespace/datafile (com a exceção de eventuais INSERTs em append-mode) : sendo assim, PLZ VERIFIQUE se REALMENTE não vai haver daqui a pouco tempo INSERTs/UPDATEs que possam ocupar esse espaço, antes de vc sair fazendo shrink/remove/whatever nesse datafile.... Senão, vc fica naquela situação do cachorro correndo atrás do próprio rabo , ie : com algum esforço vc libera o espaço no datafile via shrink/move/rebuild do datafile, aí amanhã o depois os INSERTs/UPDATEs na(sa) tabela(s) que usam essa tablespace vêm, aí toca vc a CRESCER de novo o datafile, sendo portanto um trabalho SIMPLESMENTE PERDIDO, INÚTIL e ASNINO tudo que vc fez antes, sim ????? ===>>> Então : SE realmente não é Performance a sua Preocupação, E REALMENTE vc tem razoável certeza que Não Mais ocorrerão INSERTs/UPDATEs nas tabelas que usam e tablespace, aí SIM vc pode proceder com alguma coisa para mudar a alocação e permitir o shrink nesse datafile : na versão 9ir2 que é a sua, iirc não existe a possibilidade de COALESCE ou similares na tablespace (CONFIRA na doc, mas iirc é isso) , então é mesmo MOVER para outra tablespace os índices (via REBUILD), já que vc diz que só tem índice.... Eu Não Lembro de cabeça se na 9ir2 ele já deixava vc fazer o ALTER INDEX nnn TABLESPACE novatablespace REBUILD em modo ONLINE ou se vc terá que fazer isso na OFFLINE, na próxima janela de manutenção que vc tiver : cheque aí... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "Ednilson Silva" <ednilson.silva@...> escreveu > > Chiappa, > > > > Seria ai mesmo que estou querendo chegar. > > > > No primeiro SELECT trouxe 240 linhas, é tudo INDEX que tenho nesta > tablespace (ABMX). > > Segue o resultado do segundo SELECT. > > > > SQL> SELECT FILE_ID, BLOCK_ID, BYTES, BLOCKS FROM DBA_FREE_SPACE WHERE > TABLESPACE_NAME='ABMX' ORDER BY FILE_ID,BLOCK_ID; > > FILE_ID BLOCK_ID BYTES BLOCKS > > ---------- ---------- ---------- ---------- > > 11 1377 98304 12 > > 11 1407 7348224 897 > > 11 2311 999424 122 > > > > Estou pensando desfragmentar essa tablespace. > > > > Grato, > > > > Ednilson Silva > > > > De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em > nome de J. Laurindo Chiappa > Enviada em: segunda-feira, 25 de fevereiro de 2013 16:25 > Para: oracle_br@yahoogrupos.com.br > Assunto: Re: RES: [oracle_br] ORA-03297: file contains used data beyond > requested RESIZE value > > > > > > Colega,pmfji mas o seu cenário parece mesmo ser EXATAMENTE o que eu disse, > extent(s) alocados depois de outros em branco impedindo o resize... Essa > consulta na DBA_DATA_FILE nos mostra o tamanho do arquivo, OK, cool, mas o > que precisamos saber é ** INTERNAMENTE ** como esse cara tá sendo usado, PLZ > como eu disse consulte a DBA_EXTENTS, pode ser algo + ou - : > > SELECT OWNER, SEGMENT_TYPE, SEGMENT_NAME, PARTITION_NAME, FILE_ID, > EXTENT_ID, BLOCK_ID, BYTES, BLOCKS > FROM DBA_EXTENTS WHERE TABLESPACE_NAME='NOMEDATABLESPACEEMQUESTÂO' ORDER BY > FILE_ID, EXTENT_ID, BLOCK_ID; > > E complementando com um : > > SELECT FILE_ID, BLOCK_ID, BYTES, BLOCKS FROM DBA_FREE_SPACE WHERE > TABLESPACE_NAME='NOMEDATABLESPACEEMQUESTÂO' ORDER BY FILE_ID, EXTENT_ID, > BLOCK_ID; > > aí vc comprova a minha Suposição... > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> > , "Ednilson Silva" escreveu > > > > Milton, > > Voce tem razão, desculpem minha desatenção. > > > > SQL> select FILE_NAME,FILE_ID,TABLESPACE_NAME,BYTES from DBA_DATA_FILES > > where TABLESPACE_NAME = 'ABMX'; > > > > FILE_NAME FILE_ID TABLESPACE_NAME > > BYTES > > ------------------------------- ---------- ------------------------------ > > ---------- > > /d12/oradata/app/abmx01.dbf 11 ABMX > > 19922944 > > > > Grato, > > > > Ednilson Silva > > > > > > > > -----Mensagem original----- > > De: oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> > [mailto:oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> > ] Em > > nome de Milton Bastos Henriquis Jr. > > Enviada em: segunda-feira, 25 de fevereiro de 2013 15:36 > > Para: oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> > > > Assunto: Re: [oracle_br] ORA-03297: file contains used data beyond > requested > > RESIZE value > > > > Vc está tentando deixar um datafile com 18 MB, sendo que este arquivo já > tem > > mais do que isso de dados atualmente... não tem muito segredo, não dá pra > > fazer milagre! > > > > > > > > > > On Mon, Feb 25, 2013 at 3:28 PM, Ednilson Silva > > wrote: > > > > > ** > > > > > > > > > Pessoal, > > > > > > Estou tentando fazer um resize em alguns datafile, mas esta aparecendo > > > o erro ORA03297 > > > > > > SQL> alter database datafile '/d12/oradata/app/abmx01.dbf' resize 18m; > > > > > > alter database datafile '/d12/oradata/app/abmx01.dbf' resize 18m > > > > > > ORA-03297: file contains used data beyond requested RESIZE value > > > > > > Oracle Database 9i Release 9.2.0.5 > > > > > > HP-UX B.11.31 U ia64 > > > > > > Alguém poderia dar uma ajuda? > > > > > > Grato, > > > > > > Ednilson Silva > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > ------------------------------------ > > > > ---------------------------------------------------------- > > ---------------------------------------------- > > >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de > inteira > > responsabilidade de seus remetentes. > > Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ > > ---------------------------------------------------------- > > ---------------------------------------------- > > >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » > > >Procedure » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO > > >ESPAÇO! VISITE: http://www.oraclebr.com.br/ > > ---------------------------------------------------------- > > -------------------------------------------- Links do Yahoo! Grupos > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] >
