일반적인 인식과 달리 비동기식 및 직접I/O는 상호 배타적이지 않습니다. NetApp은 이 매개 변수가 고객 환경에서 종종 잘못 구성되며 이 잘못된 구성이 여러 성능 문제의 직접적인 원인이 된다는 것을 목격했습니다.

비동기식 I/O에서는 Oracle I/O 작업을 병렬화할 수 있습니다. 다양한 운영 체제에서 비동기식 I/O를 사용할 수 있게 되기 전에 사용자는 수많은 dbwriter 프로세스를 구성했고 서버 프로세스 구성을 변경했습니다. 비동기식 I/O를 통해 운영 체제는 매우 효율적인 병렬 방식으로 데이터베이스 소프트웨어 대신 I/O를 수행합니다. 이 프로세스는 데이터를 위험에 처하게 하지 않으며 Oracle 로깅 재실행 같은 중요한 작업은 여전히 동기식으로 수행됩니다.

직접 I/O는 운영 체제 버퍼 캐시를 우회합니다. UNIX 시스템의 I/O는 일반적으로 운영 체제 버퍼 캐시를 통해 흐릅니다. 이는 내부 캐시에서 유지되지 않는 애플리케이션에 유용하지만 Oracle은 SGA 내부에 자체 버퍼 캐시가 있습니다. 거의 모든 경우 운영 체제 버퍼 캐시를 사용하는 것보다 직접 I/O를 활성화하고 서버 RAM을 SGA에 할당하는 것이 더 낫습니다. Oracle SGA는 메모리를 더 효율적으로 사용하며 I/O가 운영 체제 버퍼를 통해 흐를 때 지연 시간을 증가시키는 추가 처리가 적용됩니다. 증가한 지연 시간은 짧은 지연 시간이 중요한 요구사항일 때 쓰기 집약적 I/O에서 특히 뚜렷하게 나타납니다.

의 옵션 filesystemio_options 다음과 같습니다.

과거에는 특히 Red Hat Enterprise Linux 4(RHEL4) 릴리즈에서 비동기식 I/O 문제에 직면하는 고객이 있었습니다. 일부 오래된 인터넷 조언은 오래된 정보로 인해 비동기 IO를 피하는 것을 제안합니다. 비동기식 I/O는 현재의 모든 운영 체제에서 안정적입니다. OS에 알려진 버그가 없고 비활성화할 이유가 없습니다.

데이터베이스가 버퍼링된 I/O를 사용해온 경우 직접 I/O로 전환하면 SGA 크기 변경도 보장됩니다. 버퍼링된 I/O를 비활성화하면 호스트 운영 체제 캐시가 데이터베이스에 제공하는 성능 이점이 없어집니다. RAM을 SGA에 다시 추가하면 이 문제가 해결되며 결과적으로 I/O 성능이 개선될 것입니다.

거의 모든 경우에 Oracle SGA에 운영 체제 버퍼 캐싱보다 RAM을 사용하는 것이 더 낫지만 최고의 가치를 결정하는 것은 불가능할 수 있습니다. 예를 들어, 간헐적인 액티브 Oracle 인스턴스가 있는 데이터베이스 서버에는 아주 작은 SGA 크기의 버퍼링된 I/O를 사용하는 것이 더 나을 것입니다. 이렇게 하면 실행 중인 모든 데이터베이스 인스턴스를 통해 운영 체제의 나머지 가용 RAM을 유연하게 사용할 수 있습니다. 이는 매우 드문 상황이지만 일부 고객 사이트에서 관찰된 바 있습니다.