Re: [oracle_br] Re: Concelho com LOBs
E ai Chiappa, blz, Entao, para comecar o meu desespero, eu estou em um jornal cobrindo as ferias de outro DBA, e os caras da aplicação e gerente pediram para eu fazer essas analises de performance pois eu cai na besteira de resolver um problema que o outro DBA tinha deixado logo no primeiro dia, portanto: 1 - Infelizmente eu nao tenho tempo de testar 2 - Eu tenho 2 semanas para fazer algumas sugestoes de performance, hehehehehe Sobre as imagens, os fotografos fazem upgrade das fotos para o sistema, e durante o dia, editores (da materia) e editores (graficos) solicitam para o banco essas imagens para fazer tratamentos ou adicionar em suas materias O que eu fiz, de cara, pois estava desabilitado foi configurar o CACHE que estava desabilitado (com 100GB de RAM e eles nao estavam fazendo cache dos lobs), o LOGGING já estava desligado. Sobre o PCTVERSION estava com o padrão (10%), já anotei para zerar esse parametro ou pelo menos diminuir para 5%, a sua ideia da tabela contendo os dados de consulta e o blob estava certa, e sim, eles estao em tablespaces diferentes e o IN_ROW esta disable, alem disso os LOBS estao separados via partition gerenciados pela aplicacao Vou dar uma olhada na nota que vc enviou, vou procurar alguma dica e ver quais sugestoes adicionais posso dar. Vlw pela dica De: José Laurindo Para: oracle_br@yahoogrupos.com.br Enviadas: Terça-feira, 9 de Agosto de 2011 1:23 Assunto: [oracle_br] Re: Concelho com LOBs 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
[oracle_br] Re: Concelho com LOBs
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
