FW: block chg tracking

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Mon, 16 Feb 2015 10:11:16 -0500
Message-ID: <027e01d049fa$d002cb00$70086100$_at_rsiz.com>


From: Mark W. Farnham [mailto:mwf_at_rsiz.com] Sent: Monday, February 16, 2015 10:10 AM To: 'dmarc-noreply_at_freelists.org'; 'oracle-l_at_freelists.org' Subject: RE: block chg tracking  


And this why taking backups is part of the Business Continuation process and not the other way around.  

Defining your Business Continuation requirements in confluence with budget justification based on best net financial results including the insurance costs of the recovery and backup infrastructure should first define the acceptable solution space.  

Then you know the goal and commence engineering starting with gedanken experiments about what is possible with the existing reliable technology.  

Then sweating out the details is engineering, such as the constraint that you not place unacceptable load on the database supporting the business continuation process chosen.  

This is the difference between the primary “goal” and minimizing attendant costs and side effects. That is quite different from saying attendant costs and side effects are not important. Achieving the goal at minimum cost and side effects is optimal. Failing to achieve the goal is a failure. Achieving the goal at more than the minimum cost and side effects is less than optimal, but may be acceptable and is definitely better than failure.  

Sometimes reaching acceptability and then searching for a third set of experienced eyes for third party review and process improvement is a good way to proceed. Reviewing advances in technology periodically also is prudent, so you don’t miss a new opportunity to meet your goal at less cost and overhead.  

good luck!  


From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mladen Gogala (Redacted sender "mgogala_at_yahoo.com" for DMARC) Sent: Sunday, February 15, 2015 3:57 PM
To: oracle-l_at_freelists.org
Subject: Re: block chg tracking  

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 DBA

Received on Mon Feb 16 2015 - 16:11:16 CET

Original text of this message