Yesterday I was browsing around for a useful simple example to test Transportable Tablespaces. A colleague mailed with the other day with a strange error message. The attempt to import into a PDB in Oracle 19c failed. My first thought: Oh, this is simple. But I failed, too. And even worse, I couldn’t find a single useful note in MyOracle Support (MOS) for ORA-31640, ORA-27037, Linux-x86_64 Error: 2 with Additional information: 7. So I decided to summarize this in Transportable Tablespaces – Example and strange error with a PDB.
This was the question I received the most often during the Virtual Classroom web seminars last week: “Can you say something about EBS upgrades with 19c?”. And I promised to publish a blog post about it. But as I’m not an EBS expert, I can only share a Collection of EBS upgrade information for Oracle Database 19c. For all further inquiries, please open an SR or get in touch with your Oracle contact.
Recap – EBS and Oracle 19c
In September 2019, right before Oracle Open World, we announced the certification of EBS …Continue reading...
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?
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 …Continue reading...
I thought I had blogged about this topic already. But it seems to be that I stored this information somewhere else. Randomly I receive this question: Oracle Transportable Tablespaces – Does it work between SE2 and EE?
In addition often the question gets precised: Does it work in both directions or just one-way?
Transportable Tablespaces and Full Transportable Export/Import
Please find more information about these two very common Oracle database migration features:
- Transportable Tablespases: Character Sets – Same same but different? (May 25, 2016)
- Transportable Tablespaces and Read-Only in Oracle 12c (Dec 2, 2016)
- Full Transportable Export/Import – Things
This topic fits very well as I present about +100 TB migrations today at the “Harmony” User Group Conference in Finland.
The question whether the PERL scripts for RMAN incrementally rolled forward backups we deliver via MOS Note 1389592.1 (11G – Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup) will be supported for migrations to non-Exadata systems such as Oracle SuperCluster as well.
And yes, now we got an update into the note saying:
Although preferred destination system is Linux (either 64-bit Oracle Linux or a certified version of RedHat Linux), this procedure can be used …Continue reading...
Question: Can you EXCLUDE one or more tablespaces when doing a Full Transportable Export/Import?
First of all, this question came up already twice in real world customer migrations. So it’s not a totally unusual question. In one case a tablespace called USERS got precreated and some data did get stored. In the second case we did use RMAN incremental backups to migrate a very large database (>100TB) and some tablespaces weren’t part of the backup set.
I did brainstorm with Roy – and I dug into my notes from some years ago when the question was raised to me as …Continue reading...
We recently worked with a customer who noticed that they were not able to use transportable tablespaces to connect the same tablespace data files to two databases at the same time, even after setting the tablespaces READ ONLY in SQL*Plus. This is new behavior in 12c, and many customers are not yet aware of this change. Here are the details of what changed, why, and how you might want to deal with it if the changes affect your environment.
Starting in 12.1, data pump sets tablespaces read write during the import phase of a transportable tablespace …Continue reading...
All credits go to Don Wolf, an Oracle Advanced Customer Support engineer from Ohio as he dug out this information 🙂 Thanks Don!
Do database character sets have to match EXACTLY for Transportable Tablespaces?
That sounds like a simple question. When you look into our big slide deck the answer will be a straight “Yes”. No doubts. Regardless if you would like to do Transportable Tablespaces or Full Transportable Export/Import your sources and your target’s database character sets must be equal. Otherwise Data Pump won’t allow you to process the meta data import.
But Don was wondering about slightly differing …Continue reading...
Nice little best practice for statistics and Data Pump when doing either Transportable Tablespaces or Full Transportable Export-Import (credits to Roy and Dean Gagne).
Transport Statistics via a Staging Table
First of all we always recommend to exclude statistics when doing a Data Pump export as the import of such stats takes way longer than transporting them via a stats table. If you are unfamiliar with transporting stats between databases please see the Oracle Performance Tuning Guide with a nice tutorial:
The basic steps to transport statistics from one database to another fast and
As we have already mentioned in our recent workshops the MOS Note:1389592.1 is public now:
- MOS Note:1389592.1
Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backups
This technique currently works for migrations to Linux64 and is supported by Oracle Support for Exadata migrations only. It utiliuzes RMAN incremental backups to reduce the large amount of downtime it takes to copy and convert the datafiles cross Endianness.
Two requirements must be met to use this new functionality:
- Oracle 220.127.116.11 plus Exadata BP12 (patch 12982245)
- One-off patch 13340675 contains the RMAN extension and is currently available on top of BP12 on