Re: creative use of storage snapshots.
- From: Martin Bach <development@xxxxxxxxxxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx, Niall Litchfield <niall.litchfield@xxxxxxxxx>
- Date: Mon, 20 Dec 2010 16:51:01 +0000
Hi Niall,
I have done this with HP EVA 8100 series arrays, providing storage for
RHEL 5.3 RAC clusters. One of the things you'd like to consider is to
ensure the WWIDs you present to the dev system are constant. I found
that to work best with RHEL 5.3, saving you from purging the LUNs from
the dev box's scsi bus, something that doesn't always work reliably. The
process we used was quite simple:
1) stop/unmount disk groups used by DEV database (it's ASM throughout)
2) delete old LUNs from dev box on the storage array
3) stop managed recovery on the snap-source standby DB (don't use SRLs,
they are always written to causing the snapshot to be fuzzy!)
4) Create the snap on the storage array, ensuring the destination WWIDs
are identical to those just deleted. This can easily be done via a script
5) present new LUNs to the DEV box
6) mount the disk group(s) in ASM for the new dev database
7) use a create controlfile statement to turn the database into a
primary (could have been done differently but worked for me)
8) open the newly created database with the resetlogs option
9) do any post processing like data masking etc. For RAC, add additional
redo log threads
I could recreate a 2.5 TB development database in 30 minutes this way.
When using ASM it is important not to present source and clone LUN to
the same host, otherwise you would end up with a disks "DATA1" and 2
disk groups "DATA" for example, the SCSI bus chaos aside.
Best regards
Martin
--
Martin Bach
OCM 10g
http://martincarstenbach.wordpress.com
http://www.linkedin.com/in/martincarstenbach
On 20.12.2010 12:07, Niall Litchfield wrote:
Hi List
I have a client with storage technology that allows copy on write
snapshots to create a writeable copy of a storage volume. They are
looking at potentially using this technology to provision clones of a DR
database for development/testing and reporting purposes. The idea being
that as these databases would be a) short lived and b) have limited
changed data block volume going through them and c) not have high
performance requirements they could save considerable amounts of storage
by splitting off a clone using the snapshot technology rather than a
conventional oracle based approach. I'm aware of Delphix Database
virtualization which looks like it addresses similar issues in a similar
way. Is anyone out there doing something similar - it sounds to me like
one of those great ideas that have a huge gotcha that I can't think of
right now.
--
Niall Litchfield
Oracle DBA
http://www.orawin.info
--
//www.freelists.org/webpage/oracle-l
Other related posts:
