Ao contrário da crença comum, a e/S assíncrona e direta não são mutuamente exclusivas. A NetApp observou que esse parâmetro é frequentemente mal configurado em ambientes de clientes, e essa configuração incorreta é diretamente responsável por muitos problemas de desempenho.

E/S assíncrona significa que as operações de e/S Oracle podem ser paralelizadas. Antes da disponibilidade de e/S assíncrona em vários sistemas operacionais, os usuários configuraram vários processos dbwriter e alteraram a configuração do processo do servidor. Com e/S assíncrona, o próprio sistema operacional executa e/S em nome do software de banco de dados de maneira altamente eficiente e paralela. Esse processo não coloca os dados em risco, e operações críticas, como o Oracle refazer o log, ainda são executadas de forma síncrona.

A e/S direta ignora o cache do buffer do sistema operacional. E/S em um sistema UNIX normalmente flui através do cache de buffer do sistema operacional. Isso é útil para aplicativos que não mantêm um cache interno, mas o Oracle tem seu próprio cache de buffer dentro do SGA. Em quase todos os casos, é melhor habilitar e/S direta e alocar RAM do servidor para o SGA em vez de confiar no cache de buffer do sistema operacional. O Oracle SGA usa a memória de forma mais eficiente. Além disso, quando a e/S flui pelo buffer do sistema operacional, ela está sujeita a processamento adicional, o que aumenta as latências. As latências aumentadas são especialmente percetíveis com e/S de gravação intensa quando a baixa latência é um requisito essencial.

As opções para filesystemio_options são:

Alguns clientes encontraram problemas assíncronos de I/o no passado, especialmente com versões anteriores do Red Hat Enterprise Linux 4 (RHEL4). Alguns conselhos desatualizados na internet ainda sugerem evitar IO assíncrono por causa de informações desatualizadas. E/S assíncrona é estável em todos os sistemas operacionais atuais. Não há razão para desativá-lo, ausente um bug conhecido com o sistema operacional.

Se um banco de dados tiver usado e/S em buffer, um switch para direcionar e/S também pode garantir uma alteração no tamanho do SGA. A desativação da e/S armazenada em buffer elimina o benefício de desempenho que o cache do sistema operacional do host fornece para o banco de dados. Adicionar RAM de volta ao SGA repara este problema. O resultado líquido deve ser uma melhoria no desempenho de e/S.

Embora seja quase sempre melhor usar RAM para o Oracle SGA do que para cache de buffer do SO, pode ser impossível determinar o melhor valor. Por exemplo, pode ser preferível usar e/S em buffer com tamanhos SGA muito pequenos em um servidor de banco de dados com muitas instâncias Oracle ativas intermitentemente. Este arranjo permite o uso flexível da RAM livre restante no sistema operacional por todas as instâncias de banco de dados em execução. Esta é uma situação altamente incomum, mas tem sido observada em alguns sites de clientes.