- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: Once again async IO for oracle....
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-26-2009 04:57 AM
тАО10-26-2009 04:57 AM
I've dispute with our DB admins and I want to know which solution is better....
So the case is that they want to use the /dev/async driver on a filesystem (not on a raw device) and for what I know it is not possible for Oracle, but we have some old servers where /dev/async is used on filsystems...
So my question is which is better : to let DBAs to use /dev/async on filesystem or to use mount options (mincache=direct,convosync=direct) which is avalable with OnlineJFS?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-26-2009 05:24 AM
тАО10-26-2009 05:24 AM
SolutionI vote for none of the above.
http://download.oracle.com/docs/cd/B19306_01/server.102/b15658/appb_hpux.htm#i637036
Click on asynchronous i/o
http://download.oracle.com/docs/cd/B19306_01/server.102/b15658/appb_hpux.htm#i637036
Raw devices no longer offers much of an advantage over cooked filesystems.
SEP
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-26-2009 05:26 AM
тАО10-26-2009 05:26 AM
Re: Once again async IO for oracle....
So what are these older systems and how do you know "/dev/async" is being used? The fact that it is present _does not_ mean it is being used.
Async IO for Oracle is *not* possible on a filesystem unless you are using the Symantec/Veritas QuickIO/ODM stack (and then you wouldn't be using /dev/async anyway)
Your DBAs are wrong - tell them to go read Oracle Metalink article 139272.1, which makes this clear...
>> So my question is which is better : to let DBAs to use /dev/async on filesystem or to use mount options (mincache=direct,convosync=direct) which is avalable with OnlineJFS?
This is not an either/or question as these are 2 different things:
- as I said you shouldn't use /dev/async with Oracle on a filesystem as Oracle _will not_ open the files in asynchronous mode anyway.
- The JFS mount options you mention are about Direct IO (i.e. unbuffered IO), which is not the opposite of asynchronous IO, but the opposite of buffered IO (i.e. IO that goes through the filesystem buffer cache). Generally for Oracle it is better to let Oracle control what happens with IO buffering by operating a smaller filesystem buffer cache, forcing direct IO (via the mount options) and using a bigger SGA.
HTH
Duncan
I am an HPE Employee
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-26-2009 05:42 AM
тАО10-26-2009 05:42 AM
Re: Once again async IO for oracle....
As you can see :
fuser /dev/async
/dev/async: 6174o 23920o 12520o 14332o 12712o 12702o 12710o 14334o 12721o 15023o 14330o 12691o 12731o 12717o 12723o 12586o 14337o 25106o 12689o 12719o 12286o 21974o 12695o 12464o 12704o 12697o 12671o 12715o 12693o 12541o 14339o 12632o 15015o 11790o 24310o 14356o 19426o 14354o 25110o 24677o 23713o 24312o 14526o 14051o 5884o 25505o 9019o 4917o 14522o 25114o 4921o 4919o 4923o 24584o 14528o 4915o 15573o 14524o 24675o 24685o 26536o 24689o 26534o 24908o 26213o 14871o 21003o 25620o 14084o 6169o 21151o 24036o 24580o 6171o 24697o 6167o 24896o 24673o 21976o 23928o 19960o 24314o 23705o 5330o 26609o 23703o 14952o 24582o 21978o 515o
ps -ef | grep 14337
oracle 14337 1 28 Sep 3 ? 1548:16 oracleods (LOCAL=NO)
I think this means that oracle uses /dev/async I'm 100% sure that the datafiles are on a filesystem not on raw device.
Nevermind... fs_async kernel param is set to 0 and I think in that case we heve no real async IO (this is only a "fake") and no real performance optimisation....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-26-2009 05:54 AM
тАО10-26-2009 05:54 AM
Re: Once again async IO for oracle....
The metalink article I pointed you at discusses all this - it makes the point that Oracle processes will open /dev/async *even if async IO is not being used*
Oracle is only using async if:
i) the dbwr process opens /dev/async
ii) the oracle parameter disk_aynch_io is set to TRUE
iii) the datafiles are on raw disk
only if all 3 of these are true is aync IO really going on.
fs_async is completely ignored by oracle anyway (this is also discussed in the metalink article)
HTH
Duncan
I am an HPE Employee
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-26-2009 05:57 AM
тАО10-26-2009 05:57 AM