RE: Long running backups - OK?

First, time to recover is a much more important issue. It is also somewhat likely that curing whatever is making the backups take longer (if the only thing changed was destination media) likely will impede recovery time.  

Were the tapes direct attached or did they have their own special network channels?  

Taking longer with higher disk destination times raises a flag about network bandwidth, disk iops, and disk bytes per second bandwidth issues. Sometimes just putting the “correct” parameters on the nfs mount can make a big difference. Your mileage will vary.  

Since you’re using RMAN you’re not in “physical backup mode” as a database state, so you’re not generating extra redo. However you may have more redo archives in the total standalone recoverable file set if that is something you ship (especially via network) off site for business resumption after a campus wide or regional disaster.  

If you’re not pushing the capacity of database file i/o bandwidth (as opposed to the new destination) or cpu utilization, then “productive work” on the database shouldn’t suffer much or at all.  

If your buffer cache is lean that possible could be stressed a little extra during RMAN backups.  

If you have more elapsed time in the backup, you presumably have more redo to apply to the earliest bits of the backup to bring it current, and that may (or may not) materially affect time to recovery. Whether or not that is “material” to you depends on all the details including the time to recover service level you are trying to achieve.  

That’s all I can think of. Some streaming tape drives are very fast writing big contiguous chunks, so it is possibly your NFS disk mounts are fine. But I would check and NOT accept “that’s how we mount all the disks.” I’m rusty on the routine starting point mount strings (and please don’t call them best practices), but there is a lot of difference between the possibilities for a scad of wee little user documents and big chunks written from a backup job.  

Maybe someone else has a decent starting point mount string handy for you to compare to what you’re using.  

mwf  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Glenn Travis Sent: Friday, January 26, 2018 9:54 AM
To: oracle-l_at_freelists.org
Subject: Long running backups - OK?  

Lively discussion among our team regarding backup run times. We are using RMAN and recently migrated from tape to disk (NFS mounted) based backups. The backups are taking 2-3 times longer (up to 5 times longer when concurrent). Throughput dropped from 200-300mb/sec to 50-70mb/sec. We are investigating the performance issues but the discussion changed to ‘Does it really matter?’  

So I wanted to throw out these questions for your opinions. If a database backup is running and not adversely affecting system (and user’s applications’ performance), does it really matter how long it runs?  

Are there any negatives to having an Oracle backup run for over x hours? Say a 5 hour (or longer) backup on an active database? What are the ramifications of long-running Oracle database backups, if any?  

Note we have dozens of databases over 1tb and run fulls weekly, cumulatives (inc level 1) daily, archivelogs hourly.  

I just can’t deal with a backup running for a quarter of the day. Seems to be a long window of exposure and vulnerability should a crash occur.  

Thoughts?    

Glenn Travis

DBA ▪ Database Services

IT Enteprise Solutions

SAS Institute  

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