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.:
- MySQL Workbench has a migration feature: http://www.mysql.com/products/workbench/migrate/
- 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)
- Navicat can be used to migrate: http://www.navicat.com/products/navicat-for-mysql
- Tungsten support Oracle-to-MySQL replication: http://www.continuent.com/downloads/software
- Focused data migrators:
- http://www.ispirer.com/products/oracle-to-mysql-migration
- https://www.youtube.com/watch?v=IW3vKHWJljY
- http://www.slideshare.net/Tess98/oracle-to-mysql-migration-presentation
- http://www.dbload.com/
- http://dbconvert.com/convert-oracle-to-mysql-pro.php
- 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):
- Porting drivers and driver behavior in the app code
- Porting SQL commands all around the app code
- Conversion of non-standard SQL flavor
- Work-around restrictions and non-supported commands
- 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:
- Pythian: http://www.percona.com/live/mysql-conference-2012/sessions/oracle-mysql-migration
- 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.
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.
ReplyDelete(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)
Peter thank you for your comment.
DeleteSorry for using a wrong name, my bad, SQLyog it is!!
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. :-)
ReplyDeleteThank 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....
DeleteMySQL Workbench has a migration feature: ... ikidsworkbench.blogspot.com
ReplyDelete