RE: Backup VLDB's
Date: Thu, 19 Nov 2009 10:48:02 -0800 (PST)
Message-ID: <744847.89660.qm_at_web51103.mail.re2.yahoo.com>
What about focusing on setting as much of the data as you can readonly so you backup a much smaller subset! We have a 60TB data warehouse and have been lucky enough to set most of the data readonly. Only 15TB of the entire DB is read/write allowing us to not only back it up today via RMAN, but also scale into the future!
FYI, we are also utilizing compression within the DB…
Thanks,
Abdul
- On Tue, 11/10/09, hrishy <hrishys_at_yahoo.co.uk> wrote:
From: hrishy <hrishys_at_yahoo.co.uk>
Subject: RE: Backup VLDB's
To: "'Nizar Ahmed'" <gnahmed.c_at_stc.com.sa>, oracle-l_at_freelists.org, "Mark W. Farnham" <mwf_at_rsiz.com>
Date: Tuesday, November 10, 2009, 10:24 PM
Hi
what's the fastest way to backup" is because I need read response time in seconds on these huge tables. I do not want the RMAN backup window to run for most of the day thereby putting a load on the overall system performance. We do use block change tracking and run a differential incremental on weekdays to keep the sizes of the backup small.
You basically have 2-3 options
a)Do incremental merges to a copy of the backup as i mentioned earlier as i guess this is the path of least resistance since from your signature i can see you are a telecom company this link might be helpful (http://bit.ly/8SCjg) you might be able to convince your management easily.
b)EMC split mirror option if you decide to go that route
c)if you do not do nologging operations then use a physical standby and run your backups from there but in order to take full advantage like block change tracking file incremental merges etc you need to be on 11g.
reading this mail chain at thsi point of time my choice is a)
Not in choice you if things go wrong you dont restore from backup you switch to the copy .
Choice a is not absolute but you need to do some testing and see if it meets your specific requirements.
--
http://www.freelists.org/webpage/oracle-l
Received on Thu Nov 19 2009 - 12:48:02 CST