"Este banco esta num filesystem e minha razão para isso foram os erros que apareceu no alert log."
==> NEM IMAGINO que erro seria esse que te FORÇA a usar filesystem ao invés de raw device ou Oracle ASM, que já te dariam AUTOMATICAMENTE I/O Asíncrono e I/O direto (nada de buffer envolvido na leitura) .... E se os erros foram esses : Mon Jan 15 15:24:11 BRST 2018 Errors in file /ora01/app/admin/prd/bdump/prd_p202_97225.trc: ORA-27090: Unable to reserve kernel resources for asynchronous disk I/O Linux-x86_64 Error: 11: Resource temporarily unavailable Additional information: 3 Additional information: 128 Additional information: 1048576 ==> Vc entendeu que eles estão sendo causados pela sua tentativa de usar asynchronous disk I/O em filesystem né ? Eu estava CONDENANDO/contra-recomendando o uso de filesystems, e NÂO incentivando vc a usá-los, certo ?? Ou então vc pode desabilitar o I/O asíncrono no database, se vc (seja por qual for a razão absurda) vc TEM que usar filesystem ao invés de acessar os discos DIRETAMENTE : isso vc faria através dos parâmetro FILESYSTEMIO_OPTIONS, provavelmente... EVIDENTEMENTE, pode haver uma QUEDA DE PERFORMANCE em vc não usar AIO, mas se é um banco tão pequeno e desimportante que é aceitável rodar em filesystem, TALVEZ essa queda seja aceitável... Sobre o valor : sim, a fórmula proposta nas notas metalink que indiquei é mais ou menos isso, sim... Porém, eu ** REPITO ** : a. antes de mais nada CONFIRME COM O SUPORTE ORACLE pra ver se não tem bugs ativos na parada : se tiver um BUG causando leaks, por exemplo, vc pode setar láááá na Lua o valor do kernel que acaba dando erro de novo E b. confirme com teu sysadmin que vc TEM espaço suficiente em /proc , que o servidor TEM file handles/file descriptors suficientes, que os demais parâmetros de controle que limitam qtdades de arquivos /tamanhos que os arquivo podem crescer estão ok []s Chiappa
