If it's an option, buy more RAM and more disks.. Is it a 17gb table or 17gb of data spread across several tables? If it's across several tables, you won't have as much trouble rebuilding the indexes.
Another option is to build another machine with a bunch of ram and a RAID1 or RAID10 (SATA or SCSI). Import it there and copy the data files up to the server. On 5/20/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I doubt there is much to do. Your hardware is the bottleneck I would > think. You will completely kill the server regenerating the indexes > afterwards as well, so if the idea is to get is up and running fast, it > may not be so fast once you get it up. > > -----Original Message----- > From: Mikel - [mailto:[EMAIL PROTECTED] > Sent: Friday, May 20, 2005 11:05 AM > To: mysql@lists.mysql.com > Subject: recovering a 17G dump > > Hi list, > > I have a 17G dump from my DB, any suggestions to recover that dump > faster, > any variables to tune up?... I don't have an accurate binary backup, so I > have to restore it from my 17G text file. > > I remove the indexes, foreign keys, I will create them after I've > recovered > all the data. > I have an innodb storage, mysql ver. 3.23-58, 80G HD, 1G RAM on a > white-box > linux distribution. > > Thanks in advanced for your suggestions > > Greetings > > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
