1832210
Members
2784
Online
110040
Solutions
Nelson,
Orcale have this to say aboout AIO onb HPUX filesystems:
The kernel parameter fs_async can be set to allow asynchronous writes to file systems. However, write calls can return without the data being physically written to disk (the write sits in the UNIX buffer cache). The data in question is file-system metadata such as free space lists, blocks and inodes. A system crash would potentially lose this data, and leave the filesystem in an inconsistent state, causing database corruption. Oracle still opens files with the O_DSYNC flag (see 'tusc' snipet below), which insists that writes are physically written: open("/oracle/datafiles/system01.dbf", O_RDWR|O_LARGEFILE|O_DSYNC, 0) = 19 In summary, fs_async is ignored for datafiles(due to open() with O_DSYNC). However, filesystem metadata may be lost, potentially causing datafile corruption. Oracle does not recommend setting fs_async to '1'.
So thats a no to the your first question then.
As to your second question, the stuff Steven has pointed you to has arguments on raw vs. cooked, but what you really need is someone who has actually tested raw/async vs. cooked/sync - now maybe Clay did that, but he doesn't say in his post - can you elaborate Clay?
HTH
Duncan
I am an HPE Employee
Orcale have this to say aboout AIO onb HPUX filesystems:
The kernel parameter fs_async can be set to allow asynchronous writes to file systems. However, write calls can return without the data being physically written to disk (the write sits in the UNIX buffer cache). The data in question is file-system metadata such as free space lists, blocks and inodes. A system crash would potentially lose this data, and leave the filesystem in an inconsistent state, causing database corruption. Oracle still opens files with the O_DSYNC flag (see 'tusc' snipet below), which insists that writes are physically written: open("/oracle/datafiles/system01.dbf", O_RDWR|O_LARGEFILE|O_DSYNC, 0) = 19 In summary, fs_async is ignored for datafiles(due to open() with O_DSYNC). However, filesystem metadata may be lost, potentially causing datafile corruption. Oracle does not recommend setting fs_async to '1'.
So thats a no to the your first question then.
As to your second question, the stuff Steven has pointed you to has arguments on raw vs. cooked, but what you really need is someone who has actually tested raw/async vs. cooked/sync - now maybe Clay did that, but he doesn't say in his post - can you elaborate Clay?
HTH
Duncan
I am an HPE Employee
Actually the Oracle metalink note I pulled the above snippet from (doc ID 139272.1 on metalink if your DBAs want to look at it), give an alternative to using async IO - using multiple DBWR processes - have your DBAs already exhausted this avenue?
HTH
DUncan
I am an HPE Employee
HTH
DUncan
I am an HPE Employee