Re: RMAN Incremental Strategy for Migrating VLDB

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> 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> 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>
> 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> 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>
> 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 <+45%2053%2074%2071%2007>
>> Office Phone: (+45) 44668855 <+45%2044%2066%2088%2055>
>> Mail: peter.gram_at_miracle.dk
>>
>> Home : (+45) 38745696 <+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/
>> OakTable : oaktable.net/members <http://oaktable.net/members>
>>
>> On 17 February 2018 at 03:47, Balwanth B <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>
>>> 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>
>>> 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>
>>> wrote:
>>> >>>
>>> >>> <mime-attachment.html>
>>>
>>
>>
>

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