RE: rman backups using bcv

We must be in the same boat. 
I have a db warehouse that recently went from under 1tb to 4tb of data. 
Our old backup stratgey fell apart so  we recently implemented EMC BCV to 
take a snapshot of the database cold and mount the filesystem copies to 
another server for tape backup.  After the tape backup we would have the 
BCV copy for reporting, object recovery, etc until time to take a new 
snapshot. 

Database is in noarchivelog.  We use Informatica to daily load and it's 
too old to support bulk inserts, only conventional,  so we have tons of 
redo being written out making hot backups impractical.  In several cases 
tables require reload due to faulty sourcing systems with poor historical 
data so readonly tablespaces don't work very well either. 

What we ended up doing is a weekly cold copy and the point in time 
recovery method would be to reprocess any weekly updates via Informatica. 
The snapshots work great, however the tape backups are still at issue for 
disaster recovery.

Our entire IT is being outsourced, and of course, the outsourcer that 
picked up our tape backups and DR is jumping into the act by insisting 
that we revisit the tape backup stratgey of the weekly cold copy so I 
expect that RMAN is going to be the suggested solution.  Probably a full 
with incrementals.

Can anyone provide any good suggestions or things to watch out for? 

Thanks in advance.

Kathy





Fuad Arshad <fuadar@xxxxxxxxx> 
Sent by: oracle-l-bounce@xxxxxxxxxxxxx
12/22/2004 03:16 PM
Please respond to
fuadar@xxxxxxxxx


To
"Mercadante, Thomas F" <thomas.mercadante@xxxxxxxxxxxxxxxxx>, 
"'ryan_gaffuri@xxxxxxxxxxx'" <ryan_gaffuri@xxxxxxxxxxx>, 
shrekdba@xxxxxxxxx
cc
oracle-l@xxxxxxxxxxxxx
Subject
RE: rman backups using bcv






bascially we are having too problems
one the batch process is run in no archivelog mode thus eliminating us 
backing up at that point in time.
thisis a 7 tb database.
we can back it up in online time but that is too resprce intensive and 
since management doesnt want to buy more disk.
emc has offered this solution with the timefinder copy we already have.
 Please note since the timefinder copy is used for reporting and other 
stuff basicaly we;ve lost our backup and every thing we';ve in online time 
 which  the company says thaey dont want to lose.
i hiope this answers most of the questions.

"Mercadante, Thomas F" <thomas.mercadante@xxxxxxxxxxxxxxxxx> wrote:
I'm not sure what the purpose is for performing an Rman backup after the 
bcv
split. You can recreate this database in about a minute. So why back it
up?

I would be doing Rman backups of the source database and consider this 
(the
reporting) database expendable.

-----Original Message-----
From: ryan_gaffuri@xxxxxxxxxxx [mailto:ryan_gaffuri@xxxxxxxxxxx] 
Sent: Wednesday, December 22, 2004 2:05 PM
To: shrekdba@xxxxxxxxx; fuadar@xxxxxxxxx
Cc: Shrek; oracle-l@xxxxxxxxxxxxx
Subject: Re: rman backups using bcv

how time consuming is it to resynch the bcvs? how out of synch do you 
allow
them to get? I know this is vague... 
i would think the best way to be super anal dba would be to have your
typical rman online backups plus use the bcv mirrors and offline those. 

looking for comments, advice, etc... 

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


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


*************************************************************************************************
The following message has been automatically added by the Internet mail 
gateway 
to comply with Royal & SunAlliance IT Security Policy.

"This e-Mail has arrived via the Internet and, therefore, you should be 
cautious 
about its origin and content.  Replies which contain sensitive information 
or 
legal/contractual obligations are particularly vulnerable.  In these cases 
you should
not reply unless you are authorized to do so."


If you have any questions, please speak to your local desktop support team 
or IT 
security contact.

*************************************************************************************************




***********************************************************************************
Notice of Confidentiality 

This transmission (including attachments) contains information that 
may be privileged, confidential and protected from disclosure. Unless 
you are the intended recipient of the message (or authorized to receive 
it for the intended recipient) you may not copy, forward, or otherwise 
use it, or disclose it or its contents to anyone. If you received this 
transmission in error please notify us immediately, permanently delete 
the transmission(including attachments) from your system, and destroy 
all hard copies.  Thank you.


Email: security_usa@xxxxxxxxxx
***********************************************************************************



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

Other related posts: