Virtual Classroom #18: Cross Platform Migrations- Transportable Tablespaces to the Extreme

Oracle Database Virtual Classroom Seminar #18 tells you everything about Cross Platform Migrations with Transportable Tablespaces but to the Extreme with the brand-new M5 Migration Scripts.
Learn about the Best Practices, how to plan and exercise the most complex projects, see how the new M5 Migration Scripts work, and avoid the pitfalls.
Brought to you by the Oracle Database Upgrade, Migrations and Patching Product Management Team!
00:08 - Welcome to VC18: xTTS to the Extreme
04:01 - Introduction to Transportable Tablespaces and FTEX
08:01 - Concept of Transportable Tablespaces
17:04 - Requirements for xTTS
20:47 - The M5 Migration Scripts - Interview with Jony Safi
25:22 - The M5 Migration Scripts - How does it work
28:41 - The M5 Migration Scripts - Demo
36:29 - The M5 Migration Scripts - Workflow in detail
44:14 - Migration Best Practices - Before Migration
54:46 - Migration Best Practices - During Migration
1:01:21 - Pitfall when you transport statistics
1:03:52 - Migration Best Practices - Statistics
1:09:07 - More Best Practices - During Migration
1:18:04 - Advanced Scenarios
1:21:45 - More Advanced Scenarios
1:31:03 - Edge Cases
1:41:22 - Customer Case: EBS Migration with the V4 Scripts
1:44:22 - Testing the Migration
1:50:53 - Customer Case: Migration the Beast - M5 use case
2:05:12 - Monitoring and Troubleshooting
2:11:31 - Final Words and Goodbye
Get the slides here:
MikeDietrichDE...
Find more Virtual Classrooms here:
MikeDietrichDE...

[@joshypj7161]

Thanks for sharing this video. Couple of doubts on the last very interesting customer usecase... Oracle data guard is configured from New Prod to all other physical standby before restoring the L0+L1 backups ? L0+L1+L1 Final backups are restored to New Prod + all other physical standby in parallel ? In the case of OMF , restoring backup separately on these physical standby will cause any issues ? And finally metadata exporting to only the new Primary and remaining physical standby will get it updated over ODG ?

[@upgradenow]

Yes, on the target side, you configure your Data Guard as you like it. You backup once from source, and then restore to primary and all standby sites. Later on, when you plug-in the tablespaces using Data Pump, the data files on primary and all standby sites must be recovered to the same SCN. Then you perform Data Pump import on the target primary database. The plug-in propagates to the standby databases with redo. If you use OMF, you can create aliases from standby OMF location - to the primary OMF location. Check it here: kzbin.info/www/bejne/eqi4c6mghteDrtUfeature=shared&t=4811 Regards, Daniel

[@joshypj7161]

@@upgradenow Thanks for the pointer. Errors in file /u01/app/oracle/diag/rdbms/droltp/DROLTP/trace/DROLTP_pr00_48339.trc: ORA-01157: cannot identify/lock data file 2 - see DBWR trace file ORA-01111: name for data file 2 is unknown - rename to correct file ORA-01110: data file 2: '/u01/app/oracle/19.3.0/dbs/UNNAMED00002' PR00 (PID:48339): Managed Standby Recovery not using Real Time Apply I was getting above error as part of the MRP process , renamed that datafile to existing one with below command issue fixed. alter database rename file '/u01/app/oracle/19.3.0/dbs/UNNAMED00002' to '+DATA/DROLTP/DATAFILE/TPCC.271.1178964355' Completed: alter database rename file '/u01/app/oracle/19.3.0/dbs/UNNAMED00002' to '+DATA/DROLTP/DATAFILE/TPCC.271.1178964355' So if there are 1000 plus datafiles, how to address this situation in a standby database ? is there any easiest way to perform this ? I was not able to address above issue using asmcmd mkalias command, and i am not sure why asm files getting recognized as filesystem files part of the metadata restore redo apply at Physical standby side?

[@jeffh2125]

I'm glad you all posted this. We're testing with an EBS database despite that M5 is not yet certified with Ebusiness Suite cross platform. V4 is so convoluted, we'd love to use M5 and hope it will be certified for EBS soon. Have you all tried it on a sizeable EBS database and can you report any successes, issues, workarounds? Thanks much for the video. Really appreciate it.

[@upgradenow]

Hi Jeff, I have actually tried it on an EBS database, and it worked without problems. However, that's just the database part. I haven't tried anything of the other EBS stuff that you must do. Technically, I don't see why it shouldn't work. However, I must recommend you to follow the official procedures from Oracle and the EBS team. We have reached out to the EBS team for guidance on M5 and EBS, but so far nothing concrete. You can send me an e-mail at [e-mail]. I can update you when we hear from the EBS team. Regards, Daniel

[@jeffh2125]

@@upgradenow Hi Daniel, thanks for the quick reply. I'll send to your email address. I'm pretty sure this method will be the "goto" for cross platform as this is sorely needed in the oracle bag of tools. Hopefully it will be certified with EBS soon as their support for v4 is not very strongly worded anyway. They say to be sure to keep a standard export for backup, etc. etc. We are planning on installing the middle tier software from scratch of course as you can't migrate the homes. But we'll handle the cloning parts as usual. Thanks again and I'll send you a note, as we have some questions. Great video. 🙂

[@rajatsanwal9919]

@1:14:35 Why it is said that "never use sys as sysdba for datapump"? What is the exact reason behind this? What makes it different when we use a dedicated user for Data Pump?

[@upgradenow]

Hi, Internally in the database, SYS behaves different in many ways. Some features are disabled for SYS and in other situations a SYS session will do things differently. Regards, Daniel

[@rajatsanwal9919]

Thanks, Daniel. I may be unintentionally asking too much information from you. But to understand this, can you just provide ine example of what is disabled for sys user when performing an export with it?

[@christianfloreck8347]

I tried this out.. However, I wanted to transport only the TS listed in dbmig_ts_list.txt: a1,a2. When I launch dbmig_driver_m5.sh with L1F option I run into an ORA-29335 error for all other TS that are not taken "read only". Well, I not You spoke about "whole database" - but is there a way to do the job on single tablepaces? Thx

[@upgradenow]

Hi, The procedure was developed originally for full transportable export/import where you take the entire database including all tablespaces. Having said that, the RMAN portion should work fine with just a subset of the tablespaces, but it might require that you edit the scripts a little. Or you can extract the relevant commands from the generated scripts and run them yourself. For the Data Pump part, you need to move from a full transportable to a regular transportable job with just the tablespaces you'd like. Then also, you need to create users and all other metadata. I hope that helps, Daniel

[@christianfloreck8347]

Great Tutorial Two Questions, however: Does this work if databases have the same endian, so no migration is needed? Must Source and Target database have the same Name - I guess so, as the databasefiles have this info in the header. Thanks a lot Christian

[@upgradenow]

Hi Christian, Thanks for the positive feedback. Much appreciated. Yes, you can use this method even if the source and target databases are on the same platform. RMAN investigates the data files and determines automatically whether a conversion is needed when it restores the data files. No, you can transport the tablespaces into a database of any name. It does not matter. In the target database, Data Pump plugs in the new tablespaces and make the necessary adjustments. I hope that helps, Daniel

[@christianfloreck8347]

Hi Daniel, yes that realy helped. I was a little unsure about DB Names.