<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	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/"
		>
<channel>
	<title>Comments on: Standby Log Apply Elapsed Time</title>
	<atom:link href="http://www.pythian.com/news/1309/standby-log-apply-elapsed-time/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.pythian.com/news/1309/standby-log-apply-elapsed-time/</link>
	<description>News and views from Pythian DBAs</description>
	<lastBuildDate>Fri, 10 Feb 2012 13:01:25 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: Rich Bernat</title>
		<link>http://www.pythian.com/news/1309/standby-log-apply-elapsed-time/#comment-482133</link>
		<dc:creator>Rich Bernat</dc:creator>
		<pubDate>Wed, 08 Dec 2010 19:26:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1309/standby-log-apply-elapsed-time#comment-482133</guid>
		<description>I too was frustrated by the lack of exposure of the apply rate to the standby.  

I wrote this  script years ago using more common views and extrapolated the necessary information.  

rem Script: get_redo_apply_metrics.sql
rem Reports standby apply rate with lag
rem
set lines 120 pages 60
column SizeM  format 9,999.9
column &quot;MB/sec&quot;  format 9,999.99

select TIMESTAMP,
       completion_time &quot;ArchTime&quot;,
       SEQUENCE#,
       round((blocks*block_size)/(1024*1024),1) &quot;SizeM&quot;,
       round((TIMESTAMP-lag(TIMESTAMP,1,TIMESTAMP) OVER (order by TIMESTAMP))*24*60*60,1) &quot;Diff(sec)
&quot;,
       round((blocks*block_size)/1024/ decode(((TIMESTAMP-lag(TIMESTAMP,1,TIMESTAMP)
              OVER (order by TIMESTAMP))*24*60*60),0,1,
             (TIMESTAMP-lag(TIMESTAMP,1,TIMESTAMP) OVER (order by TIMESTAMP))*24*60*60),1) &quot;KB/sec&quot;,
       round((blocks*block_size)/(1024*1024)/ decode(((TIMESTAMP-lag(TIMESTAMP,1,TIMESTAMP)
              OVER (order by TIMESTAMP))*24*60*60),0,1,
             (TIMESTAMP-lag(TIMESTAMP,1,TIMESTAMP) OVER (order by TIMESTAMP))*24*60*60),3) &quot;MB/sec&quot;,
       round(((lead(TIMESTAMP,1,TIMESTAMP) over (order by TIMESTAMP))-completion_time)*24*60*60,1) &quot;
Lag(sec)&quot;
from v$archived_log a, v$dataguard_status dgs
where a.name = replace(dgs.MESSAGE,&#039;Media Recovery Log &#039;,&#039;&#039;)
      and dgs.FACILITY = &#039;Log Apply Services&#039;
order by TIMESTAMP;</description>
		<content:encoded><![CDATA[<p>I too was frustrated by the lack of exposure of the apply rate to the standby.  </p>
<p>I wrote this  script years ago using more common views and extrapolated the necessary information.  </p>
<p>rem Script: get_redo_apply_metrics.sql<br />
rem Reports standby apply rate with lag<br />
rem<br />
set lines 120 pages 60<br />
column SizeM  format 9,999.9<br />
column &#8220;MB/sec&#8221;  format 9,999.99</p>
<p>select TIMESTAMP,<br />
       completion_time &#8220;ArchTime&#8221;,<br />
       SEQUENCE#,<br />
       round((blocks*block_size)/(1024*1024),1) &#8220;SizeM&#8221;,<br />
       round((TIMESTAMP-lag(TIMESTAMP,1,TIMESTAMP) OVER (order by TIMESTAMP))*24*60*60,1) &#8220;Diff(sec)<br />
&#8220;,<br />
       round((blocks*block_size)/1024/ decode(((TIMESTAMP-lag(TIMESTAMP,1,TIMESTAMP)<br />
              OVER (order by TIMESTAMP))*24*60*60),0,1,<br />
             (TIMESTAMP-lag(TIMESTAMP,1,TIMESTAMP) OVER (order by TIMESTAMP))*24*60*60),1) &#8220;KB/sec&#8221;,<br />
       round((blocks*block_size)/(1024*1024)/ decode(((TIMESTAMP-lag(TIMESTAMP,1,TIMESTAMP)<br />
              OVER (order by TIMESTAMP))*24*60*60),0,1,<br />
             (TIMESTAMP-lag(TIMESTAMP,1,TIMESTAMP) OVER (order by TIMESTAMP))*24*60*60),3) &#8220;MB/sec&#8221;,<br />
       round(((lead(TIMESTAMP,1,TIMESTAMP) over (order by TIMESTAMP))-completion_time)*24*60*60,1) &#8221;<br />
Lag(sec)&#8221;<br />
from v$archived_log a, v$dataguard_status dgs<br />
where a.name = replace(dgs.MESSAGE,&#8217;Media Recovery Log &#8216;,&#8221;)<br />
      and dgs.FACILITY = &#8216;Log Apply Services&#8217;<br />
order by TIMESTAMP;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: pmlx01</title>
		<link>http://www.pythian.com/news/1309/standby-log-apply-elapsed-time/#comment-374872</link>
		<dc:creator>pmlx01</dc:creator>
		<pubDate>Mon, 14 Sep 2009 20:54:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1309/standby-log-apply-elapsed-time#comment-374872</guid>
		<description>great stuff about  x$kcclh.lhtsm. This was info i needed and saved me plenty of time and work parsing alert to get the same data. excellent post.</description>
		<content:encoded><![CDATA[<p>great stuff about  x$kcclh.lhtsm. This was info i needed and saved me plenty of time and work parsing alert to get the same data. excellent post.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Marc Billette</title>
		<link>http://www.pythian.com/news/1309/standby-log-apply-elapsed-time/#comment-361970</link>
		<dc:creator>Marc Billette</dc:creator>
		<pubDate>Fri, 05 Jun 2009 14:43:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1309/standby-log-apply-elapsed-time#comment-361970</guid>
		<description>&quot;oracle dba&quot;, I don&#039;t know if that column is useful on the primary db side. You&#039;d have to do your own observations. I do see that the column is populated on the primary but it&#039;s obviously not for standby log apply. Perhaps the column has double use, and that could explain why it is not exposed in the virtual views...

Note that I&#039;m not clear on what you would like to know about the archivers on the primary database.</description>
		<content:encoded><![CDATA[<p>&#8220;oracle dba&#8221;, I don&#8217;t know if that column is useful on the primary db side. You&#8217;d have to do your own observations. I do see that the column is populated on the primary but it&#8217;s obviously not for standby log apply. Perhaps the column has double use, and that could explain why it is not exposed in the virtual views&#8230;</p>
<p>Note that I&#8217;m not clear on what you would like to know about the archivers on the primary database.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: an oracle dba</title>
		<link>http://www.pythian.com/news/1309/standby-log-apply-elapsed-time/#comment-361951</link>
		<dc:creator>an oracle dba</dc:creator>
		<pubDate>Fri, 05 Jun 2009 08:48:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1309/standby-log-apply-elapsed-time#comment-361951</guid>
		<description>agreed with Jason. ouput may less use in real time apply.

but is it x$kcclh.lhtsm can be used to monitor primary instnace local archiver?</description>
		<content:encoded><![CDATA[<p>agreed with Jason. ouput may less use in real time apply.</p>
<p>but is it x$kcclh.lhtsm can be used to monitor primary instnace local archiver?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Log Buffer #121: a Carnival of the Vanities for DBAs</title>
		<link>http://www.pythian.com/news/1309/standby-log-apply-elapsed-time/#comment-295964</link>
		<dc:creator>Log Buffer #121: a Carnival of the Vanities for DBAs</dc:creator>
		<pubDate>Fri, 31 Oct 2008 16:02:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1309/standby-log-apply-elapsed-time#comment-295964</guid>
		<description>[...] Billette brings some interesting information about how you can monitor the amount of time it takes Oracle to apply logs. Jason Arneil has some very noteworthy work showing how performing an online rebalance of ASM can [...]</description>
		<content:encoded><![CDATA[<p>[...] Billette brings some interesting information about how you can monitor the amount of time it takes Oracle to apply logs. Jason Arneil has some very noteworthy work showing how performing an online rebalance of ASM can [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jason arneil</title>
		<link>http://www.pythian.com/news/1309/standby-log-apply-elapsed-time/#comment-294683</link>
		<dc:creator>jason arneil</dc:creator>
		<pubDate>Mon, 27 Oct 2008 10:12:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1309/standby-log-apply-elapsed-time#comment-294683</guid>
		<description>Interesting stuff, and good spot!

Output may be of less use in real time apply.

jason.</description>
		<content:encoded><![CDATA[<p>Interesting stuff, and good spot!</p>
<p>Output may be of less use in real time apply.</p>
<p>jason.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Asif Momen</title>
		<link>http://www.pythian.com/news/1309/standby-log-apply-elapsed-time/#comment-293908</link>
		<dc:creator>Asif Momen</dc:creator>
		<pubDate>Sat, 25 Oct 2008 10:50:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1309/standby-log-apply-elapsed-time#comment-293908</guid>
		<description>Hi Marc,

Good findings!!!

This will definitely be helpful when monitoring your standby databases. I will save these queries in my favorite one&#039;s. 

I have recently been advocating using Analytic Functions in SQL to make life easier, so thought of re-writing your queries using AF. 

Query 1:
========
select sequence#, fromtime, totime,
       ((to_date(totime,&#039;MM/DD/RR HH24:MI:SS&#039;)
       - to_date(fromtime,&#039;MM/DD/RR HH24:MI:SS&#039;)) * 1440) minutes_to_apply
  from (select lhseq sequence#, lhtsm fromtime,
               lead(lhtsm) over (order by lhseq) totime
          from sys.x$kcclh)
 order by sequence#


Query 2:
========
select min(lhlot) min_log_date, max(lhlot) max_log_date,
       numtodsinterval(max(to_number(a_lhtsm - b_lhtsm)),&#039;DAY&#039;) max_log_apply_duration,
       numtodsinterval(min(to_number(a_lhtsm - b_lhtsm)),&#039;DAY&#039;) min_log_apply_duration,
       numtodsinterval(avg(to_number(a_lhtsm - b_lhtsm)),&#039;DAY&#039;) avg_log_apply_duration
  from (      select lhlot lhlot,
             to_date(lhtsm,&#039;MM/DD/RR HH24:MI:SS&#039;) a_lhtsm,
             to_date(lag(lhtsm) over (order by lhrid),&#039;MM/DD/RR HH24:MI:SS&#039;) b_lhtsm,
             lhrid
        from sys.x$kcclh )
 order by lhrid;

Query 3:
========
select sequence#, fromtime, totime,
       ((to_date(totime,&#039;MM/DD/RR HH24:MI:SS&#039;)
       - to_date(fromtime,&#039;MM/DD/RR HH24:MI:SS&#039;)) * 1440) minutes_to_apply
  from (select lhseq sequence#, lhtsm totime,
               lag(lhtsm) over (order by lhseq) fromtime
          from sys.x$kcclh)
  where to_date(fromtime,&#039;MM/DD/RR HH24:MI:SS&#039;) &gt; sysdate - 60
   and  ((to_date(totime,&#039;MM/DD/RR HH24:MI:SS&#039;) -
          to_date(fromtime,&#039;MM/DD/RR HH24:MI:SS&#039;)) * 1440) &gt; 30
 order by sequence#;



Thanks again Marc for the findings.

Regards

Asif Momen
http://momendba.blogspot.com</description>
		<content:encoded><![CDATA[<p>Hi Marc,</p>
<p>Good findings!!!</p>
<p>This will definitely be helpful when monitoring your standby databases. I will save these queries in my favorite one&#8217;s. </p>
<p>I have recently been advocating using Analytic Functions in SQL to make life easier, so thought of re-writing your queries using AF. </p>
<p>Query 1:<br />
========<br />
select sequence#, fromtime, totime,<br />
       ((to_date(totime,&#8217;MM/DD/RR HH24:MI:SS&#8217;)<br />
       &#8211; to_date(fromtime,&#8217;MM/DD/RR HH24:MI:SS&#8217;)) * 1440) minutes_to_apply<br />
  from (select lhseq sequence#, lhtsm fromtime,<br />
               lead(lhtsm) over (order by lhseq) totime<br />
          from sys.x$kcclh)<br />
 order by sequence#</p>
<p>Query 2:<br />
========<br />
select min(lhlot) min_log_date, max(lhlot) max_log_date,<br />
       numtodsinterval(max(to_number(a_lhtsm &#8211; b_lhtsm)),&#8217;DAY&#8217;) max_log_apply_duration,<br />
       numtodsinterval(min(to_number(a_lhtsm &#8211; b_lhtsm)),&#8217;DAY&#8217;) min_log_apply_duration,<br />
       numtodsinterval(avg(to_number(a_lhtsm &#8211; b_lhtsm)),&#8217;DAY&#8217;) avg_log_apply_duration<br />
  from (      select lhlot lhlot,<br />
             to_date(lhtsm,&#8217;MM/DD/RR HH24:MI:SS&#8217;) a_lhtsm,<br />
             to_date(lag(lhtsm) over (order by lhrid),&#8217;MM/DD/RR HH24:MI:SS&#8217;) b_lhtsm,<br />
             lhrid<br />
        from sys.x$kcclh )<br />
 order by lhrid;</p>
<p>Query 3:<br />
========<br />
select sequence#, fromtime, totime,<br />
       ((to_date(totime,&#8217;MM/DD/RR HH24:MI:SS&#8217;)<br />
       &#8211; to_date(fromtime,&#8217;MM/DD/RR HH24:MI:SS&#8217;)) * 1440) minutes_to_apply<br />
  from (select lhseq sequence#, lhtsm totime,<br />
               lag(lhtsm) over (order by lhseq) fromtime<br />
          from sys.x$kcclh)<br />
  where to_date(fromtime,&#8217;MM/DD/RR HH24:MI:SS&#8217;) &gt; sysdate &#8211; 60<br />
   and  ((to_date(totime,&#8217;MM/DD/RR HH24:MI:SS&#8217;) -<br />
          to_date(fromtime,&#8217;MM/DD/RR HH24:MI:SS&#8217;)) * 1440) &gt; 30<br />
 order by sequence#;</p>
<p>Thanks again Marc for the findings.</p>
<p>Regards</p>
<p>Asif Momen<br />
<a href="http://momendba.blogspot.com" rel="nofollow">http://momendba.blogspot.com</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>

