RE: For those using snapshots of Prod Disk Groups - Question

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Wed, 10 Jan 2018 17:46:09 -0500
Message-ID: <102601d38a64$cf257ea0$6d707be0$_at_rsiz.com>



That process should work. Prior to RMAN, I automated the backup and clone process (also startup rename to get a point in clone of a database).  

Now there are many better solutions to that and two vendors have frequent contributors to the list.  

But I digress. For ease of use, back up your control file before and after the snapshot of the files.  

The versions to trace can then be diffed to see whether any surgery needs to be done.  

From: Noveljic Nenad [mailto:nenad.noveljic_at_vontobel.com] Sent: Wednesday, January 10, 2018 4:13 PM To: 'Mark W. Farnham'; christopherdtaylor1994_at_gmail.com; 'ORACLE-L' Subject: RE: For those using snapshots of Prod Disk Groups - Question  

Hi Mark,  

After reading your comment about the online redologs I realized that I omitted an important piece of information when describing the snapshoting process. So, I'd like to provide an additional clarification.  

After "alter system archive log current" and prior to snapshoting the file system with the archivelogs I'm querying the latest archived SCN. The database will be recovered until this SCN in the course of rollback/clone process. This means that the online redo logs will not be used at all when rolling back to the "hot" snapshot. In contrast, the snapshot online of redo logs is only used when rolling back the "cold" snapshot.  

In addition, I'd like to point out that there is a boundary condition that might render the snapshot unusable. What I mean by that is if new datafiles were created in the short time period between data file snapshot and control file backup, the files will be referenced in the control file backup, but not contained in the snapshot. Therefore, it is necessary check whether new files were created in the mentioned time period if there is a possibility that new datafiles are created by some automatic process which might run concurrently with snapshoting.  

Hence, the process would look like this:  

Alter database begin backup;

Snapshot file systems with data files

Alter database end backup;

alter database backup controlfile to trace as .. ;

raise exception if new files were created since the snapshot

alter system archive log current

save the scn for the recovery => scn = select max(next_change#) from v$log_history

Snapshot file systems with the archivelogs  

Finally, I'd like to thank you for making me aware of the mistake I did in my previous e-mail.  

Best regards,  

Nenad  

http://nenadnoveljic.com/blog/      

From: Mark W. Farnham [mailto:mwf_at_rsiz.com] Sent: Mittwoch, 10. Januar 2018 17:35
To: Noveljic Nenad; christopherdtaylor1994_at_gmail.com; 'ORACLE-L' 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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Noveljic Nenad Sent: Wednesday, January 10, 2018 10:53 AM To: 'christopherdtaylor1994_at_gmail.com'; 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/> http://nenadnoveljic.com/blog/      

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] 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.

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.

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Jan 10 2018 - 23:46:09 CET

Original text of this message