RE: ASM questions

  • From: "Best, David" <David.Best@xxxxxxxxxx>
  • To: <randyjo@xxxxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 14 Jun 2007 08:24:01 -0400

 
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


Other related posts: