Yes we do
Take a one time full image copy
Do a daily incremental - merge with the existing image
Take a snapshot (this is using data domain) and do some
housekeeping in RMAN to make this a valid backup as for the date.
And so on
A DG or not should not make a difference
I understand that NetApp has a slightly different snapshot process -
netapp snapshot is for the device not for the directory. So I guess you
will need a different solution with Netapp but I guess this will pretty
much work there also. The technique will have to be slightly different
On Behalf Of Glenn Santa Cruz
Sent: Tuesday, December 21, 2010 12:26 PM
Subject: Re: creative use of storage snapshots.
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.
On Tue, Dec 21, 2010 at 11:10 AM, Niall Litchfield
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"
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
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.
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...http://www.freelists.org/webpage/oracle-l
Please visit our website athttp://financialservicesinc.ubs.com/wealth/E-maildisclaimer.html
for important disclosures and information about our e-mail
policies. For your protection, please do not transmit orders
or instructions by e-mail or include account numbers, Social
Security numbers, credit card numbers, passwords, or other