Different MOS Notes for xTTS PERL scripts – Use V4 scripts

A long time ago my colleagues published PERL scripts to assist especially with cross platform Transportable Tablespace migrations. The PERL scripts allow you to utilize incremental backups. This way you can decrease the downtime in a migration with large databases significantly. But there are different MOS Notes for xTTS PERL scripts available. Which one should you take?

Photo by VanveenJF on Unsplash

Transportable Tablespaces and Incremental Backups

The biggest pain points in a transportable tablespace migration are usually the size of the database and its complexity. With RMAN Incrementally Rolled Forward Backups you can tackle the size aspect. Instead of having a long downtime to copy terabytes of files from A to B during the read-only phase of the transport activity (tablespaces have to remain in read-only mode for transportable tablespaces during the copy and export meta contents operation), you can leverage incremental backups.

You will always start with a Level-0 imagefile copy backup which has the same size as your database. But your tablespaces can remain read-write mode during the backup.

In the following phase you will create Level-1 incremental backups. With those, you will roll forward. Still your tablespaces remain read-write.

When you get downtime, the tablespaces need to be set into read-only mode before you trigger the final incremental backup and roll forward again. But this final incremental backup usually has just a few gigabyte. It completes much faster than a copy operation of terabytes. Then you will start the transport phase.

In order to ease that process of RMAN Incremental Backups, even cross platform and cross Endianness, we deliver PERL scripts. You can download them from MOS notes.

The PERL scripts

You can find two showcase presentations explaining the PERL scripts a bit more in detail in the Slides Download Center on the blog.

Migrate to ExaCC with TTS and Incremental Backups

Migrate to ExaCC with TTS and Inc Backups

VLDB Migrations - FTEX, RMAN

Large Database Migrations with
RMAN Incremental Backups and Full Transportable

The following MOS Notes give you access to PERL scripts supporting the RMAN Incremental Backup path together with either Transportable Tablespaces or Full Transportable Export Import:

The last MOS Note refers to a special version for the Zero Data Loss Recovery Appliance which is a big added value if you have a ZDLRA or plan to purchase one: It can become your migration vehicle. See the Migrate to ExaCC slides above for more details.

Which PERL scripts should you use?

Clearly you should use the PERL scripts V4 delivered via MOS Note: 2471245.1.

We keep the previous versions of the scripts on MOS only in case you started a project already. The V3 version got updated with the most recent fixes but MOS Note: 2471245.1 has the new and improved version of the scripts (V4) which you should use from now on.

To point to the new V4 release, the older notes have now this INFORMATION BOX:

NOTE: Consider using the new release of this procedure, version 4. This version has drastically simplified the steps and procedure. Before proceeding, review:
V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup Note 2471245.1

–Mike

Share this:

16 thoughts on “Different MOS Notes for xTTS PERL scripts – Use V4 scripts

  1. Hi,
    Mike, a little bit off-topic questions: can we use Full Transportable tablespaces to migrate 12.1.0.2 non-pdb to
    12.2.0.1 pdb ? Is this covered anywhere in documentation ?
    Regards,
    Artem

  2. Hello Mike,
    I’m not able to retrieve any MOS note referenced in your article.
    The 3 notes states “Document cannot be displayed…”
    Do you know any reason for that ?
    Regards

    • Leygonie,

      sorry for the inconvenience – the owner put the notes into REVIEW state to implement some changes (I guess).
      I can’t access them either right now through the external portal.

      They should be visible again soon.

      Sorry for the inconvenience 🙁
      I dropped the owner an email.

      Cheers,
      Mike

  3. Hello Mike,

    I am currently doing a proof of concept to migrate AIX (Big Endian) databases to Linux x86_64 (Little Endian). Just mentioning Endianess for clarity’s sake. We are running Oracle 12.1.0.2 (July 2018 PSU) for both the source and target.
    I have read through the official documentation regarding Transporting Data Across Platforms and also read through most of the MOS notes including this MOS Note you are mentioning above: 2471245.1 – V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup. I also openend various service requests to confirm the right procedure for this and also for some problems I am having which I mention below

    As our databases ranges between 3 and 12 TB we will use this incremental approach with V4 Perl Scripts as I can’t see any other alternatives?

    I am currently doing the first tests manually with setting all tablespaces to read-only and without the Perl Scripts to get a feel for the process and I am running into problems with self-containment in the Data Pump section. So if my understanding is correct the datapump export contains the metadata required to plug the tablespaces into the destination database? The Core Banking application uses partioning for archiving old data and this seems to be causing all the self-containment issues.
    Another thing to note is that most of the business code is PL/SQL so what about the Dictionary?

    Below is the rman command and some output produced during logging

    backup to platform ‘Linux x86 64-bit’
    format ‘//linux_x86_64_d-%d_s-%s.bck’
    datapump format ‘//linux_x86_64_d-%d_s-%s.dmp’
    tablespace
    ;

    Running TRANSPORT_SET_CHECK on specified tablespaces
    TRANSPORT_SET_CHECK completed successfully
    Performing export of metadata for specified tablespaces…
    EXPDP> Starting “SYS”.”TRANSPORT_EXP_XXXXXXXX_aump”:
    EXPDP> ORA-39123: Data Pump transportable tablespace job aborted
    ORA-39187: The transportable set is not self-contained, violation list is
    ORA-39901: Partitioned table x.xxxxxxx is partially contained in the transportable set.

    So my question – is there a way to get around this self-containment issue? The software provider will not change this mechanism so that is not an option. Are there any alternatives to this procedure?

    Not sure if is the right medium for asking but I thought I’d put it in the comments in any case. Maybe you have some ideas on how to tackle this differently?

    Regards
    Neil

    PS. I have generated a pdf from the MOS Note 2471245.1 before it went down 🙂

    • Neil,

      ALL data tablespaces need to be in R/O phase at the same time when you’d like to transport.
      Unless you have user objects in SYSTEM tablespace (or SYSAUX), the “self contained” check will succeed when you run it on all of the tablespaces you will transport in one call. Please check this – there’s no way around this.

      Cheers,
      Mike

      • Hi Mike

        Thanks so much for your reply. All tablespaces are set to R/O and we don’t have objects in SYSTEM or SYSAUX.
        If I run dbms_tts.transport_set_check on the tablespace list then there are no violations.

        Below the snippet from the backup to platform ‘Linux x86 64-bit’…

        Starting backup at 29-JAN-19
        Running TRANSPORT_SET_CHECK on specified tablespaces
        TRANSPORT_SET_CHECK completed successfully

        Performing export of metadata for specified tablespaces…
        EXPDP> Starting “SYS”.”TRANSPORT_EXP_AT50DB01_aump”:
        EXPDP> ORA-39123: Data Pump transportable tablespace job aborted
        ORA-39187: The transportable set is not self-contained, violation list is

        We traced this today and noticed that the not all tablespaces are processed so I have a strong feeling this could be a bug. Information in SR 3-19259291331. Basically what happens is that not all tablespace in the list I provide are processed which in turn then causes the ORA-39187.

        Just a side note. The tablespace list is huge 🙁 Nothing I can do about it. This is our core banking application.

        Regards
        Neil

  4. Hello Mike,

    Another excellent article that makes an excellent bookmark for one of the most important aspects (DB Migration).
    Like Leygonie mentioned above, it seems the issue of multiple MOS notes not being accessible appears to be universal (??). Any idea if this is being dealt with? I have opened a SR 3-19262566371 for the same yesterday but no sign of any resolution in sight so far.

    • Narendra,

      I have realized this as well. And I have seen no official statement yet regarding this.
      Please open an SR and ask the support folks what is going on.

      This is beyond our control unfortunately.

      Cheers,
      Mike

  5. Hi, Mike,

    Thanks for the blog, really hope you have influence on prioritizing of XTTS related enhancement and bug fix. I am dealing with 800TiB+ database migration, really hope the section size could be added to xtts scripts, filed an enhancement bug 29036164 in mid Dec, but was told the enhancement is still many months away (because a bug related to using section size in perl script needs to be fixed first). Have a few bigfiles that are 85TiB+ and growing. The non-restart-able nature of using XTTS script set compared to regular RMAN is also not helpful. But the V3/4 are confirmed to be able to handle added new tablespaces, the restart of level 0 (continuing from the completed tablespace backups) is possible, the run will be treated as level 1 for those already backed up, the level 0 copy will be generated for the new tablespaces.

    Thanks a lot

    • Thanks Z.

      Uhh … that’s quite a big database.
      Would you please mind if you’d drop me an email (mike.dietrich …. at ….. oracle.com)?

      Then we can discuss this in a bit more detail and can include the responsible people.

      Cheers,
      Mike

  6. Hello Mike!
    V4 script contains this:
    In version 3 important features are
    # 1. Standby support

    ## allowstandby
    ## ———
    ## This will allow the script to be run from standby database.
    allowstandby=1

    but at MOS 2471245.1 I do see this
    “It is not supported to execute this procedure against a standby or snapshot standby databases.”

    Is that just a misleading documentation?

    Thanks

    • Hi Den,

      you will need to open an SR for this unfortunately. Or tried it by yourself. Or quickly check the PERL script if it contains functionality for this switch.

      I think the support should be there now – and I guess the MOS note is not in synch with it yet.

      Cheers,
      Mike

Leave a Reply

Your email address will not be published. Required fields are marked *

* Checkbox to comply with GDPR is required

*

I agree

This site uses Akismet to reduce spam. Learn how your comment data is processed.