Boa Chiappa. Tem aquele efeito colateral, especialmente em ambientes OLTP. Se aumentar muito o blocksize pode aumentar a contenção, correto? OLTP -> 8K BATCH -> pode-se pensar em 16K mediante testes, especialmente para tbs de indexes
Escrevi alguma bobagem? :) Att Vitor Jr --- Em oracle_br@yahoogrupos.com.br, "J. Laurindo Chiappa" <jlchiappa@...> escreveu > > Blz ??? > Bom, deixe-me começar a resposta REPETINDO o mesmo que já tinha dito, vamos > ver se a segnda é de vez : ponto é, falando de blocagem para I/O (como eu > mostrei nos links anteriores, há outros tipos de blocagem, e há inclusive o > buffer block size do SO, cfrme > http://www.ixora.com.au/tips/buffered_block_size.htm), o fato é que ***** NÃO > EXISTE **** - realmente NÃO Existe - isso de "tamanho dos blocos do sistema > operacional", especialmente no unix/linux : um FILESYSTEM tem blocksize, uma > PARTITION tem blocksize, um volume (se estivermos falando de storage) tem > blocksize... Então é fundamentalmente dependente do ambiente, NÃO TEM essa > figura de bloco do SO absoluto e único, captou ?? Hai capito ? Provavelmente > o material que vc diz está (por questões didáticas) fazendo uma > supersimplificação quando fala em "block size do SO", tem mais carne debaixo > desse angú... ==> Muito bem, então o passo#1 se vc está fazendo > micro-otimizações do tipo se preocupar com block sizes (e NÂO que vc deveria > se preocupar primariamente com isso, 99,9% das vezes o Retorno é > Incomensuravelmente Maior se vc se dedicar ao Tuning nas aplicações, > principalmente Reduzindo LIOs - já que mesmo um I/O perfeitamente alinhado > fisicamente se for feito milhares e milhares de vezes TEM OVERHEAD inerente) > seria mesmo Descobrir exatamente que tipo de I/O device vai ser usado : vai > ser filesystem ? Se sim, Qual filesystem ? Filesystem nativo OU de terceiros > ?? Se for de terceiros, qual software de controle será usado, e em que versão > ?? Ou vai ser usado raw partitions ?? Em qual hardware ?? Ou serão disk > volumes ?? Volumes controlados por algum lvm (ASM, onde em grande parte vc > não se preocupa com block size, já que há a figura do aallocation size cfrme > http://askdba.org/weblog/2008/05/allocation-unit-and-extents-in-asm/ ??), ou > não ??? SABENDO disso aí é que vc poderá descobrir qual block size está sendo > usado, se é o default do dispositivo ou não, como e se é possível mudar ou se > o blocksize está "bom".... okdoc ? > > Antes de falar sobre escolha de blocksize, deixe-me discorrer um pouco > sobre a teoria : a figura do block size é relevante quando vc faz I/Os ** > mínimos **, tipo lê um registro da tabela - o RDBMS Oracle (e não só ele, > virtualmente TODOS os RDBMSs profissionais) nesse cenário ao invés de ler só > os poucos bytes referentes ao registro, o RDBMS solicita ao SO que leia TODO > o bloco aonde está o tal registro, e bota esse bloco em cache.... A idéia é > que normalmente muito em breve os outros registros que estão nesse bloco > podem ser solicitados, aí não será feito acesso ao disco, certo ? > > Muito bem : sendo assim como eu disse, valeria então a pena se usar um > bloco de TROCENTOS bytes, em tese cacheando Muito mais dados ?? Na verdade o > Problema nessa abordagem é (entre outras questões) que quanto maior o bloco > um I/O mais overhead vai haver para o SO para o completar, ok ? Então > CLARAMENTE há um sweetspot, há um ponto entre o malefício/overhead contra o > futuro benefício do caching tem o seu máximo, e depois cai > vertiginosamente..... Cito o manual Oracle de Tuning Guide, especialmente o > cap. 8 I/O Configuration and Design .... O resumo da história é que na > ESMAGADORA maioria dos casos o custo x benefício melhor para uma aplicação > genérica ocorre com bloco de 8 KBytes, E para sistemas DW/batch tradicionais > pode-se pensar em 16 KB - só saia disso com uma PROVA técnica muito > específica, em cima de TESTES REAIS aí no seu hardware, sim ?? > > Aí o seu segundo ponto : veja, fisicamente é claro q ue quando o RDBMS pede > para para o SO ler um bloco de X bytes, se o disk device em questão tem um > blocksize de exatamente X tudo tá alinhado, um I/O solicitado em tese vai > custar um I/O real no Sistema Operacional, é o ideal.... Agora, que catzo de > vantagem teria se o bloco do database fosse MAIOR que o do SO ???? O RDBMS > pediria X bytes, o device tem blocksize de x-y, PORTANTO ao menos dois I/Os > físicos serão necessários , que vantagem Maria levou ???? MUITO provavelmente > se é essa mesma a recomendação desse tal material não me parece ser lá muito > fundamentada - passa pra gente o link se esse material está online, até para > contra-recomendarmos esse talzinho, pleitearmos uma correção... > O Outro ponto é block size externo MENOR que o bloco do database : > tranquilamente isso PODE acontecer até por motivos físicos : > http://lwn.net/Articles/377895/ lista o casos de discos fisicamente alinhados > para 4 KB, por exemplo... Ora, já que X bytes requisitados pelo RDBMS ** vão > ** exigir x+y I/Os físicos diretos, o que vc DEVERIA tentar é se assegurar > que ao menos os números são múltiplos exatos entre si E o mais próximo > possível do bloco do database: digamos que vc tenha block size externo no > dispositivo de 3 KB, se o bloco do database for de 8KB o SO terá que fazer 3 > I/Os, tendo alguma sobra, já se fosse 4 KB seriam dois I/Os... > > Finalmente, sobre utilização de índices com block size grande, talvez até > maior do que o default do database : isso até pode ser positivo, mas vc NÂO > PODE se esquecer da contrapartida, como mais tempo para lock de blocos, o > overhead para o SO com I/Os mais extensos.... Leia a série em > http://richardfoote.wordpress.com/2009/02/18/larger-block-tablespace-for-indexes-revisited-part-i-the-tourist/ > (essa é a parte I, leia tudo) para uma ref mais direta e confiável, yes ??? > Eu dou a mesma Recomendação acima : antes de mais nada, TESTE no SEU ambiente > e no SEU hardware o custoxbenefício desa opção, para só sair do da linha > geral de 8 KB com dados REAIS na mão, yep ??? > > []s > > Chiappa > > > --- Em oracle_br@yahoogrupos.com.br, Wanderson Barrence <wbarrence@> escreveu > > > > 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: wbarrence@ > > ICQ: 170821994 > > Linkedin: http://br.linkedin.com/in/wbarrence > > > > > > > > Em 9 de novembro de 2012 20:55, J. Laurindo Chiappa > > <jlchiappa@>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] > > >
