Re: Multipath Config --> Question on no_path_retry N

From: Ls Cheng <exriscer_at_gmail.com>
Date: Wed, 20 Jul 2016 20:27:12 +0200
Message-ID: <CAJ2-Qb86f7JW9bkxQ9JQe6Vo091UxEniLAT09r-o1Ca6KXApxg_at_mail.gmail.com>



Shouldnt that be 0?

There is something similar in AIX, by default PATH fail hangs for 10 minutes and in a Cluster (RAC) it must set to fast fail (forces immediate failover) which is similar to 0 in queue_if_no_path

On Wed, Jul 20, 2016 at 8:18 PM, Chad Cleveland <Chad.Cleveland_at_datavail.com
> wrote:

> Hi Friends!
>
>
>
> Trying to prevent another snafu.
>
>
>
> We had a lun (not a CRS lun) go offline that was attached to one data disk
> group, used by only one database. The issue was on the storage side and we
> lost access to that LUN. This caused our entire cluster to offline. Both
> Nodes, all crs services, and all databases.
>
> While working with our sys admin, they told us we're setting parameter
> queue_if_no_path and that makes all luns queue up if one goes offline. This
> seems to go against the concept of maximum availability architecture.
> Oracle Enterprise Linux with Oracle 12c clusterware and databases…so I’d
> think this shouldn't be happening.
>
> Setting parameter no_path_retry will override queue_if_no_path, so we’re
> investigating this route.
>
>
>
> Do you have any information or actual implementation of this setting?
> We’re trying to determine the “no_path_retry N” we should set to make sure
> ASM can tolerate hung condition for some LUNs?
>
> How many more years and how many more unplanned outages we will face with
> that parameter to get to most optimum value of “N”?
>
>
>
> Oracle support hasn’t been very helpful in this matter. Ultimately, they
> said it was a parameter that needs to be determined by the storage vendor.
> Incidentally, were onsite with Oracle and they (both) provided the initial
> setting to us in agreement.
>
>
>
> Thanks!
>
> Chad Cleveland
>
>
> This email (including any attachments) is for the use of the intended
> recipient(s) only. If you have received this email in error, please notify
> the sender immediately and then delete it. If you are not the intended
> recipient, you must not keep, use, disclose, copy or distribute this email
> without the author's prior permission.
>

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Jul 20 2016 - 20:27:12 CEST

Original text of this message