Re: Unknown Exadata Cell Parameter - "_cell_fc_toresilver_limit_chdrs"

From: Osman DINC <dinch.osman_at_gmail.com>
Date: Fri, 15 Dec 2023 15:15:53 +0300
Message-ID: <CAOW9pnTTG+7xt8mkHELWJZTojMM8gy9JytU61QKTiZvBmOMwqA_at_mail.gmail.com>



Hi Mark,

Thanks for your valuable feedback. Its(_cell_fc_toresilver_limit_chdrs) default value is 390000.

Please correct me if i got you wrong, I interpret changing it to 6000000 as increasing the change directives required to start resilvering as 15 times more, thus Resilvering will occur 15 times less frequently. Less resilvering means less Internal IO.

But what can be the trade off of decreasing resilvering frequency? As far as i know, resilvering should occur in situations like flash card change, a bad mirror detection on scrubbing. On standard daily activities, there should be no resilvering operation.

Thanks. Regards.

Osman DİNÇ

Mark W. Farnham <mwf_at_rsiz.com>, 15 Ara 2023 Cum, 02:16 tarihinde şunu yazdı:

> I don’t have any documentation on that, but reading the alphacrypt, I’d
> say that if you have a bad “plex” (that is old school called a mirror, as
> in image, even though it doggone well better not be reversed), and oracle
> is rebuilding it from one or two other still valid images, this is some
> limit at the cell and fiber channel? level of the rates from change
> directives? to process.
>
>
>
> It could be something entirely different, but that matches your comment.
> Unless you have something being rebuilt at the media image level, this
> shouldn’t matter (if I have the meaning anything like correct.)
>
>
>
> The old notion was that if someone shut Oracle down to rebuild plexes on
> the physical media, then it was pedal to the metal. But if you were up and
> running (with either two or one remaining good plexes), then Oracle would
> be rebuilding the broken plexes but not be piggy and starve the users for
> i/o.
>
>
>
> I could be completely wrong.
>
>
>
> mwf
>
>
>
> *From:* oracle-l-bounce_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *Laurentiu Oprea
> *Sent:* Thursday, December 14, 2023 4:55 PM
> *To:* dinch.osman_at_gmail.com
> *Cc:* ORACLE-L (oracle-l_at_freelists.org)
> *Subject:* Re: Unknown Exadata Cell Parameter -
> "_cell_fc_toresilver_limit_chdrs"
>
>
>
> Out of curiosity, did you tried to measure the performance (defined as
> duration) of a set queries with and without this parameter set?
>
>
>
> Thanks
>
>
>
> On Thu, Dec 14, 2023, 22:22 Osman DINC <dinch.osman_at_gmail.com> wrote:
>
> Hi all Oracle enthusiasts,
>
>
>
> Do you have any information about the "_cell_fc_toresilver_limit_chdrs"
> parameter?
>
> It is set on my environment (X7-2) cellinit.ora. It is an undocumented and
> non-default configuration.
>
>
>
> I could not find any information about it, but it is commented as "It is
> set to reduce Internal IO on exadata cells". We do not have prior knowledge
> about it.
>
>
>
> Also I have screenshots of *AWR reports - Exadata Statistics - Top IO
> Reasons by MB * section.
>
> (Before and after parameter change)
>
>
>
> Before _cell_fc_toresilver_limit_chdrs parameter is set:
>
>
> https://drive.google.com/file/d/1PEcjUYAuG8SNTq1vfXLl0fyoeoffSLhq/view?usp=drive_link
>
>
>
> After "_cell_fc_toresilver_limit_chdrs"=6000000
>
>
> https://drive.google.com/file/d/12tDsDvt22oFyEaQtRdMsXcCYduw9992A/view?usp=drive_link
>
>
>
> According to the screenshots, It reduces Internal IO done by storage
> servers dramatically, but there may be a trade-off which i do not know.
>
>
>
> I want to clear this parameter as it is a non-default configuration. It
> was set on image version 20.1.5.0.0.201209 and it has been retained for
> years.
>
>
>
> Exadata image version is 22.1.17 now.
>
> If anybody can share more information about what this parameter does, I
> will be glad.
>
>
>
>
>
> Regards,
>
> Osman DİNÇ.
>
>
>
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Dec 15 2023 - 13:15:53 CET

Original text of this message