I did a blog post on this subject at
http://people.ds.cam.ac.uk/psh35/blog/post/crashconsistentrecovery/. See Oracle ;
support note 604683.1 for information, but so far as I can see it is supported
for 12c if you have “crash consistent” snapshots, and know when the snapshot
was taken.
We have the entire database on one SAN volume, so it includes the flash
recovery area and the online redo logs. I didn’t test whether you can do it
without including the flash recovery area. Clearly you should test your
approach to see whether it works or not.
We don’t use this approach for production, which for weird reasons is on local
storage.
Cheers
PaulH
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Mark W. Farnham
Sent: 10 January 2018 16:35
To: nenad.noveljic@xxxxxxxxxxxx; christopherdtaylor1994@xxxxxxxxx; 'ORACLE-L'
<oracle-l@xxxxxxxxxxxxx>
Subject: RE: For those using snapshots of Prod Disk Groups - Question
If you reload the snapshots containing the online redo logs you will likely be
in for an unpleasant surprise.
Online redo logs should only be on a special backup set for complete point in
time recovery (if they are backed up at all, which is a discussion of the
relative danger of reloading online redo logs when you didn’t mean to versus
someone deleting them before they are archived in rotation or backed up by some
other means.)
Backing up the current online redo logs (and the control files) to a special
media set is a valid first step of recovery that allows you multiple attempts a
complete recovery if something goes bump in the night during recovery. This all
applies to recovering physical backups unmanaged by RMAN, which has been
essentially the same since 6.0.
Find yourself a test host network isolated from your real host and practice
this snapshot recovery a few times to be certain of what you have.
The other thing is to make sure the archive log current completes before you do
the snapshot archive logs operation.
mwf
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Noveljic Nenad
Sent: Wednesday, January 10, 2018 10:53 AM
To: 'christopherdtaylor1994@xxxxxxxxx'; ORACLE-L
Subject: RE: For those using snapshots of Prod Disk Groups - Question
I’m using the following process for snapshoting database in archivelog mode
without stopping it:
Alter database begin backup;
Snapshot file systems with data files and online redo logs
Alter database end backup;
alter database backup controlfile to trace as .. ;
alter system archive log current ;
Snapshot file systems with the archivelogs
In the case of rollback:
Stop the database
Rollback all file systems
Recreate controlfile and recover
(Change dbid to avoid conflicts in RMAN)
I also use snapshots for “database cloning” where a new database is created
based on the snapshot. The process is similar to rollback except that new file
systems are created based on the snapshot and the controlfile backup (as trace)
has to be edited to reflect the name of the new database and new file locations.
In case that you’re stopping the source database when doing the snapshot, the
FRA is not necessary.
I rely on ZFS instead of storage copy-on-write functionality.
Last but not least, as you correctly mentioned, snapshotting is no replacement
for backup/recovery, but is very useful when doing application and database
upgrades. It is also invaluable for quick provisioning of development databases.
Best regards,
Nenad
http://nenadnoveljic.com/blog/
From: oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Chris Taylor
Sent: Mittwoch, 10. Januar 2018 16:21
To: ORACLE-L
Subject: For those using snapshots of Prod Disk Groups - Question
For those of you utilizing storage snapshots of your Prod disk groups, do you
also include the FRA contents in your snapshots?
There's an open question we're discussing about whether we need the FRA
contents as part of the snapshot.
(We're only using snapshots as protection against screw ups - not as a
backup/recovery option. So if we really, really had to we could restart the
database from a previous snapshot - or clone the snapshot to a utility server
to do some data restoration)
I'm thinking the FRA contents don't need to be part of the snapshot but I could
be mistaken.
Chris
____________________________________________________
Please consider the environment before printing this e-mail.
Bitte denken Sie an die Umwelt, bevor Sie dieses E-Mail drucken.
Important Notice
This message is intended only for the individual named. It may contain
confidential or privileged information. If you are not the named addressee you
should in particular not disseminate, distribute, modify or copy this e-mail.
Please notify the sender immediately by e-mail, if you have received this
message by mistake and delete it from your system.
E-mail transmission may not be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also
processing of incoming e-mails cannot be guaranteed. All liability of the
Vontobel Group and its affiliates for any damages resulting from e-mail use is
excluded. You are advised that urgent and time sensitive messages should not be
sent by e-mail and if verification is required please request a printed version.
