Return-Path: <oracle-l-bounce@freelists.org>
Delivered-To: 2-oracle-l@orafaq.com
Received: (qmail 25658 invoked from network); 7 Jul 2006 13:43:32 -0500
Received: from freelists-180.iquest.net (HELO turing.freelists.org) (206.53.239.180)
  by 69.64.49.119 with SMTP; 7 Jul 2006 13:43:31 -0500
Received: from localhost (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id AAC6D393913;
 Fri,  7 Jul 2006 14:43:24 -0400 (EDT)
Received: from turing.freelists.org ([127.0.0.1])
 by localhost (turing [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 02394-10; Fri, 7 Jul 2006 14:43:24 -0400 (EDT)
Received: from turing (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 268A53937AF;
 Fri,  7 Jul 2006 14:43:24 -0400 (EDT)
Received: with ECARTIS (v1.0.0; list oracle-l); Fri, 07 Jul 2006 14:42:35 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id DEB1D393A86
 for <oracle-l@freelists.org>; Fri,  7 Jul 2006 14:42:34 -0400 (EDT)
Received: from turing.freelists.org ([127.0.0.1])
 by localhost (turing [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 02020-10 for <oracle-l@freelists.org>;
 Fri, 7 Jul 2006 14:42:34 -0400 (EDT)
Received: from NT15.oneneck.corp (dot092host.oneneck.net [63.226.42.92])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 8E673393791
 for <oracle-l@freelists.org>; Fri,  7 Jul 2006 14:42:34 -0400 (EDT)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663
Priority: normal
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A1F5.435972C4"
Subject: RE: Lengthening backup
Date: Fri, 7 Jul 2006 11:43:39 -0700
Message-ID: <04DDF147ED3A0D42B48A48A18D574C45059E1A4D@NT15.oneneck.corp>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Lengthening backup
thread-index: Acah8hEppILUM+BjT+K4Zhgtfjv8twAAt/Hw
From: "Allen, Brandon" <Brandon.Allen@OneNeck.com>
To: <terrysutton@usa.net>,
 <oracle-l@freelists.org>
X-archive-position: 36838
X-ecartis-version: Ecartis v1.0.0
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
X-original-sender: Brandon.Allen@OneNeck.com
Precedence: normal
Reply-to: Brandon.Allen@OneNeck.com
X-list: oracle-l
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at avenirtech.net
------_=_NextPart_001_01C6A1F5.435972C4
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The only thing I can think of that would cause such behaviour is if for
some reason you were actually running a cumulative incremental backup.
From the script you've shown, that doesn't appear to be the case, but
could you check the incremental_level of the rc_backup_set view in your
recovery catalog and verify?

________________________________

From: oracle-l-bounce@freelists.org
[mailto:oracle-l-bounce@freelists.org] On Behalf Of Terry Sutton


I'm having some issues with a client's RMAN backup.  They're on Oracle
8.1.7.4, Solaris 8.  It's a weekly full backup, and they're backing up
~1.5TB to disk, and the longer the instance is up, the longer the backup
takes.=20

Privileged/Confidential Information may be contained in this message or =
attachments hereto. Please advise immediately if you or your employer do =
not consent to Internet email for messages of this kind. Opinions, =
conclusions and other information in this message that do not relate to =
the official business of this company shall be understood as neither =
given nor endorsed by it.


------_=_NextPart_001_01C6A1F5.435972C4
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1555" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D354214118-07072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>The only thing I can think of that would cause =
such=20
behaviour is if for some reason you were actually running a cumulative=20
incremental backup.&nbsp; From the script you've shown, that doesn't =
appear to=20
be the case, but could you check the incremental_level of the =
rc_backup_set view=20
in your recovery catalog and verify?</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> oracle-l-bounce@freelists.org=20
[mailto:oracle-l-bounce@freelists.org] <B>On Behalf Of </B>Terry=20
Sutton<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><FONT face=3DArial size=3D2>I'm having some issues with a client's =
RMAN=20
backup.&nbsp; They're on Oracle 8.1.7.4, Solaris 8.&nbsp; It's a weekly =
full=20
backup, and they're backing up ~1.5TB to disk, and the longer the =
instance is=20
up, the longer the backup =
takes.&nbsp;</FONT></DIV></BODY><!--[object_id=3D#oneneck.com#]--><FONT =
face=3DTahoma size=3D2><FONT color=3D#0000ff>
<P>Privileged/Confidential Information may be contained in this message =
or attachments hereto. Please advise immediately if you or your employer =
do not consent to Internet email for messages of this kind. Opinions, =
conclusions and other information in this message that do not relate to =
the official business of this company shall be understood as neither =
given nor endorsed by it.</P></FONT></FONT></HTML>

------_=_NextPart_001_01C6A1F5.435972C4--
--
http://www.freelists.org/webpage/oracle-l


