Hello Friends

One of my client needs to convert his MySQL database to Oracle. He has given me the Backup of mysql to me. Is there any tool/script available which used to do the same job ?

Thanks in Advance.

In principle dump sql and import sql. However, different vendors have different features that end up with different sql. I haven't dealt with the Oracle end, but where I work we have dealt with interchange between msql, mysql and postgresql. It's generally a pain in the butt, and I figure going to Oracle may be more so. You need someone who knows the database and the source and target engines. Then you do an import, see what works and what doesn't, make changes in the sql dump file, and try again. If it basically gets in, but some things are not quite right, then you end up twiddling things directly in the target database. If the person who developed the database used features specific to the source engine that aren't present or are very different in the target engine, then it becomes more difficult. We're trying to standardize on MySQL, but one of the databases that was developed in PostgreSQL is so specific that we are still running it there.

Sorry if that's not too helpful. If I had to do it, I might beat on Google for a while to see if there are any helpful tools. That's basically what you are doing by asking here. If you do find them, there will be cases they won't handle and will flag as requiring attention.

http://www.oracle.com/technology/tec...ldev_omwb.html

You could, of course, do it by hand. There are some howtos for that, just google it.

I think you might be on a hiding to nothing - through no fault of your own. Here is my thinking on the matter, but first a short story.

1.
A financial system was being re-written from ICL Cobol system that was about ten years old and well past it's sell by date. When the designers asked the users what reports they wanted, they said that they wanted the reports just like they had already. Hmmm. Asked to describe what they actually had already, bearing in mind that the Cobol system developers and most of the maintainers were long down the road, it became clear very quickly that they didn't know what they had or what they wanted. We entered a process of duplicating what they had and occasionally came upon groups of figures that couldn't be rationalized. It appears that these groups had been in error from day one 10 years ago and instead of getting corrected, they were just ignored. They were eventually left out of the new reports as no one knew what they should be representing anyway.

2.
Most database migrations tend not to just get translated from one system to the other, because that way lies mass mediocrity. As Choogendyk mentioned, to be able to succeed you will need to be familiar with both DBMS and the application, even though you weren't in on the original design. I would suggest that this is the opportunity to drop that inevitable functionality that never got used and pick up on things that weren't there originally. The Oracle database needs to be designed with the MySQL database with all it's relationships in mind and then the tables need dumped, possibly loaded to spreadsheets and reloaded into the target system. Use of triggers and non vanilla ansi standard stuff will doubtless be a real pain, in the butt and elsewhere. Good luck. If the system is of significant size, I would further suggest that one person works on the one system dumping and preparing the data, and the other person looks after loading it into the new DBMS. Working together you should manage to stay sane. Good luck.

If the cols on corresponding tables are defined in the same order, you could try a mysqldump, using the data-only options eg --no-create-db, --no-create-info etc etc. see this page: http://dev.mysql.com/doc/refman/5.0/en/mysqldump.html
Basically create a customised dump that you can then use SQL-LOADER to load.

You'll want to turn off indexes before the load to speed it up

Alternately, if you need to fiddle the MySQL values to fit the ORACLE tables, and/or change the formats/col orders, write a Perl prog using DBI to create the correct dump.
In fact, if both DBS are avail, you can use the Perl prog to connect to both DBS and just txfr data cross, amending values etc on the fly.
http://search.cpan.org/~timb/DBI-1.607/DBI.pm


Fundamentally, data txfr between any set of DBs, even the same tech, is fraught as per choogendyk's warnings. I've done it myself several times...