Return-Path: Delivered-To: 2-oracle-l@orafaq.com Received: (qmail 8641 invoked from network); 9 Sep 2008 02:55:07 -0500 Received: from freelists-180.iquest.net (HELO turing.freelists.org) (206.53.239.180) by 69.64.49.119 with SMTP; 9 Sep 2008 02:55:03 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 858D893EC9F; Tue, 9 Sep 2008 03:55:00 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05719-03; Tue, 9 Sep 2008 03:55:00 -0400 (EDT) Received: from turing.freelists.org (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 0098693EC96; Tue, 9 Sep 2008 03:54:59 -0400 (EDT) Received: with ECARTIS (v1.0.0; list oracle-l); Tue, 09 Sep 2008 03:53:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id CDC7693EB6F for ; Tue, 9 Sep 2008 03:53:02 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05157-03 for ; Tue, 9 Sep 2008 03:53:02 -0400 (EDT) Received: from troll.tpk.net (troll.tpk.net [216.107.198.11]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 0110E93EB75 for ; Tue, 9 Sep 2008 03:53:01 -0400 (EDT) Received: from MWF600XL (216-107-223-2.RightSizing.tpk.static.cust.seg.net [216.107.223.2]) by troll.tpk.net (8.14.2/8.12.11) with ESMTP id m897quwb010388; Tue, 9 Sep 2008 03:53:00 -0400 From: "Mark W. Farnham" To: , References: <809219.91656.qm@web52809.mail.re2.yahoo.com> Subject: RE: Measuring the impact of Redo Log change Date: Tue, 9 Sep 2008 03:53:06 -0400 Message-ID: <5F733AC8370C4E56A0FAFE2DDCC77078@rsiz.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_040F_01C9122F.91FE6120" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-reply-to: <809219.91656.qm@web52809.mail.re2.yahoo.com> X-archive-position: 10687 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: mwf@rsiz.com Precedence: normal Reply-to: mwf@rsiz.com List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-subscribe: List-owner: List-post: List-archive: X-list: oracle-l X-Virus-Scanned: Debian amavisd-new at localhost.localdomain ------=_NextPart_000_040F_01C9122F.91FE6120 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit When you want to measure the affects of a change, it really helps to decide what metrics to track and to get a "before the change" set of values before you make the change. Now it might turn out you have coincidentally accumulated some metrics that will be useful. If you have some recurring batch jobs with start and end times and volume of transactions recorded, that could be useful if those jobs were running against reasonably similar competitive loads previously. You can get an idea of the "before" throughput variability by charting #transactions/unit time. If the variability of "before" transactions is high, find some other metric, unless the variability is driven by outliers related to a known cause. (For example some job might run much slower against a full backup every Saturday night, but runs within a small throughput range all other days.) If you have a particular job or application that was previously experiencing delays due to writing redo logs, is it faster now? If you were not previously experiencing delays due to writing and archiving redologs, then you should not expect large differences in behavior under the same load. That comes under the heading of having fixed a problem you didn't have. Now that might not be all bad, because you probably did increase your peak throughput capacity by reducing the service time of flushing the log buffer and archiving. If you were previously experiencing delays due to writing and archiving redologs then performance should improve. Reductions in waits plus improvements in service times are part of the picture (and essentially the whole picture if you're trying to solve a particular problem), but if your redologs are intermingled with other actual i/o on your disk farm and you were pushing your throughput capacity, you may discover that things are now faster across the board. Measuring it after the fact without a before set of values is not going to be easy. Likewise, if this change was a forward looking attempt to increase maximum throughput, you might not notice any change right now. Upgrading from standard (US) 80 inch high doors to 88 inch doors is not something I notice much. But if you expect Kareem Abdul Jabbar to become a frequent visitor they would be nice. (Hmm, maybe I should have updated that to Shaq for you youngsters.) Regards, mwf _____ From: oracle-l-bounce@freelists.org [mailto:oracle-l-bounce@freelists.org] On Behalf Of Deepak Sharma Sent: Tuesday, September 09, 2008 12:33 AM To: oracle-l@freelists.org Subject: Measuring the impact of Redo Log change We recently (today) moved the redo logs from RAID5 to RAID1+0. The obvious reason of doing this is to make things better in terms of performance, as RAID1+0 is better suited for read/writes. Someone pls correct me if that's not true. What are different ways to measure the impact of this change? The platform is AIX, DB is 10.2.0.3 and DB size is 55TB, and 2TB redo is generated each day. There are plans underway to reduce the redo generation using direct path etc. (so let's not get diverted by that). We can try measuring the wait event stats using AWR, session stats etc., but what exactly to look for? 'log file switch completion', 'log file sync', are some things that come to mind - what else? Thanks, Deepak ------=_NextPart_000_040F_01C9122F.91FE6120 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

When you want to measure the = affects of a change, it really helps to decide what metrics to track and to get a = “before the change” set of values before you make the change. Now it might = turn out you have coincidentally accumulated some metrics that will be = useful.

 

If you have some recurring batch = jobs with start and end times and volume of transactions recorded, that could be = useful if those jobs were running against reasonably similar competitive loads previously. You can get an idea of the “before” throughput variability by charting #transactions/unit time. If the variability of = “before” transactions is high, find some other metric, unless the variability is = driven by outliers related to a known cause. (For example some job might run = much slower against a full backup every Saturday night, but runs within a = small throughput range all other days.)

 

If you have a particular job or application that was previously experiencing delays due to writing redo = logs, is it faster now?

 

If you were not previously = experiencing delays due to writing and archiving redologs, then you should not expect = large differences in behavior under the same load. That comes under the = heading of having fixed a problem you didn’t have. Now that might not be all = bad, because you probably did increase your peak throughput capacity by = reducing the service time of flushing the log buffer and archiving. If you were = previously experiencing delays due to writing and archiving redologs then = performance should improve. Reductions in waits plus improvements in service times = are part of the picture (and essentially the whole picture if you’re trying = to solve a particular problem), but if your redologs are intermingled with = other actual i/o on your disk farm and you were pushing your throughput = capacity, you may discover that things are now faster across the board. Measuring it = after the fact without a before set of values is not going to be = easy.

 

Likewise, if this change was a = forward looking attempt to increase maximum throughput, you might not notice any = change right now. Upgrading from standard (US) 80 inch high doors to 88 inch = doors is not something I notice much. But if you expect Kareem Abdul Jabbar to = become a frequent visitor they would be nice. (Hmm, maybe I should have updated = that to Shaq for you youngsters.)

 

Regards,

 

mwf

 

 

 

From: oracle-l-bounce@freelists.org [mailto:oracle-l-bounce@freelists.org] = On Behalf Of Deepak Sharma
Sent: Tuesday, September = 09, 2008 12:33 AM
To: = oracle-l@freelists.org
Subject: Measuring the = impact of Redo Log change

 

We recently (today) = moved the redo logs from RAID5 to RAID1+0.

The obvious reason of doing this is to make things better in terms of performance, as RAID1+0 is better suited for read/writes. Someone pls = correct me if that's not true.

What are different ways to measure the impact of this change?

The platform is AIX, DB is 10.2.0.3 and DB size is 55TB, and 2TB redo is generated each day. There are plans underway to reduce the redo = generation using direct path etc. (so let's not get diverted by that).

We can try measuring the wait event stats using AWR, session stats etc., = but what exactly to look for?  'log file switch completion', 'log file = sync', are some things that come to mind - what else?

Thanks,
Deepak

 

------=_NextPart_000_040F_01C9122F.91FE6120-- -- http://www.freelists.org/webpage/oracle-l