I have a Mysql database backup dump file (.sql), and I want to migrate this file directly into Oracle by using sqldeveloper. Will this work?
It won't work. If you do it manually from a dump, you would have to do a lot of data conversion, modify the create table code to work for oracle and so on. It would be a lot of work.
But if you have SQL Developer, it apparently has a process to do precisely that.
Check out that link:
http://www.oracle.com/technetwork/database/migration/mysql-093223.html
I hope that helps.
It cannot be realized in automatic mode, due to different basic syntax of Oracle and MySQL dump files. In addition, Orqcle uses its own RMAN utility for controlling backups and restoration.
A most viable solution is to write a script converting MySQL dump file into the format recognizable by Oracle. I guess these procedures can exist in Internet, available for (free?) downloading.
Related
My companies site uses a mysql database. One of our clients just trying to take advantage of our API is only able to give us the data in the form of a MSSQL .bak file
I have been trying to import the file using the migration tool built inot mysql workbench but have no luck.
On top of that I am trying to see if this can be done in powershell as I would like to automate this process in the future.
Any suggestions or help would be appreciated
You cannot. MS SQL Server backups are proprietary to MS SQL Server and cannot be used with any other RDBMS. You will need to restore this backup to SQL Server, then use an additional tool to transfer the data from SQL Server into MySQL.
Can you do that second portion through PowerShell? Probably. Though SSIS would probably be a better method.
So i have a low of dmp files that were to make tables in my sql developer database is there a way I could use those same dump files for my mysql database tables?
I never did that, but Googling around I found out that there are tools that make it possible. T
OraDump-to-MySQL is a program to export data from Oracle dump files into MySQL, MariaDB or Percona database. The program does direct reading from the dump, so Oracle installation is not required. Command line support allows to script, automate and schedule the conversion process.
I'm not posting a link (so that someone wouldn't call it spamming); I guess you'll be able to find it yourself.
I trying to migrate my Expression Engine site from one sever to another.
I was using MySQL version 5.1 but on my new server I’m using version 5.5.
I've just copied over the Database from the Data Directory on the old server to the new and my site wouldn't function correctly.
When I restore my Database with a MySQL Dump file from the old server, the site works.
Is there an issue with copying and pasting a MySQL database from one server to another and why is the MySQL Dump restore not effected by the same issue?
I'm trying to use this information to provide a good backup solution.
The dump and restore method works because the dump file is basically just a bunch of "CREATE TABLE" and "INSERT" Statements. The dump and restore rebuilds the database from scratch using basic SQL statements. Copy and pasting doesn't work because you are moving between different versions of the database with different data formats. If you are moving between machines with the same version of MySQL and the same configuration, then simply copying the data directory can work, assuming you do it properly. Using the dump / restore method is the most reliable way, but is often very time consuming on large (think 50 GB or even much larger) databases.
The best backup solution is to dump the SQL rather than copying files.
mysqldump utility provides a full dump of all of the data that is compatible (IIRC) all the way down to MySQL 4.0 using it's conditional statements.
I have a feeling that the reason copying data directories between 5.1 and 5.5 is because the engines may have changed the way that they store their data. I had an issue like this related to InnoDB and it was a pain in the behind. Long story short I never got the data back and unfortunately didn't have an SQL Dump (the hard drive failed!).
Anyway at the end of the day, mysqldump is the best tool to use as it creates compatible SQL statements which should work across a whole plethora of MySQL Versions, both past and future.
I haven't looked into the details, but the MySQL data files are binary files and may not be directly compatible between versions. The files produced by MySQLdump are simply a list of SQL instructions to recreate the database, so they will be more compatible between versions, though not necessarily backwards compatible, so you may have trouble going from 5.5 -> 5.1 if you ever had to.
Caveat: I have zero experience with MySQL.
I've been given a series of files to do a data conversion and would like to migrate the provided data into SQL Server 2008. The files are:
*.myd
*.myi
*.frm
These file types, as I understand it, are MyISAM. I believe that if I had a running MySQL instance, migrating to SQL Server would be fairly straightforward. I could could either use SQL Server's import wizard or Microsoft SQL Server Migration Assistant for MySQL v1.0. Unfortunately, these files are what I'm stuck with -- I just don't have access to the original MySQL instance.
I also don't presently have MySQL as a running instance locally and I'm not sure if there would be compatibility issues with the files I have.
Can I attach them to MySQL 5.5 with the goal of performing a SQLDump or perhaps to use either tool mentioned above? Am I missing a better way?
Yes, you can easily attach them to MySQL 5.5. Then you can dump the tables using mysqldump (be aware that you will need to either modify dump and remove mysql-specific stuff from the dump, or probably customize mysqldump output - check mysqldump documentation for details). You can also try to link Mysql instance to SQL Server, and then copy tables using SELECT ... INTO [sql_server_table_name] FROM [mysql_table_name].
In any case, the hardest part is to migrate stored procedures/triggers. Mysql and SQL Server have quite a different syntax for them, so you probably cannot automate this process.
Update
Also, I forgot to mention that you will have to modify mysql auto_increment columns to IDENTITY([next_auto_increment_value],1) SQL server.
I backed up my db with mysqldump from phpMyAdmin. Using MySQL 5.0.22. Made no changes to database file. Import fails. Found many instances of extra spaces using notepad, but now cannot find any other such extraneous spaces. Error is 1064.
Any suggestions on how to import file properly?
Thanks.
I encountered problems with mysql dumps of entire databases including views. So now I dump the tables and data as a separate dump, and export the views, stored routines and functions separately. I restore the tables first then the views etc.
Having come from MS SQL Server and Oracle I would like to know if there are any totally reliable tools out there for MySQL database backups and restores.
You have done several things wrong here
Using PHPMyAdmin for anything critical, especially backups. It is not production-ready, in my experience. Feel free to use it for unimportant read-only work on noncritical servers however.
Editing mysqldump files with notepad (or any other editor). Despite appearances, mysql dump files are not text files and should not be edited with any editor. They contain binary data which is not valid in most character encodings, and therefore can probably not be loaded/saved without introducing errors.
Make a fresh dump using mysqldump, which is the only reliable way of making them, and import that. Do not edit mysql dump files using notepad or any other text tool (this includes the likes of grep, sed etc).
If you need to edit a mysql dump file, then restore it into another (i.e. non-production) database instance, make the necessary changes using SQL commands and re-dump the database. This may be slow but it's reliable.