RE: rman backups using bcv
- From: KATHERINE_KAYLOR@xxxxxxxxxx
- To: fuadar@xxxxxxxxx, oracle-l@xxxxxxxxxxxxx
- Date: Wed, 22 Dec 2004 16:08:31 -0500
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...
--
//www.freelists.org/webpage/oracle-l
--
//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
***********************************************************************************
--
//www.freelists.org/webpage/oracle-l
Other related posts:
