Re: Solved: Exacheck reports "FAIL Storage Server Check Exadata Smart Flash Cache should be actually used"

From: Svetoslav Gyurov <softice_at_gmail.com>
Date: Tue, 17 Nov 2015 15:47:56 +0000
Message-ID: <CAKA5Cb+yatVfRT3TTxprsfJQndrnquvkcreMkd7+yKHZzeueeQ_at_mail.gmail.com>



Yong, Oracle released a similar note today: Oracle Data Files should not be placed on the +RECO ASM diskgroup (Doc ID 2074156.1)

If you upgrade from ESS less than 11.2.3.2.0 the cachingPolicy for RECO diskgroup will be changed from default to none but should be kept default for DATA.

On Tue, Nov 17, 2015 at 3:34 PM, Yong Huang <dmarc-noreply_at_freelists.org> wrote:

> Three weeks ago I reported the titled problem. It was later found that the
> grid disk caching policy was set to 'none'. After changing it to 'default'
> caching policy, caching statistics started to show non-zero values:
>
> CellCLI> alter griddisk DATA_CD_00_dmp2cel03 cachingPolicy="default";
> GridDisk DATA_CD_00_dmp2cel03 successfully altered
>
> CellCLI> list griddisk DATA_CD_00_dmp2cel03 detail
> ...
> cachingPolicy: default
> ...
>
> CellCLI> list metriccurrent fc_by_used
> FC_BY_USED FLASHCACHE 6,690 MB
>
> On the compute node:
>
> SQL> select * from gv$sysstat where name like '%cache%' and value > 0;
>
> INST_ID STATISTIC# NAME CLASS VALUE
> STAT_ID
> ------- ---------- ------------------------------------ ----- ----------
> ----------
> 1 58 cell writes to flash cache 8 21525
> 337656778 <-- before the change, only this stat was non-zero, contributed
> by LGWR only
> 1 59 cell overwrites in flash cache 8 3849
> 2368027758
> 1 60 cell partial writes in flash cache 8 166
> 1870362912
> 1 85 db block gets from cache 8 2848734343
> 4017839461
> ...
>
> Oracle Support helped identify the cause of the problem. But we don't know
> why the default for us becomes 'none' instead of 'default', even after
> dropping and recreating the flashcache as instructed.
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Nov 17 2015 - 16:47:56 CET

Original text of this message