Re: block chg tracking
- From: Jeremy Schneider <jeremy.schneider@xxxxxxxxxxxxxx>
- To: Oracle-L <oracle-l@xxxxxxxxxxxxx>
- Date: Mon, 16 Feb 2015 08:00:17 -0600
> On 02/15/2015 03:14 PM, Ram Raman wrote:
> Mladen, why would you say the 'goal is not reducing the reads' in this
> context? I would prefer lesser reads (lesser CPU and IO) while doing
> backups. BCT is very handy not just for prod, but for several non prod DBs
> too where we do not pay for the standby solutions like DG, etc. I will take
> BCT over commvault for the DBs we maintain, most of them under a TB.
>
On Sun, Feb 15, 2015 at 2:57 PM, Mladen Gogala
<dmarc-noreply@xxxxxxxxxxxxx> wrote:
> Because the goal of the backup is to provide the ability to get the database
> back as soon as possible. I doubt that your CIO will be very pleased if you
> save some IO operations but extend the recovery time for a few hours, in the
> world where the cost of downtime is measured in hundreds of thousands of
> dollars.
Obviously, reducing reads does matter (and RTO matters too). Running
full backups every four to six hours on production won't fly at many
places - and increasingly, the "wee hours of the morning" are another
global customer's business day. In fact I've heard CIO's mandate that
no backups are allowed from the primary production database at all
(even weekends), after very messy performance-related support cases
with their customers (internal or external). Sometimes it's
worthwhile to remove this factor so people can't blame it, even when
you know it's not the root problem. The common solution I've seen for
that situation is offloading backups to a physical standby - as Kenny
discussed. And in that situation, you can still leverage pretty much
any strategy under the sun including a backup system that supports
dedupe.
--
http://about.me/jeremy_schneider
--
//www.freelists.org/webpage/oracle-l
Other related posts:
