Oi friendão, blz, tudoi na tranquila ? Intão, vou aproveitar a sua msg e extender um pouco o assunto, falando sobre mais do que o
CHUNK - provavelmente várias coisas vc já fez, ou talvez não se apliquem no seu ambiente, mas vamos lá... Primeiro de tudo, sendo um BLOB vc certamente vai ter que o ler inteiro, na íntegra (não há uma maneira fácil de indexar, de fazer "substring" / busca parcial de um binário) , então é Crucialmente Crucial que vc faça o MENOS POSSÍVEL de I/O, o que (entre outras coisa) quando falamos de gráficos IMPLICA em usar um formato de gravação Compactado : entenda, eu NÂO estou falando de zipar o conteúdo antes de uplodear pro banco, eu estou falando de Já Gravar a imagem compactada/otimizada : por exemplo, recentemente eu escaneei alguns documentos, o software de scanner criava .TIF e dava coisa de vários Mbytes, abri o arquivo no GIMP, salvei com a mesma extensão (mas especificando compressão LZW, que é um protocolo que até o retardadinho do Paint no Windows entende) e pluft, o arquivo passou para dezenas de Kbytes, negócio impressionante, e isso ** SEM ** perda de qualidade e absolutamente SEM sacrificar a compatibilidade - como eu disse, mesmo especificando compressão, o Paint abre, o Office abre, o Croel abrem, sem probs... Aí vc vai dizer : mas Chiappa, eu como DBA é que tenho que ficar cutucando esses coisas, que os Desenvolvedores já deveriam saber e pensar antes ??? A resposta infelizmente é SIM, por incrível que pareça a esmagadora maioria dos desenvolvedores que vi não bota o tico e o teco pra trabalhar, absolutamente parece pensar que o disco é ilimitado, se vc esperar que eles pensem em rotina de limpeza de dados, em otimização do espaço, em Segurança da informação, em Crash recover, bem provável que vc não tenha retorno, então toca nós, como DBAs, ficar tocando nesses assuntos, e pelo jeito imagem de 400 Mb Não parece estar compactada/otimizada... Continuando, antes de entrar no database, outra pergunta : exatamente o que vc está usando como I/O , são raw devices, volumes gerenciados (com ASM ou com volume managers de terceiros) ou é filesystem (seja filesystem linux nativo, seja filesystem de terceiros , tipo Veritas VFX) ?? A questão é que é Crítico que vc ESTEJA fazendo I/O Async (já que Imagino que vc tem um hardware de I/O enterprise-class, capaz de atender a múltiplos I/Os simultãneos) , E no seu caso específico, já que vc está montando um cache grande pro Oracle, provavelmente deve valer a pena fazer Direct I/O, ie, bypassar o cache do Linux : http://www.puschitz.com/TuningLinuxForOracle.shtml#CheckingAsynchronousIOUsage e http://docs.redhat.com/docs/en- US/Red_Hat_Enterprise_Linux/5/html/Oracle_Tuning_Guide/RHELTuningandOptimizationforOracleV11.pdf são refs a respeito ... Aí, entrando no database : antes de mais nada, tudo que vou falar é discutido na nota metalink "Master Note - RDBMS Large Objects (LOBs)", Doc ID 1268771.1 , e nos links dela, ela será a tua ref principal... De cara, seguinte : já que o maior espaço vai ser usado pelos BLOBs (vc não diz mas eu Imagino que vc tenha no registro lógico apenas um ID como chave de busca, e a info do BLOB), aí vale a pena vc ter tablespace SEPARADA para o LOB SEGMENT (o BLOB no seu caso) - isso não vai te dar boost de performance em si mas dá umas facilidades administrativas, como por exemplo poder especificar cláusula de STORAGE diferenciada, tamanhos de extents, coisas assim... Eu Imagino também que a sua aplicação deve ser primariamente INSERT-only (imagino que essas tais imagens correspondem a digitalizações de documentos, e/ou fotos de funcionários, coisas assim, que mudam muito pouco ou nada), então o meu primeiro conselho é vc ter os LOBs (tanto o LOB SEGMENT quanto o LOB INDEX) em tablespace separadas - isso NÂO vai por si só interferir diretamente em performance, MAS vai te dar facilidades administrativas, tipo poder mensurar I/Os facilmente com a V$FILExx, poder fazer backup só dos LOBs.... Como derivada do fato de vc ter LOBs provavelmente com pouca ou nenhuma alteração, coloque esses LOBs com PCTVERSION baixíssimo, vc já ganha algum espaço com isso ... Continuando, já que vc está no 11g eu diria pra vc testar SECUREFILES ao invés dos datafiles-padrão, diz a Oracle que tem algumas vantagens : Inclusive, o que vc pergunta (o CHUNK SIZE) vale principalmente para os datafiles "comuns", os tradicionais BASIC files, com SECUREFILEs eu usei que esse valor é usado mais como uma Recomendação, vc pode ter I/Os maiores ou menores que o CHUNK em securefiles... Eu pessoalmente usei muito pouco ainda pra poder ver alguma coisa, mas fica a idéia, faça testes bons, grandes, volumosos e cuidadosos (MEDINDO quantos I/Os foram feitos pra ler os mesmos dados com BASIC especificando um CHUNK de 1 bloco, de 2 blocos, de 4 blocos, de 8 blocos (que seriam os 64 Kb que vc está pensando) , versus com SECURE) ... Já que vc sabe que necessariamente teus LOBs vão ser grandes, diria pra vc criar a tablespace com extent size uniform de 4 Mb : isso é múltiplo direto do 1 Mb que é o máximo de I/O na maioria dos sistemas, e 4 Mb nem é tão grande que permita muito espaço eventualmente não-usado, nem tão pequeno que crie centenas e centenas de milhares de extents... Eu não recomendo esse setting de 512 Mb que vc tem hoje como extent size, isso é MUITO grande, vc vai ter mais chances de eventuais white-spaces com um setting tão gigantesco... Outra : já que vc sabe que os LOBs sempre vão ser maiores que os 4kb de threshold, já crie os seus LOBs como out of line storage, aí na tablespace de "dados" vão ter só os poucos bytes dos IDs e alguma info relacionada... Essa tablespace pode ser ASSM e AUTOALLOCATE, creio... Logging : se possível (em casos como o seu, de informação carregada de arquivo e estática, que se preciso pode ser carregada de novo após crash, normalmente é) eu recomendo que vc deixe em NOLOGGING o LOB, para permitir eventuais operações com diminuição de redo log : EVIDENTEMENTE, isso Tem que Ser combinado com o DBA, para que ele faça um backup imediatamente após as operações sem log, mas via de regra vale a pena em performance... Finalmente : falando especificamente sobre o CHUNK SIZE, não vejo grande risco de vc interferir em algo com o banco por si só : a única coisa, É Claro, é que vc vai testar DIREITINHO e medir como fica a performance : o trade-off é que quanto maior o CHUNK, certamente mais blocos vão ser alocados e lidos de uma só vez, com certeza tem um ponto aí onde o retorno diminui e vc passa a ter perda, mas IMHO vc acha isso é com teste mesmo, desconheço alguma "fórmula" pronta pra isso... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Anderson Araujo de Oliveira <a13liveira@...> escreveu > > Bom dia, > > Estou analisando um banco de dados que está apresentando Lentidão com leitura > e gravação de LOBs (Imagens, em geral JPG), e queria alguns concelhos, segue > informações do Banco: > - Oracle 11.2.0.2 > - RHEL 5 > - StandAlone > - CPU 64 > - RAM 256GB > - Tamanho médio das imagens 400M > - Initial do Segmento de LOB 1G > - Next do Segmento de LOB 512M > - SGA 100G > - PGA 4,8G > - Database Block 8K > - Chunk 8K > - DB_FILE_MULTIBLOCK_READ_COUNT 128 (Não sei se ajuda, mas de qqr forma, > pensei cheguei a pensar em mudar o CHUNK para a quantidade de blocos desse > parametro, mas quando vi quantos blocos estavam configurados achei que > poderia ser muito) > > Minha intenção inicial é aumentar o CHUNK para 64K, mas como nunca trabalhei > com performance de LOBs estou com medo de impactar negativamente o banco, > alguem te experiencia com isso, sabe dizer os riscos. Detalhe o objetivo > principal dessa base é armazenar e distribuir imagens > > [As partes desta mensagem que não continham texto foram removidas] >
