PDA

View Full Version : Restoring a 350 mb database



latinO
Mon 9th Jan '06, 6:25pm
Hi all,

First of all, I'm not sure if I posted this in the right forum, sorry I was mistaken.
I'm having trouble with importing my 350 mb databse. I just moved to a new host provider. I didn't know the maximum upload file size through phpmyadmin is 350 mb. I did a search on this forum and on google and I found out I need to split the dump so I can upload it in pieces of 20 mb. It just doesn't seem to work.

I have no experience with mysql. I'm afraid I'll ruin the dump file.
I asked my new host if I can import the databse through telnet or shh but they don't support it.

Any advice on how to solve my problem is greatly apreciated, I really need to get it working.

I'm running version vb 2.3.2

Thanks in advance,

latinO

KingSpade
Mon 9th Jan '06, 6:50pm
Unless you have access to SSH or you really split the backup into multiple parts, you're going to have a time getting that file uploaded. To be honest, regardless of settings, phpMyAdmin wasn't really made to upload 100MB+ files, if you look around, you'll even notice most complaints are about struggling with 20MB's.

If you're current host doesn't support SSH at all and won't even attempt to help you move the database over, I'd start looking for a new host. Most hosts that disallow SSH will still do the common database dump here and there to help their clients out.

In your case, you really need SSH access or the host needs to help.

1996 328ti
Mon 9th Jan '06, 9:28pm
Any advice on how to solve my problem is greatly apreciated, I really need to get it working.
http://www.ozerov.de/bigdump
It breaks up your sql file into bit size chunks.

encryption
Tue 10th Jan '06, 8:23am
You can also use a program like HJSplit to break up your dump file into smaller files. However you will then need to cut and paste your db into phpmyadmin as HJSplit might split the dump file halfway through the queries and ruin your upload.

latinO
Tue 10th Jan '06, 5:36pm
http://www.ozerov.de/bigdump
It breaks up your sql file into bit size chunks.

Hi thank you all for your help and advice!
I tried to do it with this bigdump script but I get the following error;



BigDump: Staggered MySQL Dump Importer ver. 0.21b

Processing file: name.backup.sql
Starting at the line: 1
Error at the line 11: DROP TABLE IF EXISTS access;
Query: -- --------------------------------------------------------- -- -- DROP TABLE IF EXISTS access;
MySQL: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '--------------------------------------------------------- -- --
Stopped on error


What am I doing wrong?

Thanks in advance!

latinO

1996 328ti
Tue 10th Jan '06, 10:12pm
Hi thank you all for your help and advice!
I tried to do it with this bigdump script but I get the following errorSorry. The only errors I every had were config mistakes.

latinO
Wed 11th Jan '06, 2:56pm
Sorry. The only errors I every had were config mistakes.

Okay,

I think it's working now. After a few minutes I get this:



Processing file: name.backup.sql
Starting at the line: 805009


I don't get any error message but the script simply stops. If I look at the content of the database through phpmyadmin I can see it has importing a part if it but not everything. Through phpmyadmin it displays a size of 243,6 MB but the sql dump is around 350 mb. I don't know how it works with sql text files but I guess it's impossible to upload 243.6 mb in a couple of minutes with a max upload of 90 kb/sec.

What's going on?

p.s. Do I need to import the database first and then install vbulletin or the other way around?

Thanks!

latinO

KingSpade
Wed 11th Jan '06, 7:11pm
1). Import the databse
2). Upload the files, don't install.

If you are using the same version, vbulletin will take effect with the new database, though you will need to change the details in config.php.

As for the script, as above, phpMyAdmin wasn't made to upload such a large amount to be honest.

If the above script you used crunched the DB down, it could have not been optimized and it could have simply removed data that wasn't needed (like the DROP TABLE info).