Re: block chg tracking
Date: Sat, 14 Feb 2015 16:18:08 -0500
Message-Id: <653DF30A-79B9-43AB-B934-1726558FE68D_at_gmail.com>
reply to your reply inline your inline.
> On Feb 14, 2015, at 4:01 PM, Mladen Gogala (Redacted sender "mgogala_at_yahoo.com" for DMARC) <dmarc-noreply_at_freelists.org> wrote:
>
> Comments in-line:
>
> On 02/14/2015 06:48 AM, Kenny Payton wrote:
>> >> We moved our local standby databases to netapp (any snapshot storage could suffice) and replaced RMAN backups with standby snapshots. >>
>
> Why are you backing up standby databases?
We’re taking snapshots of the physical standby and using them as image file copy backups for the primary. If I have to do a block recovery in production I catalog the affected datafile to the latest snapshot prior to the corruption, catalog any necessary log files and then perform block recovery. The snapshots are mounted on the primary for easy access via DNFS. This works for block recovery, file recovery, database recovery, etc…
> Aren't they supposed to be copies of production?
Yes, they are copies of production ( physical standby ).
> What do you do during DR tests, when typically a switch-over is performed?
>
We have local DG copiesl ( same data center ) and remote DG ( different state ) for DR. We do use local standby’s for some types of testing and the snaps have actually made our lives much easier. We used to open the DG copy read/write with a guaranteed restore point set and after the testing we would flash back and get the DG wheels back on the bus to get caught up. Now we take a snapshot and mount it to an alternate location and perform the testing there. With Netapp you create a flex clone from a snapshot and that becomes a read/write copy of the snap. Both are just maps to the original unchanged blocks and space required is based on deviation from the original.
Our local DG copies do not have the IO bandwidth to support our full production load so a switchover would only be used if something really bad happened and in that event we would run in a degraded state until we rebuild the original ( all flash ) array.
>> This gives us image file full backups every two hours. It also removed the RMAN cpu/io from production. >>
>
> What is the database version? Snapping a database without putting it into the backup mode is only supported as of Oracle 12c:
>
> https://docs.oracle.com/database/121/RCMRF/rcmsynta2001.htm#RCMRF140
>
We stop the apply process before taking the snaps of the standby but are only doing this out of paranoia. As long as you can ensure you are getting a consistent snapshot of all devices recovery is crash recovery.
>> We rely on autobackup for controlfile and spfile. >>
>
> How about archive logs? If you don't have rman backup of the latest archive logs, you cannot recover to current time..
Archived logs are shipped and applied to the standby and then removed from the primary. The archived logs shipped to the standby serve as the backup of the archived logs. We ensure logs have been applied to the standby before removing them to ensure there were no issues during transport.
>
>
>
> --
> Mladen Gogala
> Oracle DBA
> http://mgogala.freehostia.com
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Sat Feb 14 2015 - 22:18:08 CET