Return-Path: Delivered-To: 2-oracle-l@orafaq.com Received: (qmail 12272 invoked from network); 18 Sep 2007 02:28:53 -0500 Received: from freelists-180.iquest.net (HELO turing.freelists.org) (206.53.239.180) by 69.64.49.119 with SMTP; 18 Sep 2007 02:28:53 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 16DDA75B2FD; Tue, 18 Sep 2007 03:28:53 -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 21260-09; Tue, 18 Sep 2007 03:28:52 -0400 (EDT) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 7846E75B661; Tue, 18 Sep 2007 03:28:52 -0400 (EDT) Received: with ECARTIS (v1.0.0; list oracle-l); Tue, 18 Sep 2007 02:43:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id CFAD175B525 for ; Tue, 18 Sep 2007 02:43:51 -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 16102-03 for ; Tue, 18 Sep 2007 02:43:51 -0400 (EDT) Received: from mx.cqu.edu.au (falcon.cqu.edu.au [138.77.5.11]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 2EF0975B523 for ; Tue, 18 Sep 2007 02:43:50 -0400 (EDT) Received: from [127.0.0.1] (helo=falcon.cqu.edu.au) by mx.cqu.edu.au with esmtp (Exim 4.63) (envelope-from ) id 1IXWoD-0002Yf-Oh; Tue, 18 Sep 2007 16:43:45 +1000 Received: from UNIMAIL.staff.ad.cqu.edu.au (remus.staff.ad.cqu.edu.au [138.77.34.93]) by falcon.cqu.edu.au (8.13.8/8.13.8) with ESMTP id l8I6hi8j009822; Tue, 18 Sep 2007 16:43:45 +1000 (EST) (envelope-from p.mclarty@cqu.edu.au) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F9BF.424E3DD8" Subject: RE: RMAN question(s) Date: Tue, 18 Sep 2007 16:43:44 +1000 Message-ID: <27AA2E9CA7A0C44283BC1E9B00086AA908262185@UNIMAIL.staff.ad.cqu.edu.au> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RMAN question(s) References: <04DDF147ED3A0D42B48A48A18D574C4508B6E72D@NT15.oneneck.corp> <04DDF147ED3A0D42B48A48A18D574C4508B6E773@NT15.oneneck.corp> From: "Peter McLarty" To: , Cc: , X-archive-position: 1640 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: p.mclarty@cqu.edu.au Precedence: normal Reply-to: p.mclarty@cqu.edu.au 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_001_01C7F9BF.424E3DD8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable With 1.2.0.3 databases we are running a lot of backups here with rman, we have ASM. We use compressed backups as we have observed similar results, the Peoplesoft demo database about 7GB reduces to around 770MB. these being backup up to an OCFS filesystem have consistently taken around 3:00 minutes. Our copys of production rman is reporting as compressing from just under 48GB down to 8GB and running between 10 and 30 minutes to the same OCFS filesystem, most are at the lower end. Interestingly one backup up of the full database to tape took around 2hrs to a virtual tape library, it was uncompressed. We are doing these regular backups to disk as we lost faith in the backup software, It has many issues that we in teh project could not stomach for easy recovery =20 We are using compressed as we find it faster, I think the smaller ones consistently took around 10 minutes without compression.=20 =20 I should be able to run some tests here, have to give it a spin and confirm the spped on a big database =20 Cheers =20 Peter =20 =20 ________________________________ From: Jared Still [mailto:jkstill@gmail.com]=20 Sent: Tuesday, 18 September 2007 11:33 AM To: Brandon.Allen@oneneck.com Cc: robertgfreeman@yahoo.com; oracle-l@freelists.org Subject: Re: RMAN question(s) On 9/17/07, Allen, Brandon wrote:=20 In case anyone is interested - I did a test of the 10g "as compresssed" backupset on a 285GB databases and here are the results: =09 ... So, I can't really make any conclusions on the backup time yet due to=20 the large variance in backup times on this environment, but it's clear that the space savings was significant (280-36=3D244 & 244/280=3D87% reduction) and the runtime from this one sample was close to the bottom=20 of the normal range so that's promising. =09 ------_=_NextPart_001_01C7F9BF.424E3DD8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
With 1.2.0.3 databases we are running a = lot of backups=20 here with rman, we have ASM. We use compressed backups as we have = observed=20 similar results, the Peoplesoft demo database about 7GB reduces to = around=20 770MB. these being backup up to an OCFS filesystem have consistently = taken=20 around 3:00 minutes.
Our copys of production rman is reporting as = compressing=20 from just under 48GB down to 8GB and running between 10 and 30 = minutes to=20 the same OCFS filesystem, most are at the lower end. Interestingly one = backup up=20 of the full database to tape took around  2hrs to a virtual = tape=20 library, it was uncompressed. We are doing these regular backups to = disk as=20 we lost faith in the backup software, It has many issues that we in teh = project=20 could not stomach for easy recovery
 
We are using compressed as we find it faster, I = think the=20 smaller ones consistently took around 10 minutes without=20 compression. 
 
I should be able to run some tests here, have = to give=20 it a spin and confirm the spped on a big = database
 
Cheers
 
Peter
 
 

From: Jared Still = [mailto:jkstill@gmail.com]=20
Sent: Tuesday, 18 September 2007 11:33 AM
To:=20 Brandon.Allen@oneneck.com
Cc: robertgfreeman@yahoo.com;=20 oracle-l@freelists.org
Subject: Re: RMAN=20 question(s)

On 9/17/07, Allen, Brandon = <Brandon.Allen@oneneck.com&g= t; wrote:
In=20 case anyone is interested - I did a test of the 10g "as=20 compresssed"
backupset on a 285GB databases and here are the=20 results:

...
So, I can't really make any conclusions on the = backup=20 time yet due to
the large variance in backup times on this = environment,=20 but it's clear
that the space savings was significant (280-36=3D244 = &=20 244/280=3D87%
reduction) and the runtime from this one sample was = close to=20 the bottom
of the normal range so that's=20 promising.



------_=_NextPart_001_01C7F9BF.424E3DD8-- -- http://www.freelists.org/webpage/oracle-l