Full Transportable Export Import (FTEX) for Cross-endian Migration

This video shows you how to use Full Transportable Export Import (FTEX) to migrate your database from one endian format to another, e.g. from AIX or Solaris to Oracle Linux. First, the concept is described and then a demo shows how it can be done.
[00:05] Concept
[02:41] Demo
[07:11] Conclusion
Slides and more information: dohdatabase.co...

[@Reaggeist]

Great Information.... thank you very much

[@upgradenow]

Glad it was helpful!

[@busingerogers1086]

At my workplace. We are migrating from supercluster m8 to exadata m9. Also we are migrating tablespaces from 18c to 19 at the point of importing meta data into 19c. We get an error about the version could you kindly help we used the transportable tablespace framework

[@upgradenow]

Hi, I'm afraid I need a little more detail to answer your question. I suggest that you read my blog post series on XTTS. It has many information, step-by-step guide and link to demos. dohdatabase.com/xtts Further, we are hosting a 2-hour webinar on such migrations. Specifically we have a similar customer case which could be of interest to you. We are using a newer method, but much of the information applies to a migration from 18c to 19c as well. dohdatabase.com/webinars/ Regards, Daniel

[@colinmaharaj]

How do I go from BIG to LITTLE as well as RAC to NON-RAC?

[@upgradenow]

Hi Colin, You can simply import the tablespaces and metadata into a non-RAC database and that should be it. There is nothing special about the data files or your data when it is a RAC database. In fact, the database parameter CLUSTER_DATABASE is all that controls the RAC behaviour. Regards, Daniel

[@colinmaharaj]

@@upgradenow ah thanks. The only thing is Im backing up from and restoring to 10g. Itanium to x64

[@upgradenow]

@@colinmaharaj Hi Colin, 10g - oh dear. Then you can't use the procedure as described in the video. You should seriously consider moving off 10g. To stay on 10g you might have to consider Data Pump instead. Regards, Daniel

[@beriscom]

Full Transportable Export Import (FTEX), can be used to migrate a self contained tablespace/user ?? (while the other tablespaces remains online in source database), or is it mandatory that you have to migrate all tablespaces at the same time, except those that contain Oracle maintained data, (like SYSTEM, SYSAUX, UNDO). I think in this video you are migrating all tablespaces (full=y), isn't it ? Thanks in advance for your answer

[@upgradenow]

Hi, That's a good question. Full Transportable Export/Import is for all the user tablespaces in your database. You can't cherry-pick. If you want just a subset of the tablespaces, you can still use the perl scripts for incremental backups, but you will need to perform a regular TTS import - instead of the FTEX import. Regards, Daniel

[@darakhmao]

I've followed your steps exactly adding RMAN convert. The imports was successful, but all the tablespaces are not plugin. I've have done import multiple times and still the same result. Do you have to pre-create the SH user first? I've did not see your step to use RMAN convert for cross endian migration. Thanks.

[@upgradenow]

Hi, When you use FTEX there is no need to create the SH user. The Data Pump import creates everything. You can find more details here including step-by-step instructions: dohdatabase.com/xtts Regards, Daniel

[@darakhmao]

@@upgradenow Thanks. It didn't work for me so I pre-create the users using another export/import. It also failed to import users because default user tablespace is missing. So I pre-created the tablespaces first, imported the users, drop the tablespaces. Now I am able to perform xtts. This is 19c on hpux IA 64 to red hat linux.

[@upgradenow]

I'm glad it worked out for you eventually. Regards, Daniel

[@NadeemKhan-hm6wz]

compressing the datafile using gzip utility, won't make it corrupt?

[@upgradenow]

Hi Nadeem, The file will be corrupt when it is in the compressed format. However, at the destination you uncompress it again. Regards, Daniel