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.


6 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. Acetech who have been one of the leading software development company in Delhi giving creative custom software development to meet interesting business challenges for the absolute most distinguished organizations and associations in the country.

    ReplyDelete
  3. 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