Re: RMAN Incremental Strategy for Migrating VLDB

This wouldn't be complete without mentioning Commvault:

http://documentation.commvault.com/commvault/v11/article?p=products/oracle/p_ora_instant_app_config.htm

Regards

On 02/18/2018 02:10 PM, Andrew Kerber wrote:
> Ok.  In that case, this is the only way to do that:
> https://oracle-base.com/articles/misc/incrementally-updated-image-copy-backups
>
> Sent from my iPad
>
> On Feb 17, 2018, at 8:33 PM, Vishnu <vishnukumarmp_at_gmail.com
> <mailto:vishnukumarmp_at_gmail.com>> wrote:
>
>> Yes, you can take incremental backup and still would be able to run
>> recover using incremental (as long as the db is not opened).. catalog
>> the incremental backup that you took from primary to standby..and
>> recover will pickup the incremental backup..
>>
>> There are many instances where standby lags than primary by several
>> hours/days due to missing archive logs, n/w issues etc, in these
>> cases copying all archivelogs from source db may not be possible or
>> not available due to various reasons or simply much time consuming
>> due to very large number of archive logs generated.. and incremental
>> backup and restore are very  useful in these scenarios..
>>
>> On Sat, Feb 17, 2018 at 8:11 PM, Balwanth B <balwanthdba_at_gmail.com
>> <mailto:balwanthdba_at_gmail.com>> wrote:
>>
>> Thanks for the reply. I am not against standby, I will propose
>> the Standby strategy to management . On other hand, I was
>> learning this method for my knowledge.
>>
>> One question in line. You're answer will be helpful.
>> *
>> *
>> Backup dB on current server, including archive logs
>> Restore and *recover* on new server (do not open DB).
>> The next day, backup archivelogs and copy to new server (or just
>> copy them).
>> *(question) can't I take incremental backup instead of just
>> archive logs. If yes, In previous run if we run recover, then how
>> I can apply incremental backup after running recover command. *
>> Catalog backup files or archive logs using rman ‘catalog start
>> with...’ command.
>> Recover database on new server (do not open db).
>> Repeat each day, or whatever interval is required. **
>> *
>> *
>>  Your answer will be help ful
>>
>>
>> Thanks,
>>
>> Balwanth
>>
>>
>> On Sat, Feb 17, 2018 at 2:22 PM, Andrew Kerber
>> <andrew.kerber_at_gmail.com <mailto:andrew.kerber_at_gmail.com>> wrote:
>>
>> Ok, then why don’t you want to do a standby?   In any case,
>> if you insist on this incremental process, the basic steps
>> are as follows:
>>
>> Backup dB on current server, including archive logs
>> Restore and recover on new server (do not open DB).
>> The next day, backup archivelogs and copy to new server (or
>> just copy them).
>> Catalog backup files or archive logs using rman ‘catalog
>> start with...’ command.
>> Recover database on new server (do not open db).
>> Repeat each day, or whatever interval is required.
>>
>> The key to the process is you only restore the control file
>> the day you run the restore command, the following days you
>> use the same control file because it keeps track of your
>> recovery state.
>>
>>
>> Sent from my iPad
>>
>> On Feb 17, 2018, at 2:05 PM, Balwanth B
>> <balwanthdba_at_gmail.com <mailto:balwanthdba_at_gmail.com>> wrote:
>>
>>> Same endian format
>>>
>>> RHEL 5 ———> RHEL 6
>>>
>>> Sent from my iPhone
>>>
>>> On Feb 17, 2018, at 11:59 AM, Andrew Kerber
>>> <andrew.kerber_at_gmail.com <mailto:andrew.kerber_at_gmail.com>>
>>> wrote:
>>>
>>>> If you are changing endian format that’s you only option. 
>>>> The file formats between big endian and little endian are
>>>> not compatible.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Feb 17, 2018, at 12:52 PM, Balwanth B
>>>> <balwanthdba_at_gmail.com <mailto:balwanthdba_at_gmail.com>> wrote:
>>>>
>>>>> Thanks for sharing that, Is this the only way
>>>>> Transportable Tablespace?  I was more of looking a DOC for
>>>>> below way. In general,Is this possible? Is there a DOC for
>>>>> this?
>>>>>
>>>>>
>>>>> 1) Do a online backup and restore on new site(restore
>>>>> database)
>>>>> 2) Take a incremental backup and again do restore (restore
>>>>> latest control file and do restore database) ---> like 2
>>>>> or 3 iterations
>>>>> 3) on cut-over day, take last incremental backup and then
>>>>> do (restore  database and recover database)...
>>>>> 4) alter database resetlogs; and open for users
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Balwanth
>>>>>
>>>>> On Sat, Feb 17, 2018 at 6:23 AM, Peter Gram Miracle A/S
>>>>> <pgr_at_miracle.dk <mailto:pgr_at_miracle.dk>> wrote:
>>>>>
>>>>> Hi
>>>>>
>>>>> I think the this is the support note you were looking
>>>>> for  "11G - Reduce Transportable Tablespace Downtime
>>>>> using Cross Platform Incremental Backup (Doc ID
>>>>> 1389592.1)"
>>>>>
>>>>> Gram/
>>>>>
>>>>> Med Venlig Hilsen
>>>>>
>>>>> Peter Gram
>>>>>
>>>>> Kultur-kustode for Miracle
>>>>>
>>>>> - we dare - we share - we care -
>>>>>
>>>>> *Miracle A/S*
>>>>> Borupvang 2c, 2750 Ballerup, Denmark
>>>>> <https://maps.google.com/?q=Borupvang+2c,+2750+Ballerup,+Denmark&entry=gmail&source=g>
>>>>> Cell: (+45) 53747107 <tel:+45%2053%2074%2071%2007>
>>>>> Office Phone: (+45) 44668855
>>>>> <tel:+45%2044%2066%2088%2055>
>>>>> Mail: peter.gram_at_miracle.dk <mailto:peter.gram_at_miracle.dk>
>>>>>
>>>>> Home : (+45) 38745696 <tel:+45%2038%2074%2056%2096>
>>>>> Home : Sæbyholmsvej 18
>>>>> <https://maps.google.com/?q=S%C3%A6byholmsvej+18&entry=gmail&source=g>
>>>>> 2500 Valby
>>>>>
>>>>> linkedin: dk.linkedin.com/in/petergram/
>>>>> <http://dk.linkedin.com/in/petergram/>
>>>>> OakTable : oaktable.net/members
>>>>> <http://oaktable.net/members>
>>>>>
>>>>> On 17 February 2018 at 03:47, Balwanth B
>>>>> <balwanthdba_at_gmail.com <mailto:balwanthdba_at_gmail.com>>
>>>>> wrote:
>>>>>
>>>>> Thanks for the response , I will propose this to
>>>>> my management. On other side, can I still get a
>>>>> doc ID or link on how to do Rman incremental
>>>>> strategy for my educational purpose. Thanks in
>>>>> advance!!!
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> > On Feb 16, 2018, at 6:45 PM, Andrew Kerber
>>>>> <andrew.kerber_at_gmail.com
>>>>> <mailto:andrew.kerber_at_gmail.com>> wrote:
>>>>> >
>>>>> > In that case a dataguard standby is really the
>>>>> way to go.
>>>>> >
>>>>> > Sent from my iPad
>>>>> >
>>>>> >> On Feb 16, 2018, at 6:28 PM, Balwanth B
>>>>> <balwanthdba_at_gmail.com
>>>>> <mailto:balwanthdba_at_gmail.com>> wrote:
>>>>> >>
>>>>> >> Yes we are in EE
>>>>> >>
>>>>> >> Sent from my iPhone
>>>>> >>
>>>>> >>> On Feb 16, 2018, at 4:37 PM, Andrew Kerber
>>>>> <andrew.kerber_at_gmail.com
>>>>> <mailto:andrew.kerber_at_gmail.com>> wrote:
>>>>> >>>
>>>>> >>> <mime-attachment.html>
>>>>>
>>>>>
>>>>>
>>
>>

-- 
Mladen Gogala
Database Consultant
Tel: (347) 321-1217



--
http://www.freelists.org/webpage/oracle-l