This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C2C17C.738A8AC0
Content-Type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Mark,
Looks good, but I have one question -- why aren't you waiting until the next
evening to perform step 5? In the event of a failure between your last
backup and the next one wouldn't you want your most recent backup data to be
available on BCV rather than tape, since a restore from BCV is much faster
than tape thereby decreasing your recovery time? Re-establishing your BCV
may give you yet another mirrored copy of your data but it's really not
necessary given the reliability of EMC storage.
Just a thought...
-Dave
-----Original Message-----
From: Donaldson, Mark [mailto:Mark.Donaldson AT experianems DOT com]
Sent: Tuesday, January 21, 2003 10:02
To: Veritasbu (E-mail)
Subject: [Veritas-bu] Incremental RMAN backups on split BCV's
So we're looking at changing our backup methods using EMC BCV's. Today we
do full filesystem backups of our Oracle database; we set the DB into hot
backup mode, split the data BCV's, roll the logs, then split the archived
redo BCV's. These BCV's are then imported & mounted to our media server &
we do simple filesystem full backups to tape.
The problem is that anticipated growth will make this difficult in the
future - we won't be able to move enough data in the necessary timespan.
Therefore, we're looking at using Oracle RMAN to perform database
incrementals. However, I'm still wanting to perform the backup off-host so
the idea is to use RMAN to backup BCV's mounted on my media server.
The idea is this, and I'm looking for proponents or detractors to this idea:
1. split & import as above to our media server
2. Open the database on the media server
3. perform the RMAN full and/or incremental as necessary
4. shutdown the Oracle instance
5. incrementally re-establish.
6. rinse & repeat the next night
The thought is that since the instance on the media server is opened &
closed normally and since the BCV should be a blockwise identical copy of
the original database, then RMAN doesn't know from run-to-run that this is a
"new" copy of the DB. As far as RMAN is concerned, the only DB involved
lives exclusively on the media server - it doesn't have to know about the
original mounted on the main server.
Anybody doing this? Any "gotchas"?
-M
------_=_NextPart_001_01C2C17C.738A8AC0
Content-Type: text/html;
charset=iso-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Incremental RMAN backups on split BCV's</TITLE>
<META content="MSHTML 6.00.2800.1106" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=636223118-21012003><FONT face=Arial color=#0000ff
size=2>Mark,</FONT></SPAN></DIV>
<DIV><SPAN class=636223118-21012003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=636223118-21012003><FONT face=Arial color=#0000ff size=2>Looks
good, but I have one question -- why aren't you waiting until the next evening
to perform step 5? In the event of a failure between your last backup and
the next one wouldn't you want your most recent backup data to be available on
BCV rather than tape, since a restore from BCV is much faster than tape
thereby decreasing your recovery time? Re-establishing your BCV may give
you yet another mirrored copy of your data but it's really not necessary given
the reliability of EMC storage.</FONT></SPAN></DIV>
<DIV><SPAN class=636223118-21012003><FONT face=Arial color=#0000ff size=2>Just
a
thought...</FONT></SPAN></DIV>
<DIV><SPAN class=636223118-21012003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=636223118-21012003><FONT face=Arial color=#0000ff
size=2>-Dave</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Donaldson, Mark
[mailto:Mark.Donaldson AT experianems DOT com]<BR><B>Sent:</B> Tuesday,
January 21,
2003 10:02<BR><B>To:</B> Veritasbu (E-mail)<BR><B>Subject:</B> [Veritas-bu]
Incremental RMAN backups on split BCV's<BR><BR></FONT></DIV>
<P><FONT size=2>So we're looking at changing our backup methods using EMC
BCV's. Today we do full filesystem backups of our Oracle database; we
set the DB into hot backup mode, split the data BCV's, roll the logs, then
split the archived redo BCV's. These BCV's are then imported &
mounted to our media server & we do simple filesystem full backups to
tape.</FONT></P>
<P><FONT size=2>The problem is that anticipated growth will make this
difficult in the future - we won't be able to move enough data in the
necessary timespan. Therefore, we're looking at using Oracle RMAN to
perform database incrementals. However, I'm still wanting to perform
the
backup off-host so the idea is to use RMAN to backup BCV's mounted on my
media
server.</FONT></P>
<P><FONT size=2>The idea is this, and I'm looking for proponents or
detractors
to this idea:</FONT> </P>
<P><FONT size=2>1. split & import as above to our media server</FONT>
<BR><FONT size=2>2. Open the database on the media server</FONT> <BR><FONT
size=2>3. perform the RMAN full and/or incremental as necessary</FONT>
<BR><FONT size=2>4. shutdown the Oracle instance</FONT> <BR><FONT size=2>5.
incrementally re-establish.</FONT> <BR><FONT size=2>6. rinse & repeat the
next night</FONT> </P>
<P><FONT size=2>The thought is that since the instance on the media server is
opened & closed normally and since the BCV should be a blockwise
identical
copy of the original database, then RMAN doesn't know from run-to-run that
this is a "new" copy of the DB. As far as RMAN is concerned, the only
DB
involved lives exclusively on the media server - it doesn't have to know
about
the original mounted on the main server.</FONT></P>
<P><FONT size=2>Anybody doing this? Any "gotchas"?</FONT> </P>
<P><FONT size=2>-M</FONT> </P></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C2C17C.738A8AC0--
|
