Re: block chg tracking

From: goran bogdanovic <goran00_at_gmail.com>
Date: Fri, 6 Mar 2015 10:32:50 +0100
Message-ID: <CAGyPXK6Rk=nFHqzERZ6SMkY8ESf=D3PSxN9pg-i4J1e6HjK40w_at_mail.gmail.com>

I tend to agree backup restore speed is relevant, tied closely to RTO business requirement ... I would wonder if some shop will base his availability strategy on 'fast backup restore' rather than to use more suitable HA solutions, which costs in case of such requirement can be easily justified to business.

On Sun, Feb 15, 2015 at 9:57 PM, Mladen Gogala <dmarc-noreply_at_freelists.org> 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. If you are a major bank, then the cost of downtime
> is enormous. The same goes for the sites like Amazon. If www.amazon.com
> goes down, the customers will go to walmart.com or alike. The costs of
> downtime can be enormous. The goal of any backup strategy is to minimize
> downtime, not to save IO operations. That is why backups are usually
> scheduled for wee hours of the night.
>
>
> 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.
>
> What is the size of the DB for which commvault's compression beats BCT
> significantly in recovery time.
>
>
>
> On Sun, Feb 15, 2015 at 11:24 AM, Mladen Gogala <
> dmarc-noreply_at_freelists.org> wrote:
>
>> On 02/15/2015 11:47 AM, Jared Still wrote:
>>
>>> Hi Mladen,
>>>
>>> Though dedup reduces the size on the backend, it does nothing for
>>> database impact.
>>>
>>> As you know BCT reduces the reads on the db by RMAN, so I am a little
>>> confused by this statement.
>>>
>>
>> That is true, but the goal is not reducing the reads, the goal is to
>> restore database in the shortest time possible. De-duplication also speeds
>> things up, because everything is read, but not everything is written. You
>> get far fewer disk writes and, if the storage medium is connected by
>> network, far less network traffic. Given that a full backup must be
>> restored, the difference is whether there will be a need for applying
>> additional incremental backups.
>>
>>
>
>
> --
> Mladen Gogala
> Oracle DBAhttp://mgogala.freehostia.com
>
>

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

Received on Fri Mar 06 2015 - 10:32:50 CET