Wednesday, April 9, 2014

Porting from Oracle to MySQL

A potential customer asked my about porting her application from Oracle Database to MySQL.

I always try to start with the "why" (a dear friend bought me this book, recommended: http://www.amazon.com/Start-Why-Leaders-Inspire-Everyone/dp/1591846447).

She said "cloud!". I said "OK!".

I conducted a short research, found many things in many places all over the place, brought them to a nice email I sent her back and then thought I'll post it here and make it public as it might be useful for us all. If you feel that I missed something, add comments, send feedback.

These are the leading tools to do the actual migration of the data structure, data export/import, sprocs, triggers, etc.:
  1. MySQL Workbench has a migration feature: http://www.mysql.com/products/workbench/migrate/
  2. MySQLYog can be used to migrate: http://tkurek.blogspot.com/2013/04/migrate-oracle-to-mysql.html  (already in the conversation in the second comment there)
  3. Navicat can be used to migrate: http://www.navicat.com/products/navicat-for-mysql
  4. Tungsten support Oracle-to-MySQL replication: http://www.continuent.com/downloads/software
  5. Focused data migrators:
    1. http://www.ispirer.com/products/oracle-to-mysql-migration
    2. https://www.youtube.com/watch?v=IW3vKHWJljY
    3. http://www.slideshare.net/Tess98/oracle-to-mysql-migration-presentation
    4. http://www.dbload.com/
    5. http://dbconvert.com/convert-oracle-to-mysql-pro.php
    6. http://www.spectralcore.com/omegasync/


The way I see it, migrating the data is 15% of a database porting project. Efforts are in (partial list):

  1. Porting drivers and driver behavior in the app code
  2. Porting SQL commands all around the app code
    1. Conversion of non-standard SQL flavor
    2. Work-around restrictions and non-supported commands
  3. Ecosystem, monitoring, tuning, tools, scripts, hardware best practices, ops skills, dev skills

Way before the migration of the data on d-day.

A lot of services, some tools. Services-wise I see around:

  1. Pythian: http://www.percona.com/live/mysql-conference-2012/sessions/oracle-mysql-migration
  2. Baron (Percona): http://www.xaprb.com/blog/2009/03/13/50-things-to-know-before-migrating-oracle-to-mysql/

I bet the big SIs (Accenture et al) are strong in this game, as those would be the default go-to service provider for the Oracle shops.


5 comments:

  1. The major problem is not migrating data, but 'stored program' code. If (for instance) an Oracle or SQL Server uses a lot of that an in a non-trivial manner this is the real challenge. If the logic is in application code it is less of a problem.

    (and thanks for mentioning our program - but the correct name is 'SQLyog'. Not 'MySQLyog'. Only the very first (non-GA) version was named 'MySQLyog' - but MySQL AB asked us to change that as they felt it came too close to their trademark. Refer http://faq.webyog.com/content/33/7/en/sqlyog-version-history.html)

    ReplyDelete
    Replies
    1. Peter thank you for your comment.

      Sorry for using a wrong name, my bad, SQLyog it is!!

      Delete
  2. Hi Doron. I was wondering if "Cloud!" is sufficient reason to undertake all this work. Is there an alternative that would give her the benefits without changing everything? Great blog btw. :-)

    ReplyDelete
    Replies
    1. Thank you David for your comment. Yea I agree that cloud is not a magic silver bullet for everything that is wrong with traditional IT, and sometimes is just "en excuse" for a major change that is due anyway I guess....

      Delete