Re: RMAN Incremental Strategy for Migrating VLDB

  • From: Mladen Gogala <gogala.mladen@xxxxxxxxx>
  • To: DOUG KUSHNER <dougk5@xxxxxxx>, oracle-l@xxxxxxxxxxxxx
  • Date: Tue, 20 Feb 2018 23:19:35 -0500

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@xxxxxxxxx> 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@xxxxxxxxx <mailto:vishnukumarmp@xxxxxxxxx>> 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@xxxxxxxxx <mailto:balwanthdba@xxxxxxxxx>> 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@xxxxxxxxx <mailto:andrew.kerber@xxxxxxxxx>> 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@xxxxxxxxx <mailto:balwanthdba@xxxxxxxxx>> wrote:

        Same endian format

        RHEL 5 ———> RHEL 6

        Sent from my iPhone

        On Feb 17, 2018, at 11:59 AM, Andrew Kerber <
        andrew.kerber@xxxxxxxxx <mailto:andrew.kerber@xxxxxxxxx>>
        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@xxxxxxxxx <mailto:balwanthdba@xxxxxxxxx>> 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@xxxxxxxxxx <mailto:pgr@xxxxxxxxxx>> 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@xxxxxxxxxx
            <mailto:peter.gram@xxxxxxxxxx>

            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/
            <http://dk.linkedin.com/in/petergram/>
            OakTable : oaktable.net/members
            <http://oaktable.net/members>

            On 17 February 2018 at 03:47, Balwanth B
            <balwanthdba@xxxxxxxxx
            <mailto:balwanthdba@xxxxxxxxx>> 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@xxxxxxxxx
                <mailto:andrew.kerber@xxxxxxxxx>> 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@xxxxxxxxx
                <mailto:balwanthdba@xxxxxxxxx>> wrote:
                >>
                >> Yes we are in EE
                >>
                >> Sent from my iPhone
                >>
                >>> On Feb 16, 2018, at 4:37 PM, Andrew Kerber <
                andrew.kerber@xxxxxxxxx
                <mailto:andrew.kerber@xxxxxxxxx>> wrote:
                >>>
                >>> <mime-attachment.html>






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


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

Other related posts: