RE: creative use of storage snapshots.

From: Michael Dinh <mdinh_at_XIFIN.Com>
Date: Mon, 20 Dec 2010 05:57:56 -0800
Message-ID: <D29F9902E534D5478F2E83FD6A44B306137B9C9CD9_at_mail02.mba.xifin.com>



Hello Nial,

We are currently doing the same thing here for development, QA, Level3.

There is a snaphot pool (storage) that holds all the changed blocks.

With 8 OLTP and 3 environments = 24 snapshots which can fill the snaphot pool up quickly.

One way to resolve the snapshot pool filling up is to do a resnap which has caused disruptions to development and QA.

We actually have a client who wants real production data for testing and we provide new snap for them every 2 weeks.

It's a great idea as long as changes are a minimum or have a large snapshot pool.

Depending on how often an environments are renapped, it can be a PITA.

HTH -Michael.



From: oracle-l-bounce_at_freelists.org [oracle-l-bounce_at_freelists.org] On Behalf Of Niall Litchfield [niall.litchfield_at_gmail.com] Sent: Monday, December 20, 2010 4:07 AM
To: ORACLE-L
Subject: creative use of storage snapshots.

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
--

http://www.freelists.org/webpage/oracle-l Received on Mon Dec 20 2010 - 07:57:56 CST

Original text of this message