Awesome series, It makes concepts much simpler to understand and implement. Wonderful and detailed videos. Love watching and listening to these videos.
Hi Wanda, That's a really good catch. The table CUST2 is created in SYS schema, which is a mistake. It should have been stored in the SH schema (like the source table). As you can see from the demo, the table is transported anyway. This is a feature of full transportable export/import (FTEX). Normally, SYS objects are not part of transportable tablespaces (stored in SYSTEM tablespace), but with FTEX it will include any non-default SYS objects using a regular export/import. You can find more details about FTEX in my blog post series: dohdatabase.com/2020/11/23/xtts/ Regards, Daniel
It is a small text file which is generated by the script. It contains important information on the backup (like SCN) that is needed for the restore later on.
Hi Wanda, If you are having difficulties with the procedure, I suggest that you read my blog post series on the topic. It has much more details and step-by-step instructions that you can use. dohdatabase.com/2020/11/23/xtts/ Regards, Daniel
Hi, Yes, you can use transportable tablespaces (including Full Transportable Export/Import) between architectures (non-CDB and directly into a PDB). It even works across versions. Regards, Daniel
How about temporary table? Is it can migrate too? Or should be manually import metadafa? I simulated but any object not migrated successfully (like temporary table), so I need expdp impdp metadata from source to target
Hi Wanda, This demo uses Full Transportable Export/Import (FTEX) and it will include the definition of the temporary tables. However, the content of the any temporary tables are not transferred. The content of temporary tables are never persistent (either session or transaction level), so only the definition of the table is transferred. I have a blog post with details on what is transferred by FTEX: dohdatabase.com/2022/03/28/xtts-full-transportable-export-import/ If you do a regular transportable tablespace migration, then you need to create many objects manually, including temporary tables. Regards, Daniel
Thanks Daniel for the demo , i have a quick question ? what if the objects you wanna move are on different tablespace , meaning the tablespace is not self contained ?
Hi Samer, This example uses Full Transportable Export/Import which includes all tablespaces in your database (except SYSTEM and SYSAUX). So you must specify all the tablespaces (or rather data files) and it will be self-contained. However, if you perform a regular transportable tablespace export you can decide on individual tablespaces. If you have e.g. an index in your tablespace that references something outside of the tablespace, you will get an error. It must be self-contained. Regards, Daniel
Awesome series, It makes concepts much simpler to understand and implement. Wonderful and detailed videos. Love watching and listening to these videos.
Glad you enjoy it!
Is CUST2 table created in schema sys at source?
Hi Wanda,
That's a really good catch. The table CUST2 is created in SYS schema, which is a mistake. It should have been stored in the SH schema (like the source table). As you can see from the demo, the table is transported anyway. This is a feature of full transportable export/import (FTEX). Normally, SYS objects are not part of transportable tablespaces (stored in SYSTEM tablespace), but with FTEX it will include any non-default SYS objects using a regular export/import. You can find more details about FTEX in my blog post series:
dohdatabase.com/2020/11/23/xtts/
Regards,
Daniel
what is that res.txt which you copied from src to trgt multiple times?
It is a small text file which is generated by the script. It contains important information on the backup (like SCN) that is needed for the restore later on.
when imdp then raise error ORA-19722: datafile /home/app/oracle/oradata/ORCL/USER2_TBS_9.dbf is an incorrect version. why?
Hi Wanda,
If you are having difficulties with the procedure, I suggest that you read my blog post series on the topic. It has much more details and step-by-step instructions that you can use.
dohdatabase.com/2020/11/23/xtts/
Regards,
Daniel
Can this be used to transfer data from non-cdb database to cdb
Hi,
Yes, you can use transportable tablespaces (including Full Transportable Export/Import) between architectures (non-CDB and directly into a PDB). It even works across versions.
Regards,
Daniel
@@upgradenow Thank you
How about temporary table? Is it can migrate too? Or should be manually import metadafa? I simulated but any object not migrated successfully (like temporary table), so I need expdp impdp metadata from source to target
Hi Wanda,
This demo uses Full Transportable Export/Import (FTEX) and it will include the definition of the temporary tables. However, the content of the any temporary tables are not transferred. The content of temporary tables are never persistent (either session or transaction level), so only the definition of the table is transferred. I have a blog post with details on what is transferred by FTEX: dohdatabase.com/2022/03/28/xtts-full-transportable-export-import/
If you do a regular transportable tablespace migration, then you need to create many objects manually, including temporary tables.
Regards,
Daniel
Should archive log mode to be enabled in this case?
Hi,
Yes, the database must be in archivelog mode.
Regards,
Daniel
Thanks Daniel for the demo , i have a quick question ? what if the objects you wanna move are on different tablespace , meaning the tablespace is not self contained ?
Hi Samer,
This example uses Full Transportable Export/Import which includes all tablespaces in your database (except SYSTEM and SYSAUX). So you must specify all the tablespaces (or rather data files) and it will be self-contained.
However, if you perform a regular transportable tablespace export you can decide on individual tablespaces. If you have e.g. an index in your tablespace that references something outside of the tablespace, you will get an error. It must be self-contained.
Regards,
Daniel