Skip to Content
Author's profile photo Stefan Koehler

[Oracle] Migrating SAP systems on Oracle with less effort


A feature called “Transportable Tablespaces” was introduced in Oracle 8i, but with a lot of restrictions. Release by release the restrictions were reduced and with Oracle 10g R2 it is usable in a SAP environment for migrating whole sap systems.

This blog article will focus on the extended feature “Cross-Platform Transportable Database” with Oracle 10g R2 and its limits.

Let’s start with the main restriction on Oracle 10g R2: “The source and destination platforms must have the same endian format”. For more informatiom about endianness – please check sapnote #552464 or the link in the references.

There is also another method were this main restriction is removed, but it is not very practicable and not supported in a SAP environment – check sapnote #1367451 for details.

Initial checks

At first we have to check on which platforms we can migrate our database with the procedure “Cross-Platform Transportable Database”.

Let’s assume our database is running on HP/UX 64 bit – run the following SQL on the database to get the possible target platforms:

shell> sqlplus / as sysdba
———– —————————– ————–
          1 Solaris[tm] OE (32-bit)             Big
          2 Solaris[tm] OE (64-bit)             Big
          6 AIX-Based Systems (64-bit)    Big
          3 HP-UX (64-bit)                         Big
          4 HP-UX IA (64-bit)                    Big
          9 IBM zSeries Based Linux         Big
         16 Apple Mac OS                        Big
         18 IBM Power Based Linux        Big

Check if the database is currenctly in the correct state for  transport (in the following example the target platform will be AIX 5L 64 bit)

shell> sqlplus / as sysdba
SQL> startup mount;
SQL> alter database open read only;
SQL> set serveroutput on
SQL> declare
db_ready boolean;
db_ready := dbms_tdb.check_db(‘AIX-Based Systems (64-bit)’,0);

Check if the database is using external tables, directories or BFILEs. Normally in a SAP environemnt these objects are not used.

shell> sqlplus / as sysdba
SQL> startup;
SQL> set serveroutput on
SQL> declare
external boolean;
external := dbms_tdb.check_external;

Software installation on the target platform

– Install the oracle RDBMS software on your target system with the same patchset and additional patches as on the source system
– Install the SAP appliaction server on your target system with SAPINST or do it manually (whatever you prefer)

The conversion of the database

The conversion can be done on the source or target platform – it depends on you to decide which platform provides the better performance or if you want to copy the system to several different platforms (in this case the conversion has to be done on the target platform). In the following example the conversion will be performed on the source host.

Let’s assume again, that our database is running on HP/UX 64 bit and we want to migrate it to AIX 5L 64 bit.

The folder <TARGET_FOLDER> is the directory where the converted database files (and meta files) are stored. You can also influence the throughput with the parameter PARALLELISM.

Be sure that you have created all sub folders (of the SAPDATAs) for the data files in the folder <TARGET_FOLDER>.

shell> sqlplus / as sysdba
SQL> startup mount;
SQL> alter database open read only;
shell> rman target /
      TRANSPORT SCRIPT ‘/<TARGET_FOLDER>/transportscript.sql’
      TO PLATFORM ‘AIX-Based Systems (64-bit)’
      DB_FILE_NAME_CONVERT ‘/oracle/<SID>/sapdata1/’,’/<TARGET_FOLDER>/’,

Post Steps

After the “CONVERT DATABASE” finished successfully, you will get an information like this:

“Run SQL script /oracle/TST/oraconv/transportscript.sql on the target platform to create database
Edit init.ora file /oracle/<SID>/102_64/dbs/init_00l0fo1j_1_0.ora.
This PFILE will be used to create the database on the target platform To recompile all PL/SQL modules, run utlirp.sql and utlrp.sql on the target platform
To change the internal database identifier, use DBNEWID Utility”

Now you just have to copy the converted data files from <TARGET_FOLDER> to your target host. In the meantime you can edit the paths in the generated init.ora and SQL script “transportscript.sql”.

If your copy job has finished run the transportscript.sql and your database is up and running.


Personally i really like that feature and used it a few times to migrate SAP or non-SAP oracle databases to different plattforms.

You can build up your whole environment previously and you only have to exchange the database on the productive migration run.

It also saves me a lot of time, because of i don’t have to test the R3load migration procedure for the different SAP releases and the runtime of the “CONVERT DATABASE” was much less than with R3load.


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      I tried to use this method in Linux-->Aix migration. After all  was finished and system was up and running, I additionally had to manually activate more then 300 views, because their definition was different in DB and in SAP dictionaris.
      Author's profile photo Stefan Koehler
      Stefan Koehler
      Blog Post Author
      Hello Evgen,
      if you have done a migration from Linux (x86 or x86_64) to AIX with this procedure, you have changed the endianness.

      In this case you have *NOT* used the extended feature "Cross-Platform Transportable Database" - you have just used "Transportable Tablespaces".

      That is what i have mentioned with my comment "There is also another method were this main restriction is removed, but it is not very practicable and not supported in a SAP environment".

      I guess the views were missed, because of the SAP schema user was created manually before cross-over endianness conversion and some steps were missed.


      Author's profile photo Chandrakanth Angannagari
      Chandrakanth Angannagari

      Hello Stefan, we would like to try this approach. Do you have a comparision of the time when using R3load approach in comparision to the Rman convert database approach – say or a 5TB database?


      Also did you happen to have any discussions with SAP when you did such a migration ? Did they fully support this approach or was it left to the customer to undertake the risk ?  


      Best Regards


      Author's profile photo G. Vandenbroucke
      G. Vandenbroucke

      we need to migrate an Oracle 4TB database from Linux to Windows. Is this possible and can we apply extra  offline redolog files to shorten the downtime, So starting from a onlone backup, adding redolog files and then open the database.