Your web platform runs on an Oracle database? You must be Nuts! – Part 2

This is the second blog post in a series designed to assist companies who wish to migrate their code from Oracle to MySQL.

In the first post of the series I tried to explain why you would like your web platform to run on a MySQL database, and not on an Oracle database. In this post, I’ll try to focus on the changes that you need to plan for when migrating from an Oracle environment.

Code

Probably the most obvious change is in code. There is no way around it – you’ll have to change your code.

1. SQL statements.
   While ANSI SQL 92 is a standard, Oracle offers extensions to the spec – and those are used by most developers, sometimes without their being aware of it.
   Of course, when moving to MySQL, those SQL statements will need to change. Some will require only minor changes (For example. When working with paging and wanting to limit number of records returned in a resultset, MySQL’s LIMIT clause will have to replace Oracle’s use of ROWNUM pseudo-variable. OR ANOTHER EXAMPLE: Oracle’s “old” outer join syntax includes (+) near tables in the FROM clause. However since Oracle9i the ANSI join syntax is supported and highly recommended by Oracle themselves!),), but some (like queries using CONNECT BY or many of the aggregate functions Oracle database offers) will require massive query and code changes.
   Even if you use an ORM tool, code changes might be required, although they will probably be much smaller.
2. Stored procedures.
   While stored procedures and triggers are supported by MySQL, they are rarely used. On the other hand, stored procedures are extremely popular in the Oracle database environment – and are very powerful.
   Every stored procedure will have to be migrated, probably manually, to run inside the application. This might result in a major performance hit, since stored procedures run in the database, “close” to the data, and many developers use them for data-crunching tasks.
   All in all, the stored procedures will probably have to be re-designed, not just re-written.

Developers’ “state of mind”

While code can be migrated, and a cost can be attached to such migration, Oracle developers often require some time before they can effectively develop code for MySQL. The limitations mentioned in the above section, and the different development tools, are difficult to get used to.

But even more – it is difficult to get used to what the database does and doesn’t offer. We’ll dive into that topic later, when we talk about scalability and high availability.

DBAs

Oracle and MySQL DBA are similar in title only. Their day-to-day job is very different.

1. Different tools.
   There is no MySQL CLI for Oracle, and SQL-PLUS can’t connect to a MySQL database.
   But those are the minor changes – SQL-Developer and MySQL Workbench are not that different.
   However, backup tools, performance monitoring utilities, and database audits are all very different, and it takes time to get used to those new tools. You should expect that at least some of the tools you currently have in your environment will not support MySQL, and you’ll have to find new tools. For some tasks, those tools are nowhere to be found, and will require in-house development.
2. Scripting.
   DBAs are measured by the quality of their scripts, and most Oracle database environments are heavily scripted. Database start, stop, error fixing, and data collection all use database engine utilities, and all those scripts will have to be rewritten.
3. Tuning parameters.
   A friend once told me about how they migrated their application from Oracle to SQL-Server. It took them three months to migrate the application and six months to tune the database. And this story is not uncommon; tuning parameters vary greatly between databases since every database has a different architecture.
4. Central management and administration. Adding an index, for example. When I have 10 DBs, I have to create on every DB, make sure it succeeded, etc…

High Availability and Scalability

Oracle users know that when they require high availability or high scalability they can turn to RAC. MySQL doesn’t offer such an option; MySQL Cluster is very different from MySQL standalone. We’ll discuss the high availability and scalability topic in our next post.