Re: RMAN Incremental Strategy for Migrating VLDB

If you dont use HCC it doesnt matter.

Thanks

On Wed, Feb 21, 2018 at 5:19 AM, Mladen Gogala <gogala.mladen_at_gmail.com> wrote:

> That's really interesting. How did you get around HCC (Hybrid Columnar
> Compression)? No instance can access those columns, unless the instance is
> on Exadata or the database is stored on Oracle storage (Axxion, ZFS
> appliance).
>
> On 02/20/2018 12:43 PM, DOUG KUSHNER wrote:
>
> We physically moved an Exadata containing physical standby databases to a
> DR site recently and used this process which leverages incremental backups
> to catch-up the databases:
>
> Steps to perform for Rolling Forward a Physical Standby Database using
> RMAN Incremental Backup. (Doc ID 836986.1)
>
> On February 18, 2018 at 5:08 PM Mladen Gogala <gogala.mladen_at_gmail.com>
> <gogala.mladen_at_gmail.com> wrote:
>
> 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> 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>
> 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>
>> 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
>>>> Office Phone: (+45) 44668855
>>>> Mail: peter.gram_at_miracle.dk
>>>>
>>>> Home : (+45) 38745696
>>>> 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>
>>>>>
>>>>
>>>>
>>>
>>
>
> --
> Mladen Gogala
> Database Consultant
> Tel: (347) 321-1217
>
>
>
>
>
> --
> Mladen Gogala
> Database Consultant
> Tel: (347) 321-1217
>
>

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