Thanks for the reponses, I should clarify that we wouldn't be using BCV's
for production. Its just for our testing enviornment in case we need to
switch back quickly to a previous backup.
------------------------------
*From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:
oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Randy Johnson
*Sent:* Thursday, June 14, 2007 1:15 AM
*To:* oracle-l@xxxxxxxxxxxxx
*Subject:* RE: ASM questions
[You're probably better off using RMAN, flashback, data guard, etc. - so
much more fine-grained than BCVs.]
I agree with Matt on this. I've been doing ASM with RMAN for a year now
and you will be severly limiting your recovery options if you stray from
RMAN for your backups. Just to list a few not too obvious advantages:
-Block level recovery. One bad block in your database? Just recover
that block not the whole file or database.
-Database Cloning
-Every block is verified during backup and during restore.
-Block change tracking makes incremental backups very fast.
-Recovery auditing using "restore database validate check logical"
Hope this helps...
-Randy
------------------------------
*From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:
oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Matthew Zito
*Sent:* Wednesday, June 13, 2007 12:20 PM
*To:* David.Best@xxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
*Subject:* RE: ASM questions
You probably want to be careful using BCVs in an ASM environment. First,
depending on your platform and configuration, you may be using disk
signatures to identify the disks, and should you reboot a node while the
BCVs are split (assuming they're exposed to one of the nodes in the
cluster), the node will see two different disks with the same ID, and could
be fairly unhappy about it. The other thing to make sure is that you do an
"instant split" on the BCVs, so they're consistent. And also, you would
want to put your archive logs in a different ASM diskgroup than the BCV one,
so that in a restore situation you don't overwrite your archive logs during
the restore.
Also, with ASM there are no "mount points" - to the OS, they look just
like raw disks. Assuming this is an EMC environment (and you're not using
the BCV term generically), though, when you do a BCV restore, nothing will
change about the disks. Basically you would bring the ASM instances down, do
a bcv restore (at a Symmetrix level), and then start ASM back up. Poof -
rolled back to the previous copy.
However, BCVs are a pretty crude tool these days for backup and recovery
situations - you can only have one or two copies, it burns a bunch of space
on your Symm as a third/fourth mirror, and there's no incremental
intelligence (you do get a slight read performance bump when your BCVs are
in established mode, but I know few people that care _that_ much about
that). You're probably better off using RMAN, flashback, data guard, etc. -
so much more fine-grained than BCVs.
Matt
------------------------------
*From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:
oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Best, David
*Sent:* Wednesday, June 13, 2007 12:06 PM
*To:* oracle-l@xxxxxxxxxxxxx
*Subject:* ASM questions
Hey all,
Please forgive my ASM ignorance if it shows but I have a couple of
questions. We are considering using BCV Copy with an ASM environment (the
database is RAC'd if that matters).
Once we make a BCV copy, what is the quickest way to restore?
I would assume the easiest would be to replace the volumes with the BCV
copy, thus keeping the device names, mount points the same. Then you would
just perform a database recovery.
What if you mounted the BCV copy on the server, so in that case the mount
point, device name, etc are different? Can you recreate diskgroups in ASM
after they have been initially created so they point to the new location?
Thanks
This message may contain privileged and/or confidential information.
If you have received this e-mail in error or are not the intended recipient,
you may not use, copy, disseminate or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so. Thank you.
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.472 / Virus Database: 269.8.15/847 - Release Date: 6/12/2007
9:42 PM
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.472 / Virus Database: 269.8.15/847 - Release Date: 6/12/2007
9:42 PM
