Re: creative use of storage snapshots.
- From: Glenn Santa Cruz <glenn.santacruz@xxxxxxxxx>
- To: ORACLE-L <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 21 Dec 2010 11:26:15 -0600
Grateful to all who have weighed in on this topic.
Could you share experiences using these same tools/techniques in keeping a
backup retention with RMAN ? We've been considering using techniques as
described to achieve a backup retention of 30 days (per our corporate
policy), leveraging snapshots to accomplish it. The basic idea is to "seed"
a volume with a full RMAN backup; then on a daily basis, perform a snapshot
of the volume, issue our RMAN backup (applying changes to the datafiles),
then delete any snapshots older than the retention period. Our thoughts are
that the SAN would maintain 30 snapshots -- if we need a restoration of any
of these points, we'd present the snapshot as a LUN to a secondary host.
Naturally, all of the above is to be done on non-production hardware (
against a dataguard standby database ).
Is anyone doing something similar? Pitfalls? This is on HP EVA 4400.
Thanks
On Tue, Dec 21, 2010 at 11:10 AM, Niall Litchfield <
niall.litchfield@xxxxxxxxx> wrote:
> Thanks to all for the great replies, especially to Kyle for the whitepaper
> link and to those with real life experience in serious oracle shops, its
> nice to know I'm not (that) insane. And to everyone for not mentioning dba
> 2.0 even though this is a great example of it, even to the way it came
> about. If project and client permits I'll likely blog it - first got to get
> the project started.
>
> On 21 Dec 2010 12:03, "Svetoslav Gyurov" <softice@xxxxxxxxx> wrote:
>
> Hi Niall,
>
> It's a great technology which saves a lot of time and space. I've done this
> with EVA6100 for a local bank for a reporting purpose. They were running
> three node RAC which is used for their core banking and another single
> machine for reporting. Just to mention they were using two virtual disks,
> one for DATA and one for FRA. Snapshot were created without any preparation
> of the RAC. As Martin said, we were using the same procedure. As very basic
> we were doing snapshot of the DATA disk, presenting snapshot disk to the
> reporting machine, starting in mount, changing some parameters and then
> opening the database. For the purpose of 1-day old reporting it is perfect
> solution.
>
> Using snapshot (not snapclone) was very convenient, because at the end of
> the day only few percent’s were filled up of the snapshot. For example if
> the DATA disk is 1TB big the snapshot and the of the end would be 10-20GB
> maximum (it really depends on how intensive is the workload on the
> database). As the snapshot is deleted and re-created everyday this was very
> space saving scheme and we didn't notice any performance issues on the
> production database. Although this process can be automated they were using
> the GUI for single disk snapshots.
>
> Here comes the limitations (at least of the EVA):
> 1. With the last version of the firmware for 4/6/8400, HP introduced LUNs
> bigger than 2TB, which is a breakthrough. I recently discovered that neither
> snapshots nor snapclones bigger than 2TB can be created!
> 2. If one wants to create a snapshot of two disks simultaneously
> (multisnap) the GUI cannot be used any longer.
> 3. Creating multisnap requires fully allocated containers! i.e. the size of
> the LUNs. Although the snapshot is immediately created is it using now the
> same size as the original virtual disks.
>
> Except for reporting, test and dev these snapshot and snapclones could also
> be used for backup. In case of doing database or application upgrades this
> can be used as very fast recovery solution.
>
>
> Regards,
> Sve
>
>
>
>
>
>
>
> On 12/20/2010 02:07 PM, Niall Litchfield wrote:
>
>
> >
> > Hi List
> >
> > I have a client with storage technology that allows copy on write
> snapshots to cr...
> -- //www.freelists.org/webpage/oracle-l
>
>
Other related posts:
