Rafael, acho que tem um equívoco na afirmação de que "aumentar o tamanho dos
blocos dos indices vc nao terá aumento nenhum de performance."
http://www.dba-oracle.com/art_so_blocksize.htm
Ressalto:
The benefits of large blocksizes are demonstrated on this OTN thread where we
see a demo showing 3x faster performance using a larger block size:
SQL> r
1 select count(MYFIELD) from table_8K where ttime >to_date('27/09/2006','dd/mm/y
2* and ttime <to_date('06/10/2006','dd/mm/yyyy')
COUNT(MYFIELD)
-------------------
164864
Elapsed: 00:00:01.40
...
(This command is executed several times - the execution time was approximately
the same ~
00:00:01.40)
And now the test with the same table, but created together with the index in
16k tablespace:
SQL> r
1 select count(MYFIELD) from table_16K where ttime >to_date('27/09/2006','dd/mm/
2* and ttime <to_date('06/10/2006','dd/mm/yyyy')
COUNT(MYFIELD)
-------------------
164864
Elapsed: 00:00:00.36
(Again, the command is executed several times, the new execution time is
approximately the same ~
You can use the large (16-32K) blocksize data caches to contain data from
indexes or tables that are the object of repeated large scans. Does such a
thing really help performance? A small but revealing test can answer that
question.
For the test, the following query will be used against a 9i database that has a
database block size of 8K, but also has the 16K cache enabled along with a 16K
tablespace:
select
count(*)
from
eradmin.admission
where
patient_id between 1 and 40000;
The ERADMIN.ADMISSION table has 150,000 rows in it and has an index build on
the PATIENT_ID column. An EXPLAIN of the query reveals that it uses an index
multi-block read scan to produce the desired end result:
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 (Cost=41 Card=1 Bytes=4)
1 0 SORT (AGGREGATE)
2 1 INDEX (FAST FULL SCAN) OF 'ADMISSION_PATIENT_ID'
(NON-UNIQUE) (Cost=41 Card=120002 Bytes=480008)
Executing the query (twice to eliminate parse activity and to cache any data)
with the index residing in a standard 8K tablespace produces these runtime
statistics:
Statistics
---------------------------------------------------
0 recursive calls
0 db block gets
421 consistent gets
0 physical reads
0 redo size
371 bytes sent via SQL*Net to client
430 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
To test the effectiveness of the new 16K cache and 16K tablespace, the index
used by the query will be rebuilt into the 16K tablespace that has the exact
same characteristics as the original 8K tablespace, except for the larger
blocksize:
alter index
eradmin.admission_patient_id
rebuild nologging noreverse tablespace indx_16k;
Once the index is nestled firmly into the 16K tablespace, the query is
re-executed (again twice) with the following runtime statistics being produced:
Statistics
---------------------------------------------------
0 recursive calls
0 db block gets
211 consistent gets
0 physical reads
0 redo size
371 bytes sent via SQL*Net to client
430 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
As you can see, the amount of logical reads has been reduced in half simply by
using the new 16K tablespace and accompanying 16K data cache. Clearly, the
benefits of properly using the new data caches and multi-block tablespace
feature of Oracle9i and above are worth your investigation and trials in your
own database.
Veja a última frase Rafael: Como podemos ver a quantidade de logical reads foi
cortada pelo meio, simplesmente usando a nova tablespace de 16K. Claramente, os
benefícios de se usar os 'novos' data caches e tablespace multiblocos valem sua
investigação e tentantivas
(tradução livre, mais ou menos isso, to com
preguiça
rsrsrsrs)
Att,/Regards,
Vitor Jr.
Infraestrutura / Infrastructure Team
Oracle 11g DBA Certified Professional - OCP
Oracle Certified Expert, Oracle Real Application Clusters 11g and Grid
Infrastructure Administrator - OCE
Oracle Database 11g Performance Tuning Certified Expert - OCE
Oracle Exadata 11g Certified Implementation Specialist
Oracle Certified Associate, MySQL 5
mail, gtalk e msn: vitorj...@gmail.com
http://certificacaobd.com.br/
skype: vjunior1981
On 12/11/2012, at 16:03, Rafael Mendonca <raffaell.t...@yahoo.com> wrote:
> Wanderson, como o Milton falou; Se vc separar os indices e os dados em
> tablespaces separados e/ou aumentar o tamanho dos blocos dos indices vc nao
> terá aumento nenhum de performance.
>
> Mas vale salientar que se vc fizer isso e colocar os seus índices para não
> gerar log, o único ganho de performance será nas suas instruções de INSERT,
> DELETE e UPDATE.
>
> Se não me engano isso foi até um artigo do Fábio Prado, segue o link:
>
> http://www.profissionaloracle.com.br/gpo/artigo/banco-de-dados/104-performance-de-consultas-em-tablespaces-separados-para-dados-e-indices
>
> ________________________________
> De: Wanderson Barrence <wbarre...@gmail.com>
> Para: oracle_br@yahoogrupos.com.br
> Enviadas: Segunda-feira, 12 de Novembro de 2012 10:14
> Assunto: Re: [oracle_br] Re: Blocos do Sistemas Operacional e Tablespaces com
> blocos diferentes
>
> Milton!!!
>
> Então não existe nenhum ganho de performance, caso eu separe as tablespaces
> de índices e de dados, mesmo que o tamanho do bloco da tablespace de
> índices seja bem maior do que o tamanho do bloco da tablespace de dados??
>
> Att,
>
> --
> Wanderson Barrence
> DBA Oracle 10g/11g
> Analista de Testes - CBTS
> ----------------------------------------------------------
> MSN: wbarre...@hotmail.com
> ICQ: 170821994
> Linkedin: http://br.linkedin.com/in/wbarrence
>
> Em 10 de novembro de 2012 12:53, Milton Bastos Henriquis Jr. <
> miltonbas...@gmail.com> escreveu:
>
> > **
> >
> >
> > >"A questão das tablespaces também é algo parecido, já vi em alguns estudos
> > >de que se pode separar os índices numa tablespace separada dos dados, com
> > o
> > >objetivo de aumentar o tamanho bloco para que a performance nas consultas
> > >possam ser melhores, mas vem a questão novamente, aumentar o bloco em
> > >quanto???"
> >
> > Isso já foi discutido várias vezes aqui: separar índices dos dados seria
> > somente
> > por questão de organização e não de performance - não faz diferença nenhuma
> > na performance!
> >
> >
> > >"Percebi que os sistemas operacionais que estou trabalhou tanto o Solaris
> > >quanto o RHEL trabalham com tamanhos de blocos de 8k, que é o tamanho
> > >default usado pelo Oracle, aí vem uma outra questão, os blocos do banco de
> > >dados podem ser maiores do que os blocos do SO??"
> >
> > Claro que pode! Isso é muito comum.
> > O que não deve fazer é o contrário - bloco do database ser MENOR que do
> > sistema operacional.
> > Pelo menos na minha opinião isso não faria muito sentido.
> >
> > Sobre "qual o tamanho"... "maior quanto"...
> > nada melhor que a documentação oficial:
> >
> > "Escolhendo o tamanho do bloco":
> >
> > http://docs.oracle.com/cd/E11882_01/server.112/e16638/iodesign.htm#PFGRF94404
> >
> > "Especificando tablespaces com tamanho de bloco diferente"
> >
> > http://docs.oracle.com/cd/E11882_01/server.112/e25494/tspaces003.htm#ADMIN11373
> >
> >
> > 2012/11/9 Wanderson Barrence <wbarre...@gmail.com>
> >
> > > Fala Chiappa!!!
> > >
> > > Eu fiz essa pergunta porque eu estava lendo em alguns materiais e artigos
> > > sobre Oracle, que os blocos do banco de dados são definidos de acordo
> > com o
> > > tamanho dos blocos do sistema operacional, como estou montando um banco
> > de
> > > dados somente para relatório, verifiquei que para maior ganho de
> > > performance na consulta os blocos do banco de dados devem ser maiores,
> > mas
> > > aí veio a pulga atrás da orelha, maior quanto??
> > >
> > > A questão das tablespaces também é algo parecido, já vi em alguns estudos
> > > de que se pode separar os índices numa tablespace separada dos dados,
> > com o
> > > objetivo de aumentar o tamanho bloco para que a performance nas consultas
> > > possam ser melhores, mas vem a questão novamente, aumentar o bloco em
> > > quanto???
> > >
> > > Percebi que os sistemas operacionais que estou trabalhou tanto o Solaris
> > > quanto o RHEL trabalham com tamanhos de blocos de 8k, que é o tamanho
> > > default usado pelo Oracle, aí vem uma outra questão, os blocos do banco
> > de
> > > dados podem ser maiores do que os blocos do SO??
> > >
> > > Estou fazendo alguns testes, mas como nuvens nebulosas ainda pairam
> > muitas
> > > dúvidas sobre a minha cabeça!!!
> > >
> > > É por isso que gostaria de saber opinião do grupo, e como o grupo lida
> > com
> > > esse problema???
> > >
> > >
> > > Att,
> > >
> > > --
> > > Wanderson Barrence
> > > DBA Oracle 10g/11g
> > > Analista de Testes - CBTS
> > > ----------------------------------------------------------
> > > MSN: wbarre...@hotmail.com
> > > ICQ: 170821994
> > > Linkedin: http://br.linkedin.com/in/wbarrence
> > >
> > >
> > >
> > > Em 9 de novembro de 2012 20:55, J. Laurindo Chiappa
> > > <jlchia...@yahoo.com.br>escreveu:
> > >
> > > > **
> >
> > > >
> > > >
> > > > Primeiro veja que o *** Sistema Operacional ** em si não tem nem impõe
> > > > block size para seus I/Os (que Imagino é o tipo de block size a que vc
> > > está
> > > > se referindo - OUTROS existem, como o kernel cache block size, mas
> > > Entendo
> > > > pelo que vc fala que é de I/O mesmo que vc quer) : no caso vc pode ter
> > > seus
> > > > I/Os em Filesystem (aí o filesystem é que vai ter um block size, que vc
> > > > consulta com tune2fs -l se for filesystem linux nativo, ou com o
> > comando
> > > do
> > > > teu fornecedor se for filesystem de terceiros, OU vc pode ter acesso
> > > direto
> > > > às partições (aí vc pode consultar com fdisk -l), OU vc pode ter disk
> > > > volumes (que aí vc consulta o block size com os comandos do volume
> > > manager
> > > > que vc usa) .... okdoc ??
> > > > A segunda pergunta : sim, vc pode ter tablespaces com blocksizes
> > > > não-default, diferentes do block size default do database -
> > normalmente o
> > > > RDBMS Oracle aceita blocksizes de 2KB, 4 KB, 8KB (o default, e
> > > normalmente
> > > > o mais usado), 16 KB e 32 KB - a lista de blocksizes possíveis pode
> > > variar
> > > > ligeiramente de acordo com a versão do RDBMS e o SO em uso, consulte a
> > > doc
> > > > da sua versão de RDBMS no seu SO... Para vc criar uma tablespace com
> > > > blocksize não-default, primeiro vc cria um buffer cache específico para
> > > ela
> > > > (parâmetro db_NNk_cache_size , onde NN é o tamanho em KBytes), e depois
> > > > simplesmente no comando CREATE TABLESPACE vc indica :
> > > >
> > > > create tablespace tafile 'lista de datafiles' size tamanhododatafile
> > > > blocksize NNk extent management tipodomanagement segment space
> > management
> > > > tipodospacemanagement;
> > > >
> > > > ==> É ** bem ** difícil vc pegar um caso onde uma tablespace com
> > > blocksize
> > > > não-default tenho um ganho (seja em performance, seja em
> > > > gerenciamento/administração), mas é possível, sim...
> > > >
> > > > []s
> > > >
> > > > Chiappa
> > > > --- Em oracle_br@yahoogrupos.com.br, Wanderson Barrence <wbarrence@
> > ...>
> > > > escreveu
> > > >
> > > > >
> > > > > Olá Pessoal,
> > > > >
> > > > > Alguém sabe me informar como eu faço para verificar o tamanho dos
> > > blocos
> > > > > que o sistema operacional está utilizando??
> > > > >
> > > > > É possível configurar tablespaces com tamanhos de blocos
> > diferentes???
> > > > Caso
> > > > > sim, como eu faço esse tipo de configuração?
> > > > >
> > > > > Desde já fico agradecido pela ajuda de vocês.
> > > > >
> > > > > Att,
> > > > >
> > > > > --
> > > > > Wanderson Barrence
> > > > > DBA Oracle 10g/11g
> > > > > Analista de Testes - CBTS
> > > > > ----------------------------------------------------------
> > > > > MSN: wbarrence@...
> > > >
> > > > > ICQ: 170821994
> > > > > Linkedin: http://br.linkedin.com/in/wbarrence
> > > > >
> > > > >
> > > > > [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
> > >
> > >
> > >
> >
> > --
> > Att,
> >
> >
> > [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]
>
>
[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
<*> Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/oracle_br/
<*> Para sair deste grupo, envie um e-mail para:
oracle_br-unsubscr...@yahoogrupos.com.br
<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
http://br.yahoo.com/info/utos.html
