Return-Path: Delivered-To: 2-oracle-l@orafaq.com Received: (qmail 27687 invoked from network); 7 Jul 2006 14:02:22 -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 14:02:15 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 22BE139431F; Fri, 7 Jul 2006 15:02:06 -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 06520-04; Fri, 7 Jul 2006 15:02:06 -0400 (EDT) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 946F13942E2; Fri, 7 Jul 2006 15:02:05 -0400 (EDT) Received: with ECARTIS (v1.0.0; list oracle-l); Fri, 07 Jul 2006 15:01:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 3EE79394160 for ; Fri, 7 Jul 2006 15:01:17 -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 06251-06 for ; Fri, 7 Jul 2006 15:01:17 -0400 (EDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 5ADBD393E45 for ; Fri, 7 Jul 2006 15:01:16 -0400 (EDT) Received: from [66.245.59.9] (helo=TerrySutton) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FyvZp-0007ZG-OT for oracle-l@freelists.org; Fri, 07 Jul 2006 15:01:22 -0400 Message-ID: <208401c6a1f7$bcae6e60$6500a8c0@TerrySutton> From: "Terry Sutton" To: References: <04DDF147ED3A0D42B48A48A18D574C45059E1A4D@NT15.oneneck.corp> Subject: Re: Lengthening backup Date: Fri, 7 Jul 2006 12:01:16 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_2081_01C6A1BD.0CE56950" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-ELNK-Trace: 5830af7b3b91928f1aa676d7e74259b7b3291a7d08dfec793ab05bc4756c71241e67b55bce9a3378350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.245.59.9 X-archive-position: 36839 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: terrysutton@usa.net Precedence: normal Reply-to: terrysutton@usa.net X-list: oracle-l X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at avenirtech.net ------=_NextPart_000_2081_01C6A1BD.0CE56950 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SQL> SELECT DISTINCT(incremental_level) FROM rc_backup_set WHERE db_id =3D 435051864 AND start_time > SYSDATE -10; =20 INCREMENTAL_LEVEL ----------------- So the incremental level is null. --Terry ----- Original Message -----=20 From: Allen, Brandon=20 To: terrysutton@usa.net ; oracle-l@freelists.org=20 Sent: Friday, July 07, 2006 11:43 AM Subject: RE: Lengthening backup 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_000_2081_01C6A1BD.0CE56950 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
SQL> SELECT=20 DISTINCT(incremental_level)
   FROM rc_backup_set WHERE = db_id =3D=20 435051864
   AND start_time > SYSDATE -10;
 =20
INCREMENTAL_LEVEL
-----------------
 
So the incremental level is = null.
 
--Terry
----- Original Message -----
From:=20 Allen, Brandon
To: terrysutton@usa.net ; oracle-l@freelists.org =
Sent: Friday, July 07, 2006 = 11:43=20 AM
Subject: RE: Lengthening = backup

The only thing I can think of that would = cause such=20 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=20 be the case, but could you check the incremental_level of the = rc_backup_set=20 view in your recovery catalog and verify?

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

I'm having some issues with a = client's RMAN=20 backup.  They're on Oracle 8.1.7.4, Solaris 8.  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. 

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

------=_NextPart_000_2081_01C6A1BD.0CE56950-- -- http://www.freelists.org/webpage/oracle-l