Return-Path: Delivered-To: 2-oracle-l@orafaq.com Received: (qmail 28366 invoked from network); 17 Sep 2007 21:20:03 -0500 Received: from freelists-180.iquest.net (HELO turing.freelists.org) (206.53.239.180) by 69.64.49.119 with SMTP; 17 Sep 2007 21:19:49 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 16F9775AD1C; Mon, 17 Sep 2007 22:18:58 -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 23516-01-817; Mon, 17 Sep 2007 22:18:57 -0400 (EDT) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id E1DB875AC5E; Mon, 17 Sep 2007 22:17:43 -0400 (EDT) Received: with ECARTIS (v1.0.0; list oracle-l); Mon, 17 Sep 2007 21:32:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id C4AB275A9FE for ; Mon, 17 Sep 2007 21:32:41 -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 04841-02 for ; Mon, 17 Sep 2007 21:32:41 -0400 (EDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 5521E75A2CB for ; Mon, 17 Sep 2007 21:32:41 -0400 (EDT) Received: by wa-out-1112.google.com with SMTP id k22so2384213waf for ; Mon, 17 Sep 2007 18:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=/tVRX65BfnEXMfJhpl+L/HH7od39+lWpd9vCojJ+lsc=; b=EXKFJvxETZFySFKXP0ixky1ihWJ/+Ltn2IiHRHuNvUW/6Cl6XaaVnhffs2ikotR3984Mfz+pPQF21EIzSKTW1PM54UkgO1ds/uybuk25vRY4+JH2+0iI8YgMlJ/cZegbJ4RvpuDxoydWNPNQ4gAv3lH/9JIAtRt/1NY7Hj9VYgA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Gj0LL1toCjNG/cLW70hUSr8PVDigQkE2wUG4cneBwnQZteD9xm4OvYnH8ALFzeptyaGLHYCLncaBBNQhSh5B19eer7FoEH9P5dBWGs6dig/BP8OZmHDFFR3vu6CbFqJCEEcGJrOzBrp77BEbWCcLZXsloJ8KCHnQNOPPz0gCKNc= Received: by 10.115.92.2 with SMTP id u2mr3211560wal.1190079159004; Mon, 17 Sep 2007 18:32:39 -0700 (PDT) Received: by 10.114.103.6 with HTTP; Mon, 17 Sep 2007 18:32:38 -0700 (PDT) Message-ID: Date: Mon, 17 Sep 2007 18:32:38 -0700 From: "Jared Still" To: Brandon.Allen@oneneck.com Subject: Re: RMAN question(s) Cc: robertgfreeman@yahoo.com, oracle-l@freelists.org In-Reply-To: <04DDF147ED3A0D42B48A48A18D574C4508B6E773@NT15.oneneck.corp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_13657_32758582.1190079158787" References: <04DDF147ED3A0D42B48A48A18D574C4508B6E72D@NT15.oneneck.corp> <04DDF147ED3A0D42B48A48A18D574C4508B6E773@NT15.oneneck.corp> X-archive-position: 1636 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: jkstill@gmail.com Precedence: normal Reply-to: jkstill@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 X-Virus-Scanned: Debian amavisd-new at localhost.localdomain ------=_Part_13657_32758582.1190079158787 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 9/17/07, Allen, Brandon wrote: > > In case anyone is interested - I did a test of the 10g "as compresssed" > backupset on a 285GB databases and here are the results: > > ... > So, I can't really make any conclusions on the backup time yet due to > the large variance in backup times on this environment, but it's clear > that the space savings was significant (280-36=244 & 244/280=87% > reduction) and the runtime from this one sample was close to the bottom > of the normal range so that's promising. > The data in v$backup_sync_io and v$backup_async_io may provide better information after the fact. I too find it difficult to get a system suitable for testing. The data in these views is not persistent, so you need to get it after the backup completes and save it. I've pasted a script at the end of this post to get you started with it, if you would like to use it. -- Jared Still Certifiable Oracle DBA and Part Time Perl Evangelist -------------------------------------------------- -- rman_io_stats.sql -- aggregation of compatible stats -- from the v$backup_async_io and v$backup_sync_io views -- alter session set nls_date_format = 'mm/dd/yy hh24:mi:ss'; col device_type format a10 head 'DEVICE|TYPE' col type format a15 col filename format a40 head 'FILENAME' TRUNC col buffer_size format 99,999,999,999 head 'BUFFER SIZE' col buffer_count format 9999 head 'BFFR|CNT' col open_time format a18 head 'OPEN TIME' col close_time format a18 head 'CLOSE TIME' col elapsed_time format 999,999 head 'ELAPSED|SECONDS' col set_stamp format 9999999999 head 'SET STAMP' col set_count format 99999 head 'SET |COUNT' col megabytes format 99,999,999.0 head 'MEGABYTES' col total_megabytes format 99,999,999.0 head 'TOTAL|MEGABYTES' col effective_bytes_per_second format 999,999,999 head 'EFF BYTES|PER SECOND' col io_count format 999,999,999 head 'IO COUNT' set line 200 break on set_stamp skip 1 on set_count --spool rio.txt SELECT set_stamp , set_count , open_time --, close_time , device_type , type , filename , buffer_size , buffer_count , bytes / 10485760 megabytes , total_bytes / 10485760 total_megabytes , effective_bytes_per_second , io_count , elapsed_time/100 elapsed_time -- stored in centiseconds FROM v$backup_async_io -- disk union SELECT set_stamp , set_count , open_time --, close_time , device_type , type , filename , buffer_size , buffer_count , bytes / 10485760 megabytes , total_bytes / 10485760 total_megabytes , effective_bytes_per_second , io_count , elapsed_time/100 elapsed_time -- stored in centiseconds FROM v$backup_sync_io -- tape, probably. could be disk ORDER BY 1,2,3 / --spool off --ed rio.txt ------=_Part_13657_32758582.1190079158787 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 9/17/07, Allen, Brandon <Brandon.Allen@oneneck.com> wrote:
In case anyone is interested - I did a test of the 10g "as compresssed"
backupset on a 285GB databases and here are the results:

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

The data in v$backup_sync_io and v$backup_async_io may provide better
information after the fact.  I too find it difficult to get a system suitable for testing.

The data in these views is not persistent, so you need to get it after the backup
completes and save it.

I've pasted a script at the end of this post to get you started with it, if you
would like to use it.


--
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist


--------------------------------------------------

-- rman_io_stats.sql
-- aggregation of compatible stats
-- from the v$backup_async_io and v$backup_sync_io views
--

alter session set nls_date_format = 'mm/dd/yy hh24:mi:ss';

col device_type format a10 head 'DEVICE|TYPE'
col type format a15
col filename format a40 head 'FILENAME' TRUNC
col buffer_size format 99,999,999,999 head 'BUFFER SIZE'
col buffer_count format 9999 head 'BFFR|CNT'
col open_time format a18 head 'OPEN TIME'
col close_time format a18 head 'CLOSE TIME'
col elapsed_time format 999,999 head 'ELAPSED|SECONDS'
col set_stamp format 9999999999 head 'SET STAMP'
col set_count format 99999 head 'SET |COUNT'

col megabytes format 99,999,999.0 head 'MEGABYTES'
col total_megabytes format 99,999,999.0 head 'TOTAL|MEGABYTES'
col effective_bytes_per_second format 999,999,999 head 'EFF BYTES|PER SECOND'
col io_count format 999,999,999 head 'IO COUNT'


set line 200

break on set_stamp skip 1 on set_count

--spool rio.txt

SELECT
        set_stamp
        , set_count
        , open_time
        --, close_time
        , device_type
        , type
        , filename
        , buffer_size
        , buffer_count
        , bytes / 10485760 megabytes
        , total_bytes / 10485760 total_megabytes
        , effective_bytes_per_second
        , io_count
        , elapsed_time/100 elapsed_time -- stored in centiseconds
FROM v$backup_async_io -- disk
union
SELECT
        set_stamp
        , set_count
        , open_time
        --, close_time
        , device_type
        , type
        , filename
        , buffer_size
        , buffer_count
        , bytes / 10485760 megabytes
        , total_bytes / 10485760 total_megabytes
        , effective_bytes_per_second
        , io_count
        , elapsed_time/100 elapsed_time -- stored in centiseconds
FROM v$backup_sync_io -- tape, probably. could be disk
ORDER BY 1,2,3
/

--spool off
--ed rio.txt


------=_Part_13657_32758582.1190079158787-- -- http://www.freelists.org/webpage/oracle-l