Il comportamento e le raccomandazioni per filesystemio_options su ASA r2 sono identici ai sistemi AFF/ FAS perché il parametro è specifico di Oracle e non dipende dalla piattaforma di archiviazione. ASA r2 utilizza ONTAP come AFF/ FAS, quindi si applicano le stesse best practice.

Contrariamente a quanto si crede, l'i/o asincrono e diretto non si escludono a vicenda. NetApp ha osservato che questo parametro è spesso configurato in modo non corretto negli ambienti dei clienti e che questa errata configurazione è direttamente responsabile di molti problemi di prestazioni.

L'i/o asincrono significa che le operazioni i/o di Oracle possono essere parallelizzate. Prima della disponibilità di i/o asincrono su vari sistemi operativi, gli utenti hanno configurato numerosi processi dbwriter e modificato la configurazione del processo del server. Con l'i/o asincrono, il sistema operativo stesso esegue i/o per conto del software di database in modo altamente efficiente e parallelo. La procedura non pone i dati a rischio e le operazioni critiche, come il logging di redo di Oracle, vengono comunque eseguite in maniera sincrona.

L'i/o diretto ignora la cache buffer del sistema operativo. L'i/o su un sistema UNIX scorre normalmente attraverso la cache del buffer del sistema operativo. Ciò è utile per le applicazioni che non mantengono una cache interna, ma Oracle dispone di una propria cache buffer all'interno di SGA. In quasi tutti i casi, è meglio abilitare l'i/o diretto e allocare la RAM del server all'SGA piuttosto che affidarsi alla cache del buffer del sistema operativo. Oracle SGA utilizza la memoria in modo più efficiente. Inoltre, quando l'i/o fluisce attraverso il buffer del sistema operativo, è soggetto a un'ulteriore elaborazione, che aumenta le latenze. L'aumento delle latenze è particolarmente percepibile con un elevato i/o in scrittura quando una bassa latenza è un requisito critico.

Le opzioni per filesystemio_options sono:

Alcuni vecchi sistemi operativi presentavano problemi con l'I/O asincrono, il che ha portato a consigli obsoleti che suggerivano di evitarlo. Tuttavia, l'I/O asincrono è stabile e pienamente supportato su tutti i sistemi operativi attuali. Non c'è motivo di disattivarlo a meno che non venga identificato un bug specifico del sistema operativo.

Se un database utilizza l'i/o con buffer, un passaggio all'i/o diretto potrebbe anche richiedere una modifica delle dimensioni SGA. La disattivazione dell'i/o con buffer elimina i vantaggi prestazionali che la cache del sistema operativo host fornisce al database. L'aggiunta di RAM alla SGA risolve questo problema. Il risultato netto dovrebbe essere un miglioramento delle performance di i/O.

Sebbene sia quasi sempre meglio utilizzare la RAM per Oracle SGA piuttosto che per il caching del buffer del sistema operativo, potrebbe essere impossibile determinare il valore migliore. Ad esempio, potrebbe essere preferibile utilizzare i/o con buffer di dimensioni SGA molto ridotte su un server di database con molte istanze Oracle attive in modo intermittente. Questa disposizione consente l'utilizzo flessibile della RAM disponibile rimanente sul sistema operativo da parte di tutte le istanze di database in esecuzione. Si tratta di una situazione molto insolita, ma è stata osservata presso alcune sedi dei clienti.