Message-ID: <50C893E8.9070508@evdbt.com>
Date: Wed, 12 Dec 2012 07:25:44 -0700
From: Tim Gorman <tim@evdbt.com>
Organization: Evergreen Database Technologies, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: oracle-l@freelists.org
Subject: Re: Just A Question. Regarding Backup strategy for Oracle Database
 with Terra Bytes of Data.
References: <CAPfA+9N97fXrO+95h0SCz2PZitjHAyF+Td1ODeuu=gX-fnqcFQ@mail.gmail.com>
In-Reply-To: <CAPfA+9N97fXrO+95h0SCz2PZitjHAyF+Td1ODeuu=gX-fnqcFQ@mail.gmail.com>
Content-type: text/plain
Content-Transfer-Encoding: 8bit
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
Precedence: normal
Reply-To: tim@evdbt.com

Sheldon,
It is crucial to clearly understand and document your application 
users's educated expectation for uptime and recoverability before 
designing a recoverability strategy (please note the term 
"recoverability strategy" and not "backup strategy").  If you don't have 
agreed-upon numbers for MTTR (mean time to repair) and XTTR (maximum 
time to repair), then you don't have enough information to create a 
suitable recoverability strategy.

Initial recommendations, just for setting expectations...

  * For databases supporting OLTP applications, "hybrid" OLTP/DW/BI
    applications, or poorly-designed DW/BI applications, cycles of RMAN
    incremental backups
      o for such databases with low MTTR requirements, flashback
        database, block-change tracking, and one (or more) Data Guard
        standby databases and backups of the standby
  * For databases supporting DW/BI applications, partitioning large
    tables by time, grouping table- and index-partitions into
    tablespaces, setting tablespaces to READ ONLY as they age, and then
    cycles of RMAN incremental backups;  a low-priority, less-frequent
    cycle for the READ ONLY tablespaces, and a higher-priority,
    more-frequent cycle for READ WRITE tablespaces and archivelogs.

Also, if QA/test and development databases are not being refreshed 
regularly as clones from production backups, then there it is uncertain 
whether backups are recoverable, and therefore useless.  Even if the 
application is a pure COTS and no development is necessary, a QA/test 
environment for upgrades, patches, and releases is necessary, and it 
should be cloned regularly.

As a representative for the ORA600 "DUDE" product (i.e. www.ora600.be), 
I hear from those who didn't understand recoverability, or who didn't 
test recoveries.  It's as much about grief-counseling as it is about 
properly using a last-resort data-extraction utility.

Hope this helps...

Kind regards,

-- 
Tim Gorman
consultant -> Evergreen Database Technologies, Inc.
postal     => PO Box 352151, Westminster CO 80035
website    => http://www.EvDBT.com/
email      => Tim@EvDBT.com
mobile     => +1-303-885-4526
fax        => +1-303-484-3608
Lost Data? => http://www.ora600.be/ for info about DUDE...


On 12/11/2012 11:42 PM, Sheldon Quinny wrote:
> Hi,
> I would like to know what type of strategy is been use by other DBA's for
> Making backups of Production DB which are in Terra bytes.
>
> Please let me know your inputs.
>
> Thank you.
>
> Regards,
> Sheldon.
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
>


--
http://www.freelists.org/webpage/oracle-l