Re: Is filesystemio_options relevant when the database is on ASM ?
- From: "Gaja Krishna Vaidyanatha" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "gajav@xxxxxxxxx" for DMARC)
- To: "Hemant-K.Chitale@xxxxxx" <Hemant-K.Chitale@xxxxxx>, "Mark W. Farnham" <mwf@xxxxxxxx>
- Date: Fri, 17 Oct 2014 15:48:41 -0700
Hi Hemant,
1) Answer to your original question is - NO, in my experience I have not
observed the setting of filesystemio_options to be relevant on ASM, if there is
no other layer such as NFS underneath ASM. Frits has already alluded to this.
The last time I did a test of this was on 10gR2 many moons ago, when I observed
identical system calls by trussing and dtracing DBWR and foreground processes
(without NFS).
2) There is an associated note - Physical Corrupted Blocks consisting of all
Zeroes indicate a problem with OS, HW or Storage (Doc ID 1545366.1), which may
be of interest to you (if you have not already seen it). Basically, the note
states that corrupted "zeroed out" blocks definitely => an issue in the
underlying OS/storage layer.
3) The reason why I mention the above is that, I have set filesystemio_options
to SETALL in the past 12+ years till date (even on ext4) and have yet to
encounter the issue mentioned in Doc ID - 1487957.1. I hope I have not jinxed
the good run ;) It is quite possible that I have been lucky ALL this time to
not encounter the error, but I think I am leaning on the side of Doc ID -
1545366.1, which clearly indicates that I have worked with some good Sys &
Storage Admins, who got their part done right :)
Having said the above, it is also comforting to note from Doc ID - 1487957.1
that the following Linux releases fixes this "OS/storage layer issue" on ext4:
1) Oracle Linux version - kernel-uek-2.6.39-200.29.3.el6uek
2) RHEL5 - kernel-2.6.18-238.el5 - RHEL5.6 Errata RHSA-2011-0017 or later
3) RHEL6 - kernel-2.6.32-71 or later
Cheers,
Gaja
Gaja Krishna Vaidyanatha,
CEO & Founder, DBPerfMan LLC
http://www.dbperfman.com
http://www.dbcloudman.com
Phone - +1 (650) 743-6060
LinkedIn - http://www.linkedin.com/in/gajakrishnavaidyanatha
Co-author: Oracle Insights:Tales of the Oak Table -
http://www.apress.com/9781590593875
Primary Author: Oracle Performance Tuning 101 - http://www.amzn.com/0072131454
Enabling Exadata, Big Data and Cloud Deployment & Management for Oracle
________________________________
From: "Chitale, Hemant K" <Hemant-K.Chitale@xxxxxx>
To: Mark W. Farnham <mwf@xxxxxxxx>
Cc: ORACLE-L <oracle-l@xxxxxxxxxxxxx>
Sent: Thursday, October 16, 2014 7:19 PM
Subject: RE: Is filesystemio_options relevant when the database is on ASM ?
Is filesystemio_options relevant when the database is on ASM ?
Found Support Note “ORA-1578 ORA-353 ORA-19599 Corrupt blocks with zeros when
filesystemio_options=SETALL on ext4 file system using Linux (Doc ID 1487957.1)”
Hemant K Chitale
From:Mark W. Farnham [mailto:mwf@xxxxxxxx]
Sent: Thursday, October 16, 2014 11:04 PM
To: frits.hoogland@xxxxxxxxx; Chitale, Hemant K
Cc: 'ORACLE-L'
Subject: RE: Is filesystemio_options relevant when the database is on ASM ?
The immediate side question becomes: Can we catalog any situations in which the
‘setall’ setting is suboptimal?
IF there are no known situations where ‘setall’ is harmful, then I believe it
would be wise to set it as standard operating procedure.
IF there are some known situations where ‘setall’ is suboptimal, then the
catalog of exceptions would be gold.
(Setting it when it does no harm operationally being irrelevant beyond a few
microseconds at database restart to parse the parameter.)
mwf
From:oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Frits Hoogland
Sent: Thursday, October 16, 2014 5:35 AM
To: Hemant-K.Chitale@xxxxxx
Cc: ORACLE-L
Subject: Re: Is filesystemio_options relevant when the database is on ASM ?
Hi Hermant,
With version 11 ASM (ASM needs to be available on the node where the database
lives), and when using Exadata, filesystemio_options is NOT relevant to the
database processes when using files (redo, data, temp) on local ASM managed
devices.
I am not sure with version 12, probably the locality between the device and the
ASM instance which it manages is relevant.
When using NFS underneath ASM, I've witnessed filesystemio_options being
honoured by the database, which means it needs setting it to 'setall' for the
combination AIO+DIO. Which makes sense, because you need to create a file on a
(NFS) filesystem to be used as ASM disk device.
Frits Hoogland
http://fritshoogland.wordpress.com
frits.hoogland@xxxxxxxxx
Office : +31 20 5939953
Mobile: +31 6 14180860
On 16 Oct 2014, at 11:25, Chitale, Hemant K <Hemant-K.Chitale@xxxxxx> wrote:
Is filesystemio_options relevant when the database is on ASM ?
Hemant K Chitale
This email and any attachments are confidential and may also be privileged. If
you are not the intended recipient, please delete all copies and notify the
sender immediately. You may wish to refer to the incorporation details of
Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at
https://www.sc.com/en/incorporation-details.html.
This email and any attachments are confidential and may also be privileged. If
you are not the intended recipient, please delete all copies and notify the
sender immediately. You may wish to refer to the incorporation details of
Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at
https://www.sc.com/en/incorporation-details.html.
Other related posts:
