<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Oracle - Concepts et Exemples &#187; result_cache</title>
	<atom:link href="https://blog.developpez.com/pachot/tag/result_cache/feed/" rel="self" type="application/rss+xml" />
	<link>https://blog.developpez.com/pachot</link>
	<description>Les fonctionalités et concepts d&#039;Oracle à partir de traductions et de démos</description>
	<lastBuildDate>Sun, 03 Apr 2016 20:36:21 +0000</lastBuildDate>
	<language>fr-FR</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>https://wordpress.org/?v=4.1.42</generator>
	<item>
		<title>Contention sur Result Cache en accès concurrent</title>
		<link>https://blog.developpez.com/pachot/result_cache_scalability/</link>
		<comments>https://blog.developpez.com/pachot/result_cache_scalability/#comments</comments>
		<pubDate>Tue, 16 Jul 2013 06:00:41 +0000</pubDate>
		<dc:creator><![CDATA[pachot]]></dc:creator>
				<category><![CDATA[MicroLearning]]></category>
		<category><![CDATA[result_cache]]></category>

		<guid isPermaLink="false">http://blog.developpez.com/pachot/?p=513</guid>
		<description><![CDATA[Le Result Cache peut amener facilement un gain de performance énorme s&#8217;il est bien utilisé: si l&#8217;appli fait souvent la même requête avec les mêmes paramètres, il peut suffire de mettre RESULT_CACHE dans la requête ou la fonction pour optimiser &#8230; <a href="https://blog.developpez.com/pachot/result_cache_scalability/">Lire la suite <span class="meta-nav">&#8594;</span></a>]]></description>
				<content:encoded><![CDATA[<p>Le Result Cache peut amener facilement un gain de performance énorme s&rsquo;il est bien utilisé: si l&rsquo;appli fait souvent la même requête avec les mêmes paramètres, il peut suffire de mettre RESULT_CACHE dans la requête ou la fonction pour optimiser cela. C&rsquo;est beaucoup plus rapide à mettre en oeuvre que de créer un cache au niveau de l&rsquo;appli, gérer son invalidation, etc.</p>
<p>Mais ce cache n&rsquo;est pas aussi optimisé que le Buffer Cache, et on peut amener une autre contention lorsque beaucoup de sessions concurrents y accèdent.<br />
Et la raison, c&rsquo;est qu&rsquo;il n&rsquo;y a qu&rsquo;un seul Latch pour gérer le result cache de l&rsquo;instance. Le symptôme, c&rsquo;est une attente sur &lsquo;enq: RC &#8211; Result Cache: Contention&rsquo;</p>
<p><ins datetime="2013-07-06T17:23:22+00:00">L&rsquo;analyse complète de cette contention dans la <a href="http://ora-demo.pachot.net/result_cache_scalability.html" title="demo" target="_blank">demo</a>.</ins></p>
<p>Le cas le pire: utiliser result_cache avec beaucoup de valeurs différentes, ou lorsque le cache est invalidé souvent. A chaque fois qu&rsquo;il y a un &lsquo;cache miss&rsquo; c&rsquo;est plusieurs latch exclusifs qui doivent être acquis. </p>
<p>Sur des données statiques, c&rsquo;est moins grave car le latch n&rsquo;est pas exclusif sur un &lsquo;cache hit&rsquo;. Attention: seulement depuis 11gR2. En 11gR1, c&rsquo;était toujours exclusif. </p>
<p>Donc le Use Case idéal pour Result Cache, c&rsquo;est plutôt des données statiques (référentiel) accédées souvent &#8211; mais pas accédées tout le temps par toutes les sessions !</p>
]]></content:encoded>
			<wfw:commentRss></wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
