Bom, sendo camarada poderíamos considerar que na "fragmentação" eles
simplesmente estejam usando mal o termo "fragmentação", e que eles
estejam se referindo na verdade ao espaço INUSÁVEL se vc se esuqcer de
adicionar os 64 Kb de bitmap e/ou usar tamanho não-múltiplos do extent
size pros datafiles , tipo :


SQL> create tablespace TS_T datafile '/oradata/ts_t_01.dbf' size
10485760 extent management local uniform size 1M nologging;

Tablespace criado.

SQL> !ls -lt /oradata/ts_t_01.dbf
-rw-rw----   1 oracle     dba        10493952 May 12
12:56 /oradata/ts_t_01.dbf


SQL>  select 10493952 - 10485760 from dual;

10493952-10485760
-----------------
             8192

meu db é de 8Kb, a diferença física é o bloco inicial de controle.
Vamos ver porém efetivamente QUANTO obtive :


SQL> select bytes, user_bytes, user_bytes + 65536 from dba_data_files
where tablespace_name='TS_T';

     BYTES USER_BYTES USER_BYTES+65536
---------- ---------- ----------------
  10485760    9437184          9502720


SQL> select file_id, block_id, bytes, blocks from dba_free_space where
tablespace_name='TS_T';

   FILE_ID   BLOCK_ID      BYTES     BLOCKS
---------- ---------- ---------- ----------
       313          9    9437184       1152


==> ou seja, mesmo levando em conta os 64 Kb do bitmap, ainda há um gap
entre o ocupado em disco e o efetivamente livre, mas isso *** NÃO É ***
fragmentação, é apenas asnice de se pedir  pra criar em disco mais do
que se vai usar, esse gap é um espaço que NUNCA será usado, e
FRAGMENTAÇÃO no bd Oracle é espaço que FOI alocado e depois mesmo livre
nunca mais poderá ser re-usado por questão de extents de tamanhos
diferentes. O correto DEVERIA ter sido :

/trafico/fco_adm>bc
10485760 + 65536
10551296

SQL>create tablespace TS_T2 datafile '/oradata/ts_t2_01.dbf' size
10551296 extent management local uniform size 1M nologging;

Tablespace criado.

SQL> !ls -lt /oradata/ts_t2_01.dbf

-rw-rw----   1 oracle     dba        10559488 May 12
13:10 /oradata/ts_t2_01.dbf

select bytes, user_bytes, user_bytes + 65536 from dba_data_files where
tablespace_name='TS_T2';

SQL>
     BYTES USER_BYTES USER_BYTES+65536
---------- ---------- ----------------
  10551296   10485760         10551296

==> ZERO de gap...

SQL> select file_id, block_id, bytes, blocks from dba_free_space where
tablespace_name='TS_T2';
   FILE_ID   BLOCK_ID      BYTES     BLOCKS
---------- ---------- ---------- ----------
       314          9   10485760       1280

==> obtive 10 Mb livres tal como queria...

Já a segunda afirmação, de que um item intríseco ao bloco como é a
migração de linhas possa ser relacionado com tamanho do datafile, foge
COMPLETAMENTE à minha capacidade de interpretação, pra mim isso é dada,
é op, é maluquice, se eu fosse cliente desses caras de imediato
colocaria ese pessoal sob alta suspeita. Classifico um relatório desses
de tragicômico, seria engraçado se não fosse trágico...

[]s

  Chiappa
 
--- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo
<[EMAIL PROTECTED]> escreveu
>
> Pessoal bom dia,
>
> Aconteceu uma situação engraçada. Foi feito um relatório por uma outra
> equipe de dba, onde disseram que o tamanho do arquivo influencia em
> fragmentação e migração de linhas. Estranhei um pouco, pq as causas
disso
> normalmente, são devidos a tamanhos de extents e tamanho do blocksize.
> Alguém teria alguma documentação dizendo isso?
>
> Obrigado desde já pela atenção.
>
> Abraços,
>
> Nelson Cartaxo
> DBA ORACLE
>






--------------------------------------------------------------------------------------------------------------------------
Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
--------------------------------------------------------------------------------------------------------------------------__________________________________________________________________

Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine
__________________________________________________________________
O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o link do mesmo para evitar trafego(pedidos) desnecessário.



Yahoo! Grupos, um serviço oferecido por:
PUBLICIDADE


Links do Yahoo! Grupos

Responder a