RES: RES: RES: Force drop table
/en/innodb-troubleshooting.html how you can resolve the problem. [At this point I deleted the table “obras.frm”. Still trying to dump, crashing every time, and restarting mysqld with a higher “innodb_force_recovery” value at a time] 120126 12:16:53 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 120126 12:16:53 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 175700181. InnoDB: Doing recovery: scanned up to log sequence number 0 175700191 120126 12:16:53 InnoDB: Started; log sequence number 0 175700191 120126 12:16:53 [Note] MyAvanutri: ready for connections. Version: '5.0.26-community' socket: '' port: 3366 MySQL Community Edition (GPL) 120126 12:18:36 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 120126 12:18:36 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 175700191. InnoDB: Doing recovery: scanned up to log sequence number 0 175700201 120126 12:18:36 InnoDB: Started; log sequence number 0 175700201 InnoDB: !!! innodb_force_recovery is set to 1 !!! 120126 12:18:36 [Note] MyAvanutri: ready for connections. Version: '5.0.26-community' socket: '' port: 3366 MySQL Community Edition (GPL) 120126 12:19:15 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 120126 12:19:15 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 175700201. InnoDB: Doing recovery: scanned up to log sequence number 0 175700211 120126 12:19:16 InnoDB: Started; log sequence number 0 175700211 InnoDB: !!! innodb_force_recovery is set to 1 !!! 120126 12:19:16 [Note] MyAvanutri: ready for connections. Version: '5.0.26-community' socket: '' port: 3366 MySQL Community Edition (GPL) 120126 12:19:31 [Note] MyAvanutri: Normal shutdown 120126 12:19:31 InnoDB: Starting shutdown... 120126 12:19:34 InnoDB: Shutdown completed; log sequence number 0 175700211 120126 12:19:34 [Note] MyAvanutri: Shutdown complete 120126 12:19:40 InnoDB: Started; log sequence number 0 175700211 InnoDB: !!! innodb_force_recovery is set to 2 !!! 120126 12:19:40 [Note] MyAvanutri: ready for connections. Version: '5.0.26-community' socket: '' port: 3366 MySQL Community Edition (GPL) 120126 12:20:20 InnoDB: Started; log sequence number 0 175700211 InnoDB: !!! innodb_force_recovery is set to 3 !!! 120126 12:20:20 [Note] MyAvanutri: ready for connections. Version: '5.0.26-community' socket: '' port: 3366 MySQL Community Edition (GPL) 120126 12:21:05 InnoDB: Started; log sequence number 0 175700211 InnoDB: !!! innodb_force_recovery is set to 4 !!! 120126 12:21:05 [Note] MyAvanutri: ready for connections. Version: '5.0.26-community' socket: '' port: 3366 MySQL Community Edition (GPL) 120126 12:21:43 InnoDB: Started; log sequence number 0 175700211 InnoDB: !!! innodb_force_recovery is set to 5 !!! 120126 12:21:43 [Note] MyAvanutri: ready for connections. Version: '5.0.26-community' socket: '' port: 3366 MySQL Community Edition (GPL) InnoDB: The user has set SRV_FORCE_NO_LOG_REDO on InnoDB: Skipping log redo 120126 12:22:25 InnoDB: Started; log sequence number 0 0 InnoDB: !!! innodb_force_recovery is set to 6 !!! 120126 12:22:25 [Note] MyAvanutri: ready for connections. Version: '5.0.26-community' socket: '' port: 3366 MySQL Community Edition (GPL) Mateus Almeida Avanutri Nutrição Serviços e Informática Ltda ME CNPJ 07.775.666.0001-60 Insc. Estadual 780.532-67 Rua São José , Nº 1304 Triângulo - Três Rios, RJ CEP 25820-150 Tel./fax: 24 2252-2468 ou 24 2252-2197 website: http://www.avanutri.com.br/ www.avanutri.com.br E-mail e MSN: mailto:supor...@avanutri.com.br supor...@avanutri.com.br Skype: suporteavanutri2 De: Johan De Meersman [mailto:vegiv...@tuxera.be] Enviada em: quarta-feira, 25 de janeiro de 2012 11:02 Para: Suporte Avanutri Cc: Shafi AHMED; mysql@lists.mysql.com; Suresh Kuna Assunto: Re: RES: RES: Force drop table Can you send the error logs from my and Suresh' solutions, so we can see what the next thing to go wrong is ? :-) _ From: Suporte Avanutri supor...@avanutri.com.br To: Suresh Kuna sureshkumar...@gmail.com Cc: Johan De Meersman vegiv...@tuxera.be, Shafi AHMED shafi.ah...@sifycorp.com, mysql@lists.mysql.com Sent: Wednesday, 25 January, 2012 1:33:54 PM Subject: RES: RES: Force drop table No good news until now... I’m starting to think that I will not recover it. When all
Re: RES: RES: Force drop table
2012/1/26 Suporte Avanutri supor...@avanutri.com.br: [At this point I deleted the table “obras.frm”. Still trying to dump, crashing every time, and restarting mysqld with a higher “innodb_force_recovery” value at a time] It doesn't matter what you set in innodb_force_recovery. If you do not have the obras.frm file (which contains the schema definition of the table), I don't know if you can retrieve the info. Put that file back, start it with a value of 6, and see if you can get any of the data out. If the data is important and have a budget for recovery, you can try (whatever solution is local for you) hiring a consultant skilled in mysql crash data recovery: - Oracle - Percona - SkySQL Regards...Todd -- SOPA: Any attempt to [use legal means to] reverse technological advances is doomed. --Leo Leporte -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: RES: RES: Force drop table
- Original Message - From: Todd Lyons tly...@ivenue.com It doesn't matter what you set in innodb_force_recovery. If you do not have the obras.frm file (which contains the schema definition of the table), I don't know if you can retrieve the info. Put that file I recommended he delete that file since he was trying to delete the table anyway, and the log said there was no metadata for that table. Mateus, I see in the last bit of logs that the recovery sequence number remains constant. Does the server still crash at that point even though there are no more error messages? What happens if you remove the innodb_force_recovery setting? If it keeps crashing without errors, you may be up shit creek :-) You can try running it through strace, but the output of that is going to be long and confusing. If you can't just do a clean install and restore from backups, a good consultant might be your best bet at this point. -- Bier met grenadyn Is als mosterd by den wyn Sy die't drinkt, is eene kwezel Hy die't drinkt, is ras een ezel -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
RES: RES: RES: Force drop table
Mysqld crashes when I try to dump everything at once. I made a test by extracting information from only one table, and it worked. I will try yet with another tables. But I guess that is it... Thanks a lot, people. You were great. =) -Mensagem original- De: Johan De Meersman [mailto:vegiv...@tuxera.be] Enviada em: quinta-feira, 26 de janeiro de 2012 14:53 Para: Todd Lyons Cc: MySQL Help; Suporte Avanutri Assunto: Re: RES: RES: Force drop table - Original Message - From: Todd Lyons tly...@ivenue.com It doesn't matter what you set in innodb_force_recovery. If you do not have the obras.frm file (which contains the schema definition of the table), I don't know if you can retrieve the info. Put that file I recommended he delete that file since he was trying to delete the table anyway, and the log said there was no metadata for that table. Mateus, I see in the last bit of logs that the recovery sequence number remains constant. Does the server still crash at that point even though there are no more error messages? What happens if you remove the innodb_force_recovery setting? If it keeps crashing without errors, you may be up shit creek :-) You can try running it through strace, but the output of that is going to be long and confusing. If you can't just do a clean install and restore from backups, a good consultant might be your best bet at this point. -- Bier met grenadyn Is als mosterd by den wyn Sy die't drinkt, is eene kwezel Hy die't drinkt, is ras een ezel -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
RES: RES: Force drop table
No good news until now... Im starting to think that I will not recover it. When all these tips doesnt work, should I presume that my database is dead? De: Suresh Kuna [mailto:sureshkumar...@gmail.com] Enviada em: quarta-feira, 25 de janeiro de 2012 02:10 Para: Suporte Avanutri Cc: Johan De Meersman; Shafi AHMED; mysql@lists.mysql.com Assunto: Re: RES: Force drop table Enable the option innodb_force_recovery =1 in my.cnf file, restart the database, ( can try upto 4 depending on the description below url ) and take the dump of all the innodb tables, remove the ibdata and data file belongs to innodb and re-import. It should be fine. http://dev.mysql.com/doc/refman/5.0/en/forcing-innodb-recovery.html Thanks Suresh Kuna 2012/1/24 Suporte Avanutri supor...@avanutri.com.br I've tried this before, but the server stills going down. The first error is always this: Couldn't execute 'SELECT /*!40001 SQL_NO_CACHE */* FROM 'usuario': Lost connection to MySQL server during query (2013) This is followed by other similar errors: couldn't execute one thing, couldn't execute another thing, etc. I've got the error while trying to execute this: mysqldump -u USER -pPASS --force --databases DATABASE (and tried --all-databases too). Thanks in advance for the help, guys. I'm starting to learn this thing by myself, your help has great value to me. -Mensagem original- De: Johan De Meersman [mailto:vegiv...@tuxera.be] Enviada em: terça-feira, 24 de janeiro de 2012 13:01 Para: Suporte Avanutri Cc: Shafi AHMED; mysql@lists.mysql.com Assunto: Re: RES: Force drop table - Original Message - From: Suporte Avanutri supor...@avanutri.com.br To: Shafi AHMED shafi.ah...@sifycorp.com, mysql@lists.mysql.com Sent: Tuesday, 24 January, 2012 3:43:36 PM Subject: RES: Force drop table 120124 12:29:28 InnoDB: Error: table `avanutri/obras` does not exist in the InnoDB internal InnoDB: data dictionary though MySQL is trying to drop it. InnoDB: Have you copied the .frm file of the table to the InnoDB: MySQL database directory from another database? That's a pretty good question it's asking :-) Earlier in your log it mentions that InnoDB wasn't shut down properly - did it crash while you were deleting that table, by any chance? Shut the service down, delete the file mysqldatadir/avanutri/obras.frm from disk and restart the service; the table will be gone. There shouldn't be any other files named obras.something if all is well. If you can, it is probably also a good idea to make a full dump of all the databases and reinitialize the InnoDB tablespaces - there may still be internal references or pages allocated to that table. Check the online manual for more information on doing that. -- Bier met grenadyn Is als mosterd by den wyn Sy die't drinkt, is eene kwezel Hy die't drinkt, is ras een ezel -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql -- Thanks Suresh Kuna MySQL DBA
Re: RES: RES: Force drop table
Can you send the error logs from my and Suresh' solutions, so we can see what the next thing to go wrong is ? :-) - Original Message - From: Suporte Avanutri supor...@avanutri.com.br To: Suresh Kuna sureshkumar...@gmail.com Cc: Johan De Meersman vegiv...@tuxera.be, Shafi AHMED shafi.ah...@sifycorp.com, mysql@lists.mysql.com Sent: Wednesday, 25 January, 2012 1:33:54 PM Subject: RES: RES: Force drop table No good news until now... I’m starting to think that I will not recover it. When all these tips doesn’t work, should I presume that my database is dead? De: Suresh Kuna [mailto:sureshkumar...@gmail.com] Enviada em: quarta-feira, 25 de janeiro de 2012 02:10 Para: Suporte Avanutri Cc: Johan De Meersman; Shafi AHMED; mysql@lists.mysql.com Assunto: Re: RES: Force drop table Enable the option innodb_force_recovery =1 in my.cnf file, restart the database, ( can try upto 4 depending on the description below url ) and take the dump of all the innodb tables, remove the ibdata and data file belongs to innodb and re-import. It should be fine. http://dev.mysql.com/doc/refman/5.0/en/forcing-innodb-recovery.html Thanks Suresh Kuna 2012/1/24 Suporte Avanutri supor...@avanutri.com.br I've tried this before, but the server stills going down. The first error is always this: Couldn't execute 'SELECT /*!40001 SQL_NO_CACHE */* FROM 'usuario': Lost connection to MySQL server during query (2013) This is followed by other similar errors: couldn't execute one thing, couldn't execute another thing, etc. I've got the error while trying to execute this: mysqldump -u USER -pPASS --force --databases DATABASE (and tried --all-databases too). Thanks in advance for the help, guys. I'm starting to learn this thing by myself, your help has great value to me. -- Bier met grenadyn Is als mosterd by den wyn Sy die't drinkt, is eene kwezel Hy die't drinkt, is ras een ezel
Re: RES: Force drop table
2012/1/24 Suporte Avanutri supor...@avanutri.com.br: I've tried this before, but the server stills going down. The first error is always this: Couldn't execute 'SELECT /*!40001 SQL_NO_CACHE */* FROM 'usuario': Lost connection to MySQL server during query (2013) What's likely happening here is that the access to the table is causing a fatal error inside your mysql daemon, it dies and restarts, resulting in the log messages you see about mysql not being shut down properly and doing a crash recovery. The followup suggestion was for you to put innodb_force_recovery=1 in your my.cnf and restart it, but that didn't work for you. The value that you pass to innodb_force_recovery controls how much of the innodb startup / crash recovery process to use. The gory details are at http://dev.mysql.com/doc/refman/5.0/en/forcing-innodb-recovery.html . Valid values are between 1 and 6. For example, I shut down my mysql daemon, I make a copy of my corrupted database at /var/lib/mysql/ into /var/lib/mysql_tmp/, and then manually start the mysql daemon in the foreground with this: su - mysql -c '/usr/libexec/mysqld --innodb_force_recovery=6 --datadir /var/lib/mysql_tmp/' It simply sounds like you need to find the appropriate value to use to make your data accessible. Regards... Todd -- SOPA: Any attempt to [use legal means to] reverse technological advances is doomed. --Leo Leporte -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: RES: Force drop table
On Wed, Jan 25, 2012 at 6:42 AM, Todd Lyons tly...@ivenue.com wrote: For example, I shut down my mysql daemon, I make a copy of my corrupted database at /var/lib/mysql/ into /var/lib/mysql_tmp/, and then manually start the mysql daemon in the foreground with this: su - mysql -c '/usr/libexec/mysqld --innodb_force_recovery=6 --datadir /var/lib/mysql_tmp/' I forgot to mention that when you do this, there will be copious amounts of debug output that are spit out and it will give really ugly warnings about tables that it finds but metadata doesn't match up. But usually it can get the data out, though if you're not processing any undo/redo logs, there's a chance that the most recent data written to the table will not be retrievable. Regards... Todd -- SOPA: Any attempt to [use legal means to] reverse technological advances is doomed. --Leo Leporte -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
RES: Force drop table
You can see the error report below: ---error file- 120124 12:23:07 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 120124 12:23:07 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 175700625. InnoDB: Doing recovery: scanned up to log sequence number 0 175700625 120124 12:23:08 InnoDB: Started; log sequence number 0 175700625 120124 12:23:08 [Note] MyAvanutri: ready for connections. Version: '5.0.26-community' socket: '' port: 3366 MySQL Community Edition (GPL) 120124 12:28:26 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 120124 12:28:26 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 175700625. InnoDB: Doing recovery: scanned up to log sequence number 0 175700625 120124 12:28:26 InnoDB: Started; log sequence number 0 175700625 120124 12:28:26 [Note] MyAvanutri: ready for connections. Version: '5.0.26-community' socket: '' port: 3366 MySQL Community Edition (GPL) 120124 12:29:28 InnoDB: Error: table `avanutri/obras` does not exist in the InnoDB internal InnoDB: data dictionary though MySQL is trying to drop it. InnoDB: Have you copied the .frm file of the table to the InnoDB: MySQL database directory from another database? InnoDB: You can look for further help from InnoDB: http://dev.mysql.com/doc/refman/5.0/en/innodb-troubleshooting.html 120124 12:32:06120124 12:32:06 [ERROR] Cannot find table avanutri/obras from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? See http://dev.mysql.com/doc/refman/5.0/en/innodb-troubleshooting.html how you can resolve the problem. 120124 12:32:06120124 12:32:06 [ERROR] Cannot find table avanutri/obras from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? See http://dev.mysql.com/doc/refman/5.0/en/innodb-troubleshooting.html how you can resolve the problem. ---end of error file Despite the error, mysql does shows obras as a table in the database. But when I try to drop it, I receive an ERROR 1051 (42S02): UNKOWN TABLE obras. I've tried mysqldump with force option, but it returns got terror: 1146: Table avanutri.obras doesn't exist when using lock tables. Then: couldn't execute 'show create table 'obras': Table 'avanutri.obras' doesn't exist (1146) Then the prompt freezes a while. After a few seconds, mysqld stops itself and the dump is aborted. -Mensagem original- De: Shafi AHMED [mailto:shafi.ah...@sifycorp.com] Enviada em: terça-feira, 24 de janeiro de 2012 10:52 Para: 'Suporte Avanutri'; mysql@lists.mysql.com Assunto: RE: Force drop table Hi, What is the error associated with pls? Best Rgs, Shafi AHMED -Original Message- From: Suporte Avanutri [mailto:supor...@avanutri.com.br] Sent: Tuesday, January 24, 2012 6:05 PM To: mysql@lists.mysql.com Subject: Force drop table Hello, I need to drop a table, but mysql cannot do it. I think the database is corrupt. Is there some way to force the drop? Mateus Almeida Suporte Técnico Avanutri Nutrição Serviços e Informática Ltda ME CNPJ 07.775.666.0001-60 Insc. Estadual 780.532-67 Rua Maestro Costa Barros, Nº 39/401 Centro - Três Rios, RJ CEP 25805-090 Tel./fax: 24 2252-2468 website: http://www.avanutri.com.br/ www.avanutri.com.br E-mail e MSN: mailto:supor...@avanutri.com.br supor...@avanutri.com.br Skype: suporteavanutri2 Get your world in your inbox! Mail, widgets, documents, spreadsheets, organizer and much more with your Sifymail WIYI id! Log on to http://www.sify.com ** DISCLAIMER ** Information contained and transmitted by this E-MAIL is proprietary to Sify Technologies Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified
Re: RES: Force drop table
- Original Message - From: Suporte Avanutri supor...@avanutri.com.br To: Shafi AHMED shafi.ah...@sifycorp.com, mysql@lists.mysql.com Sent: Tuesday, 24 January, 2012 3:43:36 PM Subject: RES: Force drop table 120124 12:29:28 InnoDB: Error: table `avanutri/obras` does not exist in the InnoDB internal InnoDB: data dictionary though MySQL is trying to drop it. InnoDB: Have you copied the .frm file of the table to the InnoDB: MySQL database directory from another database? That's a pretty good question it's asking :-) Earlier in your log it mentions that InnoDB wasn't shut down properly - did it crash while you were deleting that table, by any chance? Shut the service down, delete the file mysqldatadir/avanutri/obras.frm from disk and restart the service; the table will be gone. There shouldn't be any other files named obras.something if all is well. If you can, it is probably also a good idea to make a full dump of all the databases and reinitialize the InnoDB tablespaces - there may still be internal references or pages allocated to that table. Check the online manual for more information on doing that. -- Bier met grenadyn Is als mosterd by den wyn Sy die't drinkt, is eene kwezel Hy die't drinkt, is ras een ezel -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
RES: RES: Force drop table
I've tried this before, but the server stills going down. The first error is always this: Couldn't execute 'SELECT /*!40001 SQL_NO_CACHE */* FROM 'usuario': Lost connection to MySQL server during query (2013) This is followed by other similar errors: couldn't execute one thing, couldn't execute another thing, etc. I've got the error while trying to execute this: mysqldump -u USER -pPASS --force --databases DATABASE (and tried --all-databases too). Thanks in advance for the help, guys. I'm starting to learn this thing by myself, your help has great value to me. -Mensagem original- De: Johan De Meersman [mailto:vegiv...@tuxera.be] Enviada em: terça-feira, 24 de janeiro de 2012 13:01 Para: Suporte Avanutri Cc: Shafi AHMED; mysql@lists.mysql.com Assunto: Re: RES: Force drop table - Original Message - From: Suporte Avanutri supor...@avanutri.com.br To: Shafi AHMED shafi.ah...@sifycorp.com, mysql@lists.mysql.com Sent: Tuesday, 24 January, 2012 3:43:36 PM Subject: RES: Force drop table 120124 12:29:28 InnoDB: Error: table `avanutri/obras` does not exist in the InnoDB internal InnoDB: data dictionary though MySQL is trying to drop it. InnoDB: Have you copied the .frm file of the table to the InnoDB: MySQL database directory from another database? That's a pretty good question it's asking :-) Earlier in your log it mentions that InnoDB wasn't shut down properly - did it crash while you were deleting that table, by any chance? Shut the service down, delete the file mysqldatadir/avanutri/obras.frm from disk and restart the service; the table will be gone. There shouldn't be any other files named obras.something if all is well. If you can, it is probably also a good idea to make a full dump of all the databases and reinitialize the InnoDB tablespaces - there may still be internal references or pages allocated to that table. Check the online manual for more information on doing that. -- Bier met grenadyn Is als mosterd by den wyn Sy die't drinkt, is eene kwezel Hy die't drinkt, is ras een ezel -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: RES: Force drop table
Enable the option innodb_force_recovery =1 in my.cnf file, restart the database, ( can try upto 4 depending on the description below url ) and take the dump of all the innodb tables, remove the ibdata and data file belongs to innodb and re-import. It should be fine. http://dev.mysql.com/doc/refman/5.0/en/forcing-innodb-recovery.html Thanks Suresh Kuna 2012/1/24 Suporte Avanutri supor...@avanutri.com.br I've tried this before, but the server stills going down. The first error is always this: Couldn't execute 'SELECT /*!40001 SQL_NO_CACHE */* FROM 'usuario': Lost connection to MySQL server during query (2013) This is followed by other similar errors: couldn't execute one thing, couldn't execute another thing, etc. I've got the error while trying to execute this: mysqldump -u USER -pPASS --force --databases DATABASE (and tried --all-databases too). Thanks in advance for the help, guys. I'm starting to learn this thing by myself, your help has great value to me. -Mensagem original- De: Johan De Meersman [mailto:vegiv...@tuxera.be] Enviada em: terça-feira, 24 de janeiro de 2012 13:01 Para: Suporte Avanutri Cc: Shafi AHMED; mysql@lists.mysql.com Assunto: Re: RES: Force drop table - Original Message - From: Suporte Avanutri supor...@avanutri.com.br To: Shafi AHMED shafi.ah...@sifycorp.com, mysql@lists.mysql.com Sent: Tuesday, 24 January, 2012 3:43:36 PM Subject: RES: Force drop table 120124 12:29:28 InnoDB: Error: table `avanutri/obras` does not exist in the InnoDB internal InnoDB: data dictionary though MySQL is trying to drop it. InnoDB: Have you copied the .frm file of the table to the InnoDB: MySQL database directory from another database? That's a pretty good question it's asking :-) Earlier in your log it mentions that InnoDB wasn't shut down properly - did it crash while you were deleting that table, by any chance? Shut the service down, delete the file mysqldatadir/avanutri/obras.frm from disk and restart the service; the table will be gone. There shouldn't be any other files named obras.something if all is well. If you can, it is probably also a good idea to make a full dump of all the databases and reinitialize the InnoDB tablespaces - there may still be internal references or pages allocated to that table. Check the online manual for more information on doing that. -- Bier met grenadyn Is als mosterd by den wyn Sy die't drinkt, is eene kwezel Hy die't drinkt, is ras een ezel -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql -- Thanks Suresh Kuna MySQL DBA
