Received: (qmail 16368 invoked from network); 7 Jul 2009 12:44:56 -0500 Received: from freelists-180.iquest.net (HELO turing.freelists.org) (206.53.239.180) by static-ip-85-25-126-90.inaddr.intergenia.de with SMTP; 7 Jul 2009 12:44:53 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id B45DFC7ED3C; Tue, 7 Jul 2009 13:44:51 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at localhost.localdomain 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 Yf8yafzq7Van; Tue, 7 Jul 2009 13:44:51 -0400 (EDT) Received: from turing.freelists.org (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 119C3C7ED3D; Tue, 7 Jul 2009 13:44:51 -0400 (EDT) Received: with ECARTIS (v1.0.0; list oracle-l); Tue, 07 Jul 2009 13:42:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 51377C7E9CA for ; Tue, 7 Jul 2009 13:42:34 -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 6+5laj9rWesa for ; Tue, 7 Jul 2009 13:42:34 -0400 (EDT) Received: from mail-fx0-f211.google.com (mail-fx0-f211.google.com [209.85.220.211]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id BDA27C7E8BC for ; Tue, 7 Jul 2009 13:42:33 -0400 (EDT) Received: by fxm7 with SMTP id 7so4428922fxm.34 for ; Tue, 07 Jul 2009 10:42:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=szQVWlVKuPbNX71PEeqBr/cYbB+CNUT51Jz1zL/axx0=; b=Ih/MLl1GgLWqNi45bUVp7y22IDvaQi+NWo+/dayAW85iByuvXjEHSui3HYEKeMzDvD /1epmgAKeQ19s4ubwwILoFWECOpYXY3vYZVEX+lzfwvamlXqAauUQrilcmF4I45IXidH tpzT4sQkmB40NYqtZbtoR0y5HwkDUhqODS448= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nU2Y1rzWbLJ9kp2/zWEFalOA/3EiHvWhundgjhNwsxZh2nZxmtO2VpdJqLZlM30Y/P UY9rxbliEAEBl5vFehHeObfNWcJiRQeoAPgR0c+9cDaJU+/EcLs3IIH5Y9LMQf+schLt W62RRgZG1/+9uqO6mtt5YWwQUGD3yDQWw79s4= MIME-Version: 1.0 Received: by 10.223.110.211 with SMTP id o19mr2988947fap.57.1246988552322; Tue, 07 Jul 2009 10:42:32 -0700 (PDT) In-Reply-To: References: <4A537289.2090102@lanl.gov> <582568.13479.qm@web58704.mail.re1.yahoo.com> <6AFC12B9BFCDEA45B7274C534738067F1A9A5716@AAPQMAILBX02V.proque.st> Date: Tue, 7 Jul 2009 12:42:32 -0500 Message-ID: Subject: Re: archivelog performance issues From: Andrew Kerber To: rac_oracledba@msn.com Cc: oracle-l@freelists.org Content-Type: multipart/alternative; boundary=001636c5bb13b33e29046e212585 X-archive-position: 19152 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: andrew.kerber@gmail.com Precedence: normal Reply-to: andrew.kerber@gmail.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 --001636c5bb13b33e29046e212585 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Uh, Yes. If you are not in archive log mode, the redo log is not copied to the archivelog, so there is no overhead on the switch. When you are not in archive log mode, you just switch to the next redo log and keep going, overwriting what was in the log previously. On Tue, Jul 7, 2009 at 12:23 PM, Richard Croasmun wrote: > > On Tue, 7 Jul 2009 12:31:43 -0400 Mark.Bobak@proquest.com wrote: > > > Some things to check before you switch to archive log mode: > > > > - How frequently are you seeing log switches, at peak > load time? > > > > Size your online redo so that you get a switch about every > 15-30 minutes, at peak. > > If your load variaes greatly from peak to non-peak, you > may want to use > > archive_lag_target to get more frequent switches during > off-peak times. > > > > - Make sure you have at least three redo log groups. > > > > I agree 100% with those that state log archive mode should be based on > recoverability, not performance. In addition, from a performance point of > view, it seems to me that the only additional overhead is a copy of the > online redo log to an archive log for each log switch. I would say that all > the points about log size, frequency of log switches, number of online logs > etc would apply even when the DB is NOT in archive log mode. The only > exception would be having enough online logs (or large enough logs) such > that the copy of a particular log finishes before the database wants to use > that online redo log again. Obviously, if the DB is in archive log mode, > the overhead of the copy on the DB could be reduced by placing the archive > logs on separate disks from the database and online logs to minimize I/O > contention. An last, but not least, don't let the archive log area fill > up!! ;-) Am I missing anything here? > > > > Rick > > > > -- Andrew W. Kerber 'If at first you dont succeed, dont take up skydiving.' --001636c5bb13b33e29046e212585 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Uh, Yes.=A0 If you are not in archive log mode, the redo log is not copied = to the archivelog, so there is no overhead on the switch.=A0 When you are n= ot in archive log mode, you just switch to the next redo log and keep going= , overwriting what was in the log previously.

On Tue, Jul 7, 2009 at 12:23 PM, Richard Cro= asmun <rac_or= acledba@msn.com> wrote:

On Tue, 7 Jul 2009 12:31:43 -0400 Mark.Bobak@proquest.com wrote:
=A0

=A0=A0=A0=A0 S= ome things to check before you switch to archive log mode:

=A0

-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 How frequently are you seeing log switches, at peak load time= ?=A0

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Size your online redo so that you get a switch about every = 15-30 minutes, at peak.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 If you= r load variaes greatly from peak to non-peak, you may want to use

=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0= =A0=A0=A0=A0 archive_lag_target to get more frequent switches during off-pe= ak times.

=A0

-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Make sure you have at least three redo log groups.

=A0

I agree 100% with those that state log archiv= e mode should be based on recoverability, not performance.=A0 In addition, = from a performance=A0point of view, it seems to me that the only additional= overhead is a copy of the online redo log to an archive log for each log s= witch.=A0 I would say that all the points about log size, frequency of log = switches, number of online logs etc=A0would apply=A0even when the DB is NOT= in archive log mode.=A0 The only exception would be having en= ough online logs (or large enough logs) such that the copy of a particular = log finishes before the database wants to use that online redo log again.= =A0 Obviously, if=A0the DB is in archive log mode, the overhead of the copy= on the DB could be reduced by placing the archive logs on separate disks f= rom the database and online logs to minimize I/O contention. An last, but n= ot least, don't let the archive log area fill up!!=A0 ;-)=A0 Am I missi= ng anything=A0here?

=A0

Rick


=A0



--
Andrew W. Kerber
'If at first you dont succeed, dont take up skydiving.'
--001636c5bb13b33e29046e212585-- -- http://www.freelists.org/webpage/oracle-l