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.
Related
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 have a mysqldump from an SQL server and i want to open it in a program like MySQL Workbench or DBeaver so that i can easily search it and remove some values etc.
I'm trying to use MySQL Workbench however am unsure if i can import this SQL DUMP directly into here from the file like this. I have created in a new model and clicked import and it seems to show all my tables however they are empty.
Is this possible and how would i go about this?
MySQL Workbench can restore a dump without loading it first into an editor (and hence can even handle gigabyte sized dumps). For this go to the Data Import/Restore admin section,
select your dump, set options (e.g. what of the dump to restore) and click Start Import to start the process.
However this doesn't allow to change the dump and because of usual dump sizes even browsing them is often not possible. You can try to load the dump file into an editor if it is not too large (say around 250MB, depending on system RAM). If it is much larger you can only try special tools like hex editors (which load large files piece by piece).
As far as I remember, MySQLDump exports the database to an sql script with a .sql file extension?
In MySQL Workbench, open this file Using File->Open SQL Script or alternatively CTRL+SHIFT+O
Running the script should then create the database
I have an MSSQL dump file that I want to import into a MySQL database. I attempted doing so via phpMyAdmin and setting the compatibility to MSSQL but that doesn't seem to work. It consistently throws MySQL server has gone away. Upping the max_allowed_packet and wait_timeout didn't do anything to solve that either.
Is there a better way to import this database dump?
Try SQL Server Integration Services (SSIS), an ETL tool (Extract, Transform and Load) which is very much needed for the Data warehousing applications. Also SSIS is used to perform operations like loading the data based on the need, performing different transformations on the data.
Free from MS: http://msdn.microsoft.com/en-us/library/ms143731.aspx
Useful links:
http://www.codeproject.com/Articles/155829/SQL-Server-Integration-Services-SSIS-Part-1-Basics
Assuming you have dealt with all syntax incompatibilities, you can use this:
mysql -u<user> -p < db_backup.sql
If you are just scripting tables and data that should work fine. If you have GO statements in your script remove them, you don't need them for tables and inserts.
If you want to script other objects too you need to review each one as there are significant syntax differences.
I've exported a MySQL v4.0.25 script to a sql file and since I can't find an installer for 4.0 anymore the only option left is to use 4.1..
Now, I'm getting the common 1064 error since v4.0 doesn't have utf-8 (only latin-1) and v4.1 gives me a syntax error.
I'd be okay with editing the files manually but, one of the scripts is a file 12GB big and the other one is 5GB so I can't even find an editor able to open a file that large and a problem at hands with this migration (the files are that big because they are a copy of 2 production DBs with over 10years use).
How can I fix or bypass this problem? Any chance I can tell the import script to ignore the lines with errors (and I don't even know how many are there..)?
If it's still possible, dump the data structures in sql and the data tables in csv format using mysqldump --tab=path. This way, any modifications you will need to do will be on the much smaller sql file, keeping the large data files untouched. They you could later import the whole thing using mysqlimport command.
Alternatively, you could always use the mysql --force option for importing your sql file.
More information:
MySQL Reference Manual: mysqldump --tab=path option
MySQL Reference Manual: mysqlimport
MySQL Reference Manual: mysql --force
For manually editing the files:
If you are using Linux as your operating system, then there is a big variety of commands in your hand: more, less, sed, etc. sed is good for substitutions, similar to your question. A nice tutorial can be found at http://www.grymoire.com/Unix/Sed.html
In Windows, I sometimes use PowerShell. I had similar post on StackOverflow about "mysqldump without database name" where there is an example of how to replace a string in a dump file.
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.