Menu de navegação

[buoroParticipante]

Bom dia,
Tenho um ERP rodando em Oracle 12c e uma rotina específica estava levando 30 horas para ser executada. Estou em ambiente LINUX 64 e então defini o parâmetro db_file_multiblock_read_count = 1024 (o default estava como 128) e o tempo de execução da mesma rotina caiu para 24 horas. Considero que foi uma redução significativa (6 horas). Verifiquei que poderia ainda elevar o valor desse parâmetro para 4096. O db_block_size deste banco está como 8k. Alguém vê alguma implicação em manter o valor desse parâmetro elevado? Foi a alternativa que encontrei já que não é possível ajustar o SQL da aplicação. Obrigado

[José Laurindo ChiappaModerador]

Antes de te responder, uma Observação : tecnicamente, é TOTAL e COMPLETAMENTE FALSA a sua Afirmação que vc não pode alterar os SQLs (provavelmente por não ter acesso ao código fonte do Aplicativo) – existem SIM várias técnicas para vc MUDAR o texto de um SQL (‘trocando-o’ por um de melhor qualidade, imaginamos) sem ter acesso ao fonte do aplicativo, em http://docplayer.com.br/25266808-Sql-factoring-ajustes-de-sql-sem-acesso-aos-fontes-por-jose-laurindo-chiappa.html eu listo alguns, como o SYS.DBMS_ADVANCED_REWRITE… Na minha demonstração no artigo, uma vez tudo setado o banco recebe um ‘SELECT C1 FROM TABLEA’ mas o que é executado é um ‘SELECT C1 FROM TABLEB’, OU SEJA, eu RE-ESCREVI o SQL que o banco executa SEM ter acesso ao fonte da Aplicação, okdoc ??? E como eu cito também, é Plenamente Possível vc alterar o PLANO DE EXECUÇÃO de um determinado SQL ** sem ** ter que re-escrever ele, através da injeção de HINTs com a criação de itens customizados no database tal como OUTLINEs, SQL PROFILES, Injeção de linhas a mais no WHERE da Query via DBMS_FGAC/VPD, Ou pela criação de objetos de banco como views (tanto views ‘normais’ quanto views materializadas), criação de índices, etc, ou mesmo via alteração de parâmetros que o Otimizador leva em conta via ALTER SESSION (como vc na verdade quer fazer com o DB_FILE_MULTIBLOCK_READ_COUNT, ele é Sim um parãmetro de banco)…

Não que vc DEVA sair alterando o database e/ou o SQL da aplicação executado no banco (até porque imho uma vez que vc indicou/provou que colocando um HINT ou criando um índice ou alterando o texto de um SQL ou seja o que for a performance é imensamente melhor é OBRIGAÇÃO do Fornecedor reconhecer o bug e fornecer um bugfix na forma do SQL corrigido e/ou do objeto criado) mas a POSSIBILIDADE EXISTE SIM, sempre, ok ?? No máximo o que PODE acontecer é vc não ter PERMISSÃO de usar os recursos para re-escrever/ alterar os SQLs e/ou os planos de execução (talvez por Proibição no contrato com a fornecedora do Aplicativo, digamos), mas que dá pra fazer sem acesso ao fonte, dá….

Agora sim a sua resposta : sobre o setting do parãmetro, primeiro leia em https://logicalread.com/oracle-db-file-multiblock-read-count-mc01/ (e na Documentação Oracle) que esse param de banco indica a quantidade de blocos que o RDBMS vai pedir pro Sistema Operacional ler de uma vez só : OBVIAMENTE, há Limites Físicos, há um Máximo de BYTES que o SO e o teu hardware de disco conseguem ler de uma pancada só, sim sim ?? Via de regra esse limite é de 1 MB, mas há Storages de volumes de disco onde esse limite é bem maior….Veja também que se vc setar esse tamanho de I/O para um valor MAIOR que o limite físico, o Sistema Operacional simplesmente vai baixar para o limite físico dele…
No seu exemplo, vc setou para 1024, e já que teu block size é 8k (ie, 8192 bytes) , e isso representa 1024 * 8192 = 8.388.608 bytes, ou seja, coisa de 8 MB…. Como esse valor é Muitíssimo Maior do que o limite comum de 1 MB, eu ACREDITO que o Sistema Operacional já esteja fazendo uma leitura máxima e esteja portanto Limitando para o máximo dele : se for isso, setando para ainda mais que isso vc vai obter a mesma exata performance, já que o Sistema Operacional vai continuar limitando no máximo físico dele…. Faça um teste setando para 2048, depois um outro teste setando para 4096, que vc deve ver performance idêntica…

E para tirar a dúvida Completamente se está ou não fazendo I/O no tamanho limite (e QUAL é ele!!) vc pode fazer um TRACE 10046 numa sessão onde vc colocou um valor bem alto pro parâmetro eonde vc esteja fazendo um Full Table Scan qualquer, cfrme mostrado (por exemplo, entre outras fontes) em http://kerryosborne.oracle-guy.com/2010/01/autotuned-db_file_multiblock_read_count/ ou em https://vistababa.wordpress.com/2009/09/28/oracle-db_file_multiblock_read_count-parameter/ : no arquivo .trc que será gerado no servidor vc vai ver linhas tipo :

WAIT #6: nam=’db file scattered read’ ela= 5218 file#=4 block#=181291 blocks=NNN obj#=54141 tim=1233806813800264

onde NNN foi a quantidade de blocos que o Full Table Scan conseguiu ler de uma vez só…

[]s

Chiappa

OBS : é importante dizer que vc PODE ter efeitos colaterais sérios setando isso, veja em http://nervinformatica.com.br/blog/index.php/2014/05/29/oracle-sql-tuning-full-table-scan-x-db_file_multiblock_read_count-ou-migramos-para-11gg2-e-ficou-lento/ que aumentando esse Parâmetro vc Direcionou o Otimizador a dar preferência para FULL TABLE SCANs , o que PODE ter um efeito geral nocivo…. Use COM EXTREMO CUIDADO esse parâmetro, Testando sempre muito bem antes, alterando-o via ALTER SESSION só numa determinada sessão se possível (e não em nível geral de banco), e Sempre como último recurso : dê Total Preferência primeiro na abertura de BUG de performance com o Fornecedor, se ele não resilver aí vc tenta apelar pra re-escrita de SQLs ou criação de objetos adicionais, se ainda assim não conseguir aí sim como último recurso vc apela pra ajustes de parâmetros , o que englobaria além do DB_FILE_MULTIBLOCK_READ_COUNT os parâmetros OPTIMIZER_xx : se vc olhar a Documentação Oracle (online em https://docs.oracle.com/database/121/TGSQL/tgsql_influence.htm#TGSQL251 para o 12cR1, por exemplo) vc obtém a Lista deles todos….

[Autor]

Posts