Delphix Unix to Linux Oracle conversion

Linux is taking over the workloads from the shrinking market share of:

• IBM AIX pSeries

• Solaris Sparc Servers

• HP-UX Itanium

because Linux provides a reliable and less expensive platform. The costs reductions according to IDC for using Linux over UNIX can be on the order of 1/5 the price per end user.

Legacy RISC Systems Cost $1,425/User versus Linux at $ 256/User - IDC 2012.

The LINUX systems will represent the majority of the market by 2017.

By 2017, 65% of applications running on Unix in 2012 migrate to x86 Linux ERP scale-out architectures on x86 platforms will rise from a 10% in 2005 to 80% in 2017 - Gartner.

How will current UNIX systems migrate to Linux? For Oracle customers, how can they move data from Oracle on UNIX to Oracle on Linux? There is a magic technology from Delphix that will provide this conversion.

But without Delphix what are the options? The Oracle datafiles on UNIX are not compatible with Oracle datafiles on Linux thus converting to Linux requires converting the datafiles. The most obvious way to convert the datafiles is to simply export the data from the UNIX system and import it on the LINUX system. Such a conversion is simply too onerous for many sites. What other options are there?

• RMAN and Transportable Tablespaces

• DBMS_FILE_TRANSFER: files < 2TB; still relies on RMAN for endianness conversion

• ReplicationExport / Import: Golden Gate; Streams; DB Visit

Unless the database is small the option of Export/Import is just to slow and onerous. Replication is practical for incoming changes but not for converting an entire database. DBMS_FILE_TRANSFER still requires RMAN. RMAN is the core technology option, which on the surface sounds super practical.

RMAN can convert each datafile one by one and using transportable tablespaces to plug the new converted file into an Oracle database on LINUX. RMAN has an option to convert an entire database provided that the source and target are of the same endianness, but the CONVERT DATABASE command doesn't work when changing from one endianess to another.

Changing endianess is required when going from any Unix such as HP/UX, AIX, Solaris Sparc to Linux.  Converting from Unix to Linux is the most common conversion route. How can one convert UNIX to Linux if CONVERT DATABASE command doesn't work?

RMAN

Procedure for cross-platform conversion from big endian UNIX to little endian Linux:

1. Verify Platform support: v$database shows your platform; v$transportable_platform shows platforms for which conversion is supported

2. Create a database on the target Linux machine (or use a pre-existing database on the target machine)

3. Choose tablespaces on the source to transport: no system, undo, or temp

4. Verify that tablespaces on source meet required restrictions by running DBMS_TTS.TRANSPORT_SET_CHECK on each tablespace to be transported and check results in sys. transport_set_violations after running procedure: no encryption; locally managed tablespaces only; tablespaces self contained (table and index, IOT and overflow segment, table partitions and subpartitions, Referential integrity, LOB segment and LOB table); no users objects in SYSTEM tablespace

5. Create necessary metadata (users, grants) on target database: schemas on target database must be pre-created; tablespaces with same name as source can not pre-exist; object with the same name and owner as on the source can not exist

6. Alter READ ONLY the tablespaces on the source to be transported to the target database while doing the following: export tablespace meta data from source (the more metadata like with EBS the slower the process); export "'/ as sysdba'" file=transport.dmp transport_tablespace=y tablespaces=tablespace1, tablespace2; copy this export to target copy datafiles to target (on target change file names as needed)

7. Convert files on target with RMAN: convert datafile '/target_datafile_directory/datafile1, /target_datafile_directory/datafile2' from platform = "old platform type" DB_FILE_NAME_CONVERT(, '/target_datafile_directory','/source_datafile_directory')

8. Import tablespace metadata at destination imp "'/ as sysdba'" file=transport.dmp transport_tablespace=y datafiles=/target_datafile_directory/datafile1, /target_datafile_directory/datafile2

9. Alter tablespaces on target database read-write

Delphix

1. Delphix takes this onerous, time consuming and space consuming task and makes it a an automated, space-efficient task that can be done with a few clicks of a mouse.

2. Fully automates a complex, time consuming operation

3. Leaves source open database and usable (no need to make source read only)

4. Once converted, can make clones of the converted database in minutes for almost no storage

5. Storage used is 1/3 traditional cross-platform conversion

6. No staging files needed, eliminating need for extra copy of the source database during conversion

7. Convert source as many times as wanted even at different points in time for almost no extra storage

Delphix makes it easy and inexpensive to practice conversion. Conversions can go wrong for many reasons and it's good to have an agile sandbox in which to practice conversions. Conversion across different platforms has many constraints that are often not apparent until conversion is started. Some of the constraints require changing the source. Changing the source is problematic as the source database could be an important production database. Instead of changing the source database, one can create VDBs of the source in minutes for almost no space and then make changes to this VDB and run the convert process on this VDB. Once the source has been converted once then converted copies can be made in minutes for almost no extra storage. Such a scenario allows developers and QA to work on commodity hardware and Linux while keeping production on *NIX. Delphix enables modernization and consolidation by accelerating the re-platforming of large, complex databases onto a standardized platform and accelerating related dev and test activities associated with application consolidation, upgrades, and platform standardization.

How Delphix Does It

1. Link - Like with normal database virtualization, the first step is linking to the source database which means once and only once taking a full copy of the source database and then incrementally and forever collecting the changes onto Delphix

2. Extract Metadata -  The source database can be cloned out to any machine with the same OS and version of Oracle, but if one chooses the option "Transform to Linux" , then Delphix will spin up a clone on a staging machine. The staging machine has to be the same OS and version of Oracle binaries as the source database machine. The source database machine can be used,  but since the source is usually a production type database, most users stage on a different non-production machine so as not to perturb a sensitive production workload. Using the staging machine, Delphix will start up a clone and export metadata such as user information, packages, sequences etc.

3. Provision - Third step is Delphix using RMAN to convert the UNIX datafile's endianness to the little endian format of Linux.  Delphix tracks the bytes that change endianness and the whole conversion process generally only takes 1% more storage to store both the original datafiles and the new version of the datafiles!  Delphix also creates an empty database, imports all the metadata from the source database and imports the converted datafiles using the transportable tablespace mechanism.

Steps 2 and 3 are fully automatic and run together by Delphix. The process is a simple push button operation! As a user all that is required is:

1. Designate a staging machine

2. Designate a target machine

3. Run a verification that the source database is valid for cross-platform conversion

Above, highlighted by the red box, is the option for a machine to server as a staging environment.

On the source database, select the "Linux" conversion icon in top right, highlighted by the red box. This will bring up the validation checklist.

Above is the validation checklist. To run the check list, click the green check icon in the bottom right. The checklist tests for:

• compatible staging environment

• compatible target environment

• validation status

The last step is the validation step. The validation step checks for unsupported configurations for RMAN cross platform conversion such as when user objects are in the system tablespace.

If this case then the error will be flagged. At this point one can click the scroll icon (script icon) to the bottom right, and enter in the SQL commands to address the validation error such as: alter index "SCOTT"."SYS_C005949'' rebuild tablespace users; create table "SCOTT"."EMPNOTINSYSTEM" tablespace users as select * from "SCOTT"."EMPINSYSTEM"; drop table "SCOTT"."EMPINSYSTEM"; alter table "SCOTT"."EMPNOTINSYSTEM" rename to "EMPINSYSTEM"; create table system.mydbaobjects tablespace users as select * from mydbaobjects; drop table mydbaobjects;

Above, highlighted in the red box, is the "Transform to Linux" button which becomes available on a source database when the validation checklist has passed. Hitting this button provisions a UNIX database on a Linux target in the same workflow as normally provisioning a virtual database.

All the hard work and tedious steps are taken care of automatically by Delphix and the total storage used is only about 1% of the source database size.

References

• Moving Oracle Databases Across Platforms without Export/Import from Roger Schrag at Database Specialists

• Oracle Docs on Cross Platform Migration

• Comparison of Cross Platform Migration methods