Re: EMC Clariion "Snaps" for Oracle Backups anyone?
- From: Matthew Zito <mzito@xxxxxxxxxxx>
- To: "Mercadante, Thomas F" <thomas.mercadante@xxxxxxxxxxxxxxxxx>
- Date: Tue, 28 Dec 2004 13:54:37 -0500
Well, it depends on what your backup strategy is. I will confess an
almost complete lack of deep understanding of RMAN, but traditionally
what people use snapshots for is very similar to what they do with RMAN
and BCVs:
-quiesce database (hotbackup mode or similar)
-take snapshot
-un-quiesce database
-mount snapshotted volume somewhere
-back-up datafiles
This is pretty much the same procedure as what you'd do with BCVs, its
just that the mount and back-up component results in I/O against your
production disk volumes. On the other hand, the disk space the
snapshot is taking up is going to be non-existent at first, and
probably grow fairly slowly.
I generally favor snapshots over BCVs, as you get a great deal more
flexibility. Going back to tape is always a mess and takes forever -
much better to be able to go back to a particular snapshot and roll
forward archive logs from there. For example, I know a lot of places
that take snapshots hourly and keep those for several days, then keep
one of those hourly snapshots as a daily for a week. The total amount
of disk space those snapshots will take up is the amount of data that
has changed since the first snapshot a week ago. Also, most snapshot
implementations allow users to look at their own snapshots -
accidentally fat-fingered an rm of some scripts that you use
frequently? Go to the snapshot and recover last hour's copy - no need
to get a sysadmin involved to find a backup tape, restore, add
incrementals, etc. etc.
Also, the ability to keep large numbers of snapshots makes for some
interesting functionality. For example, imagine you're doing a
complicated change control activity involving an oracle patch, pl/sql
changes, schema changes, etc. With a BCV, you can basically break off
the BCV copies in advance, then do the changes. If there's a problem,
you roll all the way back to the beginning with the BCV copy. With a
snapshot, take a snapshot at every step in the process - each snapshot
takes only a few seconds, and you can then if something fails later,
you can roll backwards and forwards to any snapshot in the set and see
what broke your system.
Netapp is leading the pack now with very elegant read-write snapshots
that can be online cloned to new volumes. They're pretty much the only
people doing this at the moment, though I'm sure that will change.
With that, you can take a snapshot of an existing volume and make a
read-write copy of it, make changes, play around, start up an instance
on it, whatever. Then, when you're done, you can either discard the
snapshot, make that snapshot the current "real" view of that device, or
make the snapshot a _new_ volume. If you make it a new volume, the
blocks get copied in the background to new disk space so you don't
share the same physical blocks for I/O.
There's a last class of snapshot-esque functionality that's coming
called Time-addressed storage. There's one or two companies in this
space, but the most prominent is a company called Revivio. Basically,
their box sits between your storage and the hosts and tracks all of the
I/O going to the SAN. It then stores a copy of all of the changed
blocks in cheap disk that it has internally. The user then gets the
option of rolling back the view of their storage to any point in time
as far back as you want. If you then decided to make a particular view
the "live" view, it will in the background copy blocks from the revivio
to the SAN, making it exactly as it was at the point in time decided.
Pretty neat stuff, overall. It's certainly theoretically possible to
do functionality like this with BCVs, but it gets tricky, managing
large numbers of mirrored copies of data, and writes become
increasingly more expensive with multiple mirrors. From a straight
data backup perspective, BCVs have as much to offer as snapshots, but
the flexibility of snapshots and the ease of use can add a lot of
possibilities to most organizations.
Thanks,
Matt
(who has a lot of spare time on his hands today waiting for a database
instance to come up)
--
Matthew Zito
GridApp Systems
Email: mzito@xxxxxxxxxxx
Cell: 646-220-3551
Phone: 212-358-8211 x 359
http://www.gridapp.com
On Dec 28, 2004, at 1:14 PM, Mercadante, Thomas F wrote:
> Matt,
>
> Thanks for the explanation of the differences. So how would one
> implement
> this snap functionality with an Oracle database (or would it be
> appropriate
> to do so?) I would not feel good using this as part of a backup
> strategy,
> would you? How would it be useful?
>
> Thanks,
>
> Tom
>
> -----Original Message-----
> From: Matthew Zito [mailto:mzito@xxxxxxxxxxx]
> Sent: Tuesday, December 28, 2004 12:35 PM
> To: fuadar@xxxxxxxxx
> Cc: oracle-l@xxxxxxxxxxxxx
> Subject: Re: EMC Clariion "Snaps" for Oracle Backups anyone?
>
>
> The snap functionality being described is very different from BCVs. A
> bcv is a real third-mirror copy of the data. A snap, or snapshot, is a
> "virtual" or fake disk that is a representative image of the volume at
> a given point-in-time. The snapshot takes up only as much disk space
> as what has changed on disk since the snapshot has been taken. Better
> snapshot implementations can do cascading snapshots, where all of the
> snapshots only take up as much disk space total as has changed since
> the first snapshot.
>
> The disadvantage of snapshots is that any disk I/O to the snapshot
> actually goes to the live disk, so using snapshots for I/O intensive
> operations could impact the performance of your production database.
> The advantage is that while you can only have one, or possibly two, BCV
> copies of a disk, you could have potentially hundreds of snapshots, and
> can roll back your live image to any one of those snapshots online.
>
> Thanks,
> Matt
>
> --
> Matthew Zito
> GridApp Systems
> Email: mzito@xxxxxxxxxxx
> Cell: 646-220-3551
> Phone: 212-358-8211 x 359
> http://www.gridapp.com
>
>
> On Dec 28, 2004, at 9:32 AM, Fuad Arshad wrote:
>
>> by snaps do you mean emc splits. if so thisis only adisk split and
>> hardware issues can arise causing you to lose disk. and we've had to
>> deal with situations like those.
>> We do use emc bcv splits but fro a shot period of time.
>> the pupose if to keep data current in case o any mishap
>> but tape recover is still importnat.
>> it also depends o the nature and colatility of the data.
>> why does your integrator only want snaps.
>> is there a problem(performance issue) with backing up the primary db.
>> if so emc can get backups of the split to tape also.
>>
>>
>> "Daiminger, Helmut" <HELMUT.DAIMINGER@xxxxxx> wrote:
>> Hi!
>>
>> We just bought two EMC Clariion CX700 boxes as SAN storage. The boxes
>> are primarily used for Oracle databases. Our system integrator is
>> trying
>> to persuade us to use "snaps" for database backups.=20
>>
>> Is anybody out there running a similar configuration and can share
>> their
>> expieriences?
>>
>> This is 9.2 on HP-UX 11i.
>>
>> Thanks,
>> Helmut
>> --
>> //www.freelists.org/webpage/oracle-l
>>
>>
>>
>> --
>> //www.freelists.org/webpage/oracle-l
>
> --
> //www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
