Contrairement à une idée reçue, ces deux types d'E/S ne s'excluent pas mutuellement. NetApp a observé que ce paramètre est souvent mal configuré dans les environnements des clients. Cette configuration incorrecte est la cause directe de nombreux problèmes de performances.

Les E/S asynchrones offrent la possibilité de paralléliser les opérations Oracle d'E/S. Avant la disponibilité des E/S asynchrones sur différents systèmes d'exploitation, les utilisateurs ont configuré de nombreux processus dbwriter et modifié la configuration du processus serveur. Avec les E/S asynchrones, le système d'exploitation lui-même exécute les E/S en parallèle pour le compte du logiciel de base de données. Ce processus ne présente aucun risque pour les données et les opérations critiques, telles que la journalisation de reprise Oracle, sont toujours exécutées de manière synchrone.

Les E/S directes contournent le cache du tampon du système d'exploitation. Sur un système UNIX, les E/S transitent normalement par le cache du tampon du système d'exploitation. Ceci est utile pour les applications qui ne maintiennent pas de cache interne, mais Oracle dispose de son propre cache de tampon dans la SGA. Dans la plupart des cas, il est préférable d'activer les E/S directes et d'allouer la RAM du serveur à la mémoire SGA plutôt que d'utiliser le cache du tampon du système d'exploitation. La SGA exploite la mémoire plus efficacement. En outre, lors de leur transit via le tampon du se, les E/S sont soumises à un traitement supplémentaire, ce qui augmente les latences. Cette augmentation est particulièrement visible lors des E/S intenses en écriture, pour lesquelles la faible latence est primordiale.

Les options pour filesystemio_options sont :

Certains clients ont déjà rencontré des problèmes d'E/S asynchrones, notamment avec les versions précédentes de Red Hat Enterprise Linux 4 (RHEL4). Certains conseils obsolètes sur Internet suggèrent toujours d'éviter les E/S asynchrones en raison d'informations obsolètes. Les E/S asynchrones sont stables sur tous les systèmes d'exploitation actuels. Il n'y a aucune raison de le désactiver, en l'absence d'un bug connu avec le système d'exploitation.

Si une base de données utilise des E/S mises en tampon, un switch vers des E/S directes peut également justifier une modification de la taille de la mémoire SGA. La désactivation des E/S mises en tampon élimine le gain de performance fourni par le cache du se hôte pour la base de données. L'ajout de RAM à la SGA résout ce problème. Et devrait améliorer les performances nettes d'E/S.

Bien qu'il soit presque toujours préférable d'utiliser la RAM pour la SGA d'Oracle plutôt que pour le cache du tampon du système d'exploitation, il peut s'avérer impossible de déterminer ce qui est le plus avantageux. Par exemple, il est parfois préférable d'utiliser des E/S mises en tampon avec une mémoire SGA de très petite taille sur un serveur de base de données comportant de nombreuses instances Oracle actives par intermittence. Cette configuration permet à toutes les instances de base de données en cours d'exécution d'utiliser de manière flexible la RAM restante sur le système d'exploitation. Cette situation est très inhabituelle, mais elle a été observée sur certains sites clients.